Step 04

Clarify

In Brief — Proposals arrive as solutions. This step takes them apart to find the actual business problem, defines the intended outcome in operational terms, and names the assumptions the proposal depends on — before the organization commits to an approach it may not yet fully understand. A governance forum can make a responsible decision about a well-defined problem. It cannot make a responsible decision about a solution nobody has examined.

What’s Actually Happening

The intake form came back with a solution on it.

It happens almost every time. Someone submits a request and what they describe — in the problem field, in the outcome field, in the scope field — is the answer they have already decided on. “We need a new CRM system.” “We need to hire three analysts.” The problem is embedded in the solution description, implied but never stated. The outcome is described as the delivery of the solution, not as what changes in the organization when the solution works.

This is not dishonesty. It is how people think when they have been living with a problem long enough to form a strong opinion about the fix. The solution feels obvious. The problem feels self-evident. Why spend time defining what everyone already knows?

Because everyone does not already know it. And because the obvious solution is often not the right one.

Why This Step Exists

Because approving a solution without validating the problem is one of the most expensive mistakes an organization can make at scale.

The technology that gets implemented and then not adopted. The process redesign that solves the documented problem and creates two new ones nobody anticipated. The system that goes live and then the team discovers that what the system does and what the operation needed are not the same thing. In most of these cases, someone would have caught the disconnect if the problem had been clearly defined before the solution was selected.

There is a second reason this step exists. Assumptions made at this stage travel all the way through delivery. An assumption that goes unstated at Step 4 does not disappear. It becomes a hidden dependency in the project plan, a gap in the risk register, a surprise at go-live, or an explanation for why the promised benefits never materialized.

Naming assumptions is not a signal that the work is uncertain. All work has assumptions. Naming them is what makes the uncertainty manageable.

What Good Looks Like

The submission that leaves this step looks different from the submission that entered it.

The problem is stated in terms of what the organization cannot do, or does not do reliably, or does at too high a cost — not in terms of what system is needed to fix it. The intended outcome is stated in terms of what will be measurably different for a specific person or process in the organization. The key assumptions are listed, with a note on what would need to be true for each one to hold.

The proposed solution may still be on the table. Often it is the right answer. But now it is a proposal being evaluated against a defined problem, not a decision waiting for ratification.

How to Do It

The clarification step is a conversation, not a form review. Schedule a working session with the sponsor and whoever knows the operational reality of the problem. In many organizations, the Business Analyst owns and leads this conversation — they are trained to separate stated requirements from actual need, surface the assumptions underneath a proposal, and define outcomes in specific, measurable terms.

Start with the problem, not the solution. “Help me understand what’s actually happening today that prompted this.” The solution will come up repeatedly. Redirect gently. “We’ll get to what you are proposing — first help me understand the problem we are solving for.”

Move to the outcome. “When this work is done and it’s working the way you hope, what will be different? Not different about the system — different about the operation.” The answer should be specific enough that a year from now, someone could look at the operation and say definitively whether it changed or not.

Then surface the assumptions. “What has to be true for this approach to work?” Ask about adoption. Ask about dependencies. Ask about organizational capacity. Each assumption that gets named becomes a risk to manage. Each one that goes unstated becomes a surprise.

What Breaks When You Skip It

The governance forum reviews a solution and approves or rejects it without ever establishing whether the solution was the right one.

If the solution is approved, it moves into delivery carrying all the assumptions that were never examined. The project team builds to the approved spec. The business discovers mid-delivery that the spec was built on a misunderstanding of the problem. Scope change happens. Costs increase.

The organization spends significant time and money on solutions it cannot evaluate. It never builds the capability to ask, clearly and confidently, whether a proposed investment is the right response to the problem it claims to address.

The Gotchas

The requester feels interrogated. The clarification conversation can feel like a challenge to the work they have already done if it is not framed correctly. “I want to make sure I understand this well enough to advocate for it in the review” gets a different response than “I need you to prove this is necessary.”

The problem statement becomes a performance. Once people understand that a well-defined problem statement moves faster through the process, some will write problem statements that sound thorough without being honest. Ask the operational question: “Walk me through what actually happens in the process today.”

Urgency is used to skip this step. When urgency is invoked, the minimum viable version of this step still applies: name the problem, name the intended outcome, list the critical assumptions. It takes an hour. It is worth the hour.

The clarification step tries to solve the problem. This step defines the problem. It does not develop the solution. When the clarification conversation turns into a design session, redirect it.

Where the Disciplines Show Up

→ Decision Discipline: The clarification step defines what the governance forum will actually decide. A vague problem statement forces the forum to make assumptions and fill gaps. The better this step is executed, the better the decision at the tollgate.

→ Change & Absorption: Ask the adoption question here: does this solution require people to work differently? If yes, who, how significantly, and is there a plan for getting them there? An initiative that depends on behavioral change but has no change management plan is carrying a risk that needs to be named before approval.

→ Enterprise Fit: Clarification is the first opportunity to ask whether the proposed solution is compatible with the organization’s existing architecture, data landscape, and security posture. Not a full review — a flag. “Has this been looked at from an architecture perspective?”

→ Evidence: Distinguishing between what is known and what is assumed is the core discipline of this step. Every proposal has both. Naming them creates a foundation the rest of the governance process can build on.

→ Political: Scope clarification can reveal that the original proposal was shaped by the interests of the person who wrote it rather than the needs of the organization. A clarification conversation that surfaces a problem with a sponsor’s proposal requires the practitioner to be both rigorous and respectful — honest about what the problem statement does not support, and careful about how that honesty lands.

The Key
Make assumptions visible before they become commitments. An assumption that is named can be managed. An assumption that is not named travels silently through the project until it surfaces as a problem that looks like bad luck.

You know this step is working when the problem definition in the proposal file is materially different — more specific, more honest, more constrained — than what was in the original intake submission.

The Artifacts

T17 — Problem Statement Template

A structured format for documenting the problem in operational terms: what is happening today, who is affected and how, what the consequence of not addressing it is, and how the organization currently knows this is happening. No more than one page.

T18 — Assumptions Log

A table listing each assumption the proposal depends on, the confidence level, the evidence behind it, and what would need to happen to test it. This document travels with the proposal through every subsequent step and gets updated as assumptions are confirmed, revised, or invalidated.

T19 — Outcome Definition Worksheet

A structured format for defining what success looks like in operational terms: what will be measurably different, for whom, within what timeframe, and how it will be confirmed. The outcome defined here becomes the hypothesis the cost-benefit analysis tests and the benefits register tracks.