Scoping, Value, and Use Cases

A data project is rarely expensive to build and almost always expensive to maintain: every delivered report becomes a promise of maintenance, refreshes, and support. Delivering “…

Guide≈ 8 min readCheckedReading

On this page

Why this theme
What the theme measures
The five levels
Milestones by level
Detailed reading by level
Partial achievement and rating
Moving to the next level
See also

Level: 🟢→🔴 · Theme code: VAL

Why this theme#

A data project is rarely expensive to build and almost always expensive to maintain: every delivered report becomes a promise of maintenance, refreshes, and support. Delivering “the requested report” without identifying the decision it informs creates the dashboard graveyard syndrome: dozens of pages, a few used, none tied to a gain. The cost of ignoring this does not show up at delivery, but two years later, when the team can no longer stop anything or prioritize anything. This theme focuses on need quality and proof of benefit, before and after development. Generic scoping management is covered in the PI matrix, scoping and vision; here, we cover what data changes: an indicator need is often fuzzy, and its value depends on usage, not delivery.

What the theme measures#

Axis: from “delivering reports” to “arbitrating a portfolio of data products based on their value.”
Key indicator: share of data products tied to a named decision, with a measured benefit after delivery.
Unit: percentage of portfolio products that have (a) a decision-maker, (b) a success criterion, (c) a usage or impact measure.

The five levels#

Level	Short name	Promise	Typical indicator (orders of magnitude)
1	Order	The requester gets the reports they described, without anyone knowing what they are used for.	< 20% of products linked to a decision
2	Question	Each deliverable answers a written business question asked by an identified requester.	≥ 60% of requests with question and requester
3	Hypothesis	The sponsor knows what benefit is expected, how it will be recognized, and what is out of scope.	≥ 80% of projects with signed success criterion
4	Benefit	Benefit is measured after delivery, and gaps from the hypothesis inform subsequent decisions.	≥ 70% of products reviewed at 3–6 months for usage and impact
5	Portfolio	The organization arbitrates, funds, and retires its data products based on demonstrated value.	Documented annual retirements; > 90% of portfolio assessed

Milestones by level#

ID	Milestone	Verifiable evidence
PD-VAL-1.1	Data requests come into a single place (backlog, tickets).	A backlog exists; requests from the past three months can be found there.
PD-VAL-1.2	A named requester exists for each delivered report.	“Requester” field completed for ≥ 80% of delivered items.
PD-VAL-1.3	Delivery is tracked (date, version, recipients).	Browsable delivery history.
PD-VAL-1.4	The scope of each delivery is written, even briefly.	Description or release note for each version.
PD-VAL-2.1	Each request is reframed as a business question (“which SKUs are losing shelf space?”).	Backlog item with “question” field; reframing reviewed with the requester.
PD-VAL-2.2	The relevant decision-maker (the one who acts on the number) is distinct from the requester and named.	Scoping sheet with “who decides what.”
PD-VAL-2.3	Indicators are defined before development (formula, scope, granularity, frequency).	Validated indicator sheet before the first line of code.
PD-VAL-2.4	The need is checked against existing products before creating new ones (reuse).	Evidence of duplicate search in the scoping sheet.
PD-VAL-3.1	Each project carries a value hypothesis (“if we know X at D+1, we reduce Y by Z”).	Written hypothesis validated by the sponsor.
PD-VAL-3.2	A measurable success criterion is signed (usage, lead time, gap, avoided cost).	Criterion present in the charter, with measurement method.
PD-VAL-3.3	Available data is checked before commitment (feasibility: sources, quality, history).	Dated feasibility note or proof of concept, with quality findings.
PD-VAL-3.4	“Out of scope” and GDPR impact are explicitly documented.	“Out of scope” section; reference to the SEC theme analysis.
PD-VAL-4.1	A 3–6 month post-delivery review compares the hypothesis to observed results.	Value review report per product.
PD-VAL-4.2	Actual usage is measured (views, distinct users, queries).	Usage dashboard fed automatically.
PD-VAL-4.3	Products with no usage are flagged and handled (justified retention or retirement).	List of products < usage threshold, with decision.
PD-VAL-4.4	Value gaps modify the next backlog.	Backlog items resulting from a value review.
PD-VAL-5.1	A single portfolio classifies products by value and cost (see FIN).	Portfolio view reviewed at least twice a year.
PD-VAL-5.2	Products are retired each year, with archiving and advance notice.	Retirement log with date, reason, notified recipients.
PD-VAL-5.3	Use cases are assessed on common criteria (value, feasibility, risk, cost) before any funding.	Assessment grid applied to all new requests.
PD-VAL-5.4	Benefits are recognized by finance leadership or the business, not self-declared by the data team.	Written validation from a business third party on at least three products.

Detailed reading by level#

🟢 Level 1 — Order#

Observable signs: the request is an email (“can you pull sales by customer for me?”); the same report is requested again in three formats; no one knows who opens it.
What you gain: apparent responsiveness, service relationship.
What it does not guarantee: that the number is used; that two requesters mean the same thing by “sales.”
Difficulty: 1/5 · Effort: 1/5.

🟢 Level 2 — Question#

Signs: each backlog item has a plain-language question; the decision-maker is identified; the indicator sheet comes before code.
What you gain: fewer acceptance testing loops (“this is not what I wanted”) and fewer duplicates.
Does not guarantee: that the number truly changes a decision; a question can be legitimate and have no impact.
Difficulty: 2/5 · Effort: 2/5.

🟡 Level 3 — Hypothesis#

Signs: the charter includes a quantified hypothesis, even rough; data feasibility is checked before commitment; the sponsor can say no to scope extension.
What you gain: avoids projects that are “great on paper, impossible with the data”; success becomes debatable.
Does not guarantee: that the hypothesis will hold true; that the promised measurement will be done.
Difficulty: 3/5 · Effort: 3/5.

🧪 Example

On a datamart fed by a field sales application, the request “a report on shelf-space audits by retail chain” becomes: “the category manager wants to know, every Monday, which chains lost more than 2 shelf-share points so they can negotiate before month-end.” The value hypothesis: one targeted negotiation per week. Success criterion: report viewed by the 12 managers within 3 months, and at least 3 negotiations citing the number. Feasibility reveals that 30% of audits have no chain: without that finding before commitment, the project would have “succeeded” technically and failed in usage.

🟡 Level 4 — Benefit#

Signs: a 3–6 month review exists; usage is measured effortlessly (view logs); some products are put on probation.
What you gain: proof that data is being used; a factual argument during budget arbitration.
Does not guarantee: causal attribution (high usage is not an effect); quality of viewed numbers.
Difficulty: 4/5 · Effort: 3/5.

🔴 Level 5 — Portfolio#

Signs: a committee arbitrates; products are retired without drama; the business co-funds; declared value is co-signed.
What you gain: controlled product debt; resources redeployed to what matters.
Does not guarantee: accuracy of value calculation, often fragile; the risk is replacing judgment with a score.
Difficulty: 5/5 · Effort: 4/5.

Partial achievement and rating#

Each milestone is rated 0 / 0.5 / 1 according to the common rule in the README. In practice: assess using a sample of five recent products, not based on “what the team generally does.” A milestone is worth 1 if all five satisfy it, 0.5 if two to four do, otherwise 0.

A “partial 5”: a portfolio where the 20 most expensive products are assessed on value (PD-VAL-5.1), where two products were retired last year (5.2), but where benefits are still self-declared (5.4 at 0.5) and the common grid is not yet applied to small requests (5.3 at 0.5). Plausible score: 4.0 + 0.75 × 0.99 ≈ 4.7 if levels 1–4 are achieved.

⚠️ Pitfall

Milestone PD-VAL-4.2 (measured usage) can drift into “number of views”: usage is inflated by sending the link to everyone. Symptom: high usage, unchanged decisions. Fix: measure recurring distinct users and cross-check with cited decisions.

Moving to the next level#

Possible means (optional) — these are levers, not requirements; the promise alone defines the level.

Transition	Possible levers
1 → 2	A request template (“As a… I want to know… to decide…”) ; reject any request without a question and a decision-maker.
2 → 3	A one-hour scoping workshop; feasibility check through a profiling query on the source before estimation (see QUA).
3 → 4	Log views from day one; schedule the value review when the charter is signed.
4 → 5	A semiannual portfolio committee; an expiration rule (a product not viewed for 6 months is archived unless justified).

Cross-cutting pitfalls: (1) False positive — a mechanically filled charter (“gain: improved decision-making”); require a number, even approximate. (2) Goodhart — targeting a “number of evaluated products” pushes teams to evaluate unimportant products. (3) Invisible value — some products prevent risk (compliance): their value is avoided cost, to be documented as such.

🤖 AI

AI helps reframe a fuzzy request into a business question, suggest success criteria, and summarize a usage log. It does not know the actual decision or the sponsor's risk tolerance: any proposed quantified value is a hypothesis to be validated. Do not give it excerpts of customer data.