I’ve been researching what percentage of software projects fail, and so far I’ve found people reporting that the answer is 14%90%, and everywhere in between. It seems like many people would peg it somewhere in the 60% ballpark, but I think that’s just a gut feeling on their part. No one really knows.

Whatever the actual percentage, software engineers tend to have this impression of high failure rates because they have seen failure first hand.

These failures come in all shapes and sizes.

We’ve all heard the statistic that 90% of startups fail. This can be a form of software failure.

On the other end of the spectrum, in a 2015 report by the United States Department of Agriculture, they revealed that they had spent $444M on a project to replace 66 legacy systems… and they only managed to replace one. (They ended up cancelling the project.)

So why do software projects fail? First, let’s ask, “What does it mean to fail?”

For the sake of argument, let’s assume that for a project to be successful, it has to have a positive ROI. Depending on the project, that can be tough to measure.

However, for the sake of this discussion, let’s also assume that the business provides an easier way to measure success that they believe will yield ROI.

What do I mean by that?

Suppose that you run a distribution center, and products are arriving late to customers because the internal software you are using is clunky and takes too much time to operate. This is leading to complaints and bad reviews, and that’s negatively impacting sales.

A success indicator might be provided by the business to the software team that says, “We need to cut the time it takes to process incoming inventory by 25%.”

Doing so may or may not actually produce ROI, but it’s a trackable metric. With this in hand, the software team can assume that if they hit those numbers, the business will consider it a success.

This simple example actually highlights the first reason projects fail:

Failure to Understand Key Business (or Customer) Needs

In many projects, people never manage to get on the same page about what problem exactly needs to be solved. This can happen for many reasons.

A key reason is that a lot people come into these sorts of conversations with unspoken beliefs and assumptions that never get fully transferred to everyone else. They may believe that everyone else already thinks like them, or they may believe that their opinion is the only one that matters. In any case, true understanding of the problem at hand never emerges.

Let’s go back to our example.

Suppose that the distribution center is managed by a woman named Jill.

Jill reaches out to a local development company called “Jethro’s Dev Shop” to get them to “fix her system”. All Jill really knows is that orders are taking too long to process, and she has been hearing her team complain for a while about how long the software takes to use.

Jethro guarantees Jill that his team can solve the problem. He doesn’t ask many questions, and Jill just assumes that he knows what he is doing.

What Jill doesn’t know is that Jethro just read a book about the ReactJS programming framework, and he now thinks that it is the solution to all of life’s problems. He’s never built anything with it, but he’s excited to get started. Jethro is assuming that Jill primarily cares about having the latest and greatest technology. Why else would she be taking on this project?

Three months and $50k later, Jill sits down with Jethro for a demo. He walks her through a bunch of flashy ReactJS-powered screens that don’t do anything like what she was expecting. (This may sound silly, but it happens all the time.)

What’s going on here?

Jill assumed that Jethro understood her business problem. As can often happen in a sales process, Jethro over-promised, and Jill took him at his word.

Jethro assumed that he knew what Jill’s problem was. Maybe he had a rough idea of what it was, but it was glossed over in favor of implementing a specific technology.

While this is an oversimplified example, I’ve seen on multiple occasions teams spend weeks debating which framework to use when they haven’t totally nailed down what the business need is yet.

What Should Have Happened

The first thing Jethro should have done is pry into exactly what Jill meant by “fix her system”.

Here are some questions he should have been asking:

  • What does she think is broken about it? What are the biggest pain points?
  • Can you take me on a step-by-step walkthrough of the current system?
  • How is the current system impacting the business negatively at this moment?
  • How much money are the problems with the current system costing her business?
  • Has Jill or her team thought of any potential solutions? What do they look like? Why?

There is an extremely common phenomenon called the “curse of knowledge” where someone assumes that everyone else has the proper background information to understand a problem the same way that they do.

Jethro doesn’t know everything that Jill knows, and it’s Jethro’s job to realize that. It’s also his job to do the work to uncover the necessary business background to define and solve the problems at hand.

Before starting on the project, Jethro and Jill should have agreed on what success looks like. For example, they could have agreed that if Jill’s team can manage inventory 20% faster, they’ll call it a success, and anything above 30% is amazing.

This forces both parties to be solutions oriented.

From Jill’s perspective, getting to this point requires her to do a bit of math and figure out how much faster her team needs to go in order to get shipments out the door faster. It also forces her to get really specific about where the bottlenecks in her team’s current work processes are.

From Jethro’s perspective, this forces him to make sure whatever he is doing contributes to hitting that specific target. Left to his own whims, Jethro might prioritize any number of things that he deems to be “better software” than what Jill currently has.

Project Targets

From this story we can extract the idea of “project targets”. I define a project target as a specific, measurable outcome of completing a project. (This is basically the way that IEEE defines the word “requirement”, but that word now means so many things to so many people that I consider it ineffective.)

Setting and tracking progress toward this type of target is a very simple idea, but it’s not always used. Software professionals can get into a state of being highly productive without actually moving toward a target.

By that I mean that they are producing a lot of “stuff” – continuous integration pipelines, automated test frameworks, etc. – but they may not actually be moving toward the correct problem.

Always define your business targets first. Ask these two questions:

  • What does success look like?
  • How will we measure it along the way?

In the Weeds

Realistically, the above discussion is a bit oversimplified. The truth is that every line of code that goes into a product needs to fulfill some kind of business requirement. Otherwise, what is the point?

That means that there needs to be a strong, ongoing dialog between the business and the software development team. This is iterative development, and we’ll get into this more in Part 2.

Need Help?

We are a full service software engineering firm. We can help you with everything from design to project management to development.

Got a project you’d like to talk about? Get in touch at info@centralstandard.tech.