Deja de señalar con el dedo—Usa una matriz RACI (con Suze Haworth)

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts con un programa de software. Por favor, disculpa los posibles errores ya que el bot no es 100% preciso.

Ben Aston:

Quizás una de las cosas más complicadas de gestionar proyectos es que tenemos que trabajar con... bueno, personas. Y las personas pueden ser increíblemente variables. Somos inconsistentes, egocéntricos, poco fiables e increíblemente volubles, y solo estoy hablando de mí mismo. Así que me pregunto si tus proyectos son un poco como los míos. Cuando las cosas salen mal, y claro, en algún momento lo hacen, puede convertirse rápidamente en un ejercicio horrible de señalar con el dedo, donde parece que todo el mundo acusa a los demás de no hacer su trabajo correctamente. Así que, ¿cómo podemos gestionar un proyecto cuando tenemos todo eso en contra? Pues hoy lo vas a descubrir.

Gracias por sintonizar. Soy Ben Aston y este es el pódcast de Digital Project Manager. Este pódcast es traído a ti por Clarizen, líder en software de gestión de proyectos y portafolios empresariales. Visita Clarizen.com para saber más. Hoy me acompaña Suze Haworth, una de nuestras expertas DPM en The Digital Project Manager. Suze, muchas gracias por acompañarnos en el programa.

Suze Haworth:

Gracias, Ben, gracias por invitarme.

Ben Aston:

Déjame presentar bien a Suze, porque es nueva. Creo que este es nuestro primer pódcast juntos.

Suze Haworth:

Sí.

Ben Aston:

Suze es directora de proyectos digitales freelance en Londres y cuenta con mucha experiencia, lleva más de 13 años en la industria, comenzó en gestión de cuentas —igual que yo— y luego pasó a gestión de proyectos. Pero en vez de leer tu biografía, Suze, ¿puedes contarnos un poco sobre el tipo de proyectos en los que trabajas actualmente?

Suze Haworth:

¿Ahora mismo? Pues, de hecho, el año pasado me pasé al mundo freelance, así que he estado trabajando, como tú decías, muchos años en diversas agencias, pero el año pasado empecé por mi cuenta. En este momento tengo un puesto en una agencia de Londres y gestiono dos grandes proyectos: uno es un sistema de diseño para una gran empresa minorista, y el otro es la gestión de un programa de trabajo para otra marca minorista. Está siendo todo bastante interesante.

Ben Aston:

¿Entonces lo tuyo es el retail?

Suze Haworth:

En realidad es muy variado. He trabajado mucho en retail, una cadena de televisión, una ONG, de todo un poco, pero sí, hay un fuerte enfoque en retail en los proyectos que llevo ahora mismo, así que se podría decir que sí.

Ben Aston:

Genial. En tu rol como freelance, ¿qué encuentras más difícil? ¿Cuáles son los mayores retos que enfrentas ahora?

Suze Haworth:

Creo que el mayor reto —y esto siempre pasa a los project managers, hablo desde la experiencia— es que tienes muchas cosas distintas que gestionar y de las que eres responsable. No solo tratar de entregar el proyecto con éxito, sino también gestionar los tiempos, el presupuesto, los entregables del equipo, a los propios miembros del equipo, así que también gestionas muchos problemas de equipo y, por supuesto, el trato con el cliente. Así que es muy difícil compaginar tantas cosas con el tiempo disponible. Muchas veces siento que es una batalla constante para meterlo todo en un día.

Ben Aston:

Sí. ¿Te resulta más difícil por haber pasado de un puesto fijo a este rol como contratista, notas diferencia? ¿Cómo lo vives?

Suze Haworth:

Sí, es algo diferente en el sentido de que como freelance eres más dueño de tu tiempo, en cuanto a cómo cobras a la agencia. No puedes ponerte en una posición en la que sientas que no puedes decir que no. Creo que una cosa que he aprendido a hacer mejor es eso: si tienes demasiado en tu plato, solo puedes con cierta carga y necesitas hacerlo bien, así que lo mejor es, en vez de decir sí a todo, es poner límites y saber decir no.

Ben Aston:

Cuando fui contratista también me di cuenta de eso. Hay algo realmente bueno en ser freelance porque puedes... bueno, no estás pensando en ascensos. Claro, quieres mantener el contrato, pero no intentas impresionar a nadie como cuando eres fijo y piensas "Mejor digo que sí, o daré una mala imagen".

Suze Haworth:

Sí, exacto. Pero igual quieres dar buena impresión, claro. El sector es pequeño, todos se conocen, pero no, creo que está bien poder tomar una distancia al final del día y decir: "Vale, mi jornada ha acabado", cosa que a veces es más difícil trabajando fijo.

Ben Aston:

Desde que eres freelance, ¿en cuántos lugares diferentes has trabajado?

Suze Haworth:

Solo en un par, de hecho, porque no llevo tanto tiempo así. Es positivo porque he podido pasar tiempo suficiente en la agencia donde estoy ahora y conozco bien a la gente. Conozco mejor a los clientes porque paso más tiempo en los proyectos y las cuentas.

Ben Aston:

¿Trabajas en la oficina o mayormente en remoto?

Suze Haworth:

No, en la oficina. La verdad, siempre recomiendo los beneficios del trabajo remoto a todos quienes conozco porque creo que es importante y puede ser mucho más productivo, pero en muchas agencias, especialmente en Londres, se sigue trabajando sobre todo en la oficina.

Ben Aston:

Interesante. Sé que además de ser freelance y hacer trabajos por contrato, también escribes. Has escrito cosas para DPM, y además asistirás al Summit de DPM este año. ¿Puedes contarnos un poco de eso?

Suze Haworth:

Sí, claro. Me ilusiona mucho. El año pasado hablé en el DPM Summit en Las Vegas y este año dirigiré un taller. Es un tema bastante interesante, porque como PMs somos obsesivos con las metodologías, especialmente las metodologías ágiles. Voy a hablar sobre enfoques híbridos, en concreto algo que he estado implementando en un programa de trabajo actuales: el enfoque de doble vía o Dual-Track. Utiliza aspectos de Agile pero de manera combinada. Hablaré de eso, de Kanban, Lean y sobre cómo se pueden mezclar distintos enfoques para tus proyectos, sin ser necesariamente un método puro Agile o puro de otro tipo, sino adaptando metodologías existentes.

Ben Aston:

Eso está genial. Además es muy importante. Suze es una de nuestras expertas DPM y participará en nuestro curso de Maestría en Gestión de Proyectos Digitales. Si no sabes qué es-

Suze Haworth:

Sí, estaré allí.

Ben Aston:

De hecho, será este viernes, así que será la primera aparición de Suze. Una de las cosas que hablamos en el curso es no obsesionarse demasiado con el nombre de la metodología o lo que-

Suze Haworth:

Exacto.

Ben Aston:

Al final se trata de entregar el trabajo y encontrar las mejores formas de hacerlo para el equipo, el proyecto y el cliente, y ser pragmáticos, no dogmáticos. No importa si no es Scrum puro. Lo importante es entregar el proyecto.

Suze Haworth:

Justo, eso pienso. A menudo somos demasiado obsesivos con el proceso, pero realmente necesitas ver tu proyecto o producto y pensar: "¿Qué funcionará aquí?" Y eso varía mucho entre proyectos, hay que saber adaptarse y combinar.

Ben Aston:

Sí, totalmente. Hay quienes desprecian mezclar metodologías puras, pero yo nunca he visto funcionar una única.

Suze Haworth:

No, exacto. Hay mucho esnobismo sobre enfoques favoritos, pero estoy abierta a usarlos todos. En el mundo de las agencias casi siempre hay que combinar procesos y no uno puro, por los contextos.

Ben Aston:

Sí, sin duda. Además de tus charlas y artículos, ¿te has fijado metas personales para este año, algo que quieras mejorar?

Suze Haworth:

Vaya, esa es difícil. Ahora mismo estoy tan enfocada en el presente, en lo que hago dentro y fuera del trabajo, que me cuesta pensar a largo plazo. Pero sí, una gran cosa que mencioné antes es aprender a decir no. Quiero mejorar delegando y soltando un poco de responsabilidad, algo que siempre me ha costado. Como PM a veces eres un poco controladora con las cosas, así que ese es un objetivo a largo plazo para mí.

Ben Aston:

Delegar es difícil, sobre todo como freelance, cuando no sabes si la persona a quien delegas te tomará en serio, porque tú eres externa, y porque no tienes historial con ellos y no sabes si podrán hacer lo que intentas delegar.

Suze Haworth:

Eso es.

Ben Aston:

Hablemos un poco de herramientas, porque seguro que al trabajar en diferentes sitios conoces muchas. ¿Alguna que últimamente te haya facilitado la vida y que creas que todos deberían conocer?

Suze Haworth:

La verdad es que como freelance y por trabajar en tantas agencias, incluso en puestos fijos, acabas usando muchas herramientas y te adaptas a lo que usan en la empresa. Yo nunca he encontrado la herramienta ideal que haga todo lo que quiero o sin problemas. Así que no diría que hay una perfecta. Herramientas de recursos y para controlar horas he usado muchas y en todas veo cosas buenas y malas. La única herramienta que realmente me encanta —si puede llamarse así— son las hojas de cálculo de Google. Porque puedes usarlas para casi todo, o para muchas cosas diferentes.

Ben Aston:

¿Has probado usar Monday.com?

Suze Haworth:

No, la verdad que no.

Ben Aston:

Como a ti te gusta gestionar cosas en hojas de cálculo, creo que Monday puede ser...

Suze Haworth:

Soy una friki.

Ben Aston:

La ventaja de las hojas de cálculo es que son gratis, al menos Google Sheets, y muy flexibles. Pero creo que Monday añade automatización y mucho poder en control y filtrado. Deberías probarlo. Es como hojas de cálculo mejoradas.

Suze Haworth:

Vale, le echaré un ojo, seguro. Me viene perfecto.

Ben Aston:

Perfecto. Ahora hablemos de tu artículo. Hace un tiempo que lo escribiste, pero volviendo al tema, ¿cómo gestionamos a las personas que quieren tomar el mando en un proyecto o que no quieren ninguna responsabilidad? El artículo de Suze trata de cómo usar la matriz RACI para esto. Para quien no lo haya leído todavía, cuéntanos qué es una matriz RACI. ¿Qué significa RACI?

Suze Haworth:

RACI significa responsable, aprobador, consultado e informado, así de simple. Es una matriz donde mapeas las tareas o entregables de un proyecto con los stakeholders o miembros internos del equipo, y asignas una de las cuatro letras —o roles— a cada persona y cada tarea. Es decir, alguien es responsable, alguien aprobador, alguien consultado y otro informado. Es una forma estupenda de asignar la responsabilidad de cada tarea o entregable y garantizar que no haya demasiadas personas involucradas en cada decisión, teniendo claro quién hace qué durante el proyecto.

Ben Aston:

Genial. Suele haber confusión sobre quién debe estar informado o consultado, pero donde suele haber más confusión es entre ser responsable y ser aprobador. ¿Cómo gestionas eso y evitas que haya gente que quiera ser responsable pero no aprobador? Cuéntanos cómo lo haces.

Suze Haworth:

Sí, creo que este es el mayor reto de la matriz RACI y yo misma he tenido muchos problemas con esto en el pasado. Por eso la matriz RACI puede volverse complicada, porque pasas mucho tiempo pensando: ¿qué significa realmente? ¿Qué implica para la persona que asuma ese rol? Pero para simplificar, responsable es quien hace la tarea, crea el entregable o lo gestiona; es la persona que hace. El aprobador es quien debe revisar y aprobar la tarea, es decir, supervisarla, pero no hacerla.
Otra dificultad entre responsable y aprobador surge porque, si tienes un project manager o un product owner, sueles asignarles la aprobación porque son el punto central. Pero realmente hay que pensar si no hay alguien más apropiado —por ejemplo, si es diseño, ¿debería ser el director creativo? ¿El director creativo interno o el del cliente? Se trata de no poner siempre el peso en el project manager o product owner.

Ben Aston:

Eso es clave. El error común es hacer que todos sean responsables y aprobadores, no solo el project manager. Pensamos "todo el mundo debe ser responsable de esto, o tener responsabilidad colectiva".

Suze Haworth:

Totalmente. Es difícil porque sientes que todos los miembros del equipo harán la tarea y habrá cinco responsables. Pero de verdad hay que ser precisos y restringir, porque si repartes los roles entre todos, nunca conseguirás realmente para lo que sirve la RACI: definir puntos claros de contacto o de aprobación. Así que hay que usarla bien.

Ben Aston:

Creo que el reto no suele ser definir quién hace el trabajo, sino diferenciar entre consultado e informado. Porque lo que mucha gente confunde es la diferencia entre ser aprobador y consultado. Como decías, queremos que haya una sola persona que apruebe, la que tenga la última palabra en si algo es válido, casi como control de calidad. Puede haber más consultados y aún más informados; estos últimos solo están copiados en la información.
Los consultados, para mí, pueden llegar a desviar el proyecto porque son quienes tienen voz, aunque no sean responsables de la entrega o el plazo, pero sí tienen poder de opinar. Así que la tensión real es entre el aprobador y el consultado, y el juego de poder entre quienes quieren opinar, pero no se hacen responsables del resultado final.

Suze Haworth:

Sí, y además está la dificultad de que los consultados, como les hemos dado un rol, asumirán que tienen que opinar. Por eso el aprobador es clave, porque debe asegurarse de que los consultados aporten pero no desvíen el proyecto con interminables rondas de feedback.

Ben Aston:

Y siendo honestos, la matriz RACI puede volverse muy extensa. Has puesto un gran ejemplo con "El Señor de los Anillos" de cómo sería una matriz así para ese proyecto. Pero, ¿es un documento que usas siempre en tus proyectos? ¿Cómo evitas llenarlo de detalles y que se vuelva una lista de tareas con nombres?

Suze Haworth:

Soy muy partidaria de no crear documentación por crear. Si haces una matriz RACI, debe ser útil y usarse. No se trata de crearla al inicio y dejarla olvidada en el servidor. Hay que consultarla de verdad mientras avanzas con los entregables y, al final, en la revisión del proyecto, valorar si funcionó. Hay que usar la herramienta para que sea útil.

Ben Aston:

Explícame un escenario donde saques la RACI. ¿La usas en reuniones de estado, diciendo: en la próxima semana haremos esto y esto, veamos quién es responsable y quién aprobador, y a quién consultaremos o informaremos? ¿Cómo la aplicas semana a semana?

Suze Haworth:

No siempre la uso en los estados. Te indica a quién acudir, a quién involucrar, a quién enviar entregables o asignar tareas. Pero suelo usarla de referencia interna para recordar quién está implicado en cada tarea, a quién pedir feedback y a quién informar una vez entregada. Es mi referencia interna, pero si algo no va bien lo marco.
Y ahí es útil cuando, por ejemplo, asignas el rol de consultado a alguien, pero de repente todos los stakeholders quieren involucrarse. Entonces puedes hablar con tu contacto principal del cliente y recordarle: "Esto fue lo que definimos juntos al inicio, sigamos el proceso para crear eficiencia y no añadir retrasos".

Ben Aston:

Entonces, ¿tu matriz RACI abarca tanto a la agencia como al cliente, o tienes dos matrices?

Suze Haworth:

He usado ambos enfoques. Depende del proyecto: si tienes dos grandes equipos puede ser útil hacer dos matrices. Últimamente creo más una para el cliente cuando hay muchos stakeholders, para saber a quién involucrar y cuándo. Nuestro equipo suele ser más compacto, así que lo agrupo como uno solo y asumo ciertas responsabilidades, aunque muchas están de su lado. Así que cada caso es diferente, hay que adaptarlo. Lo principal es que la RACI sea útil: si tu proyecto es pequeño y con pocos actores, posiblemente ni la necesites. Solo cuando hay muchos stakeholders, internos o clientes, puede ser clave definir roles. Tienes que adaptarlo al proyecto.

Ben Aston:

La matriz RACI es estupenda para evitar que las cosas se caigan entre grietas y que la gente diga luego: "No me pidieron opinión", o "Pensé que diseño hacía las anotaciones". En mi experiencia, no es necesario que el cliente vea todo el proceso interno, eso puede confundir más; pero sí es útil para gestionar al cliente, sobre todo si es una organización política o que tiene dificultad decidiendo.
La clave es identificar a la persona que es aprobador y decir: "Recuerda al inicio del proyecto cuando acordamos que tú ibas a ser el responsable de aprobar, ¿sigue siendo así? Porque si no, habrá que ajustar el proceso, los tiempos y posiblemente el presupuesto".

Suze Haworth:

Por supuesto. Y por eso es tan importante implicar a los clientes o al equipo interno en la creación de la matriz. No basta con hacerla tú y enviarla para que la aprueben. Si no la piensan, solo dirán "vale, sigamos”, pero si participan desde el principio, todos tendrán claro su función.

Ben Aston:

En tu experiencia, ¿cuándo deja de funcionar una matriz RACI? ¿Qué señales o banderas rojas pueden indicar que algo va mal?

Suze Haworth:

Creo que hay tres cosas principales: si no consigues el acuerdo de todos desde el inicio (o asignas roles sin que lo sepan o lo acepten); si solo haces hipótesis sobre el rol de los clientes y luego lo presentas como hecho. Hay que captar el compromiso de todos, sobre todo quienes van a ser responsables o aprobadores.
Segundo, hay que usarlo de verdad y revisarlo durante el proyecto y al final ver si sirvió, ajustarlo si no. Si no, será solo burocracia sin impacto.

Ben Aston:

Quería preguntarte: sabemos cómo crear la matriz y lograr el compromiso. Sabemos cuándo puede descarrilar. ¿Pero qué hacer cuando ya ha fallado? Es la realidad de los proyectos: pensamos que hemos definido roles, incluso los hemos documentado, pero aún así surgen problemas, se cuelan cosas y la gente se enfada. ¿Cómo vuelves a controlar la situación?

Suze Haworth:

Puede ser tentador usar la matriz como amenaza si las cosas se tuercen (“tú aceptaste esto”), pero no va de eso, sino de recordar que creamos la matriz para mejorar la eficiencia y establecer expectativas, y que no seguirla añade trabajo y complicaciones.
Hay que hablar con las personas que lo están complicando o desviando y explicarles el impacto que tiene no seguir lo acordado y por qué era útil definirlo claramente.

Ben Aston:

Sí, a veces hay que ayudar a la gente a recordar la razón por la que definimos las cosas desde el principio, para que cada uno recuerde dónde aporta (o no). "Ah, por eso no soy quien aprueba esto, porque no tengo experiencia en este área".

Suze Haworth:

Y eso te obliga a que la matriz tenga realmente un propósito: hay una razón de eficiencia (por tiempo, presupuesto, etc.). Si no hay un motivo práctico al crearla, no servirá de mucho. Es solo burocracia. Así que siempre tiene que haber beneficios reales y claros.

Ben Aston:

Es difícil. Si quieres descargar una plantilla de RACI, Suze ha creado una para nosotros, y también un buen ejemplo usando "El Señor de los Anillos" para explicar cómo podría aplicarse a un proyecto. Un dato curioso: cuando enviamos el correo "Suze ha escrito este artículo, y tenemos este ejemplo basado en 'El Señor de los Anillos'" alguien me contestó: "No puedo creer que estés perdiendo nuestro tiempo con esto". Me mandó un correo sarcástico. No respondí, pero para mi sorpresa, al día siguiente me respondió: "Luego leí el artículo y está genial. Solo que no me gusta 'El Señor de los Anillos'".

Suze Haworth:

Ya, es algo muy concreto. Y cuando hice esa matriz de 'El Señor de los Anillos', pensé: "Seguro que me equivoco en algo". Así que, en realidad, estaba haciendo yo misma justo lo que digo que no hay que hacer. Pero me sirvió para dar un ejemplo más fácil de imaginar.

Ben Aston:

La parte buena fue que al menos la gente podía imaginarse ese proyecto de llevar el Anillo. Es polémico, pero creo que está genial. Suze, muchísimas gracias por acompañarnos, ha sido un placer.

Suze Haworth:

Gracias.

Ben Aston:

Si quieres sumarte a la conversación, comenta en la publicación o visita la sección de Recursos de TheDigitalProjectManager.com para unirte a nuestro equipo de Slack, donde encontrarás todo tipo de conversaciones interesantes. Y si quieres escuchar más de Suze, consulta la sección de Formación y apúntate a nuestro próximo curso de maestría en gestión de proyectos digitales, donde Suze participará. Hasta la próxima, gracias por escuchar.