- Description
- A compass
- Source
- Slashme · original page
- Licence
- CC0 Public domain
Maturity Matrices — Principle, Anatomy, and Comparison
A maturity matrix describes a domain by themes, and each theme by five levels; each level is a promise (an observable outcome, never a means) supported by milestones…
In brief
- A maturity matrix describes a domain by themes, and each theme by five levels; each level is a promise (an observable outcome, never a means) supported by verifiable milestones.
- This section offers four matrices that complement one another without duplicating each other: IT project management (PI), software development (DL), data project management (PD), BI development (BI) — 47 themes in total.
- You will learn how to explain the principle to a junior using the door example, read the anatomy of a theme, apply the common rating rule, choose the right matrix, and use cross-references when two themes overlap.
- The practical method (grid, workshop, calibration, progression plan) is in 05 — Self-Assessment.
On this page
Level: 🟢→🔴
The principle, using the example of a door#
🟢 Novice. Imagine we want to measure an organization's maturity for opening a door. We do not describe how (key, badge, biometrics): we describe what we get, across several independent axes, the themes.
| Theme | Level 1 | Level 3 | Level 5 |
|---|---|---|---|
| Performance | Opening takes less than one hour | Opening takes less than one minute | Opening takes less than one second |
| Noise | Very noisy | Audible in the next room | Silent |
| Locking | None (the door stays open) | Locked | Returned to its initial state after use |
Three takeaways that apply to all matrices in this section:
- Themes are distinct axes. A door can be quiet but slow. We do not average before looking at each axis: the “sawtooth” profile is more informative than the average.
- The promise describes an outcome, not a means. “Less than one second” is a promise; “install a badge reader” is a means. A means can be replaced, the promise remains. This is what makes it possible to use the same matrix for a SQL Server warehouse and for a lakehouse (PD matrix, “The matrix deliberately ignores tooling”).
- By design, level 5 is very difficult to fully achieve. A door that opens in less than a second, without noise, and returns itself to its initial state is a horizon. It is there to show the promise and encourage progress, even if milestones are only partially reached. We examine the substance (practices, artifacts, evidence), never a real interface.
🟡 Practical. Applied to a SQL Server datamart fed by a field sales force automation (SFA) application, the “Delivery” theme becomes: level 1 — “we deliver when it's ready, hoping for the best”; level 3 — “we deliver at a regular pace with rollback planned”; level 5 — “a validated change is in production the same day, without incident.” Same structure, different domain: that is the strength of the method.
The same team can be at 3.4 on “semantic model” and at 1.2 on “testing” in the BI matrix. The average (≈ 2.3) hides the fact that the weak link (testing) limits the reliability of delivered figures: that is what must be addressed first.
Anatomy of a theme: promise and milestones#
🟡 Practical. Every theme page, in all four matrices, follows the same structure: why this theme, what it measures, five-level table, milestones, detailed reading by level, partial achievement, moving to the next level, see also. The two elements that carry the matrix are the promise and the milestones.
| Element | Question it answers | Form | Example (“Testing” theme) |
|---|---|---|---|
| Promise (by level) | What does the beneficiary get? | Present-tense sentence, from the beneficiary's point of view, with a numeric reference point when possible | “A newly introduced defect is detected before merge, in under 15 minutes” |
| Milestone (3 to 5 per level) | How do we verify that the promise is kept? | Precise statement + verifiable evidence | “The full suite runs on every merge” — evidence: 30-day pipeline history |
| Typical indicator | What order of magnitude? | Lead time, rate, frequency | “< 15 min”, “< 5% flaky tests” |
| Possible means (optional) | How can we get there? | Leverage, never mandatory | “Mutation testing, contract testing” |
Milestone identifiers are stable and readable: <MATRIX>-<THEME>-<level>.<n>, for example PI-RSK-3.2 (IT project management matrix, risks theme, level 3, second milestone). The matrix prefix avoids any ambiguity, because several theme codes exist in multiple matrices (TST, PRF, MOD, GOV, QUA, SEC, VAL): DL-TST-3.1 and BI-TST-3.1 are two different milestones.
🔴 Expert. Why separate promise and milestones? Because they do not play the same epistemic role.
- The promise is construct validity: it says what the level means. You can discuss it with a non-technical sponsor.
- The milestones are measurability: they make the promise falsifiable through evidence. Without milestones, the matrix becomes an opinion scale; without a promise, it becomes a meaningless checklist that gets ticked without understanding (Goodhart's law: see Good practices and pitfalls).
- The “3 to 5 milestones per level” rule is a compromise: fewer than three, a single 0 milestone brings down the whole level (see the rating rule); more than five, assessment becomes heavy and the average dilutes each milestone.
Require evidence for each milestone: a document, a dashboard, a ticket, pipeline history, a test recording. An oral statement caps progress at 0.5.
The common rating rule#
The rule is identical across all four matrices; it is quoted here unchanged:
each milestone has a progress value of 0 / 0.5 / 1. A level N is achieved if the average progress of all milestones from levels 1 to N is ≥ 0.8 and no milestone is 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, adjustable). An integer score of 5.0 is exceptional and may never be reached: this is not a failure.
🟡 Practical — reading the rule.
- Only three values (0, 0.5, 1) to prevent false precision: we do not distinguish 0.6 from 0.7, but rather “absent,” “partial or inconsistent,” “observed and consistent.”
- Cumulative: level N assumes lower levels. That is why the average covers all milestones from 1 to N, not only those at level N.
- 0.8 threshold and blocking 0 milestone: the threshold tolerates small gaps (a few 0.5 values), but a missing milestone invalidates the promise (a rollback that was never tested is not a rollback).
- 0.99 factor: it guarantees that a score never equals N+1 unless N+1 is achieved (the partial maximum is N + 0.99).
Theme with 3 levels of 4 milestones each. Level 1: 1, 1, 1, 1. Level 2: 1, 1, 0.5, 1. Level 3: 1, 0, 0.5, 1. Average across levels 1 to 3 = (4 + 3.5 + 2.5) / 12 = 0.833: above 0.8, but one milestone is 0: level 3 is not achieved. Levels 1 and 2: average 7.5 / 8 = 0.94, no zeros: level 2 achieved. Score = 2 + (2.5 / 4) × 0.99 = 2 + 0.619 ≈ 2.6. The full calculation on a fictional team is in self-assessment.
The domain matrices use the tolerant rule above (cumulative average ≥ 0.8, no milestone at 0): it is meant to locate an organization and decide where to act. The product model uses the strict rule: a level is achieved only if all its applicable criteria are “in place”, and the guaranteed level is the minimum across dimensions. The two results are not comparable: a score of 2.6 on a domain theme and a guaranteed level of 2 on a product do not measure the same thing. Pick the rule according to the question: where do we stand? (tolerant) or what can we guarantee? (strict).
See also RATING (other files' /5 ratings: expert assessments, not to be confused with maturity scores) and the Glossary.
The four matrices at a glance#
| PI — IT Project Management | DL — Software Development | PD — Data Project Management | BI — BI Development | |
|---|---|---|---|---|
| Domain | Steering an IT project or product end to end | Code engineering and its delivery | Data as both an asset and a project | The BI product (model, DAX, reporting) |
| Core question | “Are we delivering what is valuable, at the announced cost and pace?” | “Can we change the software quickly, frequently, and without fear?” | “Are the figures useful, accurate, explainable, protected, and sustainable?” | “Does the BI product tell the truth, quickly, to the right person, in their language?” |
| Themes | 11 | 12 | 12 | 12 |
| Main emphasis | Governance, people | Technical, flow | Value, quality, compliance | Semantics, reporting |
| Typical reader | Project manager, sponsor, PMO | Development team, technical lead | Data owner, architect, data manager | BI developer, BI team lead |
| README | PI | DL | PD | BI |
Detailed Comparison#
🟡 In practice. The matrices differ by what they examine, not just by their title.
| Criterion | PI | DL | PD | BI |
|---|---|---|---|---|
| What is assessed | The project, the team, decisions | The code and the delivery pipeline | The dataset as an asset, its sources, its quality | The semantic model, measures, reports |
| Outcome it supports | No bad surprises for the sponsor | Frequent, safe, reversible changes | Trustworthy numbers that survive staff turnover | Accurate, fast, secure, multilingual numbers |
| Typical evidence | Logs, meeting minutes, steering dashboards | Pipeline histories, test reports, logs | Acceptance testing reports, source contracts, dictionary, lineage | Test DAX queries, PBIP/TMDL projects, refresh logs |
| Recurring indicators | Schedule variance, scope creep, value delivered | Deployment frequency, lead time for changes, failure rate | Quality rate, fix lead time, actual usage | Response time, reconciliation gaps, cost per usage |
| Typical level 5 | Portfolio arbitrated, zero surprises | Change → production in less than one day | Continuous reconciliation, active metadata | Continuous deployment, rollback in minutes |
| Typical usage risk | Governance theater (documents without decisions) | Race for delivery metrics without quality | Surface-level compliance, non-living catalog | Industrialized reports but useless |
| Volatile dimension | Method frameworks | DORA classes, SBOM formats | Regulation, data platforms | Fabric, licenses, Copilot (as of 2026-10) |
Choose the matrix based on the question you want to settle, not your profession. A BI developer has as much to gain from the PD matrix (why are the numbers disputed?) as from the BI matrix (why is the report lagging?).
Overlaps and Cross-References#
The four matrices share boundaries. To avoid duplication, each theme page points to the neighboring theme. Here is the map of the main overlaps; the rule is: assess each milestone only once, in the matrix that owns it (the “Owner” column), and use the other as context.
| Topic | Related themes | Owner | What the other matrix does |
|---|---|---|---|
| Delivery / production release | PI — Delivery and Production Release (LIV), DL — Deployment and Operations, DL — Continuous Integration and Delivery, PD — Lead Time and Industrialization (DataOps), BI — Report Versioning and Industrialization | DL for mechanics; PI for the production release decision | PI: criteria and change management; PD: data-specific requirements (replay, idempotence); BI: PBIP/TMDL artifacts |
| Testing and acceptance testing | PI — Quality and Acceptance (QUA), DL — Testing, PD — UAT and Business Validation, BI — Testing and Metrics Reliability | DL (code), PD (business numbers), BI (measures) | PI covers only acceptance criteria and the decision |
| Security | DL — Security, PD — Security, Privacy, and Compliance, BI — RLS Security and Access | DL (pipeline and secrets), PD (personal data), BI (role-based filtering) | Three angles on the same risk, no shared milestone |
| Model / architecture | DL — Architecture and Design, PD — Modeling and Architecture, BI — Semantic Model | PD for the upstream data model; BI for the semantic model; DL for application architecture | The semantic model consumes the datamart model |
| Governance | PI — Governance and Steering (GOU), PD — Data Governance and Organization, BI — Governance, Catalog, and Self-Service | Each on its own object: project decisions (PI), data (PD), models and workspaces (BI) | No overlap in milestones, but shared vocabulary |
| Cost and value | PI — Budget, Value, and Benefits (VAL), PD — Cost and Value Management (Data FinOps), BI — Cost, Licensing, and Capacity | PI for the project; PD for the data product; BI for capacity and licensing | Chain: BI cost feeds data product cost, which feeds project cost |
| Operations | DL — Observability and Reliability, PD — Operations and Support, BI — Operations, Monitoring, and Capacity | DL (application), PD (data incidents), BI (refreshes, capacity) | Three layers of the same monitoring |
| Documentation and metadata | DL — Documentation and Knowledge Transfer, PD — Metadata, Lineage, and Documentation | DL (code), PD (data) | BI relies on PD for lineage |
| Performance | DL — Performance and Scalability, BI — Performance and Data Volume | DL (application), BI (model, queries, refresh) | Same performance budget vocabulary |
| Sources and ingestion | PD — Data Sources and Data Contracts, BI — Data Layer and ETL | PD (source contract); BI (consumption in the model) | A level 3 PD contract makes a level 4 BI ETL easier |
| Adoption and communication | PI — Stakeholders and Communication (PAR), PD — Adoption and Change Management, BI — Visualization and UX | PI (project communication), PD (use of numbers), BI (ergonomics) | — |
| Team and flow | PI — Team and Collaboration (EQU), DL — Developer Experience and Flow, PI — Continuous Improvement and Learning (AMC) | PI for people; DL for technical loops | — |
Symptom: the same defect (for example, “no tested rollback”) is counted three times, in PI, DL, and PD, and artificially drags down the overall score. Cause: the same fact was assessed in multiple matrices instead of just one. Fix: apply the “Owner” column; in the other matrices, mark the milestone as “covered by” and do not count it.
🔴 Expert — dependency chains across matrices. Dependencies do not stop at matrix boundaries. Three chains come up regularly:
Quality of numbers: PD-GOV ─► PD-QUA ─► PD-REC ─► BI-TST ─► BI-IND
Fearless delivery: DL-GIT ─► DL-TST ─► DL-CIC ─► DL-DEP ─► PI-LIV
Controlled cost: BI-OPS ─► BI-CST ─► PD-FIN ─► PI-VAL
Reading: a BI-IND score at level 4 (deployment pipeline) is valuable only if BI-TST is at least level 3; otherwise you automate delivery of unverified numbers. Likewise, PI-LIV at 4 without DL-TST at 3 is surface-level scoring.
Which matrix for which question#
| Your question | Matrix/matrices to open | Entry theme |
|---|---|---|
| “Our projects are slipping on schedule and budget” | PI | Planning and Estimation (PLA), Scope and Requirements Management (PER) |
| “Our deployments are scary” | DL, then PD if it is data-related | Deployment and Operations |
| “Users are disputing our numbers” | PD, then BI | Data Quality, UAT and Business Validation |
| “The report is lagging” | BI | Performance and Data Volume |
| “If one person left, we would be paralyzed” | PI, DL | Team and Collaboration (EQU), Documentation and Knowledge Transfer |
| “We want a common language for the whole team” | All four, one session each | Self-Assessment with Maturity Matrices |
The Themes of Each Matrix#
Three-letter codes (declared in each matrix README). Milestone identifiers add the matrix prefix.
| Matrix | Themes (code) |
|---|---|
| PI | CAD framing · GOU governance · PLA planning · PER scope · RSK risks · EQU team · PAR stakeholders · QUA quality and acceptance testing · LIV delivery · AMC continuous improvement · VAL budget and value |
| DL | ARC architecture · COD code quality · TST testing · GIT versioning and branches · CIC continuous integration and delivery · DEP deployment · SEC security · OBS observability · DTT technical debt · DOC documentation · PRF performance · DXF developer experience |
| PD | VAL value · GOV governance · QUA quality · CTR contracts · MOD model · DOP DataOps · REC acceptance testing · SEC security and compliance · ADO adoption · EXP operations · FIN cost and value · MET metadata |
| BI | MOD semantic model · ETL data layer · PRF performance · VIZ visualization · DAX measures · RLS security · IND industrialization · TST testing · GOV governance · OPS operations · ACC accessibility and multilingual support · CST cost and licenses |
Good Practices and Pitfalls#
Start with a single matrix, on a specific scope (one team, one product). Run the assessment as a team, with evidence, then choose two or three milestones to reach before the next assessment (6 to 12 months). Details in Self-Assessment with Maturity Matrices.
Set a target per theme, proportional to risk and size. A three-month project with two people has no reason to aim for 4 in governance: aiming for the sufficient level is a sign of maturity.
Symptom: the score improves, but incidents do not decrease. Cause: Goodhart’s law — once a milestone becomes a target, it gets optimized without delivering on the promise (for example: test coverage inflated by tests without assertions). Remedy: cross-check evidence (documents and interviews and samples), change the sample at each assessment, never tie the score to an individual evaluation.
Symptom: two teams’ scores are compared to rank them. Cause: different contexts, sizes, and criticality. Remedy: compare a team to itself over time.
Symptom: level 5 is treated as a target to achieve everywhere. Cause: confusion between compass and target. Remedy: level 5 is exceptional by design; a consistent 3 is often an excellent outcome for a team of fewer than ten people.
Look at milestones at 0 before averages: they indicate missing links, which block achievement of a level and often signal a real risk.
Common limits across the four matrices: they measure observable practices, not project success; numeric thresholds are reference points; residual subjectivity is about half a point on a milestone (hence calibration); some external benchmarks evolve (DORA classes, SBOM formats, Fabric features, Power BI licenses) and should be rechecked at the source (status 2026-10).
AI Contribution#
AI can prepare a self-assessment (gather evidence, propose an initial milestone progress level from excerpts, draft the progression plan, compare two assessments) but does not replace it: progress is a shared team judgment, based on evidence that has been reviewed. A language model can also “find” evidence that does not exist. See the governance framework in the Cross-Cutting Overview — AI Contribution and the AI sections of AI for Project Management (General, Then Data), AI in Planning and Version Control Tools, and OneLake + SaaS Mobile Apps: AI Contribution.
| Use case | Benefit /5 | Risk /5 | Maturity /5 | Guardrail |
|---|---|---|---|---|
| Summarize evidence for a theme before the workshop | 4/5 | 2/5 | 4/5 | Verify every cited piece of evidence in the source |
| Suggest progress 0 / 0.5 / 1 per milestone | 3/5 | 4/5 | 3/5 | Progress is always decided by the team; AI does not rate on its own |
| Draft the progression plan from gaps | 4/5 | 2/5 | 4/5 | Review and arbitration by the team lead |
Detect inconsistencies between scores (e.g., LIV high, TST low) |
3/5 | 2/5 | 3/5 | Explicit dependency rules in the instructions |
Expert assessments, context: team of 5 to 10 people, occasional use with review.
See also#
- Matrices: PI · DL · PD · BI · Self-Assessment with Maturity Matrices.
- Methods that teach practices: Project Management Fundamentals · Project Management Methods Comparison · Choosing and Hybridizing Methods · CI/CD: Continuous Integration and Delivery · CI/CD for Data: Databases, Datamarts, Pipelines, and Reports.
- Tools: Version Control Systems Overview · Azure DevOps / TFS · Project Metrics and Reporting.
- Reporting: Cross-Cutting Power BI Best Practices · Power BI Reporting Project Checklists.
- Framework: RATING · Glossary · Reading Paths · Bibliography and Resources.
Next: 05 — Self-Assessment with Maturity Matrices →
✻ Written by Claude Sonnet 5.5
