software project failure case study

4 Interesting Cases of Software Failures and Consequences

Did you ever get an email from the hospital saying you are dead 8,000 people did… and that’s one example..

Humberto Linero

Bits and Pieces

The beauty of software development is that with just a computer and access to the internet amazing things can be created.

The role of software is apparent in multiple areas of our lives: educations, finance, healthcare, communication, and more. As a software engineer myself, I can appreciate the power and complexity involved in many of the software systems I use daily. However, the more I learn about software and its development process, the more I learn about their weaknesses and potential threats.

Although software systems are effective at calculating large and complex data, they have one main weakness: humans create these systems. And we humans make mistakes… lots of them. Therefore, it is natural that the software systems we build contain errors and are prone to failure.

Software systems have become such an essential part of our economy that whenever they fail, there are economic consequences. A research study done by software testing company Tricentis revealed that in the year 2017 software failure affected 3.6 billion people and caused $1.7 trillion in financial losses [1].

To give you an idea of possible consequences that may result from software failure, in this article, I will be presenting cases of software failure and its effects.

Case #1: St. Mary’s Mercy Hospital

Imagine waking up one day, checking your mailbox an receiving a letter from your hospital saying you died. Well, that is precisely what happened to 8500 people who received treatment between Oct 25 and Dec 11 at St. Mary’s Mercy Hospital. So what happened? It turns out the hospital had recently upgraded its patient-management software system. However, a mapping error in the software resulted in the system assigning a code of 20 (which means “expired”) instead of 01 which meant the patient had been discharged. But that is not all. The erroneous data was not only sent to the patients but also to insurance companies and the local Social Security Office. It is not clear how [2]

Case #2: National Health Service

I don’t know what is worse: Not taking your medicines at all or taking the wrong medication. Either way, at least 300,000 heart patients were given the wrong drug or advise as a result of a software fault. So, what happened? In the year 2016, it was discovered that the clinical computer system SystmOne had an error that since 2009 had been miscalculating patient’s risk of heart attack. As a result, many patients suffered heart attacks or strokes since they were told they were at low-risk, while other suffered from the side-effects of taking unnecessary medication [3].

Case #3: Air Traffic Control in LA Airport

The air traffic control has the important responsibility of informing aircraft pilots about relevant information regarding weather, routes, the distance between other airplanes, and more. Failing to communicate with aircraft pilots promptly could result in catastrophe. On September 14, 2004, at 5 P.M. air traffic control at the LA airport lost voice communication with approximately 400 airplanes being tracked in the southwestern United States and many planes were headed towards each other. So what happened? The primary voice communication system shut down unexpectedly. To top it off the backup system failed a few minutes after it was turned on. The cause of the error was that the communication system had an internal timer that ticks off in milliseconds. After it reached zero, it could not time itself so it would shut down. The outage affected 800 flights across the country [4].

Case #4: Toyota

In the mid-2000’s many Toyota drivers were reporting that their car was accelerating without them touching the pedal. After a series of accidents, which lead to investigations, investigators discovered that software errors were the cause of the unintended acceleration. In this case, there was a series of things wrong with the software installed in Toyota cars: Memory corruption, wrong memory handling, disabling safety systems, systems with single points of failure, and thousands of global variables. Toyota recalled millions of vehicles and Toyota’s stock price decreased 20% a month after the cause of the problem was discovered. This case demonstrates the consequences of not giving enough attention to good programming practices and testing as a result of wanting to launch the product.

In this article, we examined various cases of software failure and their consequences. These cases demonstrate that our society has a high dependency level on software and that whenever it fails, not only economic consequences can arise.

As long as humans are involved in the development process, software systems will contain errors and will be prone to failure. As software developers, our responsibility is to ensure that the systems we built are thoroughly tested in different and realistic conditions. It is to ensure that the software we are promoting is actually capable of helping and not harming its users. In many cases, competition and the desire to be the first on the market are the motivators for launching an untested and unfinished product. As software users, our responsibility is to use our software tools as a support for our activities and not blindly accept their results or suggestions.

If you enjoyed this article, please recommend and share. Don’t forget to subscribe and follow me on Twitter to stay up-to-date with my latest posts. See you in the next article.

[1] https://www.techrepublic.com/article/report-software-failure-caused-1-7-trillion-in-financial-losses-in-2017/ [2] http://www.baselinemag.com/c/a/Projects-Networks-and-Storage/Hospital-Revives-Its-QTEDeadQTE-Patients [3] http://www.dailymail.co.uk/health/article-3585149/Up-300-000-heart-patients-given-wrong-drugs-advice-major-NHS-blunder.html [4] http://www.cse.psu.edu/~gxt29/bug/softwarebug.html

SOLID Principles every Developer Should Know

A short yet detailed introduction to understanding solid design principles..

blog.bitsrc.io

A Guide to Test-Driven Development (TDD): Shorter Feedback Loop, Faster Workflow

Trust me, i used to hate testing too., keep it simple with the strategy design pattern, understanding the strategy design pattern to reduce your code’s complexity.

Written by Humberto Linero

Software Engineer

More from Humberto Linero and Bits and Pieces

What to Expect From Your Future Software Engineering Degree

My personal experience in a nutshell.

Ruvani Jayaweera

Implementing the API Gateway Pattern in a Microservices Based Application with Node.js

Build your own api gateway using node.js in under 5 minutes.

Chameera Dulanga

Best-Practices for API Authorization

4 best practices for api authorization.

Computer Science and Software Engineering: Clearing the confusion

It is common in the software domain to hear terms such as computer scientist, developer, programmer, software engineer, computer engineer…, recommended from medium.

Somnath Singh

Level Up Coding

The Era of High-Paying Tech Jobs is Over

The death of tech jobs..

My toolkit for 2024

I didn’t expect to write about my toolkit again so soon since i already made a big update in january 2023, but here we are..

General Coding Knowledge

Stories to Help You Grow as a Software Developer

Good Product Thinking

Practical Tips for Job Searching

In the ever-changing landscape of the job market, finding a new job can seem like a challenging expedition. i’ve had the privilege of….

Benedict Neo

bitgrit Data Science Publication

Roadmap to Learn AI in 2024

A free curriculum for hackers and programmers to learn ai.

Benoit Ruiz

Better Programming

Advice From a Software Engineer With 8 Years of Experience

Practical tips for those who want to advance in their careers.

Alexandru Lazar

ILLUMINATION

Ten Habits that will get you ahead of 99% of People

Improve your life and get ahead of your peers in 10 simple steps.

Text to speech

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

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

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

In this failed projects guide you will discover:

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

10. Sony Betamax

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

Lessons learned:

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

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

9. New Coke

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

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

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

8. Polaroid Instant Home Movies

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

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

7. Crystal Pepsi

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

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

6. McDonald's Arch Deluxe Burger

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

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

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

5. Apple Lisa

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

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

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

4. Levi Type 1 Jeans

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

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

3. IBM PCjr

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

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

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

2. The DeLorean DMC-12

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

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

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

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

1. The Ford Edsel

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

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

Five ways to spot project failures before they happen.

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

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

1. Low interest

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

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

2. Poor communication

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

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

3. Lack of velocity

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

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

4. A “no bad news” environment

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

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

5. Scope creep

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

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

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

Frequently asked questions about project failures.

What is a failed project?

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

What can we learn from a failed project?

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

How do I recover from a failed project?

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

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?

• Developer Blog
• Project Management Tips

How to Turnaround a Failing Software Project

Aran Davies

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

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

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

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

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

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

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

1. Assess what went wrong with the project

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

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

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

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

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

Hire expert developers for your next project

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

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

2. Analyze the root causes of the project challenges

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

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

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

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

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

3. Determine whether you have a capable team

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

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

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

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

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

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

4. Check whether you need to replace any developer

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

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

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

5. Ascertain whether the project team has enough developers

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

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

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

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

6. Plan to turn around the project

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

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

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

6a. SDLC model

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

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

6b. IT architecture

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

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

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

6c. Mitigating the application security risks

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

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

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

6d. “Managed Cloud Services” (MCS)

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

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

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

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

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

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

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

6e. Designing APIs

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

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

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

Read “ REST vs. GraphQL ” for more insights.

6f. Choosing the right technology stack

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

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

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

7. Execute the turnaround plan and track its progress

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

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

How About Preventing Your Project From Failing?

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

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

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

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

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

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

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

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

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

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

Alexey Semeney

Founder of DevTeam.Space

Hire Alexey and His Team To Build a Great Product

Alexey is the founder of DevTeam.Space. He is among the Top 26 mentors of FI’s ‘Global Startup Mentor Awards’ and is a Band Of Angels Technology Expert.

Some of our projects

Backend, Communication, DevOps, Java, Software

Management Center of Telecommunication Information

Development Team

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

Cryptocurrency Exchange

Blockchain, Ethereum, Fintech, Node.js, Smart Contracts, Solidity, Trading, Truffle

Read about DevTeamSpace:

New Internet Unicorns Will Be Built Remotely

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

The Tricks To Hiring and Managing a Virtual Work Force

DevTeam.Space Explains How to Structure Remote Team Management

With love from Florida 🌴

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

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

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

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

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

Trusted by 100x of startups and enterprise companies like

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

Real life examples of software development failures

Tricentis staff, various contributors.

No matter how technology advances, software testing will always be non-negotiable. Every week new stories emerge of software failing across a myriad of industries; sparking chaos, halting business, or even costing lives. Every year, Tricentis collects news stories from around the world, culminating in the Tricentis Software Fail Watch, an analysis of software bugs found in a year’s worth of English language news articles. These include software engineering failures of all sorts–security, usability, performance, and so on.

The Software Fail Watch is a sobering reminder of the scope of impact that software and therefore – software development and testing – has on our day to day lives. As the examples of recent software failures below reveal, a major software failure can result in situations far worse than a buggy app or inconvenient service outage.

Medicine infusion pumps recalled for deadly flaw

CareFusion is a medical equipment manufacturer that has experienced several emergency recalls in recent years. In 2015, CareFusion’s Alaris Pump was recalled over a software error that caused the pump, designed to automatically deliver medicine and fluids to hospital patients, to delay an infusion. The consequences, which can range anywhere from medicine being withheld at critical points or accidental over-dosing, can be deadly. Just four days later CareFusion issued a Class I recall over a separate line of ventilators, citing a software flaw that could cause the patient to suffocate.

Software glitch in F-35 fighter planes causes target detection problems

This spring a serious software glitch in the F-35 Joint Strike Fighter air crafts garnered wide public attention. The plane engineers identified a software bug that causes the planes, when flying in formation, to incorrectly detect targets. As each of the planes within the formation detect a target from varying angles, the software is reportedly unable to decipher whether there is just one or multiple targets. As one news agency put it, the F-35’s are “seeing double”.

Software bug assists in bank heist

This story comes in two parts: one software bug related, one not. The first part to hit the news in mid-March detailed how a group of hacker-thieves hijacked the Bangladesh Bank system to steal funds. The group successfully transferred $81 million in four transactions, before making a spelling error that tipped off the bank, causing another $870 million in transfers to be canceled.

The software bug comes in with the $81 million the thieves did successfully steal. According to Bangladesh Bank authorities, a printer is set up to automatically print read-outs of transactions made. The glitch in the system (whether coincidental or created by the thieves), interrupted the automatic printing process, so that is was only several days later that the transfer receipts were even discovered – giving the thieves plenty of time to cover their tracks.

Software glitch causes SolarCity Corp to be undervalued by $400 million in acquisition

SolarCity Corp retained an investment bank to assist in the sale of the company to Tesla Motors Inc. After the $2.6 billion dollar agreement had been signed however, the investment bank, Lazard Ltd., discovered that they had under-valued SolarCity Corp by roughly $400 million. Whoops. Unfortunately the error was discovered too late for SolarCity’s shareholders, but Tesla did offer to make up some of the difference in stock.

Frenchman sues Uber over a software bug

It’s not often you hear of a software bug resulting in divorce, but we are living in exceptional times. A common Uber app bug revealed a man’s affair to his wife, leading to a divorce and a lawsuit landing in Uber’s lap. The bug causes Uber notifications to be pushed to a device, even after logging out of your account on that device. In this case, the “cheating Frenchman”, who had once called an Uber from his wife’s phone, was exposed when she received notifications of using Uber to visit his mistress. The angry ex-husband is now suing Uber for up to $45 million in damages.

The Equifax social security hack

Equifax, one of the United States’ largest credit reporting agencies, announced that up to 143 million of their consumer records were stolen by hackers. Names, Social Security numbers, birth dates, and credit card numbers were all amongst the data stolen. Given that the population of the United States clocks in at 321 million, that means that approximately 50% of Americans could now find themselves in danger of identity theft or worse. Though the hack took place in May 2017, Equifax hid the story until early September, further outraging the public. As details of the hack have emerged, it quickly became clear that much of the damage done was a result of vast negligence on Equifax’s part.

Hawaii sends out a state-wide false alarm about a missile strike

In January 2018, the citizens of Hawaii were notified to take immediate cover in the face of an inbound ballistic missile strike. It turned out to be a false alarm, although it took over 30 minutes (and, presumably, several thousand heart attacks) before the alert was retracted. Investigations found that while the problem was largely due to human error, there were “troubling” design flaws in the Hawaii Emergency Management Agency’s alert origination software.

Related resources

The quest for mobile quality: Key takeaways from our research

Controlling the chaos: how wolters kluwer built a foundation for standardized quality on a global scale.

Performance testing for holiday readiness: How to handle traffic spikes when any day could be a holiday

Building a modern testing center of excellence, fast track your journey to sap s/4hana with the tricentis sap solution.

• 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

This month’s patch tuesday release is a big one, after cloud providers, uk antitrust regulator takes aim at ai, will ai end apple's existential crisis, usb-c explained: how to get the most from it (and why it keeps on getting better), 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

10 smartsheet tips and tricks, ar and vr bring a new twist to collaboration, how it can prepare for vr, ar and mr in the enterprise, how to cure ‘corporate amnesia’ with knowledge management software, most popular authors.

• Howard Wen Contributing Writer

Show me more

The desktop processor market is suddenly hot again.

How Intel's 'AI everywhere' strategy could challenge Nvidia's dominance

5 advanced tricks for Google’s Circle to Search on Android

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

Voice cloning, song creation via AI gets even scarier

The link between smartphones and social media addiction

Is AR/VR set for another growth spurt?

Hey there, human — the robots need you! Vote for IEEE’s Robots Guide in the Webby Awards.

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 →, 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 →, 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., why software fails, we waste billions of dollars each year on entirely preventable mistakes.

Have you heard the one about the disappearing warehouse? One day, it vanished—not from physical view, but from the watchful eyes of a well-known retailer's automated distribution system. A software glitch had somehow erased the warehouse's existence, so that goods destined for the warehouse were rerouted elsewhere, while goods at the warehouse languished. Because the company was in financial trouble and had been shuttering other warehouses to save money, the employees at the “missing" warehouse kept quiet. For three years, nothing arrived or left. Employees were still getting their paychecks, however, because a different computer system handled the payroll. When the software glitch finally came to light, the merchandise in the warehouse was sold off, and upper management told employees to say nothing about the episode.

This story has been floating around the information technology industry for 20-some years. It's probably apocryphal, but for those of us in the business, it's entirely plausible. Why? Because episodes like this happen all the time. Last October, for instance, the giant British food retailer J Sainsbury PLC had to write off its US $526 million investment in an automated supply-chain management system. It seems that merchandise was stuck in the company's depots and warehouses and was not getting through to many of its stores. Sainsbury was forced to hire about 3000 additional clerks to stock its shelves manually [see photo above, "Market Crash"].

This is only one of the latest in a long, dismal history of IT projects gone awry [see table above, "Software Hall of Shame" for other notable fiascoes]. Most IT experts agree that such failures occur far more often than they should. What's more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. The business and societal costs of these failures—in terms of wasted taxpayer and shareholder dollars as well as investments that can't be made—are now well into the billions of dollars a year.

The problem only gets worse as IT grows ubiquitous. This year, organizations and governments will spend an estimated $1 trillion on IT hardware, software, and services worldwide. Of the IT projects that are initiated, from 5 to 15 percent will be abandoned before or shortly after delivery as hopelessly inadequate. Many others will arrive late and over budget or require massive reworking. Few IT projects, in other words, truly succeed.

The biggest tragedy is that software failure is for the most part predictable and avoidable. Unfortunately, most organizations don't see preventing failure as an urgent matter, even though that view risks harming the organization and maybe even destroying it. Understanding why this attitude persists is not just an academic exercise; it has tremendous implications for business and society.

SOFTWARE IS EVERYWHERE. It's what lets us get cash from an ATM, make a phone call, and drive our cars. A typical cellphone now contains 2 million lines of software code; by 2010 it will likely have 10 times as many. General Motors Corp. estimates that by then its cars will each have 100 million lines of code.

The average company spends about 4 to 5 percent of revenue on information technology, with those that are highly IT dependent—such as financial and telecommunications companies—spending more than 10 percent on it. In other words, IT is now one of the largest corporate expenses outside employee costs. Much of that money goes into hardware and software upgrades, software license fees, and so forth, but a big chunk is for new software projects meant to create a better future for the organization and its customers.

Governments, too, are big consumers of software. In 2003, the United Kingdom had more than 100 major government IT projects under way that totaled $20.3 billion. In 2004, the U.S. government cataloged 1200 civilian IT projects costing more than $60 billion, plus another $16 billion for military software.

Any one of these projects can cost over $1 billion. To take two current examples, the computer modernization effort at the U.S. Department of Veterans Affairs is projected to run $3.5 billion, while automating the health records of the UK's National Health Service is likely to cost more than $14.3 billion for development and another $50.8 billion for deployment.

Such megasoftware projects, once rare, are now much more common, as smaller IT operations are joined into “systems of systems." Air traffic control is a prime example, because it relies on connections among dozens of networks that provide communications, weather, navigation, and other data. But the trick of integration has stymied many an IT developer, to the point where academic researchers increasingly believe that computer science itself may need to be rethought in light of these massively complex systems.

When a project fails , it jeopardizes an organization's prospects. If the failure is large enough, it can steal the company's entire future. In one stellar meltdown, a poorly implemented resource planning system led FoxMeyer Drug Co., a $5 billion wholesale drug distribution company in Carrollton, Texas, to plummet into bankruptcy in 1996.

IT failure in government can imperil national security, as the FBI's Virtual Case File debacle has shown. The $170 million VCF system, a searchable database intended to allow agents to “connect the dots" and follow up on disparate pieces of intelligence, instead ended five months ago without any system's being deployed [see “ Who Killed the Virtual Case File? " in this issue].

IT failures can also stunt economic growth and quality of life. Back in 1981, the U.S. Federal Aviation Administration began looking into upgrading its antiquated air-traffic-control system, but the effort to build a replacement soon became riddled with problems [see photo, "Air Jam," at top of this article]. By 1994, when the agency finally gave up on the project, the predicted cost had tripled, more than $2.6 billion had been spent, and the expected delivery date had slipped by several years. Every airplane passenger who is delayed because of gridlocked skyways still feels this cancellation; the cumulative economic impact of all those delays on just the U.S. airlines (never mind the passengers) approaches $50 billion.

Worldwide, it's hard to say how many software projects fail or how much money is wasted as a result. If you define failure as the total abandonment of a project before or shortly after it is delivered, and if you accept a conservative failure rate of 5 percent, then billions of dollars are wasted each year on bad software.

For example, in 2004, the U.S. government spent $60 billion on software (not counting the embedded software in weapons systems); a 5 percent failure rate means $3 billion was probably wasted. However, after several decades as an IT consultant, I am convinced that the failure rate is 15 to 20 percent for projects that have budgets of $10 million or more. Looking at the total investment in new software projects—both government and corporate—over the last five years, I estimate that project failures have likely cost the U.S. economy at least $25 billion and maybe as much as $75 billion.

Of course, that $75 billion doesn't reflect projects that exceed their budgets—which most projects do. Nor does it reflect projects delivered late—which the majority are. It also fails to account for the opportunity costs of having to start over once a project is abandoned or the costs of bug-ridden systems that have to be repeatedly reworked.

Then, too, there's the cost of litigation from irate customers suing suppliers for poorly implemented systems. When you add up all these extra costs, the yearly tab for failed and troubled software conservatively runs somewhere from $60 billion to $70 billion in the United States alone. For that money, you could launch the space shuttle 100 times, build and deploy the entire 24-satellite Global Positioning System, and develop the Boeing 777 from scratch—and still have a few billion left over.

Why do projects fail so often?

Among the most common factors:

• Unrealistic or unarticulated project goals
• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project's status
• Unmanaged risks
• Poor communication among customers, developers, and users
• Use of immature technology
• Inability to handle the project's complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures

Of course, IT projects rarely fail for just one or two reasons. The FBI's VCF project suffered from many of the problems listed above. Most failures, in fact, can be traced to a combination of technical, project management, and business decisions. Each dimension interacts with the others in complicated ways that exacerbate project risks and problems and increase the likelihood of failure.

Consider a simple software chore: a purchasing system that automates the ordering, billing, and shipping of parts, so that a salesperson can input a customer's order, have it automatically checked against pricing and contract requirements, and arrange to have the parts and invoice sent to the customer from the warehouse.

The requirements for the system specify four basic steps. First, there's the sales process, which creates a bill of sale. That bill is then sent through a legal process, which reviews the contractual terms and conditions of the potential sale and approves them. Third in line is the provision process, which sends out the parts contracted for, followed by the finance process, which sends out an invoice.

Let's say that as the first process, for sales, is being written, the programmers treat every order as if it were placed in the company's main location, even though the company has branches in several states and countries. That mistake, in turn, affects how tax is calculated, what kind of contract is issued, and so on.

The sooner the omission is detected and corrected, the better. It's kind of like knitting a sweater. If you spot a missed stitch right after you make it, you can simply unravel a bit of yarn and move on. But if you don't catch the mistake until the end, you may need to unravel the whole sweater just to redo that one stitch.

If the software coders don't catch their omission until final system testing—or worse, until after the system has been rolled out—the costs incurred to correct the error will likely be many times greater than if they'd caught the mistake while they were still working on the initial sales process.

And unlike a missed stitch in a sweater, this problem is much harder to pinpoint; the programmers will see only that errors are appearing, and these might have several causes. Even after the original error is corrected, they'll need to change other calculations and documentation and then retest every step.

In fact, studies have shown that software specialists spend about 40 to 50 percent of their time on avoidable rework rather than on what they call value-added work, which is basically work that's done right the first time. Once a piece of software makes it into the field, the cost of fixing an error can be 100 times as high as it would have been during the development stage.

If errors abound, then rework can start to swamp a project, like a dinghy in a storm. What's worse, attempts to fix an error often introduce new ones. It's like you're bailing out that dinghy, but you're also creating leaks. If too many errors are produced, the cost and time needed to complete the system become so great that going on doesn't make sense.

In the simplest terms, an IT project usually fails when the rework exceeds the value-added work that's been budgeted for. This is what happened to Sydney Water Corp., the largest water provider in Australia, when it attempted to introduce an automated customer information and billing system in 2002 [see box, " Case Study #2 "]. According to an investigation by the Australian Auditor General, among the factors that doomed the project were inadequate planning and specifications, which in turn led to numerous change requests and significant added costs and delays. Sydney Water aborted the project midway, after spending AU $61 million (US $33.2 million).

All of which leads us to the obvious question: why do so many errors occur?

Software project failures have a lot in common with airplane crashes. Just as pilots never intend to crash, software developers don't aim to fail. When a commercial plane crashes, investigators look at many factors, such as the weather, maintenance records, the pilot's disposition and training, and cultural factors within the airline. Similarly, we need to look at the business environment, technical management, project management, and organizational culture to get to the roots of software failures.

Chief among the business factors are competition and the need to cut costs. Increasingly, senior managers expect IT departments to do more with less and do it faster than before; they view software projects not as investments but as pure costs that must be controlled.

Political exigencies can also wreak havoc on an IT project's schedule, cost, and quality. When Denver International Airport attempted to roll out its automated baggage-handling system, state and local political leaders held the project to one unrealistic schedule after another. The failure to deliver the system on time delayed the 1995 opening of the airport (then the largest in the United States), which compounded the financial impact manyfold.

Even after the system was completed, it never worked reliably: it chewed up baggage, and the carts used to shuttle luggage around frequently derailed. Eventually, United Airlines, the airport's main tenant, sued the system contractor, and the episode became a testament to the dangers of political expediency.

A lack of upper-management support can also damn an IT undertaking. This runs the gamut from failing to allocate enough money and manpower to not clearly establishing the IT project's relationship to the organization's business. In 2000, retailer Kmart Corp., in Troy, Mich., launched a $1.4 billion IT modernization effort aimed at linking its sales, marketing, supply, and logistics systems, to better compete with rival Wal-Mart Corp., in Bentonville, Ark. Wal-Mart proved too formidable, though, and 18 months later, cash-strapped Kmart cut back on modernization, writing off the $130 million it had already invested in IT. Four months later, it declared bankruptcy; the company continues to struggle today.

Frequently, IT project managers eager to get funded resort to a form of liar's poker, overpromising what their project will do, how much it will cost, and when it will be completed. Many, if not most, software projects start off with budgets that are too small. When that happens, the developers have to make up for the shortfall somehow, typically by trying to increase productivity, reducing the scope of the effort, or taking risky shortcuts in the review and testing phases. These all increase the likelihood of error and, ultimately, failure.

A state-of-the-art travel reservation system spearheaded by a consortium of Budget Rent-A-Car, Hilton Hotels, Marriott, and AMR, the parent of American Airlines, is a case in point. In 1992, three and a half years and $165 million into the project, the group abandoned it, citing two main reasons: an overly optimistic development schedule and an underestimation of the technical difficulties involved. This was the same group that had earlier built the hugely successful Sabre reservation system, proving that past performance is no guarantee of future results.

After crash investigators consider the weather as a factor in a plane crash, they look at the airplane itself. Was there something in the plane's design that caused the crash? Was it carrying too much weight?

In IT project failures, similar questions invariably come up regarding the project's technical components: the hardware and software used to develop the system and the development practices themselves. Organizations are often seduced by the siren song of the technological imperative—the uncontrollable urge to use the latest technology in hopes of gaining a competitive edge. With technology changing fast and promising fantastic new capabilities, it is easy to succumb. But using immature or untested technology is a sure route to failure.

In 1997, after spending $40 million, the state of Washington shut down an IT project that would have processed driver's licenses and vehicle registrations. Motor vehicle officials admitted that they got caught up in chasing technology instead of concentrating on implementing a system that met their requirements. The IT debacle that brought down FoxMeyer Drug a year earlier also stemmed from adopting a state-of-the-art resource-planning system and then pushing it beyond what it could feasibly do.

A project's sheer size is a fountainhead of failure. Studies indicate that large-scale projects fail three to five times more often than small ones. The larger the project, the more complexity there is in both its static elements (the discrete pieces of software, hardware, and so on) and its dynamic elements (the couplings and interactions among hardware, software, and users; connections to other systems; and so on). Greater complexity increases the possibility of errors, because no one really understands all the interacting parts of the whole or has the ability to test them.

Sobering but true: it's impossible to thoroughly test an IT system of any real size. Roger S. Pressman pointed out in his book Software Engineering, one of the classic texts in the field, that “exhaustive testing presents certain logistical problems....Even a small 100-line program with some nested paths and a single loop executing less than twenty times may require 10 to the power of 14 possible paths to be executed." To test all of those 100 trillion paths, he noted, assuming each could be evaluated in a millisecond, would take 3170 years.

All IT systems are intrinsically fragile. In a large brick building, you'd have to remove hundreds of strategically placed bricks to make a wall collapse. But in a 100 000-line software program, it takes only one or two bad lines to produce major problems. In 1991, a portion of ATandamp;T's telephone network went out, leaving 12 million subscribers without service, all because of a single mistyped character in one line of code.

Sloppy development practices are a rich source of failure, and they can cause errors at any stage of an IT project. To help organizations assess their software-development practices, the U.S. Software Engineering Institute, in Pittsburgh, created the Capability Maturity Model, or CMM. It rates a company's practices against five levels of increasing maturity. Level 1 means the organization is using ad hoc and possibly chaotic development practices. Level 3 means the company has characterized its practices and now understands them. Level 5 means the organization quantitatively understands the variations in the processes and practices it applies.

As of January, nearly 2000 government and commercial organizations had voluntarily reported CMM levels. Over half acknowledged being at either level 1 or 2, 30 percent were at level 3, and only 17 percent had reached level 4 or 5. The percentages are even more dismal when you realize that this is a self-selected group; obviously, companies with the worst IT practices won't subject themselves to a CMM evaluation. (The CMM is being superseded by the CMM-Integration, which aims for a broader assessment of an organization's ability to create software-intensive systems.)

Immature IT practices doomed the U.S. Internal Revenue Service's $4 billion modernization effort in 1997, and they have continued to plague the IRS's current $8 billion modernization. It may just be intrinsically impossible to translate the tax code into software code—tax law is complex and based on often-vague legislation, and it changes all the time. From an IT developer's standpoint, it's a requirements nightmare. But the IRS hasn't been helped by open hostility between in-house and outside programmers, a laughable underestimation of the work involved, and many other bad practices.

THE PILOT'S ACTIONS JUST BEFORE a plane crashes are always of great interest to investigators. That's because the pilot is the ultimate decision-maker, responsible for the safe operation of the craft. Similarly, project managers play a crucial role in software projects and can be a major source of errors that lead to failure.

Back in 1986, the London Stock Exchange decided to automate its system for settling stock transactions. Seven years later, after spending $600 million, it scrapped the Taurus system's development, not only because the design was excessively complex and cumbersome but also because the management of the project was, to use the word of one of its own senior managers, “delusional." As investigations revealed, no one seemed to want to know the true status of the project, even as more and more problems appeared, deadlines were missed, and costs soared [see box, " Case Study #3 "].

The most important function of the IT project manager is to allocate resources to various activities. Beyond that, the project manager is responsible for project planning and estimation, control, organization, contract management, quality management, risk management, communications, and human resource management.

Bad decisions by project managers are probably the single greatest cause of software failures today. Poor technical management, by contrast, can lead to technical errors, but those can generally be isolated and fixed. However, a bad project management decision—such as hiring too few programmers or picking the wrong type of contract—can wreak havoc. For example, the developers of the doomed travel reservation system claim that they were hobbled in part by the use of a fixed-price contract. Such a contract assumes that the work will be routine; the reservation system turned out to be anything but.

Project management decisions are often tricky precisely because they involve tradeoffs based on fuzzy or incomplete knowledge. Estimating how much an IT project will cost and how long it will take is as much art as science. The larger or more novel the project, the less accurate the estimates. It's a running joke in the industry that IT project estimates are at best within 25 percent of their true value 75 percent of the time.

There are other ways that poor project management can hasten a software project's demise. A study by the Project Management Institute, in Newton Square, Pa., showed that risk management is the least practiced of all project management disciplines across all industry sectors, and nowhere is it more infrequently applied than in the IT industry. Without effective risk management, software developers have little insight into what may go wrong, why it may go wrong, and what can be done to eliminate or mitigate the risks. Nor is there a way to determine what risks are acceptable, in turn making project decisions regarding tradeoffs almost impossible.

Poor project management takes many other forms, including bad communication, which creates an inhospitable atmosphere that increases turnover; not investing in staff training; and not reviewing the project's progress at regular intervals. Any of these can help derail a software project.

The last area that investigators look into after a plane crash is the organizational environment. Does the airline have a strong safety culture, or does it emphasize meeting the flight schedule above all? In IT projects, an organization that values openness, honesty, communication, and collaboration is more apt to find and resolve mistakes early enough that rework doesn't become overwhelming.

If there's a theme that runs through the tortured history of bad software, it's a failure to confront reality. On numerous occasions, the U.S. Department of Justice's inspector general, an outside panel of experts, and others told the head of the FBI that the VCF system was impossible as defined, and yet the project continued anyway. The same attitudes existed among those responsible for the travel reservation system, the London Stock Exchange's Taurus system, and the FAA's air-traffic-control project—all indicative of organizational cultures driven by fear and arrogance.

A recent report by the National Audit Office in the UK found numerous cases of government IT projects' being recommended not to go forward yet continuing anyway. The UK even has a government department charged with preventing IT failures, but as the report noted, more than half of the agencies the department oversees routinely ignore its advice. I call this type of behavior irrational project escalation—the inability to stop a project even after it's obvious that the likelihood of success is rapidly approaching zero. Sadly, such behavior is in no way unique.

In the final analysis , big software failures tend to resemble the worst conceivable airplane crash, where the pilot was inexperienced but exceedingly rash, flew into an ice storm in an untested aircraft, and worked for an airline that gave lip service to safety while cutting back on training and maintenance. If you read the investigator's report afterward, you'd be shaking your head and asking, “Wasn't such a crash inevitable?"

So, too, the reasons that software projects fail are well known and have been amply documented in countless articles, reports, and books [see sidebar, To Probe Further ]. And yet, failures, near-failures, and plain old bad software continue to plague us, while practices known to avert mistakes are shunned. It would appear that getting quality software on time and within budget is not an urgent priority at most organizations.

It didn't seem to be at Oxford Health Plans Inc., in Trumbull, Conn., in 1997. The company's automated billing system was vital to its bottom line, and yet senior managers there were more interested in expanding Oxford's business than in ensuring that its billing system could meet its current needs [see box, " Case Study #1 "]. Even as problems arose, such as invoices' being sent out months late, managers paid little attention. When the billing system effectively collapsed, the company lost tens of millions of dollars, and its stock dropped from $68 to $26 per share in one day, wiping out $3.4 billion in corporate value. Shareholders brought lawsuits, and several government agencies investigated the company, which was eventually fined $3 million for regulatory violations.

Even organizations that get burned by bad software experiences seem unable or unwilling to learn from their mistakes. In a 2000 report, the U.S. Defense Science Board, an advisory body to the Department of Defense, noted that various studies commissioned by the DOD had made 134 recommendations for improving its software development, but only 21 of those recommendations had been acted on. The other 113 were still valid, the board noted, but were being ignored, even as the DOD complained about the poor state of defense software development!

Some organizations do care about software quality, as the experience of the software development firm Praxis High Integrity Systems, in Bath, England, proves. Praxis demands that its customers be committed to the project, not only financially, but as active participants in the IT system's creation. The company also spends a tremendous amount of time understanding and defining the customer's requirements, and it challenges customers to explain what they want and why. Before a single line of code is written, both the customer and Praxis agree on what is desired, what is feasible, and what risks are involved, given the available resources.

After that, Praxis applies a rigorous development approach that limits the number of errors. One of the great advantages of this model is that it filters out the many would-be clients unwilling to accept the responsibility of articulating their IT requirements and spending the time and money to implement them properly. [See “ The Exterminators ," in this issue.]

Some level of software failure will always be with us. Indeed, we need true failures—as opposed to avoidable blunders—to keep making technical and economic progress. But too many of the failures that occur today are avoidable. And as our society comes to rely on IT systems that are ever larger, more integrated, and more expensive, the cost of failure may become disastrously high.

Even now, it's possible to take bets on where the next great software debacle will occur. One of my leading candidates is the IT systems that will result from the U.S. government's American Health Information Community, a public-private collaboration that seeks to define data standards for electronic medical records. The idea is that once standards are defined, IT systems will be built to let medical professionals across the country enter patient records digitally, giving doctors, hospitals, insurers, and other health-care specialists instant access to a patient's complete medical history. Health-care experts believe such a system of systems will improve patient care, cut costs by an estimated $78 billion per year, and reduce medical errors, saving tens of thousands of lives.

But this approach is a mere pipe dream if software practices and failure rates remain as they are today. Even by the most optimistic estimates, to create an electronic medical record system will require 10 years of effort, $320 billion in development costs, and $20 billion per year in operating expenses—assuming that there are no failures, overruns, schedule slips, security issues, or shoddy software. This is hardly a realistic scenario, especially because most IT experts consider the medical community to be the least computer-savvy of all professional enterprises.

Patients and taxpayers will ultimately pay the price for the development, or the failure, of boondoggles like this. Given today's IT practices, failure is a distinct possibility, and it would be a loss of unprecedented magnitude. But then, countries throughout the world are contemplating or already at work on many initiatives of similar size and impact—in aviation, national security, and the military, among other arenas.

Like electricity, water, transportation, and other critical parts of our infrastructure, IT is fast becoming intrinsic to our daily existence. In a few decades, a large-scale IT failure will become more than just an expensive inconvenience: it will put our way of life at risk. In the absence of the kind of industrywide changes that will mitigate software failures, how much of our future are we willing to gamble on these enormously costly and complex systems?

We already know how to do software well. It may finally be time to act on what we know.

• Lessons From a Decade of IT Failures ›
• The Top Programming Languages 2023 - IEEE Spectrum ›

This article is for IEEE members only. Join IEEE to access our full archive.

Membership includes:.

• Get unlimited access to IEEE Spectrum content
• Follow your favorite topics to create a personalized feed of IEEE Spectrum content
• Save Spectrum articles to read later
• Network with other technology professionals
• Establish a professional profile
• Create a group to share and collaborate on projects
• Discover IEEE events and activities
• Join and participate in discussions

Why Software Projects Fail & 6 Strategies To Make Them Succeed

Far too many software projects either fail or go sideways by not meeting their original objectives, timescales or budgets

Percentage of Projects That Fail

The statistics for software project delivery show that only one in three software projects are truly successful .

According to Standish Group’s Annual CHAOS report , 66% of technology projects (based on the analysis of 50,000 projects globally) end in partial or total failure.

Just one in three software projects are considered truly successful with large projects most at risk of failure

Despite larger projects being more prone to encountering challenges or failing altogether, even the smallest of software projects fail one in ten times.

Some of the reasons for project failure are tales as old as time – a lack of proper requirements, political imperatives, weak project sponsorship, and severe over-optimism.

You don’t have to look very far for incidents of software project failures, especially those driven by the central government, as the media are quick to speak out about the waste of taxpayer’s money.

More recent examples include:

• The failed e-borders system, which has landed the taxpayer with a £220m bill for costs and damages to Raytheon , the company contracted to deliver the scheme before it was unceremoniously axed by Theresa May in the early years of the coalition.
• £100m squandered by the BBC on a video archives system that never materialised.
• £56m Ministry of Justice back-office project cancelled after the department realised the Cabinet Office had a system doing the same thing.
• Last but by no means least, £10bn sunk into the NHS’s national programme for IT before it too was shelved.

All of this begs the question, if the UK government with its extraordinary spending power and 3 million employees in central government alone ( 2017 source ) is unable to successfully launch bespoke software , what chance do smaller businesses have?

IT projects are of course inherently complex and risky – but that’s okay, we have ways to mitigate risk and avoid failure

Despite the inherent risk in software projects now more than ever businesses understand the need to use software to leverage an advantage over their competitors.

We help our customers launch successful projects every day, and have done so since 2007. We understand the steps that must be taken to avoid risks inherent in software development, and this guide outlines our six most important strategies to keep your project on time, on budget and headed for success .

Case study: Sainsbury’s Supply Chain Management Fiasco

Prior to the year 2000, a price war between Sainsbury’s and Tesco was in full flow. Both sides had done everything within their power to lower prices including squeezing their suppliers, streamlining logistics and in some cases even making a loss on certain items in the hope that margins elsewhere would make it up.

Having eliminated all commercial options Sainsbury’s turned their attention to their mainframe-based warehouse management system.

The system was, in fact, more than one system, it was nearly 400 unique yet interconnected supply chain software applications.

Peter Davis, Sainsbury’s new CEO authorised the outsourcing of all IT to Accenture, aiming to create an “ agile infrastructure built on an open, adaptive and scalable architecture with hardware and software systems that would generate very high performance, strong data security and a low total cost of ownership. ”

By May 2004 Peter Davis confirmed that “ the £1.8 billion overhaul was well underway, and would be successfully completed in 2005. ”

Mr Davis was in fact so confident about the success of their new supply chain management system that he went on to confirm that:

“ The relationship with Accenture has worked so well that Sainsbury’s has chosen to extend its IT outsourcing contract for another three years, until 2010 — a move that should allow the retailer to net additional cost reductions of more than £230 million by 2007. ”

In July 2004 Peter Davis resigned, the official reason cited was poor financial performance.

By October 2004 the new supply chain system was struggling. It was unable to track stock correctly and the shops that relied on it were starting to run out of stock.

In a bid to overcome these issues Sainsbury’s hired an additional 3,000 shelf stackers. The cost for these temporary workers ran into the millions.

Additionally, the £260m IT spend was written off and Sainsbury’s had to renegotiate the contract extension previously agreed with Accenture.

Accenture was very quick to blame Sainsbury’s for the failure – specifically, they believed that the four fully automated depots outside of their control (and not covered by the agreement) were the cause of the problems.

The new CEO Justin King blamed Accenture for the failings of the new system.

A year later in October 2005 Sainsbury’s cancelled all IT outsourcing, bringing everything back in house.

A thorough review of the failures cited the following causes:

• The project was simply too large – the “big bang” approach and waterfall project methodology limited and in most cases punished change
• Due to the prolonged nature of the project, staff turnover caused disruption and a loss of key legacy system understanding
• Lack of sponsor buy-in
• Weak outsourcing governance
• Poor project planning and “political in-fighting”

Accenture and Sainsbury’s, two mega corporations, failed to get some of the most basic software project strategies right, and their project was doomed to failure from the outset as a consequence.

Strategies to Avoid Software project Failures

Strategy 1 – define a software product vision, what is software product vision.

A good software product vision describes the core essence of a software product and where that product is headed.

It explains the higher purpose of why that product exists in the first place. It sets the direction for where the product is going and what it will deliver in the future.

As Joel Spolsky outlines in his blog post about product vision, he defines Product Vision in this simple summary:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

When we built our  HR Software  for small businesses here at Atlas, this is the product vision that we created for it:

For a small company that needs to ensure they meet employment legislation demands and overall compliance, Staff Squared is HR software that manages onboarding, employee data and files, and time off in a web-based platform. This keeps businesses compliant with employment legislation and in particular GDPR. Unlike other services our focus is on compliance legislation specifically targeted at small companies.

WHY CREATE A PRODUCT VISION

The product vision is the backbone of your software project and is the basis upon which all of your product decisions are made. Not only does the vision inform your marketing activity, if applicable, but it’s also essential when you’re trying to answer questions including:

• Should we incorporate this feature request from our clients? (Hint: It’s a flat out no if the feature request doesn’t fit your product vision)
• How should we prioritise bugs and change requests (Hint: the ones that meet your product vision should carry more weight than those that do not)
• How do we measure the success of this project? (Hint: Delivering on the product vision is a good start!)

An effective product vision guides the team and aligns all stakeholders, so investing time on vision creation is a very worthwhile investment.

Too many new-product projects move from the idea stage right into development with little or no up-front homework. The results of this ‘ready, fire, aim’ approach are usually disastrous.

Solid pre-development processes drive up new software product success rates significantly and are strongly related to financial performance.

STRATEGY 2 – Define Roles & Responsibilities From The Outset

Executive involvement is a primary variable in predicting the success of a software project.

Having a leadership team aligned across an organisation articulating the purpose, value, and rationale for a software project goes a long way towards getting stakeholders and end-users pulling the proverbial rope in the same direction. (Psst – defining a product vision is essential if you want people to buy into the project).

You need to ensure that you define the key stakeholders within your business that will be involved in the delivery of the solution.

The most important software development project roles and responsibilities are:

PRODUCT SPONSORS

The sponsor is the person or group that provides the financial resources for the project. The project sponsor works with the project management team, aiding with wider project matters such as scope clarification, progress, monitoring, and influencing others in order to benefit the project.

The sponsor leads the project through the software supplier selection process until it is formally authorised. For issues that are beyond the control of the product owner, the sponsor serves as an escalation path.

The sponsor may also be involved in other important issues such as authorising changes in scope, phase-end reviews, and go/no-go decisions when stakes are particularly high.

Typically sponsors of projects tend to be senior management or director level.

SUBJECT MATTER EXPERTS

The subject matter experts are the people from which requirements are captured.

These are the accountants, finance controllers, salespeople, production managers and so on who roll up their sleeves each day. They know their roles inside out and back to front and are rarely technical.

However, their lack of technical knowledge is their strength, as they are not bogged down in technicalities and instead are purely focused on business outcomes.

It’s imperative that discussions are held with subject matter experts at the same time as the product vision is being set down. Feedback from this group of people can save a lot of back and forth down the line.

However, given that subject matter experts tend not to be technical the right amount and type of engagement are necessary so as not to overwhelm them.

One of the ways to get them involved is to wireframe and prototype, which we discuss further on.

PRODUCT OWNER

The product owner is the project lead for the customer. They act as the main point of contact for all decisions concerning the project and as such, need to be empowered to perform their responsibilities without the need to seek too much prior authorisation from the Product Sponsors.

Appointing the right person to this role, with the appropriate delegated authority to progress the project, is fundamental to the success of the project, especially if an agile approach is undertaken.

In particular, the product owner is responsible for:

• Ensuring that the product vision is adhered to
• Making the final decision on all scope related decisions
• refining new requirements
• removing requirements that fall out of scope
• adding new requirements identified as being required to achieve the product vision
• reviewing and setting the priorities assigned to the product backlog and heading up all project planning meetings
• Resolving any disputes either with the software development team or internally

Failure to have a product owner in place usually means that projects execute in fits and starts whilst the software developers are on hold waiting for crucial feedback.

A slowdown in the momentum of a software project can have long-term consequences. Don’t ever underestimate the importance of the product owner role in the success of a software project.

USER ACCEPTANCE TESTERS

You should expect your software solution provider to carry out a wide array of testing to ensure that your new solution meets various quality assurance criteria.

On from that, representatives within your company will need to perform the final checks to ensure that the software works for the business across a number of real-world scenarios.

User Acceptance Testing (UAT) is the final step prior to a new software solution being released to live.

It’s absolutely essential that you have the resources to tackle user acceptance testing in a timely and organised fashion, as it is often UAT that creates the bottleneck between software being completed and released to the business.

It’s often the case that the aforementioned subject matter experts defined how the new solution should work, and given their close proximity to the actual work, they can make excellent user acceptance testers.

It’s an excellent idea to ensure that those employees participating in UAT are brought in from the outset, and understand, or perhaps better still contribute to, the design of the new solution.

This emotional buy-in and understanding of the software solution’s objectives reduce the friction that might otherwise exist in attempting to move users from the existing systems they know and love.

Whilst it’s important that your software solution provider has the necessary resources in place to operate your project, it is equally as important that you as the customer understand the roles and responsibilities required within your team to bring your project to successful completion.

STRATEGY 3 – Prioritise & Budget But Keep Your Score Flexible

One would imagine that every software development project needs a detailed, step-by-step plan.

The kind of plan that would outline every requirement, detail every risk and mitigation steps, document the key people involved and so on.

Such a plan would be everything that a software project would need to be successful – right?

The old adage of “ You don’t know what you don’t know ” is key here. No matter how much time is spent developing a detailed plan, specification and wireframes or prototypes there’s no way for a team to know what they don’t know.

A much better approach is to define a product vision and then define a broad-strokes plan that allows a project to begin to inch forward.

You spend time detailing a small but useful subset of features of the overall project, get it built, review it, discuss it, compare against your original product vision/plan and rinse and repeat. This, in essence, is an agile approach to software development.

An agile approach ensures that you’re not subject to a “big bang” style launch, which inevitably fails. Instead, you grow your software solution gradually, slowly and increase complexity as you move forward.

The ability to adapt and incorporate changes to your business as you move forward can mean the difference between success and failure, and moreover creates the best possible product.

“ But if we don’t define all of the requirements upfront, how can we obtain a quote for cost and timescale? Management won’t sign a blank cheque for development… ” I hear you ask.

Indeed, it’s a fair question but it’s necessary to accept that even with the best intentions no set of requirements will ever be 100% accurate at the outset of the document.

So work to get an estimate that you’re happy with, usually a range of best-worst case, and carefully manage scope to create the best product for the available budget.

To achieve this is to prioritise ruthlessly. Work should be undertaken in a close-knit partnership between the software development team and the customer.

Meetings should take place regularly to discuss the status and re-prioritise. For these meetings to be meaningful, the software partner must be transparent about the budget/time consumed and progress made towards the completion of the project.

This flexible approach keeps everybody actively focused on the delivery of the product vision to the exclusion of all waste. It also allows both parties to mould the scope of the project in response to new information.

The finished solution is a better product that meets your product vision. Given the wealth of data provided to the customer about the progress made versus budget spent, the customer always makes scope changes armed with the information they require.

We respect that it’s often the case that a business will want a cost and timescale for the building of a new software solution.

However, one should be very mindful of the change that will likely come about in your requirements as you progress, and build in mechanisms to allow changes to happen.

This is true partnership working, where information is shared and the product quality and scope carefully sculpted in collaboration.

STRATEGY 4 – Use Wireframes & Prototypes To Your Advantage

In many ways, one of the hardest parts about creating software is not the actual building of the software, but instead the communication of the requirements in the first place.

Let me give you an example…

Imagine you met somebody who had never seen a car before, and the only mechanism you could use to describe what a car looks like and how it works is the written word.

It would be a pretty gruelling experience, to say the least. Just attempting to describe what the average car looks like could be a dozen pages of text. How many wheels does it have, and where do the wheels go? Hold on, what exactly is a wheel? And so on…

Now imagine instead if you were simply able to draw them a car. Wouldn’t that make the communication of what the car looks like so much easier?

In software development, this is what we would refer to as a wireframe . Simple static drawings of one or more screens within the proposed software solution.

Now take this analogy a step further; imagine you could create a small plastic model of a car with some basic operating parts like turning wheels, opening doors, and so on.

This is what we would call a prototype , and a prototype typically conveys more information than a wireframe due to its interactive nature.

There’s a reason the saying “ a picture is worth a thousand words ” is often quoted. In software, wireframe or prototype of a proposed software solution is an essential step for communicating the desired outcome.

Getting a wireframe or prototype in place helps everybody on the team to get on the same page about what success looks like much quicker.

You’ll have multiple stakeholders within your company to involve, and the sooner they all agree on the desired outcome, the sooner your project can begin.

TOOLS FOR CREATING A WIREFRAME

The most basic prototype we’ve ever seen was created using Microsoft Excel – yes you read that correctly, Microsoft Excel.

Our customer had used one tab on the spreadsheet for each page in the software application and had cleverly used the various cells on a page to layout the page. Whilst this was a perfectly acceptable starting point, it was a tad unorthodox, to say the least!

Fortunately, a number of tools exist to allow technical and non-technical users alike to quickly create low-fidelity prototypes very quickly. Our preferred prototyping tool is  Balsamiq , and this is the type of output it’s capable of producing.

The advantage of a tool like Balsamiq is that it’s very quick and easy to output a proposed idea. Other tools for creating prototypes include:

Returning to our car analogy, the above tools are capable of creating a picture of a car to varying degrees of detail. In order to create a model of a car, the best approach is to create an HTML prototype.

An HTML prototype is a working prototype of how the finished software solution might work. The prototype is interactive, allowing end users to fire up their web browser, navigate to the prototype and actually engage with it as they would the final software solution.

Often it’s the case that a wireframe is used first for high-level discussions and to obtain broad agreement, with the prototype created next.

The advantages of an HTML prototype include:

• Both the customer and the developers are forced to think about how a solution might work within the browser which applies some real-world constraints.
• This is especially true for software being created for a mobile or tablet device.
• The code used to create the HTML prototype is completely reusable for the actual production of the software solution, so there’s no wasted work.
• It shows everybody exactly what you’re going to receive and provides an excellent opportunity to obtain stakeholder buy-in.

EXAMPLE HTML PROTOTYPE

Check out  this example  of a basic HTML prototype. As you’ll see, the prototype is somewhat interactive and allows all project stakeholders the opportunity to truly understand what the proposed end solution will look and how it will interact.

OBTAINING STAKEHOLDER BUY-IN

Whether you use wireframes, prototypes or a combination of both, the process of visually describing the outcome has a positive impact on the team from the get-go.

The team all have a chance to discuss and understand the proposed outcome, and we often see those team members who wouldn’t have taken the time to speak up at the outset use these discussions to have their say, and often what they have to say is very relevant!

Prototypes are extremely valuable communication tools. If you have the opportunity, creating a prototype together with the team who will build the end product fosters trust, increased project ownership, and a stronger shared vision than delivering an already-built artefact.

This is incredibly important during user acceptance testing, which we’ll cover off in strategy number 6 – take testing seriously.

STRATEGY 5 – Traditional (Waterfall) VS Agile Project Management

Requirements changing or being added to are almost an inevitable fact of software development, so failing to plan for them is to plan to fail.

Congratulations, you’ve just signed an agreement to argue with your development team in the coming weeks or months.

The problem here is not a lack of good intention. The problem is specifically with the opening statement “ I know all of my requirements ”.

You probably don’t, and the approach to your commercials and project management are now set up such that when you realise this is the case it’s too late.

The contract between you and the software developer attempts by its nature to limit, perhaps even prevent, change.

Alternatively, agile project management builds the need to change requirements as you progress your project into the approach explicitly.

Agile recognises that changes in requirements are not software project failures, instead, they’re opportunities to realign the project with the overall product vision as more information about the requirements are unearthed.

Another benefit of agile is that planning, design and documentation beyond the minimum necessary to begin work is a waste. It specifically focuses on delivering working features, which is where the value for the customer comes to life.

Lots have been written on the benefits of agile so rather than labour all of them, we’ll break down the highlights.

AGILE KEEPS FEEDBACK LOOPS SHORT AND TIGHT

People are much better at managing highly detailed work over short periods of time, than long ones.

That effectiveness increases further when a rhythm of repetitiveness is built up, and this is created by using short sprints.

A sprint, is another word for a short, usually two week, a cycle of development work.

Sprints allow large projects to be broken down into very short, defined, repeatable periods of time for which useful metrics can be defined, captured and measured.

At the beginning of each sprint, you agree the work be completed within the sprint. The developers and testers work to produce a completed sprint of work. You then agree on the next sprint, rinse and repeat.

This cycle of development completely mitigates the risk of everybody getting their heads down on a six-month project, only to find that when they look up again they’re completely off the track they hoped to be on.

Traditional waterfall project management is insufficient to manage the inevitable change inherent in software projects.

Agile project management, however, is well equipped to aid product owners and software development teams in managing risk, scope, budgets, and schedules to create successful valuable products.

STRATEGY 6 – Expect & Plan For Changes In Requirements

Testing isn’t the most ‘fun’ part of a software project but arguably it’s the most important.

BUGS THAT MAKE IT OUT INTO THE REAL WORLD ARE COSTLY

Various studies show that it is over five times more expensive to fix bugs or issues that make it out “into the wild” than it is to find and fix those bugs during the testing phase.

Thorough software testing is the primary way to avoid bugs leaking out into the wild, and for this sixth and final strategy we consider two unique yet related types of testing:

• Cross-browser testing – does the solution work on multiple web browsers
• Functional testing – does the software do what it’s supposed to do
• Automated testing – a routine which can perform a certain set of steps to check the outcome is as expected
• Unit testing – lines of code which automatically check other lines of code produce the correct output given certain inputs
• Testing performed by you , the customer, which is commonly referred to as User Acceptance Testing or UAT

SOFTWARE TESTING

It’s important to ensure that your software partner employs qualified and dedicated testers as part of their team.

Here at Atlas all of our testers are ISTQB (International Software Testing Qualifications Board) qualified, which means they all share an understanding of the importance of testing and how to go about it in a manner that will highlight the most issues.

• Do you automate any of your tests (We do!)
• Do they use unit tests?
• Do they adhere to any best practices around testing?
• What is the process used for releasing code from the development team, to a test server and finally to the live server?

If these questions draw blank stares, or you’re not satisfied with the answers, get a second opinion.

USER ACCEPTANCE TESTING (UAT) – THE FINAL PIECE OF THE JIGSAW PUZZLE

User Acceptance Testing (UAT) is the process of verifying that the software solution works for the end-user aka subject matter expert.

This verification has to be carried out by users who understand the product vision and the business needs being addressed.

The questions you’ll be looking to answer here include:

• Can the end-user use the software?
• Is it really what they need and does it meet the overall product vision?
• Do they have any trouble using it?
• Does it behave exactly as anticipated?

GETTING UAT RIGHT

Make sure you plan ahead for UAT so that those who are undertaking that work are available and can provide timely feedback to the development team.

Given that UAT is carried out at the end of the testing cycle, right before the release of the software, it’s one of the most critical parts of the project lifecycle and issues here can cause serious delays if not handled efficiently.

UAT should be pre-planned with a clear acceptance test plan in the requirement analysis and design phase.

Your acceptance test plan should be as ruthlessly prioritised as your software development plan, focussing on real-world tests and scenarios that are the most important first and working backwards from there.

CREATE UAT CHECKLISTS AHEAD OF TIME

Define the objectives of your UAT process well ahead of UAT. In an ideal world when you set down your product vision you will begin to create the checklist of UAT questions that your UAT team will refer to when they come to test.

Detailed testing plans help to make it easier for a team member to design the test and for other team members to carry it out. A user acceptance testing plan also helps you to recreate a test if you have to go over it again.

CREATE A PROCESS FOR RAISING UAT ISSUES BACK TO THE DEVELOPMENT TEAM

Software developers and testers tend to reside in the same building and communicate frequently, which means their ability to raise issues is streamlined.

Members of the UAT team often work remotely, and so it’s absolutely essential that as part of UAT they understand the workflow for raising issues and communicating with the software partner.

A lack of understanding of how this process works can lead to delays in the raising of issues.

An experienced software partner will understand this and provide mechanisms for your UAT team to use to raise their feedback consistently and methodically.

CARRY OUT UAT IN A REAL WORLD ENVIRONMENT

In an ideal world, you need the environment that the team worked on to perform UAT to be as identical to the live environment as possible. This is especially important when testing includes checking the software solution is performant and capable of processing real-world data.

IMPROPER UAT PLANNING CAN LEAD TO UAT TAKING PLACE IN A DISORGANISED MANNER, WHICH CAN THROW THE MOST ORGANISED PROJECT INTO CHAOS

UAT Failure Case Study – Heathrow Terminal 5 Opening

Just before the opening of Heathrow’s Terminal 5 in the UK , staff tested the brand new baggage handling system built to carry the vast amounts of luggage checked in each day.

Engineers tested the system thoroughly before opening the Terminal to the public with over 12,000 test pieces of luggage. It worked flawlessly on all test runs only to find on the Terminal’s opening day the system simply could not cope.

‘Real-world’ scenarios such as removing a bag from the system manually when a passenger had left an important item in their luggage, had caused the entire system to become confused and shut down. Over the following 10 days, some 42,000 bags failed to travel with their owners, and over 500 flights were cancelled.

Clearly not enough real-world scenarios were included when they were carrying out the UAT for the conveyor belt system in Heathrow’s new terminal. The cost of not undertaking sufficient UAT ran into millions of pounds.

As we pointed out in the second strategy above, the success of the project is dependent on you and your software partner both have the correct resources in place.

User Acceptance Testing is a key component of a successful software project, and needs to be planned ahead of time and executed efficiently so as not to bring the project to an untimely halt.

Simon Swords

Managing Director

Want to stay up to date with the latest software news, advice and technical tips?

Atlas Computer Systems Limited is a company registered in England and Wales. Registration number 05078708. Registered office: Unit 7, Britannia Business Park, Comet Way, Southend-on-Sea, Essex, SS2 6GE. Data Protection Act 1998 Registration Number Z33126116. VAT Number: 894 3482 81

Request a callback

Careers  |  Privacy Policy

Delivering clever software solutions since 2007 Copyright © 2024 Atlas Computer Systems Limited

Delivering clever software solutions since 2007 Copyright © 2024 Atlas Computer Systems Ltd

Software Project Management in a Changing World pp 27–49 Cite as

Rethinking Success in Software Projects: Looking Beyond the Failure Factors

• Darren Dalcher 3  
• First Online: 01 January 2014

4364 Accesses

10 Citations

The notions of success and failure in software projects are confusing. Failure is often considered in the context of the iron triangle as the inability to meet time, cost, and performance constraints. While there is a consensus around the prevalence of project failure, new projects seem destined to repeat past mistakes. This chapter tries to advance the discussion by offering a new perspective for reasoning about the meaning of success and the different types of software project failures.

In order to court project success, practitioners need to rise beyond a fixation with the internal parameters of efficiency, thus bringing forth the effectiveness required to secure project success. The chapter begins by discussing the limited insights from existing project failure surveys, before offering a four-level model addressing the essence of successful delivery and operation in software projects. Following consideration of outcomes and time, the chapter offers a series of vignettes and mini case studies that highlight the rich interplay between the four levels of success, before addressing the types of measures underpinning the four levels and the need to develop a multi-dimensional perspective to obtain a more accurate picture regarding the success of a project.

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

Buying options

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Anon (1979) Contracting for computer software development—serious problems require management attention to avoid wasting additional millions, general accounting office report to the congress by the comptroller general of the United States. FGMSD 80–84

Google Scholar  

Baccarini D (1999) The logical framework method for defining project success’. Proj Manag J 30(4):25–32

Barnes M (2013) Private communication, September 2013 BBC (2003) BBC Radio 4 news, 15.5.2003. http://www.silicon.com/news/500022/1/4169.html

BBC (2012) London 2012 legacy plan published, 18 September 2012. http://bbc.co.uk . Accessed 12 Nov 2013

Bloch M, Blumberg S, Laartz J (2013) Delivering large-scale IT projects on time, on budget and on value. McKinsey Finance 45:28–35

Brooks F (1975) The mythical man-month: essays on software engineering. Addison-Wesley, Reading, MA

Buxton JN, Naur P, Randell B (1969) Software engineering techniques. In: Proceedings, NATO conference, scientific affair division, Brussels

Charette RN (2005) Why software fails. IEEE Spectr 42(9):42–49

Article   Google Scholar  

Cooke-Davies T (2002) The “real” success factors on project. Int J Proj Manag 20(3):185–190

Dalcher D (1994) Falling down is part of growing up; the study of failure and the software engineering community. In: Proceedings of 7th SEI education in software engineering conference. Springer, New York, pp 489–496

Dalcher D (2009) Making sense of IS failures. Encyc Inf Sci Technol 5:2476–2483

Dalcher D (2010) The LAS story: learning from project failure. In: Turner RJ, Huemann M, Anbari FT, Bredillet CN (eds) Perspectives on projects. Routledge, New York

Dalcher D (2012) The nature of project management: a reflection on the anatomy of major projects by Morris and Hough. Int J Manag Proj Bus 5(4):643–660

Dalcher D, Brodie L (2007) Successful IT projects. Thomson, London

Dalcher D, Genus A (2003) Avoiding IS/IT implementation failure. Tech Anal Str Manag 15(4):403–407

de Wit A (1988) Measurement of project management success. Int J Proj Manag 6(3):164–170

Drevin L, Dalcher D (2011a) Antenarrative and narrative: the experience of actors involved in the development and use of information systems. In: Boje DM (ed) Storytelling and the future of organisations: an antenarrative handbook. Taylor and Francis, New York, pp 148–162

Drevin L, Dalcher D (2011b) Narrative methods: success and failure stories as told by information systems users. In: Standing conference for management and organization enquiry, SC’MOI conference, Philadelphia, PA

Drevin L, Dalcher D (2011c) Using antenarrative approaches to investigate the perceptions of Information Systems’ actors regarding failure and success. In: Pokorny J, Repa V, Richta K, Wojtkowski W, Linger H, Barry C, Lang M (eds) Information systems development business systems and services: modeling and development. Springer, New York, pp 207–218

Egan J (1998) Rethinking construction, the report of the construction task force. Department of Environment, Transport and the Region, London

Egan J (2008) Sir John Egan’s speech to the house of commons, 21st April, 2008

Eveleens JL, Verhoef C (2010) The rise and fall of the chaos report figures. IEEE Softw 27(1):30–36

Fairley RE, Wilshire MJ (2003) Why the Vasa Sank: 10 problems and some antidotes for software projects. IEEE Softw 20(2):18–25

Flowers S (1996) Software failure, management failure. Wiley, Chichester

Flyvbjerg B, Budzier A (2011) Why your IT project may be riskier than you think. Harv Bus Rev 89(9):83–85

Geneca (2011) Doomed from the start? Why a majority of business and IT teams anticipate their software development project will fail. Geneca, Oakbrook Terrace, IL

Glass R (2005) IT Failure Rates—70% or 10-15%. IEEE Softw 22(3):110–112

Glass R (2006) The Standish report: does it really describe a software crisis? CACM 49(8):15–16

IBM (2008) Making change work. IBM Global Services, Somers, NY

Jones C (1994) Assessment and control of software risks. Prentice-Hall, Englewood Cliffs, NJ

Jones C (2000) Software assessments, benchmarks and best practices. Addison-Wesley, Upper Saddle River, NJ

Jones C (2007) Estimating software costs: bringing realism to estimating. McGraw Hill, New York

Jones C (2008) Applied software measurement: global analysis of productivity and quality. McGraw Hill, New York

Jones C (2010) Software engineering best practices: lessons from successful projects in the top companies. McGraw Hill, New York

Jørgensen M, Moløkken K (2006) How large are software cost overruns? A review of the 1994 Chaos report. Inform Softw Technol 48(8):297–301

Kerzner H (2009) Project management: a systems approach to planning, scheduling and controlling, 10th edn. Wiley, Hoboken, NJ

Kloppenborg T, Mantel SJ (1990) Tradeoffs on projects: they may not be what you think. Proj Manag J 21(1):13–20

KPMG (2010) KPMG New Zeland project management survey 2010. Http://kpmg.co.nz

Linberg K (1999) Software developer perceptions about software project failure: a case study. J Syst Softw 49:177–192

Luqi, Goguen JA (1997) Formal methods: promises and problems. IEEE Softw 14(1):73–85

Lyytinen K, Hirschheim R (1987) Information systems failures—a survey and classification of the empirical literature. Oxf Surv Inf Technol 4:57–309

McManus J, Wood-Harper T (2008) A study in project failure. http://www.bcs.org/server.php?show = ConWebDoc.19584

Morris PWG, Hough G (1987) The anatomy of major projects: a study of the reality of project management. Wiley, Chichester

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

Naur P, Randell B (1968) Software engineering. In: Proceedings. NATO Scientific Affairs Division, Brussels

Pinto JK, Slevin DP (1988) Critical success factors in effective project implementation. In: Cleland DI, King WR (eds) Project management handbook, 2nd edn. Van Nostrand Reinhold, New York

Sauer C, Cuthbertson C (2003) The state of IT project management in the UK 2002–2003. Templeton College, Oxford

Sauer C, Gemino A, Reich BH (2007) The impact of size and volatility on IT project performance. CACM 50(11):79–84

Shenhar AJ, Dvir D (2007) Reinventing project management: the diamond approach to successful growth and innovation. Harvard Business School Press, Boston, MA

Standish Group (2000) Chaos 2000. Standish, Dennis, MA

Standish Group (2004) Chaos 2004. Standish, Dennis, MA

Standish Group (2011) Chaos 2011. Standish, Dennis, MA

Taylor A (2000) IT projects sink or swim. The Comp Bulletin, January, Brit Comp Society

Turner JR (2009) The handbook of project based management, 3rd edn. McGraw-Hill, New York

Wateridge JH (1995) IT projects: a basis for success. Int J Proj Manag 13(3):169–172

Download references

Author information

Authors and affiliations.

NCPM, University of Hertfordshire, MacLaurin Building, 4 Bishops Square, Hatfield, Hertfordshire, AL10, 9AB, UK

Darren Dalcher

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Darren Dalcher .

Editor information

Editors and affiliations.

University of Calgary, Calgary, Alberta, Canada

Günther Ruhe

Blekinge Institute of Technology, Karlskrona, Sweden

Claes Wohlin

Rights and permissions

Reprints and permissions

Copyright information

© 2014 Springer-Verlag Berlin Heidelberg

About this chapter

Cite this chapter.

Dalcher, D. (2014). Rethinking Success in Software Projects: Looking Beyond the Failure Factors. In: Ruhe, G., Wohlin, C. (eds) Software Project Management in a Changing World. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-55035-5_2

Download citation

DOI : https://doi.org/10.1007/978-3-642-55035-5_2

Published : 24 May 2014

Publisher Name : Springer, Berlin, Heidelberg

Print ISBN : 978-3-642-55034-8

Online ISBN : 978-3-642-55035-5

eBook Packages : Computer Science Computer Science (R0)

Share this chapter

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

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

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

• Communications
• Energy and Utilities (E&U)
• Financial Services
• Healthcare & Life Sciences
• Manufacturing
• Media & Entertainment
• Retail and Ecommerce
• Travel & Hospitality
• Artificial Intelligence Testing
• Big Data & Analytics Testing
• Blockchain Testing
• Cloud Migration Assurance
• Security Assurance
• Internet of Things (IoT) Testing
• Mobile Testing
• Robotic Process Automation (RPA)
• 5G Assurance Services
• DevOps Testing
• Compatibility Testing
• Functional Testing
• Performance Testing
• Regression Testing
• Security Testing
• Test Automation
• Crowdsourced Testing
• Quality Engineering
• ERP Testing
• Salesforce Testing
• Medical Devices Testing
• Agile Testing
• Test Data Management
• Service Virtualization
• DevOps Transformation
• Testing Center of Excellence
• Test Advisory & Transformation Services
• Build Operate Transfer (BOT) Model
• Programmatic Innovation
• Agile Transformation
• Software Product Engineering
• Application Modernization
• Blockchain Engineering
• Enterprise Application Development
• User Experience Engineering
• Site Reliability Engineering
• Data Insights
• AI & ML
• Verita – Quality Engineering Dashboard
• Velocita – Test Automation Accelerators
• Praxia – Process Accelerator
• MAP – Model Assurance Platform
• CLAP – Cloud Migration Assurance Platform
• iNSta – Intelligent Scriptless Test Automation
• Cesta – Integrated Migration Solutions
• Incight – App Experience Analyzer Tool
• Zastra.ai – Active Learning Driven Annotation Platform
• Performance Engineering Lab
• Robotics Lab
• IOT and Smart Meters Lab
• Case Studies
• Digital ARMER
• Digital Dialogues – Podcast
• Digital Dialogues – Webinars
• herDIGITALstory TM
• Newsletter – Cignizine
• Tech Briefs
• Testimonials
• White Papers
• Infrastructure
• Cigniti in the News
• Press Releases
• Board of Directors
• Board Code of Conduct
• Annual Reports
• Corporate Presentation
• Quarterly Results
• Shareholding Pattern
• Announcements
• Analyst Recognitions
• Cigniti Careers
• Campus Connect
• Alumni Relations
• Life @ Cigniti
• Diversity, Equity, and Inclusion
• Corporate Social Responsibility
• Sustainability

37 Epic Software Failures that Mandate the Need for Adequate Software Testing

Disaster is an understatement for any brand/organization/institution that has incurred losses due to an overtly minuscule but catastrophic software glitch. While technology and innovative applications have empowered brands, enterprises have recorded numerous disabling instances.

Software disasters have the potential to cause widespread disruptions and highlight the importance of rigorous testing and quality control measures in preventing catastrophic software failures.

Any application’s unexpected crashes and data inconsistencies were a direct result of the failure in software testing , revealing significant gaps in the quality assurance process. In this run on top software failures of 2016 -2015-2014, we take stock of the debacles/glitches that have changed the face of software development and endorsed the role of testing in the overall SDLC process.

Top Software Failures: Glitches and Debacles That Transformed Software Development

The failure in software testing was witnessed by brands and enterprises across diverse industries, and here is a list of software glitches/technical issues. Please note that the numbers 1-37 do not signify the high or low impact of the software glitch on the brand/enterprise.

Yahoo reports breach

Amongst the most recent data breaches , on September 22, 2016, Yahoo confirmed a data breach that exposed about 500 million credentials that date back to four years. It is considered among the largest credential leaks of 2016. The company believes that this was a state-sponsored breach, where an individual on behalf of a government executed the entire hack. It further urged users to change their passwords and security questions. As a relief for the users, Yahoo stated that sensitive financial data like bank accounts and passwords was not stolen as part of the breach.

Source: Money.cnn.com

Nest thermostat freeze

Software update for the Nest ‘smart’ thermostat (owned by Google) went wrong and literally left users in the cold. When the software update went wrong, it forced the device’s batteries to drain out, leading to a temperature drop. Consequently, the customers could not heat their homes or use any amenities.

Nest claimed that the fault was due to a December 4.0 firmware update, with related issues such as old air filters or incompatible boilers. Later, it released a 4.0.1 software update that solved the issue for 99.5% of affected customers.

Source: Cio-asia.com

HSBC’s major IT outage

Prison Break

A glitch that occurred in December 2015 led to over 3,200 US prisoners being released before their declared date. The software was designed to monitor prisoners’ behavior and was introduced in 2002. The problem occurred for about 13 years; on average, prisoners were released almost 49 days in advance.

HSBC payments glitch

In August 2015, HSBC failed to process about 275,000 individual payments, leaving many without pay before a long Bank Holiday weekend. This occurred due to a major failure with the bank’s electronic payment system for its business banking users, affecting individual payments. Bacs, a payment system used for payment processes across the UK, later picked up on this issue, labeling it as an ‘isolated issue’.

Bloomberg cancels debt issue

In April 2016, Bloomberg’s London office faced a software glitch, where its trading terminals went down for two hours. This came up at an unfortunate time when the UK’s Debt Management Office (DMO) was about to auction a series of short-term Treasury bills. Later, in a statement, Bloomberg declared that the services were restored, and the glitch resulted from hardware and software failures in the network, resulting in excessive network traffic.

RBS payments failure

About 6 lakh payments failed to get through the accounts of RBS overnight in June 2015, which included wages and benefits. Bank’s chief admin officer stated it was a technology fault, and there was no further detail on the real cause. In 2012, about 6.5 million RBS customers had to face an outage caused due to a batch scheduling software glitch, where the bank was fined £56 million.

Airbus software bug alert

In May 2015, Airbus issued an alert for urgently checking its A400M aircraft when a report detected a software bug that had caused a fatal crash earlier in Spain. Before this alert, a test flight in Seville caused the death of four Air Force crew members, and two were left injured.

Source: Theguardian.com

UK government’s new online farming payments system gets delayed

In March 2015, the UK government delayed the launch of a £154 million rural payments system.  The system is an online service for farmers to apply for Common Agricultural Policy payments from the EU. This online service, which was supposed to be up and running by May 2015, was delayed due to integration issues between the portal and the rules engine software. It was then not expected to be up even by 2016.

Source: Computerworlduk.com

Co-op Food’s double charges

In July 2015, Co-operative Food apologized to its customers and promised a refund within 24 hours. The reason was a ‘one-off technical glitch’ while processing the software that resulted in customers being charged twice.

Mispricing is a common headache faced by retailers due to system glitches, resulting in retail outlets offering customers excessively lucrative offers. John Lewis is a recent example, where the online retailer witnessed a price glitch on its website that erroneously advertised hardware at software rates.

Source: Money.aol.co.uk

Tesco iPad pricing disaster

In March 2012, Apple iPads worth £650 were priced at £49.99. After the glitch was identified, Tesco canceled the sale and did not respond to these orders, resulting in customer dissatisfaction.

Source: Mycustomer.com

Marks & Spencer 3D TV glitch

In January 2012, 50-inch 3D TVs worth £1,099 went up on sale for a mere £199 on the Marks and Spencer website. Eventually, the company decided to sell the Plasma TV sets at a lower price after it faced a customer petition. The online petition called ‘Marks & Spencer supply our TVs that we paid for’ compelled M&S to honor the orders.

Source: Thisismoney.co.uk

Reebok’s free trainers

In November 2013, Sports retailer Reebok trainers worth £100 were picked up for free from the online site, where the customers were only being charged for delivery. While the company did not honor the orders and apologized to the customer, they refunded the delivery charges and additionally gave 20% off on their next order. The pricing glitch went viral on Facebook and other sport and price deal forums, where shoppers rushed to grab £99.95 CrossFit Nano Speed footwear for just £8.50 postage.

Tennessee County kills System Update worth $1Million

After investing two years of labor and investment worth $1 Million, Rutherford Country of Tennessee, US, called off a court software system update. The core reason was that the software glitches were identified right when the deal took place, where problems related to the issuance of checks, errors on circuit court dockets, and creation of hidden charges came up in the weeks after it went Live.

Source: 99tests.com

Software Security Flaws Revealed in OLA’s Mobile App

Ola, India’s largest taxi aggregator, faced major security flaws within their system. The software bugs detected helped basic programmers enjoy unlimited free rides – at the expense of Ola and at the expense of users. The issue went public when customers brought up the weaknesses in the system. Ola tried to fix bugs when the complaints soared up and it was alarming for the brand’s reputation in the marketplace.

Source: Economictimes.indiatimes.com

Leeds Pathology IT crash

In September 2016, Leeds Teaching Hospitals NHS Trust, one of Europe’s largest teaching trusts, witnessed a pathology IT crash that delayed operations for almost 132 patients. Leeds Teaching holds a budget of £1 billion and employs over 16,000 staff. It serves 780,000 people in the city and provides expert care for 5.4 million patients . The outage further affected Bradford Teaching Hospitals NHS Foundation Trust, GP services in Leeds, and a minor number of GP services in Bradford.

Now that’s the impact!

Source: Digitalhealth.net

Cisco’s Email Security Appliances glitch

In September 2016, Cisco Systems released a critical security bulletin to announce an IT exposure that could allow remote unauthenticated users to get access to its email security appliances. The vulnerability is associated with Cisco’s IronPort AsyncOS operating system . The company further indicated that there is a way out to stop this remote access to the email appliances.

Source: Threatpost.com

Cisco Nexus Switches warning

Cisco again! In October 2016, Cisco Systems released several critical software patches for its Nexus 7000-series switches and its NX-OS software. Cisco’s Security Advisory declared that both the Nexus 7000 and 7700 series switches were vulnerable to this glitch. The vulnerabilities declared allowed remote access to systems that could enable a hacker to execute code on targeted devices. Cisco further declared that this bug (CVE-2016-1453) results from “incomplete input validation performed on the size of overlay transport virtualization packet header parameters”.

Cyber Attack on Nuclear Power Plant

In October 2016, the head of an international nuclear energy consortium declared that disruption at a nuclear power plant during the last several years was caused due to a ‘Cyber Attack’. Yukiya Amano, head of the International Atomic Energy Agency (IAEA) didn’t drill the matter much in detail but did alter the potential attacks in the future.

This shows that disruption in nuclear infrastructure due to a Cyber Attack is not a ‘Hollywood stint’!

Volkswagen’s ‘Dieselgate’ scandal

In September 2015, the US government, in a dramatic move, ordered Volkswagen to recall about 500,000 cars after learning that the company had deployed advanced software to cheat emission tests and allowed its cars to produce 40 times more emissions than the decided limit. The Environment Protection Agency (EPA) accused VW of installing illegal ‘defeat device’ software that substantially reduces Nitrogen oxide (NOx) emissions only while undergoing emission tests. The company further admitted it and announced a recall as well.

Interlogix Recalls Personal Panic Devices

In October 2016, Interlogix, a wireless personal panic devices manufacturer, recalled about 67000 devices due to its inability to operate during emergency situations. The probable cause for this glitch in operations was that the device could not communicate with the security system during an emergency. The way out was the manufacturer replacing the devices. Furthermore, the consumers could contact their professional security system installer and call for free monitoring and, if required, free replacement.

Source: News.sys-con.com

IRS E-File goes Offline

In February 2016, the Federal Agency suffered from a hardware failure. IRS announced that the hardware failure has affected numerous tax processing systems that went out of service, including the modernized e-file system and another related system. The majority of the folks trying to file taxes online could not complete the process. Later IRS made amendments and worked to restore regular operations to get back to the routine.

Source: Newyork.cbslocal.com

911 call outage

In April 2015, Emergency services got stalled for six hours in seven US states. This affected 81 call centers, literally speaking, about 6,000 people made 911 calls and could not connect across the seven states. The nationwide outage was the third major outage in three years across telecom operators of the 911 call system. This raised worries amongst federal regulators about the vulnerability of the country’s emergency response system.

Source: Wsj.com

New York Stock Exchange halts trading

In July 2015, The New York Stock Exchange stopped trading due to an undisclosed ‘internal technical issue’, where all open orders were canceled, and the traders were alerted and informed that they would receive information later. While responding to the shutdown, NYSE announced that there was no cyber breach within the system, and it resumed operations after 4 hours.

UK government’s online calculator glitch

In December 2015, the UK government found out that its online calculator for estimating the spouse’s financial worth got hit with a Form E fault, where calculations went wrong for thousands of couples who had divorced over the past 20 months. Though the issue has been prevalent since April 2014, it was noticed only in December 2015. The damage caused is yet to be estimated.

Let’s take a dip into some of the interesting software debacles of 2014

27. nissan’s recall.

For over 2 years, Nissan recalled over a million cars thanks to a software glitch in the airbag sensory detectors. Practically, the affected cars could not assess whether an adult was seated in the car’s passenger seat and consequently would not inflate the airbags in case of a crisis.

28. Amazon 1p price glitch

One of the most known glitches in history is the Amazon 1p price glitch, where third-party sellers listed on Amazon saw their products being priced at 1p each. While the products were delivered, numerous small-time retailers had to appeal to the customers to return the items.

29.Screwfix.com glitch

In January 2014, every item in the Screwfix catalog was priced at £34.99, which included items costing almost £1,599.99. Smart customers quickly collected goods worth thousands after the news spread across Twitter. Eventually, the website had to close.

Source: Telegraph.co.uk

30. Flipkart apologizes for Big Billion Day sale fiasco

In October 2014, Flipkart, an India based e-commerce giant, sent a note to its customers apologizing for the glitches that took place on the Big Billion Day Sale. The site encountered a heavy rush, which it couldn’t manage, which resulted in cancellation of orders, delayed delivery, and much more that was beyond them to manage. While the sale helped the e-commerce giant garner a billion hits in a day, it was certainly a PR nightmare for the brand.

Source: Livemint.com

31. CA Technologies paid RBS ‘millions’ for role in IT fiasco

In October 2014, CA Technologies paid ‘millions of pounds’ to the Royal Bank of Scotland. This payment was a part of the settlement agreement with Royal Bank of Scotland’s (RBS) IT outage in 2012. In 2012, a failed upgrade to CA7 batch processing software by RBS IT staff resulted in a system breakdown, affecting millions of customers. The customers were unable to access their accounts or execute any payments.

Source: Computerweekly.com

32. Chaos at UK airports

On December 12, 2014, the UK’s busiest airports got stranded due to a system glitch at Swanwick’s main national air traffic control center. Planes were grounded, and passengers got delayed. The impact was enormous as the runways were closed at Heathrow, which is one of Europe’s busiest airports. The transport secretary called this ‘unacceptable’.

33. Toyota Prius recalled over software glitch

In February 2014, Toyota Motor recalled 1.9 million newest-generation Prius vehicles worldwide due to a programming error that caused the car’s gas-electric hybrid systems to shut down. The Automaker mentioned the problems with the software settings on the latest Prius generation that initially went for sale in 2009 and could damage transistors in the hybrid systems. The identified problem could turn on the warning lights and trigger the vehicle to shut down the power in a fail-safe mode.

Source: Nytimes.com

34.Heartbleed the Web

In April 2014, the IT gang woke up to its worst nightmare: an emergency security advisory from the OpenSSL project warned about an open bug, ‘Heartbleed’. The bug could pull out a chunk of working memory from a server and run their current software. While there was an emergency patch for it, tens of millions of servers got exposed when the patch was installed. This left everyone and anyone running a server in crisis mode. This notorious bug exposed biggies like Yahoo, Imgur, and numerous others to Heartbleed.

Source: Theverge.com

35. Apple pulls iOS 8 update

In September 2014, Apple faced an embarrassment after it had to pull out its new iOS software update only a few hours after its release. This was post complaints from iPhone users about calls getting blocked after the upgrade. The tech giant pulled out the update after a storm of complaints on Twitter and Apple user chatrooms. The update further disabled the feature where people could unlock their phones with fingerprints.

Source: Mirror.co.uk

36. iCloud hack

In August 2014, almost 500 private pictures of celebrities were posted on social channels and sites like Imgur and Reddit. The images were apparently sourced through a breach of Apple’s Cloud services suite iCloud. However, later, it was found that it could be due to a security issue in the iCloud API that enabled the access and innumerable attempts to try passwords. However, there have been recent reports of similar hacks into iCloud.

Source: Dailymail.co.uk

37. Air India diverts Boeing 787 flight

During an emergency stunt in Feb 2014, Air India diverted a Boeing 787 plane to Kuala Lumpur when the pilots noticed a software glitch while on a flight from Melbourne to New Delhi. The Engineers were flown down from Hong Kong to fix the glitch and worked with Air India to resolve the same. It has been reported that the 787 has been suffering such glitches, and Boeing was aware of it.

Source: Reuters.com

Let’s make Software Error Free with Cigniti

Cigniti Technologies has collaborated with the world’s leading and innovative organizations/brands across diverse industries. Enterprises globally have trusted Cigniti’s independent software testing services and expertise for over a decade and have achieved speed to market, higher returns on investments (ROI), and enhanced quality deliveries in their overall QA initiatives. Connect with our experts to bring speed and velocity to your QA practices with the best ideas in the testing space.

Cigniti is the world’s leading AI & IP-led Digital Assurance and Digital Engineering services company with offices in India, the USA, Canada, the UK, the UAE, Australia, South Africa, the Czech Republic, and Singapore. We help companies accelerate their digital transformation journey across various stages of digital adoption and help them achieve market leadership.

View all posts

Comment (1)

Great article to convince your clients!!

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

2016 Roundup: What Did Testers Like the Most

By Cigniti Technologies

Listen on the go! A Year of Shifting Left with Cigniti Technologies  “Be specific enough to be believable and universal enough... read more

What is the need of software testing for business resilience

Listen on the go! Software testing used to be a phase in the software development lifecycle – a phase which... read more

Will AI make Software Testing irrelevant?

Listen on the go! Our smart Virtual Assistants Alexa, Siri, and Google Home have already proven to all of us... read more

Software Project Failure Process Definition

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

• Custom Software Developers
• Software Development Companies in US
• Software Development Companies in India
• Software Development Companies in UK
• Software Development Companies In Canada
• Mobile App Development Companies
• Mobile App Development Companies in US
• Mobile App Development Companies in India
• Mobile App Development Companies in UK
• Mobile App Development Companies in Canada
• Web Development Agencies
• Web Development Agencies in the US
• Web Development Agencies in India
• AI Development Companies
• AI Development Companies in India
• AI Development Companies in Canada
• AI Companies in Australia
• AI Development Companies in the USA
• Digital Marketing Companies
• Digital Marketing Companies in US
• Digital Marketing Companies in UK
• Digital Marketing Companies in UAE
• Healthcare Apps
• Fintech Apps
• Social Media Apps
• Education Apps
• Productivity Apps
• Travel Apps
• Shopping Apps
• Dating Apps
• Capcut Review
• Yoga Go Review
• Lucky Date Review
• Temu Review
• QuillBot Review
• Discord Review
• Cutout Pro Review
• Calm Meditate Review
• Coursera Review
• Opinion Pieces
• Success Stories
• 40 under 40
• Women in Tech
• Top Billionaire
• Top 2000 Companies
• Press Release
• Get featured In MAD
• Contribute On MAD
• Service Offerings
• Brand & Products
• Top Agencies
• Top Products
• For Agencies
• For Products

Show more results >

• Artificial Intelligence
• Software Development

Why Software Projects Fail, and the Traps You Can Avoid That Could Spell Disaster

Why software projects fail and how to make them succeed:, what we are saying is, share it on:.

Is software failure really inevitable? Well, as a matter of fact, a surprising amount of software projects fail. You must be wondering, what the software project failure statistics is. According to a study done by Geneca , 75% of business or IT executives feel that usually their projects are doomed right from the very beginning. Now, this mindset is the last thing you need!   According to Project Management Institute , organizations are wasting an average of $97 million for every $1 billion invested, due to poor project performance. PMI came up with a project performance metrics that exhibited the following project failure statistics:

• 14% of IT projects fail completely
• 32% projects lost their project budget upon failure
• 49% of the projects experienced scope creep that is, scope of the project was not clearly defined and controlled

While working on a project whose integral part is the development of software as a service (SAAS) app or customer relationship management (CRM) tool, software failure is not justifiable. To avoid such blunders, you need to understand the reasons why software projects fail and how to avoid these traps. Also, if you want to serve your customers efficiently; you need to concentrate on proficiency during the software development phase. Let us help by making your software project success rate better.

1.    Ambiguous Project Requirements

Did you know, less than 20% business executives describe the requirements process as the articulation of their business needs? Either the client is unable to define the requirements of the project or, the project manager is unable to understand the specifications of the project. This ambiguity further leaves the developers unsure of what features are essential. This further increases the software projects failure rate. These expectations should be laid out from a very early stage but unfortunately, that is not the case.

Case study: In 2008, Australia’s national airline – Qantas, cancelled its Jetsmart project. The project was worth $40 million and it entailed building a parts management system for airplane mechanics of the company. Following certain turn of events, the solution was so poorly executed and designed that the airplane mechanics refused to use it. After introspection, officials stated that instead of understanding the requirements properly, they just designed what they thought was appropriate. They finally had to abandon a costly IT project and ended up building a replacement solution which took another three more years! Now that you know the seriousness of this situation, let’s talk about the solution.    

Projects with effective communication are twice more likely to deliver project scope and meet the quality standards successfully when compared with the projects without effective communication.

So, here is what you need to keep in mind to overcome this cause of software project failure:

• Make sure that you are working with a professional team who knows the importance of the 5 whys .
• Team should never shy away from asking questions till they dive in deeper and reach the root cause.
• The team should also have a proven track record of scaling software.
• You should never forget that communication is the key to build a good product or service.

Note: The tree swing analogy is a generic concept; please re-create this image with text in a different art style. DO NOT copy it since this image as is because of copyright issues. 

2.   Unrealistic timelines and planning

According to Innotas, 55% of IT professionals surveyed indicated that they had a project fail due to lack of time, staff, resources, budget and planning. In the early phase of a project, time estimation is the best educated guess because teams are still comprehending the project requirements. One of the most common reasons why software projects fail is because of arbitrary deadlines and plans that are set with insufficient data. Unrealistic timelines and planning are mainly set because of these two reasons:

• Inexperienced development teams: Such teams assume that everything will go smoothly. They do not keep the project risks and project budget in mind.
• Inexperienced project managers: Sometimes project managers request an estimate too soon and don’t consider checking in with the team to find out if the given timeline is feasible or not.

 40% of CIOs say that some of the main reasons IT projects fail is an overly optimistic approach and unclear objectives. Because of these factors, the team would have to rush the software development process; this increases the error rate and results in an unsatisfactory product or service which finally answers the question why software fails?

• Ranged estimates : You should provide ranged estimates in the case of poor estimation practices. For example, if developers estimate that they require two months to finish a project, consider the risks and uncertainty that can take place. So, it’s better to provide an estimate with some buffer time included in it.
• Re-estimate frequently: Since upfront estimation is the cause of unrealistic timelines, you should re-visit your plans and estimates frequently. Ask the development team habitually to check if the project is still on track or not.

 With the help of these practices you will be able to deliver on-time-in-budget projects and minimize software development failures.

3.    Lack of testing:

Software should be thoroughly tested for bugs. But, unrealistic timelines and planning often leads to little or no testing which further results in software failure. When there is a lot of pressure to deliver a project, companies test their software at production stage which compromises the security. So, software failures due to lack of testing is one of the major reasons why IT projects fail! This will result in an unsatisfied customer or worse.   Solution: We would advise that you should execute testing throughout the software development life cycle. It is always better to test each component as soon as it is completed. Obviously, you’ll have to allocate ample amount of time for testing since it is an integral process and should not be avoided at any cost.

4.    Poor project management

Poor project management is the perfect recipe for disaster! Time, scope and budget are the key factors involved in a project but a proficient project manager is an essential element that cannot be ignored. Without a project manager, the result will be unsuccessful projects.  

According to PMI, organizations that invest in proven project management practices waste 28 times less money because more of their strategic initiatives are completed successfully. It would be best if you have someone who is monitoring the entire project. This way you will also be able to diminish procrastination of work in your team. We advise that the project manager or IT manager use an agile approach. In agile, time and budget of a project are fixed but the scope is flexible. Also, most agile teams operate in a scrum framework.

Let’s discuss a few tips that will help you in choosing a software development company for your projects

In an ideal world, it is very easy to assume that solving the above issues are very easy, all you have to do is find a software development services company to bring your ideas to life. Well, we are sorry to say but it is not that simple! It is very difficult to find companies with talented and efficient developers. You will have to consider so many factors before finalizing the software developers for startups.

• Do not ignore the latest technology and tools: The software application development company should be updated about the innovations happening in the industry. You should not trust a software development company if their technologies, tools and methods are out-of-date, even if only by a few years.
• Strong insights of the project management mode l: According to PMI, 71% of organizations now use agile approaches to their projects. If you have a team of agile ninjas by your side, the project management experience will be smooth. A team that defines your idea, finds the best solution, starts the project after analyzing, planning and estimating. Further, get the product finalized with proper testing and well crafted software.
• Dedicated resources are a must : Usually software development firms do not have sufficient workforce that can be assigned to specific projects. Dedicated resources would be experts who will look into different aspects of a project such as, developers, QA testers, project leaders, analysts, etc. Software development companies for startups pay undivided attention to this facet to provide better and error-free service.

Important takeaways

• Communication is the key, it is very important to understand the exact requirements of the project leaving no room for ambiguity to hit the bull’s eye.
• The timelines of the project should be re-visited while working on it so the project is a success.
• The lack of time, resources and budget should be kept in check.
• Adhesive testing should be done throughout the software development life cycle to avoid bugs and failure.
• Invest in proven project management methods and resources to make your project a hit.

Failure is not the end of the world; one should discover, learn and move towards the success one deserves! So, after reading this article we hope that you will not rush into the development process, but rather find a perfect custom software development company  to assign your project to and achieve the desired results. All the best!

Get connected with top notch app development company, for free.

By Sakshi Kaushik

Content Writer (B2B Editorial)

A passionate writer and tech lover, she strives to share her expertise with mobile app developers and fellow tech enthusiasts. During her moments away from the keyboard, she relishes delving into thriller narratives, immersing herself in diverse realms.

Signup to our newsletter and receive daily updates.

Uncover executable insights, extensive research, and expert opinions in one place. 40 under 40 report -->, related content.

Best AI Courses: Pathway to Becoming an AI Engineer

How to Use Gemini AI model? A Definitive Guide

What is Bing Chat? Here’s Everything You Need To Know

Evaluating AI Development Companies: Key Factors to Consider

• Application Development

Ethical AI- Balancing Innovation with Moral Imperatives

AI Use Cases: Exploring Real-World Examples in Various Industries

Why Software Projects Fail and How To Get it Right

Read more posts by this author.

Cache Merrill

Why Software Projects Fail

A few years ago, Gartner conducted a survey on why software projects fail. We’ll take a look at what the study uncovered below, but here’s what’s notable about the company’s subsequent report. The top four reasons cited for IT development project failure then still—nearly a decade later—ring true.

When Zibtek set out to establish its software development process , these four issues were top-of-mind. From pre-project consultation to launch and maintenance, we know good communication, clear requirements, and detailed planning are essential to projects meeting original goals and being completed within budget.

5 Reasons Why IT Software Projects Fail

As reported by respondents to Gartner’s survey, the top four reasons IT software projects fail are:

• A change in the organization’s priorities (39%). Sometimes there’s even a failure to reach a consensus on priorities. Whatever the priority problem may be, project owners (POs) and project teams must get aligned on top project priorities. Must-haves, should-haves, and could-haves need to be clearly laid out.
• A change in project objectives (37%). It’s extremely rare for a project’s scope to be a sealed deal upfront. It’s important, of course, to define what the project’s goal is, but all projects must be able to adapt to changing business requirements during the development process. POs and teams alike must know when to pivot, or their efforts will be at best ineffective and at worst, a failure.
• Inaccurate requirements gathering (35%). Clearly defined project requirements are arguably the most critical factor in an IT project’s success. POs and software developers can both be guilty of overlooking details that could potentially derail a software project. Many times, the project requirements aren’t clearly communicated, with both sides misunderstanding what’s needed. Detailed requirements exist for a good reason; they help everyone involved in the project to define clear goals and objectives and ensure the end product meets the PO’s actual expectations.
• Undefined opportunities and risks (29%). This mistake is comparable to building a house without blueprints. Every software development project contains elements of surprise and uncertainty. Negative or positive risks should be described in terms of potential effects on the project. Risk analysis, evaluation, and response planning build a framework for minimizing threats and revealing opportunities that can be maximized.

A fifth reason, poor communication, was reported by a quarter of respondents. It’s no surprise, of course, that effective communication is crucial to any project’s success. By establishing a culture of honesty and encouraging all stakeholders to speak up about ideas, complaints, or hesitations, the blame culture that pervades many project development teams can be eliminated.

Projects Need Less Complexity and More Governance

That’s the conclusion Gartner came to about why software projects fail. And that is one that Zibtek enthusiastically embraces. It’s our firm belief that proper planning can eliminate the top four failure triggers. When clients sometimes ask why a so-called Agile process requires so many planning sessions, we point out the sprint process is about structured flexibility, not a race to the finish line. By continually verifying priorities, objectives, and requirements, our engineers can adapt to change and incorporate new ideas.

Communication + Clear Requirements = Project Success

Zibtek believes one of the simplest ways to ensure a project stays on track is to work with a good PO who can facilitate clear communications, particularly on requirements, and help set practical expectations. Writing good [stories], backlog grooming, and [refinement meetings] are all necessary to clarify a project’s intentions and bring it to a successful launch. To learn more about Zibtek’s sprint planning process, including how it helps mitigate the most common reasons projects fail, contact us online today to schedule a consultation.