La gestión de las expectativas de un equipo de proyecto a menudo puede ser más difícil que gestionar las de los stakeholders externos. Los equipos “se forman, se enfrentan, se normalizan y se desempeñan”, pero los proyectos cortos y las tareas críticas pueden verse afectados por comportamientos no deseados, especialmente si los miembros del equipo no saben qué se espera de ellos. RACI y RACI-VS son formas de una Matriz de Asignación de Responsabilidades (RAM) que pueden ayudar a enfocar al equipo en sus roles y responsabilidades, al tiempo que ayudan al director del proyecto a pensar en el plan de Recursos Humanos. La Guía del PMBOK® incluye la Matriz de Asignación de Responsabilidades en el plan de Recursos Humanos. Está diseñada para mostrar las conexiones entre los paquetes de trabajo de la Estructura de Desglose del Trabajo (EDT) y el equipo del proyecto. Se pueden presentar múltiples niveles de RAM. Un RAM de alto nivel puede mostrar las conexiones entre paquetes de alto nivel (como fases del proyecto o tareas resumidas) y subequipos o recursos genéricos. En última instancia, el RAM conecta cada tarea con miembros específicos y nombrados del equipo.
Planificación de recursos
El RAM ilustrado es parte de la Herramienta de Estimación que desarrollé. La planificación se realiza por rol, esfuerzo y semana. Este y otros RAM similares todavía son demasiado generales para algunos equipos de proyecto. Es posible alcanzar otro nivel de detalle al utilizar el modelo RACI (Responsable, Responsable último, Consultado e Informado). La Guía del PMBOK® sugiere que un modelo RACI es importante para describir la interfaz entre múltiples equipos (por ejemplo, comprador/vendedor, interno/externo, gestión de productos/desarrollo/ventas y marketing). Las tareas en un eje, los recursos en otro, las celdas se completan con una de las letras. La Guía del PMBOK® no proporciona reglas sobre cómo crear gráficos RACI y hay poca literatura disponible, pero algunas cosas deberían ser obvias desde el sentido común: múltiples recursos “Responsables” y no relacionados pueden causar conflictos en diferencias de opinión. Asegúrese de que los miembros del equipo sean copresidentes, co-líderes o al menos tengan roles similares y colaboren bien juntos. Se deben mantener al mínimo los “Responsables” múltiples. El rol “Responsable” define quién realiza el trabajo. Múltiples “Responsables” pueden causar trabajo innecesario o duplicado. Asigne a un miembro del equipo la responsabilidad de cada tarea. Mantener a varias personas “Informadas” ayuda a desarrollar capacidad. Si un miembro del equipo está ausente o no puede llevar a cabo el trabajo por cualquier motivo, ha desarrollado un sucesor para ese rol. Es deseable tener múltiples “Consultados” para recopilar aportes de todos los posibles expertos en la materia. En general, cada miembro del equipo debe tener solo un rol. Si alguna columna está vacía, considere si ese recurso es necesario para el proyecto.
Matriz RACI
RACI-VS (VS significa “Verificación” y “Aprobación”) no está en la Guía del PMBOK®, sin embargo, lo encontré en muchas referencias. Habiendo trabajado con empresas maduras (nivel 3 y superior de SEI), puedo ver su importancia. Alguien necesita asegurar la calidad, realizar pruebas de aceptación o confirmar de alguna otra manera que una tarea esté completa. La aprobación final actúa como una puerta que impide que el trabajo incompleto avance. El entorno de desarrollo en GE Information Services fue un ejemplo clave. Una vez que se codificaba un cambio, cada desarrollador debía buscar a un compañero con experiencia en el tema para revisar el cambio de código. Los comentarios podrían incluir sugerencias de mejora de rendimiento, cumplimiento de estándares de codificación, sugerencias de pruebas unitarias y otros trabajos que debían examinarse para su integración. Una vez que se completaba la verificación, el cambio se enviaba a la dirección para su aprobación. El gerente de desarrollo podría preguntar sobre posibles problemas o las pruebas realizadas antes de la aprobación. Una vez más, se deben considerar algunas reglas de sentido común: para muchos proyectos, el rol de “Aprobación” también puede asignarse a la persona “Responsable” para brindarle la oportunidad de asegurarse de que se cumplan los estándares del proyecto y se sigan los procesos. Demasiadas aprobaciones pueden causar retrasos a medida que el producto de trabajo se envía para su revisión. La “Verificación” debe ser independiente (por ejemplo, un arquitecto que creó un cambio no debe verificar el cambio) siempre que sea posible para garantizar la máxima calidad. La “Verificación” a menudo designa el rol de aseguramiento de calidad o verificación del alcance del proyecto. Los roles de verificación y aprobación pueden ser adicionales a otros roles.
Aplicaciones de RACI y RACI-VS
Existen múltiples formas en las que se pueden aplicar los conceptos de RACI y RACI-VS:
- Se pueden utilizar como designaciones ideales para roles y responsabilidades en una definición o gráfico de procesos. Si se asigna R=Recomienda y A=Aprueba, se tiene la base para un proceso de toma de decisiones.
- CAIRO o RACI-O agrega “O”ut-of-the-Loop como un rol, alguien que no necesita estar involucrado en una tarea en absoluto.
- RASCI agrega “S”oporte.
La Guía del PMBOK® define la Matriz de Asignación de Responsabilidades como parte del plan de Recursos Humanos para un proyecto. Ayudan al director del proyecto a establecer expectativas para roles y responsabilidades, así como a planificar los recursos del proyecto. RACI y RACI-VS son formas de una RAM y pueden ser de varios niveles. Definen quién es responsable, responsable último, consultado, informado, verifica y aprueba las tareas del proyecto. Hemos analizado algunas reglas de sentido común, como asegurarnos de que solo una persona sea responsable de cada tarea para evitar trabajo redundante o esfuerzo desperdiciado. También hay múltiples formas en las que se puede aplicar el concepto y hemos analizado cuatro aplicaciones diferentes.
Ray W. Frohnhoefer, MBA, PMP es el Director de la Oficina de Apoyo a Proyectos en EDmin, así como consultor, conferencista, escritor, educador y mentor en Gestión de Proyectos. Ray actualmente forma parte del Comité de Gobernanza de Relaciones con Componentes y Comunidades del Project Management Institute, fue Mentor de Componentes para la Región 7 de PMI (Suroeste de América del Norte), fue Presidente de PMI, Capítulo de San Diego, Inc., y es miembro docente adjunto en tres universidades de San Diego. Puede obtener más información sobre sus roles profesionales en http://www.edmin.com/company/index.cfm?function=showBioDetail&id=80 y a través de su blog, The Project Notebook, en http://projectnotebook.blogspot.com.
