Activar la PMO en 1 semana

Activar una Oficina de Gestión de Proyectos (PMO) dentro de una organización es un proyecto complejo. La situación de partida que motiva la necesidad de establecer una PMO suele ser la inmadurez en la gestión de proyectos organizacional, que puede llegar a provocar serios problemas, entre otros:

• Retrasos y sobrecostes en ciertos proyectos clave para la organización, en los que no se ha gestionado correctamente el alcance y se han producido sucesivos cambios descontrolados.
• La alta dirección desconoce la situación actualizada de los proyectos. Muchas veces, no saben con certeza cuántos proyectos se están ejecutando en este momento. ¿Cuáles de ellos pueden entrar en crisis? ¿Quién reporta el estado de cada proyecto?
• Incapacidad de la organización para lanzar más proyectos por saturación de los equipos en los proyectos actuales, que se dedican a proyectos que aportan poco valor al negocio. Esos mismos recursos deberían trabajar con mayor efectividad para poder asumir más proyectos sin problemas.

En el pasado, las firmas de consultoría ofrecían líneas de servicios de PMO muy estables y rentables. Las empresas que demandaban estos servicios reconocían el valor de diseñar servicios y procesos, implantar herramientas costosas y externalizar la función de la PMO en un equipo fijo de unos 5 consultores a tiempo completo. Este enfoque de consultoría suponía ciertos problemas:

• Los proyectos de activación de PMO eran costosos y largos: Desde que un alto directivo autorizaba el proyecto hasta que los primeros project managers usaban los nuevos procesos y herramientas podían transcurrir unos 6 meses.
• El principal riesgo de estos proyectos residía en la gestión del cambio: más importante que modelar procesos y herramientas, las personas involucradas en los proyectos debían cambiar sus métodos de trabajo. Si los niveles bajos e intermedios no seguían finalmente los nuevos procesos, la alta dirección continuaba desinformada y la PMO acababa siendo un fracaso.
• Por lo que se refiere a la operación posterior, el gran inconveniente para los clientes era el alto coste recurrente en herramientas y honorarios de consultores.

En la actualidad, muchos project managers de las organizaciones ya ejercen como agentes del cambio: aplican los marcos de gestión de proyectos predictivos y ágiles, usan herramientas colaborativas gratuitas y se enfocan en la entrega de valor para el negocio en todos y cada uno de sus proyectos. Una organización que cuente con varios de estos profesionales puede esperar que cada vez más proyectos acaben en plazo, en coste, con la calidad adecuada, entregando el valor y cumpliendo el resto de los objetivos de gestión.

Otras organizaciones, menos afortunadas, no pueden esperar a que la mejora en gestión de proyectos organizacional ocurra “de abajo arriba” y necesitan interiorizar una o varias PMOs inmediatamente. En este mundo tan acelerado y tecnológico, las organizaciones de la economía de proyectos ya no pueden esperar 6 meses para mejorar su forma de gestionar los proyectos. Deben cambiar de forma progresiva y adaptativa. Como se suele decir: “Hay que cambiar la rueda con el coche en marcha”.

Activar una PMO se parece cada día más a “cambiar la rueda con el coche en marcha”.

Estudio de Caso

A continuación, vamos a describir brevemente cómo serían los pasos para activar una PMO en una empresa ficticia llamada ACME. Supongamos que se trata de una organización matricial fuerte que ejecuta mayoritariamente proyectos predictivos:

• 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.

El diagrama representa cómo se distribuyen los 20 proyectos activos dentro de las 4 unidades de negocio, el programa y los 2 portafolios:

El Problema

En ACME, los proyectos se lanzan con rapidez, pero en la ejecución ocurren demasiadas crisis y cambios descontrolados. Los project managers no reportan seguimientos periódicos. Las tareas del día a día no les dejan tiempo para planificar y controlar.

La Program Manager entra demasiado en los detalles de los 4 proyectos, no se centra en la entrega de beneficios del programa. Impone demasiada burocracia a los 4 project managers, que ya están saturados con el trabajo del día a día.

Los Portfolios Managers requieren reuniones presenciales con los project managers para conocer la situación de cada proyecto. La lista de iniciativas del plan estratégico crece continuamente, pero los Portfolio Managers se quejan de que hay una situación de bloqueo porque no se cierran correctamente los proyectos en ejecución y, por lo tanto, no es posible lanzar nuevos proyectos como se había planifcado.

El CEO y el director comercial también están muy frustrados: podrían vender más proyectos, pero no hay recursos disponibles para ejecutarlos.

La Solución

Contratar más project managers o team members no sería buena estrategia, pues la carga de proyectos podría decrecer en el medio plazo. La posible externalización también se descarta, ya que el conocimiento debe quedar dentro de la organización. Para continuar con el negocio, en ACME hay terminar exitosamente más proyectos con los mismos recursos.

La solución propuesta consiste en activar una PMO de control dentro del departamento de Organización y Procesos.

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

En PMPeople seguimos un proceso estandarizado para implementar PMOs. Aunque siempre tardamos más tiempo, pensamos que los pasos podrían optimizarse como para llevarse a cabo en una semana. En el plazo de 1 semana, ahora es técnicamente posible llevar a un porcentaje alto de personas de la organización a colaborar de forma productiva en gestión de proyectos, adoptando diferentes roles.

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.

Lunes

En PMPeople, cualquier usuario puede crear una nueva organización, lo que le convierte en el Organization Owner. Cuando finalice el proyecto de activación de la PMO, este rol se pasará al CEO, o a otra persona con autoridad para realizar los pagos mensuales o anuales.

El Organization Owner puede configurar los parámetros de la organización: logos, texto descriptivo, etc.:

El Organization Owner podría invitar, uno a uno, a los 50 Team Members y a los 30 gestores. Este paso se puede optimizar realizando una carga automática de usuarios desde un fichero Excel. Los usuarios quedan registrados con una contraseña prefijada (que luego podrán cambiar), y quedan activados con el rol de Team Member. En cuestión de minutos, se pueden dejar activados los roles de las 80 personas. Se deja para más adelante la carga de los 100 Stakeholders.

El Organization Owner sabe, desde este momento, el coste que tendrá la herramienta una vez finalize el período de prueba. En este caso, para 180 usuarios, sería de 600 €/mes, o bien 6.000 €/año, es decir: 3,33 €/persona/mes ó 33 €/persona/año.

Antes de cargar los proyectos, hay que crear las 4 Business Units y asignar a sus respectivos Functional Managers. También es oportuno crear los 2 portafolios, asignándoles sus respectivos Portfolio Managers. De igual forma puede hacerse con el programa y la Program Manager. El Portfolio Manager puede incluir el programa en su portafolio. La Program Manager también puede incluir su programa en el portafolio, de forma alternativa.

En este momento, también es conveniente crear los 5 Resource Pools y asignar a sus respectivos Resource Managers. En cada Resource Pool, también hay que configurar a cuál o cuáles de las 4 Business Units pueden servir recursos. Posteriormente, hay que emplear unos minutos para asignar cada uno de los 50 Team Members al correspondiente Resource Pool.

La información básica de los proyectos de cada Business Unit también puede cargarse automáticamente a partir de un fichero Excel. Una vez cargados en la herramienta, se pueden realizar estos pasos, que deberían llevar solo unos minutos:

• 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 PMO Supportive.
• De paso, ya se puede incluir el proyecto en el correspondiente portafolio y/o programa.

¿Qué ha cambiado hoy?

Las personas involucradas en la gestión de proyectos de ACME pueden comprobar, al final del día, que son capaces de realizar las siguientes funciones:

• 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 PMO Supportive 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.

Martes

Antes de modelar los procesos en toda la organización, es muy recomendable elegir un proyecto piloto, que sea representativo de la casuística de los otros 19 proyectos. Supongamos que el proyecto piloto es uno de los 4 proyectos que pertenece al programa.

Para profundizar en el caso lo máximo posible, vamos a suponer que la mayoría de los proyectos de ACME son predictivos y se necesita implementar un alto número de procesos de planificación para cumplir las normativas o para realizar un control efectivo. En organizaciones que gestionan proyectos ágiles no se profundizaría tanto en la planificación del alcance, el cronograma y los costes.

Antes de profundizar en el proyecto piloto, es conveniente decidir ciertos parámetros que, en principio, sólo aplicarán a los proyectos de la Business Unit a la que pertenece este proyecto, pero que con toda probabilidad serán replicables a las otras 3. El Funcional Manager puede configurar los siguientes parámetros de la Business Unit:

• 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.

Para modelar la gestión del proyecto piloto, el Project Manager (PM) completará ciertos datos en las pestañas de inicio y de planificación. Veamos primero la información de Inicio:

• 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, PMO Supportive 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.

A continuación, el PM procederá a entrar la información de Planificación:

• 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?

Las personas involucradas en la gestión de proyectos de ACME pueden comprobar, al final del día, que son capaces de realizar las siguientes funciones:

Miércoles

Llega el momento de involucrar a los protagonistas de cualquier iniciativa PMO: las personas que trabajan en el día a día de los proyectos, que en PMPeople son quienes usan el rol de Team Member. Supongamos que en el proyecto piloto se han asignado 5 Team Members a diferentes paquetes de trabajo y a diferentes tareas.

• 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?

Las personas involucradas en la gestión de proyectos de ACME pueden comprobar, al final del día, que son capaces de realizar las siguientes funciones:

Jueves

El pilotaje concluye modelando cómo hay que dar seguimiento a los proyectos. Sobre el proyecto piloto, el PM (o cualquier gestor del proyecto) realizará 2 seguimientos, el último de los cuales debe reflejar la situación real del proyecto a fecha de hoy, si es posible.

• 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?

Las personas involucradas en la gestión de proyectos de ACME pueden comprobar, al final del día, que son capaces de realizar las siguientes funciones:

Viernes

El último paso del proyecto de activación de la PMO consiste en extender los procesos, técnicas y herramientas practicadas sobre el proyecto piloto al resto de los proyectos activos de la organización.

Los 5 PMO Supportive que han ayudado a modelar la gestión del piloto, ahora pueden comenzar a involucrar a los otros 14 PM. Para facilitar la gestión del cambio, se aconseja no profundizar inicialmente en la planificación de las líneas base. En esta etapa es suficiente planificar al nivel del proyecto completo, sin descomponerlo en paquetes de trabajo, lo cual se puede realizar más adelante al ritmo de cada PM, si es necesario.

Los objetivos más valiosos sobre cada proyecto, en este momento, son estos tres:

• 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.

Antes de concluir la activación de la PMO, hay que recopilar todos los puntos pendientes, muchos de ellos habrán sido detectados en esta fase de activación, y elaborar una hoja de ruta para las siguientes fases. Se recomienda realizar un brainstorming tomando como referencia las siguientes listas, que permiten visualizar los objetos de información y casos de uso posibles para orientar la evolución a medio y largo plazo de la PMO.

Esta figura muestra los objetos de información básicos de PMPeople:

Esta figura enumera los casos de uso de PMPeople relacionados con la gestión de las personas:

Esta figura enumera los casos de uso de PMPeople relacionados con los procesos:

Esta figura enumera los casos de uso de PMPeople relacionados con el entorno del negocio:

Por último, hay que recordar que es muy importante que la alta dirección se involucre inmediatamente en los seguimientos de los proyectos, o se corre el riesgo de desincentivar el cambio y perder la inercia adquirida. Aquí se produce un efecto psicológico interesante, que en PMPeople denominamos “el efecto Gran Hermano en gestión de proyectos”:

• 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?

Las personas involucradas en la gestión de proyectos de ACME pueden comprobar, al final del día, que son capaces de realizar las siguientes funciones:

A continuación el vídeo del taller celebrado el pasado día 26 de abril (en español):

https://youtu.be/VhgTE0kdKqU

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, solo pagan los gestores) 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 pagan 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.