Como te mencioné en la lectura, existe una relación directa entre el estado de salud del proyecto y el riesgo de que este fracase. Por esto, vamos a determinar el estado de salud del proyecto a través de la evaluación de siete dimensiones en la herramienta: "Salud del proyecto". Veamos cómo se utiliza. Lo primero que tenemos que determinar acá es las características del proyecto. En este caso tenemos el nombre del proyecto, "ABC" y el gerente del proyecto, Andrés. Acá vamos a tener la calificación del chequeo del riesgo o de la salud del proyecto y nos va a salir, entonces, de acuerdo con estos elementos que vemos acá, riesgo total del chequeo de salud, entre menos 14 menos siete, imposible; menos seis a cero, alto riesgo; uno a siete, riesgo medio; ocho a 14, riesgo bajo. Con base en eso, vamos, entonces a determinar las características de riesgo de nuestro proyecto. Las dimensiones van a ser entonces: el plan del proyecto, recursos, el "ownership", el apoyo de los patrocinadores interesados a las decisiones que se toman en el proyecto, la justificación del caso de negocio, la experticia, si hay especificaciones claras o no y el apoyo de la alta gerencia. Las reglas de calificación, vemos acá, van estar en: muy de acuerdo o no sé, menos cuatro; en desacuerdo, menos 2; neutral, cero; de acuerdo, dos y muy de acuerdo, cuatro. Veamos, entonces, cómo llenamos esta plantilla. Comencemos con el plan del proyecto. Vamos a escoger un proyecto cualquiera y simplemente vamos a ir mirando cuáles son las características. Lo primero que hacemos acá es ver si hay un plan detallado para la terminación del proyecto que incluye: el cronograma, la ruta crítica, los costos, los hitos, los requisitos del personal, etc. En este caso, decimos que estamos en desacuerdo, entonces ponemos menos dos. ¿Hay un presupuesto detallado para el proyecto? Muy de acuerdo, vamos a colocar cuatro. ¿Las necesidades de personal clave, quiénes y cuándo están claras y se especifican en el plan de proyecto? ¿De acuerdo? Sí, dos. ¿Sabemos qué actividades tienen holgura o recursos que se pueden utilizar en otras áreas durante una emergencia? No tenemos mucha idea, no estamos de acuerdo, menos dos. ¿Hay planes de contingencia para el caso en que el proyecto esté atrasado en el cronograma o por encima del presupuesto? En este caso estamos muy en desacuerdo o simplemente no sabemos, menos cuatro. Seguimos, entonces, con los recursos. ¿Hay suficiente personal para terminar el proyecto? De acuerdo, dos. ¿Está disponible la tecnología apropiada a través del ciclo de vida? De acuerdo, dos. ¿La tecnología que se utilizará para apoyar el proyecto funciona adecuadamente y está completamente soportada? Sí, dos. De acuerdo. ¿Las tareas específicas del proyecto se gestionan bien? Menos dos. Desacuerdo. ¿Los miembros del equipo de proyecto tienen claro su rol? Neutral, sí. Seguimos entonces con lo que tiene que ver con el "ownership", pero antes de revisar el "ownership", miremos que, en el caso del plan del proyecto, tenemos que tener cuidado, mientras que en el caso de los recursos estamos más o menos bien. Sigamos con el "ownership", entonces, en este caso. ¿Qué vamos a revisar en el "ownership"? Vamos a mirar, entonces, el comportamiento de los diferentes interesados. ¿A los interesados se les dio la oportunidad de proporcionar la información temprano en el proyecto? Sí, no hubo ningún problema. ¿Los interesados aceptan el "ownership" de las acciones del proyecto? Sí. ¿Las condiciones de los entregables han sido convenidos con el patrocinador del proyecto? Menos dos. No estamos de acuerdo. ¿Los interesados comprenden las limitaciones del proyecto, qué no va a hacer el proyecto y qué sí va a hacer? No está muy claro, menos dos. Y, ¿los interesados entienden cuáles de sus requerimientos están incluidos en el proyecto? No estamos tan convencidos, entonces, ponemos menos dos. Fíjense que, en este caso también entonces tenemos ya los elementos que nos dicen que el proyecto tiene que tener cuidado, porque también acá tenemos problemas con el "ownership" y con los diferentes interesados. Seguimos con la justificación del caso de negocio. En este caso, ¿el proyecto se ha costeado y los presupuestos se han convenido completamente con el patrocinador? Sí, entonces vamos a poner muy de acuerdo. ¿Se hicieron estimaciones de los valores financieros, económico y comercial del proyecto? De acuerdo, dos. ¿El proyecto promete beneficios a la organización y un rol claro? No está tan claro, luego, estamos en desacuerdo. ¿Se han identificado los indicadores de éxito del negocio y se han planeado los procesos de medición? En desacuerdo total. Y, ¿existe un financiamiento adecuado para el ciclo de vida del proyecto? Vamos a decir que de acuerdo. Con esta información, entonces ya tenemos la justificación del caso de negocio, que a pesar de todo, pues no está tan supremamente mal. Vamos a mirar, entonces, ahora, la experticia. ¿Todos los miembros del equipo de proyecto poseen los niveles apropiados de experticia? Sí, ahí estamos normal, no tenemos nada de pesar, todo es neutral. ¿Los usuarios del proyecto lo entienden y son capaces de implementarlo cuando se los entregue? Sí. ¿El equipo de proyecto entiende cómo va a ser evaluado su desempeño? Sí. ¿Se han escrito, han sido entendidas y se han convenido las responsabilidades para los miembros del equipo de proyecto? Sí. Y, ¿se ha definido un entrenamiento adecuado y el tiempo para el mismo dentro del alcance y con base en el cronograma de proyectos? Sí, no hay ningún problema por esperar. Vamos a las especificaciones, a ver si son claras o no. ¿Los objetivos del proyecto están claros para todos los interesados y para los miembros del equipo? No, no están tan supremamente claros. Tenemos un problema, menos cuatro. ¿Las metas del proyecto están en línea con las metas corporativas y con los estándares corporativos? En desacuerdo, dos. ¿Está el gerente de proyecto convencido de las posibilidades de éxito de este proyecto? Sí, él es un gerente de proyecto optimista. ¿Hay una documentación adecuada a los requerimientos del proyecto y de las necesidades de desempeño operacional? En desacuerdo. Y, ¿se ha hecho una presentación adecuada de las metas y de los objetivos del proyecto a los interesados? En desacuerdo, no se ha hecho y ahí tenemos problemas. Si nos vamos entonces a mirar la calificación, vemos que es la más bajita de todas y por eso entonces dice: "cuidado con las especificaciones". Por último, nos vamos al apoyo a la alta gerencia. ¿El patrocinador del proyecto comparte la responsabilidad con el equipo de proyecto para asegurar el éxito del proyecto? De acuerdo. ¿La alta gerencia responderá rápidamente a la solicitud de recursos adicionales si se presenta la necesidad? Sí. ¿Se han convenido los términos de referencia, los niveles de autoridad y la responsabilidad para el proyecto? De acuerdo. ¿El gerente de proyecto tiene total confianza en que pueda acudir por ayuda a la alta gerencia cuando lo considere necesario? De acuerdo. ¿El patrocinador del proyecto está comprometido completamente con el éxito del proyecto? De acuerdo. Vemos, entonces, en este elemento y nos vamos a mirar la calificación, nos da la más alta de todas, sí. Y lo que vamos a mirar acá, entonces, es que vamos a obtener un riesgo alto de acuerdo con las calificaciones que tenemos acá. ¿Cómo podemos ver esto gráficamente? Nos vamos básicamente a nuestra gráfica. Y en este caso, en la gráfica, lo que estamos viendo es cuáles elementos son los más importantes y cuáles elementos están en riesgo. Fíjense que en el caso del apoyo a la alta gerencia estamos bastante bien. En el caso de recursos y de justificación del caso de negocio, no estamos tan supremamente bien. Estamos mal en la parte de las especificaciones claras y en el "ownership". ¿De acuerdo? Entonces, tenemos que mirar y esforzarnos acá, porque el proyecto como tal está en un riesgo alto.
