¿Cómo calcular el margen presupuestario?

Supongamos que se estima que un paquete de trabajo (que contiene varias tareas) tardará entre 320 (lo más probable) y 480 (el peor de los casos) horas de trabajo (sin duración) en completarse. Debido a algunas dependencias y al riesgo de cronograma y presupuesto involucrado, cree que es prudente agregar una reserva intermedia al final de este paquete de trabajo, además de un margen general al final del proyecto.

¿Cómo determina o calcula este margen de paquete de trabajo individual ?

Lo usas:

  • 2 x la desviación estándar, como propone Mike Cohn en su libro "Agile planning and Estimating", capítulo 17.
  • PERT (en ese caso, también necesita una estimación optimista): calcular el valor esperado para el cronograma y una desviación estándar de 2 x para el margen
  • Solo la diferencia entre el más probable y el promedio de los dos
  • Simulación de Monte Carlo, pero esto calcula el margen de programación para todo el proyecto. ¿Cómo puedo determinar qué márgenes intermedios usar?
  • Cualquier otra fórmula

¿Y cuál sería su justificación para el método propuesto? Y tu tasa de éxito ;-)

Gracias

¿Existen puntos de referencia para esta actividad en toda la industria o internamente?
Podría ser internamente, pero no necesariamente. Todo el conocimiento disponible se tiene en cuenta en la estimación.

Respuestas (5)

Para mí, la verdadera pregunta es qué tan buenas son sus estimaciones. Si son conjeturas salvajes, nada los salvará realmente.

De todos modos, no me gusta:

  • Solo la diferencia entre el más probable y el promedio de los dos. Parece una fórmula mágica que realmente no puedo respaldar con datos razonables.

  • IMPERTINENTE. Probablemente debería aumentar un poco sus estimaciones originales, pero este enfoque aún se basa solo en algunas estimaciones y no en datos concretos.

Otros dos me parecen mejores pero también son más complicados:

  • Desviación Estándar. Para saber cuál es su desviación estándar, necesita usar datos históricos para las tareas que ha completado. Por esta única razón, es un método mejor que los dos anteriores.

  • Monte Carlo. Con este no estoy seguro de cuál es tu enfoque. Nuevamente, este es un método que se basa en algunos datos duros, por lo que espero que haga una simulación de Monte Carlo utilizando estimaciones históricas y tiempos de trabajo reales. Si es así, ¿por qué no basa las estimaciones en la simulación de Monte Carlo en lugar de calcular el búfer de esta manera?

Si no me estoy perdiendo algo, necesita usar datos históricos (estimaciones versus tiempos de trabajo reales) al menos en un par de métodos propuestos. Si es así, mi idea sería utilizar la simulación de Monte Carlo contra sus estimaciones para calcular nuevas y mejores estimaciones que incluyan su historial. Hay un excelente artículo sobre programación basada en evidencia que describe cómo puede hacerlo.

En este caso, trabajaría en el horario con el que te sientas bien (cualquiera que sea el nivel de probabilidad que te haga sentir bien). Luego, si necesita alguna captura de seguridad adicional, agregaría búferes que se basan en el cronograma con mayor probabilidad de éxito. Por ejemplo, después de la simulación de Monte Carlo, obtiene los siguientes resultados: 70 % de probabilidad de que complete el paquete de trabajo en 390 horas y 90 % de probabilidad de que suceda en 475 horas, por lo que tiene 85 como búfer.

Si desea dividir este búfer en un par de partes después de realizar algún trabajo, simplemente divida su paquete de trabajo en partes más pequeñas y realice el mismo análisis para ambas partes de forma independiente y agregue el resultado al final de cada una.

Nota: Preferiría simplemente ir con un programa de probabilidad del 90% en lugar de agregar búferes a uno menos probable.

Utilizo un enfoque bastante similar a la programación basada en la evidencia y demostró ofrecer resultados bastante buenos siempre que los datos históricos sean confiables, por lo que ese sería mi método de elección.

Gracias Pawel. Buenos puntos para pensar. Una probabilidad del 90 % sería buena para los proyectos internos, pero ¿no sería poco competitivo para los externos?
Los porcentajes eran de la parte superior de mi cabeza. Usted y su empresa deben decidir qué probabilidad consideran razonable, es decir, no muy riesgosa pero lo suficientemente baja como para ser competitiva. Además, muchas veces las razones para no ser competitivo no están dentro del cronograma en sí, sino que son impuestas por la forma en que funciona la organización en su conjunto.

Encontré una excelente publicación de blog de Glen Alleman relacionada con este tema, en particular sobre cómo usar el análisis de Monte Carlo para calcular el margen de riesgo.

Puedes encontrarlo aquí .

Su enfoque es sobresaliente.
Sí. Definitivamente. ¡Tengo un largo camino por recorrer (y mucho que aprender) para estar a la altura de sus estándares!
Él escribe para agregar el delta entre el programa determinista y el nivel de confianza del 80% del programa probabilístico como margen... pero ¿cómo? ¿Tareas de amortiguamiento? ¿Cómo se ve eso y cómo lo construyes?
Creo que estos son amortiguadores de tiempo (duración), no amortiguadores de presupuesto. Supongo que son tareas sin asignaciones. No parece haber una regla general para determinar la duración de los búfer "en línea", eso lo decidirá el PM. Pero deberían totalizar hasta el búfer del proyecto calculado.

¿Qué es el "tampón intermedio"? ¿Qué es el "margen global al final del proyecto"? No existe tal cosa como "margen" para un paquete de trabajo.

Los términos usados ​​en la pregunta indican que se usa relleno , lo cual es un problema. Para evitar el relleno y mantener su cronograma/costo realista, debe realizar una gestión de riesgos . Identifique y documente todos los eventos negativos y positivos (!) que, si ocurren, pueden cambiar el costo y/o la duración de su paquete de trabajo. Estimar la probabilidad y el impacto de estos eventos. Manipúlelos todos juntos fuera de su paquete de trabajo. Todos juntos afectarán sus reservas de contingencia:

ingrese la descripción de la imagen aquí

La imagen está tomada de Rita's Course, 6.ª edición , página 238.

Eche un vistazo a esta cita también (página 189, misma fuente):ingrese la descripción de la imagen aquí

'búfer intermedio' = un búfer en algún lugar en el medio del cronograma, para permitir el riesgo y las dependencias; "margen general" = un búfer entre la fecha de finalización prevista y la fecha de finalización comprometida. ¡No OCULTO los buffers, al contrario, los hago explícitos! Me temo que tu interpretación es incorrecta.
No debería tener ningún búfer en su horario/costo. Es la interpretación de PMBOK, no la mía.
Siempre que los amortiguadores de contingencia estén "claramente identificados en la documentación del cronograma", al PMBOK no le importa. Además, Critical Chain es una de las técnicas de planificación descritas, que se basa en añadir buffers para gestionar la incertidumbre. Hago algo similar, programo con estimaciones más probables, agrego amortiguadores donde el riesgo de cronograma es alto.
No hay buffers en Schedule, de acuerdo con PMBOK (si me equivoco, proporcione un número de página dentro de PMBOK). "Agregar amortiguadores para gestionar la incertidumbre" se denomina relleno y debe evitarse por completo en la gestión de proyectos.
Me temo que nos malinterpretamos. "Relleno" es agregar un búfer a las estimaciones individuales, pero representándolo como una sola figura. Ocultar el búfer, de hecho. No escondo nada. Por el contrario, debido a que trabajo con un rango de estimaciones, en lugar de una estimación puntual única, elimino el posible "relleno" de la estimación más baja (la más probable). Cualquier búfer que calcule se presenta aparte de mi estimación y es un presupuesto separado. Por cierto, me puede dar el número de página donde se explica "relleno" en PMBOK, estaría muy agradecido.
@Stephan Actualicé mi respuesta con una cita de Rita's Course 6th Ed. Espero que ayude.

Usaría la diferencia entre un promedio ponderado aproximado del caso más probable y peor (320 y 480) y el más probable (320). Los pesos para cada uno dependerían de qué tan grave sea la desventaja si la tarea se retrasa.

Por ejemplo, mencionó el riesgo presupuestario. Si el costo de llegar tarde fuera enorme, utilice una ponderación del 10 % y el 90 % para el caso más probable y el peor, respectivamente. Si la desventaja no es tan mala 50/50 y si es mínima 90/10

He usado este enfoque muchas veces (principalmente para cálculos internos) ya que tiene en cuenta el impacto potencial de las tardanzas y le da espacio.

Lo que creo que es muy interesante en ese sentido es lo que Jurgen Appelo describió en su blog: http://www.noop.nl/2009/07/your-project-will-suffer-from-power-laws.html

Es posible que desee considerar eso también, ya que contiene mucha información.

¿Cómo calcular el margen presupuestario?
RespuestasAquíPolítica de privacidad1y, 1v