case study of failed project

10 Failed Projects: Examples and How You Can Avoid Making the Same Mistakes

Looking at these famous failed projects examples through the lens of a project manager , we can learn how to spot issues before they have a chance to derail our plans — and avoid our own project failures in the future.

From Betamax to Crystal Pepsi, here are some high-profile projects that didn’t turn out as planned.

In this failed projects guide you will discover:

• Ten famous projects that failed
• Five ways to spot project failures before they happen
• Frequently asked questions

10. Sony Betamax

Sony launched its cassette recording device known as Betamax in the mid-1970s. It lost the battle for market share to JVC’s VHS technology, but Sony didn’t stop making Betamax tapes until 2016. In the age of online streaming, very few us realized it was still in production.

Lessons learned:

The story of Betamax has become nearly synonymous with failed marketing because while it was innovative and hit the market before its competition did, other products proved to be cheaper and better.

The lesson learned here is that project management doesn’t end when a project is launched, or a campaign has run its course. To stop your idea from hitting the ashpile of failed projects, remember to keep analyzing, and evaluating your products. That way, they can maintain their velocity and continue to benefit your bottom line.

9. New Coke

After testing a new recipe on 200,000 subjects and finding that people preferred it over the traditional version, Coca-Cola unveiled New Coke in 1985. That sounds like a safe move, right? Wrong.

Product loyalty and old-fashioned habit got in the way and people didn’t buy New Coke as expected, costing the company $4 million in development and a loss of $30 million in back stocked product it couldn’t sell and becoming one of the most famous failed project case studies in history.

While Coca-Cola certainly did market research, they missed the mark when it comes to assessing customer motivations. Customer input is imperative in development and for your project to be successful, you need to ensure you have a way to gather comprehensive customer insight that gives accurate and realistic information.

8. Polaroid Instant Home Movies

With the Polavision you could record video, develop it in a matter of minutes, and then watch it immediately! It was groundbreaking at the time, but the two-and-a-half-minute time limit, lack of sound, and the fact that you couldn’t watch the videos on your regular TV meant this project lasted just two years .

The Polavision was revolutionary, but Polaroid dropped the ball when they failed to stay abreast of developing marketing needs. When you keep your finger on the pulse of your market, you’re ready to innovate to meet its needs and avoid project failure.

7. Crystal Pepsi

Crystal Pepsi was a hit at first, and people were excited about the new version of an old favorite. But people soon lost interest and the novelty wore off, making it impossible for Crystal Pepsi to gain a strong market share.

David Novak was the COO of PepsiCo during the project and didn’t listen when bottlers told him the Crystal Pepsi flavor wasn’t quite right. “I learned there that you have to recognize that when people are bringing up issues, they might be right,” he later said .

6. McDonald's Arch Deluxe Burger

In 1996, McDonald’s put more than $150 million into advertising — more than it had ever spent on an ad campaign — for its new Arch Deluxe Burger, only to find out its customers weren’t interested in the more grown-up, sophisticated menu option.

This is another case that highlights the importance of letting customer data drive product strategy. If McDonald’s had a more accurate picture of what its customers wanted, it could have saved millions in advertising and resources.

A great way to stay on top of data is to choose a handful of key metrics to track , make sure your tools can accurately track them in as close to real-time as possible, and then always strategize based on the numbers.

5. Apple Lisa

Lisa, the first desktop with a mouse, cost $10,000 (almost $24,000 today) and had just 1 MB of RAM. Consumers weren’t as interested as Apple anticipated, and it was a case of overpromising and under-delivering , as the 1983 ads — featuring Kevin Costner — depicted the Lisa as much more than it really was.

Transparency matters. It may feel like a buzzword you hear all the time, but there’s no better way to describe the lesson learned here other than to say that Apple was not transparent enough about the Lisa.

We no longer live in an age where you can falsify the capabilities of a product because social media makes it easier for the truth to come out and word of mouth will eventually catch up to — and destroy — projects that lack transparency

4. Levi Type 1 Jeans

While we don’t know what Levi’s project management processes are like, one way to avoid confusion is to improve internal communications so the final product has a clear message and is easily understood by end-users.

To stop your project becoming a failure case study, avoid email and spreadsheets and instead, try an operational system of record to communicate, get status updates, and track document versions.

3. IBM PCjr

IBM released its PCjr in 1983 in an attempt to attract home computer users, but the PCjr offered fewer features than its competitors and was twice as expensive as an Atari or Commodore. After customers complained about the low-quality keyboard, IBM offered an alternative, which had its own issues, and couldn’t revive interest in the PCjr

IBM had the right approach when it listened to users and provided what they were asking for: a new keyboard. Unfortunately, its response wasn’t quite enough because the product was low quality and didn’t help improve users’ experience with the PCjr.

When you listen to your market, especially in times of crisis, it’s imperative that you hit it out of the park with your response in a way that not only saves your project but inspires even more brand loyalty with extremely satisfied customers.

2. The DeLorean DMC-12

Even the futuristic shape, gull-wing doors, and gold-plated models weren’t enough to save the DeLorean DMC-12, which experienced problems throughout production, giving it a rough start.

Then, John DeLorean, the company’s founder, was arrested in 1982 on drug trafficking charges he incurred while trying to raise money to save the business. Even though he was found not guilty, it was too late for the Marty McFly-famous car.

This one is still playing out but is a great example of leveraging nostalgia and coming back bigger and better. Or in this case, faster and more powerful.

In 2016, a new DeLorean was announced and then delayed due to some legal issues. However, things are back on track for an early 2019 release with an updated interior, more powerful engine, and faster speeds. In some cases, a do-over can tap into a niche market and bring a project back from the brink of failure for a successful refresh.

1. The Ford Edsel

The Ford Edsel is the perfect example of the importance of speed to market and how even a major brand and product can fail if a project loses velocity. Things like poor communication, inaccurate deadlines, and out-of-touch project managers can majorly slow a project down, to the point that it’s no longer relevant or valuable.

Robert Kelly , services solution executive, global accounts at Lenovo and project management expert explained the importance of maintaining an accurate project schedule: “Even with the best planning and collaboration, things happen. Make sure your project schedule reflects the actual and current reality of the project.”

Five ways to spot project failures before they happen.

When you read about project management failure case studies like these, it’s hard to see how the creatives and strategists who hatched the plans dropped the ball.

While the market is unpredictable and hindsight is always 20/20, there are a few common factors in failed projects that we can all learn from.

1. Low interest

People stop showing up for meetings. Stakeholders stop participating or giving timely feedback. Tasks stop getting completed on time. All of these are signs that interest in a project is flagging.

How to stop it: Keep communications as up to date as possible. Track all assignments. Hold all assignees accountable . If stakeholders stop caring about a project, hold a sit-down to determine the current perceived value of your project to the organization.

2. Poor communication

The team doesn't know when things are getting done, what's not getting done, or why it's not getting done. The project lead isn't communicating changes to the rest of the team. When communications do go out, they are either late or inaccurate.

How to stop it: While email and spreadsheets are okay for getting basic information out, they tend to be slower and more cumbersome than the typical fast-moving team needs. Consider purchasing tools like Adobe Workfront that automate communications as much as possible.

3. Lack of velocity

Assignments are long past due, stalled on the approval of an elusive stakeholder. Maybe team members are spending more and more time on other projects. At any rate, contrary to your best projected completion dates, your project has come to a full stop.

How to stop it: See the solution to lack of interest. Accountability is especially key here. Ensure that everyone is aware of their assignments and their due dates and then press them to meet them. If stakeholders are holding a project up, call them, if possible, to find out if there are any issues.

4. A “no bad news” environment

Individual reports in meetings are especially rosy and don't match the chaos that seems to be engulfing a project. Staff members avoid questions asking for progress updates and project leaders seem to be in the dark about why tasks are being done late, or not at all.

How to stop it: Let numbers rule. Your team should be guided by a handful of key metrics that you can track, such as on-time delivery rate. And then make sure your tools can accurately track those metrics in as close to real time as possible.

5. Scope creep

The project starts to barely resemble the requirements as they were given at its outset. Timelines have stretched beyond the original projections. The phrase, "You know what would be really cool would be if we added ________," is uttered during the review and approval phase. This is scope creep — and you need to avoid it.

How to stop it: Use an airtight requirements gathering process before the project starts. In fact, don't even allow the project to start until you, your team, your stakeholders, and your requestor are all on the same page. And then treat that requirements doc like a binding contract.

In the end, the best way to avoid project failure (and embarrassing flops) is to stay one step ahead of your project and keep safeguards like these in place, so you can quickly pivot, producing a successful outcome regardless of what obstacles may arise.

Frequently asked questions about project failures.

What is a failed project?

A project can be seen as a failure when it doesn’t achieve its objectives. This doesn’t just mean overall goals – a failed project could be something that went overbudget, over deadline or lost the support of its staff and stakeholders. By thoroughly planning your project and monitoring from start to finish, you can help ensure your project is a success.

What can we learn from a failed project?

Plenty! The main thing to take away is that these projects fell mainly because of poor communication along the way. Setting up your projects to automate as much of your communication as possible is key, and having everyone aware of certain key metrics will ensure positivity and morale is always high.

How do I recover from a failed project?

Having one failed project does not mean your company or idea is a failure. Learn from the mistakes made in the project that failed and start from the beginning, making those all-important changes along the way.

• Contact sales

Start free trial

12 Notorious Failed Projects & What We Can Learn from Them

Failure is an unavoidable part of any project process: it’s the degree of failure that makes the difference. If a task fails, there are ways to reallocate resources and get back on track. But a systemic collapse will derail the whole project.

Why Is It Important to Analyze Failed Projects?

What good can come from failure? A lot, actually. Sometimes a project reaches too far beyond its means and fails, which is unfortunate but can also serve as a teaching moment. If project managers don’t learn from their mistakes, then they’re not growing professionally and will revisit the same problem in future projects.

Project managers can learn as much, if not more, from failed projects as they can from successful ones. A post-mortem analysis should be part of any project plan, and especially so when a project crashes and burns. There are valuable lessons in those ashes.

One lesson is that project management software decreases the chance of a failed project. ProjectManager is award-winning project management software that allows you to monitor your work in real time to make more insightful decisions that can keep failure at bay. Use our real-time dashboards to track the health of your project, including such important key performance indicators (KPIs) as time, cost and more. There’s no time-consuming setup required as with lightweight software. Our dashboard is ready when you are. Get started with ProjectManager today for free.

12 Top Failed Projects from History

Let’s look at the most notorious failed projects, not to gloat, but to see what they can tell us about project management .

1. Sony Betamax

The word Betamax has become almost synonymous with failure. But when it was first released, Betamax was supposed to become the leader in the cassette recording industry. Developed by Sony, Betamax was introduced in the mid-1970s but was unable to get traction in the market, where JVC’s VHS technology was king.

Surprisingly, Sony continued to produce Betamax all the way into 2016. Long before it discontinued the technology, Betamax was already irrelevant.

Betamax was an innovative product, and it even got to market before VHS. But soon the market had options that were cheaper and better than Betamax, making it a failed project. Sony’s mistake was thinking that the project was complete once the product went to market . Project managers need to always follow up on their work, analyze the data and make an evaluation about what needs to be done to keep the project relevant.

2. New Coke

Coca-Cola is one of the most iconic brands in the world. It’d take a lot to tarnish that reputation. But that’s just what happened when New Coke was introduced in 1985. People didn’t know why the Coke they loved and drank regularly was being replaced.

The company knew why. They were looking to improve quality and make a splash in the marketplace. The fact is, New Coke sunk like a stone. It wasn’t like New Coke was just released without doing market research , though it might seem that way. In fact, the new recipe was tested on 200,000 people, who preferred it to the older version.

But after spending $4 million in development and losing another $30 million in backstocked products, the taste for New Coke evaporated. Consumers can be very loyal to a product, and once they get into a habit, it can be very difficult to break them off it in favor of something different.

It’s not that Coca-Cola neglected market research to see if there was a need to develop a new product, but they were blind to their own customers’ motivations. New Coke was a failed project because the researchers needed to do more than a mere taste test.

They needed to understand how people would react when the familiar Coke they loved would be discontinued and replaced by a shiny new upstart. Market research must be handled like a science and an art—and worked into the project plan accordingly.

3. Pepsi Crystal

In 1992, Pepsi launched Pepsi Crystal. It was a unique soft drink in that there was no color. It was as clear as water. Pepsi hoped to take advantage of the growing trend for purity and health. Pepsi marketed the new drink as pure, caffeine-free and an alternative to the unhealthy traditional colas.

At first, sales looked good. The first year saw about $470 million in sales. Consumers were curious to find out if the taste was the same as Pepsi, which it was. Other colorless soft drinks started to introduce themselves to the market, such as 7Up and Sprite. But what Pepsi and the copycats didn’t take into account was how much sight influences flavor. Consumers found the product bland and sales tanked.

Pepsi Crystal was mocked on Saturday Night Live and Time Magazine listed it in its top-10 marketing failures of the 20th century.

Pepsi made the mistake of ignoring all the senses that are involved in the consummation of their product. They should have done more testing. If so, they would have realized the importance of the look of the product. Pepsi Crystal thought that a clear-looking liquid would indicate a healthy one, but what was registered by the majority of users was a bland one.

4. Ford Edsel

Ford released its Edsel model in 1957. Since then, the name has become synonymous with project planning failure. That’s an accomplishment, but not the type that Ford was hoping for. This was supposed to be the car for the middle class and Ford invested $250 million into the Edsel.

Ford ended up losing $350 million on the gas-guzzler that the public found an unattractive alternative to other cars on the market. Part of the problem was that the first Edsels had oil leaks, hoods that stuck, trunks that wouldn’t open and more issues that soured consumer confidence in the product.

The Ford was a lesson in egos at the company ignoring what the research was telling them. Ford conducted many polls to find out what Americans wanted in a car, including a name. But executives went with Edsel. The design of the car didn’t even consult the polls.

If you’re going to do polling on what the public wants, it is a poor decision to ignore that data . So much time and effort went into coming up with the name, even hiring modernist poet Marianne Moore (who came up with nothing marketable), that Ford neglected to determine if there was even a market for this new car.

5. Airbus A380

Boeing’s Airbus A380 was viewed as a way for the company to outdo the 747. It spent more than $30 billion on product development in the belief that the industry would embrace a bigger plane that could hold more passengers and increase revenue.

In fact, the Airbus A380 has sold well short of its predicted 1200 units. The plane was headed for the scrap heap as it faced obstacles such as airports having to build special infrastructure and gates to accommodate that massive plane. Those project costs would be handed back to the airlines. That’s going to sour the deal and it did.

Then there were the technical issues. Qantas had to ground its entire A380 fleet after an engine blew up. You’d think that engineers would have thought beyond having more passengers seated on a bigger plane. But they didn’t.

The biggest lesson is that just because you build it doesn’t mean that anyone is going to want it. There wasn’t the demand Boeing believed there to be. Industries and markets are fickle. Just because airlines say they want something today doesn’t mean they’ll want it tomorrow. Boeing should have hedged its bets.

6. World Athletics Championships 2019

Doha is the capital of Qatar and the site of the World Athletics Championships in 2019. The world’s best athletes went there to compete against one another, but the big event turned out to be an even bigger dud.

The problem was that the host nation was unable to sell most of the tickets to the event. Some of the greatest athletes in the world were forced to compete in stadiums that were nearly empty. It was a failure and an embarrassment.

Money is needed to plan for an event , but that investment is no guarantee that people will show up. The mistake was thinking there was a large enough fanbase to sell all the tickets. We keep coming back to this, but it deserves to be mentioned again: research is critical. It wouldn’t have taken much to determine if there were enough interested people to bring a return on the investment.

7. Garden Bridge

Vanity projects tend not to care about success or failure. They’re driven by ego and such was the case with the Garden Bridge. It was the brainchild of Boris Johnson when he was Mayor of London.

This construction project cost 53 million pounds, which is a lot of money, especially when considering it was never even built. The idea of a bridge made of gardens for city dwellers to enjoy is fine, but the over-optimistic fundraising targets and the ballooning costs led to its spectacular failure.

Projects must be realistic. It’s good to remember SMART goals , which is an acronym for specific, measurable, achievable, relevant and time-bound. If the project followed those constraints it might have been built or passed on before all that money was spent.

8. Apple Lisa

Before Apple became synonymous with the personal computer (and long before popular products such as the iPhone), it released Lisa. It costs $10,000 with a processor of 5 MHz and 1 MB of RAM. The first model sold only 10,000 units.

Lisa was fated to fail because it was really a prototype. It was marketed as a game-changer in 1983 from its popular, but command-line-based Apple II. The price is certainly one reason why this was not a realistic personal computer, but there were technical issues. It had an operating system that could run multiple programs but was too powerful for its processor. Lisa ran sluggishly.

The truth is Lisa was less a failure than an expensive lesson. Lisa led to the Macintosh, which was basically a less expensive and more effective version of Lisa. The lesson here is that one can learn from failure if it doesn’t bankrupt the company, that is.

9. Dyson Electric Car

After four years and millions of dollars, James Dyson canceled his electric car project. It took that long to realize it wasn’t commercially viable. There is certainly a growing market for electric cars as the industry is motivated by consumers and government regulations to move from fossil fuels to more energy-efficient and sustainable alternatives.

There’s a boom in the production of electric cars, from major manufacturers such as Chrysler and Ford to startups such as Tesla. But sometimes the time isn’t right and no matter how good the idea is, it’s just not meant to be.

Timing is everything. But it’s also important to note how difficult it is to penetrate a market with established players. It takes a lot of capital and manufacturing expertise to start a car company and be competitive.

Related: 10 Free Manufacturing Excel Templates

10. Stretch Project

The Stretch project was initiated in 1956 by a group of computer scientists at IBM who wanted to build the world’s fastest supercomputer. The result of this five-year project was the IBM 7030, also known as Stretch. It was the company’s first transistorized supercomputer.

Though Stretch could handle a half-million instructions per second and was the fastest computer in the world up to 1964, the project was deemed a failure. Why? The project’s goal was to create a computer 100 times faster than what it was built to replace. Stretch was only about 30-40 times faster.

The planned budget was $13.5 million, but the price dropped to $7.8 million; so the computer was at least completed below cost. Only nine supercomputers were built.

While the project was a failure in that it never achieved the goal it set, there was much IBM could salvage from the project. Stretch introduced pipelining, memory protection, memory interleaving and other technologies that helped with the development of future computers.

Creative work is rooted in failure specifically because of the serendipitous discovery that occurs. This was a creative project, which might not have met its paper objective, but created a slew of useful technologies. So, aim for your goal, and who knows what good things you’ll discover along the way.

Get your free

Lessons Learned Template

Use this free Lessons Learned Template for Excel to manage your projects better.

11. Challenger Space Shuttle

The worst failure is one that results in the loss of life. When you’re dealing with highly complex and dangerous projects like NASA, there’s always a tremendous risk that needs to be tracked . On January 28, 1986, that risk became a horrible reality as the space shuttle Challenger exploded 73 seconds after launch.

The cause was a leak in one of the two solid rocket boosters that set off the main liquid fuel tank. The NASA investigation that followed said the failure was due to a faulty designed O-ring seal and the cold weather at launch, which allowed for the leak.

But it was not only a technical error that NASA discovered but human error. NASA officials went ahead with the launch even though engineers were concerned about the safety of the project. The engineers noted the risk of the O-ring, but their communications never traveled up to managers who could have delayed the launch to ensure the safety of the mission and its astronauts.

Managers are only as well-informed as their team. If they’re not opening lines of communication to access the data on the frontlines of a project, mistakes will be made, and in this case, fatal ones.

12. Computerized DMV

No one loves the DMV. If they were a brand, their reputation would be more than tarnished, it’d be buried. But everyone who drives a vehicle is going to have some interaction with this government agency. Unfortunately, they didn’t help their case in the 1990s when the states of California and Washington attempted to computerize their Departments of Motor Vehicles.

In California, the project began in 1987 as a five-year, $27 million plan to track its 31 million drivers’ licenses and 38 million vehicle registrations. Problems started at the beginning when the state solicited only one bid for the contract, Tandem Computers, locking the state into buying their hardware.

Then, to make things worse, tests showed that the new computers were even slower than the ones they were to replace. But the state moved forward with the project until 1994 when it had to admit failure and end the project. The San Francisco Chronicle reported that the project cost the state $49 million, and a state audit found that the DMV violated contracting laws and regulations.

The problem here is a project that isn’t following regulations. All projects must go through a process of due diligence, and legal and regulatory constraints must be part of that process. If the state had done that and the contract bidding process invited more than one firm to the table, then a costly mess could have been avoided, and our wait at the DMV might actually have become shorter.

How ProjectManager Prevents Failed Projects

ProjectManager keeps your projects from failing with a suite of project management tools that shepherd your project from initiation to a successful close. Plan, schedule and track work, while managing teams, with our online software.

Plan Every Last Detail

Successful projects begin with a strong plan. But it can be hard to keep all those tasks and due dates working together on a realistic schedule. What if some tasks are dependent? It gets complicated. But ProjectManager has an online Gantt chart that plots your tasks across a project timeline, linking dependencies and breaking projects into digestible milestones.

Track Progress as It Happens

ProjectManager keeps you on track with high-level monitoring via its real-time dashboard and more detailed data with one-click reporting . Now when projects start to veer off-track, you can get them back on course quickly.

While we didn’t have an example, there are many projects that fail because they’re not equipped with the right tools for the job. ProjectManager is online project management software that gives project managers and their teams everything they need to plan, monitor and report on their project. Don’t let your next project fail; try ProjectManager with this free 30-day trial .

Deliver your projects on time and under budget

Start planning your projects.

Gustavo’s The Business Automator

The Anatomy of a Failed IT Project: Case Studies and Lessons Learned

Failure is an uncomfortable word. However, it's important to remember that failure is not the end but rather a learning opportunity , in IT and Project Management, understanding what went wrong can often be as valuable as knowing what goes right. This blog post aims to dissect my real-world cases of failed IT projects to extract actionable lessons for future endeavours.

The Importance of Studying Failures

Before diving into my case studies, let me address a crucial question:

Why should we study failures?

The simple answer is to avoid making the same mistakes, when we understand the reasons behind a project's failure, we're better equipped to mitigate those issues in future projects; the goal is not to blame nor point to anyone but to understand, adapt, and improve.

Case Study 1: Scope Creep

Let's start with a project that was initially scoped to develop a Customer Relationship Management (CRM) system for a mid-sized company within six months.

What Went Wrong

As the project progressed, additional features were requested, the client's demands changed and suddenly the team was overwhelmed. Deadlines were missed, and the budget ballooned.

Lessons Learned

The primary lesson here is the importance of a well-defined project scope. Any changes to the scope should be carefully considered , involving all stakeholders, and adjustments to resources and timelines should be made accordingly.

Case Study 2: Poor Communication

This case involves a project aimed at implementing a new security infrastructure for a financial institution.

The project suffered from a lack of clear communication. Requirements were misunderstood, leading to incorrect implementations and eventual rework. Critical updates were not effectively communicated to all team members for “watertight compartments“ causing further delays.

Effective communication is the backbone of any successful project. Regular team meetings, clear documentation, and established communication protocols can prevent many issues related to misunderstandings or lack of information.

Case Study 3: Inadequate Risk Management

This case study focuses on a software development project for a healthcare provider.

The project did not have a comprehensive risk management plan. When the team encountered issues like third-party API limitations and unexpected data privacy concerns, there were no contingency plans in place.

Risk management is not a one-time activity but a continuous process. Always have contingency plans for identified risks and update your risk assessments as the project progresses.

Common Themes

After examining these case studies, some common themes emerge, lack of planning and foresight, poor communication and inadequate risk management, but actually there are different common reasons:

Scope Creep

The project starts with a well-defined scope, but as it progresses, additional features or functionalities are added, usually without sufficient adjustments to the budget or timeline.

Poor Communication

A lack of clear, effective communication among stakeholders, team members, and clients can lead to misunderstandings, delayed decisions, and ultimately, project failure.

Inadequate Requirements

Often, project specifications are either too vague or incomplete. This ambiguity can result in a final product that does not meet the needs of the end-users.

Lack of User Involvement

Ignoring the needs and feedback of the end-users during the project can result in a product that is misaligned with market needs.

Technical Debt

Cutting corners in coding or design and/or project management might save time initially but usually leads to more work in the long term , as these issues need to be resolved later.

Overconfidence

Underestimating the complexity of a project or overestimating the team's capabilities can set the project on a path to failure from the outset.

Launching the project at a time when the market or the organization is not ready can doom even a well-executed project.

Resource Constraints

the worst one, the final conclusion: running out of time, money, or manpower can halt a project in its tracks.

My suggestions

To avoid the pitfalls highlighted in these case studies, consider the following recommendations:

Effective Planning: Ensure the project scope is well-defined and agreed upon by all stakeholders.

Clear Communication: Establish robust communication channels and protocols.

Continuous Risk Assessment: Regularly update your risk assessments and have contingency plans in place.

Remember, the goal is not to blame but to learn. As Project management giant Harold Kerzner once said:

Project management is not about managing projects but about managing expectations.

Understanding the reasons behind failures helps us set realistic expectations and equips us to manage future projects better.

Literature and more info

- Project Management Institute (PMI)

- Scrum Training

- Risk Management Guidelines

Gustavo’s The Business Automator is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Ready for more?

• Resource Portfolio Management
• What-If Scenario Planning
• Integrations for Resource Management
• Strategy Execution
• Strategic Portfolio Management
• Adaptive Project Management
• Resource Management Capabilities: Tempus Resource
• HR Workforce Agility
• Audit Resource Management
• Tempus Insight+
• Portfolio Kanban
• Program & Project Management
• Project Financial Management
• Business Intelligence Project Management Reporting
• Project Management Spreadsheets
• Resource Management
• Resource Forecasting Tools and Techniques
• Resource Management Request Workflows
• Skills & Competency Management
• Scenario Planning
• Project Scheduling
• Microsoft Project Add-In
• Project Intake
• Case Studies
• Infographics
• Press Releases
• Whitepapers
• Help Center
• In the News

4 Famous Project Management Failures and What to Learn from Them

October 8, 2018 | by greg bailey.

Every project begins with a single idea or goal, and the best of intentions. But as they progress, mistakes are made, communications break down, and deadlines and budgets change. It’s these problems that mean, even when projects are started for the right reasons,  55% of businesses experience failed projects. In fact, 17% of large-scale IT projects  go so badly that they threaten the very existence of the company.

Why do projects fail? And what leads to a failed project? This post will look at some project failure examples, including the worst-case scenarios, to identify the root cause of the problem, in the hope that we can ensure project managers don’t make the same fatal mistakes.

1. Ford Edsel

Ford Edsel is one of the most spectacular project failure examples in automotive history. Ford ’s team did extensive market research before it released the Edsel , even doing studies to make sure the car had the right ‘personality’ to attract the ideal customer . They spent 10 years and $250 million on research and planning—but by the time all this was completed, and the car was unveiled in 1957, Ford had missed its chance. The market had already moved on to buying compact cars, which didn’t include the Edsel.

Lessons learned: The Ford Edsel is the perfect fail project example that emphasizes the importance of speed to market and how even a major brand and product can fail if a project loses velocity. Poor communication and inaccurate deadlines can slow a project down to the point where it’s no longer relevant or valuable,  let alone successful.

Paying ultimate attention to areas like resource availability and utilization—ensuring project workers are working to capacity and to the best of their ability—creates more accurate project timeline estimations and stops projects from dragging.

2. NHS Civilian IT

Back in 2007, the UK’s National Health Service (NHS) looked to revolutionize the way technology is used in the health sector, through the introduction of electronic health records, digital scanning, and integrated IT systems across hospitals and community care. They called it the ‘Civilian Computer System. ’ It would have been the largest of its kind in the world. But it failed because of contractual changes—including changing specifications, supplier disputes, and technical problems. Estimates of the cost of the now-abandoned project hover around the £11.4 billion mark.

Lessons learned: Change is almost inevitable during the course of a project, especially with large and complex ones like the NHS undertook. This is one of the most talked-about project failure examples that shows the importance of flexibility for achieving great results. You need to be able to react to changes as they occur, but also preemptively identify potential problems in order to stop them before they wreak havoc.

Project and resource modeling allows project managers to create a model where they can test, in real-time, the effects of changing or modifying their projects to keep ahead of schedule. So even in the event of unexpected changes, you’re prepared for what’s next.

3. Airbus A380

Building the Airbus A380—the world’s largest commercial aircraft at the time—required production facilities from across the globe to build individual parts of the airplane. Unfortunately, these teams used different computer-aided design (CAD) programs. During installation, they discovered the parts designed by different teams didn’t fit together. This cost the company $6 billion to put right and set the project back two years.

Lessons learned: The Airbus A380 is one of those failed projects examples that teach you the importance of proper workforce coordination. Unexpected problems will always be a challenge, but there are added challenges when your workforce is based remotely or in silos. For instance, it can take longer to report problems and coordinate the right response. If Airbus’s dispersed project teams had better-prioritized communication, the problem could have been solved before the installation phase, before it was too late.

When teams work across geographies, it’s important to set goals and metrics to ensure everyone understands their tasks, like what they’re expected to achieve and when. Resource management allows you to manipulate resource data in real time, so, if something goes wrong, the problem can be resolved as soon as possible. Using remote workers makes it difficult to gather everyone in a room, explain the problem, and find the solution. Resource management tools provide real-time reporting for full visibility over your resources, so you can instantly enact change.

4. Knight Capital

In 2012, when Knight Capital was brought on to work on new code for a new SEC program, an over-optimistic deadline caused them to go to production with test code. After production, a glitch cost the company  $440 million within the first 30 minutes of trading , and company stock fell 75% within just two days.

Lessons learned: You need a granular-level view of your projects to forecast how long a project will feasibly take to complete and avoid setting unrealistic targets or deadlines. Resource management is crucial in analyzing and utilizing project resources, so projects can be completed as efficiently as possible without the need to rush work or take shortcuts.

Avoid famous project management failure with resource management

The project failure examples listed above were carried out on a monumental scale—involving a sea of moving parts and relied on a lot of people to complete. While no project can guarantee success, resource management can help measure and manage the moving parts of a project. The right resource management solution can help a project manager gain more control over their projects , providing insight into every step of the process .

Tempus Resource is a sophisticated resource management software that includes practical functionality like modeling, forecasting and ‘What-If?’ analysis. Tempus Resource can help organizations of any size and any level of project maturity reduce the risk of project failure.

To find out more on how resource management can reduce the risk of project failure,  get in touch with ProSymmetry today .

Subscribe to our Blog

Be the first to know when we post new content!

Ready to get started?

Related resources:, the best kpis for resource management.

Key Performance Indicators (KPIs) are one of the best ways to make…

Tempus Resource User Community

We are thrilled to introduce a brand-new hub created exclusively for our…

Secrets to Strategic Portfolio Delivery

Strategic planning and execution has become a central part of the portfolio…

What is Audit Resource Management?

Internal audits are a complex process with a plethora of moving parts…

ProSymmetry LLC

2000 Auburn Drive, Suite 460

Beachwood, OH 44122

© 2024 ProSymmetry. All Rights Reserved

Project Management Nerd

Project Management and Productivity

10 Project Failures That Stunned the World

The world has witnessed its fair share of project failures in the ever-evolving landscape of innovation and ambition. These grand endeavors, often pursued with the utmost determination, have sometimes crumbled in the face of unforeseen challenges.

Let’s embark on a journey to explore the stories of these failures. From the iconic Sydney Opera House, a modern architectural masterpiece fraught with budget overruns and structural challenges, to the Betamax, Sony’s once-revolutionary but ultimately defeated video format. And then, consider the bold decision by Coca-Cola to change its sacred recipe.

These projects have left an indelible mark in the annals of history. Join us as we delve into the riveting tales of these and more, examining the lessons they impart in the volatile world of innovation, ambition, and, sometimes, spectacular project failure.

1. Sydney Opera House

the Sydney Opera House is one of the icon architecture pieces in the world however it also one of the biggest project failures in history.

 In project management there are three significant constraints to any project that need to be considered. They are the triple constraints of time or scheduling, the cost of the project and the scope. The time and cost constraints are self-explanatory, however what is meant by the scope of a project are the deliverables required to make the project come to life. Essentially it provides the vision for the project. What is important to remember is that changes in one constraint will have a ripple effect on one or both of the other constraints.

Unfortunately, in the case of the Sydney Opera House there was no defined scope. No clear deliverables in place led to a massive blow out in both time and cost. In fact the cost of the project ended up being 15 times more than was originally budgeted and took 10 years longer. It serves as one of history’s greatest project failures.

The Betamax device was an analogue video recording device that was first brought to the United States in 1975. It enjoyed a first to market advantage for around 12 months before the Japanese Company JVC introduced the VHS version. It was the VHS version that began to take the market share due to its cheaper pricing. In fact, by 1980 JVC had 60% market share in the U.S. which enabled economies of scale that allowed VHS units to flood the European market at greatly reduced pricing.

Enjoying this article?

Get the PM Nerd’s weekly roundup on project trends, productivity and news

Delivered Thursday evenings. Unsubscribe at any time.

The Betamax project is a great example of a project that didn’t know when to close. In fact it was still producing consoles in 2002 and only stopped making cassettes in 2016. The unwillingness to let go of this product was one of the reasons for Sony losing overall market share to its competitors.

Further Reading| PMBOK Principle 8 -BUILDING QUALITY |

3. New Coke

In an effort to turn around the declining sales of Coca Cola, and a series of blind taste tests indicating that consumers preferred Pepsi, the decision was made to change the coke recipe.

The project was very secret and was code named ‘Project Kansas’. A significant red flag that was ignored during the testing phase was that 10-12% of survey respondents said they would be angry if Coke changed their recipe and that they may stop drinking the brand all together.

It was also the decision by management who didn’t want to release the product as alternative to Coke rather replacing the original all together.

Their was some initial success as consumers wanted to try the new recipe. This was quickly replaced by resentment particularly in the Southern states of the U.S. It was viewed by many in those regional areas as part of their identity and there was a feeling of surrendering to the enemy.

It took just 79 days after the New Coke was introduced for the old recipe to be re-instated. Less than 6 months later the original formula Coke was increasing its sales by more than twice as much as its main competitor Pepsi. In terms of project failures, the change of the Coke recipe served as one its greatest lessons.

Further Reading | Project Quality Management |

4. Delhi Commonwealth Games Bridge Collapse

The XIX Commonwealth Games were to be held in Delhi India in 2010. The lead up to the event saw major concerns from officials and competing countries regarding the slow pace of work. Problems such as corruption from Games Organising Committee officials, infrastructure compromise, the threat of terrorist attack and poor ticket sales. A significant concern were the delays in the construction of the main Games venues.

The response from the Organising Committee six weeks out from the opening of the games was to increase the workforce significantly. This resulted in a huge increase in tasks completed but also with a lack of training mistakes were bound to occur.

The concerns regarding the poor workmanship materialised on September 21, 2010 when a footbridge joining the Athletes village with the Jawaharlal Nehru Stadium collapsed injuring 23 people. This provides a classic case study of a project management scheduling strategy called fast tracking. Essentially to get tasks completed quickly the amount of labour is increased significantly. The problem is that quality reduces and disasters like the Delhi Bridge collapse can occur.

Further Reading | How to manage a saboteur in your team |

5. Waterworld

The Water World movie is a post-apocalyptic film starring Kevin Costner and distributed by Universal Pictures.

The most expensive movie ever made at the time, Waterworld is a great case study on how scope creep can impact time and cost on a project.

At the time the film was due to begin a completed script had not been authorised. This gave rise to many re-writes and changes which continued to raise costs and extend the timeline. Universal had initially authorised a budget of $100 million however the final cost of the film was pushed out to $175 million.

Unfortunately the film was not well received at the box office and ticket sales were not enough to recoup expenses.

Further Reading | How to Promote Team Collaboration in Your Organisation |

6. European Super League

In one of the biggest blunders in football administration history twelve of the top European football clubs announced they were breaking away to form a new competition. The competition was announced on April 18, 2021 and was withdrawn just two days later due to a huge outcry from the club’s biggest stakeholders its fans.

One of the immediate concerns from the football community was that in the new league relegation would not take place. This would remove one of the key elements in European leagues. Concerns came from fans, governing bodies and even European government leaders.

The project failed miserably because the owners of the clubs missed a key component of any project – stakeholder consultation. Engaging with the stakeholders early would have prevented the embarrassment that came with this decision and the cringeworthy apologies that came afterwards. Notably it was the German clubs that did not opt in to the new competition and underscores the close relationship they have with their most important stakeholders.

Club owners still have not learned from one of the most significant sporting project failures as rumours of a new model continue to swirl.

Further Reading | What is the difference between a leader and a project manager? |

7. The Delorean DMC-12

Made famous in the Back to the Future movie franchise the Delorean is still an iconic car today.

The Delorean company was in trouble even before the first car rolled off the construction line. After the company was given a great deal to setup their manufacturing plan in Belfast, a Northern Ireland consulting company gave Delorean a 1 in 10 chance of surviving.  

Design issues were the first problems to surface with the original rotary being replaced by a Peugeot V6. The larger engine couldn’t fit into the tiny space and significant changes were required.

With an inexperienced factory workforce, increasingly delayed production schedules and a CEO that has been arrested on drug charges the car stopped production after 9,000 units were made. This may seem like a large number however it wasn’t enough to save the company and it was wound up in the early 1980s.

Further Reading | The importance of setting goals |

8. IBM’s Stretch Project

The IBM 7030 which was also known as stretch was the world’s first fully transistorized supercomputer.

At the design stage the thought was to make a computer that was 100-200 times faster than its nearest competitor. Unfortunately the complexity of the project and delays in production meant it was only 30 times faster than its competitors. This was seen as project fail at IBM.

The lessons learned were absorbed into IBM and this project fail helped launch other successful products such as the IBM System/360 which were shipped to customers in 1964.

9 The Dyson Electric Car

A team of around 400 people were working on a very secretive electric car project that was due to be released in 2021. Seen as a possible competitor to Tesla the project was pulled before a unit had even been constructed.

The Dyson company is famous for producing a range of high end good value home appliances. The company is privately owned by James Dyson and he took a different approach to the project development.

Building cars is quite different to building vacuum cleaners and a lot of due diligence is required to move into this completely new challenge. This was lacking and an email to all his staff – numbering in the range of 7,000 were informed then that the project wouldn’t be going ahead.

Although close to getting it mass-produced, the cost of the inputs would have meant a price that made the car commercially unviable. It is understood that James Dyson personally absorbed the cost of the project failure and would continue to work on the battery technology developed through the development phase. This shows that lessons learned from project failures can be incredibly valuable.

Further Reading | PMBOK Principle 9 – NAVIGATING PROJECT COMPLEXITY |

10. London City – Garden Bridge

A design originally submitted by Joanne Lumley from Absolutely Fabulous fame, the Garden bridge was designed to be an elevated garden footbridge crossing the Thames joining Lambeth in the South and Victoria embankment in the North.

The project gained traction when Mayor and later Prime Minister Boris Johnson took some interest in it. However, when Boris Johnson’s successor Sadiq Khan replaced him as Mayor the true nature of the fragile financial foundation funding the bridge became clear.

The project was stopped before even a piling had been driven into the ground. One of the problems with this project was the unclear vision for what the bridge was for. Everyone agreed it would look nice but nice wouldn’t cut it when millions of pounds were at stake.

The lack of clarity of the project meant that stakeholder consultation was minimal and there was no real clear business case or consideration of ongoing maintenance of the bridge.

Before the project was quashed by the Mayor costs were already rising significantly with 1.7 million pounds being paid to a board and also significant website costs.

Another project where due diligence and clarity of scope were missing.

Further Reading | PMBOK Principle 8 -BUILDING QUALITY |

In the end, these project failures serve as more than just cautionary tales; they are invaluable sources of insight and wisdom. They remind us that even the most audacious dreams can falter when faced with unexpected challenges. The Sydney Opera House, Betamax, and Coca-Cola’s recipe change all echo the resounding message that innovation carries both the promise of greatness and the potential for missteps.

As we conclude our exploration of these project failures, we’re left with a profound appreciation for the resilience of the human spirit. We learn from these setbacks, adapt, and move forward, ever more determined to push the boundaries of what is possible. In the world of projects and initiatives, project failures, though stunning, are stepping stones to future success.

Share this:

One thought on “10 project failures that stunned the world”.

• Pingback: The 5 Biggest Abandoned Megaprojects in the World - Project Management Nerd

Leave a Reply Cancel reply

Discover more from project management nerd.

Subscribe now to keep reading and get access to the full archive.

Type your email…

Continue reading

• Generative AI
• Office Suites
• Collaboration Software
• Productivity Software
• Augmented Reality
• Emerging Technology
• Remote Work
• Artificial Intelligence
• Operating Systems
• IT Leadership
• IT Management
• IT Operations
• Cloud Computing
• Computers and Peripherals
• Data Center
• Enterprise Applications
• Vendors and Providers
• Enterprise Buyer’s Guides
• United States
• Netherlands
• United Kingdom
• New Zealand
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Copyright Notice
• Member Preferences
• About AdChoices
• E-commerce Affiliate Relationships
• Your California Privacy Rights

Our Network

• Network World

IT’s biggest project failures — and what we can learn from them

Think your project's off track and over budget learn a lesson or two from the tech sector's most infamous project flameouts..

Every year, the Improbable Research organization hands out Ig Nobel prizes to research projects that “first make people laugh, and then make them think.”

For example, this year’s Ig Nobel winners , announced last week, include a prize in nutrition to researchers who electronically modified the sound of a potato chip to make it appear crisper and fresher than it really is and a biology prize to researchers who determined that fleas that live on a dog jump higher than fleas that live on a cat. Last year, a team won for studying how sheets become wrinkled.

That got us thinking: Though the Ig Nobels haven’t given many awards to information technology (see No Prize for IT for reasons why), the history of information technology is littered with projects that have made people laugh — if you’re the type to find humor in other people’s expensive failures. But have they made us think? Maybe not so much. “IT projects have terrible track records. I just don’t get why people don’t learn,” says Mark Kozak-Holland, author of Titanic Lessons for IT Projects (that’s Titanic as in the ship, by the way).

When you look at the reasons for project failure, “it’s like a top 10 list that just repeats itself over and over again,” says Holland, who is also a senior business architect and consultant with HP Services . Feature creep? Insufficient training? Overlooking essential stakeholders? They’re all on the list — time and time again.

A popular management concept these days is “failing forward” — the idea that it’s OK to fail so long as you learn from your failures. In the spirit of that motto and of the Ig Nobel awards, Computerworld presents 11 IT projects that may have “failed” — in some cases, failed spectacularly — but from which the people involved were able to draw useful lessons.

You’ll notice that many of them are government projects. That’s not necessarily because government fails more often than the private sector, but because regulations and oversight make it harder for governments to cover up their mistakes. Private enterprise, on the other hand, is a bit better at making sure fewer people know of its failures.

So here, in chronological order, are Computerworld ‘s favorite IT boondoggles, our own Ig Nobels. Feel free to laugh at them — but try and learn something too.

IBM’s Stretch project

In 1956, a group of computer scientists at IBM set out to build the world’s fastest supercomputer. Five years later, they produced the IBM 7030 — a.k.a. Stretch — the company’s first transistorized supercomputer, and delivered the first unit to the Los Alamos National Laboratory in 1961. Capable of handling a half-million instructions per second, Stretch was the fastest computer in the world and would remain so through 1964.

Nevertheless, the 7030 was considered a failure. IBM’s original bid to Los Alamos was to develop a computer 100 times faster than the system it was meant to replace, and the Stretch came in only 30 to 40 times faster. Because it failed to meet its goal, IBM had to drop Stretch’s price to $7.8 million from the planned $13.5 million, which meant the system was priced below cost. The company stopped offering the 7030 for sale, and only nine were ever built.

That wasn’t the end of the story, however. “A lot of what went into that effort was later helpful to the rest of the industry,” said Turing Award winner and Stretch team member Fran Allen at a recent event marking the project’s 50th anniversary. Stretch introduced pipelining, memory protection, memory interleaving and other technologies that have shaped the development of computers as we know them.

Lesson learned

Don’t throw the baby out with the bathwater. Even if you don’t meet your project’s main goals, you may be able to salvage something of lasting value from the wreckage.

Knight-Ridder’s Viewtron service

The Knight-Ridder media giant was right to think that the future of home information delivery would be via computer. Unfortunately, this insight came in the early 1980s, and the computer they had in mind was an expensive dedicated terminal.

Knight-Ridder launched its Viewtron version of videotex — the in-home information-retrieval service — in Florida in 1983 and extended it to other U.S. cities by 1985. The service offered banking, shopping, news and ads delivered over a custom terminal with color graphics capabilities beyond those of the typical PC of the time. But Viewtron never took off: It was meant to be the the “McDonald’s of videotex” and at the same time cater to upmarket consumers, according to a Knight-Ridder representative at the time who apparently didn’t notice the contradictions in that goal.

A Viewtron terminal cost $900 initially (the price was later dropped to $600 in an attempt to stimulate demand); by the time the company made the service available to anyone with a standard PC, videotex’s moment had passed.

Viewtron only attracted 20,000 subscribers, and by 1986, it had been canceled. But not before it cost Knight-Ridder $50 million. The New York Times business section wrote, with admirable understatement, that Viewtron “tried to offer too much to too many people who were not overly interested.”

Nevertheless, BusinessWeek concluded at the time, “Some of the nation’s largest media, technology and financial services companies … remain convinced that some day, everyday life will center on computer screens in the home.” Can you imagine?

Sometimes you can be so far ahead of the curve that you fall right off the edge.

DMV projects — California and Washington

Two Western states spent the 1990s attempting to computerize their departments of motor vehicles, only to abandon the projects after spending millions of dollars. First was California, which in 1987 embarked on a five-year, $27 million plan to develop a system for keeping track of the state’s 31 million drivers’ licenses and 38 million vehicle registrations. But the state solicited a bid from just one company and awarded the contract to Tandem Computers. With Tandem supplying the software, the state was locked into buying Tandem hardware as well, and in 1990, it purchased six computers at a cost of $11.9 million.

That same year, however, tests showed that the new system was slower than the one it was designed to replace. The state forged ahead, but in 1994, it was finally forced to abandon what the San Francisco Chronicle described as “an unworkable system that could not be fixed without the expenditure of millions more.” In that May 1994 article, the Chronicle described it as a “failed $44 million computer project.” In an August article, it was described as a $49 million project, suggesting that the project continued to cost money even after it was shut down. A state audit later concluded that the DMV had “violated numerous contracting laws and regulations.”

Regulations are there for a reason, especially ones that keep you from doing things like placing your future in the hands of one supplier.

Meanwhile, the state of Washington was going through its own nightmare with its License Application Mitigation Project (LAMP). Begun in 1990, LAMP was supposed to cost $16 million over five years and automate the state’s vehicle registration and license renewal processes. By 1992, the projected cost had grown to $41.8 million; a year later, $51 million; by 1997, $67.5 million. Finally, it became apparent that not only was the cost of installing the system out of control, but it would also cost six times as much to run every year as the system it was replacing. Result: plug pulled, with $40 million spent for nothing.

When a project is obviously doomed to failure, get out sooner rather than later.

FoxMeyer ERP program

In 1993, FoxMeyer Drugs was the fourth largest distributor of pharmaceuticals in the U.S., worth $5 billion. In an attempt to increase efficiency, FoxMeyer purchased an SAP system and a warehouse automation system and hired Andersen Consulting to integrate and implement the two in what was supposed to be a $35 million project. By 1996, the company was bankrupt; it was eventually sold to a competitor for a mere $80 million.

The reasons for the failure are familiar. First, FoxMeyer set up an unrealistically aggressive time line — the entire system was supposed to be implemented in 18 months. Second, the warehouse employees whose jobs were affected — more accurately, threatened — by the automated system were not supportive of the project, to say the least. After three existing warehouses were closed, the first warehouse to be automated was plagued by sabotage, with inventory damaged by workers and orders going unfilled.

Finally, the new system turned out to be less capable than the one it replaced: By 1994, the SAP system was processing only 10,000 orders a night, compared with 420,000 orders under the old mainframe. FoxMeyer also alleged that both Andersen and SAP used the automation project as a training tool for junior employees, rather than assigning their best workers to it.

In 1998, two years after filing for bankruptcy , FoxMeyer sued Andersen and SAP for $500 million each, claiming it had paid twice the estimate to get the system in a quarter of the intended sites. The suits were settled and/or dismissed in 2004.

No one plans to fail, but even so, make sure your operation can survive the failure of a project.

Apple’s Copland operating system

It’s easy to forget these days just how desperate Apple Computer was during the 1990s. When Microsoft Windows 95 came out, it arrived with multitasking and dynamic memory allocation, neither of which was available in the existing Mac System 7. Copland was Apple’s attempt to develop a new operating system in-house; actually begun in 1994, the new OS was intended to be released as System 8 in 1996.

Copland’s development could be the poster child for feature creep. As the new OS came to dominate resource allocation within Apple, project managers began protecting their fiefdoms by pushing for their products to be incorporated into System 8. Apple did manage to get one developers’ release out in late 1996, but it was wildly unstable and did little to increase anyone’s confidence in the company.

Before another developer release could come out, Apple made the decision to cancel Copland and look outside for its new operating system; the outcome, of course, was the purchase of NeXT, which supplied the technology that became OS X.

Copland did not die in vain. Some of the technology seen in demos eventually turned up in OS X. And even before that, some Copland features wound up in System 8 and 9, including a multithreaded Finder that provided something like true preemptive multitasking.

Project creep is a killer. Keep your project’s goals focused.

Sainsbury’s warehouse automation

Sainsbury’s, the British supermarket giant, was determined to install an automated fulfillment system in its Waltham Point distribution center in Essex. Waltham Point was the distribution center for much of London and southeast England, and the barcode-based fulfillment system would increase efficiency and streamline operations. If it worked, that is.

Installed in 2003, the system promptly ran into what were then described as “horrendous” barcode-reading errors. Regardless, in 2005 the company claimed the system was operating as intended. Two years later, the entire project was scrapped, and Sainsbury’s wrote off £150 million in IT costs. (That’s $265,335,000 calculated by today’s exchange rate, enough to buy a lot of groceries.)

A square peg in a round hole won’t fit any better as time goes on. Put another way — problems that go unaddressed at rollout will only get worse, not better, over time.

Canada’s gun registration system

In June 1997, Electronic Data Systems and U.K.-based SHL Systemhouse started work on a Canadian national firearm registration system. The original plan was for a modest IT project that would cost taxpayers only $2 million — $119 million for implementation, offset by $117 million in licensing fees.

But then politics got in the way. Pressure from the gun lobby and other interest groups resulted in more than 1,000 change orders in just the first two years. The changes involved having to interface with the computer systems of more than 50 agencies, and since that integration wasn’t part of the original contract, the government had to pay for all the extra work. By 2001, the costs had ballooned to $688 million, including $300 million for support.

But that wasn’t the worst part. By 2001, the annual maintenance costs alone were running $75 million a year. A 2002 audit estimated that the program would wind up costing more than $1 billion by 2004 while generating revenue of only $140 million, giving rise to its nickname: “the billion-dollar boondoggle.”

The registry is still in operation and still a political football. Both the Canadian Police Association and the Canadian Association of Chiefs of Police have spoken in favor of it, while opponents argue that the money would be better spent otherwise.

Define your project scope and freeze specifications before the requests for changes get out of hand.

Three current projects in danger

At least Canada managed to get its project up and running. Our final three projects, courtesy of the U.S. government, are still in development — they have failed in many ways already, but can still fail more. Will anyone learn anything from them? After reading these other stories, we know how we’d bet.

FBI Virtual Case File

In 2000, the FBI finally decided to get serious about automating its case management and forms processing, and in September of that year, Congress approved $379.8 million for the Information Technology Upgrade Project. What started as an attempt to upgrade the existing Automated Case Support system became, in 2001, a project to develop an entirely new system, the Virtual Case File (VCS), with a contract awarded to Science Applications International Corp.

That sounds reasonable until you read about the development time allotted (a mere 22 months), the rollout plans (a “flash cutover,” in which the new system would come online and the old one would go offline over a single weekend), and the system requirements (an 800-page document specifying details down to the layout of each page).

By late 2002, the FBI needed another $123.2 million for the project. And change requests started to take a toll: According to SAIC, those totaled about 400 by the end of 2003. In April 2005, SAIC delivered 700,000 lines of code that the FBI considered so bug-ridden and useless that the agency decided to scrap the entire VCS project. A later audit blamed factors such as poorly defined design requirements, an overly ambitious schedule and the lack of an overall plan for purchases and deployment.

The FBI did use some of what it learned from the VCF disaster in its current Sentinel project. Sentinel, now scheduled for completion in 2012, should do what VCF was supposed to do using off-the-shelf, Web-based software.

Homeland Security’s virtual fence

The U.S. Department of Homeland Security is bolstering the U.S. Border Patrol with a network of radar, satellites, sensors and communication links — what’s commonly referred to as a “virtual fence.” In September 2006, a contract for this Secure Border Initiative Network (SBInet, not to be confused with Skynet) was awarded to Boeing, which was given $20 million to construct a 28-mile pilot section along the Arizona-Mexico border.

But early this year, Congress learned that the pilot project was being delayed because users had been excluded from the process and the complexity of the project had been underestimated. (Sound familiar?) In February 2008, the Government Accountability Office reported that the radar meant to detect aliens coming across the border could be set off by rain and other weather, and the cameras mean to zoom in on subjects sent back images of uselessly low resolution for objects beyond 3.1 miles. Also, the pilot’s communications system interfered with local residents’ WiFi networks — not good PR.

In April, DHS announced that the surveillance towers of the pilot fence did not meet the Border Patrol’s goals and were being replaced — a story picked up by the Associated Press and widely reported in the mainstream media. But the story behind the story is less clear. The DHS and Boeing maintain the original towers were only temporary installations for demonstration purposes. Even so, the project is already experiencing delays and cost overruns, and in April, SBInet program manager Kirk Evans resigned , citing lack of a system design as just one specific concern. Not an auspicious beginning.

Census Bureau’s handheld units

Back in 2006, the U.S. Census Bureau made a plan to use 500,000 handheld devices — purchased from Harris Corp. under a $600 million contract — to help automate the 2010 census. Now, though, the cost has more than doubled, and their use is going to be curtailed in 2010 — but the Census Bureau is moving ahead with the project anyway.

During a rehearsal for the census conducted in the fall of 2007, according to the GAO, field staff found that the handheld devices froze or failed to retrieve mapping coordinates (see Hard questions needed to save projects for details). Furthermore, multiple devices had the same identification number, which meant they would overwrite one another’s data.

After the rehearsal, a representative of Mitre Corp. , which advises the bureau on IT matters, brought notes to a meeting with the bureau’s representative that read, “It is not clear that the system will meet Census’ operational needs and quality goals. The final cost is unpredictable. Immediate, significant changes are required to rescue the program. However, the risks are so large considering the available time that we recommend immediate development of contingency plans to revert to paper operations.”

There you have it, a true list of IT Ig Nobels: handheld computers that don’t work as well as pencil and paper, new systems that are slower and less capable than the old ones they’re meant to replace. Perhaps the overarching lesson is one that project managers should have learned at their mothers’ knees: Don’t bite off more than you can chew.

San Francisco-based Widman is a frequent contributor to Computerworld .

Related content

Meta opens its mixed-reality horizon os to other headset makers, a crafty new android notification power-up, microsoft uses its genai leverage against china — prelude to a tech cold war, how to fix icloud sync in seconds, from our editors straight to your inbox.

Jake Widman is a freelance writer in San Francisco and a regular contributor to Computerworld , PCWorld , and TechHive .

More from this author

7 quick base tips and tricks, ar and vr bring a new twist to collaboration, ar in the enterprise: tips for a better augmented reality app, what is quick base a low-code database platform for citizen developers, most popular authors.

Show me more

Gen z workers pick genai over managers for career advice.

Adobe’s new Firefly Image 3 adds genAI features to Photoshop

Enterprises want AI PCs, just not yet

Why the world will be wearing more technology in the future

Is AR/VR set for another growth spurt? | Ep. 143

Voice cloning, song creation via AI gets even scarier

More tech layoffs as AI takes hold

Is AR/VR set for another growth spurt?

Epic fail: Exploring project failure’s reasons, outcomes and indicators

• Original Paper
• Published: 19 June 2021
• Volume 16 , pages 1169–1193, ( 2022 )

Cite this article

• Marc Herz   ORCID: orcid.org/0000-0002-1463-2725 1 &
• Nicco Krezdorn 2  

2325 Accesses

5 Citations

Explore all metrics

Understanding the complex phenomenon of project failure can facilitate improved project management and lower the risk of future project failure. Using a qualitative pre-study combined with a quantitative survey conducted with project managers, the study assesses the reasons for, as well as the outcomes and indicators of, project failure. The study (1) identifies planning as well as people factors as significant reasons for project failure, (2) explores outcomes of project failure, and (3) identifies key indicators and early warning signs of project failure. The results provide multifaceted insights into the phenomenon of project failure, and the authors provide specific theoretical, methodological, and managerial implications.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price includes VAT (Russian Federation)

Instant access to the full article PDF.

Rent this article via DeepDyve

Institutional subscriptions

Similar content being viewed by others

Failure in Projects

IS/IT Project Failures: A Review of the Extant Literature for Deriving a Taxonomy of Failure Factors

Rethinking Success in Software Projects: Looking Beyond the Failure Factors

Notably, more detailed perspectives focus on antecedents and drivers, the event and subsequent direct effects, indirect effects, and long-term outcomes (for a more detailed overview, see Khelil 2016 ; Klimas et al. 2020 ).

We included respondents from different regions of the world in the qualitative study to assess whether there were cultural differences in the approach to dealing with project failure. However, we found no evidence for any cultural differences and thus analyzed the interviews without further focusing on any regional factors.

The greatest proportion of respondents came from Germany (N = 71), the United States (N = 60), China (N = 22), and the United Kingdom (N = 14).

Al-Ahmad W, Al-Fagih K, Khanfar K, Alsamara K, Abuleil S, Abu-Salem H (2009) A taxonomy of an IT project failure: root causes. Int Manage Rev 5(1):93–104

Google Scholar  

Albert M, Balve P, Spang K (2017) Evaluation of project success: a structured literature review. International Journal of Managing Projects in Business.

Amankwah-Amoah J (2015) Where will the axe fall? European Business Review.

Anderson JC, Gerbing DW (1988) Structural equation modeling in practice: A review and recommended two-step approach. Psychol Bull 103(3):411–423

Article   Google Scholar  

Atkinson R (1999) Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. Int J Project Manage 17(6):337–342

Azorín JM, Cameron R (2010) The application of mixed methods in organisational research: A literature review. Electr J Business Res Method 8(2):95

Bagozzi RP (2007) On the meaning of formative measurement and how it differs from reflective measurement: Comment on Howell, Breivik, and Wilcox.

Baker BN, Murphy DC, Fisher D (2008) Factors affecting project success. Project Management Handbook, Second Edition, 902–919.

Barney JB, Hesterly W (2006) Organizational economics: Understanding the relationship between organizations and economic analysis. The SAGE handbook of organization studies, 111–148.

Belassi W, Tukel OI (1996) A new framework for determining critical success/failure factors in projects. Int J Project Manage 14(3):141–151

Black K (1996) Causes of project failure: a survey of professional engineers. PM Netw 10:21–24

Bronnenmayer M, Wirtz BW, Göttel V (2016) Success factors of management consulting. RMS 10(1):1–34

Bryde DJ, Robinson L (2005) Client versus contractor perspectives on project success criteria. Int J Project Manage 23(8):622–629

Burgelman RA, Välikangas L (2005) Managing internal corporate venturing cycles. MIT Sloan Manag Rev 46(4):26–34

Burmann C, Zeplin S, Riley N (2009) Key determinants of internal brand management success: An exploratory empirical analysis. J Brand Manag 16(4):264–284

Cardon MS, Stevens CE, Potter DR (2011) Misfortunes or mistakes?: Cultural sensemaking of entrepreneurial failure. J Bus Ventur 26(1):79–92

Charmaz K (2006) Constructing grounded theory: A practical guide through qualitative analysis. Sage, California

Chen HL (2015) Performance measurement and the prediction of capital project failure. Int J Project Manage 33(6):1393–1404

Chin A, Cohen TR, Lindblad MR (2019) Consumer bankruptcy stigma: understanding relationships with familiarity and perceived control. J Consum Aff 53(2):600–629

Chiponde D, Gledson B, Greenwood D (2019) Examining construction and project management perspectives of project-based failure.

Chipulu M, Ojiako U, Gardiner P, Williams T, Mota C, Maguire S, Shou Y, Stamati T, Marshall A (2014) Exploring the impact of cultural values on project performance: The effects of cultural values, age and gender on the perceived importance of project success/failure factors. Int J Oper Prod Manag 34(3):364–389

Clarke A (1999) A practical use of key success factors to improve the effectiveness of project management. Int J Project Manage 17(3):139–145

Cleveland S, Cleveland M (2020) Leadership competencies for sustained project success. Int J Appl Manage Theory Res 2(1):35–47

Coltman T, Devinney TM, Midgley DF, Venaik S (2008) Formative versus reflective measurement models: Two applications of formative measurement. J Bus Res 61(12):1250–1262

Cooke-Davies T (2002) The “real” success factors on projects. Int J Project Manage 20(3):185–190

Cope J (2011) Entrepreneurial learning from failure: An interpretative phenomenological analysis. J Bus Ventur 26(6):604–623

Creswell JW (2002) Educational research: Planning, conducting, and evaluating quantitative. Prentice Hall, Upper Saddle River, NJ

Cusin J, Maymo V (2016) Post-bankruptcy stigmatization of entrepreneurs and bankers’ decisions to finance. Management 19(4):305–329

Davis K (2014) Different stakeholder groups and their perceptions of project success. Int J Project Manage 32(2):189–201

Davis K (2017) An empirical investigation into different stakeholder groups perception of project success. Int J Project Manage 35(4):604–617

Diamantopoulos A, Winklhofer HM (2001) Index construction with formative indicators: An alternative to scale development. J Mark Res 38(2):269–277

Dias A , Teixeira AA (2017). The anatomy of business failure: A qualitative account of its implications for future business success. European Journal of Management and Business Economics.

DiMasi JA, Hansen RW, Grabowski HG (2003) The price of innovation: new estimates of drug development costs. J Health Econ 22(2):151–185

Dvir D, Lechler T (2004) Plans are nothing, changing plans is everything: The impact of changes on project success. Res Policy 33(1):1–15

Dvir D, Lipovetsky S, Shenhar A, Tishler A (1998) In search of project classification: A non-universal approach to project success factors. Res Policy 27(9):915–935

Eisenhardt K (1989) Agency theory: An assessment and review. Acad Manag Rev 14(1):57–74

Flyvbjerg B (2014) What you should know about megaprojects and why: An overview. Proj Manag J 45(2):6–19

Flyvbjerg B, Budzier A (2013) Why your IT project might be riskier than you think.  arXiv preprint arXiv:1304.0265. .

Flyvbjerg B, Bruzelius N, Rothengatter W (2003) Megaprojects and risk: An anatomy of ambition. Cambridge University Press, Cambridge

Book   Google Scholar  

Flyvbjerg B, Holm MS, Buhl S (2002) Underestimating costs in public works projects: Error or lie? J Am Plann Assoc 68(3):279–295

Flyvbjerg B, Skamris Holm MK, Buhl SL (2004) What causes cost overrun in transport infrastructure projects? Transp Rev 24(1):3–18

Fornell C, Larcker DF (1981) Structural equation models with unobservable variables and measurement error: Algebra and statistics. J Mark Res 18(3):382–388

Gemünden HG, Salomo S, Krieger A (2005) The influence of project autonomy on project success. Int J Project Manage 23(5):366–373

Glaister KW, Falshaw JR (1999) Strategic planning: still going strong? Long Range Plan 32(1):107–116

Glaser BG, Strauss AL (2017) Discovery of grounded theory: Strategies for qualitative research. Routledge, UK

Grundy T (2006) Rethinking and reinventing Michael Porter’s five forces model. Strateg Chang 15(5):213–229

Harrington N (2005) It’s too difficult! Frustration intolerance beliefs and procrastination. Personality Individ Differ 39(5):873–883

Hewstone M, Greenland K (2000) Intergroup conflict. Int J Psychol 35(2):136–144

Hoegl M, Gemuenden HG (2001) Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence. Organ Sci 12(4):435–449

Hüttl-Maack V, Pick D, Gierl H (2019) Handle with care! How majority cues can reduce the negative effects of warnings of foreseeable product failures. RMS 13(4):689–723

Jeng DJF, Hung TH (2019) Comeback of the failed entrepreneur: An integrated view of costs, learning, and residual resources associated with entrepreneurial failure. J Small Bus Strateg 29(1):30–42

Jensen MC (2003) A theory of the firm: governance, residual claims, and organizational forms. Harvard University Press

Johnson RB, Onwuegbuzie AJ (2004) Mixed methods research: A research paradigm whose time has come. Educ Res 33(7):14–26

Joslin R, Müller R (2016) The relationship between project governance and project success. Int J Project Manage 34(4):613–626

Jost PJ, Lammers F (2009) The organization of project evaluation under competition. RMS 3(2):141–155

Jugdev K, Müller R (2005) A retrospective look at our evolving understanding of project success. Proj Manag J 36(4):19–31

Kerzner H (2017) Project management: a systems approach to planning, scheduling, and controlling, 12th edn. Wiley

Khelil N (2016) The many faces of entrepreneurial failure: Insights from an empirical taxonomy. J Bus Ventur 31(1):72–94

Klimas P, Czakon W, Kraus S, Kailer N, Maalaoui A (2020) Entrepreneurial failure: a synthesis and conceptual framework of its effects. European Management Review.

Kraśnicka T, Głód W, Wronka-Pośpiech M (2018) Management innovation, pro-innovation organisational culture and enterprise performance: testing the mediation effect. RMS 12(3):737–769

Krippendorff K (2004) Content analysis: An introduction to its methodology, 2nd edn. Sage Publications, Thousand Oaks, CA

Laffont JJ, Martimort D (2002) The theory of incentives: The principal-agent model. Princeton University Press, New Jersy

Levasseur RE (2017) People skills: building the perfect team—a change management perspective. Interfaces 47(3):270–272

Li Y, Wen W, Yu X, Meng X, Tao Y (2020) What’s Holding Back Recovery from Failure? Insights from Entrepreneurial Passion and Coping Strategy. In Academy of Management Proceedings (Vol. 2020, No. 1, p. 10095). Briarcliff Manor, NY 10510: Academy of Management

Lv Z, Rodríguez-García M, Sendra-García J (2020) Does institutional quality affect the level of entrepreneurial success differently across the entrepreneurship distribution? Review of Managerial Science, 1–19

McGrath RG, Keil T, Tukiainen T (2006) Extracting value from corporate venturing. MIT Sloan Manag Rev 48(1):50–56

Meuser M, Nagel U (2009) The expert interview and changes in knowledge production. Interviewing experts. Palgrave Macmillan, London, pp 17–42

Chapter   Google Scholar  

Mir FA, Pinnington AH (2014) Exploring the value of project management: Linking project management performance and project success. Int J Project Manage 32(2):202–217

Molina-Azorin JF (2012) Mixed methods research in strategic management: Impact and applications. Organ Res Methods 15(1):33–56

Molina-Azorin JF (2016) Mixed methods research: An opportunity to improve our studies and our research skills. Eur J Manag Bus Econ 25:37–38

Molina-Azorίn JF (2011) The use and added value of mixed methods in management research. J Mixed Methods Res 5(1):7–24

Morris A, Wilkinson SJ, Algeo C, Candusso D (2016) Measuring project success in local government. ANZAM.

Morris P, Hough G (1987) The anatomy of major projects. Wiley, Chichester, UK

Müller R, Jugdev K (2012) Critical success factors in projects: Pinto, Slevin, and Prescott–the elucidation of project success. Int J Manag Proj Bus 5(4):757–775

Müller R, Turner R (2007) The influence of project managers on project success criteria and project success by type of project. Eur Manag J 25(4):298–309

Müller R, Zhai L, Wang A (2017) Governance and governmentality in projects: Profiles and relationships with success. Int J Project Manage 35(3):378–392

Munns AK, Bjeirmi BF (1996) The role of project management in achieving project success. Int J Project Manage 14(2):81–87

Nixon P, Harrington M, Parker D (2012a) Leadership performance is significant to project success or failure: a critical analysis. Int J Product Perform Manag 61(2):204–216

Nixon P, Harrington M, Parker D (2012) Leadership performance is significant to project success or failure: a critical analysis. International Journal of productivity and performance management.

Nunnally JC (1978) Psychometric theory, 2nd edn. McGraw-Hill, New York

Pinto JK, Mantel SJ (1990) The causes of project failure. IEEE Trans Eng Manage 37(4):269–276

Pinto JK, Slevin DP (1987) Critical factors in successful project implementation. IEEE Trans Eng Manage 34(1):22–27

Pinto JK, Slevin DP (1988) Project success. Proj Manag J 4:67–72

Pinto JK, Slevin DP (1989) Critical success factors in R&D projects. Res Technol Manag 32(1):31–35

Rhaiem K, Amara N (2019) Learning from innovation failures: A systematic review of the literature and research agenda. Review of Managerial Science, 1–46

Ritter T, Gemünden HG (2004) The impact of a company’s business strategy on its technological competence, network competence and innovation success. J Bus Res 57(5):548–556

Robertson S, Williams T (2006) Understanding project failure: using cognitive mapping in an insurance project. Proj Manag J 37(4):55–71

Rubin IM, Seelig W (1967) Experience as a factor in the selection and performance of project managers. IEEE Trans Eng Manage 3:131–135

Sage D, Dainty A, Brookes N (2014) A critical argument in favor of theoretical pluralism: Project failure and the many and varied limitations of project management. Int J Project Manage 32(4):544–555

Savolainen P, Ahonen JJ, Richardson I (2012) Software development project success and failure from the supplier’s perspective: A systematic literature review. Int J Project Manage 30(4):458–469

Schubert N, Krcic S (2020) Here lies our beloved project, may it rest in peace-the impact of grief after project failure: An exploratory study of negative emotions within the context of project failure and their impact on emotional recovery and subsequent learning

Shao J, Müller R, Turner JR (2012) Measuring program success. Proj Manag J 43(1):37–49

Shepherd DA, Cardon MS (2009) Negative emotional reactions to project failure and the self-compassion to learn from the experience. J Manage Stud 46(6):923–949

Shepherd DA, Haynie JM (2011) Venture failure, stigma, and impression management: A self-verification, self-determination view. Strateg Entrep J 5(2):178–197

Shepherd DA, Patzelt H (2018) Entrepreneurial Cognition: Exploring the Mindset of Entrepreneurs. Springer, Berlin

Shepherd DA, Covin JG, Kuratko DF (2009) Project failure from corporate entrepreneurship: Managing the grief process. J Bus Ventur 24(6):588–600

Shepherd DA, Patzelt H, Wolfe M (2011) Moving forward from project failure: Negative emotions, affective commitment, and learning from the experience. Acad Manag J 54(6):1229–1259

Singh S, Corner P, Pavlovich K (2007) Coping with entrepreneurial failure. J Manag Organ 13(4):331

Stingl V, Geraldi J (2017) Errors, lies and misunderstandings: Systematic review on behavioural decision making in projects. Int J Project Manage 35(2):121–135

Tao X, Robson PJA, Wang CL (2019) Project failure, error orientation and learning from failure. In Academy of Management Proceedings (Vol. 2019, No. 1, p. 15732). Briarcliff Manor, NY 10510: Academy of Management

Thiry M (2006) The definition of success. PM Netw 20(12):21–22

Tuman GJ (1983) Development and implementation of effective project management information and control systems. Project Management Handbook, 495–532

Turner JR (2004) Five necessary conditions for project success. Int J Project Manage 5(22):349–350

Turner JR, Müller R (2005) The project manager’s leadership style as a success factor on projects: A literature review. Proj Manag J 36(2):49–61

Turner JR (1999) The Handbook of Project-Based Management: Improving the Processes for Achieving Strategic Objectives, 2nd edn. McGraw-Hill Publishing Co, London

Turner R, Zolin R (2012) Forecasting success on large projects: developing reliable scales to predict multiple perspectives by multiple stakeholders over multiple time frames. Proj Manag J 43(5):87–99

Ucbasaran D, Shepherd DA, Lockett A, Lyon SJ (2013) Life after business failure: The process and consequences of business failure for entrepreneurs. J Manag 39(1):163–202

Verner CM, Sarwar D (2021) Avoiding project failure and achieving project success in NHS IT system projects in the United Kingdom. Int J Strategic Eng (IJoSE) 4(1):33–54

Weinkauf K, Högl M, Gemünden HG, Hölzle K (2005) Zusammenarbeit zwischen organisatorischen Gruppen: Ein Literaturüberblick über die Intergroup Relations-. Schnittstellen-Und Boundary Spanning-Forschung Journal Für Betriebswirtschaft 55(2):85–111

Westerveld E (2003) The Project Excellence Model®: linking success criteria and critical success factors. Int J Project Manage 21(6):411–418

Westfall A (2020) Information Technology Project Failure Caused by Inadequate Project Scoping: An Exploratory Qualitative Inquiry on Inadequate Project Scopes (Doctoral dissertation, Capella University).

Wright JN (1997) Time and budget: the twin imperatives of a project sponsor. Int J Project Manage 15(3):181–186

Zuofa T (2014) Project failure: The way forward and panacea for development. International Journal of Business and Management, 9(11)

Download references

Author information

Authors and affiliations.

Kleinundpläcking GmbH, Berlin, Germany

Klinik für Plastische, Ästhetische, Hand- und Wiederherstellungschirurgie, Medizinische Hochschule Hannover, Hannover, Germany

Nicco Krezdorn

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Marc Herz .

Additional information

Publisher's note.

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendix: Measurement details

Rights and permissions.

Reprints and permissions

About this article

Herz, M., Krezdorn, N. Epic fail: Exploring project failure’s reasons, outcomes and indicators. Rev Manag Sci 16 , 1169–1193 (2022). https://doi.org/10.1007/s11846-021-00479-4

Download citation

Received : 10 September 2020

Accepted : 08 June 2021

Published : 19 June 2021

Issue Date : May 2022

DOI : https://doi.org/10.1007/s11846-021-00479-4

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Project Management

Mathematics Subject Classification

• 62H15 Hypothesis testing in multivariate analysis
• Find a journal
• Publish with us
• Track your research

• Developer Blog
• Project Management Tips

How to Turnaround a Failing Software Project

By Aran Davies

8 years of experience

Aran Davies is a full-stack software development engineer and tech writer with experience in Web and Mobile technologies. He is a tech nomad and has seen it all.

Do you want to explore learnings from failed software projects’ case studies to prevent your software from facing the same failures?

There are huge sums of money to gain by launching a successful software project. Naturally, all product owners and developers hope to succeed with their software development project, however, as the data on actual success rates show, often, things go wrong.

A PMI report found a 14% failure rate for software development projects. Even disregarding the entirely failed projects, 31% don’t meet their objectives, while 43% of projects see a budget overrun.

When this happens, you need to take decisive action to turn around your project. When DevTeam.Space recently successfully turnaround one such stalled project, the software development project to develop DentaMatch , we noticed that this requires distinct competencies that some might overlook.

As an entrepreneur or an enterprise software development project leader, are you trying to turn around a failing project? If so, then you need to know about these competencies. This guide will show you how to prevent software failures .

How to Prevent a Project Failure as Assessed From the Failed Software Projects’ Case Studies?

Failed software projects’ case studies show that you need to perform the following on time to turn around a project and prevent its failure:

1. Assess what went wrong with the project

You need to assess what went wrong with the software project, and this requires you to take a deep dive. The project might already be in the news in your organization due to scope creep, budget overruns, or the quality management reports showing too many reds.

The common reasons that might cause a project to fail are as follows:

• Inaccurate requirements;
• Insufficient involvement of the project sponsors;
• Frequently changing project objectives;
• Poor development lifecycle planning. i.e wrong estimates resulting in lack of time, etc;
• Risks that no one could foresee;
• Delays caused by dependencies;
• Poor use of any new technology that might help streamline the process, improve functionalities, etc.;
• Under-staffed project teams;
• Poor project manager;
• Delays caused by the project team members.

However, these are manifestations of deeper issues as learned from failed software projects’ case studies.

Your deep dive must focus on what went wrong structurally or systematically, which caused the above-mentioned slippages or overruns. You ought to study several documents, e.g.:

Hire expert developers for your next project

• The project requirements;
• The architectural decisions;
• The technical solution and the lower-level design documents;
• Test plans, test cases, and test results;
• Review records;
• Risks and issues logs.

You need to have several face-to-face meetings with multiple project stakeholders, e.g., sponsors, developers, testers, etc.

2. Analyze the root causes of the project challenges

Having assessed the extent of damage to your project, you should now analyze the root causes. You need to focus on empirical evidence and data over hypotheses and guesses.

A “Root Cause Analysis” (RCA) exercise involves going deep into the causes of failure, unearthing deeper reasons as you analyze.

The root causes typically belong to any of the following categories:

• The lack of project management competencies;
• Using an unsuitable SDLC model;
• The development team lacks the required capabilities;
• Choosing the wrong IT architecture pattern;
• Ineffective use of cloud services;
• Using unsuitable technology stack, development tools, and testing tools;
• The lack of collaboration impedes the productivity of the team;
• Measuring the wrong metrics.

We, at DevTeam.Space, are well-equipped for analyzing why software projects fail, and you can judge our capabilities in “ The 10 biggest challenges when developing an app ”.

3. Determine whether you have a capable team

You have just assessed what went wrong with the project. In some circumstances, the existing team might be able to resolve these issues, however, there are exceptions.

You need to meet the existing team and communicate the project’s challenges. Honestly communicate with them about where you hold them responsible for the issues, and why.

You will need to change the existing team if you see any of the following:

• The existing team doesn’t take accountability for the project issues.
• It communicates reasons why it shouldn’t be held accountable, however, the reasons don’t quite add up.
• The team understands their drawbacks, however, they’re at a loss about how to turn things around.

If you had hired a software development company for this project and it performed sub-optimally, then you ought to change the development partner.

Read our guide “ How to change your software development company mid-project ” for more insights.

4. Check whether you need to replace any developer

You could also have a situation where the larger development team is capable, but, one or more developers aren’t. In such a circumstance, you need to have an honest discussion with the underperforming developers.

You might find that the said developers might have performed below par due to specific reasons, and their performance would improve if you address the underlying reasons. At other times, you could find they aren’t capable of improving their performance.

In such a situation, you would need to replace the ineffective developers. Our guide “ Getting rid of bad developers during a project ” can help you to find a replacement developer.

5. Ascertain whether the project team has enough developers

At times, projects fail due to wrongly estimating the development manpower. While the team is perfectly capable, it might be understaffed.

In such cases, you should hire competent developers to address the lack of manpower. As I have explained in “ How to Find a Good Software Developer ”, consider the following when hiring developers:

• You need programmers with strong professional ethics.
• Developers you hire need to have decision-making capabilities.
• You need developers with sufficient knowledge of computer science fundamentals.
• Programmers you hire should have the skills that are hot in the market, e.g., Node.js for web development, Kotlin for native Android development, Swift for native iOS development, Python for AI/ML programming, etc.
• You need to hire developers with good knowledge of SDLC.
• Developers need to know enough about proactively mitigating software glitches and application security risks.
• They should be able to code in a way that aligns with your choice of architecture pattern.
• You need developers that know how to code scalable apps and have familiarity with managed cloud services.
• They need to know the market-leading development tools, moreover, they should have industry knowledge.
• You also need developers that can collaborate on rectifying a software error.

DevTeam.Space’s blog recently featured an article to help you hire such developers. For more on this read “ 7 essential tips for hiring the best developers for your project ”.

6. Plan to turn around the project

You have assessed by now what went wrong and ascertained the root causes. You have also dealt with underperforming teams/developers and/or bandwidth issues in the team. It’s now time to plan the recovery of the troubled software project.

The recovery plan might include several tracks of actions and the “Root Cause Analysis” (RCA) determines them. We, at DevTeam.Space, have the right expertise for such recovery planning, as I had explained in “ What is the best development approach to guarantee the success of your app? ”.

You might need to address one or more of the following aspects:

6a. SDLC model

Ensure that you are using the right SDLC model for the kind of project you have. E.g., if you are developing a “System of Engagement” (SoE) like a mobile app, then Agile is better than Waterfall, as I have explained in “ Waterfall vs. Agile: which methodology is right for your project ”.

You should also use the right approach that works with your chosen SDLC model, e.g., develop your “Minimum Viable Product” (MVP) in the right way in an Agile project. Our guide “ 5 Tips to Create a Sleek MVP ” can help you with this.

6b. IT architecture

Choose an architecture pattern that suits your functional and non-functional requirements and delivers the best user experience without a software glitch. There are several popular architecture patterns, e.g.:

• Layered (n-tier);
• Event-driven;
• Microkernel;
• Microservices;
• Space-based.

You can use our guide “ Large Enterprise Java Projects Architecture ” to make the right choice.

6c. Mitigating the application security risks

You ought to proactively mitigate the application security risks since this is crucial for the long-term success of your project. The key application security risks are as follows:

• Broken authentication;
• Sensitive data breach and exposure;
• XML external entities (XXE);
• Broken access control;
• Security misconfiguration;
• Cross-site scripting (XSS);
• Insecure deserialization;
• Using components with known vulnerabilities;
• Insufficient logging/monitoring.

Read the “ Open Web Application Security Project (OWASP) Top 10 Application Security Risks ” report for insights on mitigating these risks.

6d. “Managed Cloud Services” (MCS)

Plan to utilize managed cloud services (MCS) smartly so that you can focus on development instead of infrastructure management.

If you are developing a web app, then you should use a Platform-as-a-Service (PaaS) platform since it offers many benefits, e.g.:

• PaaS platforms like AWS Elastic Beanstalk manage the cloud infrastructure, networking, operating system (OS), middleware, and runtime environment. You can concentrate on coding.
• You can easily integrate databases and APIs when using a PaaS platform.
• Reputed PaaS platforms offer robust DevOps tools and auto-scaling solutions.

Read our guide “ 10 Top PaaS Providers ” for more insights.

On the other hand, if you are developing a mobile app, then use a Mobile-Backend-as-a-Service (MBaaS) platform like AWS Amplify . The following advantages make it a smart move:

• MBaaS providers manage the cloud infrastructure and persistent storage, therefore, you don’t need to develop and manage the mobile backend.
• You will be able to scale your mobile app easily, moreover, you will find it easy to implement features like user management and push notifications.
• MBaaS platforms enable you to integrate APIs easily.

I have explained their advantages in “ How to choose the best Mobile Backend as a Service (MBaaS)? ”.

6e. Designing APIs

You will likely design APIs as part of your project, and you should keep the long-term success of your app in mind while doing so. While you might consider RESTful APIs, I recommend that you use GraphQL instead of REST (Representational State Transfer).

With RESTful APIs, you call an API endpoint to receive all data in it. On the other hand, GraphQL is a query language, therefore, you can specify the exact data elements you need. This has several advantages, e.g.:

• With REST, if you need more data than what the API endpoint contains, then you need to make more API calls. This is called “under-fetching”. You can avoid this with GraphQL since you can query the exact data elements you need.
• On the other hand, if you need less data than what the RESTful API endpoint can send, then you receive unnecessary data. This is called “over-fetching” and you can avoid it with the query capabilities of GraphQL.
• When using REST, you would design the API endpoint in line with the front-end view. If you change the view, then you would also need to modify the API. This slows down the front-end iterations, however, you can avoid this with the query capabilities of GraphQL.

Read “ REST vs. GraphQL ” for more insights.

6f. Choosing the right technology stack

Choosing the right technology stack improves your chances of turning around a project troubled by a software bug. The choice of technology stack will depend on the kind of project, e.g.:

• JavaScript will be a better bet for a web development project.
• If you are developing mobile apps, then you might want to create native apps since they deliver the best user experience. You should then use Kotlin for native Android development and Swift for native iOS development.
• PostgreSQL is a robust “Relational Database Management System” (RDBMS), whereas MongoDB is a popular option for NoSQL databases.

We, at DevTeam.Space, have the right expertise for choosing the appropriate technology stack, as I have explained in “ How to create a minimum viable product for your enterprise company? ”.

7. Execute the turnaround plan and track its progress

Now that you have come up with a pragmatic plan to turn the troubled project around, it’s time for execution. Use the appropriate PM techniques and tools to manage the execution.

We, at DevTeam., have AI-powered Agile processes , which are highly suited to turn troubled projects around. Our data-driven real-time dashboard helps clients track the progress of the project, as I have explained in “ How a real-time dashboard can revolutionize your eSports development process? ”.

How About Preventing Your Project From Failing?

This article focused on helping you turn around troubled projects. However, it is always better to prevent projects from failing in the first place by avoiding software bugs in the development and software testing phases.

The key to this is choosing a trustworthy and competent software development company for your projects. Our guide “ How to find the best software development company ?” can help you with this.

If you want to ensure project success, then get in touch with DevTeam.Space . Our community of top developers has years of experience turning around failing projects.

They are trained in our unique software project management process. Moreover, we match developers for your project according to experience in your required industry so that they perfectly understand your business needs.

Once you have brought us up to speed and allowed us to analyze your software project, we outline a reliable timeframe to undo the unrealistic expectations given to you by your past development team.

Within no time, we have helped you turn things around and have you back on course to completing a successful project.

Frequently Asked Questions on Learnings From Failed Software Projects’ Case Studies

Missed deadlines, broken promises, poor communication, and software errors are all examples of poor developers. If you have just fired your bad developer and need an experienced software development company to turn your project around, then contact DevTeam.Space.

The top software failures, such as of Bangladesh bank system show that poor management and bad developers are two main reasons for software development failures. Other reasons assessed from failed software projects’ case studies include unsuitable infrastructure, poor code quality where hackers take advantage of a software flaw, subpar marketing, and a badly chosen software development methodology.

DevTeam.Space is a company with lots of experience in saving failing projects. By first establishing the cause of the problem (often bad developers), DevTeam.Space will quickly implement the necessary changes to turn the project around in no time.

Alexey Semeney

Founder of DevTeam.Space

Hire Alexey and His Team To Build a Great Product

Alexey is the founder of DevTeam.Space. He is award nominee among TOP 26 mentors of FI's 'Global Startup Mentor Awards'.

Some of our projects

Paying users

Android, Android Kotlin, Health, iOS, Mobile, QA, Swift

A mobile fitness app for a famous YouTube blogger. 100K paying users within two weeks.

Backend, Communication, DevOps, Java, Software

Designing, implementing, and maintaining continuous integration for an enterprise multi-component telecommunications web application.

Blockchain, Ethereum, Fintech, Javascript, React, Smart Contracts, Solidity, Trading, Truffle, Web

A cryptocurrency wallet and an exchange platform to trade fiat currencies and crypto tokens.

Read about devteam.space:.

New Internet Unicorns Will Be Built Remotely

DevTeam.Space’s goal is to be the most well-organized solution for outsourcing

The Tricks To Hiring and Managing a Virtual Work Force

DevTeam.Space Explains How to Structure Remote Team Management

With love from Florida 🌴

Tell us about your challenge & get a free strategy session, hire expert developers with devteam.space to build and scale your software products.

Hundreds of startups and companies like Samsung , Airbus , NEC , and Disney rely on us to build great software products. We can help you, too — 99% project success rate since 2016.

By continuing to use this website you agree to our Cookie Policy

Get a printable version of all questions and answers & bring it as a cheat sheet to your next interview.

Hire vetted developers with devteam.space to build and scale your software products.

Trusted by 100x of startups and enterprise companies like

Get a complimentary discovery call and a free ballpark estimate for your project

Trusted by 100x of startups and companies since 2016 including

• Faculty and Staff
• Research Assistants
• Job Openings
• Research Areas
• Publications
• The Evidence Base Blog
• Behavioral Economics Studio
• Behavioral and Health Genomics Center
• Brain Health Observatory @USC
• Center for Applied Research in Education
• Center for Health and Labor Economics (HALE)
• Center for Self-Report Science
• Center for the Study of Health Inequality
• CESR International Development
• Institute for Food System Equity
• The Interplay of Genes and Environment across Multiple Studies (IGEMS) consortium
• LA Barometer
• Program for Children and Families
• Program on Global Aging, Health, and Policy
• USC mHealth Collaboratory
• Understanding America Study
• UAS Datapages
• Global Aging Data Repository
• Health and Retirement Study
• Yucatan Aging Data
• CESR Education Study
• Brown Bag Series
• Seminar Series
• CESR's Ten Year Anniversary
• Events Archive
• CIPHER 2024
• Expert Commentary

Case Study: Project Failure Often Linked to Design Problems

Development portfolio management group (dpmg).

• Our Mission & Challenge
• What's At Stake?
• Our Origins
• Our Services
• Our Expertise
• Quality Assurance
• Service Costs

A comparison of two sets of ratings for the same cohort of projects showed that 74% of projects with satisfactory designs also had satisfactory outcomes years later.

The quality of a project's design is a strong indicator of its likelihood of success.

The World Bank's Quality Assurance Group (QAG), DPMG's predecessor, compared two sets of ratings for the same cohort of projects. One set was based on evaluations of the design quality of each project. The other ratings measured whether these projects had achieved their development objectives by the time they closed.

Of the 385 projects evaluated, 74% of projects with satisfactory designs also had satisfactory outcomes years later. By contrast, projects rated less than satisfactory on the basis of their designs were twice as likely as others to fail.

The study also showed that design flaws could be corrected if projects were evaluated early during their implementation. More than half of the projects found to have poor designs were turned around during supervision, and those that were evaluated early performed better than those evaluated later.

Common Design Problems

Four design problems were highly correlated with risk of failure.

Overly complex project designs Some project objectives are too complex and ambitious for the institution or government to manage. Donors’ (and governments’) enthusiasm tends to expand the scope of a project beyond the capabilities of weaker governments. This complexity takes many forms:

• Multiple sub-sectors, such as the primary, secondary, and tertiary levels of education
• Multiple beneficiaries, such as disabled children, street children, migrant children, girls in ethnic minority areas, and illiterate adults
• Multiple reform objectives, such as access, quality, equity, and efficiency.

Complex projects place heavy demands on implementing entities that often have limited capacities. The mismatch between complexity and capacity occurs most frequently in low-income and fragile states.

Poorly formulated causal links between inputs, outputs, and outcomes Poorly formulated objectives set up targets that are impossible to achieve. For example, the goal of one project was to produce more trained engineers. However, the project focused on construction of new training facilities that would not have produced any graduates by the end of the project.

Poorly selected indicators of success Poorly selected indicators of success leave all parties to the project flying blind. For example, one project gave four indicators of its objectives. Three of these were outputs (such as the number of vaccination doses procured), not outcomes (such as the number of children vaccinated). In the same project, one outcome measure was inappropriate: it applied to the entire country, not to the sub-regions addressed by the project.

Premature approval Sometimes projects are approved before they are ready. Examples include infrastructure projects that begin before the bidding documents for the first year of work have been prepared or projects that begin before baseline data for indicators of intended outcomes have been collected.

When projects enter the portfolio too soon, project teams may spend the first year or longer addressing issues that should have been handled before the project started. In these cases, the project is not likely to meet its objectives by the time resources have been spent.

Project Failure Case Studies

To be notified about new Project Failure Case Studies just sign up for my newsletter by clicking here . You will receive a free copy of my Project Success Model ™ .

• SUGGESTED TOPICS
• The Magazine
• Newsletters
• Managing Yourself
• Managing Teams
• Work-life Balance
• The Big Idea
• Data & Visuals
• Reading Lists
• Case Selections
• HBR Learning
• Topic Feeds
• Account Settings
• Email Preferences

HBR Case Study: A Rush to Failure?

A complex project for the space station must come in on time and on budget—but the push for speed might be its undoing.

There is absolutely no reason why the contractors shouldn’t be able to give us rapid product development and flawless products—speed and quality both,” David MacDonagle said as he tried to light a cigarette. The warm wind, portending rain, kept blowing out his matches. Finally he gave up and slipped the cigarette back in his pocket.

• TC Tom Cross is a senior director in executive education at the University of Virginia’s Darden School of Business, where he develops executive learning programs for Department of Defense leaders. Previously he was a senior executive at such firms as KFC and Office Depot.

Partner Center

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to  upgrade your browser .

Enter the email address you signed up with and we'll email you a reset link.

• We're Hiring!
• Help Center

Project Failure Case Studies and Suggestion

2014, International Journal of Computer Applications

Related Papers

Bigmo Asiedu

milad kiaei

ibimapublishing.com

Iman Attarzadeh

Karthik D Netalkar

Construction Economics and Building

Peter Livesey

A Delphi study using project managers who had managed projects in excess of $500 million was used to confirm the significance and frequency of problems resulting from the nature of projects. Using the results obtained from the Delphi study a ranking of the problems experienced in these projects was obtained by calculating a Relative Importance Index. Additionally, the Delphi panel members were asked their views concerning the need for traditional project management skills (hard skills) and team management skills (soft skills) as project size increased from below $50 million to over $500 million. A substantial increase in the need for both skills was indicated with the increase in the need for soft skills being the most significant.

Aarti Maherchandani

karrar raoof

Darrel Hubbard

Project management, when viewed as a management discipline from the perspectives of various executive levels, functions, and types found within different enterprises, can be described as many things by those executives. The field of Project Management is complex, multifaceted, and evolving. Included within this management discipline is a wide-range of related management disciplines and knowledge-area sub-disciplines, all of which affect diverse stakeholders. However, individually, or employed in small sets, these specific views of project management neither address nor solve the larger issues associated with successfully implementing and employing project management within the overall enterprise to create benefits and value and to address stakeholder needs. In addition, a significant portion of the project management literature and defined processes and methodologies for the many management disciplines and sub-disciplines does not address the broader business, organizational, sociol...

Karen Higgins

Course Background Today's business environment moves rapidly and often unpredictably. At any given time, funding and political support may wax or wane. Technology changes in areas such as computers, new materials, or breakthrough products are rapid and profound. The competitive landscape shifts daily. Goals evolve and often are interpreted differently, depending on the perspective of the stakeholder. Uncertainties create risk that must be managed. Industries, organizations and people are more interdependent than ever, relying on each other in areas such as specialized technical expertise and facilities. Businesses must collaborate to produce a product or service. Leaders can no longer rely on power, roles or processes alone to influence outcomes when they work interdependently with other organizations. To be successful in this complex and dynamic environment, project managers and leaders must demonstrate abilities beyond experience, technical and process insight, communication ...

RELATED PAPERS

Bibiana Santos

Journal of Cardio-Vascular-Thoracic Anaesthesia and Intensive Care Society

Arzu Tekeli

Convegno Igf Xiii Cassino 1997

Stefano Invernizzi

Tae-Ho Park

Journal of Autism and Developmental Disorders

Marian E Williams

Argensola: Revista de Ciencias Sociales del …

Maria Fernanda Gutierrez Rincon

Pablo Grilli

Danilo Renzi

Computer Supported Cooperative Work (CSCW)

Arja Haapakorpi

Oriental Journal Of Chemistry

204 Nisha Tripathi

Phytochemistry

Luisa Balderrama

Revista Gestão e Desenvolvimento

Anderson Queiroz Lemos

Samuel R. Friedman

Seminar Nasional Official Statistics

Salwa Amalia Irawati Putri

Bulletin of Faculty of Pharmacy, Cairo University

Nitin Dubey

Structural and Multidisciplinary Optimization

CARLOS A CERPA LOPEZ

American Journal of Clinical Oncology

Joshua Petit

International Journal of Plant & Soil Science

Trishna Taye , Khirud Panging

Dilshod Abdulhamidov

British Journal of Dermatology

Annalisa Patrizi

Journal of the Brazilian Society of Mechanical Sciences and Engineering

Amine Smahat

PLOS Neglected Tropical Diseases

Muhammed Afolabi

Austrian Journal of Statistics

kazumi wada

tyghfg hjgfdfd

Shlomo Angel

RELATED TOPICS

•   We're Hiring!
•   Help Center
• Find new research papers in:
• Health Sciences
• Earth Sciences
• Cognitive Science
• Mathematics
• Computer Science
• Academia ©2024