¿Como puedo saber cuando el proyecto terminó en forma exitosa?

English Version Follows

Uno de los problemas más frecuentes a los que me he enfrentado desde la PMO es la incapacidad de los equipos del proyecto de decidir cuando el proyecto está terminado.

Y por equipo de proyecto no me refiero solo al equipo de trabajo que ha elaborado los entregables, sino a todos los interesados: el cliente y su personal involucrado, y las personas que participan en cada una de sus fases.

Así que una primera dificultad es decidir si el proyecto terminó o no. Pero además el esquema se complica aún más si lo que se busca es determinar si terminó en forma exitosa. Aunque puede parecer un asunto de sentido común, la verdad es que las definiciones de "terminado", "éxito" y "fracaso" son subjetivas, por lo es buena idea buscar un acuerdo entre todos los interesados sobre lo que estos conceptos representan.

Es cierto que las mejores prácticas nos sugieren registrar el enunciado de alcance preliminar y la definición del alcance del proyecto. Además sabemos que todos los cambios al alcance se deben registrar en el log correspondiente y que antes de aprobarlos se debe hacer un análisis de los riesgos y su impacto en el cronograma, en el costo, en los recursos requeridos, etc. Pero de nuevo estos documentos nos refieren a conceptos difíciles de evaluar si el equipo no se ha puesto de acuerdo previamente.

Y la percepción, los sentimientos de los interesados, rara vez tienen que ver con lo que dice el control de cambios. El sistema funciona o no, se terminó a tiempo o no, independientemente de si el documento de aceptación de entregables está firmado.

Espero que un ejemplo (ficticio) ayude a aclarar la idea: Consideremos un proyecto X, cuyo objetivo era desarrollar el sistema de nómina de la empresa Y, que permita hacer los pagos a sus 300 empleados. El plan marcaba 3 meses de desarrollo, pero a la mitad del camino se emite una nueva reglamentación gubernamental que impacta al sistema.

El equipo de trabajo hizo un esfuerzo a pesar del cual el proyecto terminó 2 semanas tarde y con un 17% de costo adicional.

El equipo de trabajo está cansado pero satisfecho. El cliente está contento porque aun cuando no se cumplieron los tiempos su portal ahora es accesible a un mercado mayor. En cambio, la gerencia media en la compañía a cargo de desarrollar el proyecto no parece muy contenta, porque incluso cuando el cliente está satisfecho el margen de ganancia se redujo.

¿Es un proyecto exitoso? No podemos dar una respuesta categórica al respecto. Es necesario hacer mediciones de valor ganado (o el método de valoración que se prefiera) para saber si la relación entre cambio de alcance, mayor costo y más trabajo es positiva o negativa. Por otro lado, dos de tres grupos de interesados están contentos, así que no debe haber salido tan mal.

Esta situación de indefinición se puede solucionar si desde el principio todos los interesados acuerdan bajo qué condiciones se va decidir que el proyecto está terminado, y como saber si ha resultado exitoso.

Bajo este orden de ideas podemos acordar con los interesados que "el sistema de nómina se considerará terminado cuando el cumpla con el siguiente listado de funcionalidades...".

Podemos acordar con todos los interesados que el proyecto es exitoso si "al finalizar el tiempo negociado (incluyendo las ampliaciones y reducciones acordadas), es capaz de realizar los pagos de una nómina de hasta 300 empleados y respeta toda la reglamentación aplicable".

Como dije, parece casi un tema de sentido común, pero no se hace.

Y a pesar de que puede parecer complicado, es un mecanismo que sin mucho esfuerzo extra puede evitar que el equipo no sea capaz de decir cuando acaba el proyecto, y cuando efectivamente termine, permite decir si el proyecto fue exitoso.

La idea de escribir este post parte de las clases que imparto en el ITESM y del #PMChat.

English Version

One of the most common problems that I have faced from a PMO perspective is the project teams inability to declare when the project is finished.

And by project team I don’t just mean people that build deliverables, but to all stakeholders: customers and staff involved, and the people involved in each project phase.

So the first difficulty is to decide whether or not the project has ended. Also it is complicated to determine if the project was finished successfully. Although it may seem a matter of common sense, the truth is that "finished", "success" and "failure" definitions are subjective, so it is a good idea to find an agreement among all stakeholders about what these concepts represent.

It is true that best practices suggest writing down the preliminary scope statement and the project scope definition. We also know that all scope changes must be registered in the corresponding log and that before approval the team should do a risk analysis and review the impact on the schedule, cost, resources, etc. But again these documents make reference to concepts that are difficult to assess whether the team has not previously agreed.

Stakeholders feelings and perceptions are rarely considered in the change control process. The system works or it doesn’t,  it was completed on time or it wasn’t regardless of whether the deliverables acceptance document is signed or not.

An example (fictional) helps to clarify the idea. Lets consider project X, whose deliverable was the payroll system of company Y. It should allow make payments to 300 employees. The schedule states 3 months of development, but in the middle of the project government issues a new regulation that impacts the system.

The team made an extra effort in spite of which the project still ended 2 weeks late and with 17% additional cost.

The team is tired but satisfied. The customer is happy because even though the schedule was not met, the system still meets regulations. In contrast, middle management in your company does not seem very happy because even though the customer is satisfied the profit margin was reduced.

Is this a successful project?

We can not give a categorically right answer to this. It is necessary to measure earned value (or the valuation method you prefer) to see if the relationship between the change in scope, cost and work is positive or negative. On the other hand, two of the three groups of stakeholders are happy, so it should not be classed as unsuccessful.

This situation of uncertainty can be resolved from the beginning if all stakeholders agree under what conditions a project would be deemed successful when it is finished.

Following this idea, stakeholders can agree that "the payroll system project shall be terminated when it meets the following list of features ...".

We agree with all stakeholders that the project is successful if "at the end of scheduled time (including extensions and reductions agreed), the system is able to make payments on a payroll of 300 employees and respects all applicable regulations."

As I said, it seems almost a matter of common sense, but is not always done.

And while that may seem complicated, without much extra effort you can prevent your team from not knowing when the project ends. When the project is actually finished it is easier to understand whether it has been successful.

The idea of writing this post came from teaching Project Management classes at ITESM and from #PMChat.


Thanks to Lindsay Scott for the review and suggestions to the english translation of this post.