The Archive as Evidence: Setting Future Deadlines from Delivered Work

Most deadline estimates are forecasts dressed as facts. A team agrees a date because it feels possible, not because comparable work has taken that long before. The result is familiar: a gentle start, a compressed middle, and a final week that consumes every spare hour. The corrective is not more optimism. It is evidence. Old projects already contain the timestamps, versions and approvals needed to calculate realistic lead times—if you treat them as data rather than nostalgia.

Start with the record, not the memory

Memory edits. It remembers the crisis and forgets the waiting. It recalls the final push but not the three weeks spent chasing a signature. Before setting a new deadline, gather the record for a small number of completed projects. Look for the first request, the first substantive draft, the review points, the final approval, and the date the work was actually delivered or published. Email timestamps, document version histories, shared drive activity, approval trails and project folders will usually provide enough to reconstruct the timeline.

This is not an exercise in blame. It is an exercise in measurement. The aim is to replace a single remembered duration with a defensible range.

What to collect

For each project, capture a short sequence of dates and note what happened between them:

• The date the request was received or the brief was agreed.
• The date the first substantive draft was circulated.
• The dates of formal reviews, approvals and sign-offs.
• The date the final version was delivered or published.
• The number of rework loops before approval.
• The main waiting periods, including time spent with clients, legal teams, committees or suppliers.

You do not need perfect records. A partial timeline is still more useful than a guess. Where a date is missing, mark it as missing rather than filling it with memory. The gaps themselves are informative: they show where your current records are too thin to support good planning.

Sample comparable work

Select five to eight projects from the past eighteen months that resemble the work you are planning. Similar scope matters more than similar job title. A small client project with two approvers is not comparable to a regulated programme with a steering group, even if both are called campaigns.

Exclude genuine one-offs and known crises from the first pass. You are looking for the normal shape of delivery, not the worst quarter in recent history. Once you have a typical range, you can add an explicit allowance for unusual risk rather than letting a single exceptional project distort every future estimate.

Separate elapsed time from working time

Lead time is not the same as effort. A document may take two days of work but six weeks to approve. If you plan only for the working time, the deadline will fail during the waiting period. Calculate both:

• Working time: the hours or days your team actually spends producing, reviewing and revising the work.
• Elapsed time: the calendar time from request to delivery, including waiting, hand-offs and approval queues.
• Waiting time: the gap between those two figures, which is often the largest and least examined part of the lead time.

This distinction is especially useful in UK organisations where approval may pass through several people, a legal review, a compliance check or a committee cycle. The work can be ready while the decision is not.

Build a range, then a date

Once you have several timelines, identify the fastest realistic delivery, the typical delivery and the slowest non-crisis delivery. Use the typical figure as your planning base and the slower figure as your risk allowance. Avoid presenting a single number as certainty. A range is more honest and more useful: it tells colleagues where the pressure points sit.

Then set the deadline backwards. Start from the required delivery date, subtract the typical approval period, subtract the review cycle, and subtract the production time. Add explicit checkpoints for the moments that historically cause delay. If the resulting plan leaves no room for a normal approval loop, the deadline is not ambitious; it is unsupported.

Account for calendar realities

Past timelines will include the UK working calendar, whether you recorded it or not. December slowdowns, August leave, bank holidays and committee schedules all leave marks on old projects. When you calculate lead times, note the season in which the work took place. A project delivered in late November may have a different shape from one delivered in February. This is not an argument for pessimism. It is an argument for counting the days that will actually be available.

Keep the method light

This does not require a new system. Add three fields to your existing project close: first request date, final approval date and delivery date. Record the number of rework loops. Once a quarter, review a handful of recent projects and update your typical lead times. The discipline takes less time than a single avoidable end-of-project squeeze.

Avoid false precision

Small samples can mislead. Scope changes can make an old project incomparable. A single smooth delivery does not prove that every future delivery will be smooth. Treat the archive as evidence, not prophecy. Use it to challenge vague assumptions, to justify realistic dates and to show where a plan depends on someone else responding quickly. If the evidence is thin, say so and build a wider range.

The practical benefit is calm. When a deadline is challenged, you can point to what comparable work actually took. When a date is set, it rests on observed lead times rather than hopeful arithmetic. Old projects are not just finished work. They are the best available record of how your organisation delivers—and a reliable guide to the deadlines you should set next.