Getting an accurate budget estimate for a software project isn’t easy. It’s hard to say exactly how long it will take and what it will cost before doing the coding. Poor budget planning often results in unexpected overruns or a need to cut the project back to fit the available funds. In the worst case, a project fails because there isn’t enough money to bring it to completion.
With good planning, you can reduce these risks. You can get a better idea of how much the project will cost and avoid surprises. A more accurate budget estimate means a more accurate time estimate too, so you have a better idea of when the code will be available.
Preparation
Step 1: Define your requirements.
The first step toward an accurate budget is defining your target with the right level of precision. This doesn’t mean spelling everything out in exhaustive detail. Too little detail leaves you open to major surprises, but too much detail drags a project down and can make it cost more.
Almost all software development today is an agile, iterative process. Trying out early versions will lead to changes. The requirements list should focus on results, not on how the software will get there. It should specify what needs to be done.
If you’d like some features, but they aren’t absolutely necessary, break them out. You can decide after finding out how much they cost.
It isn’t necessary to include everything you will want in a project. Leaving some features for Version 2 will keep the cost down, and the specs for later revisions can take advantage of your experience with Version 1.
Step 2: Break the project into phases.
Breaking your project down into phases will help to make costs predictable. Defining the phases requires working with the developer.
The first phase should call for a prototype, a demonstration version, or a minimum viable product (MVP). Its cost will be reasonably predictable and make sure that the customer and the developer are on the same page. It’s likely that the requirements will need some revision after reviewing this phase.
Let’s take a moment to distinguish those three first-phase items. A prototype is code which includes some of the features and user interface but isn’t usable for production. A demonstration version shows how the user interface works but doesn’t necessarily carry out any work. An MVP really works, though it has only a bare-bones set of features. All of them have their uses.
Subsequent phases will add functionality. Each step should present something usable, though not complete. Reviewing each one can result in some additional revisions, helping to make sure that what you get is what you want.
At the end will come alpha and beta testing. This is the time to make sure everything works as it should and any bugs are fixed.
Translating requirements into cost
Step 3: Get an initial cost estimate.
If you’re contracting with an outside developer, they’ll give you an estimate of how long the project will take and what it will cost you. If it’s an in-house development team, they’ll tell you how many people they’ll put on it, how long it will take, what outside resources they’ll need, and what that will cost the company.
The estimate may take the form of a range, from the most optimistic to the most pessimistic results. If you designated some features as optional, you should get estimates of what it will cost with and without them.
Step 4: Review the estimate.
Now you have to decide what to do with it, and what it will mean as a cost to you. If you get a range, the three-point estimate formula will be helpful. This formula is:
E = (o + p + 4m) / 6
where o is the optimistic estimate, p is the pessimistic one, and m is the median or most likely estimate.
The developer’s price tag isn’t the only cost. You need to include the time and travel costs for your people in reviewing the job’s progress, evaluating each phase, and testing and signing off at the end.
Compare the estimate to the cost of previous projects of similar complexity. If it’s higher, ask why. If it’s a lot lower, check if the developer fully understands what’s involved.
If you don’t like the estimate, you can ask about alternative approaches. Don’t try to talk the developer downward without making concessions; that will just get you a less realistic estimate.
If you have opened the project to several bidders, compare their figures. The risks of going with the lowest bidder are well-known, but if one comes in significantly lower than the others, there may be a reason, such as their having a lot of experience with what you need. Judge the credibility of the estimate as well as its cost.
Step 5: Set your budget.
Once you have an agreed-on set of requirements and a quote, you can set your budget. Be sure to include all anticipated costs. Besides the developer’s quote, the costs include:
- Time and travel for interactions with the developer.
- Time for reviewing each phase and deciding how to proceed.
- Hardware or cloud requirements.
- Final testing.
- Have reserve funds available in case the project runs over. It’s better to spend a little more than to have to cancel everything for lack of funds.
Following through
Step 6: Work with the developer through the whole project.
The job isn’t done when the contract is signed. Each phase requires diligent review, and it will affect subsequent costs. Sometimes progress will cost less than expected, in which case you can either bask in the savings or add some optional features. Sometimes it will cost more, and you need to tap the reserve or cut back on the deliverables. Flexibility is important in software development.
In brief: Lay out your requirements in advance, but be flexible on details. Don’t go overboard on the first version. Remember that development is an iterative process and will require an ongoing process of review. Recognize that changes may be necessary along the way. Do all this, and your software development budgets will stay closer to reality.