Why do so many software projects fail ?
Filed Under Improvement, Techniques, Issues, Process, Development, Software | Posted on September 3, 2007
Software development is a tough task, as evidenced by the fact that a lot of projects are known to fail for some reason or other. For a practitioner of software development, it is good to understood the reasons as to why software projects fail. This will help in trying to relate these reasons to their own projects and try to make the necessary corrections and improvements.
So what are these reasons ? Some of the common reasons are:
- Changing Requirements & Specifications: Most of the time, clients are not really sure about what it takes to transform their business ideas into reality. They need help in defining their business needs and mapping them to functionalities and applications necessary. This is where an organization that captures requirements from the client in a strategic manner will score heavily in vendor selection criteria.
Capturing client requirements isn’t as simple as asking the client to describe his needs and then labor on developing the necessary features. Beginning with a thorough understanding of the business needs, how and where the functionality being developed will help in satisfying these needs and then communicating these studies to the client and narrowing down on a set of features based on which an estimate regarding costs and time are made. This is where business analysts and customer relationship managers play an important role.
One obvious solution to changing requirements and specifications is to use the following process: Establish a reasonably stable requirements baseline before any other work goes forward. But even when this is done, requirements may still continue to creep. The bad news is that you can’t design a process that assumes requirements are stable. In virtually all projects, there will be some degree of “learning what the requirements really are while building the product. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes. The good news, on the other hand, is that if you architect a project from small, iterative phases instead of mammoth, serial deliverables, you will deliver more quickly, leaving less chance for change to overcome the work, and less risk of large systems failure.
- Incomplete Requirements & Specifications: Requirements & Analysis is one of the most important and often most neglected activities of the software development life cycle. A good requirements model fosters communication between the business and IT by enabling them to share a common vision of the system’s solution prior to implementation. This will ensure that the system meets the business needs, can be delivered on time, and have the level of quality and flexibility to easily accommodate future business needs. However, if this is not given sufficient time and effort, or if the communication between the client’s users and the requirement gatherers is tense or not good, then the requirements and specifications will not be complete.
A solid requirements engineering process is the best solution currently available to get around this problem. Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing needs, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification and managing requirements as they are transformed into an operational system.
- Technology Incompetence: Choosing the appropriate architecture for your application is key. Many times when asked to review a project in trouble, it is normally found that the development team did not apply well-known industry architecture best practices, or did not consult enough, especially when it is related to newer technologies.
- Lack of Resources: The only way to complete an engineering project rapidly and efficiently is to assign an adequate number of people and then protect them from interruptions and distractions. This helps build the motivation and effective teamwork needed for quality results. When managers fail to provide timely, adequate and properly trained resources, their projects will generally fail.
- Unrealistic Expectations & Unrealistic Time Frames: You might think that pushing for an aggressive schedule would accelerate the work, but it actually delays it. When faced with an unrealistic schedule, engineering teams often behave irrationally. They race through the requirements, produce a superficial design and rush into coding. This mad scramble to build something - anything - results in a poor-quality product that has the wrong functions, is seriously defective and is late.
It is unfair to call a project a failure if it fails to meet budget and schedule goals that were inherently unattainable. Like all engineering endeavors, every software project has a minimum achievable schedule and cost. Fredrick Brooks summarized this law in The Mythical Man Month when he stated, “The bearing of a child takes nine months, no matter how many women are assigned.” Attempts to circumvent a project’s natural minimum limits will backfire. This problem occurs any time someone makes up a number and won’t listen to anyone about how long other projects took. Projects are often intentionally underbid because of the attitude that putting a development team under sufficient pressure can get them to deliver almost anything. It is true that pressure can increase the quantity of results one receives, but, after a point, dramatically reduces the quality of those results. In fact, pressure sometimes produces the opposite of its intended effect.
- Poor User Input: the system did not meet user needs. The designers and the developers of this system had received most of their requirements from higher-level supervisors and so-called “users” who were not regularly using the existing system.
- Stakeholder conflicts: Stakeholder conflicts can play many different roles project failures. Often, stakeholders have personal reasons for not being able to work together. Other projects fail because the developers do not know who the “real” stakeholders are. Other projects, especially smaller projects within larger projects, never go anywhere because the internal stakeholders never agree on priorities. All too often, software product development is divided between a marketing-owned group who identifies features and prioritizes bug lists, and an engineering team that implements the code. The leaders of the engineering and marketing groups are supposed to “co-own” the product, and supposedly there should be some “healthy friction” between them. This thought process is flawed, and only leads to “Design by Committee”, a very strong reason for a project to fail.
- Poor Quality Work: When executives push for unrealistic schedules, the project either will be late in delivering a working product or will produce a product that doesn’t work. There’s a saying about software quality: “If it doesn’t have to work, we can build it really fast.”
- Poor planning: Well-defined processes play a critical role in the discovery, invention and implementation stages of a project. Although the word ‘process’ may be an anathema to a few, statistics have proven that following a clear development processes, stringent quality assurance processes, risk management and change control procedures help detect problems as early as possible. Even though detailed planning saves an enormous amount of time in the long run, many managers and developers believe it to be unnecessary. They seem to think time spent on things like planning, design, requirements, and inspection gets in the way of real work, which is coding and testing. This comes from the view of programming that the issue is to get the software out the door. But there’s a difference between speed and progress.
Leave a Reply
