When a project will finish: with a worked example

A project finishes when the last dependent task in its longest unbroken chain of work reaches completion. Finding that exact calendar date requires three fixed variables: the realistic duration of each task, the technical handovers between tasks, and the working availability of every person assigned, ensuring nobody is scheduled to execute two activities at the same time.

Most schedule delays do not stem from poor effort during execution. According to research on the planning fallacy by Buehler, Griffin and Ross (1994), people routinely underestimate task completion times because they focus on an idealised operational scenario rather than factoring in past performance, interruptions, and administrative delays. Understanding how a finish date is produced turns an arbitrary management target into a defensible schedule.

What factors determine the real finish date of a project?

Four concrete elements govern when a project can genuinely finish. Leaving any of these four out of a schedule produces a theoretical target date that collapses as soon as day-to-day operations begin.

1. Effort versus duration. Effort is the total quantity of working hours a task demands, whereas duration is the calendar span required to complete those hours. If an activity requires twelve hours of focused labour and a person has six hours available per day, the duration is two working days.
2. Handovers between tasks. Certain work cannot begin until preceding deliverables exist. These finishes-to-start relationships dictate that even if five team members stand ready to contribute, downstream work must wait until upstream deliverables are completed and approved.
3. Individual working calendars. People do not work twenty-four hours a day, seven days a week. Bank holidays, contracted part-time arrangements, planned leave, and company off-site days interrupt the calendar flow. A task taking three working days assigned on a Thursday afternoon will span across the weekend to finish on Tuesday.
4. Workload allocation. One person cannot conduct two mentally demanding tasks simultaneously without splitting their time. When one team member receives two urgent assignments, the second task cannot start until the first finishes, or both tasks take twice as long to complete.

The GAO Schedule Assessment Guide by the U.S. Government Accountability Office identifies realistic resource assignment and logical network logic as fundamental criteria for a defensible programme plan. Without both, dates reflect wishful thinking rather than calculated reality.

Worked example: a brochure for the printer

To see how these rules establish an exact completion date, consider a clear operational workflow: designing and sending a four-page product brochure to a commercial printer. This project starts on Monday 26 October 2026. The calendar is configured to Monday to Friday, with six hours of focused task work available per day per person. Each person works on one task at a time.

The project consists of four sequential tasks involving three contributors: Ana, Luis, and the project lead.

Here is how each date resolves across the five working days:

1. Design the cover starts on Monday 26 October at the beginning of the working day. With a duration of two full days (twelve working hours), Ana spends Monday and Tuesday completing the concept. The task finishes at the end of the working day on Tuesday 27 October.
2. Lay out the brochure depends directly on the cover design. Ana cannot lay out interior spreads until the visual identity of the cover is agreed. The task requires one and a half days (nine working hours). Because Ana finishes the cover on Tuesday evening, she begins layout work on Wednesday 28 October. She works all six hours on Wednesday, and the remaining three hours on Thursday morning. The task finishes on Thursday 29 October at midday.
3. Review the copy is assigned to Luis. It waits for the layout so that Luis can check copy against final text frames. It requires half a day (three working hours). Because Ana finishes the layout at midday on Thursday, Luis begins immediately on Thursday afternoon. He completes his review before the close of business on Thursday 29 October.
4. Send to print waits for Luis to approve the proofs. The task takes one hour and is assigned to you. Luis finished his review on Thursday afternoon. Rather than rushing print dispatch outside production hours, the schedule registers this final check for the next available working slot on Friday morning, 30 October. The project reaches full completion on Friday 30 October 2026.

If Ana had been assigned a separate task for another client taking three hours on Tuesday afternoon, the layout would have been pushed by three hours into Thursday afternoon, pushing Luis's review into Friday morning, and delaying print dispatch to Friday afternoon. A date is never an isolated point; it is the output of an unbroken chain.

Why does adding more people fail to bring forward the finish date?

When a scheduled completion date exceeds an executive deadline, the instinctive response is to assign additional team members to the remaining tasks. In software engineering and knowledge work, this intervention frequently delays completion further.

Fred Brooks formulated this principle in the mid-1970s, observing that adding human resources to a late project makes it later. When new people join a project, existing team members divert productive hours to onboard, explain decisions, and review work. Furthermore, the number of communication channels expands rapidly as team size grows, increasing coordination overhead.

More fundamentally, task dependencies impose strict limits on concurrency. In the brochure example, hiring a second graphic designer does not compress the schedule if the brochure layout depends entirely on the design language established in the cover. If task B requires the output of task A, ten individuals cannot complete task B while task A is still being produced.

To accelerate a project safely, managers must inspect the dependency chain. Only two interventions legitimately bring forward an end date:

1. Reducing scope. Removing requirements or deferring optional deliverables shortens the actual working hours required along the critical chain.
2. Fast-tracking independent work. Tasks that were artificially scheduled sequentially out of convenience can be run in parallel, provided separate people execute them and no strict logical dependency binds them.

How should you explain the finish date to clients and executives?

Stating a date without explaining its underlying mechanics leaves you vulnerable to arbitrary cuts. When a sponsor asks for a delivery date two weeks earlier, a project manager who cannot explain what drives the date has no structural argument against the demand.

To explain a finish date persuasively, follow a structured framework based on constraints rather than opinions:

1. Show the critical chain. Walk stakeholders through the unbroken sequence of tasks that dictates the final day. Point out that the final date is driven entirely by this sequence: task one must precede task two, which precedes task three.
2. Show individual allocations. Demonstrate that team members are already fully scheduled during those working windows. Explain that nobody is double-booked, and that each task duration reflects focused operational hours.
3. Identify non-working periods. Clarify how weekends, public holidays, and existing commitments influence the timeline. A project spanning across late December, for instance, loses several working days to bank holidays and business closures.
4. Offer trade-offs, not concessions. When stakeholders demand an earlier date, present the mathematical levers available. State clearly: to finish on the 20th instead of the 30th, we must either remove specific deliverables from the scope, or reassign high-priority resources from another active initiative.

In tokidu, the project manager by Sinergia Barcelona, this clarity is automated by the date engine. When you adjust task durations and dependencies with «Starts when … is done», the software applies «Dates that work themselves out» to calculate exact calendar dates based on real availability. Tapping any calculated date surfaces «Why that date?», presenting a clear sentence explaining exactly which predecessor task, individual workload, or calendar break is pushing the finish date.

How do traditional tools track baseline deviations?

During project execution, actual progress rarely mirrors the initial schedule with complete precision. Tracking the variance between what was originally promised and what is currently occurring requires comparing your live schedule against a locked snapshot known as a baseline.

Different project management software packages handle baseline capture according to their functional architecture. The following table illustrates how desktop and cloud tools manage baseline histories, verified as of 2026-09-29:

In desktop Microsoft Project, keeping up to 11 distinct baselines allows organisations to retain the original project contract while saving interim adjustments after major scope renegotiations. In Microsoft Planner, baseline tracking is restricted to premium tiers, letting managers evaluate schedule variance against one captured baseline.

Capturing a baseline provides an objective reference point when explaining schedule shifts. If a client delays sending crucial content assets by four days, comparing the live timeline against the baseline demonstrates mathematically why the delivery date moved outward by four days.

Which cognitive traps distort project estimates?

Even experienced teams fall into cognitive traps when estimating task durations. Recognising these patterns helps teams build realistic schedules before commitments are finalised.

Optimism bias

Optimism bias is the systematic human tendency to believe that future actions will face fewer obstacles, interruptions, and complications than historical precedent suggests. Guidance published by HM Treasury in the Green Book supplementary guidance on optimism bias emphasises that public sector and capital infrastructure projects routinely underestimate both delivery duration and capital cost unless explicit empirical adjustment factors are applied.

To counteract optimism bias in team planning, review past project logs. If initial estimates for layout design were consistently scheduled for one day but historically required two days due to revision cycles, set the future baseline to two days.

Black swan events and long-tail project risk

While small projects risk everyday operational delays, technical and digital initiatives face disproportionate risks from unforeseen compounding errors. In an empirical study of 1,471 IT projects published in the Harvard Business Review, Flyvbjerg and Budzier (2011) found that while the average cost overrun was 27%, one in six projects suffered an average cost overrun of 200% and a schedule overrun of almost 70%.

These high-impact outliers occur when complex technical integrations fail, dependencies cascade unpredictably, or core architecture requires complete refactoring. Ensuring a schedule contains transparent dependency handovers and visible work queues prevents invisible roadblocks from silently expanding into systemic schedule overruns.

Student syndrome and Parkinson's law

Human working behaviour responds directly to deadline structures. Parkinson's Law states that work expands to fill the time allotted for its completion. When an easy three-hour task is given a two-week window without intermediate check-ins, it frequently consumes the full two weeks as people refine minor details unnecessarily.

Student syndrome describes the opposite habit: postponing active work on a task until the final deadline is immediately imminent. When combined, these behaviours mean that extra safety buffer inserted into individual tasks rarely translates into an earlier project delivery date. Buffers assigned to individual tasks are routinely wasted, whereas buffers placed strategically at the end of critical project milestones protect the delivery date without encouraging procrastination.

5 steps to calculate a dependable project finish date

Building an accurate schedule does not require heavy manual arithmetic if you structure the sequence systematically. Follow these five operational steps:

1. Define deliverables as concrete tasks. Deconstruct the project scope into individual, testable items of work. Avoid vague containers such as «Development»; write unambiguous actions like «Build user authentication API» or «Draft terms of service».
2. Assign realistic durations in focused hours. Estimate the hours required assuming uninterrupted work. Convert hours into working days based on your team's real daily capacity. In tokidu, the default calendar allocates six productive hours per working day to leave room for correspondence and operational overhead.
3. Map sequential handovers. Link tasks strictly by operational necessity using «Starts when … is done». If a writer needs interview recordings before drafting an article, link the draft to the recording task. Avoid linking tasks that can happen independently.
4. Assign single owners per task. Ensure every task has one clear person responsible. When one team member owns multiple sequential tasks across the plan, verify that their individual schedule respects working limits without overlapping assignments.
5. Review blocked work in «Up next». Use an execution view that isolates tasks ready for immediate action from those blocked by upstream dependencies. Keeping team attention focused strictly on unblocked tasks ensures work moves through the schedule chain without unnecessary idling time.