When making the move to a product-based organization, there are quite a few tactical considerations when it comes to annual budgeting to help ensure that the needs of the Finance organization are still met. One of the biggest areas to shift is moving to that investment mindset vs. a fixed project budget mindset and from managing individual resources to managing the teams as a unit.
Typically, annual budget cycles require that all project, program and portfolio planning be completed up-front for the following year, which locks the plan in and doesn’t support any opportunities that come up during the year to adapt based on market conditions. This fixed budget also creates the mindset that the budget must be spent, regardless of whether the projects would still provide value.
There’s probably some waste being generated from this process too because during planning, estimates are most likely down to the individual person level, which leads to re-work as these massive plans are revised before they are considered final and approved. I’ve been in some organizations where we had this massive spreadsheet to complete for every project, who would work on it and for how many hours – this was in October for the upcoming year! Looking back, I wish I had a crystal ball that worked that well to know that Sally the Developer was going to be working on Project B for 10 hours in the week of August 19th the following year. But, this was the process, so we followed it.
A New Approach
Annual budgeting can still be supported in a product delivery team organization. The change is to budget for the number of teams that are needed to execute on the organization’s strategic goals.
You can start with the number of product teams that you determined in the steps outlined in the previous posts. Do you think you’ll need more or less (probably not less) for the upcoming year? The answer will probably be more, so begin to approximate how many more you’ll need. Figure out the average expense/run rate per team (remember, it’s not at the individual level any longer – having a tester without a team does not bring value). Work with senior leadership on how much more they’re willing to invest and what additional capacity that additional investment would provide.
You can even stagger the start of the new teams throughout the year, which gives a sense of how to prioritize recruiting (there’s that benefit again!). Throughout the year, assess what open investment is still on the books and decide if it’s still needed.
Because these teams are not tagged to a “project,” but rather a goal/outcome, there is flexibility regarding the “what” they would work on. Remember, the smallest increment to plan in is a “team.”
How to Enable This Shift
Start with your Finance leaders and work with them on what their specific needs are regarding the annual budget planning. What is it they need to be able to do their jobs and why? Once you understand their position, you’ll be able to work with them to achieve those goals and meet their needs with the shift to product delivery teams.
It is important to also share with them how the organization is changing; however, start from their point of view because they’re going to want to know “what it means for them.” Make their lives easy wherever you can and explain how these changes will benefit not only their team, but also the company as a whole, such as more efficient processes, making it easier to manage changes to the plan, and hopefully, higher returns on the investment.
In addition, share with them the governance frameworks that you created as part of your program and portfolio operating model. Ask them how they’d like to be included and informed of any changes to the investment mix. If you have a Financial Planning and Analysis group, they would probably like to see the investment mix so that they can also run some analyses and models based on the revenues they’re seeing at the corporate level.
Note: I’m light on the tactics here because each organization is different, so I don’t want to be too prescriptive. Happy to chat through anything though!
Capitalization in Agile
In a Waterfall environment, it seems easier to determine capitalization activities because there are phases and stages where team members work on capitalizable activities. When working in a more iterative, holistic team approach way, it may seem daunting to figure out capitalization.
What I’ve found is that it’s actually the same (or even easier). The Agile Alliance has a good write up of an approach, and at Agile2016, Dan Greening gave a presentation on Agile Capitalization. Techniques that I’ve observed include using timesheets to track capitalizable activities (by roles and whose time can be capitalized), or I’ve seen organizations that approximate time spent on capitalizable activities based on the role the individual is serving on the team.
Previous: Program and Portfolio Management Next: Final Thoughts
Shortcut: All PMO Directors Series Posts