Software is logical. People are not. That can make executing a tech project a frustrating proposition, to say the least. The goal with such projects is simple: make something that works. But whether it’s an infrastructure upgrade, a changeover to a new system, or combining two platforms into one, those involved have a high likelihood of messing up the project. The numbers regarding project failure are pretty bleak. The Boston-based Standish Group, a primary research firm focusing on software performance metrics, found that between 17 and 22 percent of all IT projects failed; another 49 to 56 percent fell in the category of “challenged.” When it comes to failure, size also matters. The Standish Group found that smaller projects succeeded 61 percent of the time. Contrast that with the largest projects, which cleanly reached the proverbial finish line only two percent of the time. Miserable numbers aren’t limited to a single firm. McKinsey & Co. likewise generated some dour statistics, estimating that large software projects went an average of 66 percent over budget; some 33 percent were late. Around 17 percent of projects placed their companies in financial peril due to poor management and execution. No wonder three in four executives expect their software projects to fail. And don’t think things are better on the other side of the Atlantic: another study by the U.K.-based Chartered Institute for IT found that almost a quarter of all tech projects ended up canceled.

Building a House is Easier

“IT projects have a greater chance of failure than a traditional construction project,” observed Jos Creese, digital consultant and past president of the British Computer Society. Tech projects are conceptually complex, and cutting corners can leave a manager or company with a solution that fits no purpose, or simply doesn’t work. Compounding the challenge is the speed at which technology evolves: if you don’t deliver a solution quickly, it could be obsolete by the time the client gets it, Creese noted. This is especially true when it comes to mergers and acquisitions, when two firms must merge their respective tech infrastructure into a combined platform that (hopefully) works. “There is a lot of evidence that mergers and acquisitions depend heavily on the ability to integrate technologies,” Creese said. If this cannot be done successfully, “you lose the benefits of the acquisition.” All stakeholders recognizing the necessary goals and framework from the outset is key. Projects implode “because people don’t understand them,” Creese added. At the same time, following a strict plan can also lead to disaster, if the plan isn’t adaptable to changing circumstances.

Find the Right Manager

Despite the risks of failure, Jim Johnson, “Chief Dreamer” of the Standish Group, suggests there are “more successes than failures” when it comes to tech projects. The bigger and more complex the project, the greater likelihood of failure, he noted: “There are so many fathers of the project that they tend to be in conflict with each other… you end up with delayed decisions, reversed decisions and poor decisions.” Hence the need for a “good sponsor,” which Johnson defines as “an executive with inspiration, creativity and know-how to deal with people and the knowledge on how to make quick and lasting decisions.” The concept of “the good sponsor” emerged from the thousands of projects examined by the Standish Group in its search for the common factors of success or failure. “There was a direct correlation between executive sponsorship and the success of large projects,” Johnson said. “One big trait is that they [good sponsors] have is to be decisive. You don’t have to be a good person to be decisive. You have to be concrete about it.” A good sponsor is typically not a tech person, he added: “They don’t have any empathy for the people who use the system… If the user [doesn’t] know how to use the system, the system fails.” Creese echoed these sentiments, although he preferred chief digital officers as the ultimate overseers or sponsors of tech projects. In his conception, the CDO works alongside the business leaders to design the platform or service, based on current opportunities presented by the technology. After that, the CDO passes off the plan to the CIO, who is responsible for the implementation and delivery of the solution.

Method in the Madness

Regardless of which executive heads the project, their process is important: methodology can make or break a project. As Creese looks at it, ideal methods must combine discipline with flexibility. Discipline restrains the manager from trying to change everything, while flexibility means knowing when to change. “Be wary of methods,” Creese warned. Business books are full of advice, and “they have lots of useful bits.” Soak up the ideas, but remember there is no strict plan or recipe that one can follow to craft a successful project. “Use experience, common sense and intelligence.” Handling an IT project demands a lighter touch than command-and-control, top-down management. For maximum responsiveness and flexibility, the team must have a degree of autonomy. Upper management must impart a clear vision of goals, and then back off. When the Standish Group looked for correlations between method and success in a massive five-year study, it found that Agile methodology worked twice as well as the more top-down directed Waterfall, which spells out every cascading step of a project. Agile accounted for an 18 percent success rate for large projects, compared to a 3 percent success rate for waterfall. Another key metric: Agile only failed 23 percent of the time for large projects, whereas Waterfall’s failure rate amounted to 42 percent. (Both methods resulted in “challenged outcomes” roughly half the time.) The big difference between Agile and Waterfall is that the former embodies feedback, while the latter makes do without it, Johnson explained: “You go through the steps [with Waterfall]. Unless you get the steps right, you screw up.” In Agile, solutions are built, tested and tried, frequently incorporating changes based on user feedback. It’s a faster process that depends on smaller teams. “Agile has an embedded project owner,” Johnson noted.

Beware of Humans

“People make dumb decisions, especially groups of people,” Johnson said. “Time is the enemy of all projects,” he said. Keeping teams small and empowered enables a company to make quick decisions about a project; latency kills the likelihood of success. “This is always a human issue,” Creese added. Projects fail “because people don’t understand them.”