Measuring Capability Maturity
I often have the need to explain the current maturity of a particular capability, function, or process, in the context of describing the current state versus the desired state and how we get to the desired state. Be it part of a data protection programme, IT incident response process, or something else.
Clearly articulating the current position versus the desired position of a capability is integral to obtaining stakeholder understanding and approval for a desired change.
I’ve found myself using the Capability Maturity Model (CMM) a number of times this year to improve reader understanding of the desired effect in documentation I’m writing.
Capability Maturity Model
The Capability Maturity Model was originally created by Humphrey Watts to describe software capability maturity in the March 1988 issue of IEEE Software. However, it can be used to describe the maturity of any process.
The Model describes 5 levels of maturity, from ad-hoc to optimised. The table below describes each level:
| Maturity level | Dscription |
|---|---|
| Initial (Ad-hoc) |
Actions are conducted on an ad-hoc basis. Actions undocumented and mostly reactionary. Processes are highly dependent on key individuals who know how to act. |
| Repeatable (Developing) |
The basic elements of the process are documented to a sufficient degree to allow repetition of certain actions. Documentation is incomplete or incorrect. |
| Defined | The process is defined as a standardised set of actions, typically aligned to known best practice or standards. |
| Managed (Capable) |
The process utilises agreed metrics to increase the performance of the process over time and reports in a structured manner. Decisions are defined by process. |
| Optimised (Efficient) |
The process is efficiently managed to a degree allowing continual improvement and may act as a competitive advantage. |
Using the Model
Primarily, I use the levels as a conceptual model along side a plan to show how a certain change, or set of changes, provide a benefit to the organisation or programme.
Showing how change A to process B, which is currently in an immature state (e.g., developing), and the expected level is defined, will improve process B to the desired level over X period is an incredibly useful tool.
Typically, shown as a process flow diagram in Word (rather than a table), it aids visual learners and allows readers to more easily absorb the effect of your proposal.
Capabilities mapped against the Model don’t need to neatly fit into a specific level. It is possible to describe your capability as in between two levels. It’s often the case you will describe something as moving between developing and defined, for example, and go on to state what actions need to be completed for the capability to be considered defined.