What is budgeting?
When you’re about to start new project lot of questions arise, but yet "how much it will cost?” is one of the most important ones. Typically, you would be concerned about how much time and money it will take to get the return on investment, or maybe to get a working product to get feedback from early customers.
You would start by listing all the features you want to have in the product and ask engineering team for an estimate of resources and time needed to complete them. But estimates are not accurate, 75% of the projects go beyond the forecast. That means that budgeting through estimation is unlikely to be correct too, though this is the approach used for most of the projects. It is no surprise that their cost exceeds the budget.
Why do you need a budget?
Budgeting is not an easy task, especially if your project has a high level of uncertainty, requirements are vague and are subject to change during development. But still, you need to know the budget to allocate the funds and make sure that the project is viable.
You also need to know your budget to check your current status against it regularly. Where are we within the project? How much time we have before the deadline? Are we on track? To answer all these questions, you need a budget.
Your budget is like a gas tank gauge on the dashboard of your car. You have speed gauge that shows you how fast you are moving, but you also have a gas tank gauge to see how long you can move forward. Then you use steering wheel and pedals to control the process and get yourself where you need to.
How to budget your project?
Guesstimate
The most common way of budgeting software projects is estimating the time needed by guess and then multiplying it by the cost of resources (e.g., work hours). Jeff Attwood, a co-founder of StackOverflow, has a great series of post on estimates, I’ll use an example from it.
Can you estimate the length of the coastline of the Pacific Ocean? I’m sure you can, but your estimate will most likely be incorrect because it will be a guess. Typically you would think of a range —let’s say somehow you remember that you have to drive about 535 miles from Portland to San Francisco. The coastline length is undoubtedly bigger than that number, but you don’t know how much. Somewhere between 535 and 2000 miles, or even more, probably. If you want to make a safe bet you would pick a wide range, say 500 - 2000 miles. If you are afraid to look like totally guessing and not knowing geography, you will choose a more narrow range.
That’s precisely how most of the projects are estimated, even if on the surface you see a nice calculation and breakdown of price. "We need to have X, Y, and Z features; We implemented Z some time ago, and we can project that on X and Y; It seems like this project will take a week to complete, but let’s multiply it by three to make sure we finish it on time."
I haven’t seen this approach working ever. When making the guess a lot of complexities are invisible, which makes it inaccurate from the very beginning. And even after adding all possible buffers, the guesstimate is bent to feel ‘right’ to stakeholders.
Estimating using known metrics.
In the last post of "How Good an Estimator are You?” series Jeff gives an example of how estimations should be made. Typically we can count certain reference points and base our estimate on them. He suggests counting things like dialog boxes, database tables, classes, reports, etc.
This approach is slightly better than a complete guesstimate because you use real numbers, but it’s still not going to work if you want to define the budget for your project. It’s as good as back-of-the-envelope calculation and can give you a very rough understanding of the budget. It’s still more of a guess, though an educated one.
Waterfall budgeting
If time allows and your project is simple enough, you can use waterfall approach for budgeting. It is quite simple. First, you need to write down detailed requirements and create design mockups. Then you break down the project into simple, digestible pieces that are known and easy to grasp and ask skilled engineers and analysts to provide the estimate.
This approach almost never works, unless the project is really simple. First of all, it’s utterly pointless if your requirements are missing critical parts, and in my practice, there’s no way of knowing it before clients of stakeholders start using the product. It’s extremely hard to envision the product using text-based requirements and mockups. Just as Europeans had a hard time visualizing unknown beasts from the jungle that travelers were describing few hundreds of years ago, stakeholders and clients will hard time to try to imagine how the product will turn out in the end.
Burn rate budgeting
It's the approach used in most startups. You accept the fact that you can’t budget for something that is unknown and define how much money you can spend every month.
Let’s imagine, that you want to build an online e-commerce solution that allows you to sell goods from all retailers in the world in an online marketplace. You figure that you will need at least three developers, a PM, QA engineer, a designer, and analyst.
After including all your monthly costs, you calculate that your burn rate will be $100,000 per month. Given the amount of money you have for the project, it’s just 18 months of development before you run out of funds.
Using this information you can start making decisions. For example, you realize that you need to cut down the number of features by three to make sure that only essentials are included — after all, it’s only 18 months to go live, and you understand that you will need two months to get up to speed and another two to polish everything before the start.
None of the budgeting approaches are perfect, but I think that burn rate budgeting a much more honest approach than estimating. When you accept the fact that you can’t estimate the unknown, it’s easier to make the right decisions. When you’re driving in the fog, you can’t just pretend that you have a clear view and go full-speed. Instead, you slow down and evaluate the road, paying attention to everything.
Unfortunately, there’s no easy way to define the cost of the project. It should be very short and straightforward, or you should be ready to use the burn rate budgeting. The former will require you to resist the urge to change the scope. The latter will allow you to embrace scope change but you will probably get less number of features done in total, though those that will be implemented will be done right.
