project-management - para - tutorial django
Cómo decirle a un gerente de proyecto "NO" para que se alcance el alcance (10)
Al perseguirlo para que entienda cómo estás tratando de ayudarlo a salvar su trabajo (es decir, le estás diciendo la verdad). Supongo que tiene más en juego que tú.
Si bien los gerentes de proyecto pueden tener cada uno su propia personalidad y estilo de gestión, parece que muchos de ellos tienen un pernicioso amor de escabullirse en "alcance lento" cuando pueden (ya sea que alguien esté mirando o no). Si bien por lo general tienen buenas intenciones (bendigan sus corazones), ¿cuál es la mejor forma que ha encontrado para decir "NO" a los gerentes de proyecto?
Al tener un buen cálculo de costos y un diseño de características para lo que está en el alcance, llevándoselo de vuelta y preguntándoles si quieren cambiar la fecha o cortar otras características. En este último caso, ¿qué características ya no son importantes y aún no se han iniciado?
La forma más fácil de hacerlo es ser firme y decirles que afectará la fecha de lanzamiento si incluye la (s) característica (s) adicional (es). En última instancia, su trabajo es enviar un producto a tiempo, por lo que la conclusión para ellos es "¿podemos encajar esto sin romper el cronograma?". Si la respuesta es no, entonces cualquier gerente de proyecto que valga su salario debería caer firmemente del lado del desarrollo al aceptar que se trata de un alcance inaceptable.
Si quieres tener éxito en tu organización, querrás ser un jugador de equipo y debes esforzarte para demostrar tu compromiso. A veces, esto significa dedicar un tiempo extra para obtener una nueva sugerencia en el producto.
Sin embargo, es más probable que impongas respeto al poner límites firmes a lo que razonablemente se puede esperar de ti. Una forma de hacer esto es ayudando a los gerentes a comprender que no van a mejorar un producto al involucrarse en el alcance, pero que es más probable que dañen el producto a largo plazo.
Se honesto
Explique que existe una estrecha dependencia entre la fecha de envío, la calidad y las características. Dígales que si quieren cumplir con la fecha de envío, la calidad se verá afectada si se agrega la nueva función.
Algo que me ha funcionado en el pasado:
Asumo que si el administrador de su proyecto quiere infiltrarse en las características, no tienen un plan de proyecto preciso. Mantenga su propia lista de tareas con una estimación del tiempo que tomará cada tarea, ordenada por prioridad; no es necesario elaborar solo un documento de texto u hoja de cálculo. Si su administrador de proyecto desea que agregue una nueva característica, envíe una copia de su lista y pregunte dónde debe insertarla en el orden de prioridad.
Si el gerente de proyecto intenta negociar sus estimaciones de tiempo, simplemente diga "Haré todo lo que pueda, pero no puedo garantizar nada".
Lo más probable es que, mientras suponga que su gerente de proyecto tiene un ''pernicioso amor por entrar a hurtadillas'' ''cuando puedan'', su perspectiva es probablemente diferente. Probablemente sea más productivo asegurarse de comprender su punto de vista.
Esto es, por supuesto, además de comunicar su propio punto de vista, a saber, las consecuencias de la fluencia del alcance. Probablemente necesite identificar explícitamente el trabajo adicional en su plan de desarrollo, estimar cuánto tiempo llevará el trabajo adicional y explicar que esto significa un retraso o descartar alguna otra característica.
Esto solo funciona si tus estimaciones son buenas. Esto no funciona si realiza el trabajo adicional de los libros, para que el tiempo adicional no sea visible. De lo contrario, es posible que cumpla con la fecha límite por otras razones, como un trabajo más difícil o aumentos de eficiencia, y su gerente de proyecto simplemente recordará que el alcance del rastreo no afectó la fecha de entrega ''última vez''.
Permítanme comenzar diciendo que si un primer ministro está "escabulléndose en el alcance lento" es un gerente de proyecto muy malo.
Habiendo dicho eso ... no es su trabajo decir que no a un gerente de proyecto. Es su trabajo asegurarse de que sepa y comprenda los costos y riesgos del cambio que está haciendo. Si el PM insiste en cambiar el alcance y ajustar nada más en el proyecto, obtenga otro trabajo (porque el proyecto y / o la empresa están condenados).
¿Son los bits que se introducen en el proyecto solicitado por el cliente? ¿Son artículos valiosos para entregar?
Ciertamente hay un problema con el PM si están infiltrando cosas en el alcance y no las hacen visibles. Esta es una preocupación seria y algo que plantearía con ellos directa y abiertamente.
Sin embargo, el alcance del alcance (en mi libro) es perfectamente aceptable si continúa cumpliendo con los requisitos del negocio. Claro, tiene fechas límite, pero ¿qué hay de malo en ser flexible con lo que entrega en esa fecha límite? Aquí es donde la visibilidad es crítica.
Una buena regla empírica es contestar siempre, "Está bien. ¿Qué deberíamos dejar para incluir esto antes de la fecha límite?" y / o "De acuerdo. Si movemos la fecha límite a X, podemos agregar eso".
Cada cambio afecta el tiempo de finalización. No hay tal cosa como una tarea de tiempo cero. Obligar a un gerente de proyecto a darse cuenta de que la calidad, la fecha de entrega o la lista de características sufrirá cada vez que realice un cambio contribuirá en gran medida a hacer que piensen bien sobre el alcance del alcance.