According to a 2017 report from the Project Management Institute (PMI), 14 percent of IT projects fail. However, that number only represents the total failures. Of the projects that didn’t fail outright, 31 percent didn’t meet their goals, 43 percent exceeded their initial budgets, and 49 percent were late.
The PMI’s survey also collected information on the most common reasons for IT project failure. Nine of the top reasons are below, followed by ideas on how to avoid or overcome them.
According to the PMI, six factors must be met for a project to be successful:
It’s no surprise, then, that 39 percent of failed projects tank because of bad requirements. It’s impossible to build something that does what it’s supposed to do, meets its goals, and makes sponsors happy when you don’t have good requirements to work from—much less to do all of that on time and within budget.
Requirements often cause projects to fail when sponsors write specification documents in a vacuum, leaving the development team out of the process.
I once worked on a project where the business team spent almost a year creating a 400+ page document detailing every requirement and design for a project. When the requirements were complete, I shared them with the development team.
In the very first review session, the development team noticed an architectural issue in the designs. The issue impacted every requirement and design for the entire project, and the only solution was to rethink the entire approach—to start over.
But instead, we scrapped the project, and the millions of dollars the company spent paying people to document those requirements became just another lesson learned.
To avoid this problem, involve all subject-matter experts—business partners, IT representatives, and even end users—during the requirements phase of a project.
Business representatives work with end users to document the “what”—the goals of the project. IT representatives weigh in on the “how”—the best way to build what’s requested.
When these two things happen concurrently, it significantly reduces the risk of project failure resulting from inadequate or incorrect requirements.
In 2008, Qantas—Australia’s national airline—canceled its $40 million Jetsmart project. Jetsmart was a project to build a parts management system for the company’s airplane mechanics. Unfortunately, the solution was so poorly-designed and complicated that the airplane mechanics refused to use it.
Officials from Qantas later stated that instead of asking the mechanics what they needed, they just built what they thought was appropriate. By failing to involve the right subject-matter experts—the end-users—Qantas had to abandon a costly IT project, and the company ended up spending three more years building a replacement solution.
Another big cause of failure arises when development happens in a vacuum. Instead of staying involved during the development phase, project sponsors hand off the requirements and wait for teams to deliver a finished product.
This leaves teams with no representative to contact when questions arise. Instead, they’re forced to make their best guess and continue developing. If they guess wrong, business doesn’t find out until development concludes.
This leads to unhappy project sponsors, products that aren’t fit for release, and complex changes that leave the project overdue and over budget.
According to the PMI’s 2017 survey, inadequate sponsor support accounts for 27 percent of failed projects.
To avoid this failure, make sure a project sponsor or other appointed business representative participates during the development phase.
The business sponsor answers the development team’s questions about requirements, and reviews in-progress work to ensure that what’s developed satisfies the original requests.
Perhaps the most publicized IT project failure of the last decade was HealthCare.gov: a U.S. government project to build a website that allowed uninsured individuals to purchase health insurance at a discounted rate through private exchanges.
HealthCare.gov launched in October of 2013, and issues appeared instantly. The site was unable to support the more than eight million users who visited it in the first few days after launch, and as a result, only 1 percent of people were able to successfully enroll.
Upon investigation, it became clear that poor communication and a significant lack of stakeholder participation were two of the biggest causes of the project’s failure.
In his article for Time, Steven Brill wrote: “No one in the White House meetings leading up to the launch had any idea whether the technology worked.” In fact, the White House’s Chief Technology Officer was deliberately excluded from project planning meetings.
Every IT project has three constraints: time, scope, and budget.
Using a Waterfall approach, time and scope are fixed, but budget is flexible. The development team delivers all requested functionality by a specified deadline. If that’s impossible, teams add budget to increase the amount of work they’re able to complete in the allotted time frame.
Using an Agile approach, time and budget are fixed, but scope is flexible. Recognizing that few—if any—projects ever go exactly according to plan, Agile’s founders advocated for a system that allows teams to shift priorities as needed to make sure finished products satisfy the most pressing business needs.
Most Agile teams operate in a Scrum framework. Scrum teams work in short iterations that are usually between one week and one month long. At the beginning of each iteration, the team plans its work. During the iteration, the plan cannot change, but each new iteration represents an opportunity to change the plan.
It may be impossible to control changing project objectives, but it is possible to minimize the impact of shifting objectives by working in a model that supports change when required.
Changing project objectives are to blame for 36 percent of failed projects, but changes in the plan don’t have to lead to failure. Minimize this risk by reducing the timeframe of plans.
Plan work in two-week iterations: determine which set of work is the most important, and focus on the tasks you’re able to complete during those two weeks. This ensures that the development team is always focused on the highest priority work and consistently delivering releasable code.
Between 2000 and 2005, developers at the FBI worked on Virtual Case File—a system intended to modernize the bureau’s IT systems and replace a legacy case management platform. After spending five years and nearly $170 million dollars, the project was abandoned.
Virtual Case File was deemed “incomplete, inadequate, and so poorly designed that it would be essentially unusable under real-world conditions.” The team contracted to build the software insisted that the problems were the result of scope creep and frequent changes in project specifications.
The cone of uncertainty—pictured above—is a diagram designed to explain the problem with project estimates.
In the earliest phases of a project, estimates are—at best—educated guesses. Because teams know so little about project requirements and dependencies, cost and time estimates may be four times more—or four times less—than actual implementation costs and timeframes.
As requirements mature and development begins, that variability lessens, but the only time it’s at zero is when the project is complete.
Variable as they may be, estimates are a necessary evil in IT projects because few business sponsors are willing to hand over a blank check. Before approving projects, sponsors need some sense of whether or not they can afford the cost—and whether or not the cost is worth the investment.
Still, inaccurate estimates aren’t a direct cause of project failure—even though they’re cited as a cause of failure in 28 percent of projects. Inaccurate estimates are the outcome of two underlying causes:
The solution to this problem depends on its underlying cause:
With proper planning and estimation, teams can usually deliver something on time and within budget—even if that something isn’t 100 percent of the requested scope. But for a project sponsor, getting less than what you hoped for is always better than getting nothing at all.
In the 1990s, the city of Denver decided to build a new airport to accommodate an increased amount of people using the existing airport. Part of the new airport project was an automated baggage handling system that would reduce flight turnaround time by 30 minutes.
Unfortunately, the complexity of building the new the baggage handling system was grossly underestimated. The baggage system alone delayed the opening of the airport by 16 months, and cost the city of Denver $1.1 million every day during the delay.
Though a version of the the baggage system was eventually released, it never worked as planned—even after the long delay and $560 million in added costs—and was eventually scrapped altogether in 2005.
There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don’t know we don’t know. – Donald Rumsfeld
As Rumsfeld’s quote highlights, there are three types of risks to any project:
Unexpected risks account for 27 percent of project failures, but they shouldn’t. The solution for unexpected risks is the same as the solution for inaccurate estimates. To avoid project failure due to unexpected risks, estimations need to reflect both known and unknown risks.
The cone of uncertainty is designed for just this purpose. In the project initiation phase, your team estimates that it will take a month to complete the coding. But since there’s still such a high potential for unknown unknowns to pop up, relay an estimate of four times that size to the project sponsor.
That extra three months will provide ample time to handle any unexpected risks that crop up. And in the best-case scenario, you finish three months early. Telling a project sponsor that you finished early and under-budget is always preferable to telling her that the project will be late and cost more than planned.
In 2001, the U.S. Census Bureau decided to initiate a project that would modernize how they collected data for the 2010 census. Instead of having surveyors use paper forms, they would build handheld computers to use for collecting survey data.
Unfortunately, the technology was more complex to build than anticipated. After in-house development teams failed to produce the technology, the Census Bureau had to engage a vendor to finish building it. But the original failure left the vendor with only a year to finish the project before the required testing period.
In the end, the project wasn’t completed on time, and the Census Bureau had to request an additional $3 billion in funding to complete the 2010 census surveys on paper.
For large and/or complex IT projects, there are often multiple development teams involved. Sometimes dependencies are internal teams from other departments that own and manage specific platforms or services, and sometimes they’re vendor teams customizing a product or service the company purchased.
When other teams you’re dependent on fail to deliver on time, it can throw the project completely off track. In fact, dependency delays are a contributing cause of failure in 23 percent of failed projects.
The bottom line is that there’s not a lot you can do to rush other teams along and make sure they finish their part on time, but you can mitigate the risk with proper planning and estimation.
Dependency delays fall into the category of known unknowns. While you can’t be certain there will be a delay before it happens, you know there’s a chance that there might be a delay, so plan accordingly. Use the cone of uncertainty on estimates from other teams.
If they say it will take two weeks to deliver the changes you need, assume it could take up to two months, and plan accordingly. Have your team work on functionality that isn’t dependent on another team’s changes, or if that’s impossible, plan to wait until the other team finishes before beginning your work on the project.
In 2004, airplane manufacturer Boeing launched its Dreamliner project with the goal of creating an innovative, quieter, and more fuel-efficient airplane. Project leaders made the decision to outsource the majority of the design, engineering, and manufacturing work, leaving Boeing with the final task of integration and assembly.
Unfortunately, this decision led to numerous issues: vendor delays in delivering parts, a lack of documentation on how to assemble systems, and the receipt of fewer fasteners than needed. Because of these issues, Dreamliner shipped four years after the originally planned maiden flight, and the project cost twice the original estimate.
Project managers often use the word “resources” to refer to people, so “not enough resources” refers to not having enough people to complete the work for a project. It accounts for 22 percent of failed projects.
As discussed earlier, different project management methodologies have different fixed constraints. In Waterfall, it’s budget, meaning you have the funds to add as many people as needed to complete the work. In Agile, it’s scope, meaning you only commit to the amount of work that your existing team members can complete.
Projects that fail because there weren’t enough people are usually the outcome of trying to run projects where scope, budget, and timeframes are all fixed. It doesn’t work. One of those three constraints must be flexible to account for unexpected risks.
Lacking the proper resources should never be the cause of a failed project—it’s should only be the cause of a project that never got started. With proper planning, it should be obvious from the beginning that there aren’t enough people to complete the required amount of work within the requested timeframe.
The solution to this problem is simply making one of the three constraints of a project—time, budget, or scope—flexible.
If you have to deliver something within a certain timeframe and budget, commit to a smaller scope. If you have to deliver the full scope within a certain timeframe, wait for more resources before beginning work on the project. Attempting to set all three constraints in stone is an almost-certain path to failure.
When a project plan is going awry, the signs are obvious. Budget is being consumed too quickly, or teams are missing targets. But the signs are only obvious if someone is watching.
Creating a plan for a project isn’t enough. Someone must monitor the plan. That person can be a project manager, IT manager, or Scrum Master—who doesn’t matter as much as the fact that someone is monitoring progress.
Inadequate project management oversight accounts for 20 percent of failed projects. To prevent this cause of failure, you must have someone in charge of monitoring progress toward project goals.
If you assign someone with little-to-no project management experience, make sure to invest in some training before project kick-off. The type of training required is flexible. Have that person study long-term for a PMI certification, or simply ask him to spend a few days reading about the types of planning exercises used in Agile.
The Shared Services Transformation Programme was an IT project designed for use by the Department of Transport in the UK. When approved, the estimated cost for the project was £55.4 million, but it would save the department £112.4 million over ten years.
Unfortunately, multiple changes and unexpected complexities—combined with little project management oversight—caused delays and increased costs. By the time the problems became obvious, the cost of the project had increased to £121.2 million, while the anticipated savings for the department decreased to £40.1 million.
Because of poor project management, a project designed to save the department £57 million actually ended up costing it £80 million.
Accounting for 11 percent of failed projects, team member procrastination goes hand-in-hand with poor project management. If developers are procrastinating—or if the people the developers are depending on aren’t supplying answers, code, or services—it should be obvious that the project plan is headed off track.
In addition to monitoring the plan, the person in charge of overseeing the project must keep a record of issues and requests, and she must push those responsible to deliver.
Look for someone who’s detail-oriented, organized, and aggressive—but not aggressive in a bad way, just in a productive way. The project manager needs to be willing to escalate issues to the appropriate channels when necessary in order to resolve risks and impediments that—if unresolved—could lead to project failure.
IT projects that succeed do so by managing risks:
Mitigating the risks of IT projects is no small task. In fact, it’s really a lot of work. But the outcome is improved project success rates, ROI, and team morale—making all of the hard work worth it in the end.