Contingent Project Management – A Definition

In an IT systems context, contingent project management (“CPM”) is the ability to select an appropriate methodology to apply to and successfully deliver a project, tuning the method as the project proceeds. ‘Contingent Leadership Style’ is analogous. Wikipedia (Fiedler) provides an explanation of contingent leadership.

Yes, a project manager can have a contingent leadership style, but may not have a contingent project management approach.

Let us look at a range of project management framework processes:

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 methods (gather and prioritise requirements, design a prototype, test, deliver, re-cycle – design, build, test, deliver, train and go live). On the scale of low risk/low complexity to high risk/high complexity some of the methodologies would be: XP, Scrum, DSDM ®, RUP ®. Note that risk and complexity do not always equate – some low complexity systems can have profound organisational risk associated with them.

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.

Sophisticated organisations may have their own ‘pet’ methodology, maybe having invested heavily (financially, managerially and politically) in developing their way of doing things, even ‘branding’ the methodology. After all this investment, they will want to ‘sweat this asset’. Projects will 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). 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.

This choking of projects by heavy methods was observed by the author in an investment bank. The project managers running a large number of 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 recommended 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 levelled the project managers’ workload, and the centralised need for control of risk and comfort.

So, what of contingent project management?

It is clear 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 best placed 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; finally, 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. In addition to ongoing Risk review, CPM requires ongoing process review and change.

How is it that more than 30% of projects fail? 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 straightfoward in principle: adapt and survive – that is, Darwinism. To apply it successfully requires a great deal of experience and flexibility.

Source by Phil Marks