i

Description

A construction site and its cranes

Source

Fons Heijnsbroek · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Maturity Matrix — IT Project Management (PI)

This matrix measures how an IT project is steered: scoped, governed, planned, protected from risk, carried by a team, communicated, delivered, and made profitable.

In brief

• This matrix measures how an IT project is steered: scoped, governed, planned, protected from risk, carried by a team, communicated, delivered, and made profitable.
• It is read across 11 themes and 5 levels; each level is a promise (an observable outcome) supported by verifiable milestones.
• It does not say how to do it (Scrum, predictive, hybrid...): it says what you get. The means are in Project Management and Tools.
• It differs from the three other matrices: here, steering, governance, and the human factor; code engineering is in Software Development, data as an asset in Data Project Management, BI product in BI Development.

On this page

1. Domain promise
2. Audience and usage
3. Scope
4. The 11 themes and their codes
5. Theme × level summary table
6. Rating rule
7. Reading scores
8. Entry Points and Dependencies
9. Typical Organization Profiles
10. Matrix Limitations
11. See Also

Level: 🟢→🔴

Domain promise#

At level 1, this promise is random: everything depends on a few people and luck. At level 5, it becomes a system property: gaps are detected before they become costly, value is measured after delivery rather than assumed, and the organization corrects its own rules. Level 5 is intentionally very difficult to fully reach (see limits).

Audience and usage#

Recommended usage: one self-assessment per project, in a half-day workshop, supported by evidence (see self-assessment and RATING), repeated every 6 to 12 months. The matrix is used to decide where to invest, not to rank people.

Scope#

In scope: end-to-end steering of an IT project or product, from idea to measured benefit; team, decision-making, communication, delivery quality, and value practices.

Out of scope (covered elsewhere, with cross-references):

• internal code quality, automated testing, continuous integration, architecture → Software Development;
• data quality, catalog, data governance, GDPR on data → Data Project Management;
• semantic model, DAX, RLS, Power BI reporting → BI Development;
• project portfolio management, corporate strategy, and public procurement (not covered);
• choosing a specific tool (see overview of planning tools).

The themes “Quality and Acceptance” and “Delivery” cover only the steering point of view (acceptance criteria, production release decision, change management); their technical counterpart is in the DL matrix.

The 11 themes and their codes#

Milestone identifiers follow the pattern PI-<THÈME>-<level>.<n>, for example PI-RSK-3.2: second milestone of level 3 of the risk theme.

Theme × level summary table#

Rating rule#

Common rule for all matrices (quoted identically):

each milestone has progress 0 / 0.5 / 1. A level N is achieved if the average progress of all milestones in levels 1 to 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, adjustable). An integer score of 5.0 is exceptional and may never be reached: that is not a failure.

Practical guidance: assign 1 only with evidence produced during the discussion (document, dashboard, ticket); assign 0.5 when the practice exists but is neither consistent nor verified; increase weighting for themes where the organization takes the most risk (example: RSK ×2 on a regulatory project).

Reading scores#

A high score is not a universal objective. A three-month, two-person project has no reason to target 4 in governance; targeting the sufficient level for risk and size is a sign of maturity.

Entry Points and Dependencies#

Where to start (high gain, moderate effort):

1. CAD: without a goal and success criteria, everything else optimizes the wrong thing.
2. PER: a single prioritized backlog immediately reduces confusion.
3. RSK: a short register, reviewed every week, pays off quickly.
4. PAR: a regular check-in and a status page prevent most surprises.

Dependencies (read as “A before B”):

CAD ─► PER ─► PLA ─► GOU ─► VAL
 │      │              ▲
 │      └──► QUA ─► LIV│
 ├──► PAR ─────────────┘
 └──► RSK ─► GOU
EQU (foundation for everything) ─► AMC (feeds all themes)

• Reliable PLA assumes controlled PER: you cannot plan what changes without a trace.
• LIV at level 4–5 assumes QUA at level 3 at minimum; the technical part is in Continuous Integration and Delivery.
• VAL at level 4 assumes CAD at level 3 (without success criteria, there is no value to measure).
• AMC is a multiplier: without it, no other theme improves sustainably.

Typical Organization Profiles#

Plausible scores by theme, for illustration (contextual assessments, not standards).

These profiles mainly show that strengths are uneven: the regulated organization excels at risk but learns slowly; the vendor ships fast but provides less structure. A useful matrix makes these imbalances visible.

Matrix Limitations#

• It measures observable practices, not project success. A project can succeed with a low score (luck, exceptional team) or fail with a high score (shifting market).
• Goodhart’s law: as soon as a milestone becomes a target, it gets optimized without being achieved. Each theme lists its gaming pitfalls; evaluation through cross-checked evidence (documents and interviews) limits them.
• Numeric thresholds are reference points, not standards: they depend on size, sector, and risk.
• Level 5 is partially theoretical: it is used to show the promise and encourage progress.
• The themes are not independent (see dependencies); an isolated high score on a downstream theme from a weak upstream theme is suspicious.
• Residual subjectivity: two evaluators may differ by half a point on a milestone; this is acceptable if evaluation is always done the same way and compared against oneself over time.
• Volatile data (tools, versions): see content files, status 2026-10.

See Also#

• Other matrices: Software Development · Data Project Management · BI Development · Matrix Index · Self-Assessment with Maturity Matrices.
• Methods that teach practice: Project Management Fundamentals · Scrum Framework · Predictive Methods · Choosing and Hybridizing Methods · Project Management Pitfalls and Best Practices (Cross-Cutting Summary) · AI for Project Management (General, Then Data).
• Tools: Azure DevOps / TFS · Project Metrics and Reporting.
• Reading the rating: RATING · Glossary · Reading Paths.

Next: 01 — Scoping and Vision →

✻ Written by Claude Sonnet 5.5