Translate

junio 28, 2013

El problema de usar verde, amarillo y rojo como colores del semáforo de estatus del proyecto


En este post hablamos ya de la necesidad definir algún tipo de código de estado que pueda proporcionar rápidamente una idea del estado general del proyecto y sugerimos Verde, Amarillo y Rojo como código de colores aceptable.


Greg recuerda que en su trayectoria laboral ha debido realizar informes del estado del proyecto para la gestión ejecutiva y el director de la PMO. Debía reportar cómo estaba controlando el presupuesto, los eventos importantes, los riesgos, y resumir el estado general.

Y la sugerencia era usar un semáforo de colores También rojo, amarillo o verde - con las siguientes definiciones:

  • Rojo: Usado cuando aparecen cuestiones graves que probablemente retrasen el proyecto o provoquen que el presupuestario se rebase en forma significativa.
  • Amarillo: Posibles problemas con el cronograma o el presupuesto, pero que probablemente se puedan resolver con acciones correctivas.
  • Verde: En tiempo, dentro del presupuesto, todo bien.

El enfoque rojo / amarillo / verde parece simple y lógico. Sólo se preocupa a los interesados ​​si algo sale mal, por lo que los proyectos verdes no necesitan mucha revisión o atención.

Sin embargo, Greg considera que el enfoque de color tiene muchas deficiencias y posibles repercusiones:

Expectativas
¿Qué sucede cuando un proyecto verde se vuelve amarillo o rojo? Generalmente hay una emotiva conversación con los interesados. Éstos son algunos de los comentarios que se escuchan con frecuencia cuando un proyecto pasa de verde a amarillo:

"¿Qué salió mal?", "¿Por qué no se administró mejor el proyecto?," ¿Cómo podemos evitar que esto suceda otra vez? "," ¿Por qué no lo viste que esto podía ocurrir?".

El Administrador de Proyectos a menudo se siente culpable con estas conversaciones y también puede poner en duda su competencia. La recomendación es controlar el sentimiento de culpa ver el problema desde una perspectiva más analítica.

No estar en línea con la incertidumbre normal de proyecto
El cono de incertidumbre (definido aquí y aquí) nos dice que no se puede entender completamente todas las tareas y los problemas potenciales dentro de un proyecto, al inicio del mismo.

A medida que avanza el proyecto aprendemos más y hay menos riesgos, pero nunca se puede anticipar todo lo que podría salir mal hasta que el proyecto esta totalmente terminado.

Cuando etiquetamos un proyecto como "verde" le estamos diciendo al patrocinador todo está bien, el día de hoy.

Pero los patrocinadores interpretan "verde", como que todo está bien hoy y que debería seguirlo estando el resto del proyecto. Greg considera que parte de la naturaleza humana asumir que si el proyecto está bajo control, permanecerá bajo control todo el tiempo.

Un enfoque diferente
Pero cualquier Administrador de Proyecto con experiencia sabe que el verde no necesariamente significa verde para siempre. Y para solucionar este problema ha cambiado su esquema de color cuando se trabaja con patrocinadores y ha eliminado el "verde" de las opciones de estado.

Las opciones son ahora:

  • Amarillo: El proyecto no tiene ningún problema conocido, pero todavía hay un alto riesgo de que algo podría ir mal (como lo demuestra el cono de incertidumbre). Al igual que con cualquier proyecto en ejecución, se administra con cautela, haciendo el mejor esfuerzo para entregar con éxito.
  • Naranja: Ha surgido un problema y los objetivos del proyecto se encuentran en peligro. Pero se ha abordado el problema y en este momento es de esperar que todavía se podrá tener éxito.
  • Rojo: Ha surgido un problema y es probable que el proyecto no alcance el 100% de éxito esperado debido a este descubrimiento. Es más que probable que no se termine en la fecha deseada, o se exceda el presupuesto, o no se pueda entregar el alcance deseado en la fecha prevista.

Lo mas interesante del artículo de Greg es el cierre: Puede ser que a los interesados les asuste pensar que no hay "verdes", pero considera que todos los proyectos están en estado "amarillo" hasta su entrega. Tenemos que enseñar a los interesados ​​que esto es una realidad de negocio.

Yo coincido plenamente con Greg.

4 comentarios:

Magdalena dijo...

Gracias, tu explicacion es sencilla y concreta, y suficiente para quienes necesitamos respuestas rápidas, saludos desde Guatemala

Unknown dijo...

Es correcto que un proyecto que siempre se reportó en verde “súbitamente se reporte en rojo” o necesariamente debe pasar primero por amarillo

Anónimo dijo...

tengo un proyecto que se ha mantenido en verde-amarillo y finalmente en verde; el alcance cambió, el equipo de desarrollo cambió, el líder de desarrollo aún no tiene definido el impacto y tampoco una nueva planeación; debido a esto "cambié el semáforo de verde a rojo" me han cuestionado por no pasar primero por amarillo. tú qué opinas Iván?

Ivan Rivera dijo...

Hola.

Recién retomo las respuestas.

Muchas gracias a todos por sus comentario.

El proyecto va de acuerdo a los parámetros (y está en verde) o fuera de los parámetros y está en rojo.

EL probema del amarillo es donde establecemos los límites. Cuando es amarillo y cuando no. Si logras establecerlo es válido usarlo, pero debes dejar registro de la definición en el reposiorio de documentos del proyecto.

Feliz año y los mejores deseos desde México.

Entradas populares