Your Timeline Is a Guess Wearing a Suit

I once nodded along to a 22 week schedule in a kick-off meeting, having skim-read it in the car park ten minutes earlier. I was the only person in that room with enough technical detail to know it was wrong. I found out how wrong in week nine, along with everyone else, which is the worst possible way to find out anything.

Here's the chain, and it happens in almost every organisation. An engineer says "probably three or four weeks, depends what we find in the legacy integration". A lead writes "4 weeks" in a spreadsheet. A planner puts it in a schedule with a start date and an end date. A bid team or a programme office pulls the end date into a slide. By the time it reaches a customer or a board, the sentence "depends what we find" has been quietly deleted, and the date has a font size.

Nobody lied. Every step was reasonable. But a range with a named unknown attached went in one end and a commitment came out the other, and the only person who ever had the full picture was the engineer who said the original sentence.

You're the person in that chain who can put the uncertainty back. Not because you're a project manager, you're not, and this isn't about taking over the plan. You're the one who can look at the dates and say whether the work behind them can actually be done in that order, by those people, in that time. If you don't do that, nobody does, and everyone downstream assumes somebody already did.

Read the plan properly once, with a pen. Then ask these.

Who produced each estimate, and have they personally done this specific thing before? An estimate from someone who has done the migration twice is a different class of object from an estimate by someone reasoning from first principles. Both are legitimate. They carry different amounts of weight and you should know which one you're holding.

What's the longest dependency in here, and does its owner know the date? This catches more slippage than anything else. Firewall rule changes, a security review board that meets fortnightly, a vendor's professional services team booked three months out, a data protection sign-off. Half the dates in a typical plan depend on someone who has never seen the plan.

What has to be true for this to work? Write the assumptions down as sentences. "The test environment matches production." "We get two change windows a week." "The three contractors start in April." A plan is a list of assumptions with dates stapled to it, and assumptions that stay unwritten are the ones that fail silently.

Where's the contingency, and can anyone point at it? If nobody can show you where it sits and what it's for, it doesn't exist. Contingency that lives inside individual task estimates has already been spent by optimism.

The standard answer when a schedule looks tight is to talk about bringing in more people. Sometimes that's right. It's right when the work genuinely splits into independent pieces, when there's someone free who already knows the domain, and when the people already on it have capacity to hand work over.

Most of the time on a squeezed project, none of those hold. The work is entangled, the available people need three weeks of context, and the person who would give them that context is the one person on the critical path. You've just taken your most constrained resource and made them a teacher.

If you're going to add people, add them early, add them to the work adjacent to the critical path rather than into it, and name the cost out loud: "two engineers from July, which costs us about two weeks of Priya's time in the first fortnight". A mitigation with no stated cost is a wish.

Not all dates are equal, and technical leaders routinely treat them as if they were.

Some milestones carry service credits. Some carry a payment stage, so missing them means the business doesn't invoice this quarter. Some are tied to a regulatory deadline or a lease expiry or a retail freeze period, and are genuinely immovable no matter how sympathetic everyone is. Others are internal and were picked because someone liked the look of the quarter boundary.

Ask, early, in plain words: which of these dates costs us something if we miss it, and how much. You'll be surprised how often nobody has told the delivery team. Then protect the expensive ones differently. Put your contingency in front of them, not spread evenly across a plan that treats a soft internal review and a contractual go-live as the same kind of object.

A 9 month data centre migration for a regional airline, roughly 400 workloads, run by a 7-person integration team. In month three, the business added the systems from two stations it had just taken over from a franchise partner. Everyone agreed this was significant. Nobody changed the plan, because reopening the schedule felt like admitting failure and the original date was already in a board pack.

So the team kept tracking against a plan that had been dead since March. Every weekly report showed amber, then a slightly worse amber, for four months. In month seven it went red, at which point the conversation was no longer "what's realistic" but "why has this been amber since March". They rebaselined anyway. They just did it from a position where nobody trusted the new numbers either.

Tracking against a plan you know is wrong isn't diligence, it's theatre with a spreadsheet. Scope changed, so the plan changes. Say so the week it happens, while it's still arithmetic rather than an accusation.

Take your current committed end date. Write down, in one sentence, the single assumption it depends on most. Not five assumptions. The one that would hurt worst if it turned out to be false.

Then find the person who owns that assumption, send them the sentence, and ask them to confirm or correct it by Friday. If they can't, you've learned something important about your date, and you've learned it in June rather than in September.