The materials, approvals, and systems in scope
A project scope names what the use case may read, which calls it may make, who approves, and where the result lands. Getting these four right is most of the work of scoping.
· 4 min read
IN SHORT
An E31 project scope names four things: the material the use case may read, such as a corpus of the site's documents; the calls it may make, as declared routes to named on-premise systems; the role whose approval it waits for before an action lands; and the systems of record where the result must arrive. These become visible properties of the published version.
A project scope at E31 Consulting is short, and most of it is four lists. What the use case may read. What it may call. Who approves. Where the result lands. Writing those four lists carefully is most of the work of scoping, and getting them right is what makes the returned version checkable.
This article goes through each one: what it names, how specific it needs to be, and what happens if it is left vague.
Material: what the use case may read
The first list names the material the use case may read. For a corpus people can question, it is the documents: which manuals, which procedures, which records, in which versions. For a desk that drafts and waits, it is whatever the version needs to produce a good result: the inbound channel, the reference material, the prior cases.
The list is specific. Not the document store, but these documents from it. Not the records system, but these record types, for these purposes. Substrate indexes what the scope names, and the version retrieves from that and nothing else.
Specificity matters for two reasons. A curated corpus produces better results than a dump. And the site team can read the list in the version afterward and know exactly what informs the answers they are getting.
If the material in scope includes anything the version will be adapted on, the scope says so, and the adapters stay on the appliance with everything else.
Calls: what the use case may reach
The second list names the on-premise systems the version may call, as declared routes. Each route has a system on the other end and a purpose: read the schedule from the planning system, write the draft to the ticketing system, file the answer in the records system.
The version makes no call the scope did not declare. On a connected site, every route reaches a system the customer already secures. On an air-gapped site, every route stays inside the building. The routes are properties of the version, so the site team can see them and change them when a system changes.
Leaving this list vague produces a version that either cannot reach what it needs or reaches more than it should. Neither is acceptable, and both are avoidable by naming the systems at scope.
Approvals: who still has to act
The third item names the role whose approval the version waits for before an action lands. There is almost always such a role. The desk that drafts and waits is waiting for someone. The corpus that answers questions may still need a person to confirm before an answer goes to a customer.
The scope names the role, not the department. Several people can hold the role, but the role is clear enough that the version can wait for it and the run record can show who acted. When the person changes, the site team reassigns the role in Agency Studio.
A scope with no approving role is a scope for a use case that acts without anyone looking, which is rarely what a customer wants on the first version. A scope with an unclear approving role is a gap that will surface during the build, at which point it is harder to close.
Systems of record: where done becomes visible
The fourth list names where the result has to land for the work to count as done. The ticketing system where the draft becomes a ticket. The records system where the answer is filed. The system the downstream team actually reads.
Often there is more than one. A result may need to land in one system to count officially and in another for the people who use it. Both are systems of record, and both need declared routes.
This list is where the statement of done becomes checkable. At handoff, the customer runs the version and looks in the systems of record. If the result is there, in the right form, with the right approval recorded, done is true.
How the four lists are used
During the build, the engineers hold the version to the scope. It reads the material, calls the systems, waits for the role, lands in the records, and does nothing else.
At handoff, the version is checked against the scope, list by list. After handoff, the four lists are visible in the version itself as the operating picture, and the site team changes them as the desk changes. Naming what done means covers how the outcome statement feeds the scope, and what a project delivers shows how the scope reappears in what the customer receives. The engagements page at /engagements describes scoping for both engagement forms.
Questions this raises
- What if we want the use case to read everything on a shared drive?
- The scope would name the drive and the roles that may read from it, and the corpus would be built from what is there. The practice would ask whether everything on the drive should inform results, because a corpus that includes stale or contradictory material produces worse answers than one that is curated.
- Can the approving role be a group rather than one person?
- It is a named role, and several people can hold the role. What the scope needs is clarity about which role approves, so the version can wait for it and the run record can show who acted. A role that nobody clearly holds is a gap in the scope.
- How specific do the systems of record need to be?
- Specific enough to declare a route to them. The scope names the system, what the version writes to it, and under what condition. Vague entries like the back office are not enough to build against.
KEEP READING