A sponsor does not need to understand every technology choice to govern a digital project. They do need independent technical assurance where architecture, security or quality warrants it. Commercial oversight cannot prove that the code is sound.
The sponsor's job is to establish whether the project is producing usable evidence, controlling investment and creating the organisational conditions for delivery. Those signals can be inspected without pretending to be the technology lead.
Start with the outcome and current forecast
Ask the team to restate the intended outcome, current scope, forecast cost and forecast completion. Compare them with the approved baseline and the latest authorised changes.
Healthy projects may change. The important questions are whether changes are visible, supported by evidence and accepted by someone with authority. A green status hiding a larger forecast or reduced scope is weak governance.
Track forecast to complete, contingency, committed spend and major assumptions. Avoid focusing only on money already spent. The forward view reveals whether the remaining work is affordable.
Inspect working evidence
Progress should become inspectable at a cadence appropriate to the work. A live service slice, content workflow, integrated data flow or tested prototype provides more evidence than a percentage-complete report.
Ask:
What can users or reviewers inspect now that they could not inspect at the previous review?
Early discovery may produce research, decisions and prototypes rather than production software. Those are valid when they answer agreed uncertainties. The team should explain how each artefact changes the next decision.
A demonstration is not proof of production readiness. Ask what is simulated, incomplete, unsecured or outside the normal environment. Celebrate learning without allowing theatre to replace assurance.
Examine decision flow
Projects lose weeks through unresolved choices. Maintain a decision log showing the question, recommendation, evidence, owner, deadline and consequence of delay.
Ask for the oldest material unresolved decision and why it remains open. The blockage may sit with the supplier, sponsor, legal team, content owner or an absent dependency. Assign action and escalation.
Decision speed is not the only goal. A rushed irreversible choice can be worse than a considered pause. Classify decisions by reversibility, consequence and evidence need; give low-risk choices lighter governance and consequential ones appropriate scrutiny.
Look at risks as changing exposure
A risk register becomes useful when it changes behaviour. Review the largest current exposures, movement since the last review, controls and named owners.
Ask which assumption, if false, would most damage value, cost or timing. Ask what the team is doing to learn about it. This directs attention towards uncertainty rather than a long static list.
Issues should be reported before their consequences become unavoidable. Sponsors can support this by responding constructively to early warnings. Punishing the messenger creates late surprises.
Follow scope and dependencies
Compare the agreed scope with what the team is now building. Small requests accumulate. Record additions, removals and their effect on outcome, budget and time.
Dependencies need owners and dates: access, content, data, environments, procurement, security review, client input and third-party integrations. Ask which dependency is most likely to affect the next milestone and whether the owner accepts that responsibility.
If the sponsor's organisation is the cause, fix it. Suppliers cannot deliver around permanently unavailable subject experts or decisions.
Assess quality and readiness separately
“Built” does not mean ready. Ask for the quality and acceptance evidence appropriate to the service:
- representative user-task results
- accessibility review
- security testing and remediation
- data migration reconciliation
- performance and resilience evidence
- content and legal approval
- operational support and recovery
- training and adoption readiness
The sponsor need not evaluate penetration-test technique. They should confirm that a competent owner defined the assurance, material findings have a treatment and residual risk is accepted at the right level.
Track defects by severity, age and trend rather than one total. Many trivial defects can obscure one issue that prevents safe launch.
Evaluate communication by decisions enabled
Good reporting tells leaders what changed, why it matters and what they must decide. It distinguishes fact, forecast and uncertainty.
A useful one-page status includes:
- outcome and current phase
- evidence completed since the last review
- forecast cost and date with variance
- material risks and issues
- decisions and dependencies due
- planned evidence before the next review
Ask whether bad news arrives early enough to preserve options. Avoid testing the delivery lead with theatrical questions about the last problem they volunteered. Inspect the record and create a culture in which transparent reporting is expected.
Pay attention to team conditions without mind-reading
Falling participation, repeated staff changes, missed actions and excessive overtime can indicate trouble. A sponsor should ask directly about capacity, role clarity and sustainable pace.
Do not infer project health from whether a lead sounds enthusiastic. People communicate differently, and a tired team may be doing excellent work under a temporary pressure. Use observable evidence and conversation.
Confirm that the named people in the proposal remain involved, that critical skills are covered and that client colleagues have protected time. If the delivery model changed, assess the consequence.
Use proportionate assurance
Non-technical oversight needs a technical counterpart. Arrange architecture, security, accessibility, data or delivery assurance according to risk. Independence may come from another internal specialist or an external reviewer who is not responsible for the work being assessed.
Define the review question and avoid open-ended audit. A short architecture review before a hard-to-reverse commitment can be more useful than a broad assessment near launch.
Assurance should inform a decision and track material actions to closure. A report stored outside the delivery process adds little protection.
Calibrate the response to evidence
Traffic-light status can prompt discussion, but universal rules such as “two amber months means escalation” ignore consequence and context. Define thresholds for the project.
An unapproved cost increase, critical security issue or failure of a launch dependency may require immediate action. A delayed low-risk content item may not. The team should state the recommended response: continue, correct, replan, pause or escalate.
When raising concern, name the observation and consequence. Ask for the team's diagnosis and options before prescribing delivery detail. The sponsor provides direction, decisions and organisational support; the delivery lead manages the work.
Five questions for the monthly review
- What evidence did we expect by now, and what can we inspect?
- What has changed in outcome, scope, cost, date or risk?
- Which decision or dependency most threatens the next commitment?
- What assurance is complete, missing or unresolved?
- What do you need from me before the next review?
The one-page project-health template available below can record the answers and status. Adapt its thresholds to the project and share it with the board or steering group alongside, rather than instead of, competent technical assurance.
Leadership oversight is not an attempt to out-engineer the engineers. It is the discipline of making value, evidence, exposure and decisions visible while specialists remain accountable for their domains.
