Un par de cuestiones relacionadas:
No hace falta decir que terminamos con problemas importantes en los proyectos con este patrocinador, principalmente la falta de planes definidos, el aumento del alcance y los requisitos cambiantes. Honestamente, no creo que este patrocinador entienda o aprecie el valor que tiene un PM, pero más allá del trabajo a largo plazo de educarlo sobre esto, ¿hay alguna forma de mitigar los problemas que estas características causan a corto plazo?
Una herramienta que estoy usando en diferentes contextos es contabilizar el trabajo dividiéndolo entre el valor agregado y el desperdicio (o sin valor agregado; es posible que prefiera usar este nombre ya que no suena tan duro). La definición de desperdicio difiere entre los equipos, pero definitivamente todo el retrabajo no agrega valor. Si dices "mucho trabajo innecesario" te pregunto: ¿cuánto exactamente? Si puede proporcionar los datos, es un buen punto de partida para una discusión con su parte interesada. Es mucho más difícil discutir con los hechos que con las opiniones.
Lo respaldaría con todas las situaciones que puede abordar para cualquier problema específico que mencione:
Una vez recopilados los datos de valor/desperdicio, también debería poder mostrar cuánto le cuestan a la organización tales "prácticas". Al mismo tiempo, arreglar algunos de ellos, como mantener a la gente informada, cuesta casi nada.
Otra estrategia para lidiar con tal situación puede ser seguir la actitud de "es mejor pedir perdón que pedir permiso". Especialmente cuando piensas en las cosas que haces dentro del equipo, como la planificación. Si puede soportar la presión de comenzar instantáneamente y hacer lo que cree que es correcto (planificar), simplemente hágalo. Te arriesgas, pero es muy raro que se culpe a la gente por hacer un buen trabajo.
Y finalmente, es posible que no importa lo que hagas, VP no cambia. Entonces es su decisión: o acepta el hecho o deja la organización. Si elige quedarse allí, por supuesto, hay una gran cantidad de reducción de daños por hacer, por ejemplo, aislando al equipo de decisiones aleatorias tanto como pueda o tratando de introducir una organización de trabajo que absorba tales cosas (pequeños lotes de trabajo, bucles de retroalimentación ajustados) .
Algunas cosas que he intentado, con diversos grados de éxito (pero ciertamente mejor que nada:
Con problemas como este, me gusta buscar en mi caja de herramientas ágil y desempolvar mi eslogan personal: "¡Ningún trabajo invisible , nunca !" Veamos cómo ayuda esto en un contexto ágil.
Mi patrocinador es visionario pero no logra comunicar la visión con la suficiente claridad como para permitir la implementación. Esto conduce a una gran cantidad de reelaboración innecesaria.
¡Sin preocupaciones! El patrocinador es el único responsable del éxito (o fracaso) del proyecto. Puede ayudar al patrocinador a hacer que el proyecto sea un éxito eventual asegurándose de que todo el retrabajo se documente como trabajo . "Reelaboración" no recibe un tratamiento especial; si se trata de una tarea que consume tiempo, dinero o recursos del proyecto, simplemente documéntelo y agréguelo al backlog. Luego, el propietario del producto deberá priorizar los nuevos elementos de trabajo, tal vez cambiando otras historias de usuario en el backlog como resultado, y el equipo seleccionará el nuevo trabajo de la cola cada vez que llegue al frente (¿superior?) del backlog y sea listo para ser arrastrado al siguiente sprint.
Esto eventualmente conducirá a preguntas como "¿Por qué la fecha de entrega del proyecto se está adelantando?" Esto es bueno y le permitirá tener una discusión sobre el proceso.
Si el proceso funciona para el patrocinador, entonces el proceso está bien. Incluso si el proceso es subóptimo, si el patrocinador rompe el proceso, el patrocinador se queda con ambas piezas.
Mi patrocinador se comunica con los líderes del equipo directamente sin mantenerme (oa otros miembros del equipo del proyecto) al tanto. Esto me impide gestionar el cambio de manera controlada, es difícil mantener el ritmo.
Los líderes de su equipo están manejando el cambio. ¡Eso es genial! Dado que el patrocinador ya los está delegando, todo lo que necesita hacer es delegarles la responsabilidad adicional de actualizar el trabajo pendiente con todo el trabajo nuevo.
Si el patrocinador habla con Joe y sugiere que se agregue una función de gran envergadura al proyecto, entonces Joe es responsable de agregar la nueva historia de usuario a la cartera de pedidos. Si Joe no quiere esa responsabilidad, debe remitir al patrocinador al Product Owner o Scrum Master. Sin embargo, no se debe permitir que Joe obligue a todo el equipo, ni dedique tiempo a trabajar en "trabajos invisibles". El trabajo debe enviarse como trabajo al equipo y agregarse visiblemente a la cola de trabajo.
Mírelo de esta manera: el proceso solo se está pasando por alto porque no hay un beneficio claro para Joe o para el patrocinador por seguirlo. Si Joe o el patrocinador se dan cuenta de que hacer un recorrido final del proceso significa más trabajo para ellos personalmente, entonces tendrán un incentivo para hacer que el proceso funcione de manera eficiente. Por otro lado, si el proceso no ofrece ningún valor, debe cambiar el proceso hasta que lo haga. ¡Eso es ganar/ganar para todos!
Mi patrocinador es un vicepresidente que cree honestamente que algunos aspectos de un proyecto exitoso (por ejemplo, tener un caso de negocios continuamente justificado) es asunto suyo y de nadie más.
¡Impresionante! Dado que su vicepresidente ha identificado una necesidad comercial, debería estar feliz de asignar los recursos del equipo a la tarea. Eso significa que el tiempo dedicado a recopilar datos para casos de uso, redactar propuestas y especificaciones, y otras tareas relacionadas debe agregarse al trabajo pendiente.
Si es un trabajo que el vicepresidente quiere hacer, entonces por supuesto agréguelo al equipo y permítale sacar las historias de los usuarios de la acumulación en cada sprint. Si es trabajo que el vicepresidente quiere delegar, entonces el equipo llevará las tareas a un sprint cuando:
Dado que es el trabajo del Product Owner priorizar el backlog, es su trabajo derivar al VP al Product Owner si hay un problema con la forma en que se prioriza el trabajo. Si el propietario del producto está de acuerdo en que actualizar un caso de negocio en este sprint es más importante que la función de mejora del patrocinador, entonces es una decisión basada en el valor para el negocio. ¡Todos ganan!
Mi patrocinador es del tipo (demasiado común) que quiere que se comience a trabajar en una solución antes de que exista un plan adecuado (o incluso una definición de cómo será la solución).
¡Maravilloso! El trabajo por sí mismo puede ser muy gratificante. Por supuesto, si se trata de un trabajo invisible, nadie recibe ningún crédito por él, y nadie enfrenta ninguna consecuencia por no planificar o diseñar incluso la cantidad mínima que los procesos ágiles necesitan para tener éxito.
La solución es la misma que antes: documentar todo el trabajo. ¿Está construyendo una nueva arquitectura porque la solución del mes pasado no estaba bien pensada? Añádelo como trabajo visible. ¿La función de aumento imprudente ha causado la muerte de millones de sus mejores clientes? Agregue el costo de los juicios, el cambio de identidad y la mudanza a otro país al presupuesto de su proyecto.
No importa cuál sea el resultado, bueno o malo, el proceso debe tener consecuencias visibles para toda la organización. Un buen proceso tendrá consecuencias naturales positivas netas; uno malo será significativamente menos maravilloso para todos los involucrados. Sin embargo, todo comienza con hacer visible el trabajo .
Agregue algunos puntos sensatos de inspección y adaptación, como revisiones de sprint quincenales y retrospectivas, y puede descubrir que "sumergir" es una estrategia que funciona para su empresa. Un poco de planificación justo a tiempo puede ser muy efectivo.
"Mida una vez, corte una vez" es el epítome de la agilidad. Incluso puede salirse con la suya con "cortar una vez, medir una vez" la mayor parte del tiempo. Sin embargo, "cortar dos veces, medir nunca" es una tontería.
La mayor parte de mi respuesta ha sido desde una perspectiva ágil, pero en última instancia, puede hacer lo mismo con cualquier metodología. ¡Solo haz que el trabajo sea visible!
Al final, un buen gerente de proyecto es el pastor del proceso del proyecto , no el ejemplo de su éxito o fracaso final. Su trabajo principal es educar a la organización, ¡incluido el patrocinador del proyecto!, sobre el proceso actual y ayudar a la gente a adaptar el proceso (o implementar otros nuevos) de manera que les permita hacer el trabajo.
Protege al equipo. Educar a la gerencia. Haz lo que tengas que hacer... ¡pero nada de trabajo invisible, nunca !
Documento, documento, documento.
La única forma de sobrevivir a este tipo de patrocinador es documentar TODO y luego rastrearlo todo.
Es de suponer que tiene un alcance, un presupuesto y un cronograma originales, o un conjunto de requisitos. Comience a hacer un seguimiento de la quema del presupuesto y muestre dónde se consume más debido a la repetición del trabajo, la falta de comunicación, la dirección poco clara, etc. Tiene razón en que él no entiende el valor de un MP, pero hay formas de educarlo Muéstrele dónde están los sobrecostos, o dónde podría haber ahorrado dinero (y, en consecuencia, hacerlo quedar bien) a lo largo del proyecto.
Y asegúrese de que su equipo entienda cómo funciona la gestión de un proyecto, para que entiendan lo importante que es que informen sobre las conversaciones con el patrocinador. No puedes evitar que hable con ellos, pero puedes hacer que te avisen si lo hace.
Buena suerte.