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

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 IT projects.

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 specific context.

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 red-tape.

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 profile
• the ability to persuade the programme board or sponsor of the relevance of the methodology and the basis of selection
• 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.