After this lesson, you will be able to:
- Convert a discovery sentence into a scope with explicit boundaries and a first deliverable
- Choose the first workflow using the value, feasibility, and visibility test
- Write success criteria the customer cannot quietly reinterpret later
- Say no to good ideas in a way that strengthens the engagement instead of straining it
Discovery ended with a sentence: for workflow X, owned by Y, we believe we can improve number Z. Scoping is the act of betting the engagement on that sentence, in writing, with a date.
Everything about this phase fights human nature. The customer wants everything. You want to be liked. The sentence wants to grow clauses. Scoping is the discipline of keeping it short anyway.
#Choosing the first workflow
Discovery usually produces several candidate workflows. The first one you build for is a strategic choice, and the test has three parts.
Value: improving this workflow moves a number someone already reports upward. Not a number you invented. One that exists in a dashboard or a monthly review today.
Feasibility: the data it needs passed your audit, the systems it touches will grant access this quarter, and the workflow's exceptions are survivable. You are not choosing the biggest problem. You are choosing the biggest problem you can hit from here.
Visibility: people see this workflow succeed. A back-office win nobody notices buys no momentum. The ideal first target is watched by many, owned by your champion, and small enough to finish before belief runs out.
Three candidate workflows survive discovery. A: huge value, needs data from a system whose owner has slow-walked every request. B: moderate value, clean data you already have, watched by the whole operations floor. C: high value, clean data, but its owner is a sceptic who joined the company last month. Which do you scope first?
#Writing a scope that cannot drift quietly
A scope document for an FDE engagement fits on one page, and its power comes from three sections most scopes omit.
What we are building first: the workflow, the owner, the number, and the date of the first working version. Specific enough that a stranger could check whether it happened.
What we are explicitly not building yet: the eleven good ideas from discovery, listed by name, with the word yet. This section does more political work than the rest of the page combined. It shows every stakeholder their idea was heard, and it converts scope creep from an ambush into a scheduled conversation.
What we are assuming: data access arriving by a date, an operator's time for testing, a sandbox environment. Each assumption names what breaks if it fails. When the access does not arrive, the schedule conversation is already half-written, and it is about the assumption, not your competence.
#Ship in week one, even if it is small
The Palantir habit of delivering something inside the first week is not bravado. It is the cheapest instrument ever invented for measuring an organisation.
The first shipped thing, however small, forces every hidden pipe to carry water. Access requests turn out to be approved or stuck. The deployment path exists or does not. The operator who promised feedback gives it or vanishes. You learn more about the true shape of the engagement from one tiny deployment than from a month of planning, because planning cannot detect what people do, only what they say.
It also transforms your standing. Before the first ship, you are a consultant with opinions. After it, you are the person who built the thing Maria uses every morning. Different conversations follow.
What qualifies as shipped is deliberately modest: a real user, a real task, running somewhere that is not your laptop. A dashboard on live data. One automated step in a twelve-step process. The demo standard from the lifecycle lesson applies in miniature: never show a path you have only run once.
#Saying no without spending trust
Scoped engagements attract requests immediately. The sponsor's peer wants a variant for their team. The operator wants three more features. Each request is individually reasonable, which is what makes scope creep feel like customer focus while it kills the schedule.
The FDE no has a structure. Acknowledge the value honestly. Place it: on the not-yet list, with the criteria that would promote it. Restate what the current scope protects, in the requester's terms, because the fastest way to lose the argument is to defend your schedule instead of their outcome.
There is one class of request that overrides scope: evidence that your chosen workflow is wrong. Scope protects a bet, not an ego. If week-two reality says the bet was misplaced, rescope loudly and in writing. The failure is not changing the scope. The failure is the scope changing silently, one reasonable request at a time, until the date arrives and nothing is finished.
Why does the first-workflow test weight visibility so heavily?
#Key Takeaways
- Scope is the discovery sentence with boundaries and a date, on one page.
- Pick the first workflow by value, feasibility, and visibility, and weight visibility for deliverable one.
- Write the not-yet list by name. It converts ambushes into scheduled conversations.
- Success criteria need a metric, a dated baseline, a target, and a method. Baselines not written down get renegotiated by memory.
- Ship something real in week one. It measures the organisation and changes your standing.
- Change the bet loudly when evidence demands it. Never let it change silently.