Eight Words Every Program Sponsor Should Be Able to Define

Most executives sponsoring a technology or transformation program were never taught to distinguish a problem from a solution, or a requirement from the thing meant to satisfy it. There’s no reason they would have been — until recently, that level of definitional precision was the business analyst’s job, not the sponsor’s. What’s changed is that these terms now surface directly in steering committee conversations, and a sponsor who can’t tell them apart is making decisions on an unstable foundation without realising it.

This isn’t about becoming a business analyst. It’s about eight distinctions that, left unmade, quietly determine how much a program costs and whether it delivers what was actually needed.

Problem statement vs. solution

A problem statement describes what’s wrong. A solution describes what fixes it. The two get collapsed constantly: “the problem is our finance system” is not a problem statement, it’s a solution stated as if it were the problem.

The distinction matters because a correctly stated problem opens up options. If the actual problem is “month-end close takes eleven working days and reporting to the board is late,” several paths present themselves — process redesign, better use of the existing system, a new system, additional resourcing at month-end. Stated as “the system is the problem,” only one path remains, and it’s usually the most expensive one. Whoever names the problem first tends to determine which solution gets funded, regardless of whether it’s the right one.

Need or requirement vs. solution

The same collapse happens one level down. “Requirement: real-time executive dashboard” is a solution written into a requirements document. The underlying need is more likely “budget variances are identified too late to act on them.”

A dashboard might address that need. So might a fortnightly variance report with a defined escalation trigger, at a fraction of the cost and delivered in weeks rather than months. When requirements are written as solutions, vendors quote against the solution, and the cheaper path is never evaluated because it was never on the table.

Root cause vs. symptom

A symptom is what you observe. A root cause is what’s producing it. Recurring complaints about slow invoice processing are a symptom; the usual response is to commission a new approval workflow in the system. Often, on inspection, the delay has nothing to do with the software — three managers routinely sit on approvals for two weeks because no consequence has ever been attached to doing so.

Rebuilding the workflow engine in that case changes nothing. The complaints return within a few months of go-live, because the constraint was never in the system to begin with. Distinguishing symptom from cause before committing budget is one of the more consistent points of failure in these programs.

Assumptions

An assumption is something treated as true without being verified. Project plans are full of them, usually unstated. “Data migration: two weeks” typically assumes the legacy data is clean enough to migrate as-is. It rarely is, and the gap is usually discovered after migration has started, by which point the two weeks has become six and the go-live date already communicated to the organisation is either missed or met with degraded data.

An unstated assumption functions as a decision nobody remembers making. Naming it in advance — “this plan assumes the data is clean; here’s how we’ll confirm that before it’s load-bearing” — is a small step that removes one of the more common causes of schedule blowout.

Dependencies

A dependency is a relationship between two pieces of work where one cannot proceed without the other. Payroll go-live scheduled for the first of the month may depend on a data cleanse, which depends on an HR restructure still under negotiation. Each of those can sit on a separate workstream, reported separately, both green, with no one responsible for tracking the chain between them.

When the dependency surfaces late — because payroll can’t run correctly — the postmortem usually finds that the connection was visible to anyone who had been asked to look for it months earlier. Mapping dependencies explicitly, rather than assuming workstream owners will flag them, is a basic but frequently skipped discipline.

Constraints

A constraint is a fixed limit the plan has to work within — commonly budget, time, or scope. Programs are routinely presented as having all three fixed simultaneously, which is not a plan; it’s a trade-off that hasn’t been made yet. Something will give, usually near go-live, usually under pressure rather than as a deliberate choice.

Naming the constraints early doesn’t remove the trade-off. It determines whether that trade-off gets decided deliberately, in advance, or forced onto the program at the worst possible time.

Stakeholders vs. users

A stakeholder is anyone with an interest in the outcome or the authority to affect it. A user is someone who operates the system day to day. The two overlap but are not the same group, and treating “stakeholders” as shorthand for “the people who’ll use it” routinely leaves out the people who control the budget, the timeline, and whether the program survives a change in leadership.

When engagement is scoped to users only, key decisions get validated with the wrong audience — and unwound later when the people who actually held the authority see the system for the first time at go-live.

Why this is worth the attention

None of these eight distinctions require technical training. They require the discipline to ask, before a decision is signed off: is this the problem or a symptom of it? Is this a need, or has a solution already been written into the sentence? What are we assuming that hasn’t been tested? What does this depend on, and who’s tracking that? Which constraint are we actually trading off, and did we choose to?

A status report can stay green for months while the gap between what was needed and what was approved widens underneath it — not because anyone was dishonest, but because the words that would have exposed the gap were never used precisely enough to catch it. That’s a definitional problem, and definitional problems are the cheapest ones to fix, provided someone is asking the questions before the money is spent rather than after.