¿Sería esta una buena manera de informar?

No sé si estoy reinventando la rueda, pero nunca me he encontrado con el siguiente método de denuncia.

Me imagino que si tuviera que elegir una sola métrica para informar a la alta dirección sobre un proyecto, sería el riesgo de que el proyecto no entregue algo del valor previsto, a tiempo. Me imagino que esta métrica podría usarse en algo como una página web de proyecto.

Al comienzo de un proyecto, como gerente de proyecto, lo establecería en un 50% conservador. El objetivo del grupo es reducir el riesgo de fracaso. Me imagino que en una página de proyecto de este tipo, habría una descripción más detallada de por qué se establece en su valor actual. Esto podría ser: Riesgo de malentendidos entre la alta gerencia y el gerente del proyecto, riesgo de que un proyecto más grande en una parte diferente de la organización lo haga obsoleto, riesgo de no tener los recursos críticos necesarios disponibles durante todo el proyecto.

La razón por la que creo que esta es la métrica más importante es porque le dará rápidamente a la alta dirección la única métrica, que es importante al momento de decidir si utilizar sus capacidades en el proyecto, ya sea deteniéndolo, redefiniendo o agregando recursos. o algo mas.

¿Es solo una vieja teoría o es nueva?

Respuestas (4)

El problema con esto es que carece de una definición formal del valor real que darás.

Si tiene una división clara de su proyecto en tareas, junto con una planificación de tareas, entonces puede usar un derivado del valor en riesgo. Significa que usted asegura que "con confianza X% cumpliremos al menos Y% de las tareas planificadas del próximo período".

Si está interesado, hay una buena entrada para el valor en riesgo en Wikipedia: http://en.wikipedia.org/wiki/Value_at_risk

Aquí está el problema que tengo con este concepto: como PM, su trabajo es reducir, mitigar o eliminar los riesgos. Se supone que debes idear un plan que asegure el éxito del proyecto incluso antes de comenzarlo. La métrica de informes y los ejemplos que usó evitan todo esto e implican que solo hay un 50 % de posibilidades de éxito incluso antes de comenzar.

"riesgo de malentendidos entre el administrador senior y el PM": si esto es un riesgo, debe abordarse y resolverse ANTES de comenzar el proyecto. Realmente estoy luchando con la idea de que comenzaría un proyecto con un posible malentendido que sigue siendo un "riesgo" declarado.

"riesgo de que un proyecto más grande en una parte diferente de la organización haga que este proyecto quede obsoleto": entonces no hay una razón lo suficientemente fuerte para este proyecto o alguien no está prestando atención a lo que está sucediendo. De cualquier manera, pone en duda el valor del proyecto incluso antes de que comience.

"riesgo de no tener los recursos críticos necesarios disponibles a lo largo del proyecto": nuevamente, esto debe hacerse y asegurarse antes de que comience el proyecto.

Supongo que el verdadero problema que tengo con esta idea es este: todos los proyectos enfrentan un riesgo principal: el riesgo de fallar. Es el trabajo del PM navegar el proyecto a través de ese riesgo principal para el éxito. Pero la forma en que lo ves es que estás creando excusas de por qué puede no tener éxito, incluso antes de que comience.

Ahora puede ser que lo haya leído mal y estos son solo ejemplos. Si es así, puede ignorar mis respuestas a los elementos específicos. Sin embargo, la idea de la gestión de riesgos aún se mantiene.

El otro problema es la idea de una única métrica para el éxito. No hay UNA métrica que sea más importante. Mgmt querrá saber si está a tiempo, dentro del presupuesto y si proporciona el resultado esperado con las cualidades definidas.

en realidad, el trabajo de los PM es administrar el riesgo, a veces eso significa aceptarlo. A menos que sea un cronograma muy corto, a lo largo del proyecto es una buena idea realizar sesiones periódicas de identificación de riesgos porque las cosas cambian y aparecerán nuevos riesgos y los riesgos actuales desaparecerán.
Acordado. No incluir la aceptación fue un error de mi parte. Gracias por captar eso. Mi mayor preocupación era la idea de que la 'probabilidad de éxito' fuera la principal métrica de informes y que fuera solo del 50 % al principio debido a los riesgos 'potenciales'.

Todas buenas respuestas, pero creo que el principal defecto es tratar de informar una métrica. Solo proporcionar esta única dimensión es peligroso porque puede parecer que estás ocultando algo cuando surgen problemas. Mantenerlo demasiado simple para la vista ejecutiva no les proporciona lo que quieren saber.

Mi consejo es tratar de hacer un tablero que se pueda revisar rápidamente. Por ejemplo, use el modo de semáforo para el estado y luego uno o dos puntos sobre los problemas que están ocurriendo actualmente o que se resolvieron recientemente y los riesgos que están surgiendo.

Parece que puede estar intentando reinventar la gestión del valor ganado .

EVM puede proporcionar métricas significativas sobre el valor general del trabajo realizado, encapsuladas en uno o más números.