Mi historia en la gestión de proyectos ... a cocachos aprendí ... (Parte I)

Sólo metodología de desarrollo poca gestión...

En 1996, iniciamos un proyecto de consultoría para la reingeniería de una área en una compañía financiera, con el análisis de los procesos logramos la reducción de tiempos, optimización de las actividades para lograr un área eficiente que permita a la compañía financiera estar preparada para incrementar su producción en los próximos años. Finalmente, este proyecto determinó la necesidad de desarrollar un nuevo software para el área que permita automatizar los procesos optimizados ya implementados.

Por ese entonces, mi experiencia en proyectos de desarrollo era alrededor de 7 años, habiendo participado en 10 proyectos aproximadamente, tanto como programador, analista programador y líder de proyecto. Mis conocimientos de desarrollo se basaban en las metodologías de desarrollo de software, tanto para análisis, diseño, programación, pruebas, gestión, etc.

Para el nuevo software para los procesos optimizados, se preparó un proyecto de desarrollo, donde tenía la responsabilidad del proyecto, era el líder del proyecto, participé en la definición y estimación del proyecto, calculado en 24 meses de duración. Finalmente, iniciamos el proyecto con un equipo estaba conformado inicialmente por 4 personas. Al cabo de 2 meses de proyecto, el analista principal (persona con mayor experiencia en el proyecto) comenta respecto a los resultados de la evaluación económica del proyecto (resultado positivo): "Con el resultado obtenido a la fecha, el proyecto fracasará económicamente...". Este comentario, que lógicamente no me gustó, me hizo pensar: "¿cómo es posible que en dos meses de avance de un proyecto de 24 meses, podamos señalar que el proyecto (en positivo) fracasará, teniendo todo el tiempo por delante para tomar las acciones correctivas necesarias para evitarlo?. Pero, el problema no era el comentario, al margen si era cierto o no, finalmente no sabía como controlarlo, para evitar a que fracasara.

A partir de esa fecha, me enfoqué a las metodologías de análisis, diseño y programación, para que el proyecto no fracasara, también teníamos planes de trabajo, pero no había el seguimiento correcto, tampoco lo entendía en ese momento. El proyecto terminó con los alcances solicitado, pero no en los plazos estimados, ni con los resultados económicos esperados, mi compañero tuvo razón, pero no porque sea un visionario, sino porque no hicimos las gestiones necesarias para evitarlo y corregirlo. Luego de esa experiencia pensamos en, darle énfasis a la supervisión de la aplicación adecuada de las metodologías de desarrollo, insuficiente claro, no lo entendía en ese momento, el tema de gestión era muy gaseoso ...

En los siguientes meses, nos dedicamos a la supervisión de proyectos bajo la metodología de desarrollo definida por la consultora, con planes de trabajo y seguimiento periódico a la metodología, pero algo faltaba...

Escalofriantes números ...

A finales de 1999, realizamos un análisis de los proyectos desarrollados durante el año, incluían aquellos iniciados antes de 1999 y aquellos que terminarán después de 1999. La evaluación debería determinar la variación del esfuerzo real total (horas hombre aplicadas más horas hombre pendientes por aplicar) con respecto al esfuerzo total original de la propuesta de cotización. El resultado fue, el esfuerzo real era un 35% adicional respecto al esfuerzo de la propuesta original, es decir, estábamos trabajando un 35% más del esfuerzo por el cual estamos cobrando. Este adicional que representaba un equivalente a 60 meses de sueldo de una persona promedio en la organización, o la planilla de sueldos de un mes.

Incluso se pensaban que no era 35% sino 50% ..., en realidad el 35% o 50% adicional no solo consideraba la responsabilidad del equipo de trabajo, por no controlar adecuadamente el proyecto, sino también incluía requerimientos adicionales del cliente, o modificaciones a las especificaciones iniciales que por motivos diferentes no eran presupuestados y por tanto, era asumido por el proyecto. ¿Motivos?, falta de control y seguimiento al proyecto, inexperiencia del equipo para identificar los adicionales o modificaciones, "rabo de paja" por los errores cometidos durante el proyecto, que no permite negociar con el cliente, falta de gestión comercial, etc.

Consideraba que con un mayor control y seguimiento al proyecto en lapsos de tiempos mas cortos podría reducirse el esfuerzo adicional, o podría rápida y fácilmente identificarse cualquier requerimiento adicional o modificación bajo la responsabilidad del cliente. El problema era ¿cómo identificar? ...

Un fracaso más, si importa ...

En el año 2000, iniciamos un proyecto cuyo contrato tenía muchas penalidades por incumplimientos de cláusulas, ya cansado de tantos proyectos estresantes por carga de trabajo, plazos sin cumplir, resultados económicos negativos, etc. Me propuse definir un esquema de planificación y control, que me permita identificar las diversas variaciones de esfuerzo y de fechas de las actividades, a lo largo de la ejecución del proyecto. Que, esta identificación de variaciones también me permita identificar al responsable de los mismos, de manera que se tenga claramente identificados las responsabilidades del contrato. Decía: "Este proyecto no fracasará, y menos por mi responsabilidad...".

Tenía los elementos suficientes para el éxito del proyecto, esquema de organización adecuada, buenos recursos, experiencia metodológica en el desarrollo de proyectos, pero faltaba el esquema de control...Es decir, tenía todos los elementos suficientes para sobrevivir en la selva, comida, agua, carpa, abrigo, herramientas, linternas, etc. pero, ¡¡¡no tenía el mapa ni una brújula!!!