Si pudiéramos generalizar los roles que asumen las personas involucradas en la gestión de proyectos dentro de cualquier organización ejecutora, ¿cuáles serían esos roles? Yo siempre digo que son 10 roles: 5 del lado de la gestión de la demanda y otros 5 del lado de la gestión del suministro. ¿Estás de acuerdo?
Con este artículo quiero validar esta regla a partir de vuestras opiniones. Os agradecería que pudiérais escribirme por email pulsando el siguiente enlace: Enviar correo con mi opinión
Según la Guía del PMBOK®, del PMI®, un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. Todo proyecto que ha de ser gestionado de forma profesional, no solo como una serie de tareas relacionadas, exige trabajar en equipo y que haya un responsable de terminar cumpliendo los objetivos de gestión de plazo, coste, alcance, calidad, etc. Así pues, ya sabemos que como mínimo hay dos roles imprescindibles: los encargados de hacer el trabajo en equipo (Team Members) y el encargado de coordinar al equipo y gestionar para cumplir los objetivos de gestión del proyecto (Project Manager).
Según la Guía del PMBOK®, el Project Manager es la persona nombrada por la organización ejecutora para liderar al equipo, siendo responsable de alcanzar los objetivos del proyecto.
Los Team Members son los individuos que respaldan al Project Manager en la realización del trabajo del proyecto para alcanzar sus objetivos.
Los proyectos no se hacen en el vacío. Si es un proyecto interno realizado con recursos propios, estos recursos pertenecerán a una unidad de negocio dentro de la organización. Si es un proyecto realizado para un cliente, el proveedor empleará recursos también desde un departamento o unidad de negocio de la organización proveedora. Cuando se trata de un proyecto cros-departamental, es buena práctica que una unidad de negocio encabece el liderazgo y la responsabilidad. Esto me permite concluir que siempre hay una unidad de negocio (Business Unit) responsable del proyecto, ejerciendo la persona responsable de esta unidad un tercer rol bien diferenciado, que podríamos llamar gerente funcional (Functional Manager).
El principal interés del Functional Manager consiste en aprobar y vigilar la utilización de sus recursos contra sus objetivos de negocio (o su cuenta de resultados). Según la Guía del PMBOK®, el Functional Manager es alguien con autoridad de dirección sobre una unidad de la organización dentro de una organización funcional. El gerente de cualquier grupo que efectivamente realiza un producto o presta un servicio. A veces se le denomina gerente de línea.
En gestión empresarial se acostumbra a utilizar terminología relacionada con la orientación al servicio cliente-proveedor para delimitar las funciones y los procesos corporativos. En gestión de proyectos también se suele utilizar esta terminología, gestión de la demanda y gestión del suministro, para especializar las funciones separando dos grupos: 1) los que piden o proponen proyectos (demand management) y 2) los que utilizan recursos para ejecutar proyectos (supply management).
Claramente, Project Managers y Team Members se encuentran en supply management. El rol Functional Manager lo veo en el lado demand management de los que piden/supervisan.
Expliquemos un poco mejor la función de project demand management:
En las organizaciones hay roles enfocados en gestionar la demanda de proyectos. Los posibles proyectos que se podrían proponer hay que saber cómo compararlos y priorizarlos, porque no tiene sentido hacerlos todos, ni se dispondría de los recursos necesarios. Estos gestores de la demanda no suelen utilizar la palabra “proyecto”, prefieren otras palabras como ideas, iniciativas, peticiones, inversiones, propuestas, etc. (en inglés: idea, initiative, request, investment, proposal, commercial bid, etc.). Los project managers suelen decir proyecto en estado de inicio para referirse a los proyectos que aún no se han autorizado, y esto suele ser confuso para el resto.
A mí me resulta útil usar la palabra Request para gestión de la demanda y Project para gestión del suministro (me estoy refiriendo a lo mismo, solo que nombrándolo de forma diferente). Incluso los estados del ciclo de vida de iniciativas y proyectos suelen entenderse mejor si los diferenciamos:
Podríamos identificar un cuarto rol específico, Requester, para referirnos a quien solicita proyectos, trabaja para que se aprueben y después necesita saber principalmente cuándo y cómo han acabado.
En las organizaciones que venden proyectos, el Requester no sería otro que el comercial que gestiona el ciclo de venta del proyecto. Por analogía, en las organizaciones cliente podríamos identificar este mismo rol para referirnos a la persona encargada de proponer proyectos internos. El rol Requester gestiona sus solicitudes de forma similar al Project Manager sus proyectos:
Es decir, el Requester puede etiquetar que una solicitud está propuesta si aún no se ha ganado/autorizado, en progreso si ya se está ejecutando, y cerrada si se ha completado. A veces se decide aplazar una propuesta esperando un momento más propicio para decidir. Cuando la propuesta se desestima o se pierde, puede marcarla como rechazada.
De forma simétrica, el Project Manager puede reconocer que el proyecto aún no se ha autorizado si está en estado inicio. Cuando el proyecto se autoriza, es útil distinguir dos estados: en planificación cuando aún no se pueden consumir recursos ni presupuesto y en ejecución en caso contrario. Cuando el proyecto pasa a estado cierre ya no se pueden imputar horas/gastos. Finalmente, cuando el proyecto se archiva se cierra el dossier y ya no se puede actualizar la información.
Continuemos ahora con el quinto rol, el gestor de recursos o Resource Manager:
En muchas organizaciones existe un rol particular para gestionar grupos de personas asignables a proyectos, normalmente denominado Resource Manager. Entre sus responsabilidades se encuentran gestionar el plan de capacidad para asegurar que hay recursos disponibles para atender las previsiones de los proyectos. El indicador que más importancia suele tener para ellos es la tasa de utilización, que deben mantener controlada entre ciertos umbrales según las categorías profesionales. También tienen responsabilidades compartidas con el departamento de RRHH: contratación, plan de carrera profesional, formación, incentivos, bajas, ausencias, etc.
El sexto rol sería el interesado, o Stakeholder:
Según la Guía del PMBOK®, un Stakeholder es un individuo, grupo u organización que puede afectar, verse afectado, o percibirse a sí mismo como posible afectado por una decisión, actividad o resultado de un proyecto.
Rol número 7, el patrocinador o Sponsor:
Formalmente, los proyectos son autorizados por el Sponsor. Según la Guía del PMBOK®, es una persona o grupo que provee recursos y apoyo para el proyecto, programa o portafolio y que es responsable de facilitar su éxito. Alguien de peso en la organización debe poner su firma en el acta de constitución para autorizar el proyecto. El sentido que tiene esa autorización es más o menos el siguiente:
“Nos hemos comprometido para gastar el dinero de la organización y el tiempo de ciertas personas de la organización para ejecutar este proyecto en lugar de otros propuestos, porque en el momento de tomar la decisión, este proyecto era más alineado, más rentable, más oportuno para los intereses de la organización.”
El octavo rol podría ser la PMO, también desde el lado de demand management porque ayudan con la carga administrativa cuando se lanza un proyecto:
Según la Guía del PMBOK®, la PMO es una estructura de la organización que estandariza los procesos de gobierno relacionados con el proyecto y facilita el intercambio de recursos, metodologías, herramientas y técnicas.
Aunque es discutible, el rol de la PMO lo veo en el lado de gestión de la demanda, más que en gestión del suministro, por 2 motivos:
- Hay muchos tipos de PMO, me gusta la simplificación que hace la Guía del PMBOK cuando hablan de PMO de soporte, de control y directiva. Creo que la PMO directiva sí estaría en suministro, pero los otros 2 tipos, que son los más habituales, me encajan más en gestión de la demanda: PMO de soporte facilita el trabajo de los PM y ahorran burocracia; PMO de control tiene como objetivo principal reportar los grandes indicadores y el resumen ejecutivo de los proyectos.
- Me gusta la distinción involucrado/comprometido (chicken/pig). La PMO puede llegar a ser muy influyente en los proyectos, pero “no se la juegan”.
Por otro lado, en el lado del supply management tenemos también dos roles orientados a gestionar programas y portafolios, que se definen así en la Guía del PMBOK®:
Un programa es un grupo de proyectos, subprogramas y actividades de programas relacionados cuya gestión se realiza de manera coordinada para obtener beneficios que no se obtendrían si se gestionaran en forma individual.
Un portafolio es un grupo de proyectos, programas, subportafolios y operaciones gestionados como un grupo para alcanzar los objetivos estratégicos.
Consecuentemente, habrá otros dos roles más en supply management: Program Manager y Portfolio Manager. Podemos observar una jerarquía entre PfM > PgM > PM dado que un proyecto puede pertenecer a un programa (o no), y a cero, uno o varios portafolios. A su vez, un programa puede incluirse en cero, uno o varios portafolios.
Resumiendo la interrelación de estos 10 roles en una sola frase:
El Project Manager puede reportar a un Program Manager o Portfolio Manager, pero necesita que los Team Members hagan las tareas técnicas, y a su vez los team members son gestionados por Resource Managers. Estos roles pueden encuadrarse en la gestión del suministro de proyectos. Por el lado de la gestión demanda de proyectos, tenemos Requesters que solicitan proyectos, Sponsors que los aprueban, Functional Managers que asumen la ejecución en sus business units, y también tenemos la PMO dando soporte administrativo y de control, y Stakeholders internos y externos a la organización ejecutora.
Según tu experiencia en gestión de proyectos, ¿qué te parece esta enumeración? ¿Echas en falta algún rol? Cualquier comentario será bienvenido. ¡Muchas gracias!