When starting a technology project, no one plans to fail. But the sad truth is that many technology projects do fail. And the failure rate is surprisingly high. Only about 29% percent of software projects are on-time and on-budget. McKinsey reports that 17% of technology projects fail so badly that they threaten the very existence of the companies that finance them.
So, how can you prevent this from happening to your project? One way is to do a risk analysis. In a risk analysis, you and your colleagues look at the project from a variety of angles and try to predict what could go wrong to prevent it from happening.
But an even more helpful technique is to conduct a project pre-mortem. That’s “pre-mortem,” not “post-mortem.” Most people are familiar with project “post-mortems.” In a project post-mortem, the project team analyzes what went right and what went wrong after a project is complete. The purpose is to capture lessons that can apply to future projects. But a pre-mortem happens before any work on a project takes place. It is a way to get “prospective hindsight.”
Pre-mortems lead to valuable insights not attainable in another way. By using a pre-mortem, teams can increase their chances of uncovering potential reasons for failure by as much as 30%.
When should you do a pre-mortem?
A pre-mortem should be done after the scope of a project and its project plan are set. The reason it should not happen until the project plan is complete is that the people participating in the pre-mortem need to be analyzing something concrete. But it should happen before the project begins.
Who should participate in the pre-mortem?
A pre-mortem should include the complete project team (not just senior team members) and stakeholders. This helps maximize buy-in and reduces the risk of blame and finger pointing later. The pre-mortem should not include anyone who isn’t familiar with the project plan.
How do you do a pre-mortem?
There are a variety of ways to do it. But here is one way. It should take between 60 and 90 minutes to complete. The pre-mortem leader starts the exercise by announcing something like: “The project has failed. It has been a complete disaster. It is way over budget, far behind schedule, and the software is almost non-functional. Our intended users are not adopting it. It is a failure in every way and a serious embarrassment. Why did this happen?”
Then, every member of the team takes several minutes to privately write down the top reasons the project failed. After that, each team member shares the reasons he or she came up with. The pre-mortem facilitator captures those reasons on a white board or by some other means.
Next, each pre-mortem participant votes on the top 3 reasons he or she thinks are most likely why the project failed. One way to do this is to give each team member 3 stickers for them to place on the white board next to the reasons they think most likely caused the failure.
These votes are tallied and the top predicted reasons for project failure are ranked. Those rankings are recorded. The pre-mortem exercise is then complete. And the project manager is tasked with strengthening the project plan in light of the pre-mortem exercise.
Why is a pre-mortem so effective?
Here are a few reasons:
- It allows people to think in terms of failure. At the beginning of a project, there is often a lot of optimism and excitement and the team might not allow itself to think about failure. The pre-mortem allows your team to think in ways it possibly has not yet.
- It makes people speak up who otherwise might not because of politics or not wanting to look like a poor team player. It is a structured and open dialogue. It democratizes the conversation and allows the people closest to the relevant information to voice their concerns.
- It counters groupthink. It gives individuals a chance to voice their concerns. It encourages them to do so. It helps the team to have a positive discussion about threats. This increases the chances that the main threats get identified.
- It provides a temporal perspective shift. When we think about the past, we tend to ask “why.” This helps us come up with better explanatory reasons for potential failure than asking “what could happen.”
So, that’s how you can do a pre-mortem. It can be a useful and eye-opening exercise. It might save your technology project from disaster.
We’ve been through our fair share of projects, so we created the following Cheat Sheet to help your team proactively plan for a successful project:
Pre-mortem Cheat Sheet
Keep in mind these factors that can cause a custom technology project to go wrong:
- Not getting buy-in from the right stakeholders. A technology project needs buy-in from all the stakeholders. When one group of stakeholders sets all a project’s requirements without input from other important stakeholders, the project tends not to end well. For example, if project managers will be the primary users of a custom software, they should be heavily involved in defining the software’s requirements. If the executive team gives all the inputs on the software that the project managers will use and the project managers give none, the company will likely end up with an expensive piece of software that doesn’t meet the needs of its intended users.
- Avoiding the most difficult users. This is related to not getting buy-in from the right stakeholders. Some companies have outspoken influencers who, regardless of job title, tend to have an outsized effect on how other employees view corporate initiatives. If you can involve these people in the project planning process, they will often become your advocates and allies, helping bring the project to a successful completion. But if you don’t, they can eventually cause a project to fail.
- Improper constraints around time or money. Time and money are limited, and all projects need appropriate time and budget caps. But the wrong limits can cause a project to fail. Sometimes projects are not given enough time and the end product ends up being rushed and not meeting the company’s needs. At other times, money is not budgeted appropriately. For example, if a company has a maximum of $50k budget for a project, it could make sense to initially scope the project at $30k. That way, if the company changes its mind mid-project about certain features, the project can still be completed to the company’s satisfaction.
- Not building in the ROI. The development of custom business tools typically gives a high ROI. But it can only do so if the ROI is thought about and built into the project. If you don’t have a clear sense of how your custom tool will benefit your company, you might build something you don’t need or might abandon the project once you realize that it will not give a good ROI.
- Scope creep. Once a development project begins, companies can become excited about the possibilities and may start trying to change everything all at once. Or, at least, they might try to change more at one time than they should. But this scope creep can sometimes end up in an unwieldy project that never reaches completion. [Use this survey tool to help identify your proper scope]
- Not treating the project as something important. Custom software is a big investment for a company. It will have a significant effect on a company’s operations for a long time (typically a decade or more). If it is rushed or not given the attention it should be given, the company could end up with a tool that doesn’t meet its needs and slows it down or isn’t even used.
Want to work with a software development partner that knows what it takes to avoid ending up with a “dead” project? Get in touch!
