The Number One Reason Software Projects Fail

I’ve worked for a few companies in my time. There have luckily been a number of successes, but unfortunately, also a few failures. This includes both startups that fail to gain traction, and projects inside enterprises that are cancelled.

There’s obviously many reasons for failure but in my experience most of them can be distilled down to one of these three. And ultimately, there’s one overarching theme that they all have in common.

Exceeding time limits

It’s not very often that a software project is cancelled because it’s taking too long. Given the amount of time and money that will normally have been invested by the time a project hits that due date, it’s better to keep going and be a little late than give up and eat those sunk costs. Smart planners build leeway into their schedules because of this. That being said, the longer a project runs over deadline, the higher the likelihood that the client will decide to cut their losses.

Moreover, any project deadline based on external events can result in a project being cancelled. Some projects are based on seasonal deadlines; others are based on social deadlines; still others are based on how over-enthusiastic the marketing department was feeling.

Other times, a potential opportunity has been spotted so marketing and technology spring into action simultaneously, with code and strategy developing in tandem. Unfortunately, the opportunity passes or the strategy just wasn’t right, and the project is cancelled.

A good example would be a website designed to help people find Christmas gifts, or perhaps a booking website for a fundraiser dinner. These sorts of projects have to be completed in advance of the events for which they provide services; the code built for recurring events can at least be shelved for 11 months, but that still means that the project failed.

Another example would be one of those sites designed to capitalise on one internet fad or another. This would be an example of a limited-opportunity project; if you miss the leading edge of a “15 minutes of fame” trend, the code – and the effort that’s gone into writing it – are worthless.

Often, exceeding the time limits themselves aren’t necessarily the death knell for a project, but they can easily lead to the next big problem: exceeding budget limits.

Exceeding budget limits

Like time limits, just because a budget limit has been exceeded doesn’t mean the project will be stopped. Software development is notoriously hard to estimate; as a result, budget limits are often soft. Most of the time, it’s better to slightly go over the limit than to kill the project and lose everything.

There aren’t many cases that come to mind where a project has been cancelled purely due to the budget being unexpectedly overrun. Normally, the correlation between development time and costs lead to both time and money going overboard at the same time. Only when it becomes evident that the running costs are going to be too high going forward have I seen projects stopped purely due to budget overruns.

For example, let’s say that you’ve developed a web system that, when prototyped, shows that one server will handle 1,000 simultaneous connections, at a price tag of $X. Unfortunately, we’ve only budgeted $Y for this (where Y is much less than X).

At this point, we can either:

• spend more time and money on trying to optimise performance of the program;
• work out how to increase the budget so it's greater than Y.

More often than not, projects in this situation end up being canned. Sure, increasing the budget is an option, but is it a good option? Exceeding the limits (time or money) are more of a symptom of a problem than a problem itself. We need to ask why these limits are set in the first place.

So what’s the third major driver for software project failure?

Apathy

It’s a broad word to use, but I think that this is the simplest way to describe the third reason why projects fail: no one cares.

Usually this means people don’t care enough to actually use or pay for your product. You can’t have a budget to spend on the product if it’s not making any money to begin with.

Even if you have customers, can you increase the cost of using your product without them leaving? Only if they care enough about it or pay more.

With business projects, there aren’t really “paying customers” as such. However, the project must provide enough value to the company to justify its existence. If the end product can’t save substantial amounts of time and effort, bring in more clients, protect from litigation, or otherwise make life better in the workplace… well, no one will care enough to use it, unless you force them to.

So what’s the solution? Try to convince our hypothetical end-users that they should care more? Good luck with that. There are ways to lower any resistance to using the end-product, most of which come down to making the product as intuitive and user-friendly as possible. Good User Interface design can and has saved projects before. But “lack of opposition” isn’t the same as “active enthusiasm”. How can we actually attract our clients’ interest?

So what’s the Number One Reason?

Out of these three major causes for project failure… well, there isn’t any easy way to point and say “this one”. There are hundreds of thousands of projects taking place at any one time across the globe, and most of the unsuccessful ones are never talked about outside of their producers. So there aren’t many accurate figures available. Beyond that, budget and time overruns kill projects before they’re completed, while apathy kills them after they’ve been produced and released.

There is, however, a common thread that links all three. Not enough time, not enough money, not enough interest. The commonality is “not enough”. The question then becomes: should they have known that there wasn’t enough? And if they didn’t, then… why didn’t they?

Well, sometimes, life just gets in the way. The current issues with COVID are a perfect example of how massive disruption causes companies to tighten their belts and focus on staying above water in the immediate future. But far more often, the problems that derail projects are ones that could have been foreseen with prudence and forethought. In short, the Number One Reason, the one that encompasses all three major causes, is insufficient planning.

Ironically, one solution can be to fail more!

Fail faster, fail more

The scientific method can be summarised as: make an observation, form a hypothesis, and then test that hypothesis to prove or disprove it. What rarely makes it into the summary is that the best way to test the hypothesis is not to test for success, but to test for failure. When you’re testing your hypothesis, you should try your best to disprove the hypothesis. If you can’t break it, can’t disprove it, then you’re onto something.

The same principle applies to project scoping. If you’ve identified an opportunity, a need for something, then the very first thing you should do is try to prove or disprove that need, with a slant towards the pessimistic.

Let’s say that you’re suddenly struck with that spark of brilliance, but rather than pressing ahead full-blast on making it a reality, you’re struck with a dark thought. What happens if you can’t find customers? Well, you could dismiss such pessimism, make the thing anyway, and assume that clients will be wowed by such a brilliant product… or you could ask around, try to see what other people think and whether they’d use it.

Well, the process might go something like this:

Awesome, we failed!

Wait, what?

As it turns out, the answer you get back is: no, they wouldn’t. Which is a real downer; your idea’s crashed and burned before it even left the ground. But you know what? If those people were right, the project would have failed anyway, suffering “Death by Apathy”.

At least you know now before investing (or wasting) months of time and piles of money in something that would have ultimately been unprofitable. At least now you can cross that idea off your to-do list. And who knows? Maybe you’ll find a niche somewhere down the line that your idea can fit into. In the meantime, there are so many other things to do.

Let’s say that you’ve gotten a different result. You’ve shopped around, and found a few clients who like the cut of your programming jib. You’re confident that this project’s a winner! What’s next?

There’s a lot of argument out there about the merits (and demerits) of agile development and the two-week sprint; however, it can be a useful approach to quickly discover which projects are going to fail, whether from lack of interest or lack of focus.

Too often, the software development process goes like this:

Don’t assume that initial interest will convert to eventual profits. Maybe those potential customers will have found other solutions while you were working. Maybe they’ll have fallen into dire financial straits and can’t afford your solution. Maybe they just wanted “good enough”, and all the extra features of the Perfect Solution dissuaded them. Whether it’s due to loss of interest or change in circumstances, perfectionism can become the enemy of good.

It’s much better for the chain of events to go like this:

This is the Minimum Viable Product approach, which is common parlance in the startup world. The key word here isn’t “Minimum”, but “Viable”; the objective should be to identify the one part of a proposed project which will bring the greatest benefit to your client… in the short term. Focus your efforts on that one part, and once it’s up and running, deliver it to the client labelled as “Phase One”.

The ideal outcome here is for the clients to raise their own enthusiasm. If the product is right there doing exactly what it’s supposed to, saving time, money and frustration, and generally being a boon to the workplace… and then the staff hear that it’s going to get even better in the future? You bet there’ll be interest in keeping the project going.

Beyond that, splitting your project into phases and budgeting separately for each phase means that you can quote lower budgets and shorter timeframes to your clients, at least on paper. The total for all phases of a project may be higher and/or longer, but clients tend to be happier when they’re getting progressive returns on their money.

Find your customers and build just enough of a product to make them happy and keep them interested. Then, while making sure they’re using the system, build upon the initial project stages. This lets you satisfy and benefit your clients while retaining their patronage long-term.

This approach of “failing upwards” works just as well – and sometimes even better – in the non-startup world. Can we deliver something to the staff in our business to make their work just a little bit easier – at least, enough that they’ll buy into our new product? Once you have people onboard and invested in the product, it’s more likely to continue being used and succeed in growing into its full potential.

But how do we validate the components of a project? What is the best way to identify the MVP?

Validating the product

As happens so often, the answer is “it depends”. There are many methods that one can take to identify a MVP and promote interest.

• Set up an online landing page for selling your product. Collect email addresses so you can let users know when your project goes live. Set a goal for a certain number of email addresses (and remember that not every email address will convert to a sale). When you hit that number, start building!
• If you have potential or existing users that you can talk to, you're already at a huge advantage. You can make a wireframe or mockup of your proposed user interface to help explain it to them. Perhaps they'll even give you some feedback to help refine the product.
• Build a super-basic prototype for your users. What's one thing you could do to make their lives easier? Perhaps your customer signup process involves staff having to copy and paste 50 different things from one spreadsheet to another. Could you build a system in a couple of days that automates the copying of ten of those things?
• Have a great idea for an app/website? Test the waters manually first, before you try to automate it. If you've got an idea for a site that tells you the cheapest place to have lunch today, try finding that information manually and posting it to a social media page at 11AM each day, to see if anyone responds. Once you can determine whether it's got a viable following, consider how you can automate the process.

There’s a ton of different ways you can validate your product before you start building. Remember that in a way, you want to fail, but you want to get that negative result early on, before you’ve spent a lot of time building something that’s going to get thrown out.

That way, you can keep your time and budget in check and know in advance if your project is going to result in a blow-out.

It may sound strange, but, at Tera Shift, we’d love to see you fail upward. Well, we’d love to see you succeed more, but we can also get you started on developing an MVP solution. Once that takes off we can work with you to flesh out the entire product. If it doesn’t, we’ll help you pivot or refine to help you get to success.