One of the most important questions at the start of a custom software project is “how much will it cost?” This isn’t just a question that you need answered, it’s a question that a responsible development team needs answered as well. Everyone should play an active role in this.
Why? Because it’s vital to make sure that you have enough budget to develop a viable software asset.
When your software project is just getting started, the difficulty of setting a budget is at an all-time high. At this point in the process, everyone involved is at the “maximum point of ignorance.”
- Requirements haven’t matured yet
- The scope may not be fully defined
- Users have had a chance to give their input or be
- Technical requirements may still be in flux
This is why RFPs aren’t an effective way for determining costs.
But have no fear. Almost all projects are loosely defined in the beginning. It’s okay to move forward as long as your development team has a methodology for refining the scope and budget along the way, prior to development.
Determining Potential Value
Custom software is an asset. Like any asset, it’s important to determine the potential for the software to do one of two things:
- Generate profit or
- Save money
In other words – will this custom software help drive revenue or drive efficiency or both?
Refining the scope and budget to an acceptable range will cost time and money. Knowing that the potential reward will outweigh the costs is important in determining whether the project is viable or not.
Making an Early Estimate
After we get a clear understanding on the project’s value, potential ROI, and refine the scope a bit, we will size up the project and provide you with a ballpark estimate.
We’ll use early requirements, high-level conversations about feature sets and business goals, historical data from previous projects, and our intuition to estimate cost at this stage. Keep in mind, this is when the estimate for your project will be at its broadest.
We start by dropping it into a broad bucket (shown below):
Next, we’ll try to tighten up the range by saying, “Your project will definitely cost $75,000, but probably won’t go over $125,000.”
If the initial ballpark estimate is too high, we can revisit the requirements to make sure we’re aligned with scope expectations. From here, we can redefine the scope and estimate again.
Moving Forward with Research, Design & Planning
If the ballpark is acceptable and the viability outweighs the costs and risk then you should look at moving forward with a Research, Design & Planning phase.
This phase helps to further define and refine the requirements and implementation plan. The output is a blueprint for initial development along with a tight budget and schedule. Your project will start to look something like this:
Occasionally, the RDP results in an estimate that is higher than the initial ballpark estimate. This is completely fine. Investing a small amount of time and money to gain knowledge is not a bad thing. Risk has been reduced and we’re more certain after the RDP about the cost of the project and the potential ROI.
Starting Your Project
After the RDP phase, you will decide whether to move forward with development or not.
About 90% of our clients move forward from here. With the budget set and risk reduced, it’s all about a predictable delivery with no surprises:
- We track our team’s progress each week to see how quickly we’re moving through the backlog to determine velocity.
- We track the budget and project final cost all along the way.
- If needed, we negotiate scope to keep the project on budget and on schedule.
It may seem like overkill at first, but taking the time upfront to answer, “how much will it cost?” is worth the time and cost. Having a responsible and realistic budget upfront keeps everyone aligned and focused on shipping custom software that can pay you back quickly.
Remember, find a development team that:
- Has a clear process for refining your budget along the way as requirements get more focused.
- Is concerned about return-on-investment (ROI)
- Is looking for ways to shorten the payback period by reducing unnecessary scope.