RAID en la gestión de proyectos: cómo apoya a las PMO y a las partes interesadas

En la gestión de proyectos, RAID es un enfoque estructurado para capturar y gestionar los riesgos, supuestos, problemas y dependencias que pueden afectar el alcance, el cronograma, el costo o la calidad de un proyecto.

RAID se entiende mejor como tres cosas a la vez:

• Un marco de referencia: una forma coherente de categorizar la incertidumbre (riesgos y suposiciones) y la realidad (problemas y dependencias) para que nada importante se pierda en hilos de correo electrónico o notas de reuniones.
• Un proceso de gestión continuo: los elementos RAID se identifican, evalúan, asignan, gestionan y cierran. El marco no termina cuando se crea la lista.
• Mecanismo de comunicación y gobernanza: los registros RAID proporcionan a los patrocinadores del proyecto, los comités directivos y las PMO un punto de referencia común para analizar el estado del proyecto, en lugar de depender de actualizaciones de estado informales.

El error más común en la gestión de proyectos RAID es tratar el registro RAID como un entregable único generado al inicio del proyecto. En proyectos bien gestionados, RAID es un proceso dinámico: surgen nuevos riesgos, se validan o invalidan las suposiciones, se resuelven los problemas y las dependencias cambian a medida que se modifican los cronogramas. Un registro RAID que no se actualiza activamente se vuelve rápidamente inexacto, y un registro RAID inexacto suele ser más peligroso que no tener ninguno, ya que genera una falsa sensación de seguridad.

RAID son las siglas de Riesgos, Supuestos, Problemas y Dependencias. Cada componente responde a una pregunta diferente sobre el proyecto.

1. Riesgos

Un riesgo es un posible evento o condición futura que aún no ha ocurrido, pero que podría afectar negativamente el alcance, el cronograma, el costo, los recursos, la calidad o los objetivos comerciales si se produce. Los riesgos generalmente se evalúan utilizando:

• Probabilidad: qué tan probable es que ocurra el riesgo.
• Impacto: cuán graves serían las consecuencias si ocurriera.
• Gestión de riesgos : una visión combinada de probabilidad e impacto, que se utiliza a menudo para priorizar.
• Propietario: la persona responsable de supervisar y responder al riesgo.
• Mitigación: medidas que se toman ahora para reducir la probabilidad o el impacto.
• Contingencia: la respuesta planificada si el riesgo realmente ocurre.
• Desencadenantes: señales de alerta temprana de que el riesgo se está materializando.
• Estado: abierto, en seguimiento, mitigado, cerrado o resuelto (lo que significa que se convirtió en un problema).

2. Supuestos

Las suposiciones son condiciones que el equipo considera ciertas para fines de planificación, pero que no ha verificado formalmente. Todo plan de proyecto se basa en suposiciones, estén o no documentadas. El problema no radica en tener suposiciones, sino en dejarlas sin validar.

Una suposición no validada puede convertirse silenciosamente en un riesgo, un problema o una dependencia:

• Si no hay certeza de que se cumpla, se comporta como un riesgo.
• Si resulta ser falso y ya afecta al proyecto, se convierte en un problema.
• Si para confirmarlo se requiere la acción de otro equipo, se trata efectivamente de una dependencia.

Ejemplo: El equipo del proyecto asume que el departamento de finanzas del cliente tendrá los datos del plan de cuentas limpios y listos para la migración al inicio de la Fase 2. Si esto no se ha confirmado directamente con el equipo de finanzas, es una suposición que podría convertirse en un obstáculo más adelante.

3. Asuntos

La distinción más clara en RAID: un riesgo puede ocurrir, un problema ya ha ocurrido.

Los problemas requieren:

• Clasificación de gravedad: qué tan impacto actual tiene el problema.
• Responsabilidad: alguien responsable de impulsar la solución, no solo de tomar nota del problema.
• Medidas correctivas: qué se hará para resolverlo
• Fechas límite: cuándo se espera la resolución
• Escalada: si el problema necesita ir más allá del equipo del proyecto para ser resuelto.
• Estado de la resolución: abierta, en curso, escalada, resuelta

4. Dependencias

Las dependencias son tareas, recursos, equipos, proveedores, decisiones, sistemas o entregables de los que depende un trabajo. Las dependencias pueden ser:

• Gestión de tareas : una tarea no puede comenzar hasta que otra termine.
• Dependencias de recursos: una tarea requiere una persona, habilidad o equipo específico.
• Dependencias de proveedores: el trabajo depende de un producto entregable de un proveedor externo.
• Dependencias entre equipos: el resultado de un equipo alimenta el trabajo de otro.
• Dependencias de proyectos: los hitos de un proyecto afectan a otro proyecto.
• Dependencias entre proyectos: varios proyectos activos dependen del mismo recurso, sistema o decisión compartida.
• Dependencias externas: aprobación regulatoria, infraestructura de terceros o preparación del lado del cliente.

En RAID, las dependencias son importantes porque una sola dependencia retrasada rara vez causa un problema aislado. Se produce un efecto en cascada: un retraso en la entrega de un proveedor pospone un hito, el cambio de hito se produce cuando se necesita un especialista compartido, ese conflicto de recursos afecta a un segundo proyecto que depende de la misma persona, y el retraso combinado afecta a un compromiso a nivel de cartera con un comité directivo.

Ejemplo: Un proyecto de migración depende de que el equipo de seguridad de red complete la reconfiguración del firewall. El equipo de seguridad también está dando soporte a otros dos proyectos activos. Un retraso de dos semanas en el trabajo del firewall no solo retrasa una tarea de migración, sino que también modifica la fecha de transición, lo que afecta al plan de recursos del siguiente proyecto, que ya estaba programado para utilizar el mismo equipo de infraestructura.

Un registro RAID es una herramienta común de seguimiento en la gestión de proyectos que se utiliza para rastrear y gestionar los riesgos, supuestos, problemas y dependencias que pueden afectar la entrega del proyecto. Proporciona a los gerentes de proyecto y a los equipos una visión clara de las amenazas potenciales, los problemas actuales, los supuestos clave y las dependencias que deben abordarse.

Un registro RAID es más que una simple lista de problemas del proyecto. Es un documento de gestión dinámico que debe revisarse, priorizarse y asignarse a responsables específicos periódicamente. Al mantener la relación entre los elementos RAID y los cronogramas, tareas, recursos e hitos del proyecto, los equipos pueden identificar problemas con anticipación y tomar medidas correctivas antes de que afecten significativamente los resultados del proyecto.

Consideremos la implementación de un sistema ERP empresarial que involucre a los departamentos de Finanzas, Operaciones, TI y un socio externo para la implementación.

En ocasiones, las organizaciones mantienen estos documentos por separado y, en otras, los consolidan en un único registro RAID con una categoría de "Decisiones". Ambas opciones son válidas; lo que importa es la coherencia en el uso de la estructura elegida por parte del equipo, más que la estructura en sí.

1. Crear un registro RAID al inicio y actualizarlo rara vez después.
2. Registrar elementos RAID sin asignar un propietario claro.
3. Confundir riesgos y problemas, y dejar riesgos reales mal etiquetados.
4. Tratar cada riesgo como igualmente importante en lugar de priorizarlo según la probabilidad, el impacto y la exposición.
5. No validar las suposiciones antes de que creen o contribuyan a riesgos, problemas o dependencias. 
6. Realizar el seguimiento de las dependencias en un documento aparte del cronograma del proyecto.
7. Mantener hojas de cálculo RAID desconectadas por proyecto, sin formato compartido.
8. No definir con antelación criterios claros para la escalada de problemas.
9. Informar sobre los riesgos sin traducirlos en un impacto empresarial que preocupe a los ejecutivos.
10. No se cierran los elementos RAID obsoletos o resueltos, lo que provoca que el registro de actividad se sature.
11. No identificar riesgos relacionados o sistémicos en múltiples proyectos 
12. Sin ofrecer a los ejecutivos una visión global de la cartera de proyectos, solo instantáneas de cada proyecto.
13. Utilizar RAID como una casilla de verificación de cumplimiento en lugar de una herramienta activa de apoyo a la toma de decisiones.

RAID es importante en la gestión de proyectos por varias razones concretas:

• Detecta los problemas a tiempo : la mayoría de los fallos en los proyectos no son repentinos. Su origen se remonta a un riesgo que no se controló, una suposición que nunca se verificó, un problema que no se comunicó a tiempo o una dependencia que no se identificó. RAID los detecta antes de que se conviertan en retrasos o sobrecostes.
• Evita que los pequeños problemas se conviertan en grandes : un en la gestión de recursos o de un proveedor es más fácil de gestionar si se detecta a tiempo. Si no se gestiona, puede provocar retrasos en el cronograma, aumentos de costos e incumplimiento de objetivos.
• Se vuelve crítico en múltiples proyectos : un retraso, un conflicto de recursos o un problema con un proveedor en un proyecto rara vez se mantiene aislado. A menudo afecta a otros proyectos que comparten el mismo personal, proveedores o decisiones. RAID ayuda a los equipos a visualizar estas conexiones en lugar de descubrirlas después de que algo falla.
• Crea responsabilidades y mecanismos de rendición de cuentas claros : un registro RAID asigna cada riesgo, problema o dependencia a un responsable específico. Esto transforma la vaga idea de un problema en la identificación de una persona responsable de tomar medidas al respecto.
• Proporciona a los equipos un lenguaje común para el estado : en lugar de una actualización vaga como "las cosas van un poco retrasadas", un registro RAID señala la causa exacta: un riesgo, problema o dependencia con nombre, con un estado y un responsable asociados.
• Facilita una mejor toma de decisiones : con los datos RAID disponibles, los gerentes de proyecto, las oficinas de gestión de proyectos (PMO)y los ejecutivos pueden tomar decisiones informadas sobre prioridades, recursos y escalamiento, en lugar de basarse en conjeturas o actualizaciones informales.

Gestionar RAID dentro de un solo proyecto es un problema de gestión de proyectos. Gestionar RAID en una cartera de proyectos es un problema de PMO y gobernanza, y plantea desafíos que una hoja de cálculo por proyecto nunca fue diseñada para resolver.

Entre las dificultades más comunes a escala empresarial se incluyen:

• Registros RAID de proyectos individuales que existen de forma aislada, sin manera de ver que el mismo riesgo aparezca en múltiples iniciativas.
• Riesgos compartidos, como un problema sistémico de rendimiento del proveedor que afecte a todos los proyectos que este apoya.
• Proveedores comunes, donde un retraso con un proveedor repercute en varios proyectos no relacionados.
• Recursos compartidos, donde el mismo especialista, equipo o componente de infraestructura es una dependencia para múltiples proyectos a la vez.
• Dependencias entre proyectos, donde el hito del Proyecto A marca la fecha de inicio del Proyecto B.
• Prioridades de la cartera, donde los líderes de la PMO necesitan saber qué elementos RAID amenazan las iniciativas estratégicamente más importantes de la organización, no solo qué proyecto tiene el registro RAID más largo.

Los responsables de la PMO suelen necesitar seguir una cadena de visibilidad: impacto del elemento RAID, impacto del proyecto, impacto del programa e impacto del portafolio. Un solo fallo en una dependencia debe ser rastreable desde el nivel de tarea hasta determinar si amenaza un compromiso de entrega a nivel de portafolio. Lograr esa visibilidad con hojas de cálculo desconectadas por proyecto generalmente requiere un trabajo de consolidación manual considerable, que se repite en cada ciclo de informes, y es ahí donde las plataformas de gestión de proyectos a nivel de portafolio comienzan a demostrar su valía.

Comprender el concepto de RAID es la parte más sencilla. Implementarlo en docenas de proyectos activos, recursos compartidos y expectativas de informes ejecutivos es donde la mayoría de las organizaciones tienen dificultades. Celoxis es una plataforma integral de gestión de proyectos y carteras, y varias de sus funcionalidades se aplican directamente a los desafíos de gestión de RAID descritos anteriormente.

El principal problema del seguimiento RAID basado en hojas de cálculo, correo electrónico y notas de reuniones es la fragmentación: la información sobre un mismo proyecto se encuentra dispersa en distintos lugares, actualizada por diferentes personas y en momentos distintos, sin una única fuente de información fiable. Celoxis admite la automatización de flujos de trabajo, incluyendo plantillas para riesgos, incidencias y registros RAID, que permiten a los equipos capturar esta información dentro del mismo entorno utilizado para gestionar el proyecto. En lugar de que un riesgo se encuentre aislado en una hoja de cálculo, sin conexión con el cronograma al que afecta, la información RAID se puede registrar como parte del flujo de trabajo del proyecto, junto con las tareas, los recursos y los hitos que pueda ver afectados.

2. Supervisar los riesgos en múltiples proyectos

(PMO) suelen tener dificultades cuando cada proyecto mantiene su propia hoja de cálculo de riesgos, sin un formato consistente ni una forma sencilla de consolidar los elementos. Celoxis ofrece de gestión de cartera de proyectos , incluyendo paneles de control y análisis que brindan visibilidad del estado de los proyectos en múltiples iniciativas simultáneamente. Esto facilita una progresión natural desde el seguimiento de riesgos individuales hasta el estado general del proyecto y la visibilidad a nivel de cartera, sin necesidad de que alguien compile manualmente las hojas de cálculo de cada equipo de proyecto antes de cada revisión.

3. Realizar un seguimiento de las dependencias entre tareas y proyectos

La gestión de dependencias es fundamental en RAID y una de las tareas más difíciles de representar con precisión en una hoja de cálculo. Celoxis incluye planificación de proyectos basada en diagramas de Gantt con dependencias de tareas y programación dinámica, de modo que cuando una tarea predecesora cambia, las tareas dependientes y las fechas posteriores se actualizan automáticamente. Gracias a que los proyectos pueden vincularse dentro del mismo entorno de cartera, los equipos obtienen una visión más temprana de cómo un retraso en un proyecto puede afectar los plazos de otro, en lugar de descubrir el impacto una vez que ya se ha producido.

4. Mejorar la propiedad y la rendición de cuentas de RAID

Un elemento RAID sin propietario es solo una nota. Estructurar la información RAID dentro del entorno de proyectos y flujos de trabajo de Celoxis permite asignar elementos a propietarios específicos con tareas y fechas límite asociadas, manteniendo la responsabilidad visible junto con el resto del plan del proyecto, en lugar de que permanezca en un documento separado y fácilmente olvidable.

5. Cree paneles e informes RAID

Los distintos grupos de interés necesitan diferentes perspectivas de los mismos datos RAID. Los gestores de proyectos necesitan información detallada por partida. Los responsables de la PMO necesitan patrones que abarquen todos los proyectos. Los ejecutivos necesitan información sobre el impacto en el negocio y la visibilidad a nivel de cartera, no una simple lista de entradas. Celoxis ofrece paneles de control e informes configurables, incluidos paneles a nivel de cartera y la posibilidad de profundizar desde una vista resumida hasta los detalles subyacentes del proyecto, lo que permite adaptar la visibilidad de RAID a cada audiencia sin necesidad de mantener informes manuales independientes para cada una.

6. Conecte RAID con datos de proyectos en tiempo real

Esta es la idea central que justifica considerar RAID como algo más que documentación. RAID resulta más útil cuando los equipos de proyecto pueden vincular riesgos, problemas y dependencias con los cronogramas, recursos, hitos y decisiones de cartera que puedan afectar, en lugar de gestionar esa información en un archivo aparte. Dado que Celoxis funciona como un entorno integrado de gestión de proyectos y cartera, en lugar de una herramienta de registro RAID independiente, la información relacionada con RAID se puede visualizar junto con los cronogramas, tareas, asignaciones de recursos, presupuestos, hitos y el estado general del proyecto. Esta conexión permite rastrear un retraso en una dependencia hasta su impacto real en el cronograma y los recursos, en lugar de que permanezca como una nota aislada que alguien deba cotejar manualmente con el plan del proyecto.

7. Utilice información sobre proyectos obtenida mediante IA cuando sea pertinente

Celoxis incluye Celoxis Lex, una funcionalidad asistida por IA diseñada para ayudar a los usuarios a interactuar con la información del proyecto y recuperarla de forma más eficiente, incluyendo la visualización de datos relevantes y el análisis de la actividad en diferentes proyectos. En el contexto de la gestión de riesgos, incidencias y dependencias (RAID), esta funcionalidad permite a los equipos y a los responsables de la PMO encontrar información relevante sobre riesgos, incidencias y dependencias con mayor rapidez en un entorno de proyecto amplio y conectado. Facilita un acceso más rápido a los datos existentes del proyecto, en lugar de realizar predicciones autónomas; no elimina la necesidad de que los equipos identifiquen, evalúen y actúen sobre los elementos RAID por sí mismos.

GroundProbe, una empresa australiana que desarrolla tecnología de monitoreo de riesgos geológicos para operaciones mineras y civiles, se topó con un problema común. Sus equipos de Desarrollo de Producto y Geofísica gestionaban varios proyectos simultáneamente, compartiendo personal entre ellos y trabajando con proveedores externos. Antes de usar Celoxis, realizaban el seguimiento de todo esto mediante hojas de cálculo, correos electrónicos y conversaciones, sin un sistema centralizado.

Los riesgos y las dependencias eran reales, pero nadie los veía con claridad. Dos proyectos requerían a la misma persona simultáneamente y nadie se daba cuenta hasta que se producía un retraso. Era difícil controlar los costes, por lo que los problemas presupuestarios aparecían tarde en lugar de temprano. Los jefes de proyecto a menudo se enteraban de los problemas solo cuando ya se habían incumplido los plazos de entrega.

La analista de negocios Laura Yue lideró la búsqueda de un sistema mejor, comparando Celoxis con Microsoft Project, Wrike y Smartsheet. Celoxis fue elegido por sus herramientas de planificación, paneles de control y soporte.

Tras el cambio, todo cambió. Los conflictos de recursos se hicieron visibles antes de que provocaran retrasos. Los paneles de control mostraban los cuellos de botella con antelación, en lugar de a posteriori. Los sobrecostes se detectaban antes. Los informes que antes requerían trabajo manual para su elaboración ahora estaban disponibles directamente desde el sistema.

Laura Yue describió Celoxis como una solución con muchas funciones, fácil de implementar y altamente personalizable, con excelentes informes y soporte.

La lección aprendida: Los riesgos y las dependencias de GroundProbe no desaparecieron al migrar a Celoxis. Lo que cambió fue que el equipo finalmente pudo detectarlos a tiempo para actuar, porque la información estaba conectada a datos reales del proyecto en lugar de estar almacenada en hojas de cálculo aisladas.

RAID solo aporta valor cuando los equipos de proyecto gestionan activamente la información que contiene, en lugar de simplemente registrarla. Un registro RAID obsoleto, desconectado del cronograma, sin dependencias, oculto en una hoja de cálculo que nadie más abre, sin responsables claros o invisible a nivel de cartera, tiene un valor práctico limitado como herramienta de gestión, por muy completo que pareciera el día de su creación.

Las organizaciones que gestionan unos pocos proyectos sencillos suelen apañárselas con una hoja de cálculo bien organizada y hábitos disciplinados. Sin embargo, las organizaciones que gestionan carteras de proyectos complejas, con recursos compartidos, dependencias entre proyectos, relaciones con proveedores y obligaciones de presentación de informes a la dirección, generalmente necesitan conectar la información RAID directamente con la ejecución del proyecto: cronogramas, dependencias, recursos, paneles de control, informes y las decisiones que los responsables de la cartera deben tomar.

Celoxis integra la planificación de proyectos, los flujos de trabajo de riesgos e incidencias, las dependencias entre tareas e interproyectos, la gestión de recursos, los paneles de control y los informes de cartera en un entorno conectado, de modo que la información RAID no se encuentra aislada de los datos del proyecto que describe. Si la gestión RAID en su organización se ha convertido en un problema de gestión de cartera en lugar de un problema de hojas de cálculo, podría ser conveniente analizar cómo lo aborda una plataforma conectada.