Day 3: Define Outcomes, Scope, and Success

The Concept

Scope problems rarely arrive as one dramatic request. They arrive as small additions: while we are doing that, could we also include this? By the time the team notices, the project has become a collection of reasonable requests with no shared definition of success.

The protection is not a longer requirements document. It is a clear relationship between outcomes, deliverables, and boundaries.

Outcome before output

An output is something the project produces: a dashboard, training session, workflow, or release. An outcome is the difference that output is meant to make: people find information faster, new hires complete setup without support, or customers receive a response within an agreed time.

AI can help you test whether a statement describes an outcome or merely an activity. Ask: “How would we know this changed?” If nobody can answer, the statement needs work.

Scope is a choice

In-scope work belongs in the current project. Out-of-scope work is not a rejection of its value; it is a decision about focus, timing, ownership, or capacity. Writing it down protects the team from having to renegotiate the same question every week.

Use AI to suggest boundaries, then confirm them with humans. It does not know which stakeholder has authority to change scope or which promise has already been made elsewhere.

Measure without pretending

A good measure gives the team evidence. It does not need to be sophisticated. Time saved, completion rate, error rate, adoption, response time, and satisfaction can all be useful when defined carefully.

Separate leading indicators from lagging indicators. A leading indicator shows whether the work is moving in the right direction. A lagging indicator shows whether the intended result actually happened. The distinction helps teams avoid celebrating activity as success.

Use this today

Take one project goal and rewrite it using this format:

We will know this worked when [WHO] can [OBSERVABLE CHANGE] within [CONDITION OR TIMEFRAME], measured by [EVIDENCE].

Then write three boundaries beginning with “This project will not…” Read them aloud. If they feel uncomfortable, that is useful information: the project may still be negotiating its real scope.

A simple scope test

For every proposed item, ask four questions:

1. Which outcome does this support?
2. Who needs it, and what evidence shows that need?
3. What happens if we do not include it now?
4. What other work, decision, or dependency does it create?

If an item supports no agreed outcome, it may be a distraction. If it supports several outcomes, it may be more important than the current plan suggests. If nobody can answer what happens when it is excluded, the request may not yet be understood well enough to estimate.

Example: from ambition to evidence

Consider the goal “improve internal reporting.” It sounds reasonable but gives the team too many possible directions. A clearer version might be: “By the end of the pilot, department leads can find the agreed weekly performance figures in one place and use them to prepare their review without requesting manual extracts.”

That outcome suggests possible deliverables, but it does not dictate one solution. The team may still need to decide whether the answer is a dashboard, a report, or a better operating process. The evidence might include successful access, agreed definitions, usage during a review, and a reduction in manual requests.

This is the kind of thinking AI can accelerate. Give it the vague goal, ask what would make the change observable, and then challenge its suggestions against what your organisation can actually measure.

Scope boundaries protect quality

When scope expands, quality often becomes the hidden sacrifice. Testing gets shortened, documentation is dropped, or the team carries unresolved work into operations. Writing exclusions early gives you a reference point when new requests arrive.

A useful exclusion is specific: “This phase will not redesign the approval policy” is stronger than “policy work is out of scope.” It tells people where the boundary sits and what conversation would be needed to move it.

Review questions for the owner

Before confirming scope, ask: Which outcome matters most if we cannot achieve all of them? What is the minimum acceptable result? Which user or stakeholder should be involved in acceptance? What is the cost of delaying this work? Which request would we remove if capacity fell by 20 percent?

AI can help you generate the questions, but the answers belong to the project owner and affected people.

When scope changes

Scope change is not automatically bad. Projects learn as they progress. A new piece of work may be essential because a risk became real or a user need became clearer. The problem is unexamined change: adding work without acknowledging what it costs or what it displaces.

Ask AI to help write a change-impact summary with five headings: reason for change, benefit, work added, impact on time and risk, and decision required. Use it to improve the conversation, not to manufacture approval. The accountable decision-maker still needs to choose.

Avoid measurable-looking nonsense

AI is very good at producing measures that sound professional. “Improve engagement by 20 percent” is not useful unless engagement is defined, a baseline exists, and someone can collect the evidence. Ask the model to challenge every proposed measure: what exactly is counted, when is it measured, and what decision would the result support?

A final check before sharing

Ask one affected user or stakeholder to describe what will be different if the project succeeds. Compare their answer with the brief. If the two answers differ, that is not a writing problem; it is a scope conversation the project needs to have before work expands.

Record the final decision and the evidence the team will use to judge it. A measurable outcome is only useful when someone knows how it will be observed.

Use this today

• Outcomes describe change; deliverables support change.
• Out-of-scope is a focus decision, not a value judgment.
• Do not invent certainty where the project has not made a decision.