The request often arrives as one line in a board paper: develop a maturity model for our partners. Someone in the secretariat opens a spreadsheet, types five headings, from Basic to Excellent, and starts filling in cells. Weeks later, at the members' meeting, nobody discusses governance or digital skills. They discuss whether a member is "good" or "very good", and who decided.
The effort is rarely the problem; the order of the decisions is. This guide shows how to build a maturity model for a partner network in eight steps, from its purpose to its first revision, with a free four-page template, a filled-in example for a fictional federation, and the mistakes I would avoid.
What a maturity model is, and where the idea came from
In November 1986, the Software Engineering Institute at Carnegie Mellon University began developing a process maturity framework, in response to a request to give the US federal government a way to assess the capability of its software contractors. By 1993 it had become the Capability Maturity Model for Software, whose five maturity levels, in the SEI's own words, "define an ordinal scale" [1].
The shape has stayed: a sequence of levels describing an anticipated, desired or typical path of development, in discrete stages [2]. Each level says what has to be true to reach it, so an assessment places an organization on the path and shows the next step. By 2005 there were more than 150 maturity models, in fields from IT services to knowledge management [3], yet when Becker, Knackstedt and Pöppelbuß examined 51 of them, only nine documented their design process in detail [2]. What follows is the method from that research, translated for program teams.
How to build a maturity model in eight steps
The steps follow the phases de Bruin, Rosemann, Freeze and Kulkarni proposed for developing any maturity model: scope, design, populate, test, deploy and maintain [3]. Each decision limits the next, and the pilot will send you back to rewrite descriptors at least once.
1. Decide what the model is for
Before any level, write down which decisions the model will inform. The research distinguishes three uses [3][4]: a descriptive model shows where each partner stands today; a prescriptive model also shows what to do next; a comparative model benchmarks partners or regions, which needs many assessments and very stable criteria. Most partner networks need the first two.
On the same page, answer who fills it in (the partner alone, with you, or with your confirmation), how often, and what it will never be used for. In my experience, that last line does more for honest answers than any instruction. If members suspect the model will decide their membership or their grant, they will rate themselves high, and the model will describe a network that does not exist.
2. Choose the dimensions
Dimensions are the themes the model covers: governance, finance, digital skills, safeguarding, youth participation. Keep them few, to limit complexity and keep them independent (de Bruin and colleagues' two models used six and four main components), and make them mutually exclusive and collectively exhaustive [3]: no evidence should count twice, and nothing your purpose needs should be missing. I aim for four to seven, split into two or three sub-dimensions where a theme is broad.
Before writing your own, look at what exists: comparing with existing models is the first requirement Becker and colleagues set for building a new one [2]. For capacity strengthening, the seven elements of McKinsey's 2001 grid for Venture Philanthropy Partners are a solid start [5], and so are the six domains in our partner capacity assessment guide.
3. Pick four or five levels
The CMM uses five levels [1]; the McKinsey grid uses four [5]. The number matters less than the requirement de Bruin and colleagues state: stages that are distinct and well defined, with a logical progression, each with a short label that signals its intent [3].
| Four levels | Five levels | |
|---|---|---|
| Typical labels | Exploring, Building, Embedding, Leading | Initial, Repeatable, Defined, Managed, Optimizing (the CMM's) [1] |
| Fits when | You can evidence four distinct states, from first steps to leading others | You can evidence a difference between doing it well and improving it systematically |
| Watch out for | Two different states squeezed into one level, where partners then stay for years | A top level nobody reaches, and middle levels raters cannot tell apart |
My rule comes from operations research: a level earns its place only if you can describe it with evidence and tell it apart from its neighbors. Count the states you can actually observe in your network, then stop. The count can go up, too: Becker and colleagues started their IT performance model with four stages and, after interviews with IT managers, moved to six, from "non-existent" to "optimized", to separate the weaker cases [2]. And write the bottom level as a starting point, not a verdict: "Exploring" opens a conversation; "Deficient" ends it.
4. Write each level as a state you can observe
This is where most models fail. A descriptor is the text in one cell of the grid. Pöppelbuß and Röglinger count intersubjectively verifiable criteria among the design principles of a useful maturity model: descriptions precise and clear enough to tell one level from the next [4]. In plain words: two people looking at the same partner should pick the same cell.
| Vague descriptor | Observable descriptor | Evidence |
|---|---|---|
| Good data protection | A named data lead; consent and retention rules are written and applied | Data policy, consent form, retention rule |
| Strong digital leadership | The board approved a digital plan with a budget and an owner | Board minutes, budget |
| Adequate reporting | Key indicators are checked by a second person and reported on time | Indicator sheet, the last two reports |
| Engages young people online | Young people co-create content, and reach is measured every quarter | Content calendar, quarterly reach figures |
Three habits help:
- Name something you could see or hold: a document, a routine, a role, a number. Ban "good", "strong", "adequate" and "effective".
- Change one thing per step. If level 3 adds a budget, an owner and a yearly review at once, a partner with two of the three has no home.
- Make levels cumulative. Each stage should include what the stages below it require [3]. A test from my operations research days: try to imagine a partner where level 3 is true and level 2 is not. If you can, the order is wrong, or the cell belongs to another dimension.
5. Define the evidence for each level
For every cell, write what would show it: a policy, minutes, a report, a figure. Keep evidence light at the lower levels and heavier at the top, where the claims are bigger, and name who provides it and who confirms it. Never ask for evidence nobody will read: every document costs a partner time that could go to its work.
6. Validate the model with partners
Show the draft to the people who will live with it. De Bruin and colleagues used the Delphi technique and focus groups to build and check their models [3]; McKinsey tested its grid with nearly a dozen nonprofit executive directors [5]; version 1.1 of the CMM came out of feedback from a workshop on version 1.0 attended by about 200 software professionals [1]. For a partner network, start with a two-hour workshop with eight to ten varied partners. Ask: Do you recognize yourselves? Is this your language? What is missing? Is anything humiliating?
7. Pilot and calibrate
Run the model for real with three to five partners. De Bruin and colleagues insist on testing the instrument for validity and reliability, so that results are accurate and repeatable [3]. The practical version: two people rate the same partner independently, and every disagreement points at a descriptor to rewrite. If every pilot partner sits at level 2, your levels do not discriminate; if nobody can imagine reaching level 4, it is a wish list. A scale that puts everyone in the same box carries no information.
8. Govern changes and reassess
Becker and colleagues note that every maturity model ages as conditions, technology and knowledge move on, and that the changes it needs belong in a new model version [2]. Treat yours like a standard: a version number, one change window a year, a change log with what changed and why, and no edits in the middle of an assessment round. When version 1.1 changes a cell, say how positions from 1.0 carry over, so no partner drops a level because you rewrote a sentence. Then reassess every 6 to 12 months. How to run those rounds, and why you should never average levels into one score, is in our guide to partner capacity assessment.
The partner maturity model template (free download)
The template turns the eight steps into four A4 pages: purpose and scope; dimensions and levels; the descriptor grid, with a descriptor test and calibration notes; and the evidence plan, validation plan and version log.
Download the maturity model builder template (PDF, 4 pages). Print it for a design workshop, or copy the sections.
Ready to turn the grid into a program partners can work on? In Advancer.World your dimensions become topics, your levels stages and each descriptor a cell, with the evidence requests on the steps between levels. Every partner sees where it stands. Free to start.
Example: a federation's Member Digital Maturity Path
Here is the template filled in for Meridian Youth Federation, a fictional federation of 26 national member organizations.
Download the filled-in example (PDF, 4 pages). Four choices are worth copying:
- The purpose excludes something. The model informs who gets peer coaching first and what the digital support fund pays for; it is never used for membership status or rankings.
- Four levels, after trying five. Nobody could evidence a difference between the two middle levels of the first draft, so the fifth level was dropped.
- Six areas under three themes. A member can be Leading in online engagement and Exploring in data protection, and that profile is what the federation needs to see.
- The pilot changed the words. Two raters read "posts regularly" as weekly and as monthly, so level 2 of online engagement became "a content calendar with channels for each audience".
Common mistakes when building a maturity model
- Writing the levels before the purpose. Without a decision to inform, the model drifts into a ranking, and partners treat it as one.
- Mistaking the questionnaire for the model. The SEI met this with its own 1987 maturity questionnaire, which people too often treated as the model itself [1]. The model is the path; a questionnaire is one way to measure it.
- Adjectives instead of observable states. "Adequate" means something different to every rater.
- Too many dimensions. Forty indicators produce a model nobody finishes.
- Designing it for partners instead of with them. A level 1 written as a list of failures teaches partners to hide.
- Changing it mid-round. One edited descriptor makes this round incomparable with the last.
Building your maturity model in Advancer.World
Advancer.World was born from the digital transformation of programs at organizations such as UNICEF and Airbus, and a program in it has the shape of a maturity model: the stages are your levels, the topics and subtopics your dimensions, and each cell holds a descriptor.
The steps between cells carry what a partner needs to move up: document upload requests for the evidence, surveys, initiatives and e-signature requests. You choose per program how partners move: by self-assessment, automatically when the previous step is complete, or only when your team confirms it. Your team can edit the design together in real time. Partners see where they stand and what the next level asks of them, in any of 22 languages, and never see other partners' data. Daily snapshots keep the history, so reports show how the network moved between rounds.
FAQ
How many levels should a maturity model have?
Four or five for most partner networks. What matters is that each level is distinct, well defined and a logical step from the one below [3]. If raters cannot tell two levels apart in the pilot, merge them.
How long does it take to build a maturity model?
Plan for two to three months for a first version: a few weeks for the purpose, dimensions and levels, a few more for descriptors and evidence, then the partner workshop and a pilot. Shortcuts return as a second version nobody budgeted for.
Can we adapt an existing maturity model instead of building one?
Often, yes, and you should look first [2]. Check the license, keep the structure if it fits your purpose, and rewrite the descriptors in your network's language.
Can a partner be at different levels in different dimensions?
Yes, and it usually is; that profile is the most useful output of the model. What a partner should not do is skip levels within one dimension, a point the CMM's authors made about their own levels [1].
Start with the purpose, not the levels
If you take one thing from this guide, make it the order. Write the purpose on one page, agree it with a few partners, and only then open the grid. A model built that way takes longer to start and much less time to defend.
Build your maturity model once, and run it with every partner. Design the grid with your team, invite your partners, and see where each of them stands, round after round. Free to start.
References
- Mark C. Paulk, Bill Curtis, Mary Beth Chrissis and Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, "Capability Maturity Model for Software, Version 1.1" (CMU/SEI-93-TR-024), February 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (accessed October 2026).
- Jörg Becker, Ralf Knackstedt and Jens Pöppelbuß, "Developing Maturity Models for IT Management: A Procedure Model and its Application", Business & Information Systems Engineering, 1(3), 2009, pp. 213-222, https://doi.org/10.1007/s12599-009-0044-5 (accessed October 2026).
- Tonia de Bruin, Michael Rosemann, Ronald Freeze and Uday Kulkarni, "Understanding the Main Phases of Developing a Maturity Assessment Model", 16th Australasian Conference on Information Systems (ACIS), Sydney, 2005, https://aisel.aisnet.org/acis2005/109 (accessed October 2026).
- Jens Pöppelbuß and Maximilian Röglinger, "What Makes a Useful Maturity Model? A Framework of General Design Principles for Maturity Models and its Demonstration in Business Process Management", Proceedings of the 19th European Conference on Information Systems (ECIS 2011), June 2011, https://aisel.aisnet.org/ecis2011/28/ (accessed October 2026).
- McKinsey & Company for Venture Philanthropy Partners, "Effective Capacity Building in Nonprofit Organizations", 2001, https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (accessed October 2026).
© 2026 Mourinho Solutions. All rights reserved.
