In general, organisations perform two types of work: projects, and operational work. The latter is relatively easy to perfect. Operational work tends to be repetitive, lending itself well to systematisation and incremental improvements over time. Projects, on the other hand, are unique from one to the next, have fixed starting and ending dates, and tend to involve steadily shifting teams. This makes it very difficult to systematise projects and develop sound processes for completing them. In this post we look at the reasons why projects fail.
The difficulty many organisations have with project management is almost legendary. According to the Standish Group’s CHAOS report, some 31% of projects are cancelled before completion, while 52% of projects see their costs go over budget by at least 180%.
Why does this happen — and is there any way to limit project failures? Unfortunately there is no simple answer, but there are a few common problems that frequently crop up and sink an otherwise successful project.
Addressing the wrong business requirement
Even if the project delivers everything on time and within budget, it can still fail. How? By delivering something the business did not actually need. The project may have been approved at the highest levels of management, yet if the result turns out to be superfluous or not what the stakeholders expected, the project will be judged a failure.
Losing focus on the necessary benefits — “scope creep”
Projects are commissioned in order to deliver certain benefits to the organisation. Your firm may need to reduce production costs, speed up customer service, or any number of other things. The goal of the project is to deliver one or more of these benefits.
Based on these benefits you draw up a “to-do” list, which may include implementing certain new systems or redesigning products. However, many people lose sight of the original required benefits at this point.
If the project team merely focuses on the “line items” required without regard to the overall benefit needed, any number of failure modes may crop up. The project may deliver a technically correct result which is nevertheless organisationally useless.
In other cases the project will expand in scope until it has become unmanageably large. What was originally a fairly straightforward project ends up attempting to completely re-architect the company. In this case, a premature failure and cost overruns are inevitable.
Lack of risk management
Since every project is unique, there is always uncertainty, known as risk. The project manager must anticipate risk, figure out what might go wrong, and devise ways to prevent that from happening. Poorly managed risks can easily appear when least expected and sink the project.
Perhaps the simplest way to manage risk is by way of a “pre-mortem” analysis of the project. It’s simply a question of assuming, for a moment, that the project will end up failing and then determining what will cause that failure. From this you can then take measures to eliminate or at least manage the risks you’ve identified.
Poor resource allocation
It often happens that in the interest of saving money, too few team members will be assigned to handle too much work. The unfortunate result is that everything ends up costing more money, as the team operates less efficiently and unforeseen delays crop up.
In some cases, this problem may occur without knowledge of the project manager. If the manager isn’t fully aware of a given person’s workload, they may inadvertently assume that person can handle more work than is actually reasonable. It’s much better to stay in touch with your team and verify what’s in their queue and that they can handle it all.
The estimates used in project planning are often closer to “guesstimates,” made by team members who try to anticipate the duration of a task by how long they took to do it last time. Sometimes this may be extremely accurate, sometimes it may not be accurate at all. If the estimates are not reliable, then the schedule is flawed and the project may take much longer than expected.
Unfortunately, as simple as estimates may seem, they can be critical to the success of the project. Once the project’s business case has been approved, other things start depending on the project completing on schedule — and changing the deadlines and budgets, or even the expectations, can be very hard.
For example, if your firm has promised to implement a new baggage handling system for an airport, airlines may start scheduling new flights for immediately following the new system’s anticipated launch. The airlines want to take advantage of the new capacity and senior managers want to enjoy the increased revenue, so it can be very hard to convince the stakeholders later that the launch must be delayed.