Cuándo acaba un proyecto: cálculo con un ejemplo resuelto

La fecha de fin de un proyecto se calcula determinando la cadena de tareas consecutivas que no tienen margen de retraso, conocida como camino crítico, sumando sus duraciones laborables y asignando a cada persona únicamente el trabajo que puede asumir sin solaparse. Para justificar esa fecha final, es imprescindible mostrar qué dependencias y qué límites de capacidad empujan cada entrega.

¿Por qué sumar horas de trabajo no predice la fecha de entrega?

El error más frecuente al estimar la conclusión de un proyecto consiste en sumar todas las horas de las tareas y dividirlas entre la jornada del equipo. Este cálculo asume de manera falsa que el trabajo se distribuye de manera homogénea y paralela entre todos los participantes desde el primer minuto. Si un proyecto reúne 120 horas de trabajo y tres personas trabajan 40 horas semanales, el calendario rara vez se completará en una sola semana.

En la práctica, las tareas dependen unas de otras por restricciones técnicas o lógicas: no es posible revisar un texto que aún no se ha escrito ni maquetar un catálogo sin las especificaciones gráficas cerradas. Cuando una tarea debe esperar a otra para arrancar, el tiempo total queda condicionado por esa secuencia obligatoria y no por el volumen agregado de trabajo.

Además, cada miembro del equipo posee una disponibilidad finita y no realiza dos tareas de concentración de forma simultánea. Cuando se asignan varias actividades consecutivas a la misma persona, esas tareas forman una cola secuencial interna que alarga el calendario, aunque ninguna dependa formalmente de otra a nivel técnico. La guía GAO Schedule Assessment Guide: Best Practices for Project Schedules de la U.S. Government Accountability Office señala que un cronograma creíble debe reflejar tanto las dependencias lógicas completas entre actividades como los límites reales de asignación de recursos, advirtiendo de que omitir estas restricciones produce fechas finales artificialmente optimistas.

¿Qué diferencia existe entre esfuerzo, duración y plazo?

Para calcular cuándo termina una entrega y defender el calendario ante terceros, resulta necesario separar con precisión tres conceptos que a menudo se confunden en las conversaciones de equipo:

1. Esfuerzo (trabajo real): representa las horas de dedicación neta que una persona necesita para completar la tarea si trabajara de manera ininterrumpida. Si maquetar un documento exige 9 horas de diseño concentrado, el esfuerzo es exactamente de 9 horas de trabajo.
2. Duración: corresponde al tiempo de calendario laborable que transcurre desde que la tarea se inicia hasta que concluye, condicionado por las horas que esa persona dedica al proyecto cada día. Si la persona tiene asignadas 6 horas de tareas al día, una actividad de 9 horas de esfuerzo requiere 1½ días laborables de duración.
3. Plazo (o fecha límite): es el límite externo fijado en el calendario civil (por ejemplo, «el 30 de octubre a las 18:00») antes del cual la tarea o el proyecto debe quedar entregado. El plazo no mide el trabajo necesario, sino la ventana temporal máxima impuesta por un cliente, un contrato o un hito de negocio.

Cuando se confunde esfuerzo con duración, se prometen entregas inviables al ignorar las interrupciones habituales, las reuniones y la jornada efectiva. Asimismo, cuando se confunde duración con plazo, se tiende a ocupar todo el margen disponible sin justificar la necesidad técnica de los días asignados.

¿Cómo influyen las dependencias y la cola de trabajo en la fecha final?

La fecha en que termina un proyecto no depende de la tarea más larga ni de la media de las actividades, sino de la secuencia de tareas encadenadas que determina el final del trabajo. En gestión de proyectos tradicional esta cadena recibe el nombre de ruta crítica, mientras que en herramientas de planificación como tokidu, el gestor de proyectos de Sinergia Barcelona, el motor de «Fechas que se calculan solas» evalúa directamente qué tareas deciden cuándo acabas sin que sea necesario calcular complejas fórmulas de holgura a mano.

Existen dos factores determinantes que empujan sucesivamente la fecha de entrega de cada actividad:

• La dependencia lógica entre tareas: cuando una tarea requiere que otra finalice previamente (relación fin a comienzo), la fecha de inicio de la sucesora queda anclada a la hora de cierre de su predecesora inmediata. Cualquier retraso en la predecesora empuja automáticamente a todas las que esperan detrás.
• La restricción de capacidad por persona: si un profesional tiene asignadas tres tareas que teóricamente podrían comenzar el mismo día, su jornada real solo le permite abordar una a la vez. Las dos restantes deben esperar en cola, lo que añade una demora provocada exclusivamente por la asignación de recursos y no por una precedencia técnica.

Para explicar por qué un proyecto termina en un día concreto, basta con reconstruir esa cadena de causas hacia atrás: la entrega final depende de la tarea anterior, que a su vez estuvo esperando a que la persona responsable terminara otra tarea previa o a que se cumpliera el horario laborable del calendario.

Ejemplo resuelto: el calendario real de un folleto para imprenta

El siguiente ejemplo ilustra el cálculo paso a paso de un proyecto de diseño e impresión con tres participantes. Se aplica un calendario de lunes a viernes con 6 horas de tareas al día por persona, donde «1 día» equivale a 6 horas netas de trabajo, asumiendo que cada persona realiza únicamente una tarea a la vez y arrancando el lunes 26 de octubre de 2026.

El desarrollo cronológico de este ejemplo muestra con total claridad cómo interactúan la capacidad individual, las dependencias y la jornada laboral:

1. Diseñar la portada: Ana comienza el lunes 26 de octubre a primera hora. Dado que la tarea tiene una duración estimada de 2 días (12 horas laborables) y Ana dispone de 6 horas diarias, ocupa la totalidad de su jornada del lunes 26 y del martes 27 de octubre.
2. Maquetar el folleto: la tarea exige 1½ días (9 horas de trabajo). Aunque Ana es quien la realiza, no puede solaparla con la portada por dos motivos concurrentes: la tarea tiene una dependencia explícita («Espera a: Diseñar la portada») y, al mismo tiempo, Ana no puede duplicar su jornada. Por tanto, arranca el miércoles 28 de octubre por la mañana. Consume las 6 horas del miércoles y 3 horas del jueves 29 de octubre, concluyendo a mitad de esa jornada.
3. Revisar los textos: Luis se encarga de esta tarea de ½ día (3 horas de trabajo). La tarea espera a que concluya la maquetación. Dado que Ana termina a mitad del jueves 29, Luis dispone de las 3 horas restantes de su propia jornada del jueves para revisar los textos, completando su parte el mismo jueves 29 de octubre.
4. Enviar a imprenta: requiere 1 hora de trabajo asignada a tu perfil. Como la revisión de textos terminó al cierre del jueves 29, la preparación del envío se traslada al inicio del siguiente día hábil, el viernes 30 de octubre, quedando completada a primera hora.

El proyecto concluye el viernes 30 de octubre de 2026. Si un cliente o responsable preguntase por qué el envío no se produce el miércoles o el jueves, la respuesta no es una apreciación subjetiva: la portada requiere dos días completos de Ana, la maquetación consume día y medio más de su disponibilidad, y la revisión de Luis no puede iniciarse sin el archivo maquetado.

¿Por qué las estimaciones iniciales suelen fallar?

Calcular matemáticamente una fecha de entrega sobre el papel no garantiza que el proyecto termine ese día si las estimaciones de base son sistemáticamente erróneas. Diversas investigaciones en psicología cognitiva y gestión pública han documentado los sesgos sistemáticos que distorsionan los calendarios.

El fenómeno conocido como «falacia de la planificación», estudiado experimentalmente por Buehler, Griffin y Ross (1994): Exploring the «planning fallacy»: Why people underestimate their task completion times, demuestra que las personas tienden a prever escenarios ideales cuando estiman sus propios plazos futuros, ignorando deliberadamente su propio historial de retrasos en trabajos similares anteriores.

En proyectos de mayor envergadura organizativa, este error individual se agrava por el sesgo de optimismo y la representación estratégica de costes y plazos. El manual técnico Green Book supplementary guidance: optimism bias elaborado por HM Treasury detalla cómo los responsables de proyectos asumen de manera recurrente que los riesgos imprevistos no se materializarán, recomendando ajustes explícitos porcentuales al alza para compensar la subestimación de plazos.

Asimismo, el análisis de grandes carteras tecnológicas publicado por Flyvbjerg y Budzier (2011): Why Your IT Project May Be Riskier Than You Think documenta que los proyectos que sufren desviaciones no solo experimentan retrasos moderados, sino que con frecuencia caen en colas de riesgo asimétricas («cisnes negros») provocadas por dependencias no detectadas y acumulaciones imprevistas de bloqueos.

¿Cómo defender y explicar la fecha final ante un cliente o un jefe?

Presentar una fecha de entrega sin desglosar su lógica interna sitúa la conversación en el terreno de la negociación arbitraria. Para evitar que un interlocutor recorte plazos sin base técnica, conviene estructurar la justificación mediante cuatro argumentos comprobables:

1. Presentar la cadena de dependencias obligatorias: mostrar qué tareas están forzosamente vinculadas entre sí. Si el interlocutor solicita adelantar la entrega final, debe indicar explícitamente qué entregable preliminar está dispuesto a suprimir o simplificar para acortar la cadena.
2. Demostrar la ocupación de las personas asignadas: evidenciar que ningún miembro del equipo puede asumir dos tareas concurrentes sin dividirse la jornada. Si una persona clave ya tiene asignadas 6 horas de tareas al día en la ruta principal, añadir más actividades solo provocará demoras en cascada.
3. Explicar el impacto de los días no laborables y festivos: aclarar que una duración de tres días laborables iniciada un jueves se traslada inevitablemente al martes siguiente debido al fin de semana, evitando el malentendido común de contar días naturales.
4. Utilizar explicaciones contextuales automáticas: en herramientas diseñadas para la transparencia del plan, como la función «¿Por qué esa fecha?» disponible en todos los planes de tokidu, al hacer clic sobre una fecha prevista el sistema redacta una frase exacta indicando qué factor la empuja: a qué tarea concreta espera, qué otra tarea previa tiene asignada esa persona o qué días no laborables median en el cálculo.

¿Qué papel cumplen las líneas base al comparar lo previsto con lo real?

Una vez calculada la fecha estimada del proyecto y acordado el calendario con las partes interesadas, resulta fundamental registrar una instantánea inmutable del plan original para evaluar el avance con rigor.

En la gestión estructurada de proyectos, esta instantánea se denomina línea base (baseline). Guardar una línea base permite comparar en cualquier momento las fechas que se calcularon al inicio frente a las fechas reales que se van produciendo a medida que las tareas se completan o se posponen.

Las distintas soluciones de software gestionan esta función de forma variada:

• En Microsoft Planner, de acuerdo con la información oficial verificada el 2026-09-29 en Announcing updates to the Baseline feature in Microsoft Planner, las líneas base forman parte de las capacidades premium del Plan 3, permitiendo almacenar una única línea base por plan.
• En Microsoft Project de escritorio, según la documentación técnica comprobada el 2026-09-29 en Create or update a baseline or an interim plan in Project desktop, es posible guardar hasta 11 líneas base independientes en un mismo archivo para comparar sucesivas revisiones contractuales.

Contar con una referencia fija evita discusiones subjetivas sobre cuándo debía terminar una tarea, permitiendo identificar de forma objetiva qué demora inicial desvió la entrega final del proyecto.