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 application 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.
We have a problem here. 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?
We’ve broken down some of the most common reasons.
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.
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).
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.
Developers need a reason to get up in the morning too. 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.
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.
More than anything, an effective team requires a common goal--a "true north," if you will. Projects often go off the rails because they lose track of (or never know in the first place) what the ultimate goal of a project is.
It happens all the time. Consider this example: A team is tasked with a project to build, say, an "automated quoting tool". Seems reasonable enough. Quotes can be complicated and we want users to be able to answer a series of questions and create for them a customized quote.
The team takes this and runs with it, and six months later they're creating customized account management features for salespeople to save quotes and advanced reporting features. They think they're building nice tools their salespeople will love. And maybe they’re right. But the "why" of the project is never re-enforced, and in reality, the entire reason for the project was "to allow anyone easy and direct access to quotes without having to wait for a salesperson to generate one for them." So although these features that are being built might be nice to have, they don’t actually support the end goal of the project at all. They had nothing to do with enabling external users to generate quotes. Had they known clearly that this was the driving purpose behind the project, the project executors could have made better decisions to keep on track toward that goal.
Every project needs to have a “true north” that decisions can be measured against.
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 why projects fail.
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. 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.