The Seven Deadly Sins Of Project Management – Article 6

Project management is a key vehicle for organisations to turn strategy into action. However, despite the increasing investment in project management capability, many projects still fail to meet their objectives. In this sixth article in a series we explore how poor change control can wreck projects, one of the ‘seven deadly sins’, initially coined by Jeffrey Pinto in his paper ‘Lies, damned lies, and project plans’: Recurring human errors that can ruin the project planning process’.

At Skarbek, we often parachute into situations where a client’s key projects are in crisis and the blame game has begun. Has there been malpractice in project management, or is it environmental factors that have driven failure – lack of resources, commitment, engagement, or sponsorship? To those project managers who readily point out that their projects were well run, but these external factors conspired against success, Pinto’s seven deadly sins provide some insights that can make the profession question whether they really got it right from the beginning.

The sixth sin addressed by Pinto is poor change control. Whilst teams are encouraged today to be agile, that imperative does not cancel out the relationship between the core project objectives of time, cost, quality, scope and resources. In fact, McKinsey’s definition of agility is a balance between dynamism and stability, and in this context, it is the change control process that provides the stability, alongside the flexibility. By all means change the scope when necessary, but do not neglect to check the impact on cost, quality, time and resources.

Pinto points in particular to rework as a consequence of poor scope control, but also interestingly contends that some rework is inevitable due to:

1. Some change in requirements always being likely during the project’s lifespan
2. ‘Gold plating’ tendencies to improve the product in flight
3. Limitations in what can practically be planned and scoped for

Moreover, some project techniques require rework, especially agile methodologies. So the question is how to maintain control of the project when inevitable rework is required. In Skarbek’s experience, the key difficulty is human-driven and that the need to execute a change control shines a light on project problems that most prefer to defer. This is a key contributor to keeping the ‘death marches’, discussed in article three, going. A change control forces a confrontation with the cognitive dissonance project teams and senior sponsors are often harbouring as the project defined begins to diverge from the reality and thus, can be an unpleasant experience!

It is vital to recognise the dire consequences that a single change imperfectly communicated can have on a project. The apocryphal story of Apollo 13 and the change to operating specifications of electrical systems that nearly caused the death of three astronauts, is a good reminder of the potential cost of badly coordinated changes.

At the portfolio level, what we have seen frequently as a consequence of that dissonance is that projects that need a change control get ‘hidden’. For example, are there projects that stop progressing between stage gates? At one client, we found 35 projects on a hold list that was never reviewed, with some projects having been 14 months on that list. Combined, the projects stalled between gates and those on hold were still consuming significant resources as activities were kept ‘ticking over’. To build an effective change control capability, we recommend the following:

• Implement a two stage change control system, one for minor and one for major changes. Major changes can be defined with pre-set criteria on cost, time, quality, scope and should always be presented to a Project Review Board
• Utilise a simple one-page change control format that allows for the objective assessment of the impact on cost, time, scope, quality and resource
• Ensure impacted functions contribute to, and sign off, the change impact assessment
• Build a culture that supports change controls to be raised when necessary
• Pressure test your portfolio system to see where projects can be hidden from the scrutiny of the change control process
• Put in metrics, such as time between gates and time on hold, to flush out the hidden projects
• Be rigorous in approving change controls and where improvements in planning and initiating are identified, ensure these learnings are captured, codified and applied
• In the initiation and planning stage, capture assumptions and ‘don’t knows’ and have action plans to resolve them over time to avoid these becoming scope derailers later

In the final article, we will explore the remaining deadly project sin before drawing together our insights as a whole of what may be dooming your projects from the offset and the overall strategies that we have found can be employed to avoid this fate.