Too often, organizations want to budget for an entire year. The managers run around for two or three months in advance of that fiscal year, attempting to predict a ton of things:
- Estimates for not-well-defined projects or features,
- Capital equipment or tool needs,
- “Headcount” aka, people needed.
Then, the organization doesn’t finalize the budget until after the year starts. Or they say things like, “You didn’t use everything you asked for last year, so we’re decreasing your budget this year.” They don’t realize that things have changed since last year. Or, that we need to plan for change this year.
The people who budget want predictions, not the ability to change. I can understand what they want. I have trouble with the duration of their desires. If you want to change what you deliver and when you deliver it, your budget will have to change.
Here are ideas for a more agile budgeting approach:
- Fund teams, not projects. Calculate the weekly run rate for each team. You can now predict the quarterly cost of a team. If you flow all work through teams, you now plan for a quarter at a time. You know what each team will cost. You can decide how long you want those teams on those projects.
- Calculate the average or median run rate across all teams. I often discover that the average is sufficient for budgeting purposes. Often, the run rate for all teams is within +/- 10% of each other. Now, you know enough to say, “How much do we want to “gamble” on a new product? What do we want to fund to get to an MVP of some variety?
- Calculate the cycle time for current products/projects now. (Projects are an instance of a product release with some specific goal. Most organizations have more products than they have teams.) How long does it take a given team/set of teams to release value to customers? You know the average cycle time for a team. You know the run rate for that team. You have a good-enough estimate of what that team can deliver when. You can decide how much money to use for how long for this product. You can’t shove more features than the team can deliver, but you can manage your investment.
- Decide on your budgeting by looking at the big picture of your organization’s money allocation into the various kinds of projects:
- Keep the lights on. (These products/projects generate minimal revenue for product or support. They do support the organization.)
- Projects that keep the current business going. (Generate the bulk of the revenue for product revenue or support revenue.)
- Projects that might create new opportunities. (You don’t know if any of these ideas will work.
- Now, what percentage is in each bucket? If you spend 45% of your budget supporting the business, and 45% on maintaining business, you’re spending 10% on possibly transformational work. Is that enough? Is that too much? What would you not do if you wanted to increase any of these buckets?
I’m sure there are more options, but these ideas can help organizations start to use a more agile budgeting approach. (I talked about a variety of these ideas in Manage Your Project Portfolio.)
I’ll talk about the strategic reasons for more agile budgeting in Part 2.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Tactical Ideas for Agile Budgeting, Part 1 Opinions expressed by Java Code Geeks contributors are their own. |
