Agile budgeting: How to do Continuous Planning, Delivery and Funding (Part 1)
You must have experienced this if you have managed projects or portfolios in your organisation. At the end of the year with annual budgeting systems, funding decisions are project-based, ie budgets are allocated on a per-project basis. BUs present their ideas to the PMO in an APM. The IT dept. provides cost and time estimates and VPs prioritise funding based on perceived customers delivery. Then, teams are formed and eventually start working. The teams delivers on an agreed plan and are measured according to project completion and how they stick to budget and time. Isn’t it familiar?
But things are changing with movement away from traditional development which were centralised around waterfall development . With agile inception and adoption , agile budgeting and planning is demanding a cross-functional collaboration since it impact entire portfolios of product / services. What this means is that the Finance and PMOs must work together to ensure the products, services, maintenance , R& D that deliver on strategic objectives focuses on funding portfolios at the right time.
There are certain principle from the Lean Agile thoughts that helps us to manage or initiate the agile planning and budgeting . These principles are very high level or a bird eye view of this function.
1) Economic View : What this means that any new project/initiatives are based on every investment decision ie not on the highest quality or shortest time to market . Based on the economic view of what is the best way to make investment based on best market conditions , best business investment on the right product and on the right time. You must have come across some of the products that gets disinvested from time to time in a portfolio.
2) Build Incrementally with fast integrated Cycles : This means build anything incrementally . If its a Product development or support or R & D , the big feedback loops gives an opportunity to get feedback ie feedback on the right choice that complements the strategy. This also entails that the teams that are build around the LOBs are created to scale. With the feedback loops , the VPs or executives from top to bottom ie from VPs, to Directors to Agile teams to support teams etc. have the opportunity to course correct when required.
3) Decentralize Decision Making : This means that setup guard rails for everyone ie from the Project managers to Product managers to Agile teams makes the right decisions at the feature level to product level. Everyone is accountable for their decision making and not across the guard rails.
4) Organize around LOBs : No Business agility can be achieved if the structure is not destined to give a flow ie organize to maximise the delivery with the LOBs. This way the forecast can be narrowed down to the LOBs that requires the funding based on the characteristics. What this means is for Support Orgs, KTLO budgets gets assigned based on the efficiencies and automation done for calendar year, for Dev and R & D , its based on new architecture, technologies etc. For other LOBs it could be expansion or contraction based on business environment.
With the above broad principles of Lean Agile methodology, the fact that emerges the most is that in case of Agile budgeting and planning, the focus is on the ‘FEATURE’ rather than on the “COST CONTROLs”. What this means can be explained with the following triangle diagram.
1) Features : The major part of this concept is the features or scope or epics or so called revenue since this generates revenue and is floating ie is not fixed since this is based on the market dynamics ie Epic Priorities, Features Importance, Backlogs Management etc. This is key to the whole concept since this is what is generated for customers and is consumed by customers.
2) Schedule: This is fixed and is typically spans a release cycle ( 3months) , this could consists of many sprints or batches or iterations within the release. With the CI/CD note that the schedule remains fixed and what ever can be released with in the time box of 3 months or the Sprints , is released . For a Support/Maintenance engagement this could differ and may be have sprints for 1 week but the release horizon remains 3 months.
3) Resources: This too remains fixed since the Lean methods promotes a stable teams, the teams that are long lasting and have the requisite knowledge built up . This is different from Project teams which are dismantled as soon as the project is done with. If the Agile teams are short of work, they take R&D, improvement items or build utilities that improves the product.
to be continued
