Estoy adminsitrando un proyecto tratando de apegarme al estándar del PMI. En este proyecto hay fechas fijas y no negociables: no podemos ir mas allá de la fecha definida.
Empecé dividiendo en fases el proyecto y arranqué con la fase de Inicio. Después de un kickoff apresurado, empalmado entre fases pero exitoso, continué con la fase de Planeación. Fuí exhaustivo en el seguimiento a los procesos de planeación que dicta el PMI. Llegó el momento de entrar en detalles técnicos y, como es mi costumbre, involucré a aquellos especialistas que pudieran ahondar en los "tecnicismos". Hasta entonces teníamos claro el objetivo del proyecto y las actividades (a alto nivel) necesarias para generar los entregables. Hasta hicimos un documento de análisis que se suponía nos ayudaría a prever cualquier problema en potencia. Yo insistí en llegar a un siguiente nivel de detalle en el análisis técnico dado que es un proyecto muy importante, pero no insistí. Finalmente confié en que el personal tecnico tenía todo bajo control y dada la prisa dado que las fechas se estaban cumpliendo, acepté poca profundidad en el detalle y acepté arrancar con un "si terminamos para esa fecha" y sin un cronograma detallado de esas actividades específicas.
La planeación de lo demás iba muy bien, llegamos a profundidades casi inecesarias y esto justificó en mi mente la falta de profundidad del análisis técnico.
La "venta" se hizo y se comprometieron fechas. En la ejecución todo empezó bien. Yo hice monitioreo de avances pero no en una base de entregables y dado que no teníamos un nivel de detalle aceptable ni fechas ligadas a entregables, me limité a preguntar "¿si terminamos para esa fecha?" a lo que siempre recibí un "si".
Finalmente 3 días inhábiles antes de la entrega la gente técnica descubre algunas actividades que eran necesarias y que llevarían alrededor de 2 días de trabajo.
Finalmente tuvimos que trabajar esos 2 días y los entregables se terminaron a un 97%.
El punto aquí es que no cumplimos con el 100% ni lo hicimos en horarios hábiles sino que sacrificamos tiempos de descanso por cumplir con la fecha establecida.
La administración exitosa de un proyecto no es entregar cuando dije que entregaría, sino que debemos cuidar del desgaste al equipo. Desde esta perspectiva y muchas otras que habrás identificado, el proyecto no fue excelentemente administrado. ¿Qué aprendí?
Lección 1: Empalmamos fases de planeación entre planeación de la administración del proyecto y la fase de planeación o análisis del proyecto. Es decir, la fase de ejecución de la administración del proyecto debe incluir toda la metodología de desarrollo: análisis, diseño, construcción, pruebas, liberación. En esta metodología, el análisis y diseño son las fases de planeación, pero caen dentro de la fase de ejecución del plan de administración de proyectos.
En otras palabras, la planeación de la administración del proyecto fué exhaustiva, pero la planeación técnica fué deficiente.
Lección 2: También es posible que se empalmen las metodologías y que la fase de planeación tecnica tenga parte dentro de la planeación de la administración del proyecto, pero ambas deberán ser exhaustivas. Lo completo de una no reemplaza el ejercicio de completar la otra.
Lección 3: Nunca la prisa reemplaza la necesidad de la planeación, la creación de un cronograma ni la definición de entregables.
Lección 4: La mala planeación desgasta al equipo.
¿Encuentras más lecciones en este caso?
2 comentarios:
Que tal a todos, tengo una moderada experiencia en la administración de proyectos de software. A los demas lectores, les comento que recientemente estoy empezando a utilizar los lineamientos del PMI para la AP, por lo puede no concordar mi opinión con los best practices del PMI. Las lecciones que puedo ver o más bien opciones de solución en la experiencia de Fer son las siguientes:
* La fase de análisis de software ha evolucionado para incluir mucho de diseño, mediante la utilización de casos de uso, prototipos, mapas de flujo de información, etc. Considero que la utilización de esas herramientas pudieron haber dado un sentido más exacto de qué actividades se tendrían que realizar, y el esfuerzo necesario para efectuarlas.
En mi caso estoy ubicando el análisis detallado antes de la ejecución (vista como fase posterior a la planeación, aunque sabemos que se sobreponen), dado que de su realización a detalle dependen los 21 procesos de planeación.
* Finalmente, algo que me ha funcionado muy bien es el reporte diario de avance individual, en el que todos los recursos participando en el proyecto reportan:
1) Tareas realizadas con tiempo invertido y tiempo pendiente. Solo es necesario que indiquen el Id de project, y número de horas de cada tipo.
2) Entregables concluidos.
3) Problemas encontrados y cómo se resolvieron (o si no se han resuelto).
4) Lecciones APrendidas.
Como PM me corresponde:
- Actualizar el project con las actividades realizadas.
- Revisar aleatoriamente actividades realizadas el día anterior (esto lo notifiqué previamente a los muchachos, buscando no generar ansiedad en ellos).
- Verificar preferiblemente todos los entregables mayores en persona. La documentación de desarrollo puede ser revisada periódicamente para validar pertinencia en los procesos actuales y su correcto uso.
- Verificar que los problemas hayan sido resueltos o apoyarlos en sus resolución.
- Ingresar problemas y lecciones aprendidas a documento de Lecciones Aprendidas.
Este approach ha ayudado en varias cosas:
- Me da una visibilidad casi en tiempo real del avance de los muchachos, sin la necesidad de un Project Server (con las obvias limitantes de comodidad para un servidor).
- Me da un sense de lo que pasa en "las trincheras", y la posibilidad de intervenir si es necesario.
- Les da un sentido de importancia a los desarrolladores, sabiendo que su trabajo está siendo monitoreado (y motivado) diariamente por el PM, siempre procurando verificar a todos por igual, para evitar malentendidos.
- El documento de Lecciones APrendidas va creciendo conforme avanza el proyecto, y todos podemos acceder al mismo para consulta.
Espero que estos tips puedan ser de provecho para los que lean este blog y por supuesto que aprecio sus opiniones al respecto. Les escribo próximamente.
¡Saludos Fer, muy buen blog!
Completamente de acuerdo contigo Rafa, las metodologías actuales ofrecen varias opciones de asegurar un análisis completo y casi bullet-proof.
También de acuerdo contigo en el hecho de que la planeación del alcance se realice en la fase de planeación del proyecto (así lo manda el PMI en los procesos del área de conocimiento de Alcance en el proceso 5.2.- Scope definition).
De hecho y muy de la mano con tu aportación, creo que la lección 3 en la que comento que nada debe reemplazar la creación de un cronograma es la parte central del problema.
Tu esquema de revisión de avances es muy bueno (creo que lo voy a adoptar). Soy muy del tipo "suelto" y no tengo un ojo sobre la gente, pero no hay que llegar a extremos. Me parece buen esquema sobre todo si se realiza periodicamente.
A propósito de eso, tengo un formato que conseguí (con permisos del autor: Anthony Chan) y que voy a compartir con Ustedes en una nueva sección del blog... ¡estén pendientes!
Anyway, muchas gracias por los consejos y seguimos en esta línea.
¡Saludos!
Publicar un comentario