How to manage risk in a software development project

3rd April 2018


We all manage risk as a daily part of our lives. From deciding to overtake a slow car in front of us, to investing in the stock market - we are always calculating risk.

Building and investing in a software project is no different, yet it is amazing how often risk isn't taken into account when entrepreneurs start out developing a new application.

This article will highlight some of the steps which can be taken to reduce risk when investing in a software application.

Get an accurate estimate in the beginning

When building a house, the first process is typically to engage with an architect. The architect plans and designs the building and even helps to give an overall ballpark estimate for the cost to build the house. It is commonly accepted that this is a vital first step in the building process.

Why then, when it comes to software development, is this step so often missed? Often an agreement is reached on an hourly or weekly rate with a developer and code starts to be written, usually with little thought on planning and without consideration of the overall cost.

Yes, it can be difficult to accurately estimate software costs, but it certainly isn't impossible. It is more than reasonable to at least get a ballpark figure to determine if the cost of investing in the software project is worthwhile.

I've been in situations where I've estimated projects for entrepreneurs where upon reviewing the full requirements, the software was a lot more complex than initially thought. By taking the time to work through this process, it allowed the entrepreneur to get a feel for the time and cost to build the application and they were able to make an educated decision on whether to invest in the project or not.

There is no magic eight ball, but taking the time to invest in this stage can give guidance to whether the project will be successful or not before a single line of code has been written!

Like blueprints supplied by an architect for a builder, a well written specification also helps give clear guidance to the development team early on so that they can see clearly what needs to be written from day one.

Pay per feature or fixed pricing

It is all very well to get an estimate for developing software, but there is still a risk when it comes to developing the software.

The software development industry is somewhat unique in its love of hourly billing. Freelancer marketplaces and contract developers typically bill by the hour.

But there is a huge risk in hiring a developer on an hourly rate basis. For starters, it is very difficult to know if you are getting good value from an hourly rate. Is $10 an hour good value, or $50 an hour, or $100 an hour.... it really all comes back to how much is produced in one hour’s work to determine if one is getting value or not.

You might think you’re getting a great deal hiring a developer for $10 an hour, but not if they are eight times slower than the developer for $50 an hour.

Other industries work off either a fixed price or a price range - e.g. your doctor will charge a fixed price per consultation (no matter how long the consultation actually takes), or if you’re getting your house painted, the painter may quote a price range, e.g. $300 - $500 for the whole project. You can at least budget accordingly knowing the price will fall somewhere in the middle.

Yet when hiring developers, the typical billing method is on an hourly basis. This makes it very difficult to stick to estimates when the 'tap keeps running' so to speak.

It also means that the entrepreneur is taking all of the risk. Hourly billing is actually counterproductive - it gives the developer zero incentive to complete a feature more efficiently.

Therefore, when hiring a developer, challenge them to offer either fixed price billing or giving some sort of ballpark which they need to stick to.

Alternatively, if your developer insists on hourly billing, be sure to ask for any estimates upfront and challenge them to ensure work is delivered within the agreed time frame.

Put together the right development team

There are so many different programming languages and frameworks that it can be difficult to know what tools should be used to build a software application. Often this decision is left to the developer, but there is a risk then that the developer may choose a language or framework for reasons other than because it is the most efficient way to develop your project.

Knowing the right skill sets which will complement a development team can be difficult. When expanding your development team, it is important to first look at the skills your current developers have and identify what skills are missing. Your hiring process should always be around finding and closing gaps in the overall skill set of your team.

In practice, it is often not the way a team is built, however. The focus is often on replicating a team member’s skill set. By focusing instead on filling the gaps within your team, you will build more balanced team and tasks can to be assigned to developers depending on the project’s actual requirements.

Use roadmapping to break the project up into phases

Roadmapping is a hugely effective but often overlooked technique to ensure that tasks are broken down into an order of priority, this is particularly helpful when building a large software project.

A fully developed specification can often be extremely overwhelming for even the most experienced developer. By breaking down the features into priorities and grouping the tasks into phases, it will allow for more accurate estimates of features, will ensure the project is built in the right order and will also mean a stable release as each phase is completed.

Apply an MVP approach to the required features

I've written a separate article about MVP development, but the basic premise is as follows:

Build only what you need to build today, to get the software to the next stage.

The idea here is that when reviewing the requirements of a feature, the development should focus around what will impact on the current software use.

If a certain part of a feature won't have any impact today, then it should be held off and developed at a later stage.

This will save significant development time while having little to no impact on the actual success of the project!


The steps listed above cover some of the ways in which you can limit the risk when investing in a software application. While it is impossible to eliminate all risks, following these steps will greatly improve your likelihood of success.

If you’re currently managing your own development team or thinking about investing in a new project, try these steps next time and let me know if it makes a difference in performance and cost.

Finally, if you need help with implementing any of these steps, then reach out and let's see if we can work together to make your project a success.

My name is Michael Houghton and I have been helping companies build rapid software applications for nearly fifteen years.

Are you an entrepreneur currently developing a software application? Subscribe to my newsletter below and I will send regular emails on how to make your software project a success!