Why you need to understand the best way to run your software project

There are a few different ways that you can run a software development project. The two main options are agile and waterfall.

[Aside: You can get hybrid approaches, and then there's the laissez-faire approach, which is basically just ‘anything goes’ and there's actually no methodology at all (an approach we don't recommend).]

AGILE

With agile you don't necessarily have the full set of functional technical requirements when you begin the project. Instead, you iterate through a series of sprints towards your objectives.

This approach provides flexibility. If, as you start the development, new requirements are uncovered or you realize that what you're developing is actually not quite fit-for-purpose, you can change it during the project in order to get what you want and what you need at the end.

With that flexibility, the trade-off is that you don't get budget certainty. Typically, with agile, the kind of estimate that would be put forward for a project would be: "well, based upon these functional requirements that we've seen, and based upon what we know right now about the project, we estimate that it's going to take between six and eight sprints." That gives you an upper and a lower boundary for the budget, but it doesn't give you budget certainty.

What can also occur is that, even though an estimate based upon the functional requirements provided has been given, if new requirements or features are discovered during the course of the project that were not estimable at the beginning, the quoted cost could exceed the upper limit of the original budget.

WATERFALL

Conversely, with waterfall everything is specified at the beginning. You will get certainty in the sense of the budget, but you're also getting the outcome locked in stone. If you uncover a new requirement partway through the project, what you have to do is go right back to the beginning and replan the entire thing. If you're not careful, that re-planning process can bring a project to a complete halt. If it turns out upon further investigation or more information becoming available, that it's not going to be fit for purpose then unless you do a complete redo of the planning for waterfall, you will ultimately get something that is not fit-for-purpose at the other end.

Agile or Waterfall?

Which way to go (agile or waterfall) is going to depend a lot on your organization and the tolerance of budgetary movements.

At GistLens, there are some projects that are so uncertain that we simply will not give a fixed price for it and therefore we won't even offer waterfall in that case.

There are other projects which have been specced out in great detail and we have confidence in the requirements, in which case we’ll say ‘here's the waterfall plan: this is when it's going to start, this is when it's going to end, and this is what the fixed price is going to be.’

The key difference

With agile, more of the risk rests with the client, and with waterfall more of the risk rests with the developer.

Consequently, the price for a waterfall project is typically higher to account for that risk than it would be with agile.

How much higher? It can be up to three times higher, depending upon what that risk is. If a project with agile was going to cost $50,000, you might find that with waterfall, it's going to cost $150,000. Depending upon the client, that might be fine. If you want budgetary certainty, that higher price might be worth the cost.

If you’ve got a software project idea that you’d like to discuss a budget for, CLICK HERE to book a time.