Errores comunes en una matriz RACI

0

La matriz RACI  es un elemento muy conocido en el mundo de la gestión y sirve como herramienta para plasmar de forma fácil la responsabilidad de una serie de personas o departamentos en una tarea determinada. Pero mi experiencia tanto a nivel laboral como lector ávido de blogs diversos  me hace ver una serie de errores comunes a la hora de definir o utilizar una matriz RACI. Y ese es el motivo de este artículo, desenmascarar estos errores y ofrecer unas buenas prácticas sobre su uso.

RACI 101

Antes de todo, por si algún lector no sabe que es una matriz RACI, una breve introducción. Consiste en una tabla en la que para cada tarea se define qué personas o unidades organizativas se asignan a cuatro roles de la tarea. Cada rol es una de las letras de RACI, y se corresponden con:

  • Responsible: Encargado o encargados de realizar la tarea.
  • Accountable: Responsable en última instancia de que se ejecute la tarea.
  • Consult: Personas que deben ser consultadas para realizar la tarea, ya sea por su conocimiento o por implicaciones.
  • Inform: Personas que deben ser informadas del avance de la tarea.

Como es un tema muy trabajado, os recomiendo que si no la conocéis os deis un paseo por artículos (preferentemente en inglés, porque hay unos fallos que no comenten) y luego volváis a este artículo.

Para hacerlo fácil os pongo un par de links:

Y ahora con los fallos comunes.

Responsible es un false-friend

La traducción de Responsible a castellano es responsable, pero no en sentido completo de responsable como lo usamos en castellano. Responsible tiene más relación con hacer la tarea que con responsabilizarse de su ejecución. Para la matríz RACI, la palabra Responsible se traduce mejor como Encargado o Asignado. Es quien tiene que hacerlo, pero no es el responsable de que se haga.

El responsable, tal y como lo entendemos en castellano, es el rol de Accountable. Como en la traducción de la matríz RACI se intenta conservar la inicial hay quien las gira y a la R le pone Responsable y a la A Asignado. Bueno, de esta manera el espíritu es el mismo, ya que tenemos dos roles equivalentes a los originales en inglés, pero cruzados. Yo no lo recomiendo, porque muchas veces se ponen las columnas como una inicial y puede llevar a confusión.

Así la R es de quien (o quienes) hace la tarea y la A del que es responsable de que se haga.

Accountable es un cerdo

¿Conoces la fábula del cerdo y la gallina?

060911-scrumtoon

En una tarea podemos distinguir dos tipos de stakeholders, los cerdos que están realmente comprometidos y las gallinas que sólo están involucradas. En una matriz RACI, la A es la del mayor de los cerdos. Es aquella persona que se juega realmente su jamón. Si se llega tarde o se entrega mal, a quien le darán la colleja será a la A.

A veces veo que esto se olvida y se plantea la A como la de un jefe que tiene que “Autorizar” la ejecución de la tarea, o el de un cliente que tiene que “Aceptar” el producto entregado. En castellano pasa todavía más, por esas ganas a darle un significado traducible a la A. Es posible que la A tenga que autorizar o aceptar esa tarea, pero lo importante no es eso. Lo importante es que si sale bien o sale mal es en última instancia responsabilidad de la A.

Cuando rellenes la matriz hay que preguntarse, ¿Si sale mal a quién van a colgar de la plaza? Pues esa es la A.

Accountable hay uno y sólo uno

Esto debe ser una regla de oro y no incumplirse nunca. Si no pones un responsable, nadie te asegura de que la tarea no caiga en el olvido y nadie se preocupa por que se haga de forma correcta. Sin un cerdo al mando, los pollos corren como si no tuviesen cabeza. De la misma manera si pones dos, se crearán ocasiones en las que no quede claro quién de los dos era el responsable de esa parte de la tarea que ha fallado. Y podemos llegar muy fácilmente a una situación en la que cada uno de los responsables pensase que el otro lo estaba controlando.

Por último, en la R, la C o la I podemos tener unidades organizativas, pero en la A deberíamos tener personas. Si ponemos una unidad, realmente estamos apuntando al responsable de esa unidad.

Responsable debe haber uno y sólo uno. Y el responsable, es la A.

Se debe consultar a la C, no es opcional

La C no es una lista de personas o departamentos que te pueden dar información sobre la tarea. Es más bien sobre personas o unidades que deben poder opinar o incluso autorizar la ejecución de la tarea. Si pongo al arquitecto de sistemas en la C no es para que le puedan preguntar si hay dudas, sino porque hay que contarle lo que se va a hacer para que él diga como se tiene que hacer. He visto poner en la C a páginas web o sistemas de información corporativos, como entidades que pueden dar información. Eso refleja un mal entendimiento del concepto C en la matriz RACI.

Hablamos de asignar responsabilidades. ¿Qué responsabilidad hay en ser el experto al que puedan preguntar? En la C encontraremos a personas que se ven impactadas por la tarea y tienen que poder opinar. A expertos que la organización considera que deben guiar a la ejecución de la tarea. Así por ejemplo en una tarea de desarrollo, en la C veremos a los usuarios clave de la apliación, a los clientes, al departamento de sistemas, al arquitecto de software, etc.

Existen dos maneras

Muy pocos artículos reflejan que la matriz puede representarse de dos maneras, por roles y por personas.

En ambas representaciones tenemos a las tareas en las filas, y las columnas y el contenido se intercambian:

  • En la matriz por roles las columnas son las cuatro letras y el contenido es cada una de las personas que ocupan ese rol en la tarea.
  • En la matriz por personas las columnas son las personas o departamentos involucrados, mientras que el contenido son las letras RACI.

Dependiendo de cada caso, una representación u otra puede ser mejor. Si lo que estamos reflejando es las tareas de un departamento, con un número limitado de actores, entonces lo mejor es hacerlo por personas. Así una persona ve fácilmente su posición en todas las tareas. En cambio si hablamos de unas pocas tareas transverales, con múltiples actores, entonces la matriz por roles es mejor opción.

Todo depende de si nuestro foco está en ver quién tiene que hacer qué en cada tarea, o que role cumple cada uno en cada tarea.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...

Diseñando el WBS

Uno de los grandes conceptos que aprendí de leer la guía del PMBOK® es el WBS, o Estructura de Descomposición de Trabajo. Pasé de una ...