Capable, mature or both?

The idea of capability maturity models originated in the mid to late eighties when the US Air Force wanted a means of evaluating potential sub-contractors.

In principle, it sounds like a great idea. If I want to benchmark one potential supplier against another, all I have to do is look at their respective levels of capability maturity. The one with the higher level of maturity should, in theory, be a better quality, lower risk alternative.

In fact it is a great idea but as with all great ideas the success is in the implementation, not the theory.

The decades following the publication of the first Capability Maturity Model (CMM) by Carnegie-Mellon University in 1988, saw an explosion in the publication of similar models and levels of interest in the idea.

In project management, a Google search for project management maturity model in April 2005 gave 6,850 results. In February 2014 the same search rendered 85,000 results.

Despite this expansion of the idea, the implementation hasnt followed in a systematic way (at least not in the UK). You dont see companies trumpeting their maturity as a means of demonstrating how good they are at delivering projects and clients rarely make a contractors maturity level a condition of tendering for a project.

Diagram: a CMMI development model showing goals, processes and functions across five levels of capability maturity.

Meanwhile, extensive surveys from the likes of PricewaterhouseCoopers1 (PwC) report that Higher maturity yields higher performance and Organisation maturity is directly correlated with organisational success.

According to PwCs findings we should be actively encouraging organisations to develop their maturity against a capability maturity model.

But the diversity of organisations that deliver projects, programmes and portfolios is vast and the market is dominated by two, fairly inflexible models: OPM32 and P3M33.

We could suggest that there should be different capability maturity models to suit different organisations. While that may make the idea of models more relevant to a wider range of organisations, it seems to lose the key advantage of having a common benchmark.

Clearly, we need a model that is flexible but consistent; adaptable but with firm foundations. In my view, the current models are neither adaptable nor consistent. In order to work out how a capability maturity model should behave, I went back to basics.

I started off by revisiting the CMMI-Dev4 model, which is the publication from Carnegie-Mellon that specifically addresses project based development (albeit for IT projects only).

This opened up ideas that had links to ISO9000 and by connecting this to the APM Body of Knowledge it all started to make sense.

The key lessons from the exercise were:

Capability and maturity are different things.
Both capability and maturity are about achieving goals not just applying functions and processes with ever increasing rigour.
ISO9000 demonstrates how to have a consistent standard across diverse organisations.
The APM Body of Knowledge demonstrates how to address projects, programmes and portfolios in a single model.

Expanding on each of these in turn:
Capability and maturity are different things CMMI-Dev has two scales, one for capability (0-3) and one for maturity (1-5) so it clearly sees these as different things.

In the CMMI models, everything that is assessed for capability or maturity is termed a process. Closer inspection reveals that the processes used to measure capability are more narrowly focused that those used to measure maturity, i.e. maturity is about integrating capabilities.

In P3M terms this means that while your organisation may be very good at managing risk, that means nothing unless you can integrate it with other functions, such as stakeholder management and schedule management, within a project life cycle.
This can translate very well into the P3 environment.

If the functions defined in a body of knowledge are used to describe capabilities, the life cycle processes in a methodology can be used to describe maturity because they integrate the functions.

Therefore, an organisation may develop its capability in individual functions, such as risk management or stakeholder management, but its maturity would be reflected by its ability to apply these together in different phases of the project life cycle.

The problem with existing models is that they tend to focus just on the functions and only use one scale that typically goes from 1 to 5. Therefore, maturity is achieved by getting better and better at performing individual functions. This means that the attributes of each function just get thinly spread in order to achieve 5 different levels.

Capability and maturity are about achieving goals
CMMI-Dev talks a great deal about goals. Reaching certain levels of capability or maturity are not just about applying the corresponding function or process with 5 different levels of thoroughness, it is about achieving the goals of the function or process.

Therefore, assuming the goals of stakeholder management (for example) are to:

ensure that the views and attitudes of all stakeholders are understood;
influence stakeholders to be supportive of the work wherever possible;
maximise the impact of supportive stakeholders;
minimise the impact of unsupportive stakeholders.

These goals are so fundamental that they should be achieved athave to be achieved in order to reach level 3 1 capability or maturity.

Getting to level 3 is all about embedding the functions and processes so that good practice survives under pressure.

So what are levels 4 and 5 all about?
Many years ago, I read an article by Professor Rodney Turner where he observed that getting to level 3 was about achieving effectiveness (i.e. achieving the goals) and levels 4 and 5 were about achieving greater efficiency (i.e. achieving the goals with less resource).

This leads to a further refinement of the ideal model to suit P3 management where delivery functions are measured to level 3 capability and processes are measured to level 3 maturity.

At levels 4 and 5, we should not be asking if risk management or the identification process etc. are being applied ever more rigorously. At these levels we should be looking at governance and cultural functions such as knowledge management, communities of practice and professionalism. These are the indicators that tell us if the right behaviours are embedded in the organisation and will continue to be efficiently applied.

Diagram: a CMMI development model highlighting the differences between capability and maturity via a scale of characteristics

ISO9000 as an approach to benchmarking
Every project, programme or portfolio has a different context. Some projects include benefits realisation some dont; some programmes are stand alone and some are part of a portfolio; some projects are delivered by a contractor on behalf of a client and some are managed internally.

All these contextual variations have an effect on the functions and processes that an organisation needs in order to be mature.

If a contracting organisation delivers outputs on behalf of clients, its maturity shouldnt be measured by its ability to perform benefits realisation because thats not what it does.
Adapting measures of quality to provide a common benchmark for very diverse organisations is exactly what ISO9000 does.

This can also be achieved in P3 management if capability and maturity areas are defined so that an organisation can identify those that are relevant to its own context.

Of course that means that any accredited level of maturity needs to be viewed in the context of the components it includes. Thats fine because when comparing organisations it would typically be organisations who share a common context that are being compared.

The use of capability maturity models is not just about comparison. They are also a framework that organisations use to structure the improvement of their project and programme delivery. This too will be much more effective if the model can be adapted to the organisations own context.

Incorporating projects, programmes and portfolios in a single model The APM Body of Knowledge was the first guide to recognise that P3M functions are largely independent of whether they are being applied to projects, programmes or portfolios. For example, the goals I defined for stakeholder management are the same, regardless of the context.

Artificial distinctions between projects, programmes and portfolios are widely promoted with each seemingly requiring its own separate methodology. This is carried through to capability maturity models (and some competency frameworks for that matter) which often struggle to distribute capability maturity indicators across three separate domains of project, programme and portfolio.

This often results in general aspects of good practice being arbitrarily allocated to only one or two of the domains. For example, one well known model identifies the attribute Ownership of risk responses is being applied consistently as being unique to programmes and deemed (by omission) irrelevant to projects and portfolios.

Using the principle promoted in the APM Body of Knowledge, attributes can be defined for functions such as risk management that are independent of whether they are being applied in a project, programme or portfolio context.

This leads to a much more flexible model with less compartmentalisation, which makes it much easier and more cost effective to apply.

Capability maturity models have a proven track record of helping organisations improve their project, programme and portfolio delivery. Hopefully, if we can make them more adaptable and relevant to the many different organisations that use P3 management, we can increase their usage and, consequently, our collective success as a profession.

1. The third global survey on the current state of project management, PwC, 2012.
2. Organisational project management maturity model, Project Management Institute
3. Project, programme and portfolio management maturity model, Office of Government Commerce
4. CMMI for Development, Software Engineering Institute, Carnegie Mellon University

Adrian Dooley is the lead author of the Praxis Framework, which combines a body of knowledge, methodology, competency framework and capability maturity model in a single integrated framework.

Praxis is open and free. It can be viewed at www.praxisframework.org

This article first appeared in Project magazine. APM members can read all feature articles from Project magazine over recent years by accessing the Project magazine archive.

Non-members can subscribe to the UK's best-read project management magazine for as little as 56.50 per year (12 copies), which includes access to the Project magazine archive. APM members automatically receive the magazine as part of their membership:

UK: 56.50

Europe: 66.50

International: 77

View a sample issue of Project

To order yours now, click "Subscribe" below: