How Not To Kill Your Software Project23rd April 2019
Tons of software development projects tend to fail after launch for various reasons, of which the primary one is the lack of clear goals. Another almost equally significant but underestimated cause of failure is that a considerable number of these startups were solving the wrong problem.
This situation is like a case of going a hundred miles per hour in the wrong direction and is quite common in the software development industry, but often binned under the ‘incompetence’ category (although, admittedly, that does play a role in some cases). It is an issue of poor communication between the parties involved.
An ideal project would mean that all the organization’s staff at every level, as well as the target users, would be utterly convinced about the need to product and its ability to solve the specific problem. This means that the CEO, VP of Marketing, VP of Operations, and every other staff or team member share the same sentiment about the project. This ideal scenario is rare.
In the real world, on the one hand, the CEO might be gunning to develop a robust app that does its job perfectly, while the marketers might not overly care about the functionality, but only be interested in developing or manufacturing a sleek product that looks shiny and marketable. The end-users whose preference matters most, on the other hand, might need a tool that simplifies a daily task for them.
The process of incremental ideation can help software development teams to make sure that everyone has a similar vision for the product. In this process, first, you pinpoint the problem to be tackled. Next, you identify and outline the steps to solving this problem, before you then engage all the team members and get their input to be sure that you are addressing the right issue and going about it effectively. Finally, to be utterly confident that this product will be useful for the end-user, a continuous review process should be adopted, where all the relevant parties continually exchange their views about the product.
However, in today’s world of software development, the product usually has an owner, whose responsibility is to make sure that the product is viewed in the same way by every team member as well as the end users. The product owner also ensures that this continuous review process helps the developers not to deviate from the plan but stay on track throughout the development process. This communication, however, is most effective when it happens naturally instead of one that is planned and formal.
The role of communication and regular feedback cannot be overstated. It is so crucial that the Agile Software Manifesto enshrines it as their most critical foundation value — “Individuals and Interactions Over Processes and Tools.” A development company that prioritizes communication between individuals has a high probability of creating a product that meets the needs of its end users. If this process of incremental ideation is followed and everyone is on the same page, then if for nothing else, you would at least avoid the awkward situation in a meeting, for instance, where a client interrupts you to say something like “but I thought you were going to …”
Hopefully, this write-up helps you not to repeat my mistakes. Remember to keep shipping!
How Not To Kill Your Software Project was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.