The Biggest Reason Why Software Development Projects Fail Is a Poorly Defined Outcome
10 reasons why Software Development projects fail 1 of 5
--
But I’m here to tell you that the real reason why software development projects fail is not due to a lack of talent or a lack of resources, it’s due to a poorly defined outcome. If you don’t have a good idea of what the final product is supposed to look like, how are you reasonably supposed to produce the right final product in the end?
Think about the following hypothetical for a second. If you get into your car, don’t you always know where you are supposed to wind up in the end? You might not know the exact route you are supposed to take (leave that to the GPS to figure out!), you might not know how long it will take you to get there (accidents and delays are a fact of life), and you might not even know if you have enough gas left in the tank to make it to the final destination without stopping for fuel, but you do know one very important detail: the final destination.
You can use this analogy to guide your thinking about any large-scale software development project. In this case, your GPS is your project specification sheet. It will identify what the final outcome will look like, what the product will do, and how it will do it.
And, just like your trusty GPS, it will suggest a number of different alternatives that are available. Do you want to take Path A, which will get you there in 3 months? Or do you want to take the much more circuitous Path B, which will most certainly NOT get you there any earlier than 3 months? Yes, there are bound to be delays along the way, roads closed for no apparent reason, and maybe even an unexpected toll along the way (if you live in the Tri-State region around New York City, you know what I’m talking about) — but you will have a very good idea of when you will arrive at your destination.
So the next time a colleague starts complaining about a failed software development project and vows to hire a better team of programmers the next time around, take a deep breath and ask the following question: Did you define the outcome of the project properly at the outset? 99 times out of 100, I can already predict what the answer of that question is going to be.
Why Solving the Wrong Problem Is Guaranteed to Ruin Your Software Project
If a poorly defined outcome is the №1 reason why software development projects fail, then a close №2 is solving the wrong problem. This is a particularly insidious problem because you might have just spent a few weeks working on little to no sleep and consuming dangerous amounts of caffeine, only to realize that your project has dangerously gone off the rails. You thought you were supposed to solve Problem X, but you were really supposed to solve Problem Y.
So why does this happen far too frequently in the software development industry? It’s too easy to chalk it up to sheer incompetence (although, surely, that does play a role in some cases). No, a better answer might be a lack of proper communication between the different stakeholders in the project.
In the best of all possible worlds, of course, there would be complete buy-in on the problem being solved by the software project at every level of an organization, and across all different functional units. In other words, the way the CEO views the project is the same way the VP of Marketing views the project, which is the same way the VP of Operations views the project, and so on, down the line.
But how often is that the case? The head of marketing may want a product that looks great when photographed for Instagram (but is way less concerned with overall functionality), the CEO may want a product that is going to become the new “killer app” of the industry, and the end user — the person who is actually going to be using this product — just wants a new tool to help them do their job better on a daily basis.
One way to ensure that all team members are on the same page is via a process of incremental ideation. As part of this process, you first identify the core problem, then outline what steps you can take to solve it, and then commit to regular communication with all team members, in order to make sure that you are still solving the right problem. By constantly interacting with all parties involved via a continuous review process, you can ensure that the project is properly adhering to the needs of the end user.
But here’s the thing — somebody needs to “own” the project. In the agile software world, for example, that’s the “product owner.” It’s the responsibility of that person to ensure that everyone is using the same language to describe what’s needed, and that team members are constantly asking questions and communicating with each other to ensure that they are really building what they set out to build. Communication needs to be fluid and happen when need arises, rather than being scheduled in advance.
In fact, the role of communication and continuous feedback is so important that it is enshrined as the most important foundational value of the Agile Software Manifesto: “Individuals and Interactions Over Processes and Tools.” If you are valuing individuals and interactions, then you are more likely to meet customer needs. At the very least, you won’t have to face the awkward situation when a client interrupts you at a meeting and says, “But I thought you were going to…”
Hey! I’m Tomer, an entrepreneur and maker. You might know me from Mevee, Crane, and Shots, among other products I’ve launched! This article is a part in a larger series I’m writing mostly based on my experiences, and is largely made of my and my team’s opinions.
I hope this helps you to avoid making the same mistakes I did, and remember to keep shipping!
This article is part of a series 10 reasons why Software Development projects fail :
- System Requirements Can Bring Any Software Project To a Screeching Halt
- Hey, Who Moved the Goalposts?
- What We’ve Got Here Is Failure to Communicate
- Poorly Defined Outcome
- “Your app will be finished on Tuesday.” — which Tuesday?!
