it projects that failed case studies

• 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

Sai group buys get well; aims to use ai for better patient engagement, microsoft 365 copilot explained: genai meets office, macstadium brings orka desktop for devops, copilot for microsoft 365 deep dive: productivity at a steep price, 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, 10 smartsheet tips and tricks, how it can prepare for vr, ar and mr in the enterprise, how to cure ‘corporate amnesia’ with knowledge management software, need a ride 3 ridesharing and 2 taxi apps considered, most popular authors.

• Gyana Swain

Show me more

'quiet firing' layoffs risk fomenting a toxic environment.

10 forgotten Android text selection shortcuts

10 ways to boost your Windows laptop’s battery life

Podcast: Why a TikTok ban makes sense

Podcast: Are audio AI companies infringing on musicians' rights?

Podcast: What skills will future tech leaders need?

Why a TikTok ban makes sense

Music companies strike back against audio AI

Skills that future tech leaders will need

Sponsored Links

• Get Cisco UCS X-Series Chassis and Fabric Interconnects offer.

• 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.

Get your free

Lessons Learned Template

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

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.

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.

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.

To better analyzed your own projects, try our free lessons learned template for Excel . Use it to identify what worked, what didn’t work, various impacts and what you can do better next time. Download yours for free today.

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.

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 on 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?

5 famous IT project failures – and how you can avoid their pitfalls

Ever had an IT project go over time or over budget?

Feature creep, insufficient training and overlooking stakeholders – the major culprits for why IT projects fail routinely crop up. The following five prominent examples are no exception. They have all failed publicly – some spectacularly – but serve as useful lessons to learn for anyone embarking on their own project, whatever the scale.

1. Sainsbury's warehouse automation

The UK supermarket giant embarked on a mammoth project to install an automated fulfilment system in their Waltham Point distribution centre. Serving most of London and the south east, the barcode-based system was supposed to streamline operations and improve efficiency.

From the initial installation in 2003, there were what were described as ‘horrendous’ errors in reading barcodes. Nevertheless, Sainsbury’s claimed that the system was working as intended in 2005. Two years later, they decided to scrap the entire project, writing off more than £150 million in IT costs.

What’s the lesson? Don’t ignore the initial phases. Problems left unaddressed at roll-out will only get worse over time – not better.

2. Apple's Copland operating system

Apple hasn’t always been phenomenally successful. When MS Windows 95 was released, the existing Mac System 7 simply couldn’t compete with its dynamic memory allocation and multitasking. Apple set out to develop a new OS in-house, with the aim of releasing a better System 8 by 1996.

It’s become known as a classic example of feature creep. As Apple refocused its resources on the new OS, project managers began to push for their products to be incorporated into System 8, derailing the project’s original scope.

Apple did eventually release System 8 to developers, but it was so unstable it did little to compete with MS Windows or boost Apple’s reputation. Before launching another developer release, Apple decided to bin System 8 and look elsewhere for their next OS – which led to the purchase of NeXT and the technology that became Mac OS X.

What’s the lesson? Project creep can take the whole thing down. Stay focused on your project’s original goals.

3. FozMeyer's ERP project

In the early 90’s, FoxMeyer was a major player in pharmaceuticals distribution in the US, worth around $5 billion. Aiming to improve efficiency, FoxMeyer bought an SAP system, together with warehouse automation technology, and brought in consultants to integrate the two. What was supposed to be a $35 million major IT project eventually became the business’ downfall. By 1996, the company was declared bankrupt.

There was a litany of reasons for failure. FoxMeyer set an unrealistic time frame: a total of 18 months to transform all their distribution systems. Warehouse employees whose jobs were under threat from the rise in automation were, unsurprisingly, unsupportive. After a series of redundancies, the first warehouse to be fully automated experienced widespread sabotage, with stock damaged and orders left incomplete. The new system also turned out to be less useful than the one it replaced. The SAP system was processing around 10,000 orders a night, compared to 420,000 under the old mainframe. FoxMeyer also accused their consultants and SAP of using the project as a training ground for new employees, rather than providing their best expertise.

What’s the lesson? No one plans failure. But you should plan for it – would your business be resilient enough to survive if the project was unsuccessful?

4. Nest's software refresh

In 2016, Nest (the Google-powered smart thermostat) released a catastrophic software update that literally left customers in the cold. A fault in the update forced the device’s batteries to run out, leaving it unable to control temperature and customers without heating or hot water in the middle of winter.

It was quick to roll out another update, solving the issue for most users. Understandably, though, the failure left some customers feeling frosty towards Nest.

What’s the lesson? Test, test and test again. Before releasing an update or implementing any kind of new system, never scrimp on the testing process.

5. US Census Bureau's remote devices 

In a $600 million contract, the US Census Bureau bought half a million handheld devices to automate the 2010 census. Since then, project costs have more than doubled and a testing session found that the devices frequently froze or failed to retrieve mapping coordinates. Some devices even had the same ID number, overwriting one another’s data. A report found that ‘the final cost is unpredictable, and immediate, significant changes are required to rescue the programme’.

It’s hard to pinpoint what went wrong, but the US Census Bureau’s dogged persistence in seeing the project through even after initial testing showed major flaws meant that remedial costs spiralled.

What’s the lesson? Have a plan B. Be prepared for failure by creating a contingency strategy, and know when to use it.

Of course, we’re writing about these examples because they had sufficient scale and notoriety to be reported publicly. For most businesses, the size of transformation may be smaller, but the potential pitfalls are just as significant.

From network upgrades and new servers, to finding and implementing the right software and systems, it pays to bring in the experts. At Ratcliff IT , we have more than 15 years’ experience of delivering projects for London’s small businesses.

Get in touch to find out how we can help your business.

Copyright © 2023 Ratcliff IT. All Rights Reserved

For IEEE Members

Ieee spectrum, follow ieee spectrum, support ieee spectrum, enjoy more free content and benefits by creating an account, saving articles to read later requires an ieee spectrum account, the institute content is only available for members, downloading full pdf issues is exclusive for ieee members, downloading this e-book is exclusive for ieee members, access to spectrum 's digital edition is exclusive for ieee members, following topics is a feature exclusive for ieee members, adding your response to an article requires an ieee spectrum account, create an account to access more content and features on ieee spectrum , including the ability to save articles to read later, download spectrum collections, and participate in conversations with readers and editors. for more exclusive content and features, consider joining ieee ., join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of spectrum’s articles, archives, pdf downloads, and other benefits. learn more about ieee →, join the world’s largest professional organization devoted to engineering and applied sciences and get access to this e-book plus all of ieee spectrum’s articles, archives, pdf downloads, and other benefits. learn more about ieee →, access thousands of articles — completely free, create an account and get exclusive content and features: save articles, download collections, and talk to tech insiders — all free for full access and benefits, join ieee as a paying member., lessons from a decade of it failures, the takeaways from tracking the big it debacles of the last 10 years.

Robert N. Charette is a Contributing Editor and an acknowledged international authority on information technology and systems risk management.

Ten years ago, IEEE Spectrum published “ Why Software Fails ,” an article that examined the underlying causes of notable project failures. A couple of years later, we started the Risk Factor blog, with the goal of tracking technology failures both large and small.

To commemorate the last decade’s worth of failures, we organized and analyzed the data we’ve collected. We cannot claim—nor can anyone, really—to have a definitive, comprehensive database of debacles. Instead, from the incidents we have chronicled, we handpicked the most interesting and illustrative examples of big IT systems and projects gone awry and created the five interactives featured here.

Each reveals different emerging patterns and lessons. Dive in to see what we’ve found. One big takeaway: While it’s impossible to say whether IT failures are more frequent now than in the past, it does seem that the aggregate consequences are worse.

Lesson 1: The Staggering Impact of IT Systems Gone Wrong

Lesson 2: overcomplexifying, underdelivering, lesson 3: the life cycles of failed projects, lesson 4: the it failure blame game, lesson 5: monuments to failure.

The world has relied on large-scale IT systems for decades, but we still haven’t learned how to prevent and avoid major glitches and failures. Here at IEEE Spectrum , we’ve been writing about such failures for 10 years (first in the oft-cited article “ Why Software Fails ,” and later in the Risk Factor blog).

Now we’re taking a step back to look at the bigger picture. We’ve scoured our archives to create a rogues’ gallery of the most notable, interesting, and emblematic failures from the past decade. We’ve included a diverse assortment of failures, which means there’s no single metric for measuring their impact. Some, like failed IT system upgrades or modernization projects, have straightforward financial consequences. Others, like operational outages and disruptions, are better measured by the time wasted and the number of people affected.

Keep in mind that the failures below are just the tip of the iceberg. They’re just a tiny fraction of the hundreds of incidents we’ve covered in Risk Factor, and an even smaller fraction of the global total. A complete list would be several orders of magnitude larger.

LESSON 1 INTERACTIVE

Explore the many ways in which it failures have squandered money, wasted time, and generally disrupted people’s lives.

As hard as it is to build IT systems in the first place, it’s arguably even more difficult to maintain them properly over time. In many government agencies, decades of neglect have resulted in a tangled mess of poorly understood and poorly implemented systems that limit operational effectiveness and efficiency. In the past decade, we’ve seen numerous attempts to combine the functionality of such legacy systems into a single modern replacement system.

That’s easier said than done. In nearly every case, such an effort turns out to be more difficult than originally thought. It’s not surprising, because each additional legacy system that needs replacing comes with its own unique challenges and hidden traps. We were curious to see if there’s a limit to the number of systems that can be practically combined.

Below, we’ve plotted the starting expectations and end results of several modernization efforts from the past few years. Nearly all exceeded their initial budget estimates, and many delivered a tiny fraction of their expected functionality (or failed to provide any functionality at all). Longer lines generally indicate greater relative failure.

LESSON 2 INTERACTIVE

See how complex projects trying to replace multiple systems with one can lead to none.

IT projects rarely fail all at once. Instead, these failures tend to snowball, growing larger and more hopeless as time goes on. Along the way, the definition of success is prone to mutation, as deadlines get pushed back and budgets increase. That’s how a project can launch “ahead of schedule” even if it’s more than three years late.

To illustrate this evolution toward catastrophe, we’ve reconstructed the budget and deadline history of a handful of the most egregious IT project debacles of the last decade.

LESSON 3 INTERACTIVE

Explore cases when even more money and more time couldn't prevent project disasters.

When IT systems fail, there’s always a reason. If you dig deep enough, at the root of any problem are human decisions: sloppy code, insufficient testing, poorly understood dependencies, and incorrect assumptions. Yet when we read about (and report on) failures, the language we use tends to assign blame to inanimate technology that can’t defend itself or get fired.

From our archive of failure coverage we’ve extracted verbatim excerpts that tried to assign blame or identify the cause of a failure. You’re likely to notice some trends about blame and accountability.

LESSON 4 INTERACTIVE

Try to match failures and glitches with their reported causes.

The final lesson to take away from our 10-year look back is how little has changed since IEEE Spectrum’s 2005 special issue on software failure . The project risk factors that can quickly lead to project death haven’t changed. This graveyard is a testament to unrealistic and unarticulated project goals, badly defined system requirements, unbounded project complexity, poorly designed human interfaces, sloppy development practices, poor project management, vicious stakeholder politics, and unbridled commercial pressures, to name but a few.

If you’re an IT executive, programmer, or project manager, you might find yourself whistling past this graveyard of some of the most expensive IT project failures of the last decade. There’s about $70 billion worth of project deaths commemorated here, just a small subset of all the dearly departed projects we have covered in the Risk Factor blog. We haven’t even tried to compute the costs involving those projects which may be, like Frankenstein’s monster, technically alive, but would be better off dead for the all the negative value they create.

Explore the graveyard by hovering over tombstones to bring up basic info about the failed system or project. You can take a deeper dive by clicking on the headline to follow the link to the original post.

LESSON 5 INTERACTIVE

The cadavers of dead it projects are buried under mounds of cash.

The Making of “Lessons From a Decade of IT Failures”

Why and how we’re looking back at a decade’s worth of IT debacles

We Need Better IT Project Failure Post-Mortems

It’s hard to find trustworthy data about IT debacles

• Why Software Fails - IEEE Spectrum ›
• Who Killed the Virtual Case File? - IEEE Spectrum ›
• The Making of "Lessons From a Decade of IT Failures" - IEEE ... ›
• Five Enduring Government IT Failures - IEEE Spectrum ›
• 2021 Cybersecurity and IT Failures Roundup - IEEE Spectrum ›
• IT failures in the financial services sector ›
• 8 biggest IT disasters of 2021 | CIO ›
• The biggest software failures in recent history | Computerworld ›

Robert N. Charette is a Contributing Editor to IEEE Spectrum and an acknowledged international authority on information technology and systems risk management. A self-described “risk ecologist,” he is interested in the intersections of business, political, technological, and societal risks. Charette is an award-winning author of multiple books and numerous articles on the subjects of risk management, project and program management, innovation, and entrepreneurship. A Life Senior Member of the IEEE, Charette was a recipient of the IEEE Computer Society’s Golden Core Award in 2008.

Joshua J. Romero is a software developer and journalist. A former IEEE Spectrum senior editor, he holds a bachelor’s degree in astronomy and physics from the University of Arizona and a master’s in journalism from New York University.

Edith Clarke: Architect of Modern Power Distribution

Sea drones in the russia-ukraine war inspire new tactics, notice to membership, related stories, software sucks, but it doesn’t have to, ai-powered proof generator helps debug software, gpus can now analyze a billion complex vectors in record time.

• 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:, tempus resource version 9.1 release.

We are thrilled to announce the release of Tempus Resource Version 9.1!…

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…

ProSymmetry LLC

2000 Auburn Drive, Suite 460

Beachwood, OH 44122

© 2024 ProSymmetry. All Rights Reserved

Failed projects: 7 examples and lessons learned

A project can fail for any number of reasons. From missed deadlines to improper resource management , there are countless potential pitfalls. Fortunately, you can learn from others’ mistakes, so you don’t have to make your own. 

Let’s peel back the layers and explore the causes behind some high-profile failed projects. You’ll discover insights to help you avoid these missteps in your own work.

Why do projects fail?

Initiatives can fall short for countless reasons. Still, common patterns emerge when examining failed projects. Here are some reasons for common project flops:

Insufficient preparation: Some project managers overlook essential project management principles, such as goal setting and project planning. Nebulous or unrealistic goals set a project up for failure from the start. Without clear definitions and prioritization of personal, departmental, and organizational objectives, a team may miss targets.

Disorganization and miscommunication: Even team members who possess the necessary skills and expertise can’t fulfill their potential without organization. If the project manager doesn’t foster effective communication among team members and stakeholders, misunderstandings and missed deadlines will ensue. Additionally, uncertainty in project team roles and responsibilities leads to conflict and gaps in accountability.

External interference: Sometimes, problems originate outside the team. Upper management may interfere, imposing scope creep or delaying essential tasks. Regulations and unforeseen policy changes may halt progress. Shifts in the market and consumer preferences can also threaten project success, especially when a team hasn’t conducted comprehensive market research.

7 examples of failed projects

Examining historic project failures can illuminate the most common pitfalls between you and success. These project failure case studies offer valuable lessons, highlighting the importance of proper project planning .

1. The Concorde supersonic passenger jet

The airline industry has seen its share of failed projects, often due to overambitious plans and inadequate market research. A prominent example is the now-defunct Concorde supersonic airliner.

The Concorde was a supersonic passenger airplane developed in the 1960s as a joint venture between the United Kingdom and France. It was designed to revolutionize air travel by reducing flight times, allowing passengers to cross the Atlantic in just a few hours. However, only 14 Concorde aircraft entered service before the line was retired in 2003.

What went wrong? 

Although it was a marvel of engineering, the Concorde faced multiple challenges preventing long-term commercial success.

The aircraft’s operation was prohibitively expensive due to high fuel consumption and maintenance needs, leading to high fares. With only around 100 seats, it could not compete with larger jets that had better economies of scale. The Concorde was also very noisy, leading to operational restrictions and limited routes. The final blow came with a catastrophic crash in 2000, which raised significant safety concerns and likely hastened its retirement. 

Project management lessons

Concorde’s failure teaches us that you must balance a project’s scope with its potential benefits. Project managers underestimated the costs and overestimated how much people would pay for faster travel. Lofty goals without realistic market assessments led to project failure.

2. The Y2K Problem

The Y2K problem, also known as the Millennium Bug, was a software glitch that garnered widespread attention as the year 2000 approached. Many computer systems were programmed to store the year as two digits (e.g., “99” for 1999). This led to concerns that these systems would interpret the year 2000 (“00”) as 1900, causing malfunctions.

An ambitious project aimed to update and fix these systems to prevent potential failures in critical infrastructure, including banking, utilities, and government operations. 

Organizations spent billions of dollars upgrading and patching systems worldwide to address the Y2K issue. The anticipated catastrophic failures largely did not occur – even in countries that didn’t invest in fixes – leading some to view the extensive efforts as an overreaction.

The Y2K problem demonstrates that better foresight can prevent chaos and save money. This case study highlights the importance of anticipating issues and keeping a level head during crises. Poor risk management and system design were big problems.

3. Sony Betamax

Sony launched its Betamax cassette recorder in 1975, confident that its superior quality would lead to market dominance. However, because of their high quality, the first Betamax tapes only offered a one-hour recording time. In addition, the technology was proprietary, limiting which companies could produce compatible devices and raising its price.

In contrast, JVC, another electronics giant, launched the VHS format in the late 1970s and licensed it widely, enabling greater market penetration. VHS tapes initially offered two-hour recording times, enough to record a feature-length film on one cassette. 

What went wrong?

Despite Betamax’s superior technology and earlier market entry, it lost to VHS, which was cheaper, easier to use, and offered longer recording times. Sony’s decision to keep Betamax exclusive limited its accessibility and appeal to consumers. Additionally, JVC’s strategic partnership with American motion picture companies helped establish VHS as the go-to format for home video recording and rental. 

Betamax’s failure shows that superior technology doesn’t guarantee success. To capture the market, products must be affordable and user-friendly. Team members must understand and address customer needs and preferences to ensure the long-term success of any project.

4. Crystal Pepsi

Crystal Pepsi, a clear cola, was launched in 1992 with great fanfare. The project team was hopeful Crystal Pepsi would outshine the competition, specifically Coca-Cola. It was marketed as a “healthier” soda option that removed the caramel coloring from the classic cola recipe, resulting in a clear, slightly less sweet beverage with fewer calories.

Although initially met with curiosity and interest, Crystal Pepsi struggled to maintain a lasting market share. Despite its innovative appearance, its taste was often described as bland and watery. 

David Novak, the executive responsible for the initiative, admitted to rushing the drink to launch and ignoring stakeholders’ concerns about taste and shelf-life. Coca-Cola also launched its own colorless cola, Tab Clear, diluting the novelty of clear colas. Due to poor sales and intense competition, PepsiCo discontinued Crystal Pepsi in early 1994, just two years after its launch. 

The Crystal Pepsi case study shows the importance of listening to feedback. It highlights the risks of poor project management and insufficient planning. Designers need adequate time to ensure product quality and satisfy customer preferences.

5. New Coke

Crystal Pepsi wasn’t the only soft drink to fall flat. Coca-Cola faced its own disaster with the introduction of  “New Coke” in 1985.

Despite being the world’s best-selling soft drink, Coca-Cola faced increasing competition from Pepsi-Cola, which was gaining market share through its aggressive “Pepsi Challenge” campaign. In blind taste tests, consumers often preferred the sweeter taste of Pepsi, leading Coca-Cola to believe its flavor needed an update.

When New Coke was introduced, the negative consumer reaction was swift and overwhelming. The backlash was so intense that the Coca-Cola Company reintroduced the original formula just 79 days later under the brand name “Coca-Cola Classic.” This move acknowledged the public’s strong preference for the original taste and highlighted customers’ emotional attachment to the brand.

The New Coke fiasco proves customers become emotionally attached to a brand. Good market research shouldn’t ignore brand loyalty when surveying consumer preferences. Even well-intentioned changes can fail if they disregard the deep-seated loyalty of the customer base.

6. McDonald’s Arch Deluxe Burger

In 1996, McDonald’s launched the Arch Deluxe Burger to attract a more sophisticated adult audience. Marketed as “The Burger with the Grown Up Taste,” the campaign featured children rejecting the gourmet burger to emphasize its appeal to adults. This was part of an effort to expand McDonald’s customer base beyond its traditional focus on kids and families.

What went wrong? Despite spending over $200 million on advertising, the campaign failed to resonate with McDonald’s core customers – kids and families. The Arch Deluxe was also more expensive than other menu items, which didn’t align with McDonald’s reputation for affordable options. After poor sales, the Arch Deluxe was completely removed from menus in 2000.

The Arch Deluxe Burger case study shows the importance of developing a product strategy that stays true to one’s customer base. Understanding and using customer data to guide decisions can save money and prevent product failures.

7. The Ford Edsel

In 1957, the Ford Motor Company debuted Edsel, a new division and brand of cars named after Henry Ford’s son. With high expectations, Ford invested over $250 million in developing a seven-model product line. Edsel targeted middle-class Americans, aiming to capture an untapped market for mid-priced cars. 

Edsel cars were too expensive to meet the needs of their intended market. Ford’s market research failed to recognize a shift in consumer preference toward compact, fuel-efficient vehicles by the time Edsel launched. Consequently, Edsel failed to achieve its sales goals and was discontinued shortly after its debut. 

The failure of Ford’s Edsel line provides a perfect example of misreading the market. Like McDonald’s Arch Deluxe burger, Ford targeted the wrong audience.

Additionally, this business case study proves product teams must balance innovation with cost consideration to meet the pricing needs of their target market.

How do we prevent projects from failing?

Successful project execution requires hard work, attention to detail, and successful project management. Here are some tips to help your projects succeed:

Set clear goals: Define what success looks like and ensure all team members understand the project’s objectives.

Avoid scope creep: Outline realistic limits and manage project changes to prevent uncontrolled growth.

Conduct thorough market research: Understand your market, customers, and competition to make informed decisions.

Facilitate effective communication: Maintain open communication among team members and stakeholders to address concerns and promote clarity.

Plan initiatives thoroughly: Create a comprehensive project plan that includes timelines, resources, and milestones. Conduct regular reviews and adjust the plan as needed.

Assign clear roles and responsibilities: Ensure everyone knows their tasks to avoid confusion and gaps in responsibility.

Monitor and manage risks: Proactively identify risks and develop mitigation strategies.

Use agile methodologies: Maintain an agile mindset in your organization. Break down projects into smaller tasks and deliver in cycles.

Remain flexible: Adjust your plans in response to new information or changing circumstances.

Conduct quality control: Review and test your product or service to ensure it meets quality standards.

Perform post-project review: After completing a project, conduct a review to identify successes and make improvements for future projects.

Final words

Projects fail for many reasons, but lessons from past mistakes can guide us toward success. Set clear goals, implement proper planning, and do your market research. By following these strategies, you can turn potential failures into triumphs. 

And you don’t need to do it alone. Tempo offers various project management tools that can streamline product development and rollout. Structure PPM helps you track and manage multiple projects and portfolios from one Jira-integrated dashboard. Strategic Roadmaps enables you to communicate your project priorities .

Explore the full suite of Tempo products and take your project management to the next level.

Related Articles

7 product release tips for a successful launch

9 product management challenges and how to solve them

10 mistakes most project managers make

Strategies for when you are smarter than your boss

What is capacity management, and why is it important?

Estimating time in project management: Tips and methodologies

What is change management? A guide for leaders

7 reasons strategic plans fail (and how you can avoid them)

Disrupt or be disrupted: Navigating disruptive technology

• Artificial Intelligence
• Generative AI
• Business Operations
• Cloud Computing
• Data Center
• Data Management
• Emerging Technology
• Enterprise Applications
• IT Leadership
• Digital Transformation
• IT Strategy
• IT Management
• Diversity and Inclusion
• IT Operations
• Project Management
• Software Development
• Vendors and Providers
• Enterprise Buyer’s Guides
• United States
• Middle East
• España (Spain)
• Italia (Italy)
• Netherlands
• United Kingdom
• New Zealand
• Data Analytics & AI
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Copyright Notice
• Member Preferences
• About AdChoices
• Your California Privacy Rights

Our Network

• Computerworld
• Network World

Why IT projects still fail

Despite strategic alignment among it and business leaders, technical and transformational initiatives still fall flat at an unacceptable rate. here’s how it can learn from its mistakes..

IT organizations have worked hard to get away from the problems that had plagued their past project delivery processes.

They have replaced expansive scopes, the waterfall methodology, and long timelines with iterative development, the agile approach, and multiweek sprints, hoping to avert the big failures that have littered IT’s history.

Those changes have indeed helped, but many IT projects still fail.

True, project failure no longer brings down the whole IT environment — as it might have done a few decades ago. Nor does it typically mean a new system doesn’t work at all and needs to be completely scrapped, another scenario from IT’s checkered project-delivery history.

Instead, failure today means an IT project doesn’t deliver some or all its expected benefits, according to CIOs, project leaders, researchers, and IT consultants. Or failure may mean a project doesn’t produce returns, runs so late as to be obsolete when completed, or doesn’t engage users who then shun it in response.

“Today, with the advances in agile, the definition of ‘failure’ has morphed,” says Te Wu, CEO and chief project officer of PMO Advisory, an associate professor at Montclair State University, and a Project Management Professional (PMP) who also serves as co-chair of the Project Management Institute’s development team on the portfolio management standard.

In other words, IT project failure now is more about missed marks than technological disasters.

Some studies bear that out. According to KPMG’s 2023 Technology Survey , 51% of the responding 400 US technology executives said they have seen no increase in performance or profitability from their digital transformation investments in the past two years.

Surveys and studies are inconsistent on the rate of IT project failures, but researchers confirm that the percentage of IT projects falling short continues to be higher than hoped.

So what’s going on? Why do IT projects continue to fail? There are some common culprits.

1. Lack of project management expertise

Workers are often tapped to take on extra work, and for IT workers that sometimes means being tasked to lead projects.

But those workers don’t necessarily have the expertise, training, or experience necessary to succeed in the project manager role, nor are they given enough time to learn what it takes to manage a project or to complete the extra project management tasks.

“We expect people who have no training to run projects. Or we expect managers who have a full-time job doing something else to also manage a project,” says Zach Rossmiller, CIO for the University of Montana.

Rossmiller knows the consequences of that approach as his IT department has had a history of doing as much.

“We’d have a couple hundred different projects going on and were expecting our managers to run them and run them efficiently,” he says. “If we had a project management office dedicated to running projects, I think we would have been a lot better off.”

Rossmiller is addressing this situation, with IT recently adding two project managers to its team. The addition of trained project management professionals is already delivering improvements, Rossmiller says, particularly in streamlining efforts and making project delivery more efficient.

That’s because trained project managers are better able to corral and schedule resources, coordinate staff schedules, and get everyone moving in the same direction — and do so across multiple projects, he says. They’re also more capable of implementing the governance needed to keep projects on target to deliver what’s expected and not let scope creep run up costs and schedules without adding additional value.

2. Little or no executive support

Another leadership problem that can tank an IT project: top-level indifference.

That scenario happens more than it should, veteran project leaders say.

“We have had meetings and project status reports where executives were asking, ‘Why are we doing this?’ They truly didn’t grasp the importance of where we were going,” says Karla Eidem, a Project Management Professional and PMI’s North America regional operations manager.

Eidem says a lack of executive support can happen even when the project has a business unit sponsor — a situation which indicates that the project, while maybe a localized priority, isn’t aligned to organizational goals.

In such cases, there’s a need to realign.

“It may mean asking the [executive team]: Given all the facts that are laid in front of you, is this project a go or no-go? Sometimes it is a no-go for some reason, but that decision has to be made,” Eidem says, explaining that executive support is crucial for success because it ensures that the resources — money, people power, attention, and so on — will be made available.

3. No business sponsor accountability

Similarly, releasing the project’s business sponsor from accountability for the tech project’s success — and putting it all on IT — can doom the project.

“You really want to have good project leadership, and that starts with the person who wrote the business case being the sponsor, making sure the project is done realistically and being a champion,” Wu says .

Business sponsors, like executives, play an important role in articulating the business reasons for the project, establishing the expected benefits, and rallying resources to the cause. Their support also signals to staff the project’s importance, which helps drive adoption of new technologies and any associated process changes, Wu adds .

4. Lack of business sponsor engagement

A supportive and informed business sponsor can remove roadblocks and bottlenecks that arise, they can escalate problems to help get them solved quickly, and they can champion successes to build momentum and excitement for the changes ahead, Eidem says.

Those benefits go away when a business sponsor is MIA.

Eidem has seen that happen.

She was working on a complex multilocation software implementation that was steadily progressing until she needed that business sponsor to bring together regional divisions for the next step in the process. The sponsor dropped the ball on that, leaving some operational teams in the dark about what was happening and others questioning why they had to participate.

“We were seeing that information wasn’t cascading, and there was some resistance in some areas,” Eidem says, adding that the situation jeopardized the project’s forward momentum.

Eidem says she discovered that the business sponsor had been pulled away from the project by another big issue and as a result wasn’t as attentive as needed in delivering information about the project to the impacted regions.

“I needed the sponsor to be focused on this project, but he had too many other priorities. So I had to be clear: As an organization, we said this project was the No. 1 priority,” she says.

To prevent the project from collapsing, Eidem scheduled more one-on-one meetings with the sponsor to build a stronger relationship and to allow for more direct communication about the project’s needs, which helped refocus the sponsor and get the project rolling again.

5. Not involving all stakeholders

IT project manager Krista Phillips recounts one case in which a large multinational corporation implemented a new technology across its companies but caught one division completely unaware of the ongoing implementation work.

Turns out that specific division had been left out of all the planning and project processes.

“I don’t know how the [project leaders] missed that, but they missed a whole unit. So when the system went live, they were like, ‘What is this?’ That caused the project team to miss scope,” says Phillips, a PMP holder serving as president of PMI’s Pikes Peak Regional Chapter in Colorado.

Phillips acknowledges that project teams don’t usually overlook entire divisions, but they sometimes fail to identify and include all the stakeholders they should in the project process. Consequently they miss key requirements to include, regulations to consider, and opportunities to capitalize on.

6. Not enough resources or not the right ones

Some project leaders list the prevailing do-more-with-less expectation as another reason for failed IT projects today. They say this mentality generally leads to project teams lacking the resources that they need to get the desired work done on time.

“Everybody is very concerned with that bottom line, and they should be concerned about that, but the other side of that is they’re expecting a few people to do a lot of things,” Phillips says.

For example, she says workers are frequently assigned to multiple projects simultaneously, and many are assigned to that project work on top of their existing duties. As a result, these workers are pulled in too many different directions.

Others say enterprise leaders underestimate costs and the time required to complete the work or they fail to allocate the right talent to the team (thinking untrained or inexperienced workers will develop the required skills on the job), even as project managers surface the consequences of under-allocating the money, talent, and time needed for success.

Experienced project leaders say it’s crucial for IT project managers and CIOs themselves to ensure that the business sponsors and C-suite executives get the information they need to be realistic about the required resources, support, and schedules.

Those project leaders, however, also acknowledge that’s a continuously tough task.

To help, they advise implementing a portfolio management program to bring visibility into all the work happening and to break down project siloes that can sometimes contribute to that under-allocation of resources.

“An emphasis on portfolio management can close a lot of the productivity pain,” Wu says. “Do fewer things, too, and do them well; that’s a hallmark of portfolio management.”

7. Lack of in-person collaboration

Wu acknowledges the benefits that the shift to widescale remote work has brought, such as the ability to scale project work globally. But he also sees how the virtual work environment can create pain points in project delivery.

To start, Wu says he has found virtual teams have a harder time coming together to solve the harder problems. “I think when it comes to tackling module tasks, virtual is good. But solving big, complex problems, there’s only so much you can do over Zoom,” he says.

Wu says he also sees some teams struggle to bond in virtual work environments. “You sacrifice the human connection,” he adds.

Consequently, Wu says work can take longer; solving a problem that would take an hour working together face to face might take 90 minutes in a virtual environment. And handoffs that went quickly and smoothly when teams were physically side by side now often require more time to coordinate across computer screens.

“People are spending more time to get to the same net effectiveness, and I think human relationships are starting to fray,” he says, noting that newer employees in particular may be missing out on the informal mentoring and learning that happens in person when they can readily see good role models and good work patterns to emulate.

Wu says these dynamics in turn put more work onto project managers who must “put in far more work and time to be collaborative and to communicate,” adding that he hasn’t yet seen any remedies to these challenges. “I know the problem, but I don’t have a solution,” he says.

8. Disjointed handoffs

At some point a project moves into production, project managers move on, and the IT initiative is then expected to show its value.

Those steps in many organizations mean that projects — and any remaining problems with them — are still being tossed over the fence, leading to disjointed accountability that does not lead to success, Wu says.

“If the business case is one party, and the project manager is another party, and then people managing the results of the project, who are even further removed from the business case for the project, are another party, then you can see the disjointed connections,” Wu says.

That disjointedness can mean missed opportunities, wrong turns, and miscommunications that lead to final products that are suboptimal.

Wu says that disjointedness can happen even in organizations using Agile and DevOps methodologies, saying that those “are just different ways of carrying the water from one side to another.”

He adds: “DevOps can address a change very quickly, but whether that change is the right change or if it delivers ROI is a very different question.”

To counteract that, Wu and others point to the need for good management and strong project governance that continually link the project’s business case to its deliverables throughout the project work as well as through the implementation and adoption phases.

Related content

Three trends showing how all-optical networks drive digital intelligence, securing confidential and protected data today. exploring vmware’s vcf sovereign cloud solution (v2)., micro logic: high-performance canadian sovereign cloud for a hybrid future, strategies to combat genai implementation risks, from our editors straight to your inbox, show me more, cybersecurity genai features: are they worth the money.

Accenture acquires Excelmax to bolster chip design expertise

Can a technology mindset save Paramount?

CIO Leadership Live Middle East with Saqib Chaudry, Chief Information Officer, Johns Hopkins Aramco Healthcare (JHAH)

CIO Leadership Live Middle East with Nithin Geo Thomas, Head of IT Amity University Dubai

CIO Leadership Live Middle East with John Mankarios, VP IT at Q Invest

Cloud Insights for Tech Leaders: Overcoming Challenges, Maximizing ROI, and Driving Growth

Sponsored Links

• The cloud shouldn’t be complicated. Unlock its potential with SAS.
• Everybody's ready for AI except your data. Unlock the power of AI with Informatica
• Get Cisco UCS X-Series Chassis and Fabric Interconnects offer.
• Everyone’s moving to the cloud. Are they realizing expected value?

• Custom Software Development
• ERP/CRM Development
• AI and Machine Learning
• Extended Reality (XR)
• Mobile App Development
• Cloud Solutions & DevOps
• Client Successes
• MLM / Network Marketing
• Retail / eCommerce
• Construction
• Transportation / Logistics
• HR / People Operations
• Consumer Services
• AI Transformation Studio
• SayHey Messenger® Enterprise Messaging App
• The Foundations Program
• 7TRAC Resources Accelerator
• Blogs & Resources
• eBooks & Whitepapers
• Business-First Philosophy
• Development Process
• Tenured Team
• Culture of Curiosity

Digital Transformation Failure Examples – Lessons Learned from Causes of Failed AI Projects, Process Automation

“Why do most Digital Transformation projects fail?” It’s a common question that arises when business leaders hear the statistics: 7 in 10 Digital Transformation projects are ultimately considered failures , whether it’s in terms of ROI, user adoption or overall profitability.

So why is it that just 30% of Digital Transformation projects succeed? And how can you avoid the pitfalls leading down the path to DT failure?

Kodak as a Digital Transformation Failure Example Involving Late Deployment

Kodak is a rather sad example of Digital Transformation failure because the brand maintained icon status within the film photography industry for so long. But Kodak failed to embrace the movement toward digital photography in time. Their market share plummeted over a span of several years when they ought to have been engaging film-turned-digital photography enthusiasts with new, innovative Digital Transformation development projects.

By the time Kodak finally got on board with the digital photography movement, it was too late and they filed bankruptcy in 2012 . Kodak has turned into a case study and unfortunate example of what happens when your Digital Transformation deployment is all wrong in terms of timing.

The GE Digital Transformation Failure Example Involving AI and Bad Machine Learning Models

Kodak isn’t the only iconic company to see a major Digital Transformation fail. GE also saw a significant DT failure; one that has served as a great case study.

GE did many things right by hiring skilled Digital Transformation developers and investing a significant sum of money into their new technology. Formed in 2015, GE Digital was designed to centralize the company’s digital initiatives. GE Digital endeavored to become one of the world’s top ten software companies by 2020. But GE spread their resources too thin and the jump to cloud technology was the initiative’s final nail in the coffin. Postmortem analysis has attributed the GE Digital Transformation failure to a number of factors, including the following.

• Lack of clarity on the true definition of Digital Transformation.
• Lack of buy-in from GE management.
• Lack of phased development. Instead, GE tried to do it all at once.
• Lack of quantifiable KPIs to evaluate success — or lack thereof — over the course of the Digital Transformation initiative.
• Lack of a management team to support the new GE initiative.

Microsoft as a Digital Transformation Failure Example Involving AI and Bad Machine Learning Models

Microsoft is a relatively recent example of Digital Transformation failure involving one of the trendiest new technologies: artificial intelligence or AI. It has been widely reported that Microsoft fired hundreds of editors — some say they laid off their entire editorial team — which were subsequently replaced by artificial intelligence to manage the company’s news articles on popular browser homepage sites such as MSN.

AI populated the Microsoft news sites with fake news, some of which was downright insulting. One obituary called a former basketball player “useless.” Other stories were all-out fabrications, such as an article that claimed President Joe Biden fell asleep at an event that never occurred. These Microsoft AI editorial fails highlight the need for an in-depth AI model development and ongoing monitoring , lest you find yourself facing a major Digital Transformation risk management issue.

Common Causes of Failed Digital Transformation Projects

Good Digital Transformation risk management is the key to maximizing your chances of long term success and a healthy ROI that remains stable or grows over time. But it’s far easier — and more conducive to a robust ROI — to begin your project with a full understanding of the most common causes of Digital Transformation failure.

Lack of a Well-Developed Project Scope

A successful Digital Transformation project requires a well-defined scope, with detailed specs for all aspects of the development project. The solution comes in the form of a detailed Business Requirements Document (BRD) and / or Software Requirements Document (SRD) .

Scope Creep Leading to Unexpected Project Costs

Some Digital Transformation projects fail because they’re never finished as a result of scope creep and poor project planning. This too can be avoided through the development of a well-considered BRD and / or SRD at the very start of the project. Some DT projects can also benefit from a phased development strategy that aligns with both the organization’s budget and the users’ needs or expectations for the technology.

Lack of Well-Defined Digital Transformation KPIs

All too often, a project lacks well-defined key performance indicators or KPIs . In these cases, it’s virtually impossible to accurately measure success. This is true whether it’s through Digital Transformation project ROI, user adoption rates, or improvements in terms of efficiency, productivity and overall performance.

It is possible to backpedal a bit by developing Digital Transformation KPIs well after a project’s deployment, although this is never as effective as coming into the project with a well-developed set of KPIs in-hand.

Lack of User Adoption Due to Poor Training and / or Engagement

Poor user adoption rates can spell failure for even the most well-developed Digital Transformation project. A lack of user training can result in a situation whereby an organization’s new technology simply isn’t used to its full potential. This underscores the importance of an employee training program or tutorials for public-facing platforms.

Scope also plays a role. Don’t try to be all things to all people. Instead of developing a mobile app with dozens of features, functions and tools, develop a mobile application with more narrow, precise capabilities that cater to a very precise type of user with a precise objective in mind.

Lessons Learned From Digital Transformation Failure Examples… And How to Succeed

At 7T, we’ve developed an eBook that outlines the most common causes of Digital Transformation failure and how these issues can be avoided. What’s more, we’ve earned a reputation as one of the top Dallas Digital Transformation companies, with a Digital Transformation development process that maximizes your chances of success with a problem → solution approach. We’ve found that this works whether it’s a machine learning-powered artificial intelligence development project, business process automations, mobile app development or another form of Digital Transformation. It all begins with a well-thought-out Digital Transformation strategy and a business requirements document that outlines the specs for your project, the user needs and the problems that you’re trying to solve through the implementation and deployment of new technologies.

The Digital Transformation development team here at 7T is guided by the approach of “ Digital Transformation Driven by Business Strategy .” As such, the 7T development team works with company leaders who are seeking to solve problems and drive ROI through Digital Transformation and innovative business solutions such as multimodal machine learning-powered AI implementations.

7T has offices in Dallas , Houston and Austin , but our clientele spans the globe. If you’re ready to learn more about AI development solutions and other Digital Transformation technologies, contact 7T today .

Reach out to our team today! hbspt.forms.create({ portalId: "1760668", formId: "7a1d929d-d378-443a-a048-9888a5e199a1" });

Related posts.

Ready for a Digital Transformation?

Supercharge your Digital Transformation efforts, whether you're a startup, established enterprise or anything in between.

Get exclusive content to grow your business with our latest blogs and resources, sent directly to your inbox!

• Privacy Overview
• Strictly Necessary Cookies
• 3rd Party Cookies

7T uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.

If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.

7T uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.

Keeping this cookie enabled helps us to improve our website.

Please enable Strictly Necessary Cookies first so that we can save your preferences!

• 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

Why Good Projects Fail Anyway

• Nadim Matta
• Ron Ashkenas

When a promising project doesn’t deliver, chances are the problem wasn’t the idea but how it was carried out. Here’s a way to design projects that guards against unnecessary failure.

Reprint: R0309H

Big projects fail at an astonishing rate—more than half the time, by some estimates. It’s not hard to understand why. Complicated long-term projects are customarily developed by a series of teams working along parallel tracks. If managers fail to anticipate everything that might fall through the cracks, those tracks will not converge successfully at the end to reach the goal.

Take a companywide CRM project. Traditionally, one team might analyze customers, another select the software, a third develop training programs, and so forth. When the project’s finally complete, though, it may turn out that the salespeople won’t enter in the requisite data because they don’t understand why they need to. This very problem has, in fact, derailed many CRM programs at major organizations.

There is a way to uncover unanticipated problems while the project is still in development. The key is to inject into the overall plan a series of miniprojects, or “rapid-results initiatives,” which each have as their goal a miniature version of the overall goal. In the CRM project, a single team might be charged with increasing the revenues of one sales group in one region by 25% within four months. To reach that goal, team members would have to draw on the work of all the parallel teams. But in just four months, they would discover the salespeople’s resistance and probably other unforeseen issues, such as, perhaps, the need to divvy up commissions for joint-selling efforts.

The World Bank has used rapid-results initiatives to great effect to keep a sweeping 16-year project on track and deliver visible results years ahead of schedule. In taking an in-depth look at this project, and others, the authors show why this approach is so effective and how the initiatives are managed in conjunction with more traditional project activities.

The Idea in Brief

Big projects fail at an astonishing rate—well over half, by some estimates. Why are efforts involving many people working over extended periods of time so problematic? Traditional project planning carries three serious risks:

• streams Planners leave gaps in the project plan by failing to anticipate all the project’s required activities and work .
• properly Project team members fail to carry out designated activities .
• results Team members execute all tasks flawlessly—on time and within budget—but don’t knit all the project pieces together at the end. The project doesn’t deliver the intended .

Manage these risks with rapid-results initiatives : small projects designed to quickly deliver mini-versions of the big project’s end results. Through rapid-results initiatives, project team members iron out kinks early and on a small scale. Rapid-results teams serve as models for subsequent teams who can roll out the initiative on a larger scale with greater confidence. The teams feel the satisfaction of delivering real value, and their company gets early payback on its investments.

The Idea in Practice

Rapid-results initiatives have several defining characteristics:

• scale—The initiatives produce measurable payoffs on a small .

Example: 

The World Bank wanted to improve the productivity of 120,000 small-scale farmers in Nicaragua by 30% in 16 years. Its rapid-results initiatives included “increase pig weight on 30 farms by 30% in 100 days using enhanced corn seed.”

• activities—The initiatives include people from different parts of the organization—or even different organizations—who work in tandem within a very short time frame to implement slices of several horizontal—or parallel-track—activities. The traditional emphasis on disintegrated, horizontal, long-term activities gives way to the integrated, vertical, and short-term. The teams uncover activities falling in the white space between horizontal project streams, and properly integrate the .

Take a companywide CRM project. Traditionally, one team might analyze customers, another select the software, a third develop training programs. When the project’s finally complete, though, it may turn out that the salespeople won’t enter the requisite data because they don’t understand why they need to. Using rapid-results initiatives, a single team might be charged with increasing the revenues of one sales group in one region within four months. To reach that goal, team members would have to draw on the work of all the parallel teams. And they would quickly discover the salespeople’s resistance and other unforeseen issues.

• results—The initiatives strive for results and lessons in less than 100 days. Designed to deliver quick wins, they more importantly change the way teams work. How? The short time frame establishes a sense of urgency from the start, poses personal challenges, and leaves no time to waste on interorganizational bickering. It also stimulates creativity and encourages team members to experiment with new ideas that deliver concrete .

Balancing Vertical and Horizontal Activities

Vertical, rapid-results initiatives offer many benefits. But that doesn’t mean you should eliminate all horizontal activities. Such activities offer cost-effective economies of scale. The key is to balance vertical and horizontal, spread insights among teams, and blend all activities into an overall implementation strategy. Example: 

Dissatisfied with its 8% revenue increase in two years, office-products company Avery Dennison launched 15 rapid-results teams in three North American divisions. After only three months, the teams were meeting their goals—e.g., securing one new order for an enhanced product with one large customer within 100 days. Top management extended the rapid-results process throughout the company, reinforcing it with an extensive employee communication program. As horizontal activities continued, dozens more teams started rapid-results initiatives. Results? $8 million+ in new sales, and $50 million in sales forecast by year-end.

Big projects fail at an astonishing rate. Whether major technology installations, postmerger integrations, or new growth strategies, these efforts consume tremendous resources over months or even years. Yet as study after study has shown, they frequently deliver disappointing returns—by some estimates, in fact, well over half the time. And the toll they take is not just financial. These failures demoralize employees who have labored diligently to complete their share of the work. One middle manager at a top pharmaceutical company told us, “I’ve been on dozens of task teams in my career, and I’ve never actually seen one that produced a result.”

• NM Nadim Matta is Head Catalyst and founding Board member of the Rapid Results Institute , a non-profit organization that pioneered the use of 100-Day Challenges to help communities and government agencies around the world make breakthroughs and accelerate progress on tough social issues.
• Ron Ashkenas is a coauthor of the Harvard Business Review Leader’s Handbook  and a Partner Emeritus at Schaffer Consulting . His previous books include The Boundaryless Organization , The GE Work-Out , and Simply Effective .

Partner Center

• PRINCE2 Agile®
• PRINCE2 Agile® German
• Management of Portfolios (MoP)®
• Management of Risk (M_o_R)®
• APMG-International AgilePM®
• APMG-International Change Management™
• APMG-International Better Business Cases™
• APMG International Project Planning & Control™ (PPC)
• APMG-International Managing Benefits™
• APMG-International PPS™
• Finance for Non Financial Managers
• APMG International Earned Value™
• Project Management Essentials
• Programme Management Essentials
• Portfolio Management Essentials
• Risk Management Essentials
• Certified Associate in Project Management (CAPM)®
• Project Management Professional (PMP)®
• Agile Certified Practitioner (PMI-ACP)®
• Risk Management Professional (RMP)®
• Program Management Professional (PgMP)®
• Scrum (Agile Business Consortium)
• Microsoft Project
• Praxis Framework™
• Online (with exam)
• Classroom (with exam)
• Blended learning (with exam)
• Virtual (with exam)
• Plus pack (with exam)
• The history of PRINCE2
• What should I study next?
• How can PRINCE2® 7TH Edition benefit you?
• What is PRINCE2 Infographic
• PRINCE2 Agile® definition
• PRINCE2 Agile® qualifications and training
• What should I do next?
• How PRINCE2 Agile® can benefit you?
• Understanding PRINCE2 Agile Whitepaper
• PRINCE2 Agile® F&P e-learning course outline: English
• PRINCE2 Agile Practitioner classroom course outline: English
• What is MSP® programme management?
• MSP® qualifications and training
• How MSP® can benefit you?
• MSP Benefits Plan
• MSP Risk Management Strategy
• MSP Blueprint
• Management of Portfolios (MoP)® qualifications and training
• How Management of Portfolios (MoP)® can benefit you?
• MOP Foundation & Practitioner Blended
• MoP Foundation Classroom
• MoP Foundation Online
• P3O® qualifications and training
• 10 Reasons to adopt P3O
• What is P3O and what can it do for you?
• P3O Foundation & Practitioner Blended
• Management of Risk (M_o_R)® definition
• Management of Risk (M_o_R)® qualifications and training
• Management of Risk (M_o_R)® history
• How Management of Risk (M_o_R)® can benefit you?
• How can M_o_R help you Manage Risk
• Applying M_o_R for Public services
• Corporate Governance and M_o_R
• MoV® definition
• MoV® qualifications and training
• MoV® history
• How MoV® can benefit you?
• MoV Foundation Online
• Online (without exam)
• APMG-International AgilePM® qualifications and training
• AgilePM Process Map
• AgilePM Foundation and Practitioner Blended
• AgilePM Foundation Online
• APMG-International Change Management™ qualifications and training
• How APMG-International Change Management™ can benefit you?
• Top 5 Tips Change Management & The Middle Managers
• APMG-International Change Management Practitioner Classroom
• APMG-International Change Management Foundation and Practitioner Classroom
• APMG-International Better Business Cases™ qualifications and training
• How APMG-International Better Business Cases™ can benefit you?
• APMG-International Managing Benefits™ qualifications and training
• How APMG-International Managing Benefits™ can benefit you?
• APMG-International Managing Benefits Practitioner Classroom
• APMG-International Managing Benefits Foundation and Practitioner Classroom
• APMG-International Managing Benefits Foundation Classroom Flyer
• Programme & Project Sponsorship (PPS) Classroom
• Programme & Project Sponsorship (PPS) Online
• Finance for Non Financial Managers qualifications and training
• Better Business Cases Practitioner Classroom Flyer
• Better Business Cases Foundation e-learning course outline
• APMG-International Better Business Cases Foundation & Practitioner Blended
• APMG International Earned Value™ qualifications and training
• How APMG International Earned Value™ can benefit you?
• APM definition
• APM qualifications and training
• RPP and ChPP information
• The APM Project Fundamentals Qualification Classroom Private
• The APM Project Fundamentals Qualification e-learning Private
• The APM Project Management Qualification (PMQ) Classroom Private
• Classroom (without exam)
• Certified Associate in Project Management (CAPM)® qualifications and training
• Project Management Professional (PMP)® qualifications and training
• How Project Management Professional (PMP)® can benefit you?
• Project Management Professional (PMP) classroom flyer
• Agile Certified Practitioner (PMI-ACP)® qualifications and training
• How Agile Certified Practitioner (PMI-ACP)® can benefit you?
• Program Management Professional (PgMP)® qualifications and training
• How Program Management Professional (PgMP)® can benefit you?
• Scrum (Agile Business Consortium) qualifications and training
• How Scrum (Agile Business Consortium) can benefit you?
• Praxis Framework™ qualifications and training
• Praxis Foundation course outline
• Praxis Practitioner course outline
• Praxis F&P course outline
• Agile and Scrum Foundation (ASF)
• Agile Scrum Master (ASM®)
• ITIL German
• Applied Business Architecture
• Service Management Essentials
• ITIL 4 FAQs
• ITIL 4 syllabus changes
• What is ITIL 4 Infographic
• Transforming IT Service Management Knowledge Into Practice With ITIL Practitioner
• The ITIL glossary of terms, definitions and acronyms
• ITIL Foundation Online
• Virtual (without exam)
• Certified Business Analysis Professional (CBAP®)
• Business Analyst
• BCS qualifications and training
• How BCS can benefit you?
• Certified Business Analysis Professional (CBAP®) qualifications and training
• How Certified Business Analysis Professional (CBAP®) can benefit you?
• Lean Six Sigma for Services
• Lean Six Sigma
• Lean Management
• Lean Six Sigma for Services qualifications and training
• How Lean Six Sigma for Services can benefit you?
• Lean Six Sigma for Services - Champion
• Lean Six Sigma for Services - Green Belt
• Lean Six Sigma for Services - Yellow Belt
• Automation Testing
• Practical Application Workshop
• Introduction to Cyber Security
• Cyber Security Expert
• Artificial Intelligence
• Robotic Process Automation
• Business Analytics
• Data Science
• Big Data and Hadoop
• Data Analyst
• Microsoft Azure
• Cloud Architect
• Digital Marketing
• Mobile Marketing
• Content Marketing
• Web Analytics
• Business Skills:
• Communication:
• Personal Effectiveness:

15% off e-learning, plus packs & blended courses

20% off virtual courses

• Blog categories
• Company Updates
• Learning and Development
• Diversity, Equality and Inclusion
• Project Management
• Software Testing
• Cloud Computing
• Mobile and Software Development
• AI and Machine Learning
• Big Data and Analytics
• Business and Leadership
• Business Analysis

10 failed projects and the lessons learned

By ilx team | 19 august 2019.

Every project teaches lessons with its successes and failures. Best practice courses highlight the importance of developing a mind-set of continuous learning from the outset of the project. In this blog we’ll look at 10 major public project failures and the lessons learnt from these mistakes.

Why should we analyse projects that failed?

Failed projects provide valuable lessons. Analysing failures can help to pinpoint weaknesses in project planning, execution, or team dynamics. By dissecting what went wrong, project teams can gain insights into the mistakes that were made and avoid repeating the same errors in the future.

Embracing failure as a learning opportunity fosters a culture of continuous improvement, which leads project teams to become more resilient, adaptable, and innovative.

10 projects that failed:

1. apple lisa.

In the early days of Apple, Lisa was the first GUI computer marketed at personal business users. It was supposed to be the first desktop computer that incorporated the now famous mouse, and a 5 MHz, 1MB RAM processor – the fastest of its kind back in 1983.

However, the project was a big failure. Only 10,000 computers were sold. It was such as failure that Steve Jobs was taken off the project and allocated to another project, the Macintosh. Apple Lisa overpromised and under-delivered, with a price-performance ratio that was significantly worse than had been expected.

Lesson learned:

The importance of stakeholder collaboration and transparency.

2. Crystal Pepsi

The early 1990s saw the trend for ‘light’ drinks emerge. In 1992, Pepsi launched Crystal Pepsi , a soft drink that tasted similar to regular Pepsi but was clear-coloured. Initially sales were good, mainly due to the curiosity factor, but soon dropped away to the point where Crystal Pepsi was withdrawn from the market just 2 years later.

The mistake of David Novak, creator of Cystal Pepsi — and Pepsi itself — was making too many assumptions about the product and market demand. Novak was even told by the bottlers that the drink needed to taste more like Pepsi. Unfortunately, he didn’t listen.

Don’t make assumptions about your audience. Leverage everyone’s expertise and verify statements before considering them fact.

3. Ford Edsel

It’s not often that Ford gets it wrong, but in the case of the Edsel , they failed on a big scale. Ford wanted to close the gap with General Motors and Chrysler. Having spent $250 million and 10 years developing the Edsel, by the time it came to the market the trend was for more compact cars.

Launched in 1957, the Edsel was considered overpriced, over-hyped, too big, and unattractive. By 1959, production was ceased.

Update a project’s business case and schedule during its lifecycle.

4. Computerised DMV

In the 1990s, the DMV tried to computerise their department to track drivers’ licences and vehicle registrations.

But after 6 years and $44 million, as well as ‘putting all their eggs into one basket’ with Tandem Computers, they discovered their computers were actually slower than the ones they replaced. On top of that, a state audit found that the DMV was violating contracting laws and regulations.

Processes should be followed, and any legal or regulatory constraints must be included in the project plan.

5. J.C. Penney’s 2011 rebrand

To wean customers away from their reliance on coupons, J.C. Penney introduced simpler price points and colour-coded price tags, and ran a marketing campaign to promote this strategy.

Customers found the new pricing structure confusing, and many items advertised never went on sale. Revenues dropped significantly and J.C. Penney had to admit failure.

The impact a lack of stakeholder and market research can have on a project.

6. Airbus A380

When the Airbus A380 was launched in 2007, much was expected of the airplane, but just 10 years later, they were being sold for no more than spare parts. The expected game-changer led to Airbus struggling to secure deals with airlines.

The A380 was expensive to produce, and Airbus’s production teams didn’t communicate and used different CAD programs. That mistake alone cost $6.1 billion . Furthermore, the second-hand market was non-existent because the planes were simply too big for any airline to make back their invested money.

The impact of poor internal communication and a business case that was built on initial sales, taking the second-hand market for granted.

7. Montreal’s Highway 15 overpass

In 2016, Montreal city officials found that an overpass for Highway 15 didn’t align with the design for the new Champlain Bridge nearby, which was also undergoing redevelopment.

So just a year after being built, the $11 million overpass was torn down . While changing design criteria can have expensive knock-on effects, there was an apparent lack of communication between projects here.

A lack of programme management meant the bridge and the overpass for the same highway were being constructed without the other being considered. The long-term planning and internal communication suffered as a result.

8. Knight Capital

The company’s stock market algorithm released in 2012 with code from an earlier build. It took just 30 minutes for a software glitch to see the company lose a massive $440 million and be forced into a merger a year later.

Although their CEO, Thomas Joyce, implied that the software bug could have happened to anyone, it is very likely that poor software development and inadequate testing models are more to blame for the defect in their trading algorithm.

Project targets and deadlines must be realistic to be achievable. Rushing a product can cause mistakes to be made.

9. Target’s failed entry into Canada

When Target said they were expanding into Canada, 81% of Canadian shoppers expressed interest in visiting them. It should have been a resounding success, but it wasn’t. Less than 2 years later, Target’s Chairman and CEO announced they were pulling out of Canada , closing all 133 stores.

Target misjudged the Canadian customer. Their stores did not feature the same low prices as the US stores, there were serious supply and distribution problems, and they opened too many stores too quickly.

The need for better resource and supply planning, as well as the impact of ineffectively managing stakeholder expectations.

10. Afghan forest camo pattern

Afghanistan’s landscape features around 2% woodland, yet this didn’t stop the US government from spending $28 million of taxpayers’ money on ‘forest’ pattern uniforms for the Afghan National Army. It was only chosen because the Afghan Defence Minister liked the design.

Ultimately, these were never used, so the money and uniforms were completely wasted. That particular forest pattern required a paid licence, while many patterns already owned by the army were more suitable for Afghanistan’s landscape.

Poor management led to a serious oversight, which stakeholder engagement and quality control would have prevented.

Common warning signs of a failing project

Throughout the 10 failed projects we’ve highlighted above, there are a number of common themes. Identifying and being mindful of these warning signs can help you avoid making the same mistakes.

Lack of interest

One warning sign may be stakeholder not attending meetings or providing feedback, as well as allocated tasks not being completed on time. It’s the project managers role to track assignments and ensure a high level of communication at all times. If you believe stakeholders are losing interest, call a meeting to reiterate the value of the project.

Learn more about how support (or lack of) from internal and external stakeholders can make or break a project.

Poor communication

It’s easy for members of the project team to become ‘lost’ and out of the loop with project progress, decisions, and reviews. Project managers should have a communication plan and automate as much as they can. This ensures everyone involved in the project is kept up-to-date constantly.

Discover how effective communication is essential to the success of projects, programmes and portfolios.

Lack of transparency

The more you try to cover up a problem or issue, the less transparency you have and the greater the problem becomes. Be honest. Issues do arise and the best way forward is to identify them as early as possible, notify stakeholders, including sponsors and customers, and work closely with them to resolve the issue.

Scope and budget creep

Don’t start the project until all the stakeholders are on the same page. Always ensure everyone has the scope statement to work from.

Find out how you can ensure your project budgets are based on reliable projections to avoid scope and budget creep .

Poor management oversight

Ensure everyone’s roles and responsibilities are well-defined. The project manager is accountable to other stakeholders.

How ILX can help train project managers

There will always be project failures. The key is to identify them as early as possible and work to resolve them before it’s too late, allowing you to minimise the damage.

It is a project manager’s responsibility to lead by example, and learn from other people’s mistakes. Training in one of our project management courses such as PRINCE2® , AgilePM® or APM PMQ , is a great way to help you develop these skills and improve your leadership qualities.

Free downloads

• Project Management

Top Project Management Failure Case Studies to Know

Home Blog Project Management Top Project Management Failure Case Studies to Know

The majority of project management failures case studies are surprisingly derived from reports published by big organizations. It's somewhat inevitable that large projects attract attention, so when the plans fail, news spreads quickly.

Project managers and other individuals preparing for the PMP exam can use these instances as a reference, which brightens their outlook. It helps them assess what not to do in order to avoid detrimental effects. Also, the individuals get to learn what measures they should adopt on time so that operations do not get derailed from track.

Please consider this blog as a guide to 10 famous projects that failed. Additionally, you will learn why conducting these case studies is important.

What is a Project Management Failure Case Study and Why is it Important?

When we evaluate failed projects case studies in project management, we try to understand why a project did not meet its objectives. These failures can be either associated with significant flaws at crucial levels or an ultimate failure leading to project termination .

Therefore, industry experts prefer to explore case studies to identify decision-making mistakes and potential factors that could lead to similar consequences in the future.

A detailed case study can offer you the following takeaways:

• What mistakes led to inadequate risk management
• What decisions caused misinterpretation of the project’s scope thus leading to unnecessary delays and extra costs
• How monitoring and control aspects failed that resulted in a delay of preventive measures
• Why funding or resources were insufficient at a particular stage
• What caused poor leadership or what were the actual reasons behind negligible stakeholder involvement

Evaluating these pointers can help you spot project warning signs at a very early stage. After that, you can guide your team to bring down the risks strategically.

Through KnowledgeHut's Project Management training courses it is now possible to gather these skills while you’re still working as a full-time professional. Our course curriculum is up-to-date with the latest industry trends. Thus, the content and training modules provide immense value even to the best of the Project Managers who are preparing for PRINCE2 or PMP examinations.

Project Management Failure Case Studies

Are you struggling to fetch failed projects case studies project management   PDF   files online?

We have got this aspect covered for you right here!

Make sure to go through these popular project management failures case studies   for a complete understanding of what actually went wrong.

Case Study 1: IBM’s Stretch Project

Who Failed?

The multinational tech brand headquartered in New York; IBM failed to drop the Stretch project at a pre-planned rate of $13.5 million.

Things They Were Trying to Achieve

From 1950 to 1956, IBM endeavored to launch the world's fastest processing supercomputer, the IBM 7030. The group of engineers hired for the project attempted to build a system that can operate at a 100-200 times greater speed compared to its nearest competitor.

Reasons Why the Project Failed

The team faced too many obstacles while designing and manufacturing the groundbreaking system. Also, there were several loopholes from the architectural perspective that contributed to IBM’s future developments.

Case Study 2: Ford Edsel

C. Doyle, who was the Marketing Manager of the Ford Motor Company at the time, attributed the market failure of the Edsel model to American mid-budget car buyers.

The company fondly aimed towards launching a car that would attract luxury car enthusiasts all over the US.

As per analysts, the vehicle had the right attributes to secure monopoly in the intended market segment. But it failed primarily because of a delay in project deployment. By the time it hit the market, the greater audience had already moved towards compact cars.

Many lessons are derivable from this instance making it one of the historical project management failures case studies .  Some key learnings from this project include the importance of maintaining deadlines, timely communication, and keeping the project managers on the same page.

Case Study 3: Levi’s Type 1 Jeans

Levi Strauss & Co., the world-renowned denim-jeans brand, tried to poach into the segment of exaggerated clothing in the early 2000s. As a result, they attempted running new ad campaigns which totally confused their audience and consequently the sales dropped.

The company’s approach was to introduce a new trend of jeans bottom wear that featured rivets, stitches, and buttons, much different from the contemporary style.

The younger generation at that time was confused about the impression of the final product. As fashion statements are quite fickle and tend to change very quickly, the idea did not sit well with the end-users.

Case Study 4: Apple Lisa

Apple, the tech giant that currently holds almost 24% of the global market share in consumer goods, initially failed while introducing the first-ever desktop with a mouse.

The company aspired to develop a compact personal device that could replace expensive minicomputers or mainframes at that time. For this, they hired trained software professionals and availed consultancy from various IC suppliers.

The project apparently promised a lot of things but ultimately failed to deliver the results. Space constraints became prominent as the computer only offered 1 MB memory. Also, the Apple FireWare floppy disks seemed unreliable. As a result, just 10,000 Lisa computers could be sold over a span of 24 months.

Case Study 5: Crystal Pepsi

Does the idea of clear Cola seem fascinating to you?

Probably not, right?

This concept was actually put into action in the 1990s when PepsiCo launched Crystal Pepsi as an effort to target health-minded customers. Unfortunately, this turned out to be one of the most spectacular project management failure case studies   in the soft drink industry.

PepsiCo introduced a unique taste and marketed it through rampant advertisement campaigns. Also, they stressed the benefits of the drink which failed to gain the expected momentum.

The product failed because at that time the market was starting to get inclined towards energy drinks. Also, traditional colas consumed a large section of the audience who preferred that taste over others.

Case Study 6: Sony Betamax

The second-biggest supplier of cameras in modern times, Sony failed in the mid 1970s while they tried to compete with JVC’s VHS technology.

At that time, the company introduced a consumer-level analog recording device that was marketed as a video cassette recorder. Performance-wise, the average playback times and fast-forward features were working seamlessly for this innovation. But there were major drawbacks that resulted in the project's downfall.

The VCR was compatible with other Sony products only. Also, the Betamax tapes came at a much higher price compared to VHS tapes. Furthermore, Betamax recordings were limited to a maximum of 1 hour, whereas VHS tapes allowed for recording durations of nearly 2 hours.

Case Study 7: Death March Project - Baggage System Disruption at Denver Int. Airport

One of the busiest international airports in the world, Denver International Airport failed.

In 1991, the airport authority made a noble attempt to streamline the time-taking luggage transfer system. Their primary objective was to attach bar-coded tags to baggage in order to fully automate the process. The authorities anticipated reducing the aircraft turnaround time by half across three terminals.

Unfortunately, DIA’s management couldn’t control the cost, risks, and time required to deal with the new system. As the body tied up with BAE to bring in the automated baggage handling system, both organizations assumed different deadlines. An unrealistic 2-year schedule was offered from DIA’s end that led to project underscoring and many detrimental situations followed due to lack of discussions.

Case Study 8: NHS’ Civilian IT Project

Great Britain’s publicly funded healthcare system, the National Health Service (NHS) failed in the 2010s.

The body targeted to revolutionize the health sector through innovations like digital scanning, electronic recording methodologies, and integrated IT devices. In a nutshell, they aspired to build the greatest civilian digitized module around the globe.

The three most prominent reasons that led to this project’s failure included supplier disputes, frequent changing of specifications, and external contractual disruptions.

You can learn about how to avoid these scenarios by joining ours   PMP online course . It is a certified step-by-step curriculum to crack the exam on the first attempt.

Case Study 9: McDonald’s Arch Deluxe Burger

The American QSR chain McDonald’s failed in 1996 after introducing a premium option in its menu - the Arch Deluxe Burger.

The brand tried to mold its menu to make it suitable for the more sophisticated class of audience.

The company gave too much importance to customer data while redefining its new production strategy. Thus, they ended up spending $150 million on advertising. Contrarily, the management failed to track the returns minutely and the demand for the product never reached expectations.

Case Study 10: FoxMeyer Drugs Bankruptcy

FoxMeyer Corporation went bankrupt in 1996 as the company misinterpreted software project risks at a latent stage.

They were trying to automate the supply chain of prescription drugs and toiletries in the wholesale segment.

The project primarily failed while handling mass orders. As thousands of pharmacies depended on the company, they got over 500,000 orders per day which clearly crossed the bandwidth of the software at that time.

Most project management failures case studies give you an idea on how delayed communication can disrupt the results. Thus, while initiating a project, the focus should be towards automating processes as much as possible.

Also, from the top management to ground level, key evaluation metrics have to be laid out for positive impact on the organization. It prevents the staff from going disarrayed and over-consuming the resources and posting errors repeatedly.

However, it doesn’t mean that the failed projects are a stigma to the company. Most successful brands have learned from their mistakes and gathered the spirit to start from the beginning. All the important changes were meanwhile incorporated along the way.

Frequently Asked Questions (FAQs)

When you deeply analyze the failed projects, you can realize the significance of effective risk management and timely communication. Also, it is crucial to prioritize 24/7 monitoring and active stakeholder collaboration to ensure previous mistakes do not get repeated

Yes, project management failures may get triggered by unexpected market changes. Even economic downturns and legal implications can impact resources and delivery deadlines.

Project management failures need to be avoided by taking an active stance on roles and responsibilities. If the managers successfully construct a collaborative team environment and set realistic budgets and timeline, then the chances of success increase many times further.

Kevin D.Davis

Kevin D. Davis is a seasoned and results-driven Program/Project Management Professional with a Master's Certificate in Advanced Project Management. With expertise in leading multi-million dollar projects, strategic planning, and sales operations, Kevin excels in maximizing solutions and building business cases. He possesses a deep understanding of methodologies such as PMBOK, Lean Six Sigma, and TQM to achieve business/technology alignment. With over 100 instructional training sessions and extensive experience as a PMP Exam Prep Instructor at KnowledgeHut, Kevin has a proven track record in project management training and consulting. His expertise has helped in driving successful project outcomes and fostering organizational growth.

Avail your free 1:1 mentorship session.

Something went wrong

Upcoming Project Management Batches & Dates

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 ™ .

• Share on Twitter
• Share on LinkedIn
• Share on Facebook
• Share on Pinterest
• Share through Email

How To Avoid Project Failure In 3 Simple Steps + 4 Case Studies

Project failure can be nasty business. Here's how to avoid project failure when you can, and survive it when you can't.

There are many reasons why projects fail, but they pretty much all boil down to one of two things (sometimes both):

• There was a risk that no one recognized, and/or
• We didn’t respond well when there was a problem

In this article, I want to focus on the big picture to help address the main cause of project—and often project management—failure.

Here's how to avoid project failure, and what to do if that catastrophic issue you didn't foresee comes to pass (you can still pull it off if you act quickly and thoughtfully!).

What Is Project Failure?

Exactly what is sounds like—anytime a project does not deliver on the project objectives the team set at the beginning, does not deliver on client or key stakeholder expectations, or is not on time, budget, or scope.

Why Do Projects Fail?

As I teased in the intro, there a variety of common reasons projects can fail . Usually this is due to a risk that wasn't properly assessed, and/or the team (including the project manager) didn't respond to the risk properly.

Other common causes of project failure might include poor communication around status, issues, or risks; team members not sticking to (or properly understanding) the project scope, project deliverables (ie. scope creep ), or timeframe; a lack of resources, or not sticking to designated processes or methodologies.

How To Avoid Project Failure: 3 Steps

Risk management is a key project management activity. It’s so important that failure to manage risk often amounts to project management failure. Risk management has three important components:

• Identify risks.
• Assess what you’ve identified: How likely is it to happen and how bad will things get if it does? What are the probability and impact?
• Prepare mitigation and contingency plans for those risks that could torpedo your otherwise successful project. Risk registers are handy for keeping track of what you’ve done.

1. Identify Risks

First, identify the risks. Doing this well will greatly increase your chances of project success. And while it’s difficult to catch them all, if you look systematically at the project, you can generally figure out the biggest risks. This is usually part of the process of creating a project plan .

My background is in software development, both product and IT, and its associated processes. Software projects are complex, fragile, and except in a few rare cases, don’t have the kind of failsafe and inspections baked in that something like construction or medical device production does.

You should have project goals for each of the four dials:

If you don’t know what those are, that’s your starting place. I find that typically two of the four will move around a bit, but the more you understand about where you’re going the easier it will be to identify obstacles.

Understanding which of the four dials is the highest priority will help you reduce risk by making appropriate trade-offs in small ways.

It’s easy to get caught up in the project schedule dial and miss risks that might affect the other dials, but they’re all related and all-important to identify.

Meeting your schedule goals with a product that’s buggy is usually not a good option—even if you send it out you’ll end up doing fix-it releases that push the schedule for an adequate product farther than addressing the issue in the first place would have done.

Sign up to get weekly insights, tips, and other helpful content from digital project management experts.

• Your email *
• Yes, I want to sign up to receive regular emails filled with tips, expert insights, and more to build my PM practice.
• By submitting you agree to receive occasional emails and acknowledge our Privacy Policy . You can unsubscribe at any time. Protected by reCAPTCHA; Google Privacy Policy and Terms of Service apply.
• Comments This field is for validation purposes and should be left unchanged.

Beyond the 4 Dials

Besides the four dials, you have three aspects of your project to balance:

• Product, which is usually covered by the dials

Process risks come in two flavors: an existing process inadequacy that doesn’t meet the needs of your project and lack of a process for something critical to what your team is doing. Process risks are pretty easy to mitigate by creating or fixing the process.

The people part is often ignored, but your team and the teams they interact with will make or break your project. Difficult or uninterested project stakeholders will make it hard to get what you need to move forward.

Overworked, stressed, or unhappy team members will not get the job done. Some of the potential people issues you can identify publicly, others you may want to address privately, but don’t make the mistake of ignoring them.

2. Assess the Risks You’ve Identified

After identifying the risks, determine how likely the risk is to happen. I usually use a percentage—100% means I’m positive it’s going to happen. It’s also important to determine how bad it’s going to be if the risk does happen. The easiest way to do this is by categorizing risks as high, medium, or low risk.

Once you’ve done this analysis, it’s time to bring your team in. Ask each project team member or contributor what they are worried about, add those to the list of risks, and put them up for review:

• Can the team think of other risks you haven’t covered?
• How do they feel about the probability and impact analysis?

Based on this meeting, you can make adjustments to your risk plan. Parts one and two are done—for now. You’ll need to review the risks at least weekly to see if there are new risks if there are some that aren’t applicable anymore and if any probability or impact has changed.

3. Prepare Mitigation and Contingency Plans

Finally, if the combination of probability and impact of any risks have the potential to derail your project, work with your team to come up with documented plans for mitigation and contingency.

Mitigation involves making the risk either less likely to come to pass or have less of an impact if it does. Contingency focuses on the steps you will take if the risk is unavoidable and occurs.

Be sure the plans are documented and everyone knows about them. It’s also a good idea to plan for potential people issues on top of the 4 dials and process, but you probably want to do the analysis yourself and keep it confidential.

How to Survive Project Failure

The second reason for project management failures is a poor response to a project risk coming to pass, foreseen or not.  This is really all up to you as the project manager. Before you do any of the steps below, start with these 2 tips:

• Don’t panic . Remember to breathe.
• Don’t point fingers and don’t let anyone else start down the blame path.

1. Refer To Your Contingency Plan

If you have a contingency plan in place, call a meeting immediately, or at least send an email triggering the contingency plan. Remind people what the plan is, and tell everyone when and how to report status.

If you skip this or delay it you’ll find that people eager to help have jumped in while in panic mode; when this happens you lose track of what’s been done and it often makes the problem worse.

If you don't have a contingency plan , immediately rally the troops with a meeting notice and strict instructions to DO NOTHING ELSE until after the meeting.

Otherwise, everyone will try to help and you’ll have no idea what’s been done. In the meeting, state the problem clearly—it’s always amazing how many different ideas people have about what the problem is.

Do a consolidated root cause analysis to get to the bottom of the issue and come up with the plan—who, what, and how—to recover. When working on a root cause analysis you need to understand who did what leading up to the issue, but keep the discussion at that level.

In other words, just the facts. Don’t assign blame, as finger-pointing is a distraction. If your team is not able to come up with the solution, you have some options.

The first is to bring in someone who knows the general subject matter but isn’t on this specific project—for example, if the problem seems to be with the database, bring in a database administrator not currently on the project to get a different view.

Another technique is to bring in someone with no working knowledge of the project at all. Sometimes having to explain every step explicitly exposes poor assumptions or something people were looking past.

2. Fix The Problem

Get everyone on board with your course of action and assign tasks. Have people report progress to you, and tell them how often to send progress reports—hourly, when they’ve finished a task, at the end of the day, or whatever makes sense given the situation.

The reporting may seem obvious to you but it won’t be to everyone. Regular updates will help ground the team. Report consolidated progress to the entire team regularly.

Those on the team with no immediate tasks are going to get itchy and eventually try to jump in and help unless you’re feeding them status updates and other information.

It’s very important to keep management in the loop as well. Use your judgment to determine who needs updates at what point, but report consolidated progress to the entire team regularly.

3. Call It Done

When it's actually done, that is. Generate a final report, and move on to the next step. Give the team a bit of a chance to recover.

4. Hold A Post-Mortem Or Retrospective

It's important to complete a project evaluation to gather lessons learned. Here's how to structure this:

• State the problem so everyone is on the same page
• Start with what went well. In the most dire situation, something still went right. This starts the meeting off with a whole different tone.
• Talk about what needs improvement. If there’s time, brainstorm ways to make the improvements; otherwise, assign tasks and due dates and follow up on those dates.

If it was actually someone’s fault, address it with that someone—privately. If you do this in public your whole team will be wondering who’s going to get embarrassed in public next.

If you skip it entirely, your team will feel like someone got away with something and the problem wasn’t fixed. Be matter of fact and follow up on any personal process changes that someone needs to make. It’s all about accountability and improvement, not finding someone to blame.

3 Real-Life Project Failure Examples

I’ve had my share of IT project failures, although they, fortunately—but painfully—recovered.

Here are a couple of my own failed IT projects and development projects as well as one example of a famous failed project.

These project failure examples and failed projects case studies should also give you a concrete idea of the ways that projects can fail and how this can be dealt with.

1. The Accounting System

Early in my career, I worked at IBM. My first real job was to pick up a fairly small system that fed into the corporate accounting systems. Someone within IBM had written it in an obscure programming language called RPG on a small system.

I didn’t just manage the project—I managed the whole system (although there was an admin) including project requirements gathering , troubleshooting, and programming.

I put a new program on one fine day, ran it, and found an error. I corrected the error and re-ran the program. The next morning I got a call from the Accounting people that there were double entries (this is very bad news in the world of accounting).

First, no one reviewed my work. Second, I didn’t engage folks from the downstream systems to check entries before they flowed through. And third, I didn’t put in the time to analyze some of the old programs that were still running and setting up double entries. There was also no process except what I was making up on the fly.

And then my response—panic. Good lord, right out of college and I’m ruining IBM’s accounting system. I didn’t include the right people—the admin didn’t know what was going on—and he generated yet another set of entries without knowing it. In the end, I worked 48 hours straight to dig down to the root cause, fix it, and write and run programs to fix the accounting errors.

And I learned my lesson—look carefully, get reviews, think about what could go wrong, and stop and think before diving in to try to fix things. Now imagine I was running a 10 person team and everyone did the same thing trying to fix the problem. It truly would have been unrecoverable without bringing down IBM’s accounting systems to dig out.

More Articles

Managing complex projects: tips to level up your skills, 5 strategies for managing multiple projects at once, why is it so difficult to use project management software well, 2. the new internal product.

As a consultant, I was running a new, big project with lots of fingers in the requirements pie making for never-ending shifts in functional priorities. We were running an agile project management process , which this company hadn’t used before. QA was very good at testing but didn’t yet understand the end-user mindset and workflow.

I knew all these things and did articulate them from time to time, but I had no risk register , no impact/probability assessment, no contingency, or mitigation plans. I was also not the primary information conduit to the project’s sponsor, although I did meet with her occasionally.

We added a sprint. Then another one. Then, as it became clear that we were not quite at the point we needed to be to do a beta test, we added a third sprint.

Because I was not the one providing information to the project sponsor I had no idea that she didn’t know all of this. The person in charge made the critical mistake of not telling the sponsor, hoping we could pull it off.

And to be fair, although I talked about risk, I didn’t provide him with a concrete set of risks to present to prepare the sponsor for the possibility of a schedule slip.

In the middle of all this, I had a meeting with the sponsor and made an offhand reference to that final sprint we’d be adding. She stopped me. She knew nothing about it and was not happy.

As it turned out, she was more upset about the surprise than the schedule slip. There were public repercussions and eventually the person in charge of the project moved elsewhere in the company because the trust was gone.

Once again, I learned important lessons from the failure. Knowing the risks isn’t enough, you need to put them together, assess them, have mitigation and contingency plans, and make them public and constantly in view.

I’ve never been one for hiding risks and issues, but the importance of transparency was made unmistakably clear.

3. Remember OS2?

Nope, nobody does. It’s one of many failed systems development projects. I was working at IBM when the original OS2 came out—a competitor to Windows. I didn’t even try that first version because at IBM we all knew it was really buggy. The rest of the world found out right away that it had too many failures to bother with.

It was buggy enough that the project team couldn’t possibly have thought it was fully baked, but somehow they didn’t make the right tradeoff and hold the release. Failing to consider the human element, both your team and your customers will ruin a beautiful plan in a hurry.

In software there is any number of alternatives to this situation—do a limited release to people who will tolerate the bugs in order to have new bleeding edge software, make public that you’re waiting to make the reliability up to your high standards, etc.

This was still early enough in my career that I could take valuable lessons from the fact that a product I loved was at a dead end on the second release.

Be clear about your priorities—there are a few cases where releasing on a certain date is more important than product quality, but not many.

Use your 4 dials, and admit your mistakes and make the fixes visible so people trust that you understand the issue and won’t make the same mistake twice.

Consider the people element—it’s as critical as the technology. I brought these lessons to software and IT projects from that time forward, and they’ve been invaluable.

The Bottom Line

Overall, remember that even though it’s ultimately your responsibility, you don’t need to do all the work. In fact, you absolutely should not try to do it by yourself. You can benefit from the wide range of experiences and knowledge of your team. You’re the leader, but you don’t have to be the entire team.

Project management software and other project management tools can help you track risks, milestones, resource allocation, and other critical indicators of whether you're on your way to a successful project.

For more actionable insights on project failure and other relevant topics in project management, subscribe to the DPM newsletter .

8 IT Project Failures of the 2010s

A couple of weeks ago I talked to Stacey Broadwell on the TechRecruit podcast and we ended up talking a lot about the lifecyle of building software, and ultimately how frequently software projects fail.

It's no secret in the industry that software is hard to make and projects often fail. Whether that number is 68% , 90% or 71% that end up being "unsuccessful" is up for debate but the number is probably well over half.

So if you're a recruiter it's good to keep in mind that when you are talking to hiring managers they are likely working on a project that is already behind schedule and overbudget and they need help the day before yesterday.

I thought it would be interesting to make a list of some major failures that happened in the last decade since we are closing out 2019 and starting on 2020 this week!

1. Canada's Phoenix Pay System

A project that was initiated in 2010 to automate and replace Canada's government payroll system. Originally planned to be a Peoplesoft implementation by IBM (off the shelf software), it was plagued by problems that are still ongoing.

I'll just quote the most recent update in the wikipedia entry.

It had "failed to properly pay nearly half of Canada's workforce of public servants, representing 153,000 people. The report added that the system, whose original 2009 budget was $309-million, had already cost taxpayers $954-million and could rise to $2.2 billion by 2023 in unplanned costs."

2. The 2013 Rollout of Healthcare.gov

It was estimated that the government spent over $840 million on this online insurance exchange rollout, but due to a myriad of issues fewer than 1% of users were able to enroll in insurance during the first week of operation.

I found a great article on this with a long list of citations .

3. Rhode Island's UHIP Program

UHIP - Unified Health Infrastructure Project was supposed to be a new public assistance program for the state of Rhode Island. Initiated in 2016 and estimated to cost $119 million, the project has not completed yet and estimated to cost a total of $487 million to fix the current issues .

4. US Depart of Defense EHR System

The US Department of Defense is in the process of replacing it's Electronic Health Record system (EHR) at a cost of $4.3 billion dollars but according to recent memos it is :

"neither operationally effective nor operationally suitable,"

Surprisingly, this is a new system meant to replace a $2 billion dollar system that was only rolled out in 2004. The new system is expected to be complete in 2023, but if the latest reports are any indication that won't happen.

Interestingly the VA (Department of Veterans Affairs) is also working on a new $10 billion dollar EHR system which sounds doomed to failure. Why the federal government needs so many separate EHR systems is beyond me.

5. Lidl Scraps a New $500 Million Euro SAP System

German grocery store chain Lidl apparently developed a new inventory management system with SAP at a cost of $500 million Euro only to completely scrap the project in 2018 after rolling it out in 2015.

6. The Coast Guard's $67 million Dollar EHR Fiasco

Another Electronic Health Record system - this time for the coast guard. It started development in 2010 and was supposed to cost $14 million, eventually the documented cost was $67 million before the project was completely scrapped. In 2016 the legacy system was retired and now the Coast Guard has reverted to using paper records .

7. National Grid ERP System

National Grid contracted Wipro to build a new ERP system at a cost $140 million, but eventually spent an additional $600 million and two years fixing the system. This was just one part of a larger $393 million program to modernize aspects of National Grid's IT system according to this article .

8. Minnesota's Rollout of a New Vehicle License System in 2017

I moved from Ohio to Minnesota a couple of years ago and when I went to renew my license I was in for a surprise. In Ohio this was a 20 minute process and your license could be issued immediately. In Minnesota they were in the middle of a rollout of a new vehicle license system.

I had to wait 3 months for my car to be re-titled and 2 months for my new license to arrive in the mail. In the meantime they invalidated my current license (stamped holes through it?) and gave me a slip of yellow paper I had to present along with my mangled license for months every time I wanted to grab a beer.

I was told by BMV workers to "call in a month or two to make sure they didn't lose the title". The project apparently cost the state $90 million before they ended up calling in an outside contractor to bail them out .

It seems that government IT projects fail at higher rates than those in the private sector (according to one article only 6.4% of government projects with a budget over $10 million are "successful" ) and some of that may be between the mis-alignment between incentives at that level. But, failures in the private sector are also widespread (as I cited in the opening paragraphs).

Building software is hard. It's not like building a house where everything is pretty much established and there are basic rules and plans to follow. Often times when you are building software because of unique data structures it would be comparable re-inventing the process of plumbing and wiring electricity every time you build a building.

Software projects often have unique requirements, situations and constraints. Even implementing off-the-shelf software in the context of an existing organization can be plagued with difficulties.

Want updates?

Want new posts about tech topics emailed to you? Sign up to the list below 👇

Also, if you are interested in learning technical topics through a video course specifically created for recruiters, don't forget to check out the courses I offer .

The main course "How to Speak Software Engineering Jargon for Recruiters" is specifically designed to help tech recruiters get up to speed fast on technical topics.

Written By Aaron Decker

I'm currently a co-founder and head of engineering at a venture backed startup called Bounty. I tend to think of myself as a backend engineer that can work up and down the stack in Typescript. Previously, I have worked as a Tech Lead and hired teams, and as a Senior Software Engineer at multiple fortune 500 companies building large products. I also did a brief stint teaching programming courses as an Adjunct Instructor at a local community college, which taught me a lot about breaking down complex things into understandable chunks.

• project management

01270 626330    |    [email protected]

• News and blog

• No products in the cart.

Failed projects and the lessons learned – 2023

Not sure why project management is needed.

In this blog, we’ve uncovered some of the most famous failed projects throughout history and explore what we can learn from them today. 

Training ByteSize are a world leading training provider; we continually provide students with the most successful and experienced trainers so you’re always in the best position to pass first. Our pass rates and customer reviews are exceptional, so you can be assured of our experience, professionalism and long-standing success when it comes to our expertise on sharing our view of failed projects.

Sometimes, the most effective way of understanding the need for project management and the reason why it’s so important is to look at previous failed projects. What is project failure? It can mean many things, from cost and time overruns to scope creep and a failure to deliver a return on investment. We’ve uncovered some of the biggest project failures in history where governance was lacking which resulted in the inability to meet objectives and deliver what was planned. Read on for our top 8 high-profile failed projects and discover the lessons that we can learn from each of them.

1. Airbus A380

In 2004, Airbus was all set to launch the biggest passenger plane in the skies. Parts were shipped from Toulouse to Hamburg for assemblage but it soon became apparent that none of the pieces actually fitted together. It was later learned that the designers were all using different CAD programs which resulted in different measurements.  

Lesson Learned: This highlights the importance of project management to keep everyone on the same page. Even across different time zones and borders, always ensure that the team is using the same programs and systems to get the task done.

2. Challenger Space Shuttle

This project failure had tragic consequences. On January 28 1986, the Challenger Space Shuttle exploded just 76 seconds after it had launched due to a combination of a faulty seal on a rocket booster and cold weather. It was determined that human error was partly to blame.

  Lesson Learned: Human error can be greatly minimised by effective project management. The role of a project manager is to put systems in place to reduce the risk of human error impacting on projects, big or small.

3. World Athletics Championships 2019

In 2019, the best world athletes made their way to Doha to compete in the World Athletics Championships. Unfortunately, the host nation was unable to sell the majority of tickets so athletes were forced to compete in nearly-empty stadiums.

Lesson Learned: It doesn’t matter how much money you put into an event. If you don’t have a strong homegrown fan base, it will be very difficult to fill seats and create a memorable experience.

4. McDonald’s Arch Deluxe Burger

When McDonald’s launched a new ‘grown-up’ version of their iconic hamburger, called the Arch Deluxe Burger in 1996, it was discovered that customers weren’t interested in changing the original formula. McDonald’s put more than $150 million dollars into their ad campaign but the burger failed to gain popularity and was soon dropped.

  Lesson Learned: The biggest lesson learned here is to always let customer data drive product strategy. With the right project management, McDonald’s would have had a clearer idea of what its customers wanted. A great way to do this is to track selective key metrics and ensure your tools can accurately track the data in real time. Then, use the numbers to formulate your strategies.

5. Knight Capital

In 1985, Coca Cola launched a product called ‘New Coke’ which turned into a real fizzer with the public. Even though the new recipe went through a taste trial of 200,000 people, it turned out that fans of Coca Cola were too loyal to the original recipe to be enticed to drink a new one.

Lesson Learned: While Coca Cola did their market research and learned that customers were open to a new product, they failed to see their customer’s own motivations. More than a mere taste test was needed to understand how fans would feel when their beloved Coca Cola was suddenly replaced by a different product. It’s a reminder to treat project management as a science and an art that needs to be worked into the project accordingly.

6. Ford Edsel

The Ford Edsel was a result of extensive research into what Ford consumers wanted in a car. The problem was that by the time the model was released, the market had already moved on to more compact cars and the Ford Edsel was already outdated. 

Lesson Learned: While project research is absolutely essential, it is only successful if used in a timely manner. This highlights the importance of being quick to market fresh ideas before the public moves on to the next trend.

7. The Garden Bridge

The Garden Bridge has been dubbed a failed vanity project, pushed by Boris Johnson when her was the Mayor of London. The project cost £53m in total, despite never actually being built . According to a report, the bridge was over-optimistic both in terms of the fundraising possible and the final cost. This led to a shortfall which could never be overcome, despite surveying work on the riverbed already getting underway.

Lesson learned: Ambition is a powerful thing, but it needs to be grounded in reality, particularly when relying on fundraising to get projects off the ground. In retrospect, it would have been wise to establish if the project was feasible before spending £161,000 for a website.

8. The NHS’ Civilian IT Project

The project that aimed to revolutionise the NHS IT systems was a failure that cost the taxpayer somewhere in the region of £10bn. The politically-motivated and top-down nature of the project meant that scope creep and a complete underestimation of the requirements doomed this project from the start.  The government was later criticised for its inability to handle large IT contracts.

Lesson learned: It’s important to consider the size and capabilities of your own organisation before taking on an ambitious project.

9. Sony Betamax

Lesson learned: While Sony Betamax may have been first to market, the project failed because it didn’t innovate. In the face of a cheaper product (VHS) with a better marketing model, Sony stuck to their guns and lost market share as a result. 

10. Waterworld

The making of the movie Waterworld seemed doomed from the start. The director started shooting without finalising the script and multiple rewrites along the way resulted in production being extended from the scheduled 96 days into 150 days which pushed costs to $135 million dollars over budget.

Lesson Learned: Defining the scope of a project before it starts is crucial to preventing cost and time overruns. In the case of this movie, the script should have been signed off before production even began.

11. Pepsi Crystal

Pepsi’s COO at the time later admitted that he ignored reports from his team that Pepsi Crystal didn’t taste quite right, but he pushed ahead with production anyway.

Lesson learned: When you have a wealth of knowledge on your side, it makes sense to make the most of it. While taking every single piece of feedback on board might be impossible, there is a middle ground that stops you from missing important cues. 

12. Denver International Airport

Build your project management knowledge and avoid failed projects with Training ByteSize

At Training ByteSize, we aim to equip you with the skills you need to excel as a project manager and lead your team to success every time. We’re a world leading training provider with exceptional pass rates and the most experienced trainers to keep you a step ahead of the rest. Our popular PRINCE2 course teaches you how to pre-plan your project, structure each stage and close remaining tasks after completion. We also offer other in-demand courses for project management, including Agile PM, Agile BA, Change Management and APM. Take control today and give us a call to discuss your needs and discover the right training course to advance your skills and your career.

Avoid failed projects with project management training: APM Project Management Qualification

APM stands for the Association for Project Management . This term has become synonymous with professionalism and is well known throughout the UK and Europe. APM is an educational charity who is committed to developing and promoting the value of project management in order to deliver improved project outcomes for the benefit of society.

The Association for Project Management,  Project Management Qualification  (APM PMQ), is a project management qualification designed and developed to provide candidates with a conceptual understanding of project management.

The course is knowledge based and designed to enable candidates to feel comfortable involving themselves in projects of all sizes across a breadth of industries.

The APM PMQ is seen as an intermediate level project management qualification. It is recognised around the world for signifying a certain level of competence.

Our APM PMQ online learning package

We offer training for this internationally recognised life-long certification for just £599+vat, this includes 12 months access to our online learning platform, email support from our expert trainers and the accredited PMQ exam.

Our course has been expertly put together by our leading APM Trainer to ensure the most significant elements of the classroom course remain an important focus throughout the online learning.

At the end of each online session there is a thorough review within the workbook covering the main points as revision and added additional information which will also be of use to you.

As you work through the course there will be ‘Pauses for Thought’ allowing you to develop the ‘Thinking Process’ which is required for the PMQ examination.

You will be asked to consider topics, their importance and relationships with other elements of project management. We will encourage you to share and compare your thoughts with ours to sense check you are on the right track.

The course is intensive and there is roughly 40 hours learning to work through. Ultimately our  APM PMQ online course is the ideal way for busy professionals to gain this much sought-after qualification.

Try before you buy

Knowing what the course looks like before you buy anything is a service we’re really proud to offer. Click here to see our  APM PMQ online course demo .

Look out for offers

We’re always supporting our customers with fantastic offers to help ensure you can afford to train, so make sure you check out our  offers page  before you buy.

We’re here for you at every stage of your project management career, so please take the opportunity to talk to us. You can use the chat function in the bottom right of your screen, email us at  [email protected] , or call us on +44 (0)1270 626330.

Avoid failed projects with project management training: PRINCE2 Foundation

PRINCE2  is widely considered to be the world’s leading project management method. There are now people qualified in PRINCE2 in most countries around the world, with many companies and government organisations using the method to deliver change and develop new products and services.

PRINCE2 is a structured approach to project management. It provides a really clear framework for managing projects in a results-driven environment.

The purpose of PRINCE2 is to give you complete control over your project. The process will help you pre-plan how you want to implement your project, how to structure each stage of its execution and how to close off any remaining tasks once the project has finished.

PRINCE2 has been designed to be generic so that it can be applied to any project regardless of project scale, type, organisation, geography or culture. It provides a tried and tested method from which many organisations can benefit.

Discover your PRINCE2 6th Edition certification with Training ByteSize

Here at Training ByteSize, we boast an incredible 96% first-time pass rate for our PRINCE2 Foundation exam.

Our online learning packages offer you a convenience that no other training option does; you can login to your dedicated portal and learn at a pace and time that suits you.

All our courses are engaging and interactive, with mock exam simulators and full support packages

They are accessible, flexible and efficient, allowing you to move quickly through topics you feel comfortable with and spend more time focusing those that need more time.

We have special offers on our PRINCE2 courses

Now more than ever, it’s so important to invest in yourself and ensure you stand out in the market. We’re committed to supporting you and other learners through the challenging times we’re all facing, so our courses are on special offer and start from just £249+vat for an all-inclusive learning package. 

PRINCE2® Foundation 6th Edition Course . For £249+vat our online learning package includes 3 months access to our exceptional online learning environment and the official accredited PRINCE2 Foundation exam.

PRINCE2® Practitioner 6th Edition Course . This Practitioner online learning package is priced at £399+vat and includes 3 months access to our excellent online learning environment,  the handbook (worth £85) and official accredited exam.

PRINCE2® Foundation and Practitioner 6th Edition Course . For £599+vat you can access both learning packages, take both accredited PRINCE2 exams and we’ll send you the handbook.

PRINCE2 explained in 100 seconds flat!

Try before you buy with our prince2 course demo.

Discover the quality of our online learning with these free course demos of the PRINCE2 Foundation  and  PRINCE2 Practitioner .

PRINCE2 online courses are a great way to study and our e-learning system is interactive and engaging

Studying for your qualification online is a viable option for so many project managers:

• Learning is completely flexible to suit your busy schedule
• The interactive online course consists of voice-over and animation to keep you engaged throughout the learning
• You can access it anywhere in the world and take your exam online at a time that suits you best
• The e-learning will take around 10 hours to complete (depending on what you are studying) and includes a mock exam simulator with lots of past questions so you can really test yourself before going for the real exam
• Our pass rates are well in excess of the national average (nearly 100%!), there is really no reason you should fail!

Related Posts

Top 5 Project Management Trends To Look Out For In 2022

Better Business Cases: Five Case Model Flowchart

WHITEPAPER: Have Learning Styles In Training And Development Adapted In The COVID Age?

Please wait while you are redirected to the right page...

User registration

You don't have permission to register, reset password.

• Developer Blog
• Project Management Tips

How to Turn Around 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 know how to turn around a failing software project?

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 turn around 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.:

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

Trusted by 100x of startups and companies like

• 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 ”.

Hire expert developers for your next 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'.

Alexey is Expert Startup Review Panel member and advices the oldest angel investment group in Silicon Valley on products investment deals.

Some of our projects

All backend All frontend Design WordPress

A website to publish AI research papers with members-only access and a newsletter.

Android iOS Java Mobile PHP Web Website

A complete rebuild and further extension of our client's web and mobile shipping system to allow it to serve 28 countries.

Public Storage

All backend Devops IoT Mobile Web

A B2B2C solution with Web, Mobile, and IoT-connected applications that aim to revolutionize the public storage industry.

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

By clicking Accept Cookies, you agree to our use of cookies and other tracking technologies in accordance with 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

Engagement Model

Team Augmentation

Streamline your team's expansion, minus HR complexities.

Managed Projects

Bringing your ideas to life, with our tech teams.

Web Development

Crafting digital solutions that help you convert visitors into customers.

Mobile Development

Go mobile-first with responsive apps for collaboration and digitizing workflows.

Emerging Technologies

Harness tomorrow's technologies whether it's AI, IoT, VR, AR, or blockchain.

Unleash resilience with robust practices for unparalleled software excellence.

Data Analytics

Turn raw data into actionable insights for driving strategic decisions.

E-Commerce Development

Create an online presence that helps you drive engagement and conversion.

UI/UX Design

Harmonizing your brand with intuitive designs for usability, putting users first.

Software Testing

Pinpoint software defects swiftly with our expert testing approach.

Low-Code/No-Code

Achieve scalability, cost-effective agility while empowering non-tech teams.

Cyber Security

Strengthen your cyber defense by securing every attack stage.

As a digital partner, we empower businesses with user-centric solutions.

Craft and engineer innovative tech upgrades in all things fintech.

Improve and enhance healthcare stakeholder experience—be it patients or doctors.

Evolve and empower education seamlessly through our tech-driven solutions.

Transform your work teams through tailored software solutions for seamless excellence.

Real Estate

Elevate and enhance your real estate presence with our tech solutions.

Boost travel outcomes and customer satisfaction with our tech developments.

Oil and Gas

Digitizing and optimizing your oil and gas operations with our tech expertise.

Electronics and Communication

Fortify your business with next-gen electronics & communication solutions.

Partner Platforms

Transform your customer engagement seamlessly through intuitive solutions.

Boost productivity with flexible data management and collaboration tools.

Build, deploy, and manage applications and services on Azure seamlessly.

Amazon Web Services

Maximize business potential via resource management, scalability, innovation.

Google Cloud

Enhance customer experience by leveraging Google's infrastructure and technologies.

Streamline operations and enhance efficiency with automation.

All-in-One Cloud-Based HR and Finance Solution

Manage all aspects of your business on one unified platform.

Get a 360-view of customers that drives satisfaction, retention, sales.

Optimize workflows and improve team collaboration through data analytics.

Effortlessly access vital insights through the Power BI.

Accelerate your expansion with our Shopify expertise.

Create a strong online presence and connect with the right audience.

Streamline business-customer interactions with conversational AI.

Empowering Your IT Journey with Information and Tools.

Cost Calculator

Effortless Development Estimate in just a few clicks

Insights, Trends, and Expert Perspectives Unveiled

Video Library

Curated Collection of valuable insights and expertise

Technologies

Hire Developers that deliver top-notch tech solutions.

React Native

Cloud & DevOps

Microsoft Azure

Robot Framework

Looker Studio

Why Ajackus?

Reasons on why you should choose us.

Career Advancement

Advance professionally by working for top clients across the globe.

Holistic Training

Get holistic learning for a well-rounded and versatile skill repertoire.

Remote First

Step into a new era of work with our 'remote-first' work culture.

Explore Ajackus: Learn About Our Values and Innovations.

Discover Our Story and Values at Ajackus

Security & IP

Stimulate your growth in our secure environment

Referral Program

Grow with Us: Refer Clients, Earn Rewards

OCT Framework

Discover the framework for optimal client success

The Anatomy of Failed IT Projects

Siddhesh Patankar

Jun 18, 2024 · 9 mins read

Table of Contents

With any project, there are issues: maybe it is hard to communicate across different time zones, or additional tasks appear that break your initial plan. In most of the cases, those things can be controlled. However, sometimes, they are big enough to lead to failed IT projects. This can cost you time, money, reputation, and even a whole business. How can this be avoided?

This article will let you in on some of the reasons why software projects fail and show what you can do to minimize your risks. First, we define what we mean by a failure of a software project.

What translates to a failed software project?

A project is deemed a failure when it must be abandoned before release or removed from the market after launch. The reasons for failed IT projects are varied, ranging from minor issues like insufficient resources to major management inefficiencies. Typically, they fall into the following categories:

Delays in a project can significantly damage relationships with stakeholders who are eagerly awaiting the outcomes and profits. Additionally, markets are dynamic, and readiness to adapt to these changes is crucial.

Unexpected difficulties are part of every project and often require additional investment. However, if extra funding isn’t feasible, the project may need to be cancelled or paused until conditions improve.

Releasing a low-quality product can have severe repercussions. A notable example is Samsung’s problematic phone batteries, which caused major issues upon release (see below for more details).

Use and Market Fit

If your solution doesn’t meet customer needs or isn’t user-friendly, it will struggle to gain traction in the market.

Failures often compound upon one another. For example, time and resource pressures might force your team to cut corners, compromising quality. Alternatively, trying to minimize costs during the discovery stage can result in a product that poorly fits the market.

Understanding these factors can help identify potential pitfalls early and implement strategies to mitigate risks, ensuring a higher likelihood of project success.

High-Profile Failed IT Projects Examples

Real-world case studies of failed IT projects offer valuable lessons on what can lead to a project’s downfall. Here are some notable examples:

NHS IT System Project Failure

Hasty execution is often a recipe for disaster, especially in large-scale projects with significant responsibilities. The UK’s National Programme for IT , designed to overhaul the patient health record system, is a prime example. The government underestimated the requirements, leading to an unrealistic and rushed schedule from the start. This debacle cost taxpayers approximately £10 billion.

Samsung’s Exploding Batteries

In 2016, Samsung faced one of the worst crises in its history. The launch of the Samsung Galaxy Note 7 in August was highly anticipated, but by September, reports of overheating and exploding batteries began flooding social media. Samsung had to discontinue the entire product line and recall around 2.5 million phones .

Toyota’s Accelerator Fault

Toyota’s notable IT project failure stemmed from an accelerator malfunction in its Lexus range. Due to a system fault and improper memory handling, the cars experienced unintended acceleration. Within weeks, Toyota recalled millions of vehicles and was fined $32.4 million .

These examples illustrate that the consequences of project failures extend beyond budget overruns. Companies risk losing their reputation and can even endanger users’ lives.

A survey of 3,234 project management practitioners revealed that 14% of projects fail. Understanding the reasons behind these failures is crucial to minimizing risks in future projects. Let’s investigate why software projects fail and how to mitigate these risks.

Causes Leading to Failed IT Projects and How to Overcome Them

Understanding why software projects fail is essential for improving your chances of success. Here are some typical issues you may encounter during project implementation and strategies to overcome them.

Unclear Project Goals

One of the primary reasons for failed IT projects is the lack of clear objectives. Approximately 37% of projects fail because the goals are not well-defined. Without a clear vision of what you aim to achieve, it’s challenging to identify when the project is off track.

Solution: Establish Measurable Success Criteria

Define clear and measurable objectives for your software project. For instance, you might aim for a solution that increases your conversion rate by 30%. Once you’ve established your key performance indicators (KPIs), you can develop a project plan based on these metrics.

Unrealistic Expectations

While ambitious goals can drive innovation, they must align with the expectations of your target users. It’s crucial to avoid succumbing to stakeholder pressure and overestimating what can be achieved.

Unrealistic expectations can lead to rushed tasks, poor decision-making, and shortcuts that compromise the quality of the product.

Solution: Conduct Thorough Research and Maintain Open Communication

Validate your ideas before diving in. Conduct focus groups to gauge how your target market will react to your concept before significant investment.

Moreover, maintain open lines of communication. Regular discussions with stakeholders, team members, and subject matter experts are essential for rational decisions.

Vague Project Scope

A poorly defined project scope, often caused by unclear goals and overconfidence, is a major reason for failed IT projects. The project scope outlines the activities and resources required to deliver a project. Without a well-defined scope, it’s challenging to establish milestones, assemble an effective team with the necessary expertise, and delegate tasks appropriately. Poor planning accounts for 39% of failed It projects.

A vague project scope can lead to several issues:

• Incorrect Cost Estimation: Inaccurate cost projections can restrict resources, affecting the quality of deliverables. Budget constraints might even force project pauses.
• Incorrect Time Estimation: Delays can arise from inaccurate cost estimates, shifting milestones, scope changes, team collaboration gaps, or resource shortages. These delays slow the time to market, causing lost customers and stakeholder dissatisfaction.
• Unforeseen Resource Gaps: Resource allocation is complex and can be disrupted by unexpected issues, such as simultaneous employee absences or the failure of outdated systems.

Solution: Comprehensive Advance Planning

While “plan in advance” may sound obvious, it is crucial and often challenging. Here are some tips to avoid failed IT projects:

• Resource, Timeline, and Cost Planning: List the necessary talent, software tools, and hardware resources. Plan milestones, break them into tasks, and assign team members and resources to each milestone. This will help you calculate the project cost and create a detailed schedule.
• Use Project Management Tools: These tools help estimate task timelines accurately, optimize resource usage, and improve cost estimation. They streamline processes, track task dependencies, and monitor project metrics.
• Hire a Dedicated Team: If in-house expertise is lacking, partner with a reliable team. Experienced partners can offer valuable insights and use methods like bottom-up estimation or reverse analysis to recommend the best approach.

Inadequate Project Documentation

Proper documentation is critical for project planning. It consolidates all prerequisites for the project scope, including software requirements specifications and user manuals. Without thorough documentation, it’s difficult to align team efforts with client expectations and ensure team commitment to deliverables.

Solution: Centralize and Automate Documentation

• Central Repository and Document Management Software: Centralize documentation management to avoid scattered documents across spreadsheets, emails, and chat messages.
• Automate Documentation Processes: Use tools that manage document version history in real-time, allowing seamless import, storage, sharing, export, and security of documents. This keeps the team and stakeholders informed and connected throughout the project.

Poor Communication Within the Project Team

Ineffective communication, particularly during critical moments, can exacerbate an already complex project and lead to unsatisfactory failed IT projects.

Solution: Cultivate the Right Culture and Use the Right Tools

Successful software projects often feature teams that complement each other’s knowledge and collaborate effectively to solve problems. Implementing a project management approach that promotes transparency and collaboration is key to ensuring smooth teamwork.

• Ensure Clarity: Every team member understands the overall project goals, their specific responsibilities, and how their work contributes to the project’s success. This fosters inspiration and engagement.
• Encourage Active Listening: Valuing team input helps members feel heard and appreciated.
• Implement Effective Tools: Set up robust tools for online communication, video conferencing, project management, and file-sharing to facilitate seamless interaction.

If you’re new to project management, consider partnering with a web development firm that has a transparent and well-established workflow. This can provide the support needed to navigate initial challenges.

Unforeseen Risks

Ignoring potential risks can delay project implementation, lead to cost overruns, or jeopardize the project’s success. Undefined opportunities and risks cause 27% of failed IT projects . While predicting the future is impossible, proactive risk management can mitigate these issues.

Solution: Proactive Risk Management

Effective risk management involves identifying potential problems early and capitalizing on possible opportunities. Here’s a strategy for managing risks:

• Brainstorm Risks: Identify all potential risks at the project’s outset.
• Communicate Risks: Inform clients and stakeholders about these risks early to prevent surprises.
• Evaluate Risks: Assess each risk based on its nature, potential impact, and likelihood of occurrence.
• Prioritize Risks: Rank the risks to focus on the most critical ones.
• Mitigate Risks: Develop strategies to reduce the likelihood and impact of each risk.
• Preventive Measures: Implement measures to prevent risks from occurring.
• Response Plan: Decide on actions to take if a risk materializes.

By addressing risks proactively, you can prevent them from escalating into major issues, as seen in the Toyota case. Proper risk management aligns with customer expectations and enhances project success.

Achieving Success in Software Projects

To achieve success in software projects, it’s essential to anticipate potential issues throughout the development lifecycle. Here are some key strategies:

Clear Goals and Realistic Planning

Ensure that everyone on your team fully understands the project goals. This clarity allows you to develop a realistic project scope, adhere to timelines and budgets, and allocate resources efficiently. Collaboration, both within your team and with stakeholders, is crucial.

Partnering with Experts

Consider collaborating with an experienced software development company. Their expertise can significantly enhance your project’s chances of success.

Choosing the Right Software Development Agency

Selecting the right outsourcing partner involves various criteria, such as cooperation and pricing models, corporate culture, industry knowledge, and technical expertise. Here are some tips to help you choose:

Understanding Business Needs

Ensure the agency shows a keen interest in understanding your business requirements. This understanding guarantees accurate project estimates and clear articulation of how they plan to meet your needs.

Development Methodologies

Inquire about the software development methodologies the agency uses. Agile techniques like Scrum and Kanban are popular due to their flexibility. However, the choice of methodology should suit your specific project needs. For instance, Kanban is ideal for continuous delivery, while Scrum, with its sprint-based approach, can accelerate time to market.

Communication

Assess the agency’s communication practices. Find out what tools they use to provide updates and how frequently they will contact you. A dependable partner will keep you well-informed, be transparent about potential challenges, and avoid making unrealistic promises.

With these tips, you can find the best partner to help you deliver a successful product and avoid delivering failed IT projects.

Why Choose Ajackus? Your Tech Partner in India for Software Projects

In today’s digital world, having just a great idea isn’t enough. Businesses need a powerful boost to drive them towards exponential growth and outshine their competition.

At Ajackus, we’re more than just IT service providers ; we’re your dedicated mission control, carefully crafting custom solutions to ensure no failed IT projects.

Extensive Experience

With over 12 years of industry expertise, we’ve successfully navigated the diverse landscapes of over 15 industries, including healthcare, fintech, real estate, edtech, oil and gas, travel, HRtech, and more.

Broad Proficiencies

Our technical proficiency spans across 100+ technologies , including JavaScript, PHP, Python, Java, Ruby, QA Manual, Go, iOS, DevOps, Android, Spring Boot, React, Angular, Ruby on Rails, and more.

Proven Track Record

Committed to excellence, we’ve delivered over 300+ successful projects , demonstrating our ability to convert industry knowledge and technical skills into tangible outcomes.

Significant User Impact

Our solutions have positively impacted over 500 million end users, highlighting our significant role in enhancing digital experiences.

Strong Communication

We prioritize English proficiency to ensure effective and transparent collaboration, maintaining clear communication with our clients throughout the project lifecycle.

High Client Satisfaction

Our clients’ satisfaction is evident from the positive feedback and enduring partnerships we’ve built. With an impressive 4.9 rating on Clutch , we have been recognized as the Top App Development Company and Top Software Developers for 2022, 2023, and 2024.

Agile Methodology

Our agile approach allows us to quickly adapt to changing project requirements. For example, our Product Requirement Document (PRD) process typically takes 2-4 weeks (30-40 hours), while the development of a Minimum Viable Product (MVP) is usually completed in 8-12 weeks, ensuring efficiency without compromising quality.

This is just a snapshot of the comprehensive IT solutions we offer at Ajackus. We’re here to elevate your business and fuel your growth.

Conclusion: Save Your Failed IT Projects Now!

Life would be a much easier place if everything went as planned. But, no—as every project manager would attest—things are quite the opposite, and problems will arise.

We hope this article has helped you assess how well you understand a project’s risks of failure and guided you through actions to improve your software development project management workflow. We are right here in case you need the support of an experienced software development partner.

Want to achieve a 100% success rate and avoid failed IT projects? Let’s talk about it.

Start a Project with Ajackus

You may also like.

16 Strategies for Crafting an Intuitive Dashboard UI Design

What Low Code And No Code Can Build You?

Low code no code: Why Tech Development Democratization Good for Businesses?

Benefits of Staff Augmentation in Project Flexibility

Most Reviewed Staff Augmentation Agency in India

A Comprehensive Analysis to Legacy Application Modernization

Can IoT Development Transform Your Business?

An Ultimate Guide to DevOps Outsourcing for Your Business

How AI Trip Planner Is Making Tourism Smarter?

The State of UI UX Design Trends in 2024

Can UI UX Web Design Boost Website Performance?

Let’s build your project together.

Fill out the form, and our growth experts will get back to you within 1 business day.

Recognized and appreciated by leaders and entrepreneurs just like you.

Cookie policy

Lessons learned from successful and failed UX Design projects

by Davide Guaglianone | May 10, 2023 | Case Studies , User Experience | 0 comments

Reading Time: 6 minutes

In the ever-evolving world of user experience (UX) design, professionals are constantly seeking ways to sharpen their skills and stay ahead of the curve. One of the most valuable resources available to them is UX case studies. These real-world examples offer a unique opportunity to learn from both successful and failed design projects, providing insights into what works and what doesn’t.

Whether it’s a groundbreaking innovation or a cautionary tale, UX case studies serve as a treasure trove of knowledge that can help designers and teams fine-tune their own approaches. Uncovering key patterns and trends, better understanding the impact of design decisions, and ultimately delivering more satisfying experiences to users can be achieved through dissecting these examples. So, what are some of the most important lessons we can learn from these case studies, and how can we apply them to our own projects? Read on to find out.

Table of Contents

The importance of UX case studies

UX case studies are instrumental in the growth and development of designers and teams alike. They offer invaluable insights into the experiences of others, enabling us to learn from both their triumphs and setbacks.

One of the main benefits of studying UX case studies is the ability to identify patterns and trends that emerge across different projects. Designers can develop a deeper understanding of the principles and strategies that lead to successful outcomes by identifying and acknowledging these patterns. Additionally, observing trends can help us stay current with industry shifts and adapt our methods accordingly.

Another crucial aspect of UX case studies is the opportunity to assess project outcomes and feedback. These examples often contain detailed information about the design process, including the challenges faced, solutions implemented, and the results achieved. Examining this data can enable us to cultivate a more precise understanding of effective and ineffective elements, which can then better inform our design choices.

UX case studies serve as a powerful learning tool for designers, offering a wealth of information that can be leveraged to enhance our skills and ultimately create better user experiences. Extracting vital lessons from real-world examples and applying them to our own projects can drive continuous improvement and innovation.

Analyzing successful design projects

When we explore successful UX design projects, we can identify several key characteristics that distinguish them from others. Analyzing these projects provides valuable insights into the factors contributing to their success, which we can apply to our own work.

At the core of successful design projects lies a strong emphasis on user-centered design. This approach underlines the importance of understanding users’ needs, preferences, and pain points, allowing designers to create tailored solutions that address specific requirements. Ensuring our solutions are both effective and delightful involves prioritizing the user experience and placing them at the heart of the design process.

Examining successful UX projects reveals how these principles have been put into practice. For instance, Airbnb’s user-friendly platform has revolutionized the vacation rental industry with its intuitive design. By focusing on user needs and incorporating a clean, visually appealing interface, Airbnb has facilitated the process of finding and booking unique accommodations for millions of travelers worldwide.

Similarly, Apple’s success can be largely attributed to its dedication to user-centered design. The seamless integration of hardware, software, and services within the Apple ecosystem leads to a cohesive and intuitive user experience that customers have come to appreciate and expect.

To ensure that our designs resonate with users and deliver outstanding experiences, we can incorporate the insights from successful design projects that identify key ingredients for triumph.

Lessons from failed design projects

While we can learn a great deal from successful design projects, there are also valuable insights to be gained from those that did not meet their goals. Examining failed design projects helps us recognize common pitfalls and obstacles, enabling us to sidestep these mistakes in our own work.

One crucial lesson from projects that fell short is the importance of iteration and adaptation. Designers must be ready to continuously refine their solutions based on user feedback and changing circumstances. A failure to adapt and evolve often results in a suboptimal user experience.

For example, Google Glass, an ambitious attempt by Google to enter the wearable technology market, ultimately fell short due to various factors such as privacy concerns, limited functionality, and an unappealing design. Despite the initial excitement surrounding the product, Google Glass failed to connect with users and was discontinued in 2015.

Another notable example is Microsoft’s Clippy, the infamous assistant introduced in Microsoft Office 97. Clippy was intended to make the software more user-friendly; however, users found it intrusive and unhelpful. As a result, Clippy was eventually removed from the Office suite.

A deeper understanding of potential pitfalls that could hinder our efforts can be gained by studying failed design projects and others. This knowledge enables us to proactively address potential issues, leading to more successful outcomes in our own projects.

Applying lessons to your own projects

With the insights gleaned from analyzing both successful and failed design projects, we can apply these lessons to our own work, fueling continuous improvement and growth. To incorporate these learnings into your design process, consider the following strategies:

Embrace a user-centered mindset by prioritizing the understanding of your users’ needs, preferences, and pain points. Use this information to inform your design decisions and create solutions tailored to their specific requirements.

Adopt an iterative and adaptive approach, refining your designs based on user feedback and changing circumstances. Continuously test and improve your solutions to ensure they remain relevant and effective.

Collaboration and communication are essential, so foster open dialogue with your team and stakeholders. Share your findings and insights while being receptive to feedback from others. This collaborative approach helps develop more comprehensive solutions.

Balancing user needs and business goals is crucial. While focusing on user needs is vital, considering your organization’s objectives is equally important. Strive to create designs that satisfy both user requirements and business goals, delivering value to all parties involved.

Weaving these strategies into your design process enables you to utilize the insights gained from UX case studies, thereby improving your skills, developing more efficient solutions, and achieving superior outcomes for your projects. Remember that the key to success in UX design lies in continuous learning, adaptation, and growth.

Steering clear of common UX design mistakes

Steering clear of common UX design mistakes can significantly improve your projects and create better experiences for your users. Let’s explore some top UX design mistakes, their impact on users and projects, and tips for avoiding them:

Neglecting user research: Failing to conduct proper user research can lead to designs that don’t meet user needs or expectations. To avoid this, invest time in thorough user research, including interviews, surveys, and usability tests, to better understand your users.

Overloading users with information: Providing too much information can cause confusion and negatively affect the user experience. To counter this, practice content hierarchy and keep interfaces clean and focused on essential elements.

Inconsistent design elements: Inconsistency in design elements can disorient users and diminish brand recognition. To ensure a cohesive experience, develop a robust design system and adhere to it throughout your project.

Poor navigation: Difficult navigation frustrates users and hinders their ability to find information or complete tasks. To enhance usability, design intuitive and straightforward navigation that allows users to easily access the desired content.

Ignoring accessibility: Neglecting accessibility can exclude users with disabilities, limiting the reach of your design. To create an inclusive experience, follow accessibility guidelines and ensure your design is usable for all users.

To create more effective and inclusive designs that cater to the needs of a diverse user base, and ultimately lead to more successful projects, it is important to be aware of these common UX design mistakes and take proactive steps to avoid them.

The role of collaboration and feedback

Collaboration and feedback play a crucial role in the UX design process, significantly contributing to the success of a project. The importance of teamwork in UX design cannot be overstated, as it allows for the pooling of diverse skills, perspectives, and ideas, leading to more innovative and well-rounded solutions.

In addition to collaboration among design team members, gathering input from various stakeholders, such as product managers, developers, and even users, is essential. This input provides valuable insights that can be incorporated into the design process, ensuring that solutions align with user needs and expectations, as well as business objectives.

An essential aspect of the collaborative process is iterating and refining design solutions based on feedback. Designers must be open to critique and willing to make adjustments as needed. This iterative approach ensures that the design evolves and improves over time, ultimately resulting in a more effective and satisfying user experience.

Both collaboration and feedback are integral components of the UX design process. Designers can leverage the insights and expertise of a diverse group of stakeholders to create user-centered solutions that meet both user needs and business goals, by fostering a culture of open communication and teamwork. Embracing this collaborative mindset is key to achieving success in UX design.

UX case studies offer a wealth of insights and lessons that can be applied to our own design projects. By analyzing both successful and failed design projects, we can identify patterns and trends, as well as common pitfalls and obstacles. This knowledge helps us refine our design approaches, ensuring better outcomes and more satisfying user experiences.

We’ve explored the importance of user-centered design, collaboration, and feedback, as well as strategies for avoiding common UX design mistakes. These lessons emphasize the value of UX design and its ability to create meaningful and engaging experiences for users.

As designers, it’s crucial to embrace a mindset of continuous growth and learning. Studying UX case studies and applying their lessons to our own work can improve our skills, help us create more effective solutions, and ultimately contribute to the ongoing evolution of the UX design field.