Tras la lectura del PMBOK y sus 47 procesos, de los que 24 están enmarcados en el grupo de procesos de planificación, el lector interpreta que el plan de proyecto o plan de dirección del proyecto y resto de documentación a generar para un proyecto debe ser inmensa. ¿Es esto siempre así? ¿Qué dice exactamente PMBOK al respecto?
Es cierto que tras la lectura del PMBOK da la sensación de que el gestor de proyecto debe generar extensos y detallados documentos, entre otros por supuesto el plan de dirección de proyecto cargado de planes subsidarios, donde todo quede perfectamente descrito al milímetro. Sin embargo, por otro lado el PMBOK exige, como no podía ser de otro modo, que dicha documentación refleje la realidad en cada momento y por tanto sea actualizada por el gestor del proyecto cada vez que un cambio suceda. Sea cual sea el tamaño y repercusión del cambio, todo el plan debe quedar actualizado de inmediato, una vez que el mismo ha sido aprobado.
Esto es comprensible y asumible si pensamos en grandes proyectos de gran criticidad para los interesados implicados en el mismo.
Pero,… habitualmente la mayor parte de los gestores de proyectos nos enfrentamos a proyectos de tamaño medio, donde los cambios son constantes y para más dificultad, nuestro tiempo a dedicarle a la actualización de la documentación generada es reducido. ¿Qué hacemos entonces? ¿No aplicamos PMBOK?
Pues no, no es eso lo que dice el PMBOK. Hay que tener claro que PMBOK no es un método, sino que es un enfoque metodológico y por lo tanto es generalista y va al máximo (tiene que servir para cualquier tipo de proyecto). Cuando un gestor de proyectos aplica el PMBOK, debe adaptarlo a su contexto real: factores ambientales y proyecto concreto. Por lo tanto si nuestro proyecto está sujeto a muchos cambios, o si el tiempo que puedo dedicar al proyecto es limitado puesto que estoy en muchos más a la vez o si, como es habitual, suceden ambas cosas a la vez, adaptaré el PMBOK a mi realidad y generaré documentación seguramente algo menos densa, sin llegar a tanto detalle.
Está claro que si planifico y documento al detalle, controlaré mejor todo, pero el mantenimiento de dicho plan será inmanejable… y es peor tener documentación desactualizada que no tenerla!
Como decía, en proyectos con muy pocos cambios (yo no los conozco), documentar extensamente puede tener sentido, pero en proyectos altamente cambiantes (por desgracia cada vez más habitual) hacer un plan detallado nos aboca a un esfuerzo inmenso cada vez que un cambio aprobado nos hace re-planfiicar o, lo que es peor, nos lleva a tener nuestra documentación desactualizada.
A modo de conclusión, mi recomendación sería que debemos documentar nuestros proyectos al nivel máximo que sea razonablemente mantenible.
Y para dar un poco más de peso a esta recomendación, citaré a Albert Einstein cuando decía: “Haz las cosas lo más simple posible, pero no más simple”. Vamos, que documentemos lo mínimo razonable, pero tampoco no nos pasemos, como hicieron los autores de estos ejercicios:
¿Qué opinión os merece? ¿Consideráis que la planificación debe ser muy voluminosa o muy escueta?… ¿o depende?
En mi experiencia, considero que un buen Plan de Proyecto debe contener lo siguiente:
1. Definición del alcance y del organigrama. Una correcta formulación del alcance y un bien organizado WBS y OBS.
2. Diagramación lógica usando MS Visio (Que evita errores de lógica).
3. Diagrama de redes en primavera o MS Project (Gantt), sin duraciones solo predecesores.
4. Identificar soporte (Logística de materiales y equipos) y procesos (las tareas) usan metodologías diferentes (Lean construcción).
5. Análisis de restricciones para identificar procesos y soporte. (Aquí termina la planificación y comienza la programación).
6. Análisis de precios unitarios de las tareas empleando cómputos métricos y rendimientos. Ahora si se podrá calcular la duración de las tareas.
7. Presupuesto del proyecto. Con este apartado termina el Plan de Proyecto.
Lo anterior puede aplicar a cualquier tipo de proyecto de TI; en el caso que sea uno de construcción de infraestructura, debemos saltarnos el paso 2 aplicando en su lugar la secuencia del grupo de procesos de Gestión del alcance de acuerdo con nuestra experiencia y de ahí ajustarnos en el paso 3 en adelante.
Saludos, espero poder haber contribuido.
Muchas gracias por tu aportación Alejandro. Me parece muy interesante!
¿Alguien más se anima a explicar cómo simplificar la gestión en proyectos concretos?
Saludos,
Carlos
Sin duda un proyecto es muy complejo mas que hacer cuadros y cálculos, por mi experiencia en proyectos de mas de mil millones de dolares te puedo resumir que el 80% de exito radica no en el plan sino en las personas que estan a tras, en tus diagramas y flujos nadie te dice que tu Gerente esta bien capacitado o tus jefes encargados no se iran a mitad del proyecto o simplemente que tus analistas estaran pendientes de cualquier factor negativo que retrase el proyecto. Sin duda todos los calculos se asume que la gente detras del pryecto tiene las mismas cualidades y habilidades y en mi experiencia eso es un grave error.
Saludos,