- Description
- Murs de casiers numérotés en bois dans un couloir : une grille où chaque case a sa place
- Source
- Stacalusa · original page
- Licence
- CC0 Public domain
Maturity Matrix — Data Project Management (PD)
This matrix measures the maturity with which an organization manages its data projects and data products: from the idea of an indicator to the number a decision-maker uses, including…
In Brief
This matrix measures the maturity with which an organization manages its data projects and data products: from the idea of an indicator to the number a decision-maker uses, including sources, quality, acceptance testing, security, adoption, and cost. It focuses on substance (what is achieved), never on a tool or interface. It includes 12 themes, 5 levels per theme, and 4 verifiable milestones per level. After reading, you'll know how to position your team, choose where to start, and avoid confusing “having a tool” with “having a result.”
Level: 🟢→🔴
Domain promise#
Every published number is useful (it answers an identified decision), accurate (it is acceptance-tested and any variance is explained), explainable (you can trace it back to its source in minutes), protected (it exposes only what should be exposed), and sustainable (it survives staff turnover, source changes, and version upgrades).
A data project differs from a software project in one way: the deliverable is an asset that lives on after the project, and its accuracy depends on systems the team does not control (sources, field data entry, business definitions). The PD matrix therefore treats data as both a product and an asset base, with owners, contracts, measured quality, and a cost trajectory.
Audience and usage#
- Data project managers, architects, BI/datamart developers: assess the real state of a project or data product.
- Business leads and data owners: understand what they can require from the technical team, and what they owe in return.
- Managers: prioritize an improvement plan over 6 to 18 months, without aiming for level 5 everywhere.
Recommended use: a team-based self-assessment by theme, using the evidence in the “Verifiable evidence” column (self-assessment). Start with 90 minutes, score broadly, then refine theme by theme.
Scope#
| In scope | Out of scope (covered elsewhere) |
|---|---|
| Value, governance, quality, contracts, model, DataOps, acceptance testing, compliance, adoption, operations, cost, metadata | Generic project management (schedule, risks, budget): Maturity Matrix — IT Project Management (PI) |
| The data lifecycle as an asset | Code and delivery engineering: Maturity Matrix — Software Development (DL Code) |
| Requirements applied to the model and reports | Semantic model, DAX, RLS, UX: Maturity Matrix — BI Tool/Application Development |
| Data project management decisions | Detailed architecture of Power BI reporting: Power BI Reporting — OneLake and Managed SQL Server |
When two themes overlap, each page links to the other and avoids duplication (e.g., report-side testing in BI, number-side acceptance testing in PD).
The 12 themes and their codes#
Milestone identifiers use the format PD-<THEME>-<level>.<n> (e.g., PD-QUA-3.2).
| No. | Code | Theme | In one sentence |
|---|---|---|---|
| 01 | VAL | Scoping, Value, and Use Cases | Each data product addresses a named decision and is evaluated based on measured benefit. |
| 02 | GOV | Data Governance and Organization | Each data element has an owner, arbitrated definitions, and enforceable rules. |
| 03 | QUA | Data Quality | Quality is measured by dimension, committed through thresholds, and corrected at the source. |
| 04 | CTR | Data Sources and Data Contracts | Source changes are announced, versioned, and no longer break consumers. |
| 05 | MOD | Modeling and Architecture | The data model reflects the business, absorbs change, and remains explainable. |
| 06 | DOP | Lead Time and Industrialization (DataOps) | A data change reaches production quickly, in a repeatable and reversible way. |
| 07 | REC | UAT and Business Validation | Numbers are validated against an independent reference, with explained and signed-off variances. |
| 08 | SEC | Security, Privacy, and Compliance | Personal and sensitive data is identified, minimized, protected, and erasable. |
| 09 | ADO | Adoption and Change Management | Users actually rely on the numbers, and their decisions demonstrate it. |
| 10 | EXP | Operations and Support | Data incidents are detected before users notice and resolved within a committed timeframe. |
| 11 | FIN | Cost and Value Management (Data FinOps) | The cost of each data product is known, attributed, and compared with its value. |
| 12 | MET | Metadata, Lineage, and Documentation | Every number is traceable to its source, and every object is understandable without its author. |
Theme × level summary#
Condensed promise for each cell; details (and thresholds) are on each theme page.
| Theme | 1 — Initial | 2 — Repeatable | 3 — Defined | 4 — Controlled | 5 — Optimized |
|---|---|---|---|---|---|
| VAL Value | The request is a list of reports | One business question per deliverable | Value hypothesis and success criterion | Benefit measured after delivery | Portfolio arbitrated, products retired |
| GOV Governance | Everyone has their own definition | Owners known for key data | Arbitrated glossary, active committee | Rules enforced and audited | Fluid governance, close to domains |
| QUA Quality | Errors discovered by users | Basic checks on every load | Dimensions, thresholds, and data SLAs | Quality managed, root causes fixed at the source | Predictive quality, zero quality debt |
| CTR Contracts | The source changes without warning | Contacts and schedule are known | Written contract per source | Contract tested, changes versioned | Contracts managed by producers |
| MOD Model | Ad hoc model, per report | Documented shared model | Domain-based modeling and conventions | Model absorbs change and history | Evolvable model without disruption |
| DOP DataOps | Manual delivery, in days | Repeatable scripts and kits | Versioned pipeline with tests | Safe continuous delivery, rollback | On-demand deployment, measured with DORA |
| REC Acceptance testing | “Looks good to me” | Manual acceptance testing on samples | Acceptance plan using reference numbers | Automated acceptance testing and non-regression | Continuous reconciliation in production |
| SEC Security/GDPR | Personal data ignored | Inventory of sensitive data | Register, minimization, rights | Protection proven, erasure tested | Privacy by design, audited |
| ADO Adoption | Report delivered, silence | Training at delivery | Change plan and champions | Usage measured and corrected | Data-driven decision culture |
| EXP Operations | Firefighting on demand | Basic monitoring, email support | Categorized incidents, target timeframes | Data SLAs met, proactive alerting | Self-healing, problems eliminated |
| FIN Cost/value | Unknown cost | Estimated total cost | Cost per data product | Unit cost managed and optimized | Continuous value/cost arbitration |
| MET Metadata | Knowledge in the author's head | Partial manual documentation | Reference dictionary and lineage | Lineage extracted automatically | Active metadata driving the platform |
Rating rule#
Each milestone has progress 0 / 0.5 / 1. A level N is achieved if the average progress of all milestones from levels 1 through N is ≥ 0.8 and no milestone is at 0. Theme score = N_achieved + average progress of milestones at level N_achieved+1 × 0.99 (e.g., 2.4). Matrix score = weighted average of themes (default weight 1, customizable). A whole score of 5.0 is exceptional and may never be reached: that is not a failure.
See also the Rating: How to Read Scores, Ratings, and Legend and Self-Assessment with Maturity Matrices.
How to read scores#
| Range | What it describes | Useful stance |
|---|---|---|
| 0–1 | Numbers exist, but reliability depends on individuals | Secure the essentials: owners, basic checks, minimum acceptance testing |
| 1–2 | Local practices work, but are not transferable | Write it down, repeat it, make it reproducible |
| 2–3 | Standards exist and are applied by part of the teams | Generalize and verify with evidence, not declarations |
| 3–4 | Practices are measured, gaps are visible and handled | Manage by indicators, fix causes at the source |
| 4–5 | The system improves and adapts almost on its own | Only target themes where the value gap justifies it |
An average score of 3 is already excellent for a team of fewer than ten people. These ranges describe; they do not judge.
Where to start and dependencies#
Entry points (best effort/gain ratio in most contexts): QUA, REC, and GOV. A team that cannot say whether its numbers are accurate (REC), measure their defects (QUA), or define who arbitrates a definition (GOV), will gain nothing from the other themes.
VAL ──► GOV ──► MET
│ │ ▲
│ ▼ │
│ CTR ──► MOD ──► DOP ──► EXP ──► FIN
│ │ │ │ │
│ ▼ ▼ ▼ ▼
└─────► QUA ──► REC ──► ADO SEC (cross-cutting)
- GOV before QUA: without an owner, an anomaly has no recipient (GOV, QUA).
- CTR before DOP: you cannot deliver quickly on sources that change without notice.
- QUA and REC before DOP level 4: continuous delivery without automated checks accelerates errors.
- MET and SEC are cross-cutting: raise them from level 2 onward across all other themes.
- VAL determines FIN: cost only makes sense relative to benefit.
Typical organization profiles#
Plausible scores (0–5 scale), provided as orders-of-magnitude benchmarks.
| Profile | VAL | GOV | QUA | CTR | MOD | DOP | REC | SEC | ADO | EXP | FIN | MET | Average |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Small BI team, isolated hero (2–3 people) | 1,5 | 1,0 | 1,8 | 1,0 | 2,5 | 2,0 | 2,0 | 1,5 | 1,5 | 1,5 | 0,5 | 1,0 | ~1,5 |
| Tooled datamart team, versioned kits (5–8 people) | 2,0 | 2,0 | 2,5 | 2,0 | 3,2 | 3,0 | 2,8 | 2,5 | 2,0 | 2,3 | 1,0 | 2,2 | ~2,3 |
| Enterprise data platform, formal governance | 3,0 | 3,5 | 3,2 | 3,0 | 3,5 | 3,5 | 3,0 | 3,5 | 2,8 | 3,2 | 2,5 | 3,3 | ~3,2 |
| Mature “data product” organization | 4,0 | 3,8 | 4,0 | 4,2 | 3,8 | 4,2 | 3,8 | 4,0 | 3,5 | 4,0 | 3,5 | 4,0 | ~3,9 |
Set a target by theme, not a global target. A five-person team has no reason to aim for level 4 in FIN if its monthly cost fits on one line.
Matrix limitations#
- Ratings are expert assessments, contextual by nature; two honest teams will get similar, not identical, scores.
- Numeric thresholds (lead times, rates) are benchmarks; adapt them to criticality (a regulatory number does not have the tolerance of an internal dashboard).
- The matrix deliberately ignores tooling: a SQL Server warehouse and a lakehouse platform are judged against the same promises.
- Goodhart's law: a milestone that becomes a target stops being a good indicator. Each theme page points out likely misuses.
- It says nothing about culture or people beyond what can be observed in practices; see the PI matrix.
See also#
- Other matrices: Maturity Matrix — IT Project Management (PI) · Maturity Matrix — Software Development (DL Code) · Maturity Matrix — BI Tool/Application Development · Self-Assessment with Maturity Matrices
- Methods: Methods Specific to Data Projects · CI/CD for Data: Databases, Datamarts, Pipelines, and Reports · Scrum Applied to Data, BI, and Datamarts · Project Management Pitfalls and Best Practices (Cross-Cutting Summary)
- Tools: VCS and SQL/BI Data · Project Metrics and Reporting
- Reporting: Power BI Reporting Project Checklists · Cross-Cutting Power BI Best Practices
- Glossary · Rating
✻ Written by Claude Sonnet 5.5
