Christopher Pola on Agile Financial Planning Adoption

Christopher Pola
Executive Advisor
Rally Software

Christopher Pola, Executive Advisor Rally Software helps organizations adapt enterprise-wide processes, like finance and HR, to agile ways of working.

Let’s talk about agile financial planning. How do you do agile financial planning in the first place? What are some of the challenges of trying to run agile with the old-world waterfall concurrently?

To kick it off, I will start with ‘how do you do it’? When I approach organizations about this, I have two things in mind. One is, let’s define what agile financial planning is, and the other is one of the principles of beyond budgeting.

When I define it, I say there are three main “macro” categories to agile financial planning. The first is lean budgeting, the second is funding allocations, and the third one is capitalization. These activities are the domain of the finance organizations, and they’re fundamentally different.

The foundation stone to all this is mindset, without the paradigm shift there is always friction that circumvents the overall goal. There’s this whole ethos, “What’s the purpose of finance? What values, principles and practices do they have? How do we view them?” Typically, they’re viewed as antagonistic. They’re either the bean counter, or the tyrant. Everyone’s mindset needs to shift. They’re a business partner, just like when you go to your accountant, or financial planner. The same should be with your CFO.

On top of that, there must be support for open and ethical information systems. So one version of the truth. Everyone has to have the same allowance for information flow versus budgets that are only seen by some people and only determined by a restricted number of people. Transparency is king. That in and of itself is a big mind shift.

 

Let’s define lean budgeting as you see it.

Budgets manage fixed and variable elements. When we’re talking about product development, lean budgets are different than a traditional budget in what is determined as ‘fixed’ vs. ‘variable’. In lean budgeting we see people and time as fixed elements. You can be more fixed about those parameters and say, “Okay, this is the people who are employed for this fixed time, and thus the run rate is ‘x’. The budget is generally based on the project labor run rate, and other relatively fixed costs.” It’s easier to do, and more lightweight than the traditional budgeting process.

In the old way, it was the scope that was ‘fixed’. We would have the requirements in the scope, and we’d fix that by asking for estimates around the time, in terms of the number of people we could allocate, it would take to complete. We would always be changing or adjusting people or time to meet a budget forecast made months ago. Another traditional method that adds overhead, and doesn’t help achieve business outcomes would be cost-centers. That whole paradigm doesn’t serve the organization in terms of being flexible in the new way of working, but more on that another time.

So lean budgeting: keep it simple, focus on what’s really fixed and variable, and that’s the scope.

 

How does funding allocation look in the agile finance world?

The second category, funding allocation, that’s all to do with managing the scope, and applying the principles of flow or beyond budgeting. We flip the proverbial ‘Iron Triangle’ upside-down. Funding allocation decisions happen in quarterly steering meetings. The planning cadence and horizon for funding decisions needs to become more frequent, this is ‘agile financial planning’. The budget can still be long-term, because it is forecasting the fixed elements: this number of people will be employed across this time period. There are a fixed number of days in a week, weeks in a month, months in a year. So, take the viewpoint that time is more fixed, and now have conversations about ‘what is the right thing to do during this time?’. Be diligent about the scope. In those quarterly cadences of steering the business, you due your due diligence, portfolio governance, and have a discussion about funding the work. “Do we continue to invest further in this initiative or venture?”. In the old way you just manage variance to the budgeted scope, you keep doing something even if there are signals that indicate “this is not the right thing to do anymore.”

You’ve got to be meeting as a group (finance, product management, engineering, operations), on a regular cadence, and having a frank discussion ‘about is this the right thing we should be investing in right now?’, instead of just managing to a fixed plan where any variance from that plan sounds alarms. That is sensible, because there is new information and results to review in light of your funding allocations. So the funding allocation activity can happen in business steering meetings, have everyone involved for transparency, including finance.

 

And then the third one, capitalization.

I focused on this topic a lot. To make a balance sheet look better, you should have an agile capitalization policy, per se.

First, there’s a lot of information in the work. I see organizations imposing additional processes around collecting additional information for capitalization, and it is just overhead. For example, requiring time tracking to do calculations. This is nonsense because you should already have more accurate information in the actual work. For example: ‘You know who’s working on it, you know when they start the work, and how long it takes to complete it.’ Adding on another data entry overhead or requiring additional proxy data control points should be done only if it adds ‘value’ from a systems perspective. The accounting standards and guidelines, were written a couple of decades ago, and based on the phase-gate waterfall type of methodology, yet they are very much applicable to agile ways of working. Accurate, consistent and defensible capitalization of labor costs, of agile methods is certainly achievable with the current guidelines. It provides a compelling benefit for practicing enterprise agility, so I encourage every customer to investigate the potential.

We use feature points/size to do capitalization. Not story points, feature points. At the feature level, we have the data roll up for the work done by a team or multiple teams. The data is consistent, accurate and defensible. We can make some rudimentary calculations about the time and costs to build that software feature, maybe use ratios to determine what was expense vs. capitalizable etc. The information, data points, is in the work. Having agile teams is foundational to this type of accounting practice.

Companies understand doing it at the feature level eliminates a lot of overhead. It keeps it simple. In addition, capitalizing a feature has some ancillary benefits, because the feature is actually that unit of work that exists through the whole value stream. In other words, everyone in the value stream will likely use the feature work as common reference:  business people, executive stakeholders, your portfolio/program teams, product owners, engineers, operations, and support staff, sales and marketing, everyone understands what that feature is. If you have a single dataset that is used to manage all that activity for the feature across the value stream, then you have flexibility in how you capitalize the work. You have a lot of insights to improve how work flows through your organization.

 

So you recommend that all stakeholders work from the same data source?

Yes, correct. That’s even something Peter Drucker said, back in the day. He said a single-management system, with a single data source saves you 20 to 30 percent of management overhead. He quantified it, and understands the benefit of reducing ambiguity around that management data.

 

What concrete steps can an IT leader take to move the financial planning more away from a waterfall-like method toward agile financial planning?

You invite the financial people into your planning sessions. Partner with them. There’s a whole new learning curve they have to go through. They also have to understand what the different dynamics are like. Software assets are very different from physical ones. Teach them how you plan and execute the work in an agile way, the principles of product flow, and the benefits. They will understand, and I bet they will be avid supporters of this way of working. Teach them things that are wrong with the current orthodoxy, I’m a big fan of Dan Reinersten. Things like: How efficiency and utilization metrics are counterproductive. Teach them ‘Why?’ managing knowledge workers at 100% utilization and capacity, causes severe economic damage to your organization. Have those conversations, so business, finance and IT get to a common understanding, and common goal.

The other thing is, they’re very conservative by nature, and that’s absolutely good. Create an implementation plan, or make sure you approach any collaborative activity in a way that matches, and honors those values. Do experiments, and run new innovative accounting practices in parallel to existing processes. There has to be a period where you’re doing things in parallel. Today, you probably have the traditional budget process, resource allocation, time tracking overheads etc. And you want to show how you can achieve the same (or better) business outcomes doing lean budgeting, funding allocation, and agile capitalization without time tracking.

Experiment with agile capitalization, go slowly and do it in parallel or as an experiment that does not disrupt the status quo. Demonstrate the result, and I suspect the feedback will be, “okay, we’re still defensible, still conservative, and this process has a lot less overhead. I get my weekends back…” so they’ll switch. But you can’t up-end. You hear a lot of talk about big bang transformations, and it has its place. Yet to expect finance to flip a switch, and do this way of working, is naive because there’s so much preparation before that switch. That’s basically what you’re doing here when you run things in parallel.

 

This makes sense because it needs to arrive back at a place that finance is comfortable with, that they can back and defend and agree with. Even though maybe the process of getting there is a, “ There’s more than one road to Rome,” type of methodology.

Agreed, because everything they’ve learned is just one way to comply with the guidelines or manage a business. Now you’re changing how they need to view, how they need to think, and how they need to work, themselves. And you’re saying this is easier. Sometimes that subconsciously triggers, “Is it accurate if it is easier? Or, what will happen to my role/job?” Changing someone’s way of thinking is the hard first step. When you partner with finance, empower them as part of the larger team to give input into how the work is planned, your organization structure, and how to ROAM the Risks in product development, you might be pleasantly surprised with the outcome. Agile financial planning provides greater flexibility for running your business, that is a necessary first step to achieving business agility.

 

Is there any scenario in which you see Agile financial planning and old-style waterfall financial planning co-existing together harmoniously?

I think they can coexist, but they’re very much separate entities inside an organization. It would be dependent on what product line, on what different division you’re supporting.

Article Contents

Categories

Tags

Additional Resources