What is CPM?
by Phil Marks
In an information systems or technology context, CPM ("contingent project management") is the ability to
select a management methodology to apply to and successfully deliver a project, tuning the process as the project
proceeds. It is analogous to 'Contingent Leadership Style' but in a project context. See Wikipedia for an explanation of contingent leadership.
Yes, a project manager can have a contingent leadership style, but may not have a contingent project management
Consider the range of project methodologies (and the range will include some proprietary methods):
Waterfall (gather requirements, design, build, test, deliver, train) – the ‘traditional’ way of building
systems. This worked well for systems where the rate of business and technology change was low, having grown out of
engineering and construction. It still works well in a construction (civil engineering) context, where generally,
the rate of technology change is low. Requirements of a building may change during construction, but the rate of
scope creep is still low as compared with many IT projects. In the right circumstances, it can still work well with
Agile (in general terms: prioritise requirements, design a prototype, test, deliver, re-cycle – design, build,
test, deliver). On the scale of low risk/low complexity to high risk/high complexity (though risk and complexity do
not always equate – some low complexity systems can have profound organisational risk associated with them), some
of the methodologies would be: XP, Scrum, DSDM ®, RUP ®.
Prince ® could be used in either of these contexts for governance of the project on a wider organisational
scale, or locally on a smaller scale. Indeed, the advent of Prince2 moved the methodology into a wider non-IT
Agile methodologies are most appropriate for example where requirements are unclear at the outset, and/or the
technology is new or being stretched, and/or a new business model is being adopted (to name just a few reasons).
The range of Agile methods also relate to scale of project and team size.
Larger organisations may have their own in-house or ‘pet’ methodology. They might have invested heavily
(financially, managerially and politically) in developing their way of doing things, even ‘branding’ the
methodology. After all this development, they will want to ‘sweat this asset’. Projects will then have to fit into
the corset they impose – this can cause strangulation at the extreme, building a high probability of failure into a
project, even before it is initiated.
After all, Prince ® was developed in the UK Public Sector (and the UK Government still has massive problems
delivering projects). RUP ® is now an IBM brand. At the top end of projects, Prince is often seen as excessivley
bureaucratic, but it shouldn't be like that. CPM should ensure that the appropriate processes are selected for a
project and that they are applied judiciously so that the project is not strangled by administration and
For example, an investment bank where the project managers running smaller projects were unable to meet the
centralised project reporting requirements imposed on them, leading to frustration in the managers, frustration in
the programme office, and frustration in and with the ‘methodology police’. The solution was to
- prioritise the projects according to risk (measured on several dimensions),
- report project status on an ‘exceptions’ basis, and
- tune reporting frequency to project risk.
This balanced up the project managers’ workload, and the centralised need for control of risk and comfort.
So, what of contingent project management?
The proposition is that a significant degree of experience is necessary to be able to select the appropriate
methodology for a project, and the programme board is not always the best body to decide for reasons mentioned
earlier – investment and political capital for example.
An effective project manager will have
- the wisdom and experience to select the correct tool for the job based on his or her perception of the risk
- the ability to persuade the programme board or sponsor of the relevance of the methodology and the basis of
- worked with a number of methodologies
- experience enabling the ‘heavy’ or ‘light’ touch application of a methodology
- an innate sense of the risks and their relative salience, meaning that a focus is developed and maintained
on the things that matter
- the ability to dynamically tune the methodology to circumstances without loss of control (finance, timeline
and quality), as the ‘things that matter’ change
Dynamic tuning means applying the tool judiciously – some projects may require very high levels of stakeholder
communication, others will have to be highly focused on technology/ performance and proof of concept, others may
have political governance issues, new or immature business models, and so on. Some projects, of course, will
exhibit all of these risks and more beyond. This list and balance of risks will change significantly during the
lifecycle of the project. This is simply, ongoing process review.
If there are so many project and programme managers, then how is it that more than 30% of projects fail (I shall
not delve into failure reasons here, that is the subject of another article)? It is because failing projects
continue in the same old vein, without contingent project management being deployed and the management not
responding appropriately to changes in risks.
Contingent Project Management is really simple: adapt and survive – that is, Darwinism.
© 2010 Phil Marks. All Trade and Service Marks are acknowledged.