Why Software Projects Fail

Software projects fail often - way too often.

In 2014 the Standish Group, an IT research firm, conducted a study that surveyed 365 people representing over 8,000 software development projects. The results were, in a word, bleak. For example, over 30 percent of projects get canceled before completion. At large companies, according to their results, less than 10 percent of projects are “successful.” The bad news goes on, but you get the idea. The success rate on software projects is terrible.

The amount of capital, time and energy placed into software projects should preclude failure, and yet it occurs over and over again. So why do so many software projects fail? 5 main reasons: poor communication, confusing requirements, weak executive support, lack of a strong ‘why’, and lack of unified direction. We examine all of these reasons and how to avoid them.

1. Poor Communication

This is the number one reason that software projects fail.

Perhaps the most remarkable number that Standish Group landed on was this: under 10 percent of IT projects at large companies are successful. Something about large companies makes successful software development obtrusively difficult.

Another data point in the study indicates what that “something” is. For small companies, Standish Group found that project success rates approached 30 percent. That’s a 20 percent gap. Small companies--for all they lack in resourcing and manpower--consistently outperform their larger counterparts in one key area: communication.

Communication is the single most crucial component of a productive development cycle. The importance of having engineers, managers, and executives who talk to each other, solve problems together and, frankly, don’t mind being in each other’s company, cannot be overstated. No project can succeed without clear, high quality communication. This one component is more valuable than any individual person, machine, or software program.

Maybe this is why the Agile Manifesto lists “Individuals and interactions over process and tools” as the number one value. The founders of the Agile methodology knew the discussions around the software would be far more important than the tools used to create it. Without fluid communication between the team, scrum master, product owner, and stakeholders, the software project will be more likely to fail.

2. Confusing Requirements

Big ideas change the world. Too often, though, project sponsors come to the table with big ideas that lack specificity. For example, a simple term like “improved efficiency” might seem clear and obvious. In reality, it is quite ambiguous.

On the flip side, projects can be bogged down by requirements that are overly burdensome. It may be that too many people with too many different (and often conflicting) interests have their hands in the cookie jar. In rare cases, being overly detail-oriented risks missing the forest (building a good software program) for the trees (getting one or two minute details so perfectly right, to the point where everything else suffers).

The best way to avoid either of these situations brings us back up to number one: communicate. The stakeholders must be able to answer questions the team or the product owner has about the project, likewise the team and product owner must be allowed to ask those questions. Once the team has answers, they can then work internally to prioritize the work by the most important requirements. This leads to clear, efficient and successful projects.

3. Weak Executive Support

Executives and stakeholders may not have a hand in writing code, but the support of high-up personnel in a company is crucial to the success of developers. When questions and issues arise, and decisions need to be made, having somebody around with the political capital to make the hard decisions is invaluable.

If an executive and a stakeholder truly has a stake in the game, they should be an active participant of the process. They should be available for questions or design check-ins. They should understand any hiccups or challenges that may delay the project so that they can champion for the project to come to completion. They should see the value in the solution to help the team drive to it.

4. Lack of a Strong “Why”

Even developers need a reason to get up in the morning. Nobody wants to work on a project simply because they’re receiving a paycheck. People want to know what they’re doing is worth something--that their long hours of labor will have some sort of positive impact on a company and, hopefully, society.

Software projects sometimes exist in the ether, that in-between state where everyone knows what has to be done, but not why. Without a worthwhile, driving force--a positive end goal that everyone can get behind--such projects are doomed forever to their state of purgatory, where scope creep, budget inflations and never-ending development cycles abound.

When executives and stakeholders can clearly express a ‘why’ to the development team, they will see a clear difference in how the team works. The ‘why’ often brings the motivation for the team.

5. Poor Upfront Budget Estimation

There’s a saying in software development - “if you want to know how much a software project is going to cost, multiply the cost estimate by 3. [pause]. Then double it.”

While we can chuckle at that, it’s only a soft chuckle with a half-smile because anybody who has spent time executing these projects knows there’s just a little too much truth to it. According to the Standish Group study, over half of all software projects end up costing nearly double their projected estimates.

Nobody has an unlimited budget. And cost overruns are a major part of software development project failures. Instead of trying to cut back costs at the beginning to make the project more desirable, be realistic about what is needed to accomplish the project. Knowing your why and communicating it clearly to the team to make estimates on time and effort will help immensely with this.

6. Poor Management

The 2004 United States men’s basketball team included some of the best players to ever play the game: LeBron James, Dwayne Wade, Carmelo Anthony, Tim Duncan and Allen Iverson. Five of the best basketball players in the NBA, but they weren’t good. In an exhibition match they lost by 20 points to Puerto Rico, earning the nickname “The Nightmare Team.” In the Olympics, The Nightmare Team settled for the bronze medal.

No team, no matter how strong its personnel, is effective without the right management. In a software project, even if they’re not typing the zeros and ones, management and proper coordination is as necessary to success as anybody on the ground. They must foster a productive work environment, stave off obstacles along the development cycle, keep the focus, and be attentive to the needs of their team members. They should inspire teams to do their best work. They should be effective planners, decision-makers, and coordinators, keeping everybody on track. Without quality leadership, in software as in life, any team project is destined to fail.