Estimar un proyecto no es adivinar: duración, coste y recursos

Al inicio de un proyecto, una de las primeras preguntas que suelen plantear clientes, patrocinadores y responsables de negocio es también una de las más difíciles de responder: ¿cuánto tardará y cuánto costará?

La necesidad de obtener una respuesta rápida lleva a menudo a confundir una estimación con una promesa. Sin embargo, en ese momento todavía no contamos con la información necesaria: no conocemos todos los requisitos, pueden surgir nuevos riesgos y, a veces, ni siquiera sabemos qué recursos estarán disponibles.

Por eso, estimar un proyecto no consiste en comprometer una fecha exacta, sino en tomar mejores decisiones con la información disponible en cada momento.

Lo cierto es que, cuando hablamos de estimaciones, tendemos a pensar únicamente en plazos y costes. Pero una estimación también debe considerar el esfuerzo necesario, los recursos que participarán en el proyecto y el grado de incertidumbre asociado.

En este artículo veremos qué significa realmente estimar un proyecto y algunas técnicas sencillas que pueden ayudarnos a hacerlo con mayor criterio.

1. Por qué estimar no es adivinar

– Necesito una estimación para el viernes

Es una petición habitual en las primeras fases de un proyecto. Y, en muchas ocasiones, lo que empieza siendo una solicitud razonable termina convirtiéndose en una negociación de fechas.

Alguien pregunta cuánto tiempo puede durar el proyecto. Se ofrece una primera aproximación y, a partir de ahí, la conversación cambia: la estimación empieza a interpretarse como una promesa y, poco después, acaba convirtiéndose en un compromiso cerrado.

Sin embargo, una estimación no es una promesa. Tampoco un deseo y, desde luego, no debería tratarse como una fecha fijada en piedra.

Un deseo es aquello que nos gustaría que ocurriera. Una promesa es un compromiso que asumimos. Una estimación, en cambio, es una valoración de lo que creemos que puede ocurrir en ciertas condiciones.

La diferencia parece sutil, pero tiene consecuencias importantes. Al inicio de un proyecto existen dudas, riesgos, dependencias y supuestos que pueden cambiar a medida que avanzamos. La incertidumbre no es algo excepcional, es consustancial a cualquier proyecto.

Por eso, cuando tratamos una estimación como un acuerdo cerrado, corremos el riesgo de interpretar cualquier desviación como un fallo de la estimación, cuando en realidad puede deberse a nuevos datos que simplemente desconocíamos.

Estimar consiste en construir la mejor aproximación posible con la información que tenemos hoy, sabiendo que probablemente tendremos que revisarla mañana.

2. Qué se estima realmente en un proyecto

Estimar un proyecto implica diferenciar duración, coste, esfuerzo y recursos. Están relacionados, pero no son lo mismo, y confundirlos puede llevar a planes poco realistas.

Por eso conviene analizarlos por separado antes de hablar de fechas, presupuesto o compromisos de entrega.

2.1 Duración

La duración responde a la pregunta: ¿cuánto tiempo tardará el proyecto?

Pero no depende solo del trabajo que haya que hacer, sino de cuándo pueden hacerlo las personas implicadas, de las dependencias entre tareas y de los bloqueos que puedan aparecer.

2.2 Coste

El coste intenta responder a otra pregunta: ¿cuánto dinero necesitaremos para llevar a cabo el proyecto?

Aquí entran las horas de trabajo, proveedores, licencias, materiales, herramientas, desplazamientos o cualquier otro gasto del proyecto. El error habitual es calcular el coste solo a partir de una cifra global, sin entender bien qué hay detrás.

2.3 Esfuerzo

El esfuerzo es la cantidad de trabajo necesaria para completar una actividad o un entregable.

Y aquí conviene hacer una distinción importante: esfuerzo y duración no son lo mismo. Duración es el tiempo que pasa en el calendario hasta que ese trabajo termina.

Por ejemplo, una tarea puede requerir 80 horas de esfuerzo. Si una persona puede dedicarle 40 horas por semana, la duración será de unas dos semanas. Pero si solo puede dedicarle 20 horas por semana, la duración será de unas cuatro semanas.

El esfuerzo no cambia; lo que cambia es el tiempo necesario para completarlo. Por eso no conviene confundir horas de trabajo con tiempo calendario.

2.4 Recursos: quién hará el trabajo y con qué disponibilidad real

Esta es una de las partes que más se suelen pasar por alto. No basta con calcular que un trabajo requiere 300 horas de trabajo. La pregunta importante es quién va a realizarlas y en qué condiciones reales de disponibilidad.

No es lo mismo contar con una persona dedicada al 100% que con alguien que solo puede dedicar unas horas a la semana. Tampoco es lo mismo disponer desde el inicio de los perfiles adecuados que descubrir más adelante que falta capacidad técnica, participación de un usuario clave o disponibilidad para tomar decisiones.

Por eso, podemos estimar el esfuerzo antes de tener cerrada la asignación de recursos, pero la duración del proyecto dependerá de quién realizará el trabajo, de su disponibilidad real y de si tiene la capacidad necesaria para hacerlo.

En muchos proyectos, el problema no es que la estimación de horas fuera disparatada, sino haber dado por supuesta una disponibilidad de recursos que luego no se cumple.

3. Ejemplo práctico: implantación de un CRM en una empresa

Veamos un ejemplo aplicado. Imaginemos una empresa de distribución con 50 empleados que ha decidido implantar un nuevo CRM para centralizar la gestión comercial.

Lo que conocemos	Lo que aún desconocemos
50 empleados utilizarán el CRM	Calidad de los datos a migrar
Procesos comerciales identificados	Integraciones necesarias
Herramientas actuales conocidas	Peculiaridades de cada departamento
Objetivos de negocio definidos	Resistencia al cambio

Actualmente, los equipos trabajan con hojas de cálculo, bases de datos dispersas y procesos diferentes según el departamento. La dirección quiere mejorar el seguimiento de clientes y oportunidades comerciales, disponer de información más fiable y reducir tareas manuales.

Antes de aprobar el proyecto, surge la pregunta esperada: ¿Cuánto tiempo tardará, cuánto costará y qué recursos necesitaremos para implantar el nuevo sistema? Plantear la pregunta es sencillo. Responderla, no tanto.

Conocemos algunos aspectos relevantes. Sabemos aproximadamente cuántos usuarios utilizarán la herramienta, los principales procesos comerciales que deberán gestionarse en el CRM y las aplicaciones que actualmente utiliza la empresa.

Sin embargo, todavía hay aspectos que desconocemos. No sabemos cuál es la calidad real de los datos que habrá que migrar, qué integraciones serán necesarias con otros sistemas, las peculiaridades de cada departamento o el nivel de resistencia al cambio que encontraremos durante la implantación.

Con este punto de partida, la cuestión no es establecer una fecha o un presupuesto exactos, sino proporcionar una estimación lo suficientemente fiable para tomar decisiones.

4. Estimación paramétrica: utilizar los datos para mejorar las estimaciones

Cuando necesitamos estimar una actividad, una opción habitual es buscar un proyecto parecido y utilizarlo como referencia. Eso sería una estimación análoga.

La estimación paramétrica va un paso más allá. En lugar de basarse en un único caso anterior, utiliza datos históricos para identificar una relación medible entre una variable y el esfuerzo, la duración o el coste.

Por ejemplo, imaginemos una empresa de traducción que ha comprobado en trabajos anteriores que existe una relación bastante estable entre el número de palabras y las horas necesarias para traducir un documento.

Si los datos muestran que traducir 10.000 palabras requiere unas 24 horas y 20.000 palabras unas 47 horas, podemos utilizar esa relación para estimar un nuevo trabajo de 18.000 palabras con más criterio que si nos basáramos solo en la intuición.

La clave no está en utilizar una fórmula compleja, sino en contar con datos comparables y una relación suficientemente estable.

Aún así, este tipo de estimación también tiene límites. Si los datos históricos son escasos o poco fiables, la fórmula puede dar una sensación de precisión que no es real.

5. Estimación PERT: cuando existen diferentes escenarios

Volvamos al proyecto de implantación del CRM.

Uno de los trabajos más críticos consiste en migrar la información desde los sistemas actuales al nuevo CRM. Puede parecer una tarea relativamente sencilla, pero todavía hay cosas que desconocemos: la calidad de los datos, posibles duplicidades o problemas de compatibilidad entre sistemas.

En situaciones como esta resulta difícil proporcionar una única estimación fiable. Por eso, PERT plantea tres escenarios: optimista, probable y pesimista, para obtener una estimación más realista.

Supongamos que el equipo plantea las siguientes estimaciones para la migración de datos:

• Escenario optimista: 5 días.
• Escenario más probable: 10 días.
• Escenario pesimista: 20 días.

La técnica PERT combina estos tres escenarios mediante la siguiente fórmula:

(Optimista + 4 × Más probable + Pesimista) ÷ 6

Aplicando los valores anteriores:

(5 + 4 × 10 + 20) ÷ 6

Duración estimada PERT: 10,8 días

Más allá del resultado, lo interesante es el razonamiento que hay detrás.

PERT no intenta adivinar cuánto durará realmente una actividad ni eliminar la incertidumbre. Lo que hace es reconocer que pueden darse diferentes escenarios e incorporarlos a la estimación.

En lugar de actuar como si todo fuera a salir exactamente según lo previsto, nos obliga a reflexionar sobre qué podría ir mejor de lo esperado y qué podría complicarse durante la ejecución.

Si quieres profundizar en el funcionamiento de esta técnica, puedes consultar el artículo específico que publiqué sobre el método PERT.

6. Qué hacer cuando la estimación deja de ser válida

Hasta ahora hemos visto distintas formas de estimar un proyecto. Sin embargo, existe una realidad que ningún director de proyecto debería olvidar: tarde o temprano aparecerá información que no conocíamos cuando hicimos la estimación inicial.

Sigamos con el ejemplo del CRM.

Durante las primeras semanas descubrimos que hay datos duplicados, algunas integraciones son más complejas de lo previsto y algunos departamentos tienen necesidades que no se habían identificado al inicio.

En ese momento, la estimación original deja de reflejar la realidad del proyecto y a pesar de ello, lo más habitual es intentar mantener el plan inicial a toda costa.

«Cuando estás en un hoyo, lo primero que debes hacer es dejar de cavar»

Lo más razonable es parar, ver qué ha cambiado y actualizar nuestra estimación con la nueva información disponible. Al fin y al cabo, una estimación es tan válida como los supuestos en los que se apoya. Cuando estos cambian, también debería hacerlo la estimación.

Conclusión

Estimar un proyecto no consiste en fijar una fecha exacta desde el primer día. Su valor está en ayudar a decidir mejor cuando todavía no conocemos los detalles.

Además, una buena estimación no se limita a calcular fechas o presupuestos. También debe tener en cuenta el esfuerzo necesario, los recursos disponibles y la incertidumbre asociada.

Técnicas como la estimación paramétrica o PERT pueden ayudarnos a construir previsiones más razonables, pero ninguna de ellas elimina por completo la incertidumbre. De hecho, una buena estimación no es estática: evoluciona a medida que aprendemos más sobre el trabajo.

Por eso, la próxima vez que al inicio de un proyecto alguien te pida una fecha o un presupuesto, no te limites a dar una cifra. Tan importante como el número es entender qué supuestos lo hacen posible.

---