Change language:
Comments

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 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 November 2015 the same search rendered 76,200 results.

Despite this expansion of the idea, the implementation hasn’t followed. You don’t see companies trumpeting their maturity as a means of demonstrating how good they are at delivering projects and clients rarely make a contractor’s maturity level a condition of tendering for a project.

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”.

If PwC’s findings are correct then 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 loses 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. 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 processes.
  • ISO9000 demonstrates how to have a consistent standard across diverse organisations.
  • The APM BoK 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.

capability maturity tableThis 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 integrate and apply these 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 should be achieved at level 3 capability. Similarly, the goals of integrative processes should also be achieved at level 3 maturity.

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 because the appropriate behaviours have been embedded).
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.

 

 

ISO9000 as an approach to benchmarking

Every project, programme or portfolio has a different context. Some projects include benefits realisation some don’t; 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 abilities that an organisation needs in order to be mature.

If a contracting organisation delivers outputs on behalf of clients, its maturity shouldn’t be measured by its ability to perform benefits realisation because that’s 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 project 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. That’s 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 delivery. This too will be much more effective if the model can be adapted to the organisation’s own context.

 

Incorporating projects, programmes and portfolios in a single model

In my article about the ‘discontinuous mind’ I explain how the concept of projects, programmes and portfolios as discrete, mutually exclusive entities is more a product of the human intellect than any fundamental, objective differences.

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

 

SHARE THIS PAGE
No history has been recorded.

Capable, mature or both

Back to top