Minimal IT - Process maturity and value

28 July 2009

Process maturity and value

Process maturity models must be supported by a simple view of how value is delivered.

The Capability Maturity Model (CMM) is the best-known process maturity model. It was initially developed to evaluate software providers for US government contracts.

The CMM defines five levels of maturity:

Level 1 - initial - no defined processes
Level 2 - repeatable - the organisation generally produces repeatable results
Level 3 - defined - the organisation has defined standard processes
Level 4 - managed - the organisation uses metrics to manage processes
Level 5 - optimized - the organisation optimises and improves processes

In theory, organisations working at higher maturity levels are more efficient and have fewer risks.

CMM was initially targeted at software development. Now there are maturity models for nearly every specialism in IT, such as project management, people management, service delivery, information security, enterprise architecture, and so forth.

Process maturity models are useful for activities that have clear objectives and which are repeatable, such as programming to specification, or day-to-day service delivery. However, process maturity models have many limitations:

Process maturity models focus on how things should be done, not what should be done. The focus on how, not what, is less useful when objectives are not clear.
Process maturity models use institutionalised knowledge. Many situations need innovation and personal experience, not just institutionalised knowledge.
Defined processes can lead to inappropriate solutions. For example, organisations with defined processes for software development tend to see software development and the solution to every problem.
Defined processes underplay the softer side of management. Success depends more on getting close to the business customer than it does on efficiently churning out code.

Processes try to deal with these limitations. There are processes for gathering requirements, designing solutions, and communicating with stakeholders. But the very fact that these are presented within a process framework makes them subservient to the framework, as if they were just part of the bureaucracy involved in getting on with the real work of programming, or whatever.

I am not against process maturity models, but they are just a tool for delivering value. If you can not see the connection between your processes and value delivery, you can not deliver value.

One way of making the connection is to start with a simple, generic view of how value is delivered. Something like:

Describe simply what are you trying to achieve.
Understanding what you really must do to achieve this. This is not "list all the tasks that you can think of putting on a project plan", but is about the mechanisms that must engage to deliver value.
Break down the required work into manageable chunks.
Execute the work as proficiently and efficiently as possible.

If you can see how your processes achieve this, albeit in a better defined and more formal way, then there is a good chance your processes will deliver value.

But if your processes are obsessed with formalities and obscure the underlying value mechanism, then the processes, however well-defined and mature they may be, can not deliver value.