Every Project I've Seen Fail, Failed in Week One

The failure happens in the first fortnight. Everything after that is the bill arriving, in instalments, with interest. I have never seen a project collapse in month seven for a reason that was actually invented in month seven.

Week one is when a project is at its most dangerous, because it feels like the safe part. Nothing has gone wrong. Everyone is friendly. The sponsor is enthusiastic. And you are making the decisions that will determine the outcome, in conversations that nobody minutes.

Somebody says "we'll integrate with the existing monitoring platform" and everyone nods. Nobody asks which of the four monitoring tools in the estate they mean, or whether "integrate" means a dashboard, alert routing into the on-call rota, or a full agent rollout onto every host. Those are three different projects with a variance of several months between them, and the whole question passed through the room in eleven seconds.

Two months later you find out that the sponsor meant the full agent rollout and you scoped the dashboard. At that point you are not having a technical conversation. You are having a commercial one, and you are on the wrong side of it.

The words that should make your neck prickle in week one: integrate, migrate, support, refresh, uplift, align. Every one of them is a container that different people fill with different contents while nodding at each other.

Here is the one that still makes me wince.

A national postal and parcels operator, 186 delivery depots and nine sorting hubs, a network refresh replacing the kit at every one. The plan assumed each depot had a spare rack unit and dual power in the comms cabinet, because the asset records said so and because that is what the standard build had specified when the estate was rolled out years earlier.

About 45 of them did not. Some had been extended, some had a cabinet full of somebody else's hardware, a handful had a comms cabinet that a depot supervisor had turned into a stationery cupboard. We found out in week 12, when the rollout teams were already on the road and the hardware had already been ordered.

The cost was 45 extra site visits, a 4-week slip, and a relationship with the customer that never quite recovered its early warmth. The fix, had anyone thought of it, was to survey 15 depots in week one. Two engineers, four days, a phone camera and a checklist. Nobody did it because in week one there was no problem to solve, and surveying depots feels like admin next to designing the target architecture.

That is the pattern. The cheap moment to test an assumption is always the moment when testing it feels unnecessary.

Most teams do produce an assumptions list. It usually lives on page four of a document, has 30 items on it, gets read once, and exists mainly so somebody can point at it during an argument later. That is a legal artefact, not a management one.

Make it useful with two columns. Against each assumption, write who will confirm it and by when. Then work out what happens if it turns out to be wrong.

The ones that matter are where being wrong costs you more than two weeks or more money than you can approve yourself. There will be a small number of those, usually somewhere between 3 and 6 on a normal-sized piece of work. Those are not assumptions any more. They are risks with a friendly name, and they need testing before design finishes, not before go-live.

Everything else can sit on the list and be reviewed at a milestone.

One thing to be honest about here. You will not eliminate the unknowns in week one, and a leader who tries will still be doing discovery in month three while the team sits idle and the budget burns. The goal is not certainty. The goal is that the assumptions you are carrying are ones you chose to carry, with a date on them.

The other reason week one does the damage is that most teams treat the scope document as something you complete and then stop touching. Signed, filed, back to the real work.

Then reality does what reality does. A regulatory date moves. Two of the four systems in scope turn out to share a database. Someone leaves. By month four the document on the shared drive describes a project that no longer exists, and the team is working to an unwritten version that only lives in people's heads, which means every person is working to a slightly different one.

Put a scope review on the calendar at each milestone. Fifteen minutes, three questions: what changed, what did we agree to that isn't in here, and what is still in here that we quietly stopped doing. Version the document, date it, and send the diff to the people who signed it. Not the whole document, the diff. They will read a diff.

Take the piece of work you are running now. Find the single assumption that would hurt most if it turned out to be false, the one where you would lose a month or a chunk of margin.

Write it in one sentence. Put a name against it, yours if nobody else will take it, and a date this fortnight. Then go and actually test it: ring the supplier about the lead time, pull the real config off ten devices rather than trusting the asset register, get the one person who knows the legacy system to tell you whether that integration exists.

If the answer comes back wrong, you have found it in week one, which is the cheapest week it will ever be found in.