Se espera que los gerentes de proyecto adivinen el futuro, una tarea difícil incluso en ciencias como la meteorología. Como muchos proyectos terminan tarde (debido a un alcance ampliado, duraciones subestimadas, etc.), es tentador aumentar las estimaciones.
¿Cuándo está bien (o no está bien) hacerlo? Lo primero que se me ocurre es que es arriesgado compartir estimaciones ampliadas con los miembros del equipo del proyecto (ya que ampliarán su trabajo para adaptarse a los plazos ampliados) y arriesgado compartir estimaciones ampliadas con la gerencia (ya que agregarán algunos complementos propios). antes de pasar el horario hacia arriba). Por otro lado, es casi seguro que planificar un cronograma sin relleno conducirá a un proyecto tardío.
¿Pensamientos?
Siempre debe trabajar con un rango de estimaciones: el más probable y el peor de los casos. Agregue márgenes en los puntos de riesgo en su programa y al final, pero déjelos claros para que todos los vean. Esa es la forma profesional de gestionar proyectos.
Administre a los miembros de su equipo contra las estimaciones más probables. No tendrán problemas para trabajar en el borde cuando saben que hay espacio para maniobrar cuando Murphy ataca.
Cuando tenga bien resueltas sus contingencias, la gerencia no tendrá motivos para inflar.
En mi experiencia, la transparencia funciona mejor.
Nunca está bien acolchar. Las contingencias se calculan y se agregan al PMB para manejar las incertidumbres en sus estimaciones de tiempo y costos.
Es mejor prometer poco y cumplir demasiado que prometer demasiado y cumplir poco. Rellenar sus estimaciones agregando un búfer de seguridad le ayudará a asegurarse de que está en la primera categoría y no en la última categoría.
Es imposible predecir el futuro, especialmente si está estimando algo que contiene muchas tareas con las que no tiene experiencia.
'Rellenar y estimar' es una habilidad y un requisito básico para un PM: en realidad es Gestión de riesgos, ¿verdad? Un plan es un mapa de hacia dónde vas y cuánto tardarás en llegar, ninguno de los dos está seguro porque ninguno de los dos ha sucedido todavía. Necesita 'rellenar' o adaptarse a un cambio de dirección y un cambio en el esfuerzo de trabajo basado en eventos que aún no han sucedido (como un cambio en los desarrolladores, nueva tecnología, cambios/influencias comerciales internas/externas). Un buen enfoque es comparar proyectos anteriores para la misma empresa/equipo y ver cómo sus estimaciones originales coinciden con las finales. Otro buen enfoque es desarrollar una matriz de riesgos que incluya un potencial de ocurrencia y un potencial de impacto, con un rango de tiempo/$, que puede usar como una "plataforma de riesgo" para el proyecto.
david espina
Tiago Cardoso