May 17, 2011 - Despite well-trained project managers, detailed plans, countless excellent documents, efficient project meetings, and the very best of intentions, some projects still fail and sometimes fail badly. Why?
Projects fail for both internal and external reasons. Even so, the project management team can often take steps to mitigate the risks well before they become actual issues. The key to success is being aware of issues and acting promptly.
In the early stages of a project, the team is optimistic and enthusiastic. They want it to succeed. But lurking beneath the rather vague initial designs are assumptions and hidden risks. Can the most difficult part of the project actually be done? Has anyone ever been successful in the timescale we require? Do we really have the skills to do it? Often the answers given are optimistic without really being able to answer the questions.
Essential to the early phase of any project is a risk reduction exercise in which the project team gets a clear understanding of where the major risks lie. It could be that the design is new and contains untested elements. Perhaps research is required to confirm that a particular part of the design is possible. Maybe a prototype needs to be built before we can trust the estimates. It could be that, as yet, no-one has developed the required skills in house, or that they are scarce or even unavailable.
In the case of software projects, this initial lack of clarity about the underlying risks can be missed in the drive to get moving, to cut some code, to get some prototyping underway. While development engineers may be fully aware of the uncertainty, their initial optimistic estimates are nevertheless taken as a reliable source for project planning. What should have been explicit risks, lie implicit in the schedule of the project itself. Any later suggestion that the initial estimates were too optimistic and need to be changed will face resistance because the plan will already have been communicated around the business.
Let's assume that the initial phase was in fact a risk reduction phase and that some significant risks were identified. We need to understand the severity and likelihood of these risks. Trying to put numbers on vaguely understood risks is itself a risky activity. Often these will be little better than guesses. The optimism of the project will encourage managers to defer detailed analysis of these risks, trusting instead the ability of the team to solve the problem later in the day.
The way to mitigate these future risks is to spend some time carrying out risk reduction activities, such as prototyping, developing skills, exploring the viability of design decisions. At this stage, very costly mistakes can be captured at low cost. Failure to devote resources to this early activity can cost a project dearly.