The steering pack is detailed and the supplier gives a confident account of progress. Workstreams are moving, demonstrations are frequent and actions have owners.
When the sponsor asks which business outcomes are now proven, which choices remain open and whether the organisation will be ready to operate, the answers still come mainly from the supplier.
That does not make the supplier the problem. A capable delivery partner should lead its plan, people and products. The risk is that the client has also allowed the supplier to become the clearest authority on the outcome, priorities, decisions and evidence of success.
Projects rarely become supplier-led through an explicit handover. Control moves gradually as unresolved client questions become supplier assumptions so that delivery can continue.
Each step can look reasonable alone.
1. The plan describes supplier activity, not client outcomes
The status report lists workshops held, designs completed, tickets closed, environments configured and percentage complete. These measures help a supplier manage delivery. They do not show whether the intended service is becoming workable.
A client-controlled plan connects activity to an organisational outcome or critical journey. It shows the decisions and dependencies needed next, the evidence that will demonstrate progress, the operational preparation still required and the conditions for business acceptance.
Ask what a completed activity has made possible. A configured renewal workflow may be progress. It becomes evidence only when representative users, data, integrations and rules demonstrate the agreed result. It becomes readiness when staff, support and finance can operate it safely.
One familiar pattern is a status report becoming more detailed as the decision it should support becomes less clear. More delivery data cannot compensate for an absent client view of success.
2. Business choices arrive as technical constraints
A configuration workshop is told that the platform requires one approach. Sometimes that is true. Sometimes the platform supports several approaches but one is simpler for the current delivery. The client still needs to understand the options and consequences.
Choices about membership rules, data ownership, permissions, exceptions, support and future flexibility can be consequential even when they arrive in technical language. They should not be accepted accidentally by the people closest to a workshop.
Define decision rights before the decisions become urgent. The supplier decides how to deliver within agreed constraints, while the operational owner decides how the service should work. Cross-system and risk trade-offs belong to the client technology owner; material scope, cost and outcome trade-offs belong to the sponsor. Readiness and acceptance remain with the authorised business owner.
Not every decision needs a committee. It needs the right owner, a clear recommendation, enough evidence and a latest safe date.
The choice can be effectively made in a configuration workshop several weeks before the steering group first sees it as a project decision.
When a consequential choice appears only in a ticket comment, the organisation may discover its effect after it has been built into data, process and contract assumptions.
3. Demonstrations create enthusiasm but no decision
Demonstrations are valuable. They make abstract work visible and allow operational users to challenge it early. They become weak governance when positive reactions are recorded as approval without stating what was actually proven.
Before each demonstration, identify the requirement or journey being examined, the conditions and data being used and anything simulated or absent. Be explicit about the decision or feedback required and where unresolved points will be recorded.
A screen can work while identity matching, permissions, migrated data, payments, communications or support handling remain unproven. Applause at the end of a demonstration is not business acceptance.
In troubled projects, stakeholders often remember approving the appearance of a journey while the supplier remembers approval of the design. Both accounts can be honest. The meeting simply did not distinguish feedback, decision and acceptance.
4. The change log becomes the real requirements document
Change is normal. A steady flow of change requests can also reveal that the original requirement, discovery or commercial boundary was not strong enough.
Before approving cost or delay, classify each proposed change as:
- a genuinely new business need;
- a missing or unclear requirement;
- an incorrect supplier or client assumption;
- a defect against agreed behaviour; or
- incomplete delivery of an existing commitment.
The classification affects accountability, priority and commercial treatment. It also tells the steering group whether it is dealing with isolated change or a systemic weakness.
When the change log becomes the busiest governance document, it has usually started carrying the requirements, assumptions and design decisions that were never settled elsewhere.
If the supplier alone defines the category, estimates the work and recommends the response, the client has no independent basis for change control. The answer is not to reject supplier advice. It is to compare the advice with the organisation’s own requirement, decision record and business value.
This is why procurement clarity matters. A proposal and a backlog cannot safely become the only account of what the organisation needs.
5. The client cannot explain the current position
Ask the sponsor or senior responsible owner to explain, without opening the supplier report, which outcomes have been demonstrated, what important work remains and which decisions cannot wait. They should also be able to say what is driving cost or delay, what remains materially uncertain and what would prevent operational release.
If the answers depend on bringing the supplier into the room, the organisation lacks an independent view. That does not require duplicating a delivery team’s detailed reporting. It requires interpreting that information in the context of the outcome for which the client remains accountable.
A useful client view is often shorter than the supplier report. It should make the business consequence, evidence, uncertainty and decision explicit.
This gap often develops because the supplier has the people and routines to keep its account current while client leaders are balancing operational roles. Capacity is therefore part of control. Naming an internal owner without giving them time, authority or technical support does not solve the problem.
6. Supplier completion becomes business acceptance
A system can be delivered and deployed while the organisation is not ready to use it.
Data may not reconcile. Staff may be unable to resolve exceptions. Payments or communications may not work across the complete journey. Support teams may have no route for an incident that crosses suppliers. None of those facts necessarily means the supplier has failed to complete a contracted deliverable.
The client must define acceptance in terms of operational evidence:
- priority journeys work end to end under representative conditions;
- material exceptions can be handled safely;
- data has been reconciled by its business owner;
- staff can perform the new process with appropriate access;
- support, monitoring and escalation are active;
- known risks have authorised owners; and
- the accountable business owner can sign off readiness.
At late acceptance meetings, every workstream can be marked complete while nobody is able to show the whole journey operating under one set of conditions.
“The system is live” is a deployment fact. It is not proof that the organisation can deliver the intended outcome.
The Client-Control Test
Use five lines to test whether the client still holds the right responsibilities:
| Control layer | The client must be able to state | The supplier should contribute |
|---|---|---|
| Outcome | What must become possible and why it matters | Feasibility, options and delivery implications |
| Priority | What matters first when time, cost or scope conflict | Estimates, dependencies and consequences |
| Decision | Who can choose and accept each material trade-off | Recommendation and supporting evidence |
| Evidence | What will demonstrate progress and complete journeys | Delivery results, defects and technical evidence |
| Acceptance | Who decides the service is ready to operate | Contractual completion and release support |
Score each line clear, fragile or supplier-dependent. The labels are deliberately simple:
- Clear: a named client owner can explain the position and show the current record.
- Fragile: an owner exists, but the answer depends on unavailable evidence, limited capacity or an unrecorded assumption.
- Supplier-dependent: the supplier is the only reliable source or is making a decision that belongs to the organisation.
A project does not need the supplier removed from any line. It needs the client to remain accountable for the left-hand column.
When a steering group scores the five lines honestly, the discussion moves away from whether the supplier is performing and towards which client responsibilities are no longer functioning.
The Client Architecture Function establishes who owns cross-system decisions. The Client-Control Test reveals whether the organisation still owns the outcome, priorities, evidence and acceptance around those decisions.
If fragile or supplier-dependent lines are already threatening the outcome or decision date, carry them into the Board Recovery View rather than treating them as another set of project actions.
Use the next steering meeting to restore the balance
Do not begin with a debate about whether the project is supplier-led. That language can make a constructive relationship defensive.
The temperature in the room falls once the conversation moves from blame to a named client decision, the evidence it needs and the date by which it must be made.
Instead, complete the Client-Control Test for one critical journey. Identify the fragile or supplier-dependent lines, then agree:
- the named client owner;
- the record or evidence that must be brought under client control;
- the supplier input required;
- the decision that follows; and
- the date by which the position must be clear.
Keep the supplier leading its delivery. Restore client ownership where only the organisation can legitimately hold it.
Good suppliers do not need passive clients. They need clear ones.