We can probably all think of projects that have "failed" – perhaps processes got worse rather than better, maybe they were cancelled because of cost overruns, or perhaps systems were launched with fundamental errors.
How do you know when – and why – a project has failed? In many cases, the reason for failure is obvious. However, the definition of failure isn't always clear: one project with a significant delay might be described as a failure; yet another, with a similar delay, might be seen as a stunning success.
In this article, we'll define project failure, and explore the factors that cause some projects to fail.
Definition of Project Failure
A project is considered a failure when it has not delivered what was required, in line with expectations. Therefore, in order to succeed, a project must deliver to cost, to quality, and on time; and it must deliver the benefits presented in the business case.
The requirements for success are clear and absolute – right? Unfortunately, it's not that simple. Because the second part of our definition of success is that the project must be delivered "in line with expectations."
If key stakeholders agreed that a project had to exceed its initial budget, the project may still be considered a success. Likewise, if a project delivered everything that was in the detailed project designs, it may still be considered a failure if it didn't include vital elements that the key stakeholders needed. This doesn't seem fair, but project success and failure isn't just about the facts, nor is it simply about what was delivered. It's also, crucially, about how the project is perceived.
Reasons for Project Failure
Here are some of the main reasons why projects fail:
The wrong business requirements have been addressed
If your project is set up to deliver the "wrong thing," it may be considered a failure even if everything is delivered on time, within budget, and to the required quality. This seems harsh. But if your project doesn't deliver what the organization really needs, this will inevitably negatively affect how it's perceived. This is why it's so important to conduct a thorough business requirement analysis.
It's not possible to deliver the business case
If your business case can't be delivered, then you have an impossible task. To make things worse, after the business case is approved, delivery of other things then becomes dependent on your project. This makes changing your project's deadlines, budgets and expectations more difficult.
For example, once you've promised to deliver a new airport baggage management system, airlines may schedule additional flights for shortly after the system's launch, so that they can take advantage of the new capacity. If the baggage system doesn't work, or if it has major problems during testing, it may be hard to convince senior managers to allow the project to be delayed, because they will have to give up promised increased revenue.
When you write your business case, make sure you think through the project requirements in detail, and identify what's needed to ensure that you can deliver those requirements. Don't just list assumptions – make sure you explore them thoroughly. Review other, similar projects, so that you don't forget any major items. If you're delivering a new system, review your hardware and interface requirements. If you have major risks, include sufficient contingency resources (people, budget, and time) to manage those risks appropriately. Remember that implementing change is hard!
Be realistic, and be ready to have some difficult conversations. For instance, your CEO may be disappointed that he can't have what he wants before the year end, or key users may say that they really need a fully featured product at the end of phase one. However, it will be a lot harder to have these conversations at a future date, when your project is in trouble!
In many cases, business case documentation is written before a project manager is assigned. If you're the incoming project manager, make sure you don't simply accept these documents as they are!
You're responsible for delivering the project, so be sure to review the business case. Validate assumptions, and identify any gaps or areas that need more detail. If difficult conversations are needed, have them now. Once deadlines, requirements, and budgets are set, expectations are much more difficult to change!
Governance is poor
Few projects ever start without a sponsor. This is the person who has identified the need for change in an area of the business, and who is committed to making that change happen. He or she plays a vital role in ensuring the project's success. A good sponsor can make a mediocre project fantastic, and a poor sponsor can delay and frustrate a fantastic project team.
The project sponsor is supported by the project's governance bodies, usually in the form of a steering group. These governance roles are essential: they provide direction, guidance, and critical review of the project and its progress. As project manager, you're involved in the day-to-day running of the project, but governance groups can take a step back and look at the project from a different perspective. They can ask difficult questions about progress and performance. They may see things that you've overlooked. However, they can also support you by providing contacts and insights that help you get things done, and by providing "political cover" when you need it.
Project managers don't usually have any influence over who their project sponsor is. Sponsors either self-select, or they're chosen because of their position in the organization. However, you often have more influence over who is in your steering group. As such, if you know that your project sponsor lacks passion for the project, or if the sponsor doesn't like to say no to people who keep trying to expand the project scope, then make sure you balance this with tougher or more engaged steering group members.
Implementation is poor
If you deliver your project competently, you'll avoid poor implementation – right? Unfortunately, it's not that clear. Delivery can be complex. You need to manage risks, issues, and scope; manage your team; and communicate with stakeholders.
Delivering change is hard, and not everything is in your control. Therefore, being competent isn't enough for good implementation, but it's a good start!
People lose focus on the project's benefits
Projects are based on a list of benefits that must be delivered. For example, you may need a faster customer service process, you may need to produce products more cheaply, or you may need to improve the quality of your service. These benefit statements should be refined so that they're clear, concise, and quantified.
From these benefit statements, a set of "things to do" is generated. For example, you may need to consult customers, redesign products, or implement a new system. The outcome of this is a bisiness case, document that analyzes the project in terms of costs, and of the benefits will be delivered.
The project team then focuses on detailed planning, and on delivering the line items in the project plan – building a new system, developing training packs, mapping out new processes, and so on. At this stage, the team may forget about the benefit requirements.
This often results in a project deliverable that's well built, but doesn't provide the necessary benefits. For example, if the project plan focuses on designing and building a system, you could get a fantastic system, but one that's not being used by the business.
To avoid this problem, adopt a benefits management approach throughout the life of the project, and remember the need to deliver the required benefits when you're planning and delivering your project.
The environment changes
This is probably the trickiest area. If the business's needs change, then your business case can become outdated before you've actually completed the project. You may have to review your original requirements and goals partway through the project to decide how to proceed, and this may result in changing the scope of your project – or even canceling the project altogether!
If you're working in an environment that's changing fast, you can help reduce the risks by doing the following:
- Making timely decisions – If the project is clearly not going to be able to deliver the revised requirements, don't ignore this. The sooner you communicate this, and the sooner you make a decision about the project's future, the better.
- Considering smaller projects – It's more difficult to change direction in a large cruise ship than in a tugboat. So, think about whether a proposed project's scope and delivery timeline are appropriate within your business environment. Delivering projects in smaller pieces is not always appropriate, but it's worth considering.
- Managing expectations – Just because you cancel a project does not automatically mean that the project is considered a failure. This depends on many factors, including how you manage the involvement of key project stakeholders in the decision-making process.
Key Points
For a project to be successful, it's not enough simply to manage your project competently, and deliver a good quality product. To avoid failure, make sure you have identified the right business requirements, created an achievable business case, put strong project governance into place, managed a high-quality implementation, focused on benefits, and monitored your changing environment.
Above all, be sure to manage the expectations of your stakeholders, so that they stay supportive. After all, these are the people who will declare your project to be successful – or otherwise.
