Hace unas semanas, estuve asistiendo a un director de proyecto con un proyecto problemático. Revisamos la documentación desde el principio, comenzando con los sospechosos habituales: el acta del proyecto, la estructura de desglose de trabajo y el cronograma. Todos parecían bastante sencillos y comprensibles. Sin embargo, cuando llegamos a los informes de estado, comenzó la confusión. Los informes de estado de este proyecto eran hojas de cálculo de unas 10 páginas de longitud. Cada semana, el equipo solo podía discutir alrededor de 3 páginas de información, y la mayoría de ellas eran riesgos. “¿Por qué es tan largo, qué contiene?” le pregunté. Él respondió que era su registro RAID, que utilizaba para llevar a cabo las reuniones de estado. Quería asegurarse de no pasar por alto nada, por lo que se aseguraba de incluir cada elemento relacionado con el proyecto y clasificarlo como R (riesgo), A (acción), I (problema) o D (dependencia) en esta enorme hoja de cálculo. Como la primera sección era “Riesgos”, ciertamente se abordaban. Por lo tanto, la mayor parte de la discusión en su reunión semanal de estado se centraba en eventos que ni siquiera habían ocurrido.
Para ser justos, utilizado de manera adecuada, un registro RAID es una excelente herramienta para ayudar a los directores de proyecto a mantener los proyectos en el buen camino. Enumera, en un solo lugar de fácil acceso, casi cualquier evento presente o futuro que pueda afectar su proyecto. Sin embargo, pueden surgir algunas dificultades que disminuyen la utilidad de un registro RAID.
Frecuencia
En un proyecto promedio, los riesgos pueden no necesitar ser revisados cada semana, pero en un proyecto de alto riesgo, el registro de riesgos puede necesitar ser revisado con mayor frecuencia incluso que los elementos de acción. Cada proyecto tiene una composición diferente, lo que debería dictar la frecuencia con la que se debe considerar cada categoría en un registro RAID.
Importancia
Cuatro categorías (R, A, I, D) pueden generar muchos elementos. Es por eso que en cada categoría debe haber una forma de priorizar los elementos que el equipo, de hecho, sigue. Esto significa que los problemas o acciones de alta prioridad se pueden discutir en la reunión de revisión de estado, mientras que los elementos de baja prioridad pueden ser abordados por el director de proyecto después de la reunión, y según el tiempo lo permita.
Enfoque de gestión
Finalmente, los elementos en cada una de estas categorías requieren un enfoque de seguimiento diferente. Por ejemplo, los “Problemas” son situaciones problemáticas. Pequeñas o grandes, son discrepancias o desacuerdos que han ocurrido dentro del proyecto y deben resolverse. Pueden requerir manejo de conflictos, negociaciones o la participación de la dirección. Por otro lado, los “Riesgos” son eventos que pueden o no ocurrir. Llegar a la mitigación de riesgos requiere la generación de enfoques alternativos, sí, pero es posible que nunca lleguen a implementarse.
Por estas razones, es importante pensar cuidadosamente si mantener un solo registro RAID o mantener registros separados de Riesgos, Problemas, Acciones y Dependencias para ser monitoreados en momentos diferentes.
