Using Maturity Models
By Andy ‘PRINCE2’ Murray
A Tale of Two Organisations
In the last few months I’ve had two customer requests for help to improve Risk Management with respect to projects.
The requests were very similar in that both organisations had problems with being ‘surprised’ by deviations or exceptions to projects. “We only seem to know the project is in difficulty after the event”. Therefore, both organisations believed that improving their risk management capability would reduce the instances of surprise.
I’m always keen when scoping solutions that we address the cause rather than the effect. (This wasn’t always true – when I was a student I turned up my radio to overcome the effect of my noisy engine. This worked for about 4 months until one day my radio was no longer required. My engine had become permanently silent!)
A little probing revealed two very different causes for these two organisations.
Organisation 1 – Project Boards
This organisation struggled to establish appropriate governance structures. Project Executives tend to be in name only and often are not aware of their accountabilities. In particular there was no concept of project tolerance.
Project tolerance is the permissible deviation from a project’s plan. This enables the project manager to mage the project without raising exceptions to board for every project issue. For example, rather than setting a precise budget of £94,100, it is better to allow the PM to make day-to-day decision so long as the project is completed within say £90,000 and £95,000. Tolerances should be set for other factors too (Time, Scope, Quality). There needs to be a balance between those deviations to a project which are permissible and those which require intervention from the project board.
Project tolerance too narrow = the project executive becomes a surrogate project manager (micro managing the project)
Project tolerance too wide = the project manager becomes a surrogate project executive (making all the decisions)
No project tolerance set = tends to either extreme (i.e. the PM may escalate everything or nothing)
This particular organisation tended to be too tolerant and the consequence being that Project Executives only understood the true state of the project when they received project reports or at project reviews – hence the surprise when ‘actuals’ didn’t match their expectation.
The element of ‘surprise’ was just as likely to be due to a change of requirements or a change of strategy that had taken place since their last review than the affect of an unforeseen problem (i.e. risk).
Organisation 2 – Planning
The second organisation had difficulties planning projects since their projects exist in a changing environment or were often going into the unknown.
To compensate these issues, the projects’ objectives and deliverables tended to be loosely defined so that they could flex in response to changing requirements or a better understanding as the project progressed.
The affect of this approach is that it is difficult to judge a project as a success or failure since there is no real baseline to judge it from. Loosely defined products and objectives also leaves expectations open to interpretation and assumptions. “I thought the back-up facility would be automated rather than manual”
For this organisation, the issue of ‘surprise’ was primarily a case of different opinions as to what the project would deliver (and when) rather than the affect of unforeseen problems (i.e. risks)
And the point is….
The remedy to the problems faced by the above two organisations did not come from implementing a risk management framework or sending their PMs away on risk management courses as requested.
For organisation one it was a case of educating both project sponsors and project managers on project governance and establishing a mechanism to check that for each person appointed to a project they had defined responsibilities for their role (including the degree of decision making permissible before escalating to the next level of authority).
For organisation two it was a case of introducing the ‘modular and incremental’ approach to planning to address the issue of projects operating in an environment of uncertainty. Coupled with the PRINCE2 concept of management stages, they gained an ability to define the near term objectives and deliverables with sufficient degree of detail to reduce expectation gaps on completion.
So what’s this got to do with Maturity Models?
Just like there are many reasons that an engine can be noisy, there are many reasons why an organisation can consistently be surprised with deviations to their projects (or their expectations of their projects!).
It is useful to do an ishikawa diagram for any given effect to help identify the cause. Fortunately, within Project and Programme Management we have a number of maturity models available to us that help codify the various elements of project and programme management.
For example, within the OGC’s Portfolio, Programme and Project Management Maturity Model (P3M3) there are 32 Key Process Areas (KPAs) that are required for excellent performance. Rather than simply list the KPAs (as they are in most Bodies of Knowledge) a maturity model presents them hierarchically. KPA’s belong to one of five levels of maturity:
- Initial (chaotic, ad hoc, heroic) – the starting point for use of a new process.
- Repeatable (process discipline) – the process is used repeatedly.
- Defined (institutionalised) – the process is defined/confirmed as a standard business process.
- Managed (quantified) – process management and measurement takes place.
- Optimising (process improvement) – deliberate process optimisation/improvement.
Each level of KPAs need to be in place for the next level of KPAs to be fully effective. Within (P3M3) there are 10 KPAs at level 1 and 2 relating to project management.
When meeting prospective clients for the first time, I now use these 10 KPAs as my initial ‘lines of enquiry’ to gain an approximate understanding of their broad capability, enabling a more rapid identifcation of the likely causes of the effects that they are wishing to resolve.
Gone are the days of turning up radios and hoping the noise will go away!
P3M3 is part of the OGC’s Successful Delivery Toolkit™. The toolkit is a Crown Copyright Value Added product developed, owned and published by the Office of Government Commerce. It is subject to Crown copyright protection and is reproduced under licence with the kind permission of the Controller of HMSO and the Office of Government Commerce.”
PRINCE ® is a Registered Trade Mark and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. PRINCE2™ is a Trade Mark of the Office of Government Commerce.
® Capability Maturity Model, Capability Maturity Modeling, CMM, CMMI, SCAMPI and Carnegie Mellon are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
PRINCE2 Registered Consultant
Outperform UK Ltd
Andy Murray is a PRINCE2 Registered Consultant and a director of Outperform UK Ltd. Andy holds a Diploma in Company Direction from the Institute of Directors (IOD) the final step to becoming a Chartered Director. Andy has been consulting in bid and project management for the last 15 years helping organisations across the globe win and then deliver profitable contracts. Andy’s mission is to help organisations win deals that remain profitable beyond to point of contract!
Outperform UK Ltd is an Accredited Consulting Organisation (ACO) licensed to consult in the OGC’s best practice products. Outperform is a corporate member of the Association for Project Management (APM), a corporate member of the Best Practice User Group and is ISO9001 certified.