The Consultant Built It and Left. I Have Seen This Story End Three Ways.

A system I built was dead within a year of my last day on the project. The model was clean. The reports were fast. People had clapped at the handover. Twelve months later it was a folder nobody opened.

I have handed over a lot of BI systems across twenty-five years inside industrial groups. Some were still running well five years on. Others died quietly. For a long time I could not explain why, because the ones that survived were not always the best-built ones.

The story almost always ends one of three ways.

The first ending is slow degradation. The system keeps running, but nobody really maintains it. A source column gets renamed and one measure breaks. Someone patches it by hand. Then that someone changes jobs, and the patch becomes folklore. Two years later the reports still load, but people have learned which numbers to quietly ignore. The thing is alive and untrusted at the same time.

The second ending is the return to Excel. Within a few months, someone rebuilds the numbers that matter in a spreadsheet they control. The expensive system still exists. It just stops being where decisions are made. Nobody announces this. You notice it when a manager pulls up a spreadsheet in a meeting instead of the report you delivered.

The third ending is survival. Someone inside the company owns the system, extends it, argues about it, and folds it into how the business actually runs. Two years later it is bigger than what I left, and better.

For years I assumed the third ending was a reward for good engineering. Tighter model, cleaner code, smarter visuals. I was wrong. I have watched elegant systems rot and clumsy ones thrive. The build quality was not what decided it.

Here is what decided it. Whether one person inside the organisation was ever set up to own the thing after I walked out the door.

That sounds obvious written down. It almost never happens in practice. Knowledge transfer gets treated as a document you produce in the final week, or a two-hour session where the consultant talks and everyone nods. That is not transfer. That is a recording of a decision nobody was part of.

Real transfer is a choice made at the start, not the end. It is deciding on day one who inherits this system, and then building the whole engagement around that person. They sit in the discovery sessions. They hear why each definition was chosen, not just what the final answer was. When they read the documentation later, it was written for them, because they were already in the room when it was made.

When that person exists from the beginning, everything technical can be average and the system still survives. When that person does not exist, everything technical can be perfect and you still get ending one or two. The consultant optimised for the day of delivery. Nobody optimised for the day after.

It is worth asking why the owner so rarely gets named. It is not usually neglect. Naming an owner means committing a real person's time to something that is not yet urgent. That time has to come from work that already is. So the role stays vacant, everyone assumes someone will step up, and the assumption holds right until the first thing breaks. By then the consultant is gone and the person who might have owned it never learned why anything was built the way it was.

So the useful question, if you are about to sign a BI engagement, is not about the tool or the timeline. It is this: who inside our organisation will own and extend this in two years, and are they involved right now? If you cannot name that person, you are not buying a capability. You are renting one, and the meter stops the day the consultant leaves.

If that person does not exist yet, the honest move is to create the role before the build starts, not after it ends. If they exist but are buried under "the team" and never make it into the discovery room, that is the first gap to close. Not the data model. The owner.

A consultant who cannot name their internal successor on day one is building a dependency, not a capability. That is not always their fault. Most of the time nobody asked them to think about it, and a dependency is easier to sell than an exit. But it is always the client who carries the risk when the dependency breaks.

I still think about the system that died within a year. Nothing about the build would embarrass me today. I had just quietly assumed that someone would pick it up, without ever making sure that someone existed. That assumption is the most expensive one I have made in this work, and it never showed up on any invoice.

The consultant who builds a report that cannot survive their own departure has not finished the job. They have created a dependency that will cost more than the original project the day it breaks. If you are about to sign a BI engagement, or you are managing one right now, ask one question before the next sprint starts: who inside this organisation will own and extend this in two years? If the answer is unclear, the engagement was not designed for your success. → Design for the day after delivery