Maturity Models

A maturity model is a business tool used to assess people/culture, processes/structures, and objects/technology.

See https://en.wikipedia.org/wiki/Maturity_model

Contents:

Maturity model levels
Maturity model examples
Maturity model process perspectives
Top-down vs. bottom-up
Modeling Maturing Levels
Rebuttals to maturity models
Related assessment metrics
FAQ

Maturity model levels

Maturity model levels are typically a series of steps of sophistication such as:

Level 0: Not Applicable
Level 1: Initiate
Level 2: Develop
Level 3: Standardize
Level 4: Manage
Level 5: Orchestrate

Maturity model levels have a range of terminology in various industries such as:

Level 0: None, Never, Negligible, Not Applicable.
Level 1: Initiate, Investigate, Implicit, Individual-oriented, Informal-usage.
Level 2: Develop, Describe, Duplicate, Direct-oriented, Department-usage.
Level 3: Standardize, Specify, Scale, Service-oriented, Segment-usage
Level 4: Manage, Measure, Mainstream, Mission-oriented, Mass-usage.
Level 5: Orchestrate, Originate, Ongoing, Opportunity-oriented, Outsize-usage

Maturity model examples

We welcome examples of maturity models. If you know of a maturity model, please let us know by by creating a GitHub issue and/or a pull request.

General maturity models:

Topic maturity models:

Agile
- Agile Compass for maturity in agile teams
- Agile Fluency
- Agile DevOps Maturity Model by Hewlett Packard Enterprise (HPE)
- Agile Maturity Model (AMM) by ThoughtWorks (TW)
- Agile Team Maturity Model by Prowareness
Capability
- Capability Maturity Model Integration (CMMI) for Development by Carnegie Mellon Software Engineering Institute (SEI)
- Capability Maturity Model Integration (CMMI) for Acquisition by Carnegie Mellon Software Engineering Institute (SEI)
Continous Improvement
- Continuous Improvement Meetings Maturity Model
Continuous Delivery
- Continuous Delivery Maturity Model by Xebia
Data Center
- Data Center Automation Maturity Model by Xebia
Enterprise Architecture
- Enterprise Architecture: TOGAF Maturity Model
- Enterprise Architecture Maturity Model based on CMMI CM SEI
EIM : Enterprise Information Management
- EIM Maturity Model by Gartner
Green Software
- Green Software Maturity Matrix
IAM: Identity and Access Management
- IAM Program Maturity Model by Gartner
Infrastructure as Code (IaC)
- Infrastructure as Code maturity model by Joel Parker Henderson
- Infrastructure as Code maturity model by Stafford
IT: Information Technology
- IT Capability Maturity Framework by the Innovation Value Institute (IVI)
- Technical Leadership Career Ladder by Poss
Management
- Program and Portfolio Management Maturity Model by Gartner
- Project Portfolio Management Maturity Levels by Priority Systems
- Portfolio, Programme & Project Management Maturity Model (P3M3) by OGC
Open Source
- OpenSource Maturity Model
Product
- Kwan’s Hierarchy of Product Needs
PS: Professional Services
- PS maturity scorecard by SPI Research
Skills
- Programmer competency matrix
- Skills maturity model by Prowareness
Six Sigma
- Lean Six Sigma Maturity Model
- The Six Sigma Maturity Model™
Social Media
- Social Media Maturity Model
Software Documenation
- README Maturity Model
Team
- Team Capability Maturity Model by novumAVI
- Team Performance Maturity Model
Vendors
- Apache Project Maturity Model

Maturity model process perspectives

P3M3® describes process perspectives. These can be assessed at all maturity model levels.

Control Management: how well the organization maintains control of the initiatives currently ‘in flight’.
Benefits Management: how well the organization defines, tracks and ensures achievement of performance improvement from the investment.
Financial Management: how well the organization manages and controls the investment through business cases and budgetary control.
Stakeholder Management: how well the initiatives engage with and communicate with the external environment to minimize the negative implications engagement can achieve.
Organizational Governance: how well the organization controls the initiation and alignment of its investments with the corporate strategy.
Risk Management: how well the organization focuses on and mitigates the impact of threats and the leveraging of opportunities.
Resource Management: how well the organization develops its own talent and utilizes the opportunities from the supply chain to overcome peaks and troughs.

Top-down vs. bottom-up

Two approaches for designing maturity models exist:

Top-down approach: a fixed number of maturity stages or levels is specified first, then corroborated with characteristics (typically in form of specific assessment items) that support the initial assumptions about how maturity evolves.
Bottom-up approach: distinct characteristics or assessment items are determined first, then clustered in a second step into maturity levels to induce a more general view of the different steps of maturity evolution.

Modeling Maturing Levels

Modeling Maturity Levels is a classification system defined by Anneke Kleppe and Jos Warmer in their book MDA Explained Addison-Wesley. The levels characterize the role of modeling in a software project. The concept shows resemblance to the way software processes are rated with the Capability Maturity Model.

See:

There are 6 levels:

Level 0: No Specification: the specification of software is not written down. It is kept in the minds of the developers
Level 1: Textual Specification: the software is specified by a natural language text (be it English or Chinese or something else), written down in one or more documents
Level 2: Text with Models: a textual specification is enhanced with several models to show some of the main structures of the system
Level 3: Models with Text: the specification of software is written down in one or more models. In addition to these models, natural language text is used to explain details, the background, and the motivation of the models, but the core of the specifications lies in the models.
Level 4: Precise Models: the specification of the software is written down in one or more models. Natural language can still be used to explain the background and motivation of the models, but it takes on the same role as comments in source code.
Level 5: Models only: the models are precise and detailed enough to allow complete code generation. The code generators at this level have become as trustworthy as compilers, therefore no developer needs to even look at the generated code.

Rebuttals to maturity models

Related assessment metrics

FAQ

Can I create a maturity model?

Yes. Anyone can create a maturity model. For example, many organizations create their own maturity models, sometimes based on public maturity models, sometimes making use of internal confidential information, sometimes in consultation with experts and advisors. and so forth. This repository links to many maturity models that are created by many people and many organizations.

Who decides what goes into a maturity model?

The team that creates the maturity model decides what goes into it. For creating your own maturity models, we suggest using a "decision record" that can help your team research what you want to go in, and document your choices, in order to help other people understand and leverage your work.

Is a maturity model a snapshot in time or a future plan?

Snapshot. Good teams will leverage the snapshot in order to create future plans, such as plans to work toward a higher maturity model level.

Is a maturity model descriptive or prescriptive?

Descriptive. A maturity model describes the levels and their items, and does not prescribe how a team moves from one level to the next, or acquires items. In rare cases, a specific maturity model may provide adjuct advice, yet this is inherent to the maturity model.

Can a maturity model evolve over time?

Yes. As an organization evolves, each of its maturity models can evolve. For example, some organizations like to look ove each of their maturity models, each year, to ensure that each maturity model is still useful, and also to update each model as desired, based n the organization's goals and capabilities.

Does a maturity model have an end state?

Yes. Then end state of a maturity model is when it is no longer useful to a team. For example, this can happen when a team decides that its current capabilties are fine as is, or when a team outgrows a maturity model by acheiving its highest level then wanting to improve even more.

Is a maturity model different than a scientific model?

Yes. A maturity model is intended to be a quick easy summary in order to help a team communicate about its current capabilties, and plan for future capabilties. The word "model" has the meaning "a small thing that represents another thing, that is often larger, or more complex, or more abstract." For comparison a "scientific model" is intended to explain and predict the behaviour of a real object or system, such as a visualization model that can contextualize a scientific object, or a predictive model that can foreccast a scientific system.

Is a maturity models verifiable?

Yes. A maturity model can describe its levels and items in terms of qualitative metrics and/or quantitative metrics. For example, a programmer can describe Level 1 "Initiate" in terms of "Write a program that prints Hello World", up to Level 5 "Orchestrate" in terms of "Run a worldwide distributed system in concert with our key partners".

appleboy/maturity-models

ErrorLooks like something went wrong!

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Error
Looks like something went wrong!

Packages