El registro RAID que nadie actualiza: fallos comunes y cómo evitarlos
Un registro RAID — riesgos, supuestos, incidencias (issues) y dependencias — es una de las herramientas de proyecto más simples que existen, y de las que más a menudo se abandonan. Se crea con buenas intenciones en el arranque, se llena con intensidad durante una semana y luego muere en silencio. Cuando algo sale mal, el registro muestra un riesgo abierto hace seis meses y una incidencia que en realidad se cerró en marzo. Cuando los equipos pasaron a lo remoto e híbrido en 2021, esto empeoró: las conversaciones de pasillo que mantenían a todos informados de los riesgos vivos desaparecieron, y un registro obsoleto se convirtió de pronto en la única memoria compartida. Aquí está dónde fallan estos registros y qué hacer en su lugar.
Por qué se quedan obsoletos los registros RAID
Confundir las cuatro categorías. Un riesgo es algo que podría ocurrir; una incidencia es algo que ya ocurrió. Un supuesto es algo que se da por cierto sin prueba; una dependencia es algo que se necesita de otro sitio. Cuando se vuelca todo en un único cubo de «cosas que vigilar», el registro pierde la precisión que lo hace útil.
Sin responsable por línea. Una entrada sin una persona con nombre es una entrada que nadie actualiza. Que «el equipo» sea dueño de un riesgo significa que nadie lo es. Cada línea necesita un nombre.
Registrar sin evaluar. Un riesgo sin probabilidad ni impacto no se puede priorizar, así que todo parece igual de urgente, lo que equivale a que nada lo sea. Sin una puntuación, el registro se vuelve una lista plana que se pasa de largo.
Tratarlo como documentación, no como herramienta de trabajo. Si el registro solo se abre para cumplir una casilla de gobernanza, siempre estará desactualizado. Tiene que ser aquello desde lo que realmente se conduce la conversación.
No cerrar nunca nada. Un registro que solo crece se vuelve ilegible. Los riesgos ya superados y las incidencias resueltas deben marcarse como cerrados, con fecha, para que los elementos vivos resalten.
Convertirlo en un registro que el equipo mantenga al día
La solución tiene menos que ver con la plantilla y más con el ritmo. Un registro RAID se mantiene vivo cuando revisarlo es un acto breve, regular y visible, en lugar de una excavación arqueológica trimestral.
Ponga una breve revisión RAID en una agenda recurrente: unos minutos en la reunión semanal del proyecto, no una ceremonia aparte a la que nadie asiste.
Manténgalo donde el equipo ya trabaja, no en un archivo enterrado. Para un equipo remoto, una vista compartida siempre abierta supera a un documento que alguien debe recordar enviar.
Puntúe los riesgos de forma simple: probabilidad alta/media/baja frente a impacto alto/medio/bajo basta para ordenar la lista.
Dé a cada entrada un responsable, un estado y una fecha de última revisión, para que un vistazo revele qué está vivo y qué está fosilizado.
Cierre los temas en voz alta. Marcar un riesgo como cerrado y decir por qué importa tanto como plantearlo.
Un buen registro RAID no es un artefacto grueso; es una imagen breve, honesta y actual de qué podría descarrilar el trabajo y quién vigila cada cosa. Cuando se mantiene de verdad, hace el trabajo silencioso para el que fue concebido: permite al equipo ver el problema con tiempo para actuar, en vez de explicarlo después.
Si su seguimiento de riesgos e incidencias se ha convertido en un documento en el que nadie confía, la asesoría en entrega de programas y proyectos de XNM puede ayudarle a reconstruir una disciplina RAID que su equipo de verdad use.