Introduction

It is a sad statistical fact that software projects are scientifically fragile and tend to fail more than other engineering fields.

"A Standish Group research report shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates" (1)

The statistics also show results for different software company sizes and types:

"…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…" (4)

Scope

This article describes several reasons for software project failures.

Who Should Read this Article?

Readers who are interested in the article question, especially software project managers.

When Can a Software Project be Defined as a Failure?

The failure mark of disgrace is quite arbitrary and subjective. Ask the project manager of a failure project and he will tell you that it is not. The intensiveness of the failure also varies from project to project. In a commercial software company, a failure will be related to the software consumer. For example:

The software did not meet with the consumers need.
The software release was later than scheduled (deadline violation).
The software had too many bugs.

Sad Statistical facts

According to research conducted by the Standish Group in 2005:

"… only 28 percent of software projects in 2000 succeeded outright …" (2)
"… Some 23 percent were cancelled, and the remainder were substantially late …"(2)
The following statistics are a result of the year 2000:
The following is a list of failure reasons, Standish Group (1):

Why Do Software Projects Tend to Fail?

Note: The following list of software project failure reasons is not prioritized. Some of the reasons are claims that were measured by researchers. I have tried not to add my own judgment; it is left to the reader.

The maturity of the software engineering field
- The software engineering field is much younger than the other engineering fields and that, in time, will get more stable
- The field is young and therefore most of the field engineers and managers are also young. Young people have less experience and therefore tend to fail more
- Young people are more optimistic and tend to estimate badly
Shortage of knowledge base

As a relatively young engineering field, software engineering is short of accumulative knowledge bases. For example, the famous gang of four book "Design Patterns: Elements of Reusable Object-Oriented Software" was first published in late 1994. The book suggests design patterns to common software design problems and it is one of the famous knowledge base materials in the software engineering field. "Software engineering has evolved steadily from its founding days in the 1940s"(5), but it is still short of accumulative knowledge base as opposed to other engineering fields. Another example is OOP (Object Oriented Paradigm). OOP is considered to be more successful than the previous procedural paradigm. OOP was only embraced by the Software industry in the 1990s. "Even though it originated in the 1960s, OOP was not commonly used in mainstream software application development until the 1990s."(Wikipedia)
Software is not tangible

As opposed to other engineering fields like civil engineering, the software engineering building blocks are much less tangible and therefore hard to measure and estimate. "Software is abstract"(2)
Competition: harsh deadlines

The competition in the software industry is harsh. The Time-To-Market (TTM) is crucial and the drive to meet harsh deadlines is enormous. This characteristic, along with other methodological anomalies like "Code first; think later" and "Plan to throw one away; you will, anyhow," makes competition harsh. The hard competition in the software industry causes not only the need to deliver ASAP, but also the requirement to catch as many potential customer eyes as possible. Firing in every direction causes disorganization, fast coding and projects that are not well planned.
Technology changes rapidly

"Software development technologies change faster than other construction technologies."(2) Until recently, Microsoft was frequently bombarding the industry with new technologies. Rapid technology changes introduce liability for software manufactures. For example, new Operating Systems obligate a company like Ahead to release a new adaptable version of Nero. A few years ago, Microsoft had decided to change the way it introduced new technologies to the software industry. It introduced the wave methodology. In this methodology, Microsoft agreed to release a bundle of technologies (tools, Framework, programming languages etc.) in waves, every several years and by that, let the software industry adapt and digest the new upcoming technologies. Lots of popular software like Ulead Video Studio and Nero that used to run on Windows XP do not run on Windows Vista.
Change is tempting

A building architect will not decide to add additional floors during the building construction. The result would be dreadful, as the building foundations were not constructed for it. The software architect's hand, however, will be much more loose on the trigger. Irresponsible changes like adding new features and redefining existed ones may cause deadline violations and/or bad planning and coding (patch). Given the harsh competition (see item 6), it looks like changes are inevitable.
Bad time management

Estimating the development time should correlate to the employees ("resources") on hand. In some cases, managers estimate and then enforce a time table as if they were the ones who were going to do the developing. This type of enforcement yields pressure on development and may harm it. Moreover, violating deadlines in this condition is common.
Bad or no managing skills

It is common that software managers are used to being excellent, successful and professional software engineers. Unfortunately, the skills are not the same when it comes to successful managing. Great engineering skills do not guarantee great managing. Newborn software managers do not receive the right, or any, guidance.
Wrong or no Software Development Life Cycle (SDLC) methodology

Developing life cycle methodology must be part of software project management. Nevertheless, it should not be forced into the R&D environment. The software engineering field is relatively young (see item 4), but still there are already well-known developing life cycle methodologists (Agile, Crystal, Spiral, Waterfall, etc.), successful stories and case studies. Software project managers may adopt one of the existing methodologies, but usually there is also a need to adapt the methodology to the company on hand. The adaptation includes: company culture, employees, marker, managers, etc. This is the Waterfall Model:
Bad or no documentation

Documentation should be considered as a "must have" and not "nice to have". Documentation is an integral part of developing the life cycle process. It should not be caught as a nagging tedious task, done for the sake of some strict QA manager. There are various types of software project documentation, each related to a certain stage in the development life cycle of the project. For example:
- Statement of Work: preliminary requirements and project frame, usually written by the customer
- Marketing Requirements Document (MRD)
- Software Requirements Specifications (SRS)
- High Level Design (HLD), written by R&D
- Low Level Design, written by the R&D
- Project Schedule
- Software Quality Assurance Plan (SQA)
There are lots of templates and different names to the above documentation. Nevertheless, the important thing is that their existence requires the position holder to think before working on the project. The documents need to be stored and updated during the life of the project as it is done in a source code case (out of date document is a bug). Badly written or no MRD or SRS document can cause project failure (See item 11 bad SRS document).
Bad or no software requirements

As much as it sounds bizarre, in some software projects SRSs (Software Requirement Specifications) do not exist or are badly written. There are many types of SRS formats and even if it was only one common template, the content would vary from company to company. It is a question of how well-defined the requirements are. I have never heard about a well-defined SRS that caused projects to fail, but I am familiar with the opposite. A laconic requirements document affects the ability to break the software complexity, generate tasks and estimate time. Moreover, inadequate definitions cause misunderstandings and wrong implementation. Changes to the project during the development become inevitable and, in time, project deadlines will be missed.
Lack of testing
- Those who develop the software should not test it. The developer should run unit testing, but it is not a replacement to an objective QA test.
- Testing only at the end of a long milestone raises problems due to the load of testing and inherent problems that should have been caught at earlier stages.
  Moreover, managers tend to rush the testing period at the end of the milestone in order to release on time
- QA that does not bite and has no real power does not have the right effect on the R&D department and is there for the project itself.
- QA should be started as soon as the software project starts. Hence, even in the planning stage. QA participation in early stages is important for its preparation for the software. For example, QA should also check the SRS document and make sure that the software was implemented according to it.
- The following Professor Brooks rule of thumb might seem radical, but being given no proportional time for planning and testing is indeed problematic: "1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing."(3)
- Tester to developer ratio: there is no rule of thumb that defines the number of QA engineers per software engineer. The reason for that is that it depends on many variables and more specifically on the characteristics of the software. For example, if "multilingual" is a software requirement, then the number of tests increases. Another example will be the number of supported Operating Systems. The number of testers required to test the software requires estimation. Bad estimation can cause project failure. There are several models that help with Tester to developer ratio (see reference number 7). According to a recent informal survey held at QAI's 20th Annual Software Testing Conference in September of 2000 (8):
Poor communication among the "Holy Triangle:" customers, R&D and marketing

The "Holy Triangle," as I define it, describes the important relationships between the customers, marketing and R&D. As seen in the picture below, the marketing side combines the Customer and R&D. Marketing interviews the customers and picks at their needs constantly. Then it brings the important knowledge to the R&D department. Strange as it may seem, in some commercial software companies, the customer requirements and needs are not gathered. This anomaly can happen if the company suffers from "Hero base project." In this case, a certain persona, usually the company CTO, enforces the project requirements without taking into consideration the market and the customer's real needs. The result of this behavior might be the creation of software that lacks the market needs and, in time, is a project failure. "… The communication of requirements from customers to developers is a common source of problems, as is the communication from developers to customers of the repercussions of those requirements…"(2)
Human resources management

It is a given fact that lots of software project managers start working without the basic guidance of how to motivate people to succeed. Software managers tend to manage their software engineers only in the professional engineering aspects. However, software engineers are people too. Learning what motivates them requires time and will from the manager side. No two men are alike, both in terms of management and motivation.
No version / source control

Surprising as it may sound, some software projects are not backed up in source control. Sources get lost; versions cannot be regained; products on customer's side can not be reconstructed.
No or bad risk management

"…A project risk is an uncertain event or condition that has consequences for the project…The purpose of risk management is to identify, analyze, and respond to project risks…"(2). Given the above items and the fact that software projects tend to fail, it would be absurd not to manage risks. The Risk Management Document is the foremost design to enforce the software company to think about what can go wrong. The thinking process itself can solve problems before they even happened. Examples of risk:
- Incomplete or badly written requirements
- Choosing a technology that is not known by the current developers
- Relying on complex third party software
The Risk Management Document needs to be updated during project life cycles. It should not be too general or vague, but address real details of problems that might occur.

Summary

"…Software development isn't just a process of creating software; it's also a process of learning how to create the software that is best suited for its purpose."(2) The article describes some of the answers to the question, "Why software projects tend to fail?" I encourage the reader to keep reading on that topic for two main reasons:

Knowledge: knowing why software projects fail is a good start to preventing your own software project failure.
Incomplete: the information in this article is incomplete; I consider it as a promo to keep reading.

Bibliography and References

The CHAOS Report
Standishgroup web site, 1994
Software Project Secrets Why Software Projects Fail
George Stepanek, Apress, Sep 2005
The Mythical Man-Month Essays on Software Engineering
20th Anniversary Edition, Frederick P. Brooks, JR, Addison Wesley, Aug 2002 Why Software Fails, spectrum IEEE Online, Robert N. Charette
History of software engineering, Wikipedia
Theory and Problems of Software Engineering
David A. Gustafson, McGraw-Hill.
Estimating Tester to Developer Ratios
Kathy Iberle,Sue Bartlett
The Elusive Tester to Developer Ratio
Randall W. Rice
Templates and Guidance
Project Reference
Recommended Requirements Gathering Practices
Dr. Ralph R. Young, Northrop Grumman Information Technology

Why Software Projects Tend to Fail