The case of incomplete/failed software development projects in Kenya
Quite a number of the new leads for software development that we receive at our firm Trendpro Systems Ltd involve clients who fell apart with their former software developers and left the client with an incomplete project after they had paid them. These clients normally expect that it’s a simple process where our developers can pick up the source code and develop on it to completion with just a little effort. The problem comes in when we realise that their source code is not a standard piece of software which can be scaled or the language used to code is not compatible with what our developers are using or when the client wanted a certain outcome but the initial developer wouldn’t translate it into code and by the time the client was complaining, the developer had to stop the project.
Most software clients have vague ideas whose scope in IT terms, they aren’t aware of (considering they aren’t IT experts) and therefore they can’t clearly define them fully. This is where it requires the software developer or the person in charge of coming up with the project requirement to listen to the client and know what they want their project to deliver and ask the necessary questions to fill in the missing information. They then can convert the clients’ needs into the full project requirements for the development team to work on and as well enable them to develop a reasonable quote for the clients.
Besides that, it’s also a good practice that we require of our software developers to try to spec out what the User Interface should look like after they have received all the project requirements so that they can articulate all the assumptions that may be existing on both models or other details that might have been missed out. This way we greatly improve the completion rates of the projects that we undertake.
In the case of startup companies who have an idea which doesn’t yet have a paying customer, you can’t fully talk about developing such a project as a product because you don’t know in a advance what feature(s) the market will applaud or reject. Therefore, we like to approach such cases with a ‘requirements discovery’ approach where we design a minimum viable product with basic functionality and let our clients put it to test with their beta clients who can then give us feedback on what to keep and what to discard and we keep building on that.
Another practice that we have adopted is the incremental development approach where we break down the project into a 1-2 weeks milestones which we deliver within that period to allow the client to test and re-evaluate and give us feedback of any changes before we proceed. This agile development approach makes it possible not to define the whole project upfront but create a small part of it and iterate. This helps us not to do like a 3 months work of development on the wrong track and we get valuable feedback from customers as we develop.