Siete pasos para recuperar un proyecto encaminado al fracaso

Voy a cerrar el año con este artículo en el que J. Frank Carr nos propone en su blog "Visual Basic notebook for .net": 7 pasos para recuperar un proyecto encaminado al fracaso. 

1. Deje de trabajar y tire a la basura el plan de trabajo actual. 

La primera recomendación de Frank es: detengamos el trabajo. Si cuando surgen problemas el trabajo continúa, es probable que se caiga en una espiral mortal. 

Se fuerza al equipo a trabajar horas extra, provocando estrés, o se aplican otras técnicas igual de malas como aumentar el equipo con nuevos consultores o programadores, o empezar a usar una nueva herramienta con la esperanza que ella nos saque del problema. 

Pero Frank hace una afirmación que aunque parece obvia, es difícil de asimilar: Si las cosas ya empezaron a ir mal, seguir el mismo curso solo las va a empeorar. 

Y manipular el cronograma es otro movimiento políticamente riesgoso, nos dice Frank. Seguramente habrá muchos recursos invertidos en el proyecto (dinero y esfuerzo del equipo de trabajo), por lo que la recomendación es asegurarse de que todo el mundo entienda que el plan de trabajo actual tiene un problema que lo hace defectuoso y poco realista, que genera falsas expectativas a la alta gerencia y los usuarios, y desmoraliza a los desarrolladores. 

Hay que destacar que el objetivo del proceso de recuperación es un nuevo plan que realmente refleje las necesidades del proyecto. Como atinadamente señala Frank, se necesita poco de coraje político para hacer esto, por que en algunas organizaciones estará mal visto que el Adminsitrador de Proyecto detenga el trabajo y advierta sobre el desastre inminente. 

Para vender el cambio en forma políticamente aceptable, Frank recomienda enfatizar los aspectos positivos: que se va salvar el proyecto mientras que continuar en el rumbo actual lo llevará al fracaso, que se va ahorrar dinero, etc. 

2. Revise y evalúe todo 

Enseguida Frank nos sugiere regresar a los requerimientos y diseño de la solución originales y determinar si pueden encontrar allí las fallas. 

Tal vez los requisitos son castillos en el aire y deben ser reducidos a algo más realista que pueda cumplirse en el tiempo establecido. Tal vez el diseño sea demasiado ambicioso y necesite ser reducido o resuelto gradualmente a través de varias iteraciones. Frank sugiere tomarse tiempo para revisar cada característica y su importancia para el proyecto, clasificándolas luego como 'obligatorias', negociable, "opcionales", o "pueden esperar". Y no hay que permitir que la alta gerencia diga que todo es prioritario. 

La sugerencia es revisar todo el proyecto para determinar si se están usando las herramientas adecuadas, e identificar las áreas con problemas de modo que se puedan hacer correcciones. 

3. ¿Es viable el proyecto? 

Cuando se ha revisado todo y se identificaron las causas de los problemas, es el momento de decidir si el trabajo debe continuar o no. Este es el momento de la verdad. Si los problemas que se han identificado en el paso anterior indican que no hay forma de que el proyecto termine 'tal cual', entonces debe ser cancelado. 

Por ejemplo, si la reevaluación indica que se necesitará un año para completar el proyecto con una plantilla de 5 programadores, pero el presupuesto sólo permite 2 personas y el calendario es de 3 meses, debe ser obvio para todos que no se va a terminar. 

Puede ser factible recuperar una parte del proyecto y hacerlo dentro de la línea de tiempo necesaria para no desechar todo el proyecto, sino buscar cosas que pueden ser recuperados y reutilizados para un proyecto razonablemente más reducido. 

4. Negociar 

Ahora es el momento de negociar con los patrocinadores del proyecto los cambios en el cronograma y las especificaciones. Esto puede ser difícil en situaciones de fuerte carga política,pero, si el proyecto se va a recuperar, es un paso necesario. 

En primer lugar Frank sugiere examinar y revisar las especificaciones y requisitos con los patrocinadores. Si los defectos se encuentran en esta parte del proyecto, trabajar en la negociación de estos primeros. A continuación, hay que decir lo que puede y no puede hacer, lo que no puede esperar y lo que deben esperar, y así sucesivamente. Habrá un poco de desacuerdo, pero el objetivo es reunir un conjunto realista de características aceptadas por todo el mundo. 

Por último, negociar el crongorama. Y aquí Frank es enfático: no se comprometa con nada. Explique que tendrá que trabajar con el equipo de desarrollo para elaborar un programa realista basado en el conjunto de características negociada. Usted puede dar una estimación gruesa, pero si compromete una fecha determinada es muy posible que se esté preparando para un segundo fracaso. 

5. Priorizar y estimar las tareas pendientes 

Ahora que se tiene lo que debe ser un conjunto de características realistas hay que presentarlas al equipo de desarrollo y hacer que se preparen las estimaciones para cada una de estas características. La sugerencia en este caso es mantener la granularidad pequeña para dividir las tareas en unidades de no más de un día o dos. 

También asegúrese de que usted incluye en las estimaciones el tiempo requerido para atar los cabos sueltos y que elimina las características que dejarán para una versión posterior. Por último, asegúrese de no escatimar ninguna prueba o documentación necesaria. 

6. Construir un nuevo crongorama realista.

Ahora que todas las tareas se han identificado, se puede crear un cronograma realista y preciso. Una vez que este nuevo plan está listo, debe presentarlo a los patrocinadores del proyecto. Si no se obtiene la aprobación, hay que regresar al paso 4, negociar. 

El objetivo es construir un crongorama preciso aceptado por todos y que permita lograr el resultado deseado. 

7. Vuelva trabajar. 

Con el proyecto está de vuelta en el camino, es momento de empezar a trabajar de nuevo. Asegúrese de no repetir los errores del pasado. Tenga cuidado con los malos hábitos que se arrastran de nuevo. Mantenga un ojo vigilante en los problemas recurrentes existentes o los nuevos que puedan surgir. Recuerde que los problemas suelen ocurrir muy lentamente y poco a poco, así que no debe permitir que crezcan al ignorarlos.  

...

Con este post cierro las publicaciones de 2013. Nuevamente agradezco a todas las personas que amablemente hicieron el esfuerzo de leerme en el blog, en twitter y en todas las oportunidades que tuve de expresarme a lo largo del año. Mis mejores deseos en las fiestas y un año nuevo exitoso para todos.