Most enterprise programmes fail in year three, not at launch

The call usually comes in the third year. A platform went live on schedule. Somebody presented it at a town hall and there were photographs. Then the integrator's senior engineers moved to the next account, the client's product owner was promoted into a different division, and a reconciliation job that runs on the last Friday of the month started failing. Nobody currently employed knows why that job exists, and the engineer who wrote it left two employers ago.

We have been building systems for organisations that cannot switch them off since 2010, and this is the failure mode we see most often. It is rarely dramatic. There is no outage, no regulator, no post-mortem. The system simply stops being changeable, and an organisation that cannot change a system starts working around it. Spreadsheets appear. A second database appears. Six years later somebody proposes a transformation programme to replace the thing that was itself a transformation programme.

Launch is the easiest day the system will ever have

Look at what a go-live actually involves. The vendor has its strongest engineers on site. A change freeze is in place across the rest of the estate. Migration runs in a controlled window with every relevant person awake and in one room. The rollback plan has been rehearsed twice. Support is staffed at several times normal load for a fortnight, and the people answering the phone are the people who wrote the code.

Under those conditions most competent teams can get most systems live. A launch tests the launch. It says very little about whether anyone will be able to safely change a validation rule three winters later, which is the thing the organisation is actually buying.

What decays, and roughly in what order

The decay is predictable enough to plan around, which is the only encouraging thing about it.

People go first. Named senior engineers roll off after the stabilisation period, which is commercially reasonable and usually written into the contract on both sides. They are replaced by a support tier that is cheaper and, by design, less familiar. The knowledge that mattered was never in the repository. It was the reason a particular queue has a retry limit of three rather than five, and the fact that raising it will quietly duplicate payments.

Documentation goes second, at the first significant refactor. Someone renames a service, moves two endpoints and updates the code. The page describing the old shape survives, because nothing forces it to fail. Nine months later a new engineer follows it and reaches a conclusion that is confidently wrong, which is worse than having no documentation at all.

Integration knowledge goes third, and this is the expensive one. Enterprise systems are held together by agreements that were made in meetings and implemented in code, and the meeting is not written down anywhere. A field is mandatory because a regulator asked a question during a particular audit. A batch runs at 02:40 because the upstream extract finishes at 02:30 and somebody once measured it. Remove the people who remember, and each of those becomes a decision nobody is willing to touch.

Operational context goes last and least visibly. Which supplier to ring about the network appliance. Which of the client's own teams has to approve a firewall change and how long they take. Whether the disaster recovery site has ever been used. This is not engineering knowledge and it is not written in any technical document, so it evaporates when the delivery manager changes jobs.

Why the third year specifically

The timing is not superstition. Several clocks tend to expire close together.

• Hypercare and warranty periods run three to twelve months, so the senior build team is contractually gone well before year three.
• Support and licence terms are commonly signed for two or three years, which puts the first genuine renegotiation right there.
• Platform dependencies reach end of support on a similar cycle. The framework major version that was current at design time is no longer current, and the upgrade is now a project rather than a patch.
• The business asks for its first structural change by then. A new region, a new legal entity, a new regulator, a merger.

A healthy system absorbs any one of those. The programmes we get called about are the ones where all four land in the same quarter and there is nobody left who can hold the whole thing in their head.

We used to think this was a documentation problem

For several years we treated continuity as a writing exercise. Every engagement ended with a substantial handover pack: architecture diagrams, sequence diagrams, an operations manual, a data dictionary, an environment inventory. The packs were good. We were pleased with them and clients signed them off.

They did not work. A document is only useful to somebody who already knows enough to ask the question it answers, and the engineer arriving in year three does not know what to ask. They know a job failed. They do not know that the job belongs to a family of four, that two are safe to rerun and two are not, and that the difference is a flag in a table nobody mentions in the architecture diagram because it is not architecture.

What changed the outcome was replacing most of the writing with rehearsal. Fewer documents, each one tested by making somebody unfamiliar follow it while the author sits on their hands and says nothing. It is a slow, faintly humiliating exercise and it finds more than a review ever did.

Staffing for year three, starting in week one

The practical answer is unglamorous and mostly about people rather than architecture.

We name the engineers who will still be on the account in year three, and we put them on the build. That is the whole argument in one sentence. It is also the part clients find hardest to price, because it means paying senior rates during a phase where a cheaper team would produce output that looks the same in a demonstration.

The people who build your system are the people who answer the phone about it in 2029.

Then we make sure no single person is the only route into any part of the system. Every significant component has at least two engineers who have changed it under time pressure, which is a different qualification from having read it. During the build we take a component owner off the team for a fortnight and let somebody else carry it. Whatever breaks in that fortnight is the documentation we actually needed, and we write that and nothing else.

The runbook gets written during the build rather than at handover, for the same reason. A procedure written from memory in the final sprint describes what somebody believes the system does. A procedure written the first time you perform it, at the hour you had to perform it, has been tested at least once.

We also insist that the client can deploy without us before we consider the work finished, and the test for that is a specific one. A client engineer, on their own machine, takes a real change through the pipeline to production while our team watches and stays quiet. If that exercise is uncomfortable, the handover has not happened yet, whatever the plan says.

This costs more, and clients notice

Being straightforward about the trade: this approach is more expensive in year one and roughly indistinguishable from a cheaper one on launch day. We have lost tenders on price to firms who staffed the build with whoever was between projects and priced the following years of support as a separate and optimistic line item.

Some of those programmes turned out fine. Enough of them became the third-year phone call that we stopped competing on the first number. Where a client genuinely needs a system for eighteen months, or where the business it supports is being sold, the cheaper approach is the correct one and we say so rather than arguing.

Signs a programme is already on the year-three track

These are all visible during delivery, long before anything goes wrong, which makes them worth checking while there is still time to act.

• The names in the bid are not the names at kickoff, and nobody has explained the substitution.
• No client engineer has ever made a production change without the vendor present.
• The documentation lives in the vendor's tooling and would not survive the end of the contract.
• Nothing in the test suite predates user acceptance testing, so the tests describe the demonstration rather than the system.
• The runbook is a task in the plan, scheduled last.
• There is one person everybody names when a particular subsystem comes up, and everybody laughs about it.

None of those is catastrophic on its own. Together they describe a system that works and cannot be maintained, which in a bank or at a border post is a slower version of the same problem.

The measure we care about is narrow and boring. Some Tuesday afternoon in the third year, an engineer who has never met anyone from our team needs to change how a form validates a tax identifier and get it into production before Friday, without ringing us and without breaking the month-end close. Whether they can do that was largely settled in the first eight weeks, long before anyone stood up at a town hall.