Fórmula de tiempo esperado (PERT): estimar sin adivinar

Cuando le preguntas a alguien cuánto tarda una tarea, la respuesta es un número. Ese número arrastra dos sesgos conocidos: el optimismo (subestimamos lo que no hemos hecho antes) y el anclaje (la primera cifra mencionada contamina todas las demás). El resultado lo conoces: proyectos que «siempre» salen tarde aunque cada estimación individual sonaba razonable.

La respuesta defensiva típica es inflar: «dilo por el doble». Pero el colchón tiene sus propios problemas: se nota, se negocia, y en tareas con riesgo real ni el doble alcanza. La tercera vía es la que formalizó el PERT en los años cincuenta para el programa Polaris: en vez de un número, pedir tres escenarios y combinarlos con una fórmula. El costo es pedir dos datos más; el beneficio es que la incertidumbre deja de estar escondida en el colchón y se vuelve visible.

La fórmula de tiempo esperado del PERT es: TE = (O + 4M + P) / 6. Donde O es la estimación optimista (todo sale bien a la primera), M es la más probable (una semana normal, interrupciones incluidas) y P es la pesimista (el escenario malo realista, no la catástrofe).

El 4 que multiplica a M es el corazón del modelo: pesa cuatro veces el escenario típico porque, en la distribución que asume el PERT, es el que más se repite; los extremos corrigen por exceso de confianza y por riesgo. El 6 es solo la suma de los pesos (1 + 4 + 1). Nada más y nada menos: el resultado es un promedio ponderado donde lo probable manda y los extremos ajustan.

La fórmula tiene una compañera que casi nadie usa y es la más útil: la desviación estándar, σ = (P − O) / 6. Mide la incertidumbre de la tarea: una σ pequeña dice que los tres escenarios coinciden y la estimación es firme; una σ grande avisa de que la tarea puede irse en cualquier dirección y merece atención antes que las demás.

Toma una tarea con O = 2 días, M = 4 días y P = 10 días (rehacer una pantalla que toca un módulo viejo, por ejemplo). El tiempo esperado es:

TE = (2 + 4 × 4 + 10) / 6 = 28 / 6 ≈ 4,67 días. Y su desviación estándar: σ = (10 − 2) / 6 ≈ 1,33 días. Esa σ es alta a propósito: la brecha entre 2 y 10 días delata que nadie sabe bien cuánto duele el módulo viejo, y eso ya es información accionable. Ahora el mismo cálculo sobre un paquete de tres tareas:

Dos detalles que evitan errores comunes. Primero: los TE sí se suman —el paquete espera 12 días—, pero las σ no: la incertidumbre del conjunto se calcula con raíz de la suma de cuadrados, √(1,33² + 0,33² + 1²) ≈ 1,7, así que un rango honesto para comprometerse es «12 días, con margen razonable de ±2». Segundo: si una sola tarea domina la σ total, esa es la que hay que partir en pedazos o investigar primero.

La fórmula rinde donde la incertidumbre es real y el compromiso es externo:

• Tareas de alto riesgo, las que tienen σ grande por definición: usar PERT solo en ellas es el mejor retorno por minuto invertido.
• Hitos con compromiso externo: una fecha prometida a un cliente o a la dirección merece más que una corazonada; el TE con su rango da algo que se puede defender en una reunión.
• Decisiones de comprar o posponer: si el TE de la alternativa interna duplica el plazo del proveedor, la discusión cambia de tema antes de gastar un peso.

Y es humo cuando se aplica por disciplina en lugar de por utilidad. Estimar todo el backlog con tres escenarios cuesta más de lo que aporta: en tareas rutinarias tu histórico ya es mejor estimador que la fórmula. También es humo sin materia prima: si nadie puede distinguir razonablemente O, M y P, el resultado con dos decimales es precisión de mentira. Y si tu equipo ya trabaja por flujo —por ejemplo con scrumban y su lead time histórico—, gran parte de la estimación simplemente deja de ser necesaria: el sistema predice por ti.

En su versión completa, el PERT nunca fue solo la fórmula: era la fórmula más la red. Cada actividad tiene su tiempo esperado; las actividades se encadenan con sus dependencias; y la cadena más larga de la red —la ruta crítica— define la duración del proyecto. El margen (slack) de cada tarea indica cuánto puede retrasarse sin mover la fecha final.

Para un proyecto chico eso se traduce en algo muy simple: calcula el TE de tus tareas, ponlas en orden de dependencia y mira qué cadena suma más. Esa cadena es donde cualquier σ grande se paga con días de retraso, así que es ahí donde conviene bajar incertidumbre primero. El método paso a paso, con o sin PERT, está en cómo calcular la ruta crítica de un proyecto.

La fórmula es honesta solo si sus entradas lo son. Cuatro reglas:

1. Define las anclas por escrito. O significa «todo sale bien a la primera», M «una semana normal con interrupciones» y P «el mal escenario realista». Sin definición compartida, cada quien cotiza en su propio idioma y la fórmula hereda el ruido.
2. Pídelas por separado y sin verlas entre sí. Si anuncias la más probable primero, las otras dos orbitan alrededor; si anuncias el deadline, las tres orbitan a su alrededor. Orden sugerido: O, luego P, y M al final.
3. Ancla con histórico, no con memoria. Cuánto tardaron las últimas tres tareas parecidas vale más que la sensación de quien la hizo. El sistema completo para construir ese histórico está en cómo estimar tiempos de un proyecto.
4. Cierra el ciclo. Anota el TE antes de empezar y la duración real al terminar. Sin comparación posterior el equipo nunca calibra, y las σ de tu proyecto no aprenden de su propio historial.

Y si quieres registrar estimaciones, checklists y cierre de cada tarea en una herramienta que vive en tu carpeta —JSON local, sin cuenta ni asientos, con checklists y procesos para repetir lo que ya te salió bien— Hito está pensado para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — estima con anclas, ejecuta con checklists, todo local-first.