Engagement Stages

The frame is also a diagnostic: first name the stage an engagement is in, then check that stage's condition.

Programming

A Project That Feels Wrong but Has No Clear Cause

A project that is going badly rarely announces where it went wrong. The team may feel busy, the customer may seem unhappy, and the metrics may look flat. Yet nobody can say what to fix first. When this happens, the natural reaction is to ask a large question: what is wrong with this project? That question is very hard to answer, because almost everything looks like a problem at once.

Replacing a Large Question with a Smaller One

The three-phase frame gives a more precise starting point. Used as a diagnostic, it asks a simpler question than 'what is wrong with this project?' It asks two questions instead: which stage are we in, and is that stage complete? Those two questions turn a vague feeling of trouble into a bounded search. You only need to examine one stage at a time.

The frame does not tell you the cause of the problem. It tells you where to look first. Finding the right place to look is the first step in deciding what to do next, and that is the whole job of the diagnostic.

The Three Stages in Order

Definition

Engagement Stages: the frame is also a diagnostic. First name the stage an engagement is in, then check that stage's condition. If the condition is not met, the engagement is stuck in that stage.

The frame has three stages, which are scoping, validation, and delivery. They form a sequence. An engagement moves forward through them in that order, and the stage it is currently in determines which condition you check. Each stage has a test that pairs it with one concrete piece of evidence that is either present or missing.

Read the diagram from left to right. The sublabel under each stage names the condition that must hold before the engagement can move past it. The highlighted validation box marks a stage whose condition is not yet met, so the engagement does not move on to delivery. A stall is not a vague slowdown. It is a specific stage whose condition has not been satisfied.

Naming the Stage Before Checking It

The diagnostic has a fixed order, and the order matters. You must first name the stage. Only after that can you check the condition belonging to that stage. If you skip the naming step and go straight to a check, you may test the wrong condition and conclude that a project is fine when it is actually stuck somewhere else.

The flowchart captures the full procedure. The first two steps identify where the engagement is. The third step runs the single check that belongs to that stage. The decision at the end either locates the stall or clears the stage. Notice that the test never asks about the whole project at once.

The Stuck Condition for Each Stage

Each stage has its own stuck condition. Scoping, validation, and delivery each fail in a different way, and the difference is what lets you pinpoint the stall. The table below sets the three conditions side by side.

Stage	Engagement is stuck when	Evidence that is missing
Scoping	The customer cannot articulate the top-five priority the project addresses.	A clear, customer-stated top-five priority.
Validation	The eval set is built but the customer has not signed off on the threshold.	Customer sign-off on the threshold, even though the eval set exists.
Delivery	The system is in production but the metric is not moving.	Movement in the metric after the system has gone live.

The stuck condition for each of the three stages

Look closely at what each condition requires. Scoping is stuck on a missing customer statement about priority. Validation is stuck even though a technical artifact exists, because the agreement on the threshold is missing. Delivery is stuck even though the system is live, because the metric has not responded. The same surface appearance of progress can hide a stall in a different stage, so the test always checks the specific evidence for the named stage.

Key point

The stuck condition for a stage is the specific evidence that is missing. Presence of work in a stage does not prove the stage is complete. A built eval set or a live system is not enough on its own.

Tracing a Hypothetical Engagement Through the Frame

Worked example

Locating the stall in a validation-stage project

A hypothetical team has finished building its eval set. Its lead says the project is basically done because the test results look encouraging. The customer has not yet agreed which score counts as acceptable. Which stage is the engagement in, and is it stuck there?

1
Describe the engagement
The evidence available is an eval set that has been built, and a customer who has not agreed on a threshold. The lead's impression that the project is done is not itself evidence about any stage.
2
Name the current stage
An eval set exists, so the engagement has reached validation. The stage is validation, not delivery, because the work being checked is the agreement on what the eval set must show.
3
Check the validation condition
The validation condition asks whether the customer has signed off on the threshold. The problem states that they have not.
4
Apply the decision
The condition is not met. The engagement is stuck in validation. The encouraging test scores do not clear the stage, because the stuck condition is about the missing sign-off.

Result

The engagement is stuck in validation. The next step is to get the customer to agree on the threshold, not to start delivery work.

Mistakes When Using the Frame

Common mistake
Asking what is wrong with the whole project
Why it fails
The frame is designed to replace that large question with a narrower one: which stage are we in, and is that stage complete?
Do this instead
Name the stage first, then examine only that stage's condition.
Common mistake
Checking a condition before naming the stage
What it looks like
Testing whether the metric is moving when the team has not yet confirmed the customer's priorities.
Why it fails
The stuck condition belongs to a specific stage. Checking the wrong one can clear a project that is actually stuck earlier.
Do this instead
Follow the fixed order: describe, name the stage, then check that stage's condition.
Common mistake
Treating visible work as proof a stage is complete
What it looks like
Reading a built eval set as proof that validation is finished.
Why it fails
Validation is stuck when the threshold is not signed off, even if the eval set exists.
Do this instead
Look for the specific missing evidence the stage requires.
Common mistake
Mistaking a slow project for a stuck one
Why it fails
The source asks what evidence would show a project is stuck in its stage rather than simply moving slowly. A slow project still has its stage condition met or on its way to being met.
Do this instead
Decide whether the named stage's stuck condition is actually present before calling the project stalled.

Predicting the Stuck Stage Before Reading the Answer

What do you think happens?

A system has gone live in production. The dashboard is running, but the success metric has not moved for six weeks. Before reading on, which stage is the engagement stuck in?

Reveal answer

Answer:

Delivery.

The delivery stuck condition is that the system is in production but the metric is not moving. The scenario meets that condition exactly, so the engagement is stuck in delivery. The live system shows that scoping and validation have been passed, so the stall sits in the last stage.

MEDIUM

A different hypothetical engagement has a clearly written document listing the customer's top five priorities, and the team has begun building an eval set. The customer has not yet agreed on the threshold that the eval set must reach. Name the stage the engagement is in, state which condition it fails, and explain what evidence would clear the stall.

Hints

Start by naming the stage. An eval set exists, so think about which stage builds one and which stage requires agreement on what it must show.
Check whether the scoping condition is met. The top-five priorities are written down, which is the scoping evidence.
The stuck condition in the stage you name is the one that matters. Which piece of evidence in that stage is missing?

Your attempt (not saved)

Key Takeaways

The three-phase frame turns a vague sense of trouble into two precise questions: which stage are we in, and is that stage complete?
The stages are scoping, validation, and delivery, and they are followed in that order.
Each stage has a stuck condition: scoping stalls when the customer cannot articulate the top-five priority, validation stalls when the threshold is not signed off after the eval set is built, and delivery stalls when the system is in production but the metric is not moving.
The diagnostic always names the stage first and checks only that stage's condition. The frame shows where to look first, not the cause of the problem.