- Description
- Un phare de pierre sur une jetée rocheuse, éclairé par le soleil du soir au-dessus de la mer.
- Source
- Jebulon · original page
- Licence
- CC0 Public domain
Scoping and Vision (CAD)
A poorly scoped project does not fail at the end: it fails in the very first week, diligently pursuing a goal no one shares. The cost is considerable and hidden…
Level: 🟢→🔴 · Code: CAD · Matrix: PI
Why this topic#
A poorly scoped project does not fail at the end: it fails in the very first week, diligently pursuing a goal no one shares. The cost is considerable and hidden: discarded development work, reports no one opens, endless priority debates because “success” was never defined. Conversely, lean but honest scoping (why, for whom, what, how far, how will we know) saves weeks. Running example: “rebuild the sales force datamart” is not scoping; “reduce delivery time of visit metrics for area managers from 3 days to 4 hours” is.
What this topic measures#
- Axis: from a vague idea to a quantified, revisable portfolio decision.
- Key indicator: share of projects whose objective, scope, success criteria, and decision-maker are written before kickoff, and reviewed at every milestone.
- Unit: percentage of compliant projects, lead time from idea to go decision, number of projects stopped with full awareness.
The five levels#
| Level | Short name | Promise | Typical indicator (orders of magnitude) |
|---|---|---|---|
| 1 | Verbal idea | The project starts when someone asks for it; everyone understands the goal in their own way. | < 20% of projects with a written objective |
| 2 | Written objective | Each project has an identified objective and requester; we can state what it should deliver. | 50 to 70% of projects with a written objective |
| 3 | Validated framework | Sponsor, users, and team sign off on the same vision, the same scope, and the same success criteria before starting. | ≥ 90% of projects scoped; scoping in 1 to 3 weeks |
| 4 | Quantified decision | Go/no-go is based on quantified assumptions, reviewed at each milestone; a project that loses its reason to exist is stopped. | ≥ 1 documented stop or reorientation per year; assumptions reviewed at 100% of milestones |
| 5 | Arbitrated portfolio | The organization funds only projects that beat the best alternative; it knows how to say no quickly and stop early without shame. | Assumed early-stop rate; released budget reinvested |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| PI-CAD-1.1 | A request exists in a traceable form (email, ticket). | Find the original request for 3 recent projects. |
| PI-CAD-1.2 | An identified named requester. | The name appears in the ticket or meeting notes. |
| PI-CAD-1.3 | Initial deliveries can be linked to a request. | Link 3 recent deliveries to a request. |
| PI-CAD-2.1 | A one-page brief: objective, requester, target users, desired deadline. | Open the briefs for 3 active projects. |
| PI-CAD-2.2 | The objective is framed as a user outcome, not as a technical solution. | Review the objective: does it contain an outcome verb, not “migrate to X”? |
| PI-CAD-2.3 | What is out of scope is written down. | “Out of scope” section is not empty. |
| PI-CAD-3.1 | Short vision validated (statement, users, problem, expected benefit) by sponsor and team. | Dated document with traceable approval (email, signature, meeting notes). |
| PI-CAD-3.2 | 3 to 5 measurable success criteria, with baseline and target value. | Each criterion has a unit, an initial state, and a target. |
| PI-CAD-3.3 | Constraints and assumptions are explicit (budget, timeline, dependencies, available data). | Browsable assumptions register. |
| PI-CAD-3.4 | A single decision-maker is named for scoping trade-offs. | Their name appears in the document and in meeting notes. |
| PI-CAD-4.1 | A quantified business case (costs, gains, volume or usage assumptions) comes before go. | Spreadsheet or memo with assumptions and sensitivities. |
| PI-CAD-4.2 | Each major milestone reviews the business case and records a decision: continue, reorient, stop. | Milestone notes with explicit decision. |
| PI-CAD-4.3 | At least one project has been stopped or reoriented based on these reviews. | Record of a stop decision and its rationale. |
| PI-CAD-4.4 | A “lightweight” risk-proportionate scoping approach exists (three-size template). | Three templates used depending on size. |
| PI-CAD-5.1 | Projects are compared against each other using common criteria before funding. | Prioritization grid applied to the whole portfolio. |
| PI-CAD-5.2 | Completed projects are compared against their business case (forecast variance known). | Annual planned vs. actual report. |
| PI-CAD-5.3 | Stopping a project is valued (budget reallocated, no blame). | Examples of stopped projects cited in committee with no sanction. |
| PI-CAD-5.4 | Scoping assumptions improve year over year (calibration). | Planned vs. actual variance on gains decreases over 2 years. |
Detailed reading by level#
Level 1 — Verbal idea. Signs: projects are born in a hallway; two people describe the same project differently. Benefit: responsiveness, no overhead. Does not guarantee: building the right thing. Difficulty to reach: 1/5. Effort: 1/5. Suitable for a disposable prototype.
Level 2 — Written objective. Signs: one page per project, a known requester. You can reject an addition by saying “that is not the objective.” Benefit: end of the most obvious confusion. Does not guarantee: that the objective is measurable, or that users validated it. Difficulty: 2/5. Effort: 1/5.
Level 3 — Validated framework. Signs: at kickoff, the team can recite vision and success criteria; late requests are judged against the vision. Benefit: less rework, stable priorities, useful steering committee. Does not guarantee: that assumptions are correct or that gains are realized (see VAL). Difficulty: 3/5. Effort: 2/5.
Level 4 — Quantified decision. Signs: the business case is a living document; some projects are slowed down or stopped. Benefit: you stop funding what is no longer worth it, which frees real capacity. Does not guarantee: honest numbers (risk of polishing); see pitfalls. Difficulty: 4/5. Effort: 3/5.
Level 5 — Arbitrated portfolio. Signs: portfolio committee compares, abandonments are praised, gain estimates are calibrated. Benefit: best use of overall capacity. Does not guarantee: a sound upstream strategy. Difficulty: 5/5. Effort: 4/5. Rarely achieved outside large organizations; a partial 5 is enough to capture most of the value.
Partial achievement and rating#
Apply the common rule from the README: each milestone is worth 0, 0.5, or 1.
- 0.5: the practice exists but only for large projects, or the document exists but has not been reviewed since kickoff.
- 1: three randomly selected projects show the evidence.
- A partial 5: validated framework everywhere (level 3 achieved), quantified business cases on major projects, one openly accepted project stop during the year; the portfolio committee already compares three or four projects on one grid. Plausible score: 4.3.
Eight-person datamart team: written objectives everywhere (2.1 to 2.3 = 1), validated vision without quantified criteria (3.1 = 1, 3.2 = 0.5, 3.3 = 0.5, 3.4 = 1). Average levels 1–3 = 0.93 > 0.8 with no zero: level 3 achieved. Level 4: 4.1 = 0.5, 4.2 = 0, 4.3 = 0, 4.4 = 0 → average 0.125. Score = 3 + 0.125 × 0.99 ≈ 3.1.
A milestone at 0 blocks the level even with a high average. Symptom: “we have everything but no named decision-maker”; cause: implicit trade-offs; remedy: name the decision-maker, it is free.
Moving to the next level#
Possible means (optional)
- 1 → 2: one-page brief required before any development ticket; reject any project without a requester.
- 2 → 3: two-hour scoping workshop (problem, users, success criteria); vision statement technique; see Project Management Fundamentals and Predictive Methods (Waterfall, V-Model, Spiral, RUP, PMBOK, PRINCE2, Merise, CMMI) for the project charter.
- 3 → 4: standard business case spreadsheet; review at milestones (end of major sprint, phase review); see Choosing and Hybridizing Methods.
- 4 → 5: shared prioritization grid, annual planned-vs.-actual review, culture of letting go.
AI helps structure scoping (rephrase a need, list missing assumptions, generate clarification questions), see AI for Project Management (General, Then Data). It does not replace sponsor validation or accountability for gain estimates; a generated business case that was never challenged is a classic false positive.
Gaming: scoping after the fact to “regularize” (written success criteria already know the result). Control evidence: document date earlier than first development work. Another misuse: polished business case to get funding (Goodhart's law: the grid gets optimized instead of being honest). Remedy: systematically compare planned and actual (PI-CAD-5.2).
In a data project, scoping includes source availability and quality from the start; see Scoping, Value, and Use Cases.
See also#
- Related topics: 04 Scope and Requirements · 07 Stakeholders · 11 Budget, Value, and Benefits · 02 Governance.
- Other matrices: Scoping, Value, and Use Cases (data) · Semantic Model (BI) · Architecture and Design (DL).
- Practice: Project Management Fundamentals · Predictive Methods (Waterfall, V-Model, Spiral, RUP, PMBOK, PRINCE2, Merise, CMMI) · Choosing and Hybridizing Methods · Project Planning and Tracking Tools: Overview · Glossary.
✻ Written by Claude Sonnet 5.5
