Matrix: Project management

How work on the product is run: needs, priorities, planning, expected quality, risks, communication, delivery measurement, continuous improvement.

≈ 11 min readReading

In brief

8 dimensions, levels 0 to 5, 112 criteria.
Tool: run an assessment by choosing “Project management”.
Levels and criteria: original synthesis, references cited at the bottom of the page.

On this page

Overview
Needs and priorities
1. Requirements gathering
2. Backlog and prioritization
Delivery and quality
1. Expected quality and definition of “done”
2. Delivery measurement
Steering and team
Sources and verification

Scope

The running of the work on the product: gathering needs, backlog and priorities, planning and tracking, definition of “done”, risks and dependencies, communication with stakeholders, delivery measurement, lessons learned. Going into production belongs to the “Deployments” theme, the life of the installed product to the “Application maintenance” theme.

8 dimensions, six levels (0 to 5) and 112 observable criteria. To place your product: open the assessment for this theme. The calculation rules are here.

Overview#

Each cell is the level’s signature for the dimension.

Dimension	0 · Handcrafted	1 · Locally tooled	2 · Shared	3 · Industrialized	4 · Integrated and governed	5 · Autonomous
Requirements gathering	Needs expressed by email, in the corridor or in meetings, with no trace.	Requests recorded.	Need formulated.	Structured gathering.	Need and usage brought together.	Need anticipated.
Backlog and prioritization	The work to be done lives in messages and in people’s heads.	Task list.	Single backlog.	Backlog ordered and managed.	Priorities arbitrated.	Priorities driven by value.
Planning and tracking	No planning: things get done when they can.	Deadlines known.	Iterations or milestones.	Realistic plan.	Flow-based management.	Probabilistic forecasting.
Expected quality and definition of “done”	“Done” means “the developer has finished”.	Informal verification.	Written definition.	Standards applied.	Quality verified continuously.	Quality guaranteed by the pipeline.
Risks and dependencies	Risks are discovered as they materialize.	Risks mentioned.	Risks listed.	Risks addressed.	Risks built into the plan.	Risks anticipated.
Communication with stakeholders	Information circulates by chance, through whatever conversations happen.	Occasional information.	Regular communication.	Demos and feedback.	Users involved.	Targeted communication.
Delivery measurement	No measurement: you just have the impression of going fast or slow.	Simple counting.	A few measures.	Four delivery measures.	Measures put to use.	Speed and stability together.
Lessons learned and continuous improvement	Lessons stay in the memory of those who were there.	Informal discussions.	Retrospectives.	Knowledge retained.	Improvement tracked.	Learning organized.

Link with the global model

Dimension of the global model most concerned: Project management and roadmap; also Testing and fixes and Industrialization and deployment. An organization’s maturity matrices are described in the maturity matrices section.

Needs and priorities#

Requirements gathering#

How are users’ needs understood, formulated and validated?

Level	Signature	Criteria to meet
0 · Handcrafted	Needs expressed by email, in the corridor or in meetings, with no trace.	Starting point: no criteria.
1 · Locally tooled	Requests recorded.	Requests are written down and kept. Each request has an identified requester.
2 · Shared	Need formulated.	Each request states the need (why) and not only the solution wanted. Acceptance criteria are written with the requester. A request is checked against what already exists before being accepted.
3 · Industrialized	Structured gathering.	Needs are gathered through workshops or interviews with the users concerned. The needs of the different profiles (users, administrators, clients) are distinguished. Mock-ups or prototypes are validated by users before development.
4 · Integrated and governed	Need and usage brought together.	Usage feedback (usage reports, support requests) feeds the gathering of needs. Reference users take part at regular intervals in the review of needs. A recurring need from one client is studied for all clients.
5 · Autonomous	Need anticipated.	The expected value of each need is estimated before it is developed. The value obtained is checked after delivery and compared with what was expected. Emerging needs are detected by analyzing usage and the market.

Effect on the user

What is built answers a real need, formulated with those who will use it.

Backlog and prioritization#

Is there a single, ordered list of the work to be done, and who decides the order?

Level	Signature	Criteria to meet
0 · Handcrafted	The work to be done lives in messages and in people’s heads.	Starting point: no criteria.
1 · Locally tooled	Task list.	The work to be done is in a list. The list can be consulted by the team.
2 · Shared	Single backlog.	A single backlog brings together needs, enhancements and defects. Each item has a priority and a requester. Items are precise enough to be estimated.
3 · Industrialized	Backlog ordered and managed.	The backlog is ordered according to an explicit rule (value, risk, cost, urgency). A product owner decides the order, after hearing the stakeholders. The backlog is refined regularly: items clarified, split or removed.
4 · Integrated and governed	Priorities arbitrated.	A committee or a ritual arbitrates priority conflicts between clients or between teams. The roadmap links backlog items to a product objective. Abandoned items are removed with an explanation, not left to age.
5 · Autonomous	Priorities driven by value.	The backlog order is based on the measured value of previous deliveries. The share of work devoted to enhancements, fixes and debt is chosen and tracked. The cost of delay of each item is estimated.

Effect on the user

Everyone knows why one thing comes before another, and what is not planned is not promised.

Delivery and quality#

Expected quality and definition of “done”#

What makes it possible to say that a piece of work is done?

Level	Signature	Criteria to meet
0 · Handcrafted	“Done” means “the developer has finished”.	Starting point: no criteria.
1 · Locally tooled	Informal verification.	A piece of work is reviewed or tried by someone else before it is delivered. Defects known at delivery are noted.
2 · Shared	Written definition.	A definition of “done” is written down and known to the team. It includes at least: tests, review, documentation update. Work that does not meet it is not counted as delivered.
3 · Industrialized	Standards applied.	Development and testing standards are written down and enforced through review. The acceptance criteria of each request are verified before delivery. The definition of “done” is reviewed at regular intervals.
4 · Integrated and governed	Quality verified continuously.	Part of the definition of “done” is verified automatically (tests, style checks, code analysis). The expected quality distinguishes the different types of deliverables (jobs, reports, documentation). Defects that escape into production are counted and their causes analyzed.
5 · Autonomous	Quality guaranteed by the pipeline.	A deliverable that does not meet the criteria is automatically rejected by the delivery pipeline. The definition of “done” evolves according to the defects observed. Quality indicators are published with each delivery.

Effect on the user

A finished piece of work is usable, tested, documented and deliverable: not “almost finished”.

Delivery measurement#

Is the team’s ability to deliver quickly and without breakage measured?

Level	Signature	Criteria to meet
0 · Handcrafted	No measurement: you just have the impression of going fast or slow.	Starting point: no criteria.
1 · Locally tooled	Simple counting.	The number of deliveries and their date are noted. Deliveries that caused problems are mentioned.
2 · Shared	A few measures.	The frequency of deliveries is measured. The lead time between the request and the delivery is measured. The number of deliveries that caused an incident is counted.
3 · Industrialized	Four delivery measures.	Lead time for changes, deployment frequency, change failure rate and recovery time are measured. These measures are drawn from the tools (repository, delivery pipeline, incidents), not declared by hand. They are shared with the team.
4 · Integrated and governed	Measures put to use.	The measures are used to choose improvements to the delivery pipeline. The measures are tracked per application or service, not globally. Unplanned rework after a delivery is measured.
5 · Autonomous	Speed and stability together.	Speed and stability measures are tracked together, so as not to improve one at the expense of the other. The measures are compared with external benchmarks. Improvement targets are set and tracked.

Effect on the user

Decisions to improve delivery are based on measurements, not impressions.

Steering and team#

Planning and tracking#

Is the work broken down, planned and tracked, with shared visibility?

Level	Signature	Criteria to meet
0 · Handcrafted	No planning: things get done when they can.	Starting point: no criteria.
1 · Locally tooled	Deadlines known.	Important deadlines are noted. One person keeps track of what is in progress.
2 · Shared	Iterations or milestones.	The work is organized in fixed-length iterations or in milestones. Progress is visible to the team and to stakeholders. Each iteration has a goal.
3 · Industrialized	Realistic plan.	Estimates are based on the team’s observed velocity. Real capacity (leave, support, other tasks) is taken into account. A deviation from the plan is reported as soon as it appears, with a proposed response.
4 · Integrated and governed	Flow-based management.	Work in progress is limited, and blockages are made visible. End-to-end lead times (from request to delivery) are measured. Planning takes into account dependencies with other teams and clients.
5 · Autonomous	Probabilistic forecasting.	Delivery dates are announced with a confidence level based on history. Forecast deviations are analyzed to improve estimates. The plan adjusts regularly without losing the clarity of commitments.

Effect on the user

Announced deliveries arrive, and a deviation is known early, not on the deadline.

Risks and dependencies#

Are risks and dependencies identified, tracked and addressed?

Level	Signature	Criteria to meet
0 · Handcrafted	Risks are discovered as they materialize.	Starting point: no criteria.
1 · Locally tooled	Risks mentioned.	The main risks are discussed at the start of a project. Dependencies on other teams are known.
2 · Shared	Risks listed.	A risk register is kept, with probability, impact and owner. Each dependency has a contact person and a deadline. The register is reread at regular intervals.
3 · Industrialized	Risks addressed.	Each important risk has a decided response (avoid, reduce, accept, transfer). Technical risks (obsolescence, dependence on one person, debt) are included. Late dependencies are escalated according to a known rule.
4 · Integrated and governed	Risks built into the plan.	Risks influence prioritization and planning (margins, preliminary trials). Risks that materialized are analyzed to improve subsequent forecasts. Security and compliance risks are examined with the people responsible.
5 · Autonomous	Risks anticipated.	Measured warning signals (debt, lead times, defects) trigger the risk review. Risks are quantified to arbitrate investments. The risk history of all projects is capitalized and reused.

Effect on the user

Unpleasant surprises are rare, and those that do happen had been foreseen.

Communication with stakeholders#

Are the people concerned by the product informed and involved?

Level	Signature	Criteria to meet
0 · Handcrafted	Information circulates by chance, through whatever conversations happen.	Starting point: no criteria.
1 · Locally tooled	Occasional information.	A progress report is circulated from time to time. Key users are known.
2 · Shared	Regular communication.	Stakeholders are listed with what they expect from the product. Progress is communicated at a fixed rhythm. Changes that affect users are announced before they go live.
3 · Industrialized	Demos and feedback.	Regular demos show finished work to users. Feedback received is recorded and acted on. Release notes are written for users, not only for the team.
4 · Integrated and governed	Users involved.	A group of users or clients is involved in the direction of the product. Major decisions are explained with their reasons. Stakeholder satisfaction is measured at regular intervals.
5 · Autonomous	Targeted communication.	Each profile receives the information that concerns it, through the channel that suits it. Communication is measured (reading, understanding, questions received). Stakeholders have self-service access to progress and to the roadmap.

Effect on the user

Nobody learns by chance what is changing, and important decisions have been shared.

Lessons learned and continuous improvement#

Does the team learn lessons from what it does, and apply them?

Level	Signature	Criteria to meet
0 · Handcrafted	Lessons stay in the memory of those who were there.	Starting point: no criteria.
1 · Locally tooled	Informal discussions.	Difficulties encountered are discussed after a project. Decisions taken are sometimes noted.
2 · Shared	Retrospectives.	A retrospective is held at regular intervals or at the end of a project. Each retrospective produces actions with an owner. Actions decided are reviewed at the next retrospective.
3 · Industrialized	Knowledge retained.	Architecture decisions and their reasons are recorded. Lessons are accessible to the whole team, including newcomers. Onboarding documentation lets a new person contribute quickly.
4 · Integrated and governed	Improvement tracked.	The effect of improvement actions is verified through measurements. Part of the capacity is reserved for improving practices and tools. Lessons are shared across teams.
5 · Autonomous	Learning organized.	Practices that succeed are generalized through a defined process. The team experiments with new practices in a controlled way and evaluates their effect. Improvement capacity is a tracked objective, not leftover time.

Effect on the user

A mistake or a good idea benefits the next team instead of being lost.

Origin of the criteria

The dimensions are inspired by the references cited below; the levels and the criteria are an original synthesis, not a reproduction of a framework. They are offered to be discussed and adapted, not as authority.

Sources and verification#

Scrum Guides — The 2020 Scrum Guide — artifacts (Product Backlog, Sprint Backlog, Increment) and the associated commitments (Product Goal, Sprint Goal, Definition of Done)
DORA — Software delivery performance metrics — five delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate; speed and stability are not in opposition
Microsoft Learn — Operational excellence (Azure Well-Architected Framework) — DevOps culture, development standards, automation
Martin Fowler — Technical Debt — technical debt makes enhancements more costly (the “interest”); pay it down where you change things often