Strategy Behind More Agile Budgeting, Part 2

Strategy Behind More Agile Budgeting, Part 2

By Discovery Lean Six Sigma

0/5 stars (0 votes)

https://www.jrothman.com/wp-content/uploads/2019/05/iterate.jpg 400w" sizes="(max-width: 204px) 100vw, 204px">I suggested ways to think about more agile budgeting in part 1. I didn't tell you why.

How do you budget your own money and time? If you're like me, you have a plan for the year. I evaluate the plan—my products, services, and clients—on a regular basis. I always evaluate monthly. Sometimes, I evaluate more often.

That's because I manage my company in a similar way as your managers manage your organization. I can't depend on a certain revenue each month. I have a pretty good idea about my floor (the minimum revenue I'll make). I never know what the ceiling is. I want to stay inside my budget so I don't have to worry. My feedback loop is one month at the outside.

Organizations want the same thing. They need to “know” (that's a guess) about the minimum income. When people make project portfolio decisions, they're saying, “This is our best-guess mix of products and services that we think will give us this much revenue now and plan for the future.”

Annual budgeting constrains the project portfolio ideas and work to a one-year feedback loop. If your feedback loops are one year in duration, how can you afford to change anything?

Incremental Funding Reduces Risk

Incremental funding works much better. You don’t make bets for a year at a time. You can make bets for a quarter or less at a time. If you're like me, you might make bets for a month or even less duration before the next decision.

How do you know how to bet? Throughput is the answer. That depends on cycle time. Cost of that throughput? Run rates. You don't have to predict anything at all. You can use real data.

What if you're doing something new? If you measure cycle time, you can look for historical data about when teams start something new. You still know the team's run rate.

I can predict how long it takes me to write an article. A book? Longer and I still have a minimum time. Publish that book? Ah, don't get me started on all the details. I'm getting better at managing the details to publish in all formats everywhere.

I can also predict how long it takes me to create or customize an in-person workshop. I have an upper bound for online workshops.

That's why I have a monthly list of deliverables. I can change that mix because I can produce some of my products in under a month. And, if I can't because they take longer (throughput), I can decide if I made enough progress on any of them to know whether to continue. Or, to do something else.

Incremental Budgeting for Your Life

When you, personally, budget for a year, you know where you want to spend your money. Mortgage/rent, vacation, utilities, food—you decide how much goes where. That's not a project portfolio, but your budget reflects the decisions you think you're going to make over the course of the year.

If you get laid off, you change your plans. If you get a better job for more money, you might change your plans, too. Your budget is a tool, not a hammer that drives you to do crazy things. (I hope.)

A yearly budget is a plan, not a guarantee. When things change, you change the budget. When you change the budget (incremental budgeting), you have the opportunity to fund differently (incremental funding.)

Rethink the Budget Inputs

What if your organization still needs to “budget” for an entire year? This is where the run rate of all the teams matters. Salaries are relatively fixed expenses. Sure, they will vary over the course of a year, but you can estimate salary increases:

  • If we hire more junior people, we’ll increase the average run rate by x%, more senior people by y%. What mix of people do we need to do the work we want to do?
  • If we increase base pay, then the run rates increase by z%.

You can define x, y, and z depending on inflation rates and the general salary parity in each location where you have people. We can calculate cycle time if we hire people and create distributed teams. (See Help Managers Visualize Their Problems. Also, see From Chaos to Successful Distributed Agile Teams. for value streams and cycle time calculations.) We might also have capital expenses so the distributed people have sufficient infrastructure and tools.

Separate What You Report from Your Practices

Many organizations think they are supposed to manage with the same cost accounting ideas that they report to the outside world. That would be convenient. However, cost accounting focuses on the cost of things, not the value of what people produce (or don't) over time. That's why I don't recommend ever using duration estimation for managing the project portfolio. I do recommend Cost of Delay.

You might have to use accepted accounting practices for what you report to the outside world. You don't have to use them to manage your organization. You can use incremental funding, incremental budgeting, and lean metrics to manage the project portfolio and adapt. Use the data you need to have a more agile approach.

The shorter the feedback loops for your budgeting and project portfolio decisions, the more you can align the people and teams to the projects. Incremental budgeting for an organization can reduce pressure to do it “all.” Incremental funding for projects helps people see what's most valuable.

When you shorten feedback loops, it's possible to use incremental budgeting and incremental funding. You'll discover you don't have to plan as much at one time and your planning will be more effective. That's why more agile budgeting helps the decision-making in your organization.

Both posts:

The post Strategy Behind More Agile Budgeting, Part 2 appeared first on Johanna Rothman, Management Consultant.




Original: https://www.jrothman.com/mpd/2019/05/strategy-behind-more-agile-budgeting-part-2/
By: johanna
Posted: May 16, 2019, 4:01 pm

comments powered by Disqus

Discovery Lean Six Sigma

Dummy user for scooping articles

I'm a dummy user created for scooping  great articles in the network for the community.