¿Cómo evitar que los directores de proyectos bien intencionados se involucren demasiado en los detalles?

Cuando se trabaja en proyectos, a menudo hay gerentes de proyectos que han hecho la transición desde roles técnicos.

Para bien o para mal, estos gerentes de proyecto a menudo toman la iniciativa en la definición de los entregables técnicos, a menudo a riesgo de alienar a los equipos técnicos, perder dependencias, restricciones, etc. que definen los logros técnicos, etc.

A veces aparece un gerente de proyecto que ha tenido una exposición básica a soluciones técnicas e intenta definir hitos técnicos.

En lugar de decirles que no es su lugar definirlos (ya que puede resultar en resultados no deseados, por ejemplo, conflictos, egos desafiantes, etc.), ¿cuál sería un enfoque o conjunto de enfoques apropiados?

Respuestas (3)

Ciertamente, hay personas que no pueden evitar saltar de sus carriles de natación e involucrarse donde no deberían estar. Cuando eso sucede, lo golpea de frente y les hace saber que están interfiriendo y poniendo en peligro el éxito. El PM, sin embargo, tiene licencia para saltar fuera del carril de natación PM y no puedes decirle que te deje en paz.

Asumiendo que usted no tiene un gerente tipo microgerente crónico, su PM está saltando fuera del carril de natación PM debido a usted y su equipo. No es el PM y la solución no es averiguar cómo manejar el PM. Es usted y su equipo y la solución es averiguar qué está haciendo o no está haciendo su equipo que está causando la interferencia del PM. Hay falta de confianza, falta de rendimiento, riesgos crecientes, quejas, algo.

Si tiene ese tipo de PM de microadministrador, alégrese de que los proyectos tengan una fecha de finalización, momento en el cual puede encontrar otro proyecto y otro PM.

Aplicar las mismas técnicas, el PM debería haber aplicado:

Como dijiste (en la medida en que lo interpreté), no quieres molestar a nadie ni plantear un conflicto.

Una buena manera es dirigir una conversación haciendo preguntas (no encontré una buena referencia):

  • ¿Cuáles fueron sus suposiciones al poner esa fecha?
  • ¿Sabías que este equipo no ha aplicado esa tecnología antes?
  • ...

Si logra preguntar de manera interesada, su PM no se molestará. Además, el PM debe notar la falta de conocimiento y crear un grupo de expertos en el futuro.

Solo por la integridad de la respuesta:

  • A veces es mejor pelear un conflicto que cargar algo por mucho tiempo
  • ¿Son sus proyectos finalmente exitosos (presupuesto de wrt y contratos de seguimiento)? Tal vez sea la forma (fea) de presionar a los desarrolladores o de ganar un contrato, de lo que debería argumentar de otra manera (más éxito comercial).

Bueno, primero es importante recordar que un PM que ha incursionado puede tener consejos u opiniones útiles y puede que no los exprese de la manera adecuada. Es en el mejor interés de todas las partes involucradas navegar a través de los egos para garantizar que se cree la mejor solución posible.

Dicho esto, mi consejo es trabajar con el PM para abordar cuáles son los requisitos reales del cliente. Una buena manera de hacer esto es simplemente hacer preguntas de sondeo:

  1. Cuáles son los requisitos detallados.
  2. Cuáles han sido los comentarios de los clientes.

A medida que comiencen a brindar soluciones de implementación, recuérdeles cortésmente que le gustaría concentrarse en los requisitos sin procesar y no en cómo los resolvería.