h1

Por qué fallan los proyectos IT

04/30/2010

Wizdoc [Icon By Buuf]  Tips & Tricks.

No se puede tener un gran software sin un gran equipo, y la mayoría de los equipos de desarrollo se comportan como familias disfuncionales.

Jim McCarthy, ingeniero de software norteamericano.

Después de un par de semanas de cambios y más cambios por parte del usuario, retrasos de otro proveedor que impactaron en nuestros propios tiempos, así como las motivadoras palabras de "High Management" como "No sé qué estás haciendo; para mí que me estás tomando el pelo", el miércoles pasado terminamos la primera fase de nuestra implantación del portal y gestor de contenidos Liferay para un cliente.

En estos momentos estamos cerrando algunos detalles finos como documentación y cursos de capacitación, pero ya empezamos con la segunda fase y hemos regresado a los horarios "normales" de 9 A.M. a 7 P.M., pues en las semanas anteriores salíamos hasta las 9 o 10 de la noche. De hecho, mi estrés alcanzó su punto máximo el viernes antepasado, cuando me eché un round verbal con el jefe porque se puso a gritonearme con la frasecita "¡Si el firewall del cliente no permite que levante nuestro portal, me vale madres! ¡Te pago por resolver problemas, no crearlos!" Y el señor estuvo a punto de perder no sólo a un integrante del equipo, sino a 3, pues cabe destacar dos cosas: una, que la expresión "me vale madres" calienta hasta al más frío, sobre todo si proviene de un jefe que no te quiere escuchar; la segunda es digna del Jefe Pelopunta de Dilbert, pues ¿de cuándo a acá los proveedores podemos exigir al cliente que apague su firewall para que levanten nuestras aplicaciones? Ni arrastrándome con los labios a la Basílica de Guadalupe se me hubiese cumplido el "milagrito".

Un post-mortem

Pero bueno, después de la tormenta viene la calma. Ya un poco más relajados, mis superiores me comentaron que desde su punto de vista, este proyecto estuvo a punto de fracasar. Siento que no tenían la "foto completa" del estatus del proyecto porque sí, existía un retraso, pero no era atribuible a nosotros. De hecho, una vez que estos señores se pusieron las pilas, negociaron con el cliente un incremento de dos semanas al costo del proyecto, con lo que nos dieron un respiro. Sin embargo, esto me provocó la inquietud de generar un post-mortem del proyecto, sobre todo porque tendremos que lidiar con el mismo cliente y mismos jefes para las siguientes entregas. En términos generales, éstos fueron los resultados que encontré en conjunto con el resto del equipo:

• A nivel técnico, éramos el primer equipo en la empresa que implementaba Liferay para una aplicación de la vida real. Aunque se nos sugirió contactar a los expertos en Liferay del Cuartel General, casi de inmediato declinamos su ayuda. ¿La razón? El líder del otro equipo nos contestó una pregunta con la siguiente frase: "¿portlets a la medida?… mmm no, aquí implementamos Liferay out-of-the-box para 60 usuarios en total."

• Los retrasos se debieron a que el otro proveedor es responsable de componentes críticos de la solución y sin estos componentes, no podíamos salir.

• Al existir una demora en la salida a producción, el cliente aprovechó los "tiempos muertos" para pedir funcionalidad adicional que mis jefes aceptaron gustosamente, para quedar bien con el cliente con un "plus" que podríamos aportar.

• Aceptar esta funcionalidad adicional fue algo natural porque consideraron que estos "pequeños cambios" como transparencias de componentes HTML o terminar ésta y otras funcionalidades con compatibilidad cross-browser para Explorer 6, 7 y 8 son algo muy sencillo de implementar: "a final de cuentas sólo es HTML y JavaScript, ¿qué tan difícil puede ser?"

• Finalmente, la falta de comunicación entre la dirección, el cliente y el equipo. Jugando al "teléfono descompuesto" nos metimos todos en un lodazal. Por ejemplo, el cliente solicita a "High Management" realizar un set de pruebas el viernes por la mañana, pero nadie comunica de este hecho al equipo. Sin deberla ni temerla, llegamos a trabajar el viernes por la mañana, para en el momento en que nos sentamos en nuestro lugar ser instantáneamente acosados por los altos mandos preguntando, histéricos, por qué todo está abajo.

A partir de esto surgieron un par de recomendaciones para cambiar esta situación de ahora en adelante. La primera y más importante, alineación y comunicación entre "High Management" y el equipo de trabajo. Si la alta dirección quiere gestionar el proyecto, puede hacerlo pero entonces no necesita un Project Manager, sino un responsable de proyecto que sólo dé seguimiento a las decisiones de más arriba. Lo opuesto es igualmente cierto: si se está realizando una gestión de proyectos formal, las buenas prácticas como el PMBOK dictan que el Project Manager es el amo y señor indiscutible del proyecto. Las medidas intermedias sólo generan "varias cabezas" que resultarán en acuerdos y tareas que no son del conocimiento de todos, acabando por impactar al proyecto, a menos que exista una alineación total de todos los involucrados.

Por otro lado, un tema muy común en el área de consultoría: como account manager no debes vender un "plus" ni comprometer tiempos al cliente sin antes consultar con el área técnica, incluso si hace poco fuiste programador. ¿Por qué? Ésta industria avanza a pasos agigantados, y con un par de años que dejes de programar te oxidas por completo. Si no confías en tus técnicos y crees que lo que hacen es fácil o "siempre buscan la manera de tomarte el pelo", estás jodido. En este caso particular, al susodicho que se cree account manager-programador-arquitecto-investigador se la estoy guardando para que en el momento que me salga con otro "¡Pero eso es fácil! ¡Hasta yo te puedo echar la mano!" me lo voy a torcer con la de "OK: échatela tú" e inmediatamente notifique a todos que este señor ha tomado responsabilidad por un entregable técnico.

¿Por qué fracasan los proyectos IT?

La anterior anécdota ha servido de preámbulo para contestar la siguiente cuestión: ¿Por qué fallan los proyectos IT con tanta frecuencia? De acuerdo al reporte El impacto de requerimientos de negocio en el éxito de proyectos de tecnología (aquí el PDF), realizado por IAG Consulting:

68% de los proyectos son marginalmente exitosos o completos fracasos. De hecho, 50% de los proyectos "marginalmente exitosos" fueron "fugitivos" que poseían dos de las siguientes tres características:

• Tomar más de 180% del tiempo para ser terminados.
• Consumir un exceso del 160% sobre el presupuesto estimado.
• La entrega de menos del 70% de la funcionalidad requerida.

Esto significa que dos de cada tres proyectos se cancelan o son tan malos que nadie no los usa y que la mitad de los que hacen "el paso de la muerte" acabaron batiéndose de alguna u otra forma. ¿Cuáles son las razones de este comportamiento? La mayoría ya los sabe, pero con el afán de completitud, incluyo la lista de los 10 pecados capitales en IT:

1. Requerimientos incompletos. Mala recopilación de requerimientos y su documentación.

2. Fallas en la comunicación. Comunicación deficiente entre programadores, stakeholders, usuarios y la alta administración. Falta de participación del usuario.

3. Falta de recursos. Desarrolladores insuficientes o con falta de skills. Desarrolladores que no trabajan en equipo. Alta rotación de los desarrolladores.

4. Metas poco realistas. Calendario poco realista, conduciendo a presiones de tiempo y estrés sobre los desarrolladores, desembocando en errores, malas decisiones e incluso alta rotación del equipo.

5. Requerimientos cambiantes. Requerimientos que cambian frecuentemente. Scope creep.

6. Falta de planeación. Planeación y documentación inconsistente del proyecto.

7. Malas prácticas de desarrollo. Prácticas de desarrollo de la Edad de Piedra. Por ejemplo, sin control de versiones o rastreo de incidencias. Las pruebas son usualmente una idea tardía.

8. Seguimiento deficiente. Escasa presentación de informes acerca del estatus del proyecto. Los stakeholders no tienen idea del progreso del proyecto o sus hitos.

9. Uso de tecnologías inmaduras. Usar nueva tecnología para impresionar a los clientes. Tecnología con la que los desarrolladores no están familiarizados.

10. Presiones comerciales. Presiones para lanzar el producto por razones comerciales.

La mayoría de estos riesgos son mitigados con metodologías de arquitectura, calidad, gestión de proyectos y desarrollo para asegurar el éxito. Sin embargo, ¿Por qué sigue existiendo un altísimo índice de fracaso en la industria? Incluso adoptando todas estas medida tenemos una alta probabilidad de que el proyecto se bata o falle en sus objetivos. La respuesta es relativamente sencilla, pero primero revisemos una de las grandes verdades de la ingeniería de software:

Menos del 5% de todos los proyectos IT fallan debido a la tecnología.

Es decir, a menos que seleccionemos COBOL para desplegar un portal web o Visual Basic para realizar una implementación de Business Intelligence, la mayoría de los proyectos tienen una excelente probabilidad de salir adelante si usamos las herramientas adecuadas. El correcto entrenamiento en dichas herramientas es otro cantar, pero la mayoría de las veces los programadores pasan por una curva de aprendizaje y tarde o temprano se vuelven productivos. Sin embargo, incluso si la mitad de los programadores fueran absolutos incompetentes que nunca generan código coherente, nuestro índice de falla sería del 50%, pero en la práctica esto no ocurre. De hecho, existen proyectos que son la crème de la crème en aspectos de calidad, liberados en tiempo y presupuesto pero… nadie los usa, formando parte de ese 68%.

La respuesta está en la gente

De acuerdo a Michael Krigsman, CEO de Asuret, una firma especializada en Gobierno IT, las fallas en los proyectos se deben a una comunicación, colaboración y planeación disfuncionales entre las áreas involucradas. Es decir, entre los stakeholders, no se hablan unos con otros, manejando diferentes expectativas y metas, acabando por llevar el proyecto al desagüe. ¿Eso es todo? Absolutamente. Resulta que lo malo de los proyectos es la gente y la manera en la que se comunican o fallan en hacerlo. El blog Companies Management (hoy difunto) nos da diez signos de un desastre inminente:

1. El proyecto está basado en los sueños del CEO, pero nadie tiene claro su valor de negocio.

2. El patrocinador está demasiado ocupado para escuchar, o es demasiado débil para ofrecer su apoyo.

3. "High Management" quiere empezar a trabajar ya y preocuparse por la planeación después.

4. Los estimados de la duración del proyecto son realizados por "High Management".

5. "High Management" indica al Project Manager que ignore términos contractuales vagos.

6. "High Management" advierte al Project Manager que no levante la mano acerca de problemas durante la fase de planeación.

7. Los gerentes funcionales proporcionan los recursos incorrectos.

8. El cliente acepta trabajo de manera formal, pero se niega a ponerlo sobre escrito.

9. Las expectativas del cliente son demasiado elevadas o mal administradas por el Project Manager.

10. El Project Manager está demasiado preocupado en perder el empleo o enfadar al cliente.

Ooops. Casi todos estos issues tienen que ver con la falta de comunicación entre los stakeholders; la mayoría se resuelve con un cafecito y una pequeña charla en corto. Otros son complejos y a menos que los involucrados se reúnan y platiquen abiertamente sobre el riesgo y cómo mitigarlo, tarde o temprano se volverán críticos, golpeando la viabilidad del proyecto. Entonces, ¿cómo asegurar que todos estemos en el mismo canal? Para lograrlo debemos considerar las "tres verdades del éxito en IT", que el mismo Krigsman define:

1. La creación del valor define el éxito. Contrario a la creencia popular, incluso proyectos tardíos o que han rebasado su presupuesto pueden ser increíblemente exitosos si proporcionan el suficiente valor a la organización. Sin embargo, la organización primero debe tener una comprensión clara y unánime de la importancia del proyecto.

2. La colaboración es esencial. Por definición, las iniciativas que tocan diferentes áreas o departamentos involucran la distribución activa de información, así como la comunicación entre diferentes silos y segmentos. Administrar expectativas "implícitas" es difícil, especialmente cuando los stakeholders pertenecen a múltiples organizaciones con diferentes definiciones del éxito.

3. La gente es lo más importante. Aunque la frase "Alineación IT/negocio" es un cliché, la comunicación consistente y sistemática es crítica. Para evitar grandes males como el bloqueo mutuo – cuando por falta de consenso sobre un tema se detiene el progreso en un proyecto – o la negación – cuando se sigue trabajando a pesar del desacuerdo, esperando a que "todo se resuelva sobre la marcha" – los equipos de proyectos exitosos encuentran formas de abordar las expectativas de diversos stakeholders a pesar de estas diferencias.

Resumiendo, debemos usar el manifiesto de las metodologías ágiles que dictan: colaboración con el cliente sobre la negociación del contrato. Aunque esto no significa que regalemos nuestro trabajo, sí quiere decir que debemos tener una comunicación clara y constante. A veces nos "lanzarán tirabuzones", pero como le digo a mi gente: "si el usuario se te pone muy loco por correo, primero echémosle un telefonazo para calmarlo, dándole a entender que tenemos todo bajo control; en cuanto hayamos acordado que el tema ya está resuelto o que deberemos realizar algunas tareas adicionales, enviamos el correspondiente correíto con copia a todo el mundo notificando en qué quedamos". De esta manera el cliente sabe que si algo se presenta y es de nuestro lado, lo estaremos revisando; de igual manera si es de su lado, queda el precedente que nosotros no tenemos "la bolita".

Así entonces, la principal labor del Project Manager y del Architect o Team Leader se vuelven menos para "gestionar metodologías, recursos y presupuestos" y se enfocan más en fungir como intermediarios entre las diferentes áreas que son afectadas por nuestras soluciones así como con el resto del equipo de trabajo. Por ello existen equipos que son toda una piola para cerrar proyectos complicados: entre el administrador y el arquitecto traducen las necesidades de un usuario no técnico a requerimientos específicos, ayudándolo en aterrizar ideas y convertirlas en tiempos, costos y entregables tangibles.

Y bueno, ¿Cómo figura nuestro proyecto en todo esto? La falta de comunicación ha sido entre el equipo y los jefes, no entre el equipo y el cliente. Tanto el usuario técnico como el de negocios tienen interacción constante con nosotros y aunque ocasionalmente nos tiran buscapiés, en términos generales hemos salido bien librados. Cuando hay que decir no, tratamos de hacerlo lo más polite posible y debido a la relación, el cliente estuvo dispuesto a pagar dos semanas de sobretiempo que no fueron culpa nuestra – claro que él tampoco no es un pan de Dios y ya se lo está cobrando al otro proveedor. ¿En qué acabará todo esto? Así como lo veo yo, el único riesgo que tiene nuestro desarrollo es el account manager-programador-arquitecto-investigador, que en vez de estar sobre nosotros debería estar sobre el cliente. Si algo aprendí de la aeronáutica es que frecuentemente, si quieres despegar, tienes que deshacerte del peso muerto.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: