Why do projects fail? This is a question that has many answers. I intend for this post to be part of a series of posts that address issues that lead to project failure and what you can do to increase your project’s success rate.
First and foremost, let’s define failure. I mean that–I want Us to define it, because, like success, it’s defined and determined by the person or people receiving the deliverables. So, think about some of the projects you’ve worked on, whether or not they failed. If they failed, what constituted their failure; if they were successful, what would have constituted their failure? I’m going to take a stab at some of the reasons:
- Didn’t produce all of the deliverables agreed upon
- Didn’t produce the deliverables on schedule
- Produced the deliverables on time but not to the quality standards agreed upon
- Funding was cut halfway through the project
- Weather negatively impacted the deliverables or schedule
And the list goes on. I’m a big proponent of KISS (Keep It Simple Stupid), so rather than get into a long and drawn out explanation of failure, I’m going to boil these reasons down to one simple and palatable term–RISK. These are all risks of the project and, as a Project Manager, you should be spending the majority of your time mitigating risk. Think about it–if you’ve done all of your work drafting a Project Charter, getting approval, and planning the entire project, there’s nothing worse than getting derailed for one reason or another because you failed to adequately plan for and monitor risk on the project.
Here’s what you should know:
- If you’ve planned your project correctly, you’ve already developed a risk management plan through which you, your team members, and your stakeholders have identified risks and created risk response plans to address each one.
- If you haven’t begun to develop your risk management plan–that’s OK. Project planning, executing, and monitoring are iterative processes, so there’s no better time than now to start a plan.
- During the Identify Risks process, you should be documenting all of the risk on the Risk Register. Think of this document as a centralized list of all project-related risks. It’s from this document that you will begin to develop risk response strategies for each of your risks.
- Risks take many shapes and forms. There are known and unknown risks; secondary risks; qualitative and quantitative risk analysis; and response strategies that can be developed to accept, avoid, exploit, mitigate, share, or transfer risk. Do your research to know which is the most appropriate for your individual projects.
- Risks should be a topic at every meeting.
The goal is to be prepared for any of the documented risks and to know exactly what to do were any of them to come to fruition. The PM should be able to simply follow the Project Plan.
I always go back to the old adage often attributed to Benjamin Franklin–“Failing to plan is planning to fail.” Don’t let the lack of risk response planning be the reason your project fails.
Mike