Cono de la incertidumbre: por qué las estimaciones tempranas fallan

Por Tara Minh · Actualizado el 10 de octubre de 2026

El cono de la incertidumbre es un modelo que muestra que las estimaciones de un proyecto son menos confiables al inicio y solo se vuelven más confiables a medida que se resuelven las incógnitas. La versión de Steve McConnell sitúa las estimaciones tempranas de software entre 0.25x y 4x del resultado final, y el rango se estrecha hacia 1.0x conforme se toman decisiones.

Datos Clave

• 4x en ambas direcciones: Las estimaciones hechas en la etapa de Concepto Inicial pueden desviarse por un factor de 4x por arriba o 4x por abajo (0.25x), una dispersión de 16x entre el valor más bajo y el más alto, según el white paper sobre el cono de la incertidumbre de Construx.
• Mejor caso, no una promesa: El cono muestra la mejor precisión que pueden alcanzar estimadores expertos. Hacerlo peor es fácil, y ser más preciso solo es posible con algo de suerte (mismo documento de Construx).
• Origen subjetivo: Barry Boehm dibujó la primera versión en su libro de 1981 Software Engineering Economics, y sus rangos se fijaron a criterio como límites de confianza del 80%, no se midieron a partir de datos de proyectos (Bossavit, The Leprechauns of Software Engineering).
• Estrechar es trabajo: La mayor parte del estrechamiento ocurre en aproximadamente el primer 20 al 30% del tiempo calendario, y solo porque el equipo toma decisiones que eliminan variabilidad (Construx).

¿Qué es el cono de la incertidumbre?

Imagine un embudo tumbado de lado. A la izquierda, al inicio del proyecto, es ancho. A la derecha, cerca de la entrega, termina en punta. El eje vertical indica qué tan lejos puede estar una estimación de esfuerzo, costo, cronograma o alcance de lo que finalmente se entrega. El eje horizontal es el tiempo, marcado por hitos: concepto inicial, definición de producto aprobada, requisitos completos, diseño completo y terminado.

La idea es simple. Al inicio de un proyecto no sabe exactamente qué está construyendo, quién lo construirá, qué riesgos aparecerán ni qué requisitos cambiarán. Cada una de esas incógnitas añade variación a la estimación. A medida que cada una se define, el rango plausible de resultados se reduce.

Esa es la parte que todos citan. La parte que omiten es lo que McConnell dice justo al lado: la incertidumbre no se reduce porque pase el tiempo. Se reduce porque alguien tomó una decisión. El white paper de Construx lo dice sin rodeos: la única forma de reducir la variabilidad de la estimación es reducir la variabilidad del propio proyecto. Pedirle a un equipo "una semana más para afinar la estimación" no sirve si nada del proyecto se definió durante esa semana.

De dónde viene el cono

Barry Boehm esbozó la primera versión en Software Engineering Economics (1981) y la llamó curva de embudo. En la etapa más temprana, las estimaciones podían fallar por un factor de 4 en cualquier dirección: el white paper de Construx de McConnell fija el rango del Concepto Inicial en 4x por arriba y 0.25x por abajo, una dispersión de 16x.

Steve McConnell le dio después el nombre de "cono de la incertidumbre" y lo incorporó a sus libros sobre estimación, entre ellos Software Estimation: Demystifying the Black Art (Microsoft Press, 2006). Construx, la empresa que fundó, todavía publica el modelo como white paper.

Aquí va la salvedad honesta. El análisis de Laurent Bossavit sobre la historia del cono concluyó que los rangos de Boehm surgieron del criterio, no de un conjunto de datos medido. Bossavit también señala los datos de Todd Little de 2006, tomados de informes de estado de proyectos reales y publicados en IEEE Software, que no coincidían con el embudo simétrico. Los proyectos reales se retrasan mucho más a menudo de lo que se adelantan, y muchos se quedan en "90% terminado" durante un largo periodo.

La respuesta de McConnell, en el documento de Construx, es que el cono es el mejor caso y que los proyectos mal gestionados generan una "nube" de incertidumbre que nunca se estrecha. Por eso conviene tratar el cono como un modelo didáctico útil y una disciplina de planificación, no como una ley estadística. Su lección práctica se mantiene de todos modos: las cifras tempranas merecen rangos amplios.

Cono de la incertidumbre frente a otros conceptos de estimación

El cono no es una técnica de estimación. Es una lente para juzgar cuánta confianza darle al resultado de cualquier técnica en un momento dado. Por eso se complementa con los métodos de abajo, en lugar de reemplazarlos.

Una regla práctica útil: elija el método cuya precisión corresponda al ancho del cono. Una estimación ascendente al nivel de la hora es falsa precisión en el concepto inicial. Una estimación análoga aproximada es un desperdicio cuando el diseño ya está terminado y el alcance cerrado.

Por qué las estimaciones tempranas fallan

Es tentador culpar al estimador. Por lo general, el estimador no es el problema. Cuatro factores ensanchan el cono al inicio.

Los requisitos son vagos. "Construir un portal de clientes" puede significar una página de inicio de sesión y una lista de facturas, o una plataforma de autoservicio completa con pagos. Ambas son lecturas honestas. La diferencia de esfuerzo entre ellas es enorme.

El alcance es un blanco móvil. Las partes interesadas agregan y quitan funcionalidades cuando ven algo real. Es la expansión del alcance en su forma temprana, antes de que exista siquiera una línea base de la cual desviarse.

Las dependencias son desconocidas. Todavía no sabe que el equipo de pagos tiene una cola de seis semanas, o que el sistema heredado necesita reescribirse antes de poder integrarlo.

El equipo no está consolidado. Las habilidades, la disponibilidad y la velocity son suposiciones hasta que las personas han trabajado juntas en el proyecto real.

Luego está la capa humana. El optimismo es la opción por defecto, y una cifra dicha en voz alta en una reunión tiende a convertirse en promesa. Si un patrocinador oye "unos cuatro meses" en el concepto inicial, esa cifra termina en un plan, un presupuesto y a veces un contrato con el cliente. Nadie recuerda que venía con un rango de "uno a dieciséis".

Construx lo señala como el verdadero peligro. Las organizaciones que se comprometen mientras el cono sigue ancho, en sus palabras, socavan la previsibilidad y aumentan el riesgo. Comprometerse en el concepto inicial o en la definición del producto significa convivir con un error de estimación de 2x a 4x.

Cómo usar el cono de la incertidumbre (paso a paso)

No puede hacer desaparecer el cono, pero sí puede usarlo de forma deliberada. Esta es una secuencia de trabajo.

Paso 1: Nombre la etapa con honestidad

Decida dónde está hoy el proyecto: idea inicial, alcance aprobado, requisitos completos, diseño completo o construcción. Sea crítico. Un proyecto con presupuesto aprobado y un documento de requisitos a medio escribir sigue estando en el extremo ancho.

Paso 2: Dé un rango, no un punto

Convierta su mejor estimación en un valor mínimo y uno máximo. En el concepto inicial, el modelo de Construx permite de 0.25x a 4x, así que una estimación intuitiva de 100 días se convierte en 25 a 400 días. Eso se ve absurdo en una diapositiva, y ese es el punto. Si la brecha alarma a la gente, aceptarán el trabajo que la estrecha.

Para rangos a nivel de tarea, la estimación de tres puntos le ofrece una forma defendible de obtener los valores bajo, probable y alto.

Paso 3: Liste las incógnitas que crean el ancho

Anote cada pregunta abierta que mueva la estimación: requisitos sin definir, integraciones desconocidas, dotación de personal sin confirmar, tecnología sin probar. Ordénelas según cuánto rango añade cada una. Esta lista también es el comienzo de su registro de riesgos.

Paso 4: Programe el trabajo que elimina incógnitas

Trate el descubrimiento como entregables. Defina la visión del producto, incluido lo que queda fuera del alcance. Complete los requisitos. Haga un prototipo de la interfaz más riesgosa. Ejecute un spike técnico sobre la integración que nadie ha probado. Cada una de estas acciones elimina variabilidad, y cada una debe tener un responsable y una fecha.

Paso 5: Retrase el compromiso firme

La guía de McConnell es que no son posibles compromisos significativos en la parte temprana y ancha del cono, y que las organizaciones eficaces esperan hasta haberlo forzado a estrecharse. Su documento describe como posibles y adecuados los compromisos asumidos cerca del 30% del avance del proyecto. Si el negocio necesita una cifra antes, entregue el rango y etiquételo como rango.

Paso 6: Reestime en cada hito

Vuelva a hacer la estimación cada vez que se resuelva una incógnita importante, no según el calendario. Compare cada nuevo rango con el anterior. Si no se está estrechando, tiene una nube, y el proyecto necesita una conversación sobre alcance, dotación de personal o enfoque.

Paso 7: Fije la línea base cuando el rango sea estrecho

Cuando el rango sea lo bastante estrecho para que el patrocinador lo financie y el equipo se comprometa, regístrelo como la línea base del proyecto. A partir de ahí, dé seguimiento a la variación frente a esa cifra.

Plantilla lista para copiar: seguimiento del rango de estimación

Copie esta tabla en su plan de proyecto y actualícela en cada hito. La columna "Ancho" es simplemente el valor alto dividido entre el bajo, y muestra de un vistazo si el cono se está estrechando.

Cómo completarla:

1. Bajo y alto provienen de estimaciones de tres puntos sumadas en todo el trabajo, o de aplicar los multiplicadores del cono a una única mejor suposición.
2. Incógnitas resueltas es una lista simple de las decisiones tomadas desde la fila anterior. Si esta celda está vacía y el ancho no cambió, es lo esperado.
3. ¿Compromiso permitido? es una columna de política. Acuérdela con su patrocinador desde el principio para que nadie discuta al respecto al comenzar.

Si la columna de ancho deja de bajar durante dos hitos seguidos, escale el tema. Algo en el proyecto no está convergiendo.

Ejemplos por función de negocio

El cono no se limita al software. Cualquier trabajo con alcance indefinido y pasos desconocidos se comporta así. Las cifras de abajo son aritmética ilustrativa que aplica los multiplicadores de la etapa temprana (0.25x a 4x) a una primera suposición aproximada, no son benchmarks.

Tomemos el lanzamiento de marketing. "Ocho semanas" parece razonable hasta que pregunta qué incluye. Si el brief no está aprobado, quién aprueba los textos y si legal debe revisar las afirmaciones, entonces "ocho semanas" es una esperanza. Una vez fijados el brief, el mapa del sitio y la cadena de aprobación, ese mismo proyecto podría cotizarse honestamente en seis a diez semanas.

La misma lógica se aplica a un despliegue de operaciones. Antes de mapear procesos, una cifra de $200,000 no tiene más fundamento que una de $600,000. Después del mapeo y de una lista corta de proveedores, el rango podría estrecharse a algo que un director de finanzas pueda firmar.

El cono y los equipos Agile

Una objeción común: "Somos Agile, así que el cono no aplica". Aplica de otra forma, no deja de aplicar.

El propio documento de Construx dice que en los proyectos iterativos se atraviesa un cono en miniatura en cada iteración. Antes del trabajo de requisitos de una iteración, se está en la parte del cono correspondiente a la definición del producto aprobada. Con iteraciones cortas, un equipo puede pasar por requisitos y diseño de UI en pocos días, reduciendo la variabilidad de 4x a 1.6x para esa porción de trabajo. Si el cronograma es fijo, esa variabilidad se manifiesta como incertidumbre sobre qué funcionalidades caben, no sobre la fecha final.

Lo que se sacrifica, señala el documento, es la previsibilidad a largo plazo del costo, el cronograma y las funcionalidades combinados varias iteraciones más adelante. Muchos equipos optan por un punto intermedio: definir la mayoría de los requisitos al inicio y luego construir en iteraciones cortas. El documento afirma que eso reduce la variabilidad del cono a alrededor de más o menos 25%.

En la práctica, esto significa que los equipos Agile siguen necesitando rangos para los roadmaps y las fechas de lanzamiento, y que los métodos de dimensionamiento relativo como los story points funcionan mejor para el trabajo de corto plazo. Los elementos lejanos merecen un dimensionamiento grueso y un honesto "sabremos más después".

Qué hacer y qué evitar con el cono de la incertidumbre

Qué hacer

• Cite rangos desde el principio. Diga "de cuatro a dieciséis meses" en el concepto, no "ocho meses". Un rango lo protege y educa al patrocinador.
• Vincule el estrechamiento con decisiones concretas. Cada fila de su seguimiento debe mostrar qué se resolvió desde la última estimación.
• Reestime en los hitos. Una nueva estimación una vez completos los requisitos vale más que una actualización mensual que no aporta nada nuevo.
• Use los rangos para priorizar el descubrimiento. La incógnita que más ancho añade se trabaja primero.
• Separe las estimaciones de los compromisos. Una estimación es lo que usted espera. Un compromiso es una promesa. No deben confundirse en la misma frase.
• Combine el cono con un método cuantitativo como la simulación Monte Carlo cuando tenga suficiente detalle para modelar.

Qué evitar

• No trate el cono como algo automático. El paso del tiempo no lo estrecha. Las decisiones sí, y el documento de Construx dice que el cono puede convertirse en nube cuando un proyecto no se controla bien.
• No prometa una precisión que el modelo no puede dar. Ni siquiera los estimadores expertos pueden superar el cono. Solo pueden fallar por más.
• No comprima el rango para complacer a un patrocinador. Una cifra más ajustada sin información nueva detrás es solo un riesgo mayor.
• No ignore el sesgo. Los proyectos reales se retrasan más a menudo de lo que se adelantan, así que no suponga que los extremos bajo y alto son igual de probables. Incline su rango hacia el lado pesimista.
• No deje que una estimación puntual salga de la sala. Cuando "unos cuatro meses" aparece en un correo sin su rango, ya es una promesa.
• No use un método preciso en una etapa vaga. Las estimaciones ascendentes al nivel de la hora sobre un concepto de una página son teatro.

Errores comunes con el cono

Algunos equipos oyen "las estimaciones son poco fiables al inicio" y concluyen que planificar no sirve. Sí sirve. El cono dice que se planifique en proporción a lo que se sabe, y que el esfuerzo inicial se dedique a resolver las incógnitas más grandes en lugar de pulir una cifra.

Otros toman la forma simétrica demasiado al pie de la letra. La crítica de Bossavit es un buen recordatorio de que un diagrama limpio no es prueba de una distribución limpia. Use los multiplicadores como punto de partida para una conversación y luego ajústelos según su propio historial. Si los proyectos pasados de su organización han superado el presupuesto en un 40% en promedio, inclúyalo.

Un tercer error es usar el cono para excusar la falta de una línea base. Una vez que el alcance y el diseño son estables, el cono ya cumplió su función. En ese punto, la variación respecto de la línea base es un asunto de gestión, no de incertidumbre. Los equilibrios entre alcance, cronograma y costo pasan a ser la conversación correcta.

Conclusiones clave

El cono de la incertidumbre le da una respuesta defendible a una pregunta que todo patrocinador hace: "¿Cuánto tiempo tomará?". La respuesta honesta al inicio es un rango, y el ancho de ese rango es información. Estréchelo tomando decisiones, no esperando. Posponga los compromisos firmes hasta que el cono se haya estrechado. Y revise sus cifras cada vez que se resuelva una incógnita real.