Why Solving the Wrong Problem Is Guaranteed to Ruin Your Software Project
10 reasons why Software Development projects fail
--
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, admittedly, 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 sees 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 wish to 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 addressing the right problem. By regularly interacting with all parties involved via a continuous review process, you can ensure that the project is appropriately 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 always 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 the 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 critical 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 a maker. You might know me from Mevee, Crane and Shots, among other products I’ve launched! This article is a part of a more extensive series I’m writing mostly based on my experiences and is mainly 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 of 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?!
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +422,678 people.
Subscribe to receive our top stories here.
