Most Software Projects Fail — Make Sure Yours Don’t
Here’s a sobering fact: Most software development projects fail.
According to a report by The Standish Group, 31.1% of projects will be cancelled before they’re completed and 52.7% of projects will run over budget by nearly twice as much as originally budgeted.
These numbers are startling. You can choose to ignore this harsh reality and simply hope for the best. Or, you can seek to understand the causes for failure and then take steps to improve your chances for success.
A Classic Perspective: Cost-Time-Quality
What are some possible explanations for why most software projects fail? I’d like to highlight two long-standing perspectives that are a bit limited and outdated, but still worth acknowledging.
The first is the “cost-time-quality” pyramid, which is frequently cited when a project is running behind schedule. The typical refrain from the hapless manager: “Well, you know, pick two.”
While the cost-time-quality relationship has some validity, it doesn’t fully explain why a project that initially looked to be successful is now on an unsuccessful trajectory. Further, it’s about as helpful as the engineer pointing out Newton’s law of universal gravitation after the rocket blows up on the launch pad. It doesn’t offer a solution.
Another Classic Perspective: Brooks’ Law
First published in 1975, The Mythical Man-Month: Essays on Software Engineering is another commonly cited reference. The collection of essays was written by Frederick Brooks, a software project manager for IBM’s OS/360. The illustration on the cover shows dinosaurs stuck in a tar pit. The more you struggle, the faster you’ll go under.
Brooks dissects an interesting observation that adding more engineers to a late project doesn’t accelerate its completion. In fact, it makes the project run longer.
Brooks offers compelling arguments for prototyping, over-communicating among team members and the power of a handful of great engineers (vs. many mediocre ones). Unfortunately, The Mythical Man-Month is terribly outdated. The book deals with mainframe computers and predates modern tools, design patterns and reusable code. In my opinion, it’s no longer relevant and not particularly actionable.
A Modern Perspective: Biasing for Success
I often say that the key to a successful customer is a customer who wants to be successful. In my experience, the primary determinant for a successful business is strong executive leadership.
The executive’s top responsibility is to bring clarity to the team. For software projects, this means defining success. With that understanding, teams can quickly decide what’s important and what’s not.
For example, let’s suppose a company is focused on releasing an MVP (minimum viable product). Usually, the underlying purpose is to prove a point to investors and unlock the next round of funding. If that’s true, then what’s the most critical thing to demonstrate with the MVP? Is it adoption/number of downloads? Stickiness/same-store sales? Efficacy/the ability to move the needle on a customer’s KPI?
The ability to define success provides the organization with a huge advantage.
Additionally, the value of relevant technical experience also cannot be understated.
The combination of powerful, low-cost cloud computing services (like Amazon Web Services and Microsoft Azure), libraries of reusable code and generally accepted design patterns allow software products and software companies to be created almost instantly. If you don’t want to be left in the dust, on-the-job training simply isn’t an option.
Recruiting the best talent is so important, and the best talent is often a combination of skills and relevant experience. You can’t waste time reinventing the wheel or having someone make rookie mistakes. For instance, when building teams in the digital health space, there’s a classic question: Do you hire the best engineers, or do you hire the best subject matter experts? The answer is, you hire the best engineers with digital health experience.
Separately, the best teams have frequent progress reviews and constant communication. If your teams haven’t embraced Scrum / Agile methodologies, then you’re taking on a lot of risk. By modern standards, two-week “sprints” (Scrum parlance) is a common development iteration that helps keep teams moving forward.
Note: Hosting daily “standup” meetings is a great start to enhance communication, but doing that alone isn’t Scrum. Demos, retros and all the key Scrum ceremonies are critical to ensure all stakeholders are informed and empowered to make course corrections when needed.
Testing and QA are fundamental, and the best teams invest in them. QA needs to be staffed appropriately — and at the beginning of the project because QA brings a critical perspective on what’s to be built.
Another common question/debate: What’s the ideal QA engineer-to-developer ratio? In my experience, one QA engineer to three coders produces great results — especially when test automation is in place. In many situations, this ratio helps maximize velocity and also ensures QA is rightfully empowered.
Lastly, software cannot go to production without QA approval, even if it means missing a deadline. If deadlines can circumvent QA, then QA becomes an option and not a necessity.
Cutting off Failure at the Pass
At Newfire Global Partners, we take these failure modes into account with our engagements. We work with executive leadership. We tap into our pool of accomplished, senior engineers with the most relevant experience. We enforce aggressive Scrum / Agile methodologies. And we help build and empower the QA function. All with the goal of ensuring every software project is a success.
