Why software projects fail - and how we make them work
Success / Failure Factors
Software projects are known to have a high level of failure. How high? The often referred study on software project failures, published by the Standish Group is called the CHAOS Report. It is a result of analyzing software projects in the US.
On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. 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.
This quote from the report draws a dismal picture for software projects. Another interesting finding of the report are the factors and their relative importance in contributing to the success or failure of projects.
Project Challenged Factors % of Responses 1. Lack of User Input 12.8% 2. Incomplete Requirements & Specifications 12.3% 3. Changing Requirements & Specifications 11.8% 4. Lack of Executive Support 7.5% 5. Technology Incompetence 7.0% 6. Lack of Resources 6.4% 7. Unrealistic Expectations 5.9% 8. Unclear Objectives 5.3% 9. Unrealistic Time Frames 4.3% 10. New Technology 3.7% Other 23.0%
Software developers are aware of these factors. And the fact that the first three factors being beyond the direct control of the development team only proves that the often used – ‘not my fault’ excuse by developers for failed projects is not totally unfounded.
Development Methodology
The main factors for software development failure are lack of user involvement and incomplete or changing specifications. The reason these factors are so commonly attributed to failure of development projects is largely the development methodology used for most software projects. Conventional development methodology involves creating up-front systems analysis and specifications design of a project spanning a large number of features that require several man-months or man-years of development. Development is then carried out in an extended development cycle assuming that:
- the specifications are clearly written
- the interpretation of the specifications by the developers matches the user’s expectations
- the expectations of users do not change during the development cycle
All these assumptions are highly unreliable. User involvement in such a project begins only after the development cycle is almost or entirely completed. This results in the inevitable ‘this is not what I meant/want’ response.
Agile / Adaptive Software Development Methodology
Software development methodologies have evolved in the last decade that incorporate:
- close collaboration between the programmer team and business experts
- face-to-face communication (as more efficient than written documentation)
- frequent delivery of new deployable business value
- tight, self-organizing teams and
- design of code and development teams in a way that minimizes the risks of inevitable change in requirements.
These Agile or Adaptive Software Development are now following in various forms such as Scrum, Crystal, XP (Extreme Programming), etc. and are based on the realization that building software is not like building an immovable asset such as a house or a bridge. Software is a movable asset in the sense that it needs to change over time and space. Software is a tool for humans. Humans change, requirements change and hence software needs to change not just a few times in the form of project or product upgrades, but continuously, as a process of evolution.The Agile Manifesto is a statement of shared development values crafted by various originators and practitioners of these agile methodologies:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Reach1to1 Methodology
At Reach1to1, we have adopted a methodology that is based on the agile manifesto.
-
Development of Process Scenarios (User Stories)
A Process Scenario or User Story is a description of tasks that are performed by users in typical scenarios while interacting with customers. The stories will also describe how the processes will be facilitated by the software. The stories will not describe the software in technical terms, database layouts or algorithms. They will use the language and terminologies normally used by users. -
Release Plan for entire project
The release plan specifies which user stories are going to be implemented in which development cycle, and dates for those releases. The release plan is finalized together by the entire team.
Also during the release plan, the infrastructure requirements are laid out in terms of the hardware, operating systems, other supporting software platforms etc. -
Small Release Cycles (as planned in the release plan)
Development is carried out in several small cycles lasting not more than 4 to 6 weeks each. Each development cycle will involve: -
Scope Planning
-
User Interface Prototype
-
Software Development
-
Unit and Functional Testing
-
Installation on site
-
User Feedback
-
Fine Tuning as required
The scope for each cycle will be planned in a way that it can be completed in not more than 4-6 weeks from the start, and the results are usable and testable by the users. Each week there shall be a review meeting of the entire team for assessing the progress of the cycle, and modifying the scope if necessary so as to ensure its completion on time, and with acceptable results.
Scope plans for a new cycle are started only after the previous cycle is completed. This ensures that the clarity achieved by the users and developers are incorporated into the plan for the next cycle.
Other principles that maximize project success
In addition ot using an agile development methodology, Reach1to1 also uses the following principles:
- Affordable Technology
- Preferably open source technologies to keep the technology costs affordable
- Component Based Architecture
- Develop application architectures based on components that can be easily upgraded or replaced independently of other components
- Object Databases
- Use databases that allow changes in the data model at any time, rather than databases that require fixing the data model initially and are difficult to change
We follow these principles to build and deliver custom-built solutions that automate business processes in a way that maintains the high levels of flexibility, scalability and efficiency that is required especially by evolving enterprises.
