Modelo RACI - Qué es y para qué se usa

Hola de nuevo. Hoy quiero hablaros de una técnica que es a la vez tan simple como necesaria, y que sin embargo, se tilda de teórica e inútil en muchas ocasiones...incluso cuando nos damos cuenta de que hace falta.

Es una técnica de gestión de proyectos, por lo que efectivamente, aquellos proyectos que carezcan de una adecuada gestión, son los principales candidatos a quejarse de esta técnica.

El modelo RACI es una técnica que permite identificar quién se encarga de qué en el proyecto. Pero va mucho más allá, identificando los principales roles intervinientes en cada tarea. Los roles que identifica esta técnica son cuatro, cuyas iniciales en inglés dan nombre al modelo:

• Responsible: responsable de ejecutar la tarea. Vamos, quien la hace físicamente, el que se pone manos a la obra, y se "mancha" las manos.
• Accountable: responsable de que la tarea se ejecute, es quien rinde cuentas. ¿Porqué separar este rol con el anterior? En muchas ocasiones, yo puedo ser el responsable de que algo se haga, pero no lo hago directamente yo. Lo subcontrato, o lo asigno a un tercero. Y es importante diferenciar las tareas que hago yo directamente, de las que encargo a otros.
• Consulted: este rol tiene información útil o valiosa para la realización de las tareas, aunque no sean responsables de las mismas ni participan activamente en su ejecución. Por ejemplo, grupos de expertos en un tema, grupo de calidad, etc. Es importante destacar, que este rol interacciona bi-direccionalmente, es decir, se le consulta, y él responde, o bien participa de forma espontánea aportando su conocimiento.
• Informed: informado. En este rol incluiremos a todos los grupos que hay que mantener informados, poner en copia de los correos, etc. La principal diferencia con otros roles es que con éste se tiene comunicación unidireccional.

¿Cómo se hace todo esto?.

Una forma simple es hacer una tabla, donde por cada fila, escribiremos en la primera columna el nombre de las tareas. De esa forma, por cada fila (por cada tarea), rellenaremos a su derecha unas columnas adicionales, una por cada persona o grupo involucrado. En esas columnas adicionales, indicaremos su rol por las iniciales antes mencionadas: R, A, C, I.

A la hora de rellenar con estas letras/roles, tendremos en cuenta una serie de reglas:

• No es necesario usar todas las letras (R,A,C,I) en cada fila/actividad.
• Al menos, sí deben aparecer en cada fila/actividad, los roles R y A (es decir, responsable y encargado de ejecución). Los roles C,I, son por tanto opcionales en cada fila.
• En cada fila/actividad, debe aparecer un único R (responsable de ejecución), y un único A (responsable de la tarea).
• En cada fila/actividad, los roles C,I pueden repetirse.
• Una misma persona/grupo, puede asumir varios roles para una misma tarea. En ese caso, se anotaría algo como "R/A" si por ejemplo fuese a la vez responsable de la tarea y de su ejecución.

La imagen siguiente ejemplifica lo comentado:

¿Dónde se utiliza esto?

Yo lo he usado principalmente en documentación funcional para definir el "As-Is" o el "To-Be" de los procesos de negocio, o en contratos, o propuestas, donde es fundamental dejar claro el papel de las distintas partes durante el ciclo de vida de una tarea.
Es importante hacer notar, que el rol de las distintas partes puede cambiar en el tiempo. Por ejemplo, en un mantenimiento, el proveedor anterior de mantener la aplicación puede pasar de R/A, a solamente A/C (en la fase de transición) y finalmente solo C en un período de soporte en el que el nuevo proveedor de mantenimiento tiene ya el control total del soporte.

¿Y ya está?
Pues no. Como siempre, hay variantes para todos los gustos. Por ejemplo veremos dos a continuación.

RACI-S

Existe la variante RACI-S, que añade un rol adicional de Soporte ("Support"). Ésta es la variante que he visto en la práctica. EL rol Soporte, se encarga de dar soporte de todo tipo al rol "R" (que es quien hace la tarea), en todo lo que éste necesite. No confundir con el rol "C", que sería más bien un experto en la materia, y que si bien también da soporte, digamos que dicho soporte sería más "pasivo" que el del rol "S".

RACI-VS

También existe la variante RACI-VS que añade dos roles:

• Verify (verificador): este rol se encarga de actividades de verificación, es decir, de comprobar si el producto está conforme con los criterios de aceptación establecidos en su descripción/diseño/calidad.
• Sign (aprobador o supervisor): este rol aprueba las decisiones del rol Verificador y autoriza el producto. Lo lógico es que el trabajo de un S preceda siempre al de un A.