In an IT systems context, contingent project management (“CPM”) is the ability to select an appropriate methodology to successfully apply and deliver a project, adjusting the method as the project progresses. The ‘contingent leadership style’ is analogous. Wikipedia (Fiedler) provides an explanation of contingent leadership.
Yes, a project manager may have a contingent leadership style, but they may not have a contingent project management approach.
Let’s look at a variety 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 technological change was low, having grown out of engineering and construction. It still works well in a construction (civil engineering) context, where the rate of technology change is generally low. A building’s requirements may change during construction, but the scope progress rate remains low compared to many IT projects. Under the right circumstances, it can still work well with IT projects.
Agile methods (gather and prioritize requirements, prototype, test, deliver, recycle: design, build, test, deliver, train, and go live). On the scale from low risk/low complexity to high risk/high complexity, some of the methodologies would be: XP, Scrum, DSDM ®, RUP ®. Keep in mind that risk and complexity are not always equal: some low-complexity systems may have profound organizational risk associated with them.
Prince ® could be used in any of these contexts for project governance on a broader organizational scale, or locally on a smaller scale. In fact, the advent of Prince2 moved the methodology into a broader, non-IT-specific context.
Agile methodologies are more appropriate, for example, when the requirements are not clear from the outset, and/or the technology is new or scaling, and/or a new business model is being adopted (to name just a few reasons). . The range of agile methods is also related to the scale of the project and the size of the team.
Sophisticated organizations may have their own ‘pet’ methodology, perhaps having invested heavily (financially, administratively and politically) in developing their way of doing things, even ‘branding’ the methodology. After all this investment, they will want to ‘sweat this asset’. The projects will have to fit into the corset they impose; this can cause extreme throttling, creating a high probability of failure on a project, even before it gets started.
After all, Prince ® was developed in the UK public sector (and the UK government still has massive problems delivering projects). At the high end of projects, Prince is often seen as overly bureaucratic, but he shouldn’t be. CPM must ensure that the appropriate processes are selected for a project and applied judiciously so that the project is not choked by administration and bureaucracy.
This strangulation of projects by heavy methods was observed by the author in an investment bank. Project managers running a large number of smaller projects were unable to meet the centralized project reporting requirements placed on them, leading to managerial frustration, program office frustration, and frustration in and with the ‘ methodological police’. The recommended solution was
– Prioritize projects according to risk (measured along various dimensions), report project status on the basis of ‘exceptions’ and adjust reporting frequency to project risk.
This leveled the workload of project managers and the need for centralized risk control and comfort.
So what about contingent project management?
It is clear that a significant degree of expertise is needed to be able to select the right methodology for a project, and the program board is not always in the best position to decide for reasons mentioned above, eg investment and political capital.
An effective project manager will have
– the wisdom and experience to select the right tool for the job based on your perception of the risk profile; the ability to persuade the program board or sponsor of the relevance of the methodology and the basis for selection; I worked with a range of experience in methodologies that allowed for the application of a ‘heavy’ or ‘light’ touch to a methodology; an innate sense of risks and their relative relevance, which means you develop and maintain a focus on the things that matter; finally, the ability to dynamically adjust the methodology to circumstances without loss of control (finances, schedule and quality), as the ‘things that matter’ change
Dynamic fit means applying the tool wisely: some projects may require very high levels of stakeholder communication, others will need to focus heavily on technology/performance and proof of concept, others may have political governance issues, business models new or immature, etc. us. Some projects, of course, will exhibit all of these risks and beyond. This list and balance of risks will change significantly during the life cycle 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 failed projects continue in the same vein as always, without contingent project management being implemented and management not responding adequately to changes in risks.
Contingent project management is really simple in principle: adapt and survive, ie Darwinism. To apply it successfully requires a lot of experience and flexibility.