Individuos e interacciones sobre procesos y herramientas (en Proyectos) 

Los proyectos han existido siempre. Desde el comienzo de la historia, las personas se han organizado para convertir las ideas en realidad. Ideas tan retadoras como construir una gran pirámide, una gran muralla, un gran canal para unir océanos, la primera bomba atómica, poner un hombre en la luna, un telescopio para fotografiar el big bang, una vacuna para salvar al mundo, etc. Todas estas ideas se han hecho realidad gracias a los proyectos.

Podemos decir que la gestión de proyectos es una disciplina relativamente joven. Hace poco más de 50 años, los expertos se dieron cuenta de que no se podían gestionar los proyectos con las mismas técnicas que las operaciones. Se llegó al consenso de que se requerían una serie de procesos para lograr que los proyectos terminasen a tiempo, en coste, entregando el valor y cumpliendo los objetivos de gestión, para después transicionar el producto, servicio, o resultado final, a las operaciones del día a día.

Independientemente del sector, todos los proyectos se parecen en que hay que justificarlos, planearlos, ejecutarlos, controlarlos y cerrarlos. Profesionales expertos de talla mundial comenzaron a debatir buenas prácticas para gestionar requisitos, alcance, tiempo, coste, calidad, recursos, comunicaciones, riesgos, adquisiciones, interesados, etc. Se publicaron marcos estandarizados de procesos para la gestión de proyectos y comenzó a diferenciarse y especializarse la disciplina de project management.

Hoy día, las ideas son más retadoras y en consecuencia, los proyectos para convertirlas en realidad se hacen cada vez más complejos. Hay proyectos para que los ordenadores piensen por nosotros, para conseguir ordenadores mucho más rápidos, para conducir sin conductor, para combatir el cambio climático, para hacer viable la energía de fusión, colonizar Marte, etc. En estos proyectos trabajan cientos de personas al mismo tiempo, de forma coordinada, desde lugares muy distantes. Sin ir tan lejos, en las empresas donde trabajamos, los proyectos están por todas partes. Si eres lo que se denomina un trabajador del conocimiento, lo más normal es que cada día tengas varias reuniones para participar en varios proyectos que se ejecutan simultáneamente.

Los proyectos de hoy día exigen una gestión excelente. En las empresas, la gestión de los proyectos marca la diferencia para adelantar a la competencia, conquistar nuevos mercados, innovar, crecer, etc. La gestión deficiente de proyectos perjudica seriamente a las empresas (caso Bard) mientras que la gestión excelente sube el valor de la acción (Microsoft).

La mayoría de los proyectos de hoy día requieren:

• Planificación gradual: Los requisitos no están claros y el alcance hay que refinarlo interaccionando continuamente con los interesados.
• Ir más allá de la triple restricción: No es tan importante controlar los cambios, el tiempo y el coste como entregar el valor y cumplir los objetivos del negocio.
• Governance en tiempo real: Los jefes necesitan tomar decisiones informadas anticipándose a los problemas, mientras todavía hay opciones factibles para corregir el desempeño, pero no tienen tiempo para leer documentos extensos sobre decenas o incluso centenares de proyectos en ejecución. Las PMOs deben orientarse al valor.
• Gestión inclusiva: No es eficaz centralizar la gestión en una persona: la gestión ha de ser colaborativa porque las soluciones suelen llegar del interesado más inadvertido. Hay que involucrar en la gestión a personas que no son profesionales en proyectos.

Hoy día podemos decir que la gestión de proyectos profesional ha cambiado documentos por resultados, y da menos importancia a los procesos que a las personas. Las pruebas más claras las encontramos en la nueva edición del PMBOK, que ya no se basa en procesos sino en principios y en dominios de desempeño.

La gestión profesional de proyectos de hoy día ya no es eficaz si se realiza de forma aislada (un equipo que lo hace todo) o puntual (reuniones, informes). Las demandas de colaboración entre los diferentes interesados deben satisfacerse continuamente para lograr los objetivos de gestión del proyecto (calidad, alcance, tiempo, coste, etc.). En este mundo digital hiperconectado, las personas necesitan colaborar en línea para tomar decisiones informadas y proponer acciones proactivamente. Los proyectos necesitan este tipo de colaboración distribuida, especialmente.

Cualquier herramienta que aspire a unificar la gestión profesional de los proyectos en las empresas, debería adaptar las funcionalidades a los diferentes perfiles para que solo accedan a la información útil y necesaria de forma efectiva. Este ha sido sin duda el mayor reto al que nos hemos enfrentado en PMPeople y lo que ha provocado más cambios desde que comenzó el desarrollo en 2015.

Los distintos roles intervinientes en la gestión profesional de proyectos pueden dividirse en dos grupos:

• Demand Management: Las personas que proponen proyectos y se interesan en su seguimiento.
• Supply Management: Las personas que utilizan recursos materiales y humanos para ejecutar proyectos.

Como se explicaba detalladamente en este artículo, los roles de la gestión profesional de proyectos pueden definirse como sigue:

• Stakeholder (SH): 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.
• Requester (RQ): Persona que solicita proyectos. Trabaja decididamente para que se autoricen, y después da seguimiento al progreso y tiene el mayor interés en su conclusión exitosa.
• Sponsor (SP): Persona que provee recursos y apoyo para el proyecto, programa o portafolio y que es responsable de facilitar su éxito.
• Functional Manager (FM): Persona con autoridad de dirección sobre una Business Unit (BU). Todo proyecto se gestiona en el ámbito de una BU. Aunque en un proyecto participen recursos de distintas BUs, es buena práctica que solo una de ellas sea identificada para la rendición de cuentas.
• Project Management Office (PMO): Persona o grupo de personas que estandariza los procesos de gobierno relacionados con el proyecto y facilita el intercambio de recursos, metodologías, herramientas y técnicas.
• Project Manager Assistant (PMA): Persona o grupo de personas que ayuda al Project Manager en el ejercicio de sus funciones diarias.
• Portfolio Manager (PfM): Persona asignada por la organización ejecutora para autorizar, equilibrar, monitorizar y controlar los componentes del portafolio, a fin de conseguir los objetivos estratégicos.
• Program Manager (PgM): Persona autorizada por la organización ejecutora para dirigir al equipo o los equipos responsables de conseguir los objetivos del programa.
• Resource Manager (RM): Persona con autoridad de dirección sobre un Resource Pool, responsable de gestionar a los Team Members dentro del pool, llevando a cabo tareas de contratación, gestión de carrera profesional, formación, políticas de incentivos, gestión de bajas, ausencias, etc.
• Team Members (TM): Persona encargada de desarrollar el trabajo en equipo a fin de cumplir los objetivos del proyecto.
• Project Manager (PM): Persona nombrada por la organización ejecutora para liderar al equipo, siendo responsable de alcanzar los objetivos del proyecto.

Pasemos ahora a describir cómo los diferentes roles colaboran en una organización proyectizada. La siguiente tabla nos sirve para resumir los principales objetos en nuestra herramienta PMPeople, así como quiénes pueden crearlos, modificarlos o eliminarlos.

Por ejemplo, el objeto proyecto puede ser creado/modificado/eliminado (Create/Update/Delete = CUD) por un Functional Manager. Sin embargo, un Portfolio Manager no puede crear ni eliminar, solo modificar la información del proyecto (Update = U). En cuanto al Project Manager, puede crear y modificar proyectos, pero no eliminarlos (Create/Update = CU).

Veamos, a continuación, algunos casos de uso representativos en nuestra herramienta PMPeople.

El Functional Manager (FM) es el “dueño” de una o varias Business units (BUs):

• El FM puede crear una nueva BU.
• El FM puede parametrizar los datos de la BU. Estos datos se usarán desde todos los proyectos que se ejecuten dentro de dicha BU, incluyendo: calendarios laborales, clientes, fases, etiquetas, tipos de gastos, medios de pago, criterios de desempeño de proyectos, etc.
• El FM puede crear proyectos dentro de su BU.
• El FM puede asignar al patrocinador o Sponsor (SP) y al Project Manager (PM) de cada proyecto.
• El FM puede ejercer un control del proyecto supervisando la información actualizada por otros roles gestores, como el PM (también PMO, PMA, PfM, PgM).

En la siguiente captura de pantalla pueden observarse algunas funcionalidades accesibles por el FM sobre un proyecto concreto:

El Project Manager (PM) puede gestionar los proyectos que le han sido asignados, o bien los que él mismo ha creado:

• El PM puede iniciar el proyecto: completar los datos de definición del proyecto, inclusión en un programa y/o portafolios, integración con otras herramientas, elaboración del caso de negocio, acta de constitución, registro de interesados, etc.
• El PM puede asignar al RQ (Requester), SP (Sponsor), y uno o varios PMA (PM Assistant).
• Los PMA asignados podrán ayudar al PM a gestionar el proyecto.
• El PM puede planificar el proyecto: alcance, entregables, requisitos, fechas, reuniones de seguimiento, hitos, costes, plan de financiación, tareas, asignación de recursos, etc.
• El PM puede invitar a ciertos interesados. El registro de interesados puede incluir algunos interesados que deben acceder al proyecto a través de la herramienta. Estas personas podrán acceder en línea a cierta información de planificación y control.
• El PM puede poner el proyecto en estado de ejecución. Los Team Members podrán ver sus asignaciones, reportar horas y gastos. En distintas fechas de seguimiento, planificadas o sobrevenidas, el PM controla el estado del proyecto midiendo las desviaciones contra las líneas base, redactando la información relevante para los interesados, gestionando cambios, etc.
• El PM puede controlar los recursos, aprobando o rechazando imputaciones, replanificando tareas, horas, etc.
• Finalmente, el PM puede poner el proyecto en estado de cierre. Los TMs ya no podrán imputar horas ni gastos.
• Cuando se hayan completado los procesos de cierre, el PM puede poner el proyecto en estado archivado. A partir de entonces, el PM ya no podrá modificar la información del proyecto (PMA y PMO pueden volver a poner proyecto en estado closing si hay que hacer algún cambio).

En la captura de pantalla pueden observarse algunas funcionalidades accesibles por el PM sobre un proyecto concreto:

El Resource Manager (RM) es el “dueño” de uno o varios Resource Pools:

• El RM puede crear un nuevo Resource Pool e incluir a los Team Members (TM).
• Por su parte, un TM puede auto incluirse proactivamente dentro de un Pool de Recursos.
• Para asignar un TM a un proyecto, el PM debe buscarle dentro de un pool.
• El TM también puede unirse proactivamente a un proyecto si conoce un código privado.
• El TM puede ver las asignaciones de trabajos dentro de proyectos en ejecución. Puede saber qué otros TM trabajan en las mismas asignaciones, reportar horas trabajadas y gastos incurridos. También pueden enviar comentarios al PM sobre el proyecto, de forma anónima o no, así como información sobre su estado ánimo en el trabajo (de forma anónima), o cual será muy útil a la hora de hacer retrospectivas.
• El PM puede controlar los gastos y horas trabajadas provenientes de los TMs, sus progresos en tareas, etc.

En la siguiente captura de pantalla pueden observarse algunas funcionalidades accesibles por el RM sobre un Team Member de uno de sus Pools:

En la siguiente captura de pantalla pueden observarse algunas funcionalidades accesibles por el TM sobre una asignación a un proyecto:

El Stakeholder (SH) puede ver los proyectos a los que ha sido invitado:

• El SH también puede unirse proactivamente a un proyecto si conoce un código privado. También puede realizar la operación inversa si deja de tener interés en el seguimiento de un determinado proyecto.
• El SH puede supervisar la información sobre la planificación y el control del proyecto.
• El SH puede enviar comentarios sobre el proyecto (anónimos o bien indicando sus datos) para que sean tenidos en cuenta por el PM.
• El SH puede solicitar cambios al PM.

En la siguiente captura de pantalla pueden observarse algunas funcionalidades accesibles por el SH sobre un proyecto:

El Requester (RQ) puede crear solicitudes, que internamente se tratan como proyectos que aún no han sido aprobados (en estado de inicio):

• El RQ puede asignar al PM, que podría comenzar a gestionar los procesos de inicio conjuntamente con el RQ. El estado del proyecto “inicio” se corresponde con el estado de la solicitud “propuesta”.
• El RQ también puede asignar al patrocinador del proyecto (SP).
• Cuando el proyecto se aprueba, el RQ puede pasar la solicitud al estado “en progreso” o bien el PM puede pasar el proyecto al estado “en planificación” y, cuando termina la planificación, al estado “en ejecución”. Desde el punto de vista de la solicitud, sigue en estado “en progreso”.
• El RQ puede visualizar la información de control del proyecto.
• Cuando el proyecto ha concluido, el RQ puede indicarlo pasando la solicitud al estado “cerrada”, o bien el PM puede pasar el proyecto al estado “cerrado” o “archivado”.

En la siguiente captura de pantalla pueden observarse algunas funcionalidades accesibles por el RQ sobre una solicitud/proyecto concreto:

El Program Manager (PgM) puede crear programas:

• El PgM puede incluir los proyectos que componen el programa.
• El PgM puede ayudar al PM a gestionar el proyecto incluido en su programa.
• El PgM puede enviar comentarios y solicitudes cambios para que sean tomados en cuenta por el PM.

En la siguiente captura de pantalla pueden observarse algunas funcionalidades accesibles por el PgM sobre un programa concreto:

El Portfolio Manager (PfM) puede crear portafolios:

• El PfM puede incluir los proyectos que componen el portafolio.
• El PfM puede ayudar al PM a gestionar el proyecto de su portafolio.
• El PfM puede enviar comentarios y solicitudes cambios para que sean tomados en cuenta por el PM.
• El PfM puede incluir los programas que componen el portafolio.
• El PfM puede ayudar al PgM a gestionar el programa incluido en su portafolio.

En la siguiente captura de pantalla pueden observarse algunas funcionalidades accesibles por el PfM sobre un portafolio concreto:

El Resource Manager (RM) puede visualizar la retroalimentación sobre el desempeño de los Team Members que forman parte de su Pool:

• El RM puede fijar los criterios de evaluación para los TMs de su pool.
• Los demás roles pueden evaluar el desempeño del TM en un proyecto, sobre la base de dichos criterios.
• El TM puede visualizar el feedback para el evaluado.
• El RM puede visualizar el feedback para el evaluado y el fedback para el equipo gestor.

El Functional Manager (FM) puede visualizar la retroalimentación sobre el desempeño de los proyectos de su Business Unit:

• El FM puede fijar los criterios de evaluación para los proyectos de su BU.
• Los roles SH, RQ y SP pueden evaluar el desempeño del proyecto, sobre la base de dichos criterios.
• El feedback puede incluirse en el informe de cierre del proyecto, accesible por los roles gestores (PMO, PMA, FM, PfM, PgM y PM).

Hay otros muchos casos interesantes que de colaboración en gestión de proyectos profesional: relaciones con proveedores, seguimientos, flujos de aprobación y control, etc. ¿Podría haber algún otro ámbito más propenso a la colaboración entre profesionales que los proyectos?

PMPeople es la herramienta para la economía de proyectos. Se diseñó para unificar la gestión profesional de los proyectos de las organizaciones, destacándose por los siguientes puntos:

• Diseñada por y para project managers profesionales, siguiendo los estándares de gestión de proyectos profesional.
• Productividad en línea (menos reuniones, menos documentos, menos flujos) por colaboración distribuida entre 12 roles especializados: Dueño de la Organización; 6 roles para la gestión de la demanda y 5 roles para la gestión del suministro.
• Aplicación freemium (uso gratuito por tiempo ilimitado, pago por uso) con usabilidad equivalente por web y por la aplicación móvil.

Comience a usar PMPeople gratis, sin límite de tiempo, sin límite de usuarios. En las organizaciones premium solo tienen coste los gestores. Algunos roles (interesados, team members, patrocinadores y gestores de recursos) son siempre gratis. Podrá añadir o reducir usuarios premium según las necesidades reales de su organización. En todo momento, tendrá acceso a nuestro soporte interactivo por Slack. Nuestros servidores se encuentran dentro de la UE. Si lo prefiere, el software puede quedar alojado en sus instalaciones.

Leer este artículo en inglés.