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)
This article describes several reasons for software project failures.
Readers who are interested in the article question, especially software project managers.
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:
According to research conducted by the Standish Group in 2005:
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.
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)
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)
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.
"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.
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.
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.
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.
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:
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:
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).
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.
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)
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.
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.
"…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:
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.
"…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:
This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.
A list of licenses authors might use can be found here
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.