Part II · Chapter 2 · The Boundary · lesson 9
The exclusion that is defensible and still loses you the deal
14 min
Builds on The two hundred questions, and the three they are really asking
Part II · Chapter 2 · The Boundary · lesson 9
14 min
Builds on The two hundred questions, and the three they are really asking
Two boundary statements. Same company, same controls, same period, same auditor. Both narrow. Neither says anything untrue.
The first.
The Orrery production platform, and the identity and deployment systems that control access to it. The 39 people who can reach production or read customer records. Outside this boundary: the analytics add-on, which holds aggregated usage data and no customer records and runs in a separate account; the internal reporting tools; the marketing site.
The second.
The Orrery core service and its supporting infrastructure, for the period stated. Systems and functions not directly involved in delivery of the core service are out of scope pending further assessment.
Predict
Three things make a narrow boundary read as discipline rather than evasion. None of them is about being wider.
The exclusions are enumerated. Named things, not a residual category. A residual category is an exclusion whose contents the reader has to guess, and they guess high.
Each exclusion says what it holds. Aggregated usage data and no customer records lets a reader decide in one beat whether they care. Not directly involved in delivery lets them decide nothing.
The line is drawn on a predicate they can apply themselves. Can reach production or read customer records is a test. Core service is a name for whatever you decided.
Evasion is not narrowness. It is narrowness the reader cannot measure.
Now your own version of the decision, which is harder than reading somebody else's, because the thing you want to leave out is the thing your deadline depends on leaving out.
What would you do
You sell Orrery. The production platform is in reasonable shape and the period opens in five weeks. There is also an analytics add-on: three engineers, a separate cloud account, its own database, used by about a sixth of your customers. It holds aggregated usage data — counts and timings, no customer records — and the three engineers have full access to all of it.
Bringing the add-on inside the line means a second evidence stream for every control that would claim to cover it, owned by a team of three who currently own nothing of the kind, starting in five weeks.
The whole advantage of the enumerated boundary is that a reviewer can compare it with something. They have read your competitor's, they know what the normal shape is, and three named exclusions of uninteresting things reads as a company that did the work.
When the buyer has no comparable vendor to measure you against — a new category, a bespoke arrangement, the first time their procurement team has evaluated anything like you — the comparison is not available. Then enumeration reads as what it literally is: a list of three things you did not cover. Without a baseline, specific looks worse than vague, which is the one situation in which the fourth option's authors were not being lazy.
The response is to supply the baseline yourself: say what is ordinarily inside a boundary like this and where yours differs. That is more work than a sentence and it is the only thing that substitutes for a reviewer who has seen ten others.
Check