We do a lot of things when we meet potential clients. Assuming we mutually determine that Atomic is a good match to the project, the conversation eventually ends up at how much the project will cost. The shallow answer (“as little as possible”) is correct, but not very useful. We put the following outline together to suggest a more actionable approach that avoids a major risk and achieves the goal of maximizing the product created for our client’s investment.
Know the impact of your project
Our clients generally build software to generate revenues or reduce expenses. If the client doesn’t know how much money can be earned or saved by a successful project, then it will be difficult to determine whether the project makes business sense regardless of what it might cost. Building a model requires understanding the business and the project being considered. Sometimes we work as consultants to help with this work.
Get a ballpark guess from your team
We’ve done approximately 400 projects in our ten years of working together. From this experience, and drawing upon the data in our time tracking system, we can give clients a ballpark guess about project size without making a full responsible estimate.
This rough guess will be a broad range, for example, $50-100k. It won’t represent the maximum possible degree of project variability (the cone of uncertainty says that estimation error at this point in a project can be a factor of 16x between under and over estimation). The range of our ballpark guess is much tighter (only a factor of 2x, say) because of what we’re assuming about how we work with our clients. We’re not really trying to estimate how big the project could be—that would be irresponsible at this point. Instead, we’re guessing based on our prior experience at how much money will be required to work collaboratively with the client to build a viable product.
Secure funding for 150% of the ballpark guess
If your analysis of the revenue generating or expense saving potential for the project doesn’t indicate a satisfactory return in the event that you spend 150% of the ballpark guess, you should kill the project. It’s much worse to spend too little than it is to spend too much. Setting the project budget to the 150% mark doesn’t mean you have to spend the money, but it does protect you from the disaster of being undercapitalized. Investors know this idea as “keeping some dry powder.” They anticipate the need for future rounds of funding, and recognize that the first round may be wasted if there’s no way to get to the second round.
Set a development budget below your project budget
A fixed budget focuses both you and your team on the hard work of defining and building the smallest possible product that delivers value. You’ll need to make hard choices about scope. The team will need to offer creative alternatives and tradeoffs. Keeping the development budget below the project budget creates a constant force pushing you to build less and release sooner. Once you release, if you learn from users that you need to add important features, you still have project budget.
Build the smallest possible product that delivers value
Assuming you’re confident enough about the market or the need to build and release a product, i.e. you’re not following Steve Blank’s customer development strategy or using the technique of minimal viable product, then you need to do the hard, creative, and challenging work of figuring out how little software you can possibly build that, when deployed, will deliver value. A big part of that is getting to real users as early as possible. If you don’t have this confidence, you should consider using a technique like customer development.
Build to budget
Work with your team to get the most possible features, and the most important features, built for your budget. In theory it shouldn’t matter how you do things if you can build that smallest product and hit the fixed budget. In practice, we believe you increase your odds of success if you do some work up front, deliver tested software every week, decompose and estimate smallish tasks, and track your velocity to forecast completion and cost.