¿Cómo manejar múltiples gerentes de proyecto?

Registro de problemas y registro de riesgos. (sugerencia para @David Espina, sin cuya respuesta me hubiera perdido esto).

Usted es responsable de su(s) proyecto(s). Todo lo que puedas resolver en relación con esos proyectos, estás obligado a resolverlo. Estos son ejemplos de cosas que no puede resolver, porque son artefactos de activos de procesos organizacionales disfuncionales.

Las cosas que no puede resolver van en el registro de problemas y deben informarse a la gerencia,

"No podemos predecir la fecha de finalización con menos de un +/- 75 % de precisión porque dedicamos aproximadamente el 25 % de nuestro tiempo a administrar nuestras prioridades en conflicto"

De manera similar, el registro de riesgos debe indicar la incertidumbre y, lo que es más importante, el impacto del flujo de prioridad.

Cuando los proyectos y los gerentes de proyectos no están sincronizados, esto es un problema a nivel organizacional. La organización necesita resolver este problema si opta por avanzar en su nivel de madurez de gestión de proyectos. Dicho esto, es bastante común. Por lo general, ve esta pregunta desde el punto de vista del PM, que está tratando de garantizar que sus recursos matriciales se utilicen para su beneficio sobre los otros proyectos.

Sugeriría ser muy claro en cuanto a las prioridades conocidas bajo las cuales está operando y el nivel de utilización prometido que comprometió para su equipo en cada proyecto. Cuando tengas un conflicto, escala. Debe haber una ruta de escalada para que los conflictos puedan analizarse y resolverse. Y sobre todo, comunícate con cada uno de los PMs exigiendo el tiempo de tu equipo. Entonces, si tiene una fecha límite con un proyecto, asegúrese de que todos los demás lo sepan.

En cierto sentido, no está dentro de su rol sincronizar los proyectos. Es su función garantizar la utilización adecuada para su equipo, de modo que se minimicen los conflictos en el ancho de banda, que no se sobreutilice a ningún individuo y que el trabajo se secuencie según las prioridades conocidas.

Estoy completamente de acuerdo con Marc y David y quiero sugerir, en cuanto a cómo configurar esto , que encuentre una herramienta que pueda usar para rastrear fácilmente las historias de sus proyectos y barajar sus prioridades . Una herramienta que se puede configurar de manera que los PM sean informados inmediatamente de cualquier cambio y puedan ver el estado actual.

Prácticamente cualquier herramienta de gestión de proyectos debería hacer esto por usted, pero comprarlos/configurarlos puede ser un problema o incluso imposible, según la política de la empresa. Otras herramientas más livianas podrían encajar mejor, así que mencionaré una en un comentario y otras pueden agregarse con el tiempo a medida que las opciones se vuelvan obsoletas.

Gracias a todos por las excelentes respuestas. Elegí un ganador, pero quería agregar mi propia experiencia en los últimos días.

Como soy líder del equipo de IU, creamos una IU estúpida usando angular, yeoman, etc. (las herramientas que usamos todos los días) para crear una IU con todo lo que necesitamos.

Este entorno tiene una "recarga en vivo" para que cada vez que cambio el código, se actualice, por lo que todos nuestros datos también están codificados. Suena extraño, pero parece la mejor herramienta, ya que los datos se guardan en formato JSON, que es lo mejor para los desarrolladores.

Decidimos que el scrum del equipo estará en un nuevo formato, levanto el servidor y todo el equipo mira nuestra nueva interfaz de usuario. Decidimos llamarlo "plan de vuelo" ya que nos recordaba la pizarra que tienes en los aeropuertos para los vuelos de ida y vuelta. Incluso estamos usando íconos de aviones y terminología en él.

Ya tenemos 7 secciones: - Una general para todas las tareas con algún cálculo de progreso según el peso y el estado de las subtareas (terminado, iniciado, inicial, nulo). - también incluye 'fecha límite', 'ETA', 'tiene diseño (sí/no)', 'miembro del equipo responsable', 'última actualización', 'creado en', 'empezando a trabajar en'... - Preguntas - para preguntas que tenía el equipo y tengo que encontrar una respuesta - Problemas pendientes - revisamos nuestro JIRA y vemos si hay nuevos problemas. documentamos nuestra decisión en el plan de vuelo. - Pautas: donde simplemente escribimos algunos estándares para el equipo (debemos ejecutar la compilación localmente antes de cada compromiso, debemos notificar los cambios de ETA 10 días como máximo antes de la fecha límite, etc.) - Alertas rojas: problemas importantes que se plantearon y Necesito burbujear.

Y estamos agregando más a medida que necesitamos... Sin herramienta, sin autorización de la empresa.

Las primeras reuniones tomaron un tiempo (40 minutos) y ahora se han reducido a 20 minutos, lo cual es razonable.

Al final de cada scrum de equipo, lo imprimo en PDF y se lo envío a mi supervisor, que a su vez puede hacer lo que quiera con él.

Apenas he tenido noticias de los gerentes de proyecto durante más de una semana. Nuestros plazos son en un par de días y todo parece estar bien.

Un gerente de proyecto me dijo que vio el "plan de vuelo" y no entendió la fecha límite; debería ser 1 día antes... simplemente cambiamos la fecha límite...

Sus respuestas y comentarios me ayudaron a diseñar y mejorar el plan de vuelo. También estoy enlazando a esta página desde el plan de vuelo por si acaso.

No creo que necesites una herramienta para hacer esto. Debe tener una reunión de PM en la que reúna a los gerentes de proyecto y establezca las prioridades. De hecho, tenemos dos de estas reuniones, una para los PM con el gerente de los PM donde discutimos el estado de nuestro proyecto y cualquier interdependencia. También tenemos una reunión con el administrador de recursos para solicitar recursos y ver cómo se asignan los recursos en los planes. Nuestro departamento en general aclara los proyectos estratégicos y de alta prioridad en nuestras reuniones trimestrales, para que todos sepan por qué otro proyecto podría tener prioridad en recursos sobre el suyo.