Activar la PMO en 1 semana

• El director general de ACME se apoya en 3 gerentes funcionales que lideran cada uno un área de negocio y son quienes autorizan los proyectos de sus departamentos. Estas 3 áreas de negocio suman 50 personas asignadas a tiempo parcial a equipos de proyectos, agrupadas en 4 centros de recursos.
• Adicionalmente, existe un departamento de Organización y Procesos, liderado por otro gerente funcional. La futura PMO formará parte de este departamento, que dedicará para tal fin un equipo de 5 personas y 2 responsables.
• El director general también tiene un perfil comercial y vende proyectos, junto con otra persona que se centra exclusivamente en labores de venta de proyectos.
• En este momento, ACME tiene 20 proyectos en ejecución entre los 4 departamentos, involucrando a 50 personas.
• Contando al personal involucrado de ACME, de los clientes y de otras organizaciones, hay en total unos 100 interesados que demandan un seguimiento continuo de estos 20 proyectos.
• Un total de 15 project managers se dedican a tiempo completo a gestionar estos 20 proyectos: Hay 10 project managers enfocados en un solo proyecto. Otros 5 project managers gestionan a la vez 2 proyectos.
• Los documentos de los proyectos se comparten, de forma segura, a través de la herramienta Google Drive. Para las tareas del día a día los equipos usan la herramienta de gestión de tareas Asana. Para la comunicación por mensajería instantánea usan Slack. Para la planificación y el seguimiento del cronograma los project managers utilizan la herramienta de scheduling Microsoft Project.
• De los 20 proyectos, 4 de ellos conforman un macroproyecto que hay que ejecutar conjuntamente, como un programa, liderado por una Program Manager.
• ACME también cuenta con 2 Portfolio Managers: Un portafolio incluye el programa anterior, más otros 6 proyectos; el otro portafolio incluye 5 proyectos. Los 2 portafolios incluyen proyectos de distintas unidades de negocio. Hay 5 proyectos que no están incluidos en ningún portafolio o programa.

La solución consiste en activar una PMO con personal propio de la organización.

PMPeople significa “Personas colaborando en Gestión de Proyectos”. PMPeople proporciona la tecnología para la transformación digital de las organizaciones en la Economía de Proyectos. Profesionalice la gestión de sus proyectos mediante la colaboración en línea entre personas que usan distintos roles.

• En cada uno de los 20 proyectos, hay que asignar quién usará el rol Requester (el CEO o el director comercial) y el rol de Project Manager.
• Asimismo, puede asignarse al Project Sponsor, que en este caso coincide con el Functional Manager.
• Para cada proyecto, hay que asignar quién asistirá al project manager desde la PMO con el rol PM Assistant.
• De paso, ya se puede incluir el proyecto en el correspondiente portafolio y/o programa.

¿Qué ha cambiado hoy?

• 80 personas pueden acceder a PMPeople por web o instalándose la aplicación móvil. Pueden cambiar su contraseña, entrar en la organización ACME, ver el logo, la descripción, saber quién es el Organization Owner, etc.:

• Las 2 personas responsables de la PMO pueden usar el rol PMO para comprobar que pueden ver todos los proyectos, recursos, Business Units y Resource Pools. Pueden controlar cualquier proyecto como si fueran el Project Manager, cualquier portafolio como si fueran el Portfolio Manager, cualquier programa como si fueran la Program Manager, cualquier Business Unit como si fueran el Functional Manager y cualquier Resource Pool como si fueran el Resource Manager. Nótese que, en PMPeople, el rol PMO tiene acceso a casi todas las funciones dentro de la organización, salvo algunas exclusivas del Organization Owner.
• El responsable del departamento de Organización y Procesos, además de PMO, tendrá el rol de Functional Manager, para ver los datos de su Business Unit. También tendrá el rol de Resource Manager, para ver los datos del Resource Pool y de los 5 Team Members integrantes del equipo PMO.
• El CEO y el director comercial pueden entrar con el rol Requester para ver en qué estado están los proyectos que ellos han solicitado.
• Los responsables de las 3 Business Units pueden probar los roles Functional Manager, Sponsor y Resource Manager.
• Los integrantes del equipo PMO, además de como Team Members, podrán usar el rol PM Assistant para ver los proyectos en los que pueden asistir al Project Manager.
• Los 2 Portfolio Managers pueden ver los proyectos que componen sus portafolios. Uno de ellos, además, puede ver que tiene un programa en su portafolio, y puede acceder a los proyectos que componen dicho programa.
• La Program Manager, a su vez, puede entrar en los proyectos que componen su programa.
• Los 15 Project Managers pueden ver que tienen proyectos en una o dos Business Units. Recordemos que hay 10 project managers que se enfocan en un solo proyecto; y otros 5 project managers gestionan a la vez 2 proyectos. Pueden entrar en sus proyectos y añadir o actualizar cualquier información (no pueden cambiar al Project Manager, como es lógico).
• Los 5 Resource Managers pueden cambiar los datos de su Resource Pool, asegurarse que el pool está integrado por los Team Members correctos y también pueden comprobar otra información de detalle de cada Team Member.
• Por último, los 50 Team Members pueden comprobar que están en el Resource Pool adecuado y otra información de detalle.

• Los calendarios que determinan los días laborales en los proyectos de su unidad.
• Los esquemas para las notificaciones automáticas por email cuando se cumplen determinados eventos en sus proyectos.
• Los datos de los clientes de sus proyectos.
• Las distintas fases que permiten modelar el ciclo de vida de sus proyectos.
• Las etiquetas para filtrar las listas de proyectos.
• Las categorías de costes y los medios de pago que usarán los Team Members al declarar gastos en sus proyectos.

• En los datos del proyecto, se puede configurar el proyecto para permitir que los usuarios se puedan unir al proyecto a través de un código privado. Los usuarios con los roles Stakeholder, PM Assistant y Team Member, pueden unirse al proyecto proactivamente, vía web o por aplicación móvil, si saben este código.
• En el apartado de análisis del beneficio, el PM puede completar cierta información sobre el retorno financiero esperado tras la finalización del proyecto, después de que el producto del proyecto se haya transferido a operaciones.
• En el apartado del acta de constitución, el PM puede completar la información necesaria para justificar el proyecto. En la web, puede comprobar que es posible descargar un fichero PDF con el documento del acta de constitución.

• Desde la aplicación móvil, puede comprobar que es posible ver y modificar esta información del Project Charter.

• En el apartado equipo de proyecto, los usuarios pueden conocer al resto de los integrantes. De momento faltan los Team Members porque aún no han sido asignados.
• En el apartado de registro de interesados, el PM puede añadir a los interesados del proyecto y la información relevante de cada uno de ellos. Además, si un interesado debe acceder desde la herramienta, esto se puede configurar de dos maneras, que conviene ensayar en este momento. Supongamos que el Organization Owner ha registrado a los 5 Stakeholders que tiene el proyecto piloto. En la sección registro de interesados, dentro de cada interesado concreto, el PM puede seleccionar al usuario correspondiente de la lista de interesados de la organización, o bien le puede invitar con su dirección de email. El resultado en ambos casos es el mismo: estos usuarios verán el proyecto piloto cuando entren en la organización con el rol de Stakeholder. El PM invita así a 3 de los 5 Stakeholders. A los otros 2 Stakeholders, el PM les pasará el código privado del proyecto para que se unan ellos mismos, proactivamente.
• Por último, en la pestaña de inicio también se puede conectar PMPeople con otras herramientas que use la organización para este proyecto concreto. Recordemos que en ACME ya se usaban las herramientas Google Drive, Asana y Slack para colaborar en los proyectos.

• Supongamos que el proyecto piloto ya se ha planificado en la herramienta Microsoft Project (MSP). En tal caso, la planificación del alcance, el cronograma y los costes se puede hacer muy rápidamente. En MSP, el PM se asegura de que se ha grabado la línea base. En el campo Priority indicará con valor=1 cuáles son los paquetes de trabajo y los hitos que hay que subir a PMPeople. En el campo Notes puede introducir la descripción de cada paquete de trabajo.

• En PMPeople puede usar el botón “rebaseline” para cargar automáticamente los nombres y las descripciones de los paquetes de trabajo, las fechas de la línea base del cronograma y la línea base de costes.
• En el apartado de la planificación del alcance, el PM puede entrar la información del enunciado del alcance del proyecto. También puede completar la descripción de los paquetes de trabajo y asociar a cada paquete los requisitos y los entregables correspondientes.
• En el apartado de la planificación del cronograma, suponiendo que se han subido las fechas desde MSP, el PM puede explicar la base para las estimaciones de duraciones y puede revisar la descripción de los hitos asociados a cada paquete de trabajo.
• En el apartado de la planificación del coste, suponiendo que se han subido los costes desde MSP, el PM puede explicar la base para las estimaciones de costes. Si en la organización se usa el método EVM, el PM puede periodificar el coste presupuestado del trabajo planificado (lo que también se conoce como valor planificado). Antes, el PM habrá tenido que planificar las fechas de seguimiento.
• En el apartado de la planificación de la financiación, el PM puede desglosar las partidas de ingresos, gastos, reservas y costes. El PM y los demás roles gestores pueden ver la gráfica en cascada detallando el margen económico del proyecto.

• En el apartado de planificación de recursos, el PM puede asignar a los Team Members a cada paquete de trabajo.
• En el apartado de planificación de tareas, el PM puede crear tareas para cada paquete de trabajo. En este caso, el PM puede importar las tareas desde la herramienta Asana.

¿Qué ha cambiado hoy?

• Para que los Team Members puedan revisar sus asignaciones, antes el PM debe pasar el proyecto a estado “ejecución”. Si el proyecto estuviera en otro estado (inicio, planificación, cierre o archivado) entonces los Team Members no verían a qué paquetes de trabajo del proyecto están asignados. Tampoco verían las tareas asociadas a dichos paquetes de trabajo.
• Los 5 Team Members del proyecto piloto pueden revisar sus asignaciones y saber qué compañeros de equipo están asignados al mismo paquete de trabajo.
• Los Team Members pueden colaborar para redactar el Acta de Constitución del Equipo.
• Los Team Members pueden revisar sus tareas (sabiendo su código RASCI y el de sus compañeros). Pueden actualizar fechas, descripciones, mensajes recordatorios, etc. También pueden completar sus tareas, reabrirlas, filtrar por fechas, etc. Los Team Members pueden unirse proactivamente para colaborar en otras tareas, si es necesario.
• Los Team Members pueden reportar las horas trabajadas (pueden registrar las horas extra) y sus gastos, quedando a la espera de la aprobación del PM.

• Es recomendable que se practique esta funcionalidad desde la aplicación móvil.

• Los Team Members pueden trasladar comentarios sobre el proyecto (anónimos o con el autor visible) al PM.
• Los Team Members pueden registrar su estado anímico y otra información útil para las retrospectivas ágiles.
• Los Team Members pueden revisar las retroalimentaciones dirigidas a ellos.
• En este momento del proyecto de activación de la PMO, es oportuno ensayar la capacidad de proporcionar retroalimentación a los Team Members: Los 5 Stakeholders, el director comercial (Requester), el jefe del departamento de Organización y Procesos (usando sus roles de Functional Manager y Sponsor), los 5 PMOS, los 2 PMO, el PfM, el PgM, y el PM, pueden pasar comentarios de prueba para que puedan verlos los 5 Team Members, en la web y con la aplicación móvil. Al escribir una retroalimentación, se permite añadir un texto para los gestores (este texto no se muestra al Team Member).
• Los roles gestores (PM, PMO, PMOS, PfM, PgM, RM), pueden revisar las retroalimentaciones dirigidas a los Team Members, incluyendo la información para los gestores.
• Los roles gestores pueden aprobar o rechazar horas y gastos individualmente, pero muchas veces es conveniente gestionar la capacidad de los recursos y gestionar los gastos de muchos usuarios, en varios proyectos, en un rango de fechas.

¿Qué ha cambiado hoy?

• La información más importante de un seguimiento es la de tipo “cualitativo”, explicando en líneas generales la situación global de cada paquete de trabajo y del proyecto completo. Es importante expresar el estado de salud con un indicador semafórico. Normalmente, el color verde se usa cuando el proyecto va según lo planificado, el color amarillo cuando hay problemas moderados, y el color rojo si la situación del proyecto es preocupante. También se recomienda comentar los riesgos y problemas más importantes, los principales supuestos y las dependencias externas. Los usuarios con el rol Stakeholder, Requester, Functional Manager y Sponsor podrán ver esta información en forma de cuadro de mandos:

• Para completar el seguimiento, el PM (o cualquier gestor del proyecto) puede entrar los datos de alcance, cronograma, costes y financiación.
• El PM (o cualquier gestor del proyecto) puede actualizar el registro de riesgos, el registro de incidentes y el registro de supuestos.
• El PM (o cualquier gestor del proyecto) puede leer los comentarios provenientes de los Team Members, Stakeholders, Sponsor, y Requester. A su vez, el PM (o cualquier gestor del proyecto) puede añadir comentarios de gestión, a modo de cuaderno de bitácora.
• El PM (o cualquier gestor del proyecto) puede procesar los cambios solicitados por los Stakeholders, Requester y Sponsor. Los marcará como aceptados o rechazados, según sea la decisión del comité de control de cambios, si lo hay.
• El PM (o cualquier gestor del proyecto) puede revisar la realimentación sobre el proyecto proveniente de Stakeholders, Sponsor y Requester.
• El PM (o cualquier gestor del proyecto) y el Requester pueden añadir lecciones aprendidas mientras el proyecto esté abierto.
• El PM (o cualquier gestor del proyecto), el Functional Manager y el Requester pueden revisar el informe de cierre mientras el proyecto esté abierto.
• Ciertos elementos del informe de cierre se van actualizando automáticamente: El Resumen del Proyecto muestra la información del cliente, resumen del alcance, cambios aprobados, fechas e hitos globales del proyecto. El Libro del Proyecto muestra información sobre el margen financiero, y sobre cada paquete de trabajo, incluyendo la tarea resumen del proyecto, información sobre el desempeño del alcance, el cronograma y el coste. El Cuaderno de Bitácora muestra incidentes y comentarios ordenados cronológicamente. En el informe de cierre también se incluye una sección con las retroalimentaciones sobre el proyecto provenientes de los Stakeholders, el Requester y el Sponsor, ordenadas cronológicamente.

¿Qué ha cambiado hoy?

• Integrar a todos los Team Members que tengan asignaciones a proyectos.
• Que cada proyecto ofrezca un seguimiento cualitativo actualizado, con el color semafórico correspondiente.
• Dar de alta a los 95 Stakeholders restantes, para que sean invitados a cada proyecto por el PM correspondiente, que decidirá si facilita el código privado o les invita directamente.

• Es muy efectivo que el PM sienta que, en cualquier momento, el director general, por ejemplo, desde su teléfono móvil, puede interesarse por el estado de su proyecto.
• Esto provoca la motivación necesaria y suficiente para que los PMs adopten el hábito de actualizar la información de seguimiento continuamente.
• A la larga, se fomenta la buena práctica de monitorizar y tomar acciones correctoras en cada uno de los proyectos.
• Desde una perspectiva organizacional, comienzan a darse las condiciones prácticas para que más proyectos terminen cumpliendo los objetivos de forma generalizada.

¿Qué ha cambiado hoy?