Jose María González López
Project manager y Fundador de Habilis Software http://www.habilissoftware.com/
Continúa la serie de artículos que forman el decálogo para hundir proyectos no sin antes referenciar la 5ª parte del mismo:
Torpedo 7. La planificación
"Ningún plan sobrevive al contacto con el enemigo."
Mariscal de campo von Moltke
Nuestro apartado para la planificación es bastante sencillo aunque trate un tema tan amplio. El grado de planificación de un proyecto según PMI (entendiendo por planificación como todas las actividades relacionadas con los planes especificados en el PMBOK 4ª y 5ª edición) debe ajustarse a la naturaleza del mismo, por eso, en función del tipo de proyecto que tengamos entre manos nuestra estrategia deberá cambiar.
Como gestor del proyecto debes conocer cuántas herramientas de planificación y gestión tengas a tu alcance para poder aplicar nuestro mantra: "Conocer e ignorar" y así precipitar el proyecto hacia su fracaso (que es de lo que trata éste decálogo).
Como guía tomaremos las estadísticas que nos dicen que aproximadamente el 80% de los proyectos realizados en España se retrasan más allá de lo aceptable o incluso, fracasan. Esta cifra debe alentarnos puesto que hace más fácil nuestra tarea: hundir un proyecto no es imposible, de hecho, es más que probable y estoy totalmente convencido de que, en la mayor parte de ellos, el secreto radica en todos los pequeños detalles que hemos ido viendo a lo largo de la serie de artículos.
En este punto debemos tomar una decisión. ¿Cómo es nuestro proyecto? ¿Es un proyecto claramente definido desde el principio? ¿Cómo es de estable en cuanto a necesidades? ¿Cuán alto es el nivel de incertidumbre? ¿Tiene un límite razonable de tiempo? Respondiendo a estas preguntas (y a otras más, por supuesto) podremos decidir una estrategia de planificación y gestión. Centrándonos en el mundo de las tecnologías y el desarrollo de software (Dimos por supuesto al inicio de la serie que el decálogo se centraría en ésta especialización), dicha decisión básicamente consiste en decidir si aplicar metodologías ágiles en la gestión o si aplicar marcos como el de PMI o PRINCE2.
Normalmente, y, por supuesto, siempre dependiendo de cómo sea el proyecto, las metodologías ágiles demuestran una mayor flexibilidad y adaptabilidad al ciclo de vida de un proyecto de desarrollo de software. Suelen ser una elección adecuada en proyectos con un alto nivel de incertidumbre, con necesidades inestables, con equipos pequeños o medianos y sin un límite de tiempo estrictamente definido (por ejemplo, proyectos abiertos, con facilidad de ampliación o proyectos de investigación). Si tu proyecto tiene buena estabilidad en sus requisitos, un nivel de incertidumbre controlado o tiene un límite de tiempo estricto es adecuado utilizar, por ejemplo, el marco definido por PMI y reducir la flexibilidad de la gestión para poder maximizar las posibilidades de cumplimiento de los objetivos en el tiempo fijado. No pretendo generar en el lector el eterno debate sobre QUÉ es mejor, sí las técnicas lean (o agiles), PRINCE2, ITIL o el marco PMI. A mí no me gustan los radicalismos. Creo, desde mi humilde opinión, que lo más favorable es no decantarse por una en concreto, si no conocer todas las herramientas, metodologías, modelos, marcos o buenas prácticas posibles y saber cuándo y cómo aplicarlas para maximizar sus ventajas.
Pero recordemos para que estamos aquí. Nuestro propósito, señores y señoras, es hundir profesionalmente un proyecto y para ello la norma es CONOCER E IGNORAR. Ya sabemos que debemos adelantar la estrategia de gestión y planificación a través del análisis de la tipología del proyecto. Es fácil también equivocarse en la elección de la misma y tratar de utilizar una herramienta en un entorno que no favorece su aplicación. Me explico: La aplicación de una norma de planificación pensada para entornos estables en un entorno inestable con un alto nivel de incertidumbre, por ejemplo, puede causar problemas y cuellos de botella en algunos de sus procesos. Igualmente nos ocurrirá si tratamos de aplicar una norma ágil en la que el cliente goza de libertad de acceso al proceso de desarrollo, en la que se permiten correcciones continuadas mediante evolutivos y procesos de retrospección, en la que el tiempo de proyecto puede dilatarse sin problemas en un entorno que, realmente, no lo permite.
Es como usar gasolina sin plomo en un diésel... puede que funcione, si... pero irá como el culo, seguro.
Centrándonos un poco, y teniendo en cuenta la cita del inicio de éste artículo, necesitamos que nuestra planificación NO tenga capacidad de adaptación ni sea flexible, que no anticipe problemas y que no sea capaz de adecuarse a la práctica ni a la evolución de las expectativas del cliente. ¿Qué PMBOK recomienda? Tú acata. No te molestes en averiguar si tu proyecto necesita o no un plan de gestión de las comunicaciones, hazlo directamente (y cuanto más extenso, mejor). ¿Qué no llevas los costos del proyecto? No importa, haz un buen plan de gestión de costos. Ah, ¿que ahora sí que los llevas? Pues vuelve a rehacer el plan de gestión de costos, por si acaso. No hay nada que peor le siente a la planificación de un proyecto que el desorden y es a lo que tienes que tender.
Por último, y sólo por dar una pincelada de color al asunto, no malgastes tu tiempo elaborando planes de configuración del proyecto o documentos que faciliten la tarea de saber en qué se está trabajando. No especifiques como debe organizarse el equipo, ni cómo deben versionarse los documentos ni cómo organizarlos. Hay que dejar que los integrantes del equipo se organicen de manera espontánea, libre y sin normativas que limiten su creatividad a la hora de destruir y su capacidad de equivocación. Sobre todo no elimines la posibilidad de que trabajen con documentación antigua o fuera de versión, de que puedan machacar un documento final con un borrador o de que realicen por si solos una actualización de producto en preproducción (o... producción... aunque eso es sólo para los auténticos campeones del sabotaje...). ¿Canvas?... ¡Por favor! ¿Qué beneficio puede dar el tener post-it con tareas en una pizarra? Pfffff.... Eso sólo trae orden y control... nada útil.
Nota: El autor del presente artículo no se responsabiliza del mal uso de la información aquí recogida ni del hecho científico probado de que, en determinados cerebros, la psicología inversa no funciona...