Siento que si publico un plan de proyecto que muestra la finalización en la fecha X, no puedo presionar para que se complete en la fecha (X - 3 semanas). Pero si publico un plan que muestra la fecha (X-3 semanas), ¿cómo puedo rastrear la fecha de finalización "más probable" (que probablemente sea la fecha X)?
Cuando crea una estimación, el resultado final es un rango de fechas de finalización, o costos, con una distribución probabilística que se encuentra encima de eso. Cuando establece un objetivo, el resultado final es un número ÚNICO que vive en algún lugar de esa distribución. Establecería ese objetivo en función del apetito por el riesgo. Muévalo hacia la izquierda, como su escenario X-3, para desafiar al equipo y adoptar una postura más agresiva. Muévalo a la derecha y hágalo consistente con su más probable. O muévalo aún más a la derecha si necesita incorporar contingencias debido a un montón de incógnitas ambientales.
En la mayoría de las herramientas de programación, puede establecer varias líneas base. Su línea base cero puede ser la oficial que tiene un precio y se vende a su cliente. Puede establecer una línea de base, utilizando un objetivo más agresivo como desafío de su equipo, y establecer medidas y premios en función de eso. Durante el curso del proyecto, mida contra ambos. No "castigaría" al equipo por perder el desafío bajo ninguna circunstancia. Este sería un escenario de tipo de premio y lo configuraría para que fuera más divertido, competitivo y un impulso moral en comparación con cualquier otra cosa.
Trate de implementar la programación basada en evidencia en su primer proyecto. Si recopila la evidencia con bastante regularidad y actualiza su cronograma, verá cuándo puede comenzar su próximo proyecto. La clave aquí es la actualización regular . No se comprometa con el segundo proyecto; intente aplazar su decisión utilizando la opción real , hasta que se sienta seguro de establecer la fecha de finalización del primer proyecto.
Secundo la respuesta de David y me gustaría agregar un método simple para implementar esto en su planificación.
Al estimar el tiempo para cada tarea, debe hacer una estimación muy agresiva sin ninguna holgura incorporada. La holgura para cada tarea luego se combina en un gran bloque de "búfer" que coloca al final de su plan.
Un ejemplo simplificado:
Estimaciones "probables" tradicionales sin búfer:
Task01[10days] > Task02[3days] > Task04[7days] > END
Estimaciones agresivas con buffer agregado:
Task01[7days] > Task02[2days] > Task04[5days] > Buffer[6days] > END
Durante el proyecto, mantiene la fecha final estática pero cambia la duración del búfer según el progreso; es decir, si una tarea se completa antes de la estimación, se agrega al búfer, y si una tarea va más allá, se resta del período del búfer.
Esto le brinda una única métrica de 'salud' para que el proyecto se comunique y cree bonificaciones/incentivos. Esto también simplifica la toma de decisiones difíciles al principio del proyecto. Si usó el 33 % de su búfer, durante el primer 25 % de su proyecto, puede comunicarse fácilmente y discutir este problema con los propietarios del equipo y del proyecto.
Se necesita coraje y perseverancia, pero puede mantener la contingencia del cronograma separada de la ruta crítica. La parte difícil es que sus clientes lucharán por un compromiso de entrega en una fecha anterior.
En su caso, significa trabajar hasta un T-3 y guardar las 3 semanas en su bolsillo trasero.
Esto es más eficiente que distribuir la holgura porque lo más probable es que la necesite para una o dos áreas grandes en lugar de para todas. (Si se perdió cada estimación, tiene un problema mayor).