The Four Levels Every Project Sponsor Is Actually Responsible For

Most sponsors think the job is to approve the business case, then watch the RAG status until go-live.

That’s Level 1. It’s also the smallest part of the job.

I’ve sat on both sides of enough ERP programs — building them, rescuing them, overseeing them — to see the same gap repeat itself. A sponsor signs off on a business case, delegates the rest to a steering committee, and eighteen months later is blindsided by a system nobody adopted, at a cost nobody flagged in advance. Not because anyone lied. Because the sponsor stopped at the level that was easiest to see.

There are four levels a sponsor is actually expected to work across. Underneath all of them sits something more basic: the infrastructure to see the truth at all.

The foundation: decision-making infrastructure

Before any of the four levels, there’s a prior question — do you have the ability and infrastructure to see what’s actually happening, or only what’s reported to you?

This isn’t a personality trait. It’s structural. It means direct access to the people doing the work, not just the people summarising it for you. It means asking the change manager a question the project manager didn’t prepare them for. It means walking the floor occasionally instead of reading the pack.

Without this, everything above it is decoration. You can be diligent at every level and still be diligent about the wrong picture.

Level 1 — The Business Case

Ability to understand how the project and its end result serve the overall business goal.

A council replaces its finance system because reporting is slow. That’s the stated reason. The real driver, if anyone bothered to name it, is that rates processing takes three people a week when it should take one person a day.

If the sponsor never articulates that link, every later tradeoff — a cut scope item, a vendor’s “recommended” configuration, a timeline slip — gets judged against the wrong yardstick. The project can hit every milestone and still fail to solve the problem it was funded to solve.

Level 2 — Systems Architecture

Ability to understand how the product will fit into the overall systems landscape.

A new ERP module quietly duplicates functionality that already exists in the HR system. Nobody flags it, because nobody owns the whole landscape — the vendor knows their product, the internal team knows their patch, and the sponsor knows neither.

Two years later, payroll reconciliation breaks because there are now two sources of truth for the same data, and nobody can say which one is authoritative. This is not a technology failure. It’s a sponsor who approved a piece without understanding the whole.

Level 3 — Alignment

Developing alignment between business goals, product outcome, acceptance, uptake, support, and continuous improvement.

The system goes live on schedule. It matches the spec. The RAG status is green. Nobody checks whether the operational teams who have to use it every day actually accept it.

This is where drift hides best, because everything measurable looks fine. Uptake is not a measurable milestone in most project plans — it’s assumed. A sponsor operating at Level 3 asks the uncomfortable question before go-live, not eight months after, when low adoption has already become “just how things are here.”

Level 4 — People, Product, and Process

Alignment between people, product, and processes for smooth adoption and change management.

Change management gets treated as a training schedule in the final two weeks before go-live. It should have been a sustained alignment effort from the start — between what the process now requires, what the people were doing before, and what the product actually does.

Skip this, and you get the pattern every sponsor eventually recognises too late: different departments quietly building their own workarounds, because the official process doesn’t match how the work actually gets done.

The must-have: this is not a one-time decision

Here’s what makes this a framework rather than a checklist — none of these four levels get resolved once. The whole point of the foundation underneath them is that you continue to see the true picture, and continue making decisions that facilitate the success of each level, for the life of the program.

A sponsor who nails the business case at kickoff and never revisits it hasn’t done the job. Neither has one who understood the systems landscape at design stage but stopped paying attention once build started. Each level needs to be held, not just achieved.

Which level are you actually operating at right now — and is it because you chose to, or because it’s the only one your reporting lets you see?