“How much is this going to cost?” I get this question all the time from current and potential clients.
It’s an important question because building custom software is an investment and it should be treated as such. The cost of producing a viable product should determine the feasibility of the project. Sometimes it’s too expensive to build a better solution. Other times, the savings don’t justify the cost.
Unfortunately, it’s too difficult to know how much something is going to cost before we understand it. There are too many unknowns at the beginning of a project: the requirements haven’t matured, the scope isn’t fully defined, or the solution isn’t finalized. And no matter how much upfront work you do to plan your project, there will always be changes during discovery and prototyping. It’s perfectly okay to start a project without a defined scope or budget as long as they are refined throughout the process.
What are the financial rewards of the project?
New projects emerge as a solution to a business problem. What are the profit-generating or cost-savings potential of a new solution? Identifying the potential reward will help us keep things in perspective throughout the project.
Initial Estimation
While setting a budget is difficult, we can start with an initial estimation based on what we currently know. We’ll use the initial project requirements and historical data from previous projects to create an initial range estimate.
Range estimates are an attempt to provide an expectation for a low and high budget range. For example, we might say the project will definitely cost $50,000 but probably won’t go over $100,000. Since there are so many unknowns and too many risks at this point, we opt for wide ranges to ensure we’re setting expectations upfront.
If the range estimate is much higher than expected, we can revisit the requirements and redefine the scope to fall within a more appropriate range. Alternatively, the project may not be worth the investment. In this case, we can move to solve a different problem through a new project where the reward will be much greater.
Discovery
If the initial project estimate is accepted, we’ll move into the discovery phase. Utilizing human-centered design, we’ll focus on refining the scope, understanding users, and shaping our solution.
Product Design Workshop
We start all new projects with a product design workshop, typically 2-3 half-day sessions. The purpose of the workshop is to set the stage for the product and answer some critical questions like what is the problem we’re solving, who are we solving this problem for, and what kind of solution are we creating?
We start our workshops by defining the project charter, which includes our problem statement, timeline, key players, goals and success metrics. This establishes a common understanding of the project at a high level.
We’ll use user journey maps to visualize the activities and tasks that users will engage in to accomplish their goals. The journey maps identify the features and functionality that is required to build a custom software solution. We’ll use this information to estimate design and development efforts to implement these features.
At this point, our team has a better understanding of the project and a visualization of the workflow. Using this information, we’ll refine our initial estimate as needed and begin to tighten up the estimate range.
Low-Fidelity Prototyping
Sometimes more visualization is needed to estimate a project accurately. In many cases, we may create low-fidelity wireframes or mockups to prototype the solution.
Sometimes systems are complicated, and more visualization is required to truly understand the costs of production. In those cases, we will spend a day or two creating low-fidelity mockups or wireframes to assist in estimating. Through the enhanced visuals, we can come to a consensus on the features that we’re building to understand the effort better.
Decision-Making Time
Through discovery, we paint a clear picture of what we’re building and why. We’ve spent money to gain knowledge about the problem and solution. In most cases, the refined estimate falls within the initial range. Occasionally, the estimate may increase as we learn more about the product.
Discovery allows us to reduce risk, though. If we jumped right into the project, we could have spent more money to learn the same thing. Or even worse, we could have built the wrong product. At this point, a decision is made to move forward with the project or not.
In-budget and On-time
We work on a fixed budget, variable scope model. This means that the estimated budget becomes a constraint on the project.
All of the stories to be completed are organized in a backlog that we constantly groom on a weekly basis. All stories are tracked in our project management software throughout the project. We provide a weekly report card that tracks our progress, budget, and overall project health.
Since budget is a constraint, we negotiate scope to keep the project within budget. At the end of the project, we deliver a final release in-budget and on-time.