Rescatar un proyecto

19 septiembre, 2012

“El viaje para rescatar y recuperar un proyecto comienza por reconocer que el proyecto tiene un problema”. Así comienza uno de los libros del género (el de Khotari y Mitchell (2008), pero hay algunos más, el más leído recientemente es el de Todd Williams (2011), aunque ninguno me gusta mucho.

La mayoría de los proyectos fallan, no alcanzan sus resultados en tiempo, alcance o coste, según estadísticas que varían entre los  “Informes del Caos” del Standish Group hasta aproximaciones más ponderadas como las de Gartner o la National Audit Office del Reino Unido. Según Gartner, 8 de cada 10 dólares gastados en proyectos informáticos no sirven para nada. Uffff.

Muchas veces, lo mejor que podemos hacer con un proyecto fallido es matarlo cuanto antes y regresar “sanos y salvos”. Pero a veces vale la pena hacer un esfuerzo extra para intentar rescatarlo, reenfocarlo y recuperarlo.

FUENTE: Wikipedia. Licencia CC

(Entre las dos posiciones, hay alguna gente (clientes, directores de informática o de negocio) que encuentran un camino para limpiar su responsabilidad y recuperar algunos costes recurriendo al diagnóstico forense y la demanda judicial. Hay gente pa tó, pero la realidad es que no hay buenos proveedores ni buenos proyectos si no hay buenos clientes, y que los éxitos y los fracasos suelen ser compartidos.)

Yo creo que si la necesidad de negocio persiste, si las economías (los costes hundidos y los flujos de caja descontados) justifican la espera y si las cosas se manejan bien, vale la pena recuperar el desastre, o intentarlo. Hay firmas y profesionales a los que nos toca hacer esta clase de intervención de bombero (a veces de “bombero torero”, la verdad). Como en los matrimonios, tiendo a creer que es preferible la continuidad que la ruptura y que el sufrimiento es menor (ya sé, no siempre y no para todos).

La literatura científica no ha dedicado mucha atención a este tema, que ha quedado en las manos de lo que escriben o lo que venden los propios practicantes. De mi experiencia, la de algunos colegas y algo de literatura profesional, me atrevo a hacer algunas observaciones que espero que sean útiles:

1) Reconocer el problema, hacerlo cuanto antes y comunicarlo a la dirección: “Houston, tenemos un problema”. Es importante ver el problema como un problema de negocio, no como una dificultad técnica o una alarma administrativa de riesgos gestionada por una oficina proyecto. (Los mayores marrones los he encontrado en proyectos con oficinas reconocidas y bien dotadas.) He recomendado algunas veces el sistema de hitos (milestones) sencillos orientados a objetivos, con responsables y presupuestos asignados ( [1][2]), frente a la parafernalia de documentos y planes basados en actividades y volúmenes de trabajo ejecutados.

2) Comunicar bien con los interesados, mientras nos aclaramos. En el centro del proceso de rescate debería estar la comunicación justa y necesaria, el portavoz adecuado (frecuentemente el espónsor de negocio) y un pacto de tranquilidad y paciencia. Los problemas se hacen mayores bajo las presiones desordenadas de usuarios estresados y descontentos.

3) Diagnosticar e intervenir rápido. La mayoría de los problemas son sencillos y comunes, no requieren largas auditorías, revisiones de código y mayores pruebas. Las causas más habituales de fracaso son una esponsorización pobre y poco activa por parte del cliente, jefes de proyecto inexpertos, responsabilidades indefinidas, alcance y requerimientos difusos, planes optimistas, presupuestos infravalorados, programas demasiado largos y con entregas tardías, tests insuficientes y ninguna gestión de interesados. Todo esto puede saberse pronto y explicarse con sencillez.

4) No parar el proyecto y trabajar con los equipos. Sólo con el proyecto en marcha, puedes ver cosas que los demás no ven. Sólo trabajando con el jefe de proyecto, puedes ver más que él, como en el ajedrez. Sólo preguntando a clientes y usuarios desesperados, puedes realmente entender qué es y qué no es importante para ellos y replantear el proyecto.

5) Presentar y negociar un plan de recuperación, que probablemente será duro. El plan casi siempre incluye recortar o fasear el alcance (¿qué es verdaderamente importante tener ahora y qué puede esperar?), revisar la esponsorización (¿quién es realmente el cliente, qué necesita y que tiene que hacer para que las cosas se arreglen?), reestructurar las responsabilidades internas y del proveedor, cambiar el jefe y la oficina de proyecto (pues sí, alguien tiene que caer) y renegociar las condiciones económicas y de tiempo de manera que todo el mundo pierda un poco, pero no todo. El plan debe incluir un programa de comunicación y gestión de interesados y algunos quick-wins, que ayuden a dar confianza y credibilidad.

6) Acompañar al cliente, al menos al principio. Mi experiencia es que, como los niños o los enfermos convalecientes, lo más complicado son los primeros pasos y ganar nuevas y buenas costumbres. El seguimiento aquí debe ser cercano y es bueno que los «bomberos» se queden un tiempo para apagar los rescoldos y dejar el bosque más limpio y practicable.

En fin, aceptaré de buen grado comentarios y sugerencias de los que tenéis éstas y otras experiencias.

Nota:
La obra que os propongo hoy es El Incendio del Borgo, un enorme fresco pintado por el estudio de Rafael (se atribuye cada vez con más convicción a Giulio Romano, su principal colaborador) alrededor de 1515, y que se conserva en las estancias del Vaticano. Me recuerda unos versos de Auden: «About suffering they were never wrong, / The Old Masters.» Aprovecho para recomendaros la exposición de Rafael en el Museo del Prado, en colaboración con el Louvre.

(Visited 122 times, 1 visits today)
Autor / Autora
José Ramón Rodríguez
Profesor de Dirección de Sistemas de Información, Gestión de Proyectos y Business Intelligence de los Estudios de Informática, Multimedia y Telecomunicación de la UOC y consultor de empresas independiente.
Comentarios
Posicionamiento Natural28 septiembre, 2012 a las 12:12 pm

Totalmente de acuerdo !

Unos pasos que todo el mundo debería seguir !

Responder
Alejandro Tunaroza18 octubre, 2012 a las 4:48 pm

Primero agradecer por este excelente articulo.

Encuentro que las observaciones que mencionas están muy alineadas con los valores y principios del Agile Manifesto. Es acá donde me entras algunas dudas sobre la relación que se tiene entre la Gestión Clásica de Proyectos (Basada en PMI) y el uso de la filosofía Agile en el desarrollo de proyectos. ¿Son estas dos metodologías contradictorias, complementarias o diferentes? ¿Y cuál es más efectiva o adecuada?. En mi caso personal considero que son completamente contradictorias y que la más adecuada (por lo menos en mi experiencia diaria) es la relacionada al desarrollo Ágile, pero me gustaría saber tu opinión.

Espero haber sido claro.
Muchas Gracias

Responder
Jose Ramón19 octubre, 2012 a las 4:21 pm

Hola Alejandro. Perdona la tardanza, no había visto tu mail, muy inteligente,
Ufffff, me pones en un compromiso! Puedes ver mis entradas sobre Agile i PMI en este mismo blog.
La evidencia empírica no es concluyente ahora mismo. Y probablemente estamos hablando de cosas diferentes y que no se pueden comparar. Agile nace para la producción de software a medida y probablemente empieza a proporcionar resultados superiores a l desarrollo en cascada (SDLC).
PMBOK cubre el ciclo completo de gestión de cualquier clase de proyectos y yo lo veo como una ‘caja de herramientas’ que el jefe de proyecto experimentado usara según cada necesidad y no como un catecismo.
PMBOK es un estándar de facto, sobre todo en las Américas, y es lo que hay.
El propio PMI ha adoptado en sus estándares de gestión de proyectos de desarrollo de software los principios y algo mas de Agile.
En la UOC intentamos ser bastante prácticos y enseñamos las 2 cosas…

Responder
Deja un comentario