- Lo lees en 7 min
- Archivado en Gestión de Proyectos
- Escrito por Cesáreo hace 12 años y 1 meses (27 Sep 2011 14:50)
Al hilo de una cena con amigos el otro día sobre la metodología de planificación de proyectos que plantea el PMI (Project Management Institute) hablábamos sobre la burocracia en la gestión de proyectos. La burocracia es algo con lo que convivimos, sea cual sea, nuestro trabajo, y en estos tiempos de crisis no vendría mal recortarla un poco.
La metodología del PMI está descrita en el PMBOK. Este libro (bastante grande) es muy completo y contiene todo el material de estudio para presentarse a los examenes de certificación que el PMI ofrece. Yo he coincidido en varias charlas con representantes del PMI (en Colombia) y mi postura sobre esto ha sido siempre la misma:
- El PMBOK contiene toda la base de conocimiento pero ...
- ...no sirve para la mayoría de los proyectos
Y no sirve porque, al querer abarcar toda la casuística en la gestión de proyectos, es una metodología tan completa, que se come el proyecto. Aunque las certificaciones PMI son reconocidas en el ámbito profesional (básicamente te permiten cobrar más) pueden generar directores de proyectos peores, no mejores. Ojo que no digo que el PMI y su PMBOK no sirvan (de hecho son la mejor referencia descriptiva y es importante conocerlo) sino que tiene que adaptarse a la realidad del proyecto.
Mi aproximación a la gestión y seguimiento de proyectos es mucho más sencilla por las características de mi trabajo.
Mi problema con las metodologías es cuando se convierten en el fin, no en la herramienta para cumplir los objetivos del proyecto (que termine en presupuesto, plazo y según el alcance contratado). O cuando no se evalúa y se adapta la metodología a la realidad concreta de los proyectos (tan cambiantes). Mi problema es cuando las metodologías se convierten en el proyecto, y los objetivos originales del proyecto desaparecen. Esto se puede aplicar también a las supuestas certificaciones de calidad (iso, efqm, etc). En realidad son oportunidades de mejora para las organizaciones y para las personas, pero pueden aprovecharse o no. Obviamente, no es un problema de la metodologia sino de las personas (y como la usan).
Para explicar este concepto (y de la burocracia en general), en mis charlas de gestión de proyectos lo cuento con la historia de este árbol (en la foto). Este árbol es un ficus estrangulador del parque Amboró (Bolivia). Cuento que este árbol:
- Es parásito. Es decir, comienza pegándose al árbol original como una cuerda tensa y ajustada y lo va abrazando poco a poco. Así como todos esos papeles innecesarios (plantillas, protocolos, formularios ...) que van apareciendo en la gestión del proyecto.
- Crece tanto, que... se convierte en el árbol, es decir, el árbol original desaparece y lo que eran tallitos parásitos, forman el nuevo árbol. El abrazo es mortal y elimina el árbol original.
Lo más curioso del ficus estrangulador es que con el paso del tiempo aparece como un árbol normal. De hecho, en el de la foto entro yo con mis brazos abiertos, dentro del hueco. La verdad es que es impresionante y digno de ver. Como en la gestión de proyectos, la burocracia y la metodología se convierten en el fin, no en la herramienta. Y muchas veces dedicamos recursos a lo que no es y terminamos empantanados con una burocracia inservible y los proyectos sin terminar.
En fin, que la recomendación en el día a día es sencilla, ¿qué aporta este formulario al proyecto? ¿este proceso? ¿este dato? Una dinámica de evaluación continua (el famoso ciclo PDCA) es el que favorece distinguir lo importante de lo irrelevante. Un dato importante en los proyectos es medir el coste de la planificación y seguimiento del proyecto (en mi opinión no debe superar el 10% del total)
Sino, ocurre que terminamos pagando por mara (caoba) y obtenemos un ficus estrangulador. Muy bonito, pero no es lo mismo.
Blog 1 de 1.000
Sección » Gestión de Proyectos
|
Software en Gestión de Proyectos
Para planificar [1] o hacer seguimiento [2] a un proyecto en realidad
no hace falta software. La clave es la persona porque el software *es
simplemente una herramienta*.
La necesidad del software *surge de la ingeniería civil e industrial...
|