Software Failiure

All successful software projects start with the premise that the end result will be successful. The owner of the project initial goal is to deliver on time and on budget. Although these are the primary focus when the project begins, yet is it not more important that the project deliver tangible business and consumer results? A project manager must take both the customer and the project into consideration when performing a software project. Time, thought and much consideration (focus) must be the aim of the project from beginning until completion of the software project. These are primary keys to a project’s success. There are many keys that ensure the success of a project many will become familiar to the reader throughout the reading of this paper. Business drivers such as problems or opportunities that maybe encountered in the beginning and throughout the completion of the project are criteria used to measure the benefits of the project. These drivers should be the primary focus when scoping the project and setting the goals of the project. All projects begin with goals in the order of priority directly related to and supported by the business goals. Target goals are put into place to ensure the project meets the specified time and does not deviate more than those allowable in project plan. The customer and the project planner must be in complete agreement on the goal and anticipation of the project before the project begins. An understanding of what the customer expects the success of the project to look like and what measurements will be considered to determine the desired outcome of the project to the customer’s satisfactions are critical points when the project is started. These issues should be easily understood by all concerned. A successful project must first be defined. Question, how do we define the success of a software project? We could begin by looking at meeting desired cost, schedule, and scope objectives. Was the project’s completion date met? Was it within budget guidelines and did it meet the desired specifications? Software project success has often been defined in ways that are measured the day the project was finished. This is not always the case. Some projects exceed the specified date originally set forth at the forefront of the project. This does not mean that the project was a failure because of the time constraints. Many projects require more testing than was originally set forth at the start of the project or more funds that are necessary to ensure the project is a success. One example is the Sydney Opera House (Duncan, W.R.), that cost sixteen times as much to build and took four times as long to complete as the original estimates. Although thought to be a project management disaster ending up producing an enduring and inspiring civic symbol. Would this constitute as a project failure? Project success depends on a combination of product success and project management success. Many project owners define the success of the project by the time of completion. If the project was completed in the specified time it was a success. Ask yourself this question; if the project was completed early or a day or two late with all specifications met did you have a success software project? Or if it was completed on time with continual adjustments after completion, is this a successful project? A project must follow a completion milestone that should allow for each step of the project to fall within specification. All software project should include modification allowances that provide for added research should the project require it.

Literature Review

Software failure can be “defined as the occurrence of either deficient functionality, where the program fails to perform a required function, or deficient performance, where the program performs a required function too slow or in an insufficient manner”?. (Rutgers Computer & Technology Law Journal. Perlman, Daniel T., 1998) We live in a society that depends extensively on computers to accomplish our everyday needs; everything from monitoring patients in hospitals to monitoring our national defense depends primarily on computer software not failing. Bearing in mind their fundamental need for computers to function properly, software project failure rates are among the highest across all industries, however the number of statistical reports analyzing those Failure are lesser then one would expect.

This literature review provides an overview of general literature available on this subject, the main of objectives of the evaluation are to establish why software projects fail and the main reasons a project may fail along with what lessons can be learnedA  to improve software developments in order for them to success in the future. The subject of Software Project Failures is full of books, and papers thatA stress Why Software Projects Fail, most of them share numerous characteristics ranging from failure due to incomplete requirements to failure due to an incompetent project manager.A 

Among the studies examining these failures is the 2009 Standish Group CHAOS Report. The report is a collection of data on project failures in the software industry. Its main goal is to make the industry effective and productive and to illustrate ways to improve its success rates and increase the value of the software investments. Their most recent results were published in April, 2009.

The introductory statement in CHAOS Report reads: “The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using few materials and less labor to perform the same task.”? Tom Clancy (The Sum of All Fears) (The Standish Group, 2009)

With use of this quote the CHAOS Report suggests that software developers should adopt bridge builders approach of learning from past mistakes. The report explains that the difference between software failures and bridge failures is that when a bridge fails “it is investigated and a report is written on the cause of the failure”?... whereas when a software fails the “failures are covered up, ignored, and/or rationalized. As a result, we keep making the same mistakes over and over again.”? (The Standish Group, 2009)

The Standish Group investigated the failure and success rates along with the reasons for success and failure. Their study surveyed four focus groups with IT executives of major companies. The attendees represented a wide variety of industries, including insurance, state and federal government, retail, banking, securities, manufacturing and service. Three distinct outcomes, called Resolutions, were what the subsequent report divides projects into. Project Resolution Types 1 (Success), 2 (Challenged), and 3 (Impaired). Resolution Type 1 was when a project was a success; it was completed on time and on budget, with all the functionalities and features intact.A  The projects that fell in this category only amounted to 16.2%.A Resolution Type 2 was when a project was completed, however it was over budget or over time, and missing some or all of the functionalities and features that were originally requested.A  52.7% of all studied projects fell into the Resolution Type 2 category. Resolution Type 3 were projects that were abandoned at some point during the development cycle, consequently becoming total losses.A  A staggering 31.1% of all the projects studied fell into this category.A 

The Standish Group further divided these results by large, medium and small establishments. A large establishment was one with greater than $500 million dollars in revenue per year, a medium was defined as having $200 million to $500 million in yearly revenue, and a small was from $100 million to $200 million. However the statistics for failure were equally discouraging in companies of all sizes.

The most important aspect of the research is discovering why projects fail. The report isolated that the top five factors found in successful projects were: user involvement, executive management support, clear statement of requirements, proper planning, and realistic expectations. These indicators were extracted from surveyed IT executive managers of their opinions about why projects succeed.

Project Success Factors

% of Responses

1. User Involvement

15.90%

2. Executive Management Support

13.90%

3. Clear Statement of Requirements

13.00%

4. Proper Planning

9.60%

5. Realistic Expectations

8.20%

6. Smaller Project Milestones

7.70%

7. Competent Staff

7.20%

8. Ownership

5.30%

9. Clear Vision & Objectives

2.90%

10. Hard-Working, Focused Staff

2.40%

Other

13.90%

The top factors found in “Challenged”? projects were: lack of user input, incomplete requirements and specifications, changing requirements and specifications, lack of executive support, and technical incompetence. The list of top indicators factors found in “Failed”? projects were: incomplete requirements, lack of user involvement, lack of resources, unrealistic expectations, lace of executive support, changing requirements and specifications, lack of planning, didn’t need it any longer, lack of IT management, and technical illiteracy.

Project Challenged Factors

% of Responses

1. Lack of User Input

12.80%

2. Incomplete Requirements & Specifications

12.30%

3. Changing Requirements & Specifications

11.80%

4. Lack of Executive Support

7.50%

5. Technology Incompetence

7.00%

6. Lack of Resources

6.40%

7. Unrealistic Expectations

5.90%

8. Unclear Objectives

5.30%

9. Unrealistic Time Frames

4.30%

10. New Technology

3.70%

Other

23.00%

The Standish group report conclude that projects succeed because of: executive support, user involvement, experience project manager, clear business objectives, minimized scope, standard software infrastructure, firm basic requirements, formal methodology, and reliable estimates. The main causes of IT project failure were: lack of clear link between the project and the organization’s key strategic priorities, including agreed measures of success; lack of clear senior management and Official ownership and leadership; lack of sufficient data; lack of effective engagement with stakeholders; lack of skills and proven approach to project management and risk management; along with lack of effective project team integration between clients, the supplier team and the supply chain. Causes of failure could also be the result of the problem not being properly defined: they may have developed the right solution to the wrong problem. This is best addressed by trying to understand the reason for doing the job.

The CHAOS Report does have its own shortcomings. Its measures of success are relatively narrow; it only measures success by examining whether a project was completed on time and on budget. The Standish group does not include measures of quality, risk, and customer satisfaction. Nevertheless, the CHAOS Report endures as an important measure for the software despite limited standards of measurement and limiting sources to interviews with executives.

There are several other studies on statistics over IT project failure rates which mainly concur with the overall picture of the IT industry that the CHAOS Report provides. In 1997, a study conducted by KPMG Canada, reviewed 176 projects. Their findings determined that over 60% of projects failed to meet their sponsor’s expectations. A staggering 75% missed their deadline by 30% or more, and over half “substantially”? exceeded their budgets. The main causes for project failure that were identified were: poor project planning, specifically, inadequate risk management and a weak project plan; weak business case; and lack of top management involvement and support. In September 2000, the Gartner Group surveyed 1375 respondents through interviews. (Gardner, 2010) The study indicated that roughly 40 percent of all IT projects fail to meet business requirements. In a more recent survey, the Aberdeen Group claimed 90 percent of projects came in late, while 30 percent were simply cancelled before the deadline. (Booth, R., 2000)

According to Tom Carlos in his article "Reasons Why Projects Fail”? gather major reasonsA  ranging from simple to complex project, The most common reasons for failureA  found in the list include :A 

•A A A A A A A A A A A A  Poorly managed

•A A A A A A A A A A A A  Inadequate or vague requirements

•A A A A A A A A A A A A  Undefined objectives and goals

•A A A A A A A A A A A A  Lack of management commitment

•A A A A A A A A A A A A  Poorly defined roles and responsibilities

•A A A A A A A A A A A A  Stakeholder conflict

•A A A A A A A A A A A A  Team weaknesses

•A A A A A A A A A A A A  Lack of user input

•A A A A A A A A A A A A  Scope creep No change control process Meeting end user expectations

•A A A A A A A A A A A A  Poor communication

•A A A A A A A A A A A A  Lack of a solid project plan

•A A A A A A A A A A A A  Lack of organisational support

•A A A A A A A A A A A A  Centralised proactive management

•A A A A A A A A A A A A  initiatives to combat project risk

•A A A A A A A A A A A A  Enterprise management of budget resources

•A A A A A A A A A A A A  Provides universal templates and documentation

•A A A A A A A A A A A A  Unrealistic timeframes and tasks

•A A A A A A A A A A A A  Competing priorities

•A A A A A A A A A A A A  Poor communication

•A A A A A A A A A A A A  Insufficient resources (funding and personnel) Business politics

•A A A A A A A A A A A A  Overruns of schedule and cost

•A A A A A A A A A A A A  Estimates for cost and schedule are erroneous

•A A A A A A A A A A A A  Lack of prioritisation and project portfolio management

•A A A A A A A A A A A A  Scope creep No change control process Meeting end user expectations

•A A A A A A A A A A A A  Ignoring project warning signs

•A A A A A A A A A A A A  Inadequate testing processes

•A A A A A A A A A A A A  Bad decisions

The first 10 failure in the list focus strictly on software requirements where in the requirements are defined user input, stakeholders, communication.

Data and Hypotheses

When we look at the success or failure of a software project we must also analyze other areas that can have an impact on the project. A review of the Business Analysis Benchmark gives the project owner and the customer a clear understanding of the organization’s maturity in requirements definition and with management expectation of the project outcome. (IAG Consulting. Ellis, E., 2009) Findings in this analysis showed that requirements maturity has a strong positive correlation to every major measure of development efficiency assessed. It can be a strong motivator in the success of the project. Based upon time performance, budget performance, function performance, each can be a fundamental point in project success when there is an increase in these areas. The project owner must have a clear vision/goal to prepare for success. Failure can become apparent in many ways, i.e. changing the vision in the middle of the project, disputes on the primary focus, expectations that are beyond project scope, unreliable or not enough resources to maintain project direction and possibly the most valuable to the success of the project is good leadership. An article titled, “If Software Quality is so Important, Why is it So Often Neglected? (Sassenburg, H., 2006), a great title for this literature review research. This article further explores the Standish Group’s CHAOS Report with a great quote, “Software Crisis has not yet reached the turning point. It gives the reader a good statistical percentage, “Only 28% of software projects succeed these days, down from 34% a year or two ago. Outright failures [projects cancelled before completion] are up from 15% to 18%. The remaining 51% of software projects are seriously late, over budget and lacking features previously expected”?. As the study reviews this article a discovery is made based upon the research that includes how the cost is distributed. The designer allows certain percentages for each area of the project phase. In the analyze segment of the project it is projected that 10% will be utilized. Design phase will encompass about 15% while the realization and testing will average the remaining percentage. Many projects exceed the budgeted percentage and allotted funds will be taken from one phase and move over to the phase in need. This can at times cause the project to slow in progress or be placed in a temporary state or even placed on hold. The end or mid-result can be the determinant of a number of factors that are evaluated to determine how to complete a software project. The CHAOS Report gives unique information regarding how much is spent on IT application development, $250 billion each year on IT application development which equates to approximately 175,000 projects. A large company can spend anywhere from $2,322,000 to develop a project. Medium companies can spend $1,331,000 and a small company can even spend $434,000 to develop a software project. It has also been determined that many of these projects regardless the cost will fail. Hence CHAOS, therefore no longer can one speak the three monkeys, “hear no failure, see no failure, speak no failure”?.

In the article, Project Management Practices: The Criteria for Success or Failure, (OW, S. H., & Harzadeh, I.) list the top four factors that contribute to a projects success are, user involvement, executive management support, clear statement of requirements and proper planning. This article also explores how a project fails; the main reason for failure is listed as, the inabilities of project owner’s to plan and estimate correctly, or fail to implement the tasks according to plan or simply failure causes by human factor. The Standish Group has estimated that American companies spend at least $81 billion for cancelled software projects. Also, that another $59 million to complete a project that has exceeded budgeted plans. It has been estimated that only 16.2% of software projects were completed on time and on budget. Only 9% of this estimation is for larger companies that have a successful project finished on time and on budget. On occasion these are simply a fraction of the original requirements. Scary? On another scale, Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

The study determined that the most projects, 37.1% were impaired and subsequently cancelled in medium companies, compared to 29.5% in large companies and 21.6% in small companies. Many software project failures are due to cost and time overruns which result in the restart of the project. These causes the project to go over budget and exceed time requirements set forth in the original software project plan. With the three major elements for a project in place, (user involvement, executive management support, and a clear statement of requirements), there is a much greater chance that the project will be a success. Without these three elements the chance for failure increases. In the project management scorecard there are several surveys in which to score whether the project is a success or a failure. A survey list reasons most people give, regardless the type of business for failed or poorly managed Projects. This score card also list the cost of a failed project when poorly managed. An article in the datacenter journal, facing IT Project Failures, explains that the failure of an IT project as others discoveries disclose, can simply mean that the project has gone over budget by a certain percentage, that completion of the project was delayed beyond a certain point or that the business failed to reap a certain return on investment from its project. The CHAOS report indicates that project success rates have increased to 34 percent of all projects. This percent is 100% more from the success rate found in the first study in 1994. A decline in project failure to 15% of all projects is a great improvement over the 31% failure rate reported in 1994. In this current survey a total of 51% of all projects were over the specified time required, over budget or lacking features and requirements.

Cite this page