Most significant projects in a growing business have a “sponsor”: a senior person whose name is on the plan, who opens the kick-off meeting and who is supportive throughout. Eighteen months in, a key assumption fails and the sensible move is to stop part of the work and redirect the money. The question goes to the sponsor, who agrees it looks right and says they will need to raise it with the owner, because a change of that size is not theirs to make. At that moment everyone learns something they should have known on day one: the project had an endorser, not a sponsor.
The same projects often have a second gap. The people who govern them represent the money and the builders: the owner or manager who approved the funding, the project lead, perhaps the main supplier. The people who must actually change how they work for the benefits to arrive, the warehouse supervisor, the planning team, the service coordinators, are consulted occasionally but not seated. Decisions that shape their working lives for years are made without them, and the benefits quietly fail to appear.
This article explains why sponsorship is an office defined by the authority to stop, why the people who must turn an output into value deserve a seat while decisions are made, and how to write benefits as commitments by named owners rather than forecasts by a project. It is general information for owners and managers running change in their businesses.
A sponsor is defined by the power to stop
A useful definition from project management teaching describes the sponsor as the lowest level in the organisation with the authority to start and stop the project, and as the first point of escalation. Practitioner guidance adds a second property: the sponsor is the person for whom the work is done, who carries the risk if it goes wrong.
Put together, sponsorship is an office with two properties: authority sufficient to start and stop, and ownership of the consequences. Chairing meetings and championing the change are useful additions, not the substance.
Three misreadings are common:
- Sponsorship is a level. Businesses often appoint the most senior person connected to the work. But seniority and delegated authority are different. A manager with authority to commit the money is a better sponsor than a more senior person who would have to ask. Position the sponsor as close to the work as the authority allows.
- Enthusiasm is a qualification. The office exists to make continuation decisions. Someone who cannot imagine stopping cannot perform its central function. The right disposition is ownership, not advocacy.
- Sponsorship is a relationship to manage. It is an office, with a holder, a delegation, obligations and a record.
The power to stop matters because stopping is an individual act. Someone has to accept the sunk cost, tell the people affected and defend the decision afterwards. A committee can withhold approval, but it rarely stops anything.
Five tests of a real sponsor
- Name test. One person, named in three seconds. Not a committee, not two people jointly.
- Delegation test. Does their authority cover the remaining commitment? If not, raise it in writing for this project, or choose someone whose authority already covers it.
- Exposure test. If the project fails, whose results or budget carry the consequence? If not the sponsor’s, the office has been separated from the risk.
- Resource test. Can the sponsor commit the people and time the plan needs, not just request them? This is the most common point of failure.
- Awareness test. Ask the sponsor what they believe they can decide. The gap between their answer and the plan is the real position.
When projects fail two or more tests, the remedy is rarely to find someone more senior. It is to write the delegation down.
Disagreeing with the sponsor
Practitioner advice on disagreement is sensible: if the sponsor’s direction seems wrong, say so honestly; if they hold their position, follow it and work to make it succeed. That is how decision rights should work. But it depends on one condition: the disagreement must be heard and recorded. Without a record, an accurate warning can disappear, and a later failure gets attributed to delivery. The workable version is simple: the concern is stated and noted, and the sponsor’s decision is noted as the sponsor’s. That does not challenge authority; it makes authority accountable. The decision rights before meetings article covers keeping a simple record of who decided what.
Seat the people who turn outputs into value
A project produces an output: a system, a building, a redesigned process, trained staff. The benefit arrives only when people change how they work: when orders stop being re-keyed, when scheduling follows the new system instead of the old spreadsheet, when the old process is switched off. That change happens in the operational business, not in the project.
One well-known governance approach, described by G. J. Rankins, gives the people who govern a project three named interests: one representing the business funding the work, one representing those building it, and one representing those who must use what is built and deliver the benefits. Two details matter. The seats are not equal: there is a single point of accountability, the person representing the business, supported by the other two. And it is about who is represented, not how often they meet.
Seating the users changes three things:
- Trade-offs are made with the operating consequence visible. When scope is cut, the item most likely to go is the one that is expensive to build and whose value is diffuse, often the part that makes the result usable. A seated user makes that visible.
- Acceptance means something. Acceptance by someone who must live with the result is a judgement. Acceptance by people who will not is a completeness check.
- The receiving team prepares. A seated representative spends months watching the change take shape and preparing processes, training and people.
Fill the seat by exposure, not seniority: the person whose own results move if adoption fails, often a supervisor or operations lead. Make sure they can commit their team to a readiness date without having to ask, and that their team actually has the capacity. And be clear that representation is not a veto: the sponsor still decides; the user has a voice and a role in acceptance.
Not every project needs this. If the value arrives simply because the thing exists and works, such as a replacement roof or a compliance upgrade, the funding and user interests are effectively the same. The test is whether anyone has to change what they do for the benefit to arrive.
Write benefits as commitments by named owners
Benefits often fail not during delivery but in the quiet months afterwards, when the capability exists and the behaviour has not changed. The project manager cannot own those benefits: they have no authority over how an operational area works months after handover, and are usually on another job by then.
Treat each expected benefit as a claim made by a named owner about a change they will make. Instead of:
The new scheduling system will reduce planning effort by one full-time role.
write:
The planning supervisor will reduce the scheduling team from three to two roles by the end of the third quarter after go-live, provided at least 90% of schedules are accepted without manual changes. Evidence: roster and schedule acceptance rate.
The second version names the person, the action, the timing, the condition and the evidence. It is harder to write and will be resisted. It is also the only kind that can be realised, and it exposes something the first hides: the benefit depends on a decision someone has not yet agreed to make. If nobody will sign it, the benefit is not real, and the business case should shrink accordingly. The when the project succeeds and the strategy fails article covers testing projects for outcomes rather than outputs.
Five tests for each benefit
- Named owner: has a specific person read and accepted the claim?
- Behaviour: what will people do differently? “Use the new system” is an activity, not an outcome.
- Switch-off: what existing process, tool, role or cost will stop, and on what date? Benefits that depend on something ending only arrive when it actually ends.
- Evidence: what measure will show the benefit, and will it still be produced a year after the project closes?
- Stabilisation: how long will performance dip while people learn, and who carries the extra load?
The cheapest, most effective intervention is often to keep a small amount of support available for a defined period after go-live, with explicit authority to switch off the old way. While the old spreadsheet or process remains available, people will use it whenever the new one is inconvenient.
A worked example
This is an illustration. A manufacturer with 60 staff is implementing new production scheduling software. The project’s named sponsor is the general manager. The steering group is the owner, the general manager, the software implementer and the project lead. The planning supervisor, whose team will use the system every day, attends when invited.
Running the sponsor tests reveals gaps. The general manager’s approval limit is $20,000; the project still has about $85,000 to spend. The general manager has never stopped a project and assumes the owner would decide anything significant. The owner and general manager agree in writing that the general manager holds authority for this project up to $100,000, including authority to pause or stop it, and will consult the owner only if the remaining budget would be exceeded.
The planning supervisor is given a seat, a voice on scope changes and a role in final acceptance. At the first meeting with the supervisor present, a proposed scope cut, removing the screen that shows machine changeover times, is reversed: the supervisor explains that without it, planners will keep using the old spreadsheet.
The business case originally said the system would “save one full-time role”. It is rewritten as a claim by the planning supervisor: the team will go from three to two by the third quarter after go-live, if at least 90% of schedules are accepted without manual changes. The old spreadsheet will be switched off six weeks after go-live. The implementer provides two days a week of support for eight weeks after launch to cover the dip.
Six months after go-live, the acceptance rate is 92%, the spreadsheet is gone and the team has reduced to two through a planned retirement. The benefit is visible in the roster, and the supervisor presented it.
How this applies to a small Australian business
- Name one sponsor for each significant project, and write down what they can decide, including stopping.
- Check the sponsor’s authority covers the remaining commitment.
- Record disagreements and the sponsor’s decisions.
- Seat the person whose team must change, where benefits depend on behaviour.
- Write benefits in the owner’s voice, with action, timing, condition and evidence.
- Schedule the switch-off of old processes and tools.
- Plan for the dip after go-live with temporary support.
- Review benefits six and twelve months after go-live, with the owner presenting.
Signals worth watching
- Sponsors who need to ask someone else before making significant decisions.
- Sponsors who have never stopped anything.
- Users consulted but never seated.
- Benefits described as what a system will do, not what someone will change.
- Old processes still running months after go-live.
- Benefit measures that stop when the project closes.
Common mistakes
- Appointing sponsors for seniority rather than authority.
- Choosing enthusiasts who cannot contemplate stopping.
- Making the project manager responsible for benefits.
- Leaving users outside the decisions that shape their work.
- Forgetting to switch off the old way.
- Expecting benefits to start the month after go-live.
Frequently asked questions
Can the owner always be the sponsor? Often, in a small business. But if the owner sponsors everything, decisions queue. Delegating sponsorship of a defined project, in writing, can speed things up.
What if the users resist? Resistance is often information about how the work really runs. Seating them early surfaces it while there is still time to adjust.
Should the sponsor attend every meeting? Not necessarily. What matters is that they make the decisions reserved to them, promptly.
How detailed should benefit claims be? Detailed enough that someone could check them a year later: who, what, when, under what condition and how it will be measured.
What if a benefit cannot be measured directly? Choose the best available evidence, such as a time saving sampled monthly or a customer measure, and agree it in advance with the owner.
Questions to ask
- Who can stop this project next week, without asking anyone?
- Does that person’s authority cover what remains to be spent?
- Whose team must change how it works for the benefits to arrive, and are they at the table?
- Is each benefit written as a commitment by a named owner?
- What will be switched off, and when?
- Who carries the load during the dip after go-live?
Bringing it together
A sponsor is the person with the authority to start and stop a project and the exposure to its consequences, not its most senior supporter. Name one, write down what they can decide, and record disagreements and decisions. Where benefits depend on people working differently, give those people a seat while the decisions that shape their work are made. Write each benefit as a commitment by a named owner, with the action, timing, condition and evidence, schedule the switch-off of the old way, and support people through the dip. Projects deliver outputs; the right people at the table turn them into results.
Source: KEVOS notes, drawing on teaching and practitioner material on project sponsorship, G. J. Rankins’ comparison of two project management methods and their board structures, P. Morris and A. Jamieson on programme and benefits management, and teaching material on benefits realisation. Examples and figures in this article are illustrations. This article is general information.
