19 de mayo de 2013

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.


12 de mayo de 2013

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: ¿Quieren saber qué se supone que debe hacer un Product Owner? Solo tienen que visitar este enlace y ya lo saben todo.

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?


1 de mayo de 2013

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.

28 de abril de 2013

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”.


21 de abril de 2013

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?


14 de abril de 2013

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.


7 de abril de 2013

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?


31 de marzo de 2013

Fail to Plan is Plan to Fail




In their day to day job, Project Managers should master the habit of visualizing about the project. Deliverables are also created twice. Before that deliverables could be tangible, the Project Manager had already imagined them. Before that team members could follow a number of processes and develop many activities, the Project Manager “had already been there”. Starting with the end in mind, in the field of Project Management, means something very specific: planning.

Before insisting about the importance of good planning for every Project (fail to plan is plan to fail), let’s think of what happen when the Project Manager doesn’t have the habit of planning. When you see someone leading a project just doing what customer asks, responding day to day issues and crisis just by reacting. Can you call this to manage a project? 


24 de marzo de 2013

Retrospectiva del Proyecto Havannah

A continuación tienen un vídeo con un breve resumen de los 5 últimos posts dedicados al caso práctico con métodos ágiles desarrollado en el libro Agile Estimating and Planning, de Mike Cohn.


Espero que les sirva como referente práctico para aclarar conceptos como: iteración, historia, puntos-historia, velocidad, iteration planning, release planning, iteration review, etc. Nada tan efectivo como imaginar estos conceptos en acción en un caso más o menos realista, ¿verdad?

Por favor, no se queden solo con el vídeo, que no equivale a leer el capítulo de más de 50 páginas. Les animo a que compren este buen libro, ideal para comprender mejor los métodos ágiles. Si solo pueden leer una parte, lean el caso práctico desarrollado en el capitulo 23. Si quieren leer este capítulo en español, pueden empezar por aquí.

17 de marzo de 2013

Quemando las iteraciones del Proyecto Havannah


Quinta y última entrega de la traducción capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, dejábamos al equipo a punto de comenzar la primera iteración de 2 semanas, que habían planificado en 4 historias de 18 puntos. También habían previsto que el proyecto duraría entre 12 y 20 semanas. En este post veremos lo siguiente:
  1. El equipo demuestra los resultados de la 1ª iteración (completan 16 puntos de 18) y planifican la 2ª iteración con 3 historias de 18 puntos.
  2. Demuestran la 2ª iteración completa al 100% y planifican la 3ª teniendo en cuenta dos nuevas funcionalidades “emocionantes” que ha investigado Diana, de 30 y 35 puntos, respectivamente. Si quieren mantener la planificación en 12-20 semanas, deben renunciar a una funcionalidad emocionante de 30 puntos. Antes de arrancar la 3ª iteración, quedan por quemar 133 story points (más que los 132 que tenían al principio del proyecto, ¿significa esto que van para atrás?).
  3. Por último, atendemos a la reunión de revisión de la última iteración del proyecto, finalizado en un plazo 22 semanas, con 2 semanas de retraso sobre la estimación inicial comunicada de 20 semanas, pero a cambio de mucho más valor para el negocio.
En este caso práctico, los métodos ágiles han supuesto una cuantificable mejora del proceso de desarrollo de software, sobre todo comparando con el retraso acumulado del proyecto anterior de 6 meses.

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.