La mentalidad “hamburguesa cocinada, hamburguesa vendida”

 
El desarrollo de software es una actividad muy diferente a la producción. Sin embargo, los Directores de Proyectos de software a menudo aplican una filosofía de gestión derivada completamente de los entornos de producción de la era industrial.

Imagine por un momento que usted es el gerente de una franquicia local de comida rápida. Para usted, tendría mucho sentido tomar cualquiera de las siguientes medidas para aumentar la eficacia en la producción:

• Reducción de la tasa de error: Hacer que la máquina (humana) funcione tan suave como sea posible.
• Dirección autoritaria (presionar, castigar, más horas).
• Tratar a los trabajadores como piezas intercambiables de una máquina.
• Ritmo de producción constante: No pensar en lo que supone la transición operativa para ganar velocidad o el tiempo que supondrá cerrar la operación.
• Estandarizar el proceso: Hacerlo todo según el manual.
• Eliminar la experimentación (para eso pagan a los de servicios centrales).

Estas medidas serían razonables si usted se dedicara al negocio de la comida rápida (o a cualquier otro entorno de producción), pero no es así. Usted es Director de Proyectos. La mentalidad de “hamburguesa cocinada, hamburguesa vendida” puede resultar fatal si se dedica al desarrollo de software, o cualquier otro proyecto relacionado con el “trabajo del conocimiento”. Solo le servirá para quitarle la ilusión a la gente y para alejar su atención de los problemas reales.

Este estilo de gestión es completamente opuesto a la efectividad en el tipo de trabajos que debe desarrollar el “knowledge worker”.

Getting the client happy with everything

Effective Project Managers know very well that stakeholders’ management is the most important project knowledge area. A project only finishes when stakeholders have met or exceeded their expectations. That is: when they are happy with the project result.

Each project has many stakeholders, but one of them especially important to manage: the client, the one who pays for it —we should extend this group of special interest with final users, the ones who are to use the product, service or result. 
  
In many service oriented companies is usual that the person who sold the project tries to centralize communication with the client. Effective Project Managers do their best to manage client expectations by themselves with the least intermediation.

If we don’t get client actively interested in our project during execution, or gets surprised or upset with the final result, then our project will be a great failure. 

One boss of mine used to say: “In projects, client has to be happy with everything but the price.” 

But “Getting client happy with everything” is easier said than done, isn't it?

Los problemas de ayer son los riesgos de hoy

 
Como escribió León Tolstoi: “Todas las familias felices se parecen, pero las infelices lo son cada una a su manera”. En nuestra profesión, yo creo que podríamos decir lo siguiente: “Todos los proyectos felices se parecen, pero el drama que se vive en proyectos que fracasan es muy particular”.

Imagine que está comenzando un nuevo proyecto y alguien le dice: “Este proyecto tuyo se parece mucho al que Pedro acaba de concluir, ¿por qué no le preguntas?”.

Usted está ocupado comenzando la planificación. Le parece que este proyecto se ha vendido muy por debajo de coste y plazo. Está descubriendo que hay muchos interesados contrarios al buen fin del proyecto, el alcance no está bien definido, hay mucha innovación y mucho que perder si el proyecto sale mal.

Decide despejarse un poco e ir a ver a Pedro.

En el Corazón de la Planificación

Cuando se hace un análisis post-mortem de un proyecto que ha fracasado, es decir, ha terminado muy tarde, con mucho sobrecoste, mala calidad, etc., y las desviaciones han llegado a tal punto que tanto el cliente como el proveedor declaran que el proyecto ha sido un auténtico fracaso, llegando a veces al extremo de tener que ir a juicio, muchas veces descubrimos que la causa principal es una mala planificación.

Me refiero a esos proyectos que, por ejemplo, deberían haber terminado en 15 meses y duran más de 20, que acaban con pérdidas netas de cientos de miles de euros, o que en el momento de la entrega, el cliente no acepta y por tanto no paga.

El post anterior Fail to Plan is Plan to Fail explicaba la importancia de una buena planificación para la conclusión exitosa de cualquier proyecto. Este post trata de profundizar sobre qué procesos de planificación son, a mi juicio, los más importantes, porque si se hacen mal es como “planificar el fracaso”.

En otras palabras, ¿qué procesos de planificación son causa raíz directa de fracaso, si se hacen mal?