Hábitos para jugar bien como Director de Proyectos

 
Con buenos hábitos, cualquier Director de Proyectos puede acabar siendo un Director de Proyectos Eficaz, pero no encontraremos ningún libro que nos explique la secuencia a seguir para llegar a serlo. Los proyectos son sistemas naturales, no artificiales, nadie puede garantizar el éxito regular. Cuando analizamos qué distingue a un Director de Proyectos Eficaz, la respuesta siempre es la misma: tienen buenos hábitos, centrados en principios. Recordemos la idea principal de este blog:

El éxito en los proyectos se consigue con buenos hábitos

¿Podríamos evaluar a los Directores de Proyectos sobre la base de sus hábitos? Absolutamente. Podríamos estructurar un sistema de hábitos necesarios para la efectividad en la gestión de proyectos (ya sea un esquema de 7 hábitos a partir de los hábitos de Covey, o cualquier otro esquema particular) y utilizarlo para reclutar a nuevos Directores de Proyecto, como veíamos en el post titulado Entrevista para contratar a un Director de Proyectos, o bien evaluar su desempeño sobre un marco de competencias factible como veíamos en el post titulado Evaluando a Directores de Proyecto.

En otros dos posts, comentábamos lo que significa jugar bien el rol del Director de proyectos: parte 1, y parte 2. Veamos ahora qué hábitos hay detrás de esas reglas del juego.

The tale of the tailor, the princess and the continuous improvement plan

Most organizations use mangement by objectives (MBO), key performance indicators (KPI), balance scorecards, continuous improvement programs, etc. All these tools are useful provided they are founded by good paradigms (i.e. based on principles). Every company has to find its balance between P (Production) and PC (Production Capacity). Production capacity includes research, learning, innovation, process improvement, dealing with customers, etc. Production has to do with sales, billing, value creation for investors, etc. If metrics are not based on principles, we could be very efficient measuring and improving everything, but... what if we are climbing the ladder of success only to discover it's leaning against the wrong wall?

What follows is an illustrative text on how metrics and continous improvement plans may lead to a false feeling of good performance. This is an excerpt of the book Slack. Getting past burnout, busywork, and the myth of total efficiency, by Tom DeMarco. It starts with a tailor who lost a needle in a haystack. For some reason, it was important to him to find that needle and worked hard into it, but he was not succeeding at all. This tailor had read many books and tales. When he was up to giving it up, a young princess showed up and then he remembered: A real princess would have the sensitivity to feel a pea through 20 mattresses. She should help him in finding out his needle, for sure! What started as a productive collaboration towards a simple and definite goal, ended up with certain changes along the way. Both of them planned a new of working to be more efficient under a continous improvement plan. However, this kind of plans sometimes tend to maximize the wrong goal and result counterproductive to organizations (and people).

La historia del sastre, la princesa y el plan de mejora continua

Las empresas tienen gestión por objetivos, indicadores clave de rendimiento, cuadros de mando, planes de mejora continua, etc. Todas estas herramientas están muy bien, siempre que se apoyen en paradigmas basados en principios. Una empresa debe buscar el equilibrio entre su capacidad de producción (investigación, innovación y aprendizaje, desarrollo profesional, mejora de procesos, gestión de las relaciones con los clientes, etc.) y la producción (venta de productos y servicios, facturación, generación de valor para el accionista). Si los indicadores no se basan en principios, podemos ser muy eficientes midiendo y mejorando, pero nuestra escalera hacia el éxito no se apoyará en la pared adecuada.

A continuación pueden leer un texto muy ilustrativo sobre cómo los indicadores y los planes de mejora continua nos pueden dar una falsa sensación de progreso. El texto está extraído del libro Slack. Getting past burnout, busywork, and the myth of total efficiency, de Tom DeMarco. Cuenta la historia de un sastre que perdió una aguja en un pajar. Por alguna razón era importante para él encontrar aquella aguja y trabajó concienzudamente para encontrarla, sin éxito. Este sastre tenía una gran pasión por la lectura y en especial por los cuentos. Cuando comenzó a darse cuenta de lo difícil que resultaba encontrar una aguja en un pajar, a punto ya de rendirse, vio pasar a una princesa y recordó que las princesas saben si han dormido en una cama con un guisante bajo veinte colchones. ¿No podría ayudarle esta bella princesa a descubrir su aguja perdida entre el heno? Lo que empezó siendo una colaboración con un objetivo claro, acabó diluyéndose un poco y el objetivo sufrió algunos cambios. Ambos trabajaron con mucha eficiencia sobre un plan de mejora continua. Sin embargo, estos planes a veces tienden a maximizar el objetivo equivocado y resultan contraproducentes para las empresas (y también para las personas)...

Yesterday’s Problems are Today’s Risks

Leon Tolstoi wrote: “Happy families are all alike; every unhappy family is unhappy in its own way”. Likewise, we could say that happy projects are all alike, but the drama we live in every failed project is so particular.

Imagine you are starting a new project and somebody tells you: This project is very similar to that just concluded by Peter, why don’t not you ask him?

You are busy preparing the kickoff meeting. You think this project has been poorly sold and will take longer. You are discovering there are many stakeholders opposing the project, scope is not well delimited, there is much innovation and much to lose if the project goes wrong.

You decide to refresh a bit and go to see Peter.

Quiero ejecutar un proyecto ágil

Cambiar hacia métodos ágiles los procesos de desarrollo software de una gran organización es posible, deseable, motivador, rentable, sostenible, etc. En mi opinión, los métodos ágiles no son una moda pasajera sino que han venido para quedarse y constituyen la única alternativa realista a la crisis del software. Estos métodos son muy estables: han variado poco y son globalmente reconocidos desde que se publicó el manifiesto ágil en 2001. La prueba definitiva de lo estables que son estos métodos la obtenemos cuando buscamos información en Internet y encontramos material divulgativo de extraordinaria calidad. Más adelante comentaremos el vídeo de hace 2 años que da título a este post: I want to run an agile project. Hay otros muchos vídeos muy buenos: Visiten este enlace para tener una introducción muy completa de Scrum. ¿Quieren saber qué se supone que debe hacer un Product Owner? Solo tienen que visitar este enlace y ya lo saben todo. ¿Quieren ver cómo hay que hacer un daily standup? Pinchen aquí.

Si una determinada organización se decide por el método ágil más popular, Scrum, mucha gente dentro de la organización ya sabrá en qué consiste, quién debe hacer qué y y por qué, y qué podría ir mal. Todos saben de los peligros de los “scrum-buts” (esto es, usar Scrum parcialmente ignorando los beneficios posibles de usarlo todo), y reconocen la conveniencia de empezar siendo puristas en una adopción inicial, hasta alcanzar la madurez suficiente en gestión de proyectos adaptativos para adaptar entonces los procedimientos a la organización.

Entonces, si adoptar los métodos ágiles es tan fácil, hay tanto conocimiento y tanto consenso, ¿por qué será tan infrecuente que se adopten de forma eficaz en las grandes organizaciones?

Mis 10 consejos para aprobar el examen PMP®

La acreditación Project Management Professional (PMP®) del Project Management Institute (PMI®) está experimentando un creciente interés en España. Las cifras hablan por sí solas. En diciembre de 2012:

• El número de socios españoles de PMI era de más de 3.500 (lo que supone un incremento del 40% en 2012). 
• El número de PMP españoles era de unos 3.900 (lo que supone un incremento del 37% en 2012). A finales de abril de 2013, España ya cuenta con 4.194 PMPs, superando a Francia (3.603) y a Italia (4.158), aunque todavía vamos por detrás de Reino Unido (6.313) y Alemania (9.759).

Nuestras cifras de crecimiento en 2012 contrastan con el crecimiento a nivel global, que terminó el año 2012 con estos resultados:

• Número de socios de PMI en todo el mundo: unos 400.000 (+7% en 2012).
• Número de PMP en todo el mundo: 510.000 (+9% en 2012).

Es decir, en nuestro país, el número de afiliados a PMI creció casi 6 veces más que en el resto del mundo, y el crecimiento en número de PMPs cuadruplicó el crecimiento medio. Especialmente, los datos de PMPs son más significativos por la situación actual de crisis que atravesamos. Hay que tener en cuenta que los cursos para preparar el examen PMP son caros y aunque uno se decida por la preparación autodidacta, hay unos costes fijos mínimos que pagar a PMI para seguir el proceso de certificación:

Por otra parte, podemos decir que el examen PMP es un ejemplo de proceso bajo control. PMI aplica unos estándares de calidad muy elevados para garantizar que el examen sostiene la acreditación mundialmente reconocida y actualizada. El proceso del examen está certificado ISO 17024 desde 2007. Desde un punto de vista práctico, si el candidato no se ha preparado muy bien, la probabilidad de suspender el examen se mantiene muy elevada. PMI no publica estadísticas sobre la tasa media de suspensos en el examen PMP, pero por lo que se comenta en los foros de PMI, mi estimación es que al menos 1 de cada 3 personas suspenden. Con estas hipótesis, según mis cálculos, más de un millón de euros fueron invertidos sin éxito por colegas españoles en 2012, porque se presentaron al examen y suspendieron.

Por esta razón, y dada la avalancha de solicitudes que se está produciendo antes de que cambie el examen en agosto a la nueva versión, me ha parecido oportuno escribir una lista de 10 consejos sobre el examen PMP.

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?