Who’s on First?
At first glance, financial modeling in an Agile world is simple. Instead of tracking projects (large or small), you are now tracking people. You model costs based almost entirely on capacity. You may feel like you’ve hit a home run because it’s true: Capacity-based financial modeling can be much easier than project-based modeling.
But it is contingent on getting one thing absolutely right—your organizational structure. Failing to optimize your organizational structure can create nuances and hardships for your financial model downstream and turn your home run into a foul ball. Consider a few tips to optimize your organizational structure:
Agile teams must be cleanly and clearly aligned to business outcomes.
Before you even consider budget or actuals, think about how you’ve organized your teams. They should be formed around well-defined capabilities with well-defined business outcomes. Create minimal overlap between teams. The more you can make the alignment one-to-one, the better. Financially, this helps as you aim to have one charge code to represent your team, its budget, and its actuals. This will also represent the asset or business outcome you’re achieving.
If you can keep the charges one-to-one within the team and charge code, then you can truly estimate and budget based on capacity. You won’t have to consider shared resources, matrixed organizations, dotted-line reports, shared assets, and shared business objectives among multiple teams.
It also simplifies asset and tax reporting down the road (more on that later). This also means creating a cross-functional team, so all players involved in the creation of the asset are on the same team. If you have a team charging to multiple charge codes, your teams aren’t aligned to business outcomes.
Teams should be made up of roles—not people.
One way to lose track of financial capacity for a team is by focusing on the people on the team—tracking where people move, their rates, their hours, etc. At its core, an Agile team should have specific roles assigned to the team: business analyst, scrum master, product owner, developer, QAs.
When tracking and forecasting the capacity for the team, consider the roles, not the people. This will allow you to get a true picture of what the capacity for the team looks like, versus what the people look like. It is also important to get the right roles on a team. This will allow your team to become “sticky.”
This does consider that role allocation is different at different times within the life cycle of a team. For instance, a new asset may need more business analysts up front to get work started, versus a team in production support. Focus on the roles necessary for the team to meet its business objectives, giving you a clear financial picture for the future.
Team members’ skills should be T-shaped.
Another way to lose financial capacity is to allow team members to waste time waiting for others. While you may spend the same amount of money, your bang for the buck is dramatically decreased if you have unproductive team members.
If your team members have T-shaped skills (i.e., depth of related skills and expertise in a single field, along with the ability to apply knowledge in areas of expertise other than their own), your team members can help reduce inefficiencies and bottlenecks that may occur in the pipeline. For example, if your developers also have the ability to write cards, then your business analyst (BA) is no longer a bottleneck for developers to do their work. Over-specialization will kill you when working with fixed capacity.
Teams should be managed at a portfolio level.
Teams should roll up to a portfolio and manage financials at that level. The variability that occurs within teams can come out in the wash when summarized at a portfolio level. The portfolio leaders should be accountable for financials, tracking, understanding, and addressing variances. An added benefit to managing at a portfolio level is the flexibility it provides to move allotted portfolio funds throughout the various teams
This is more relevant in an organization that uses outside labor. It’s easier for such an organization to control costs by ramping up or down its reliance on contractors and avoiding the impact of hiring or firing employees. In an organization that is staffed primarily with employees, the teams’ cost structure would be more predictable.
In summary, the organization you create will make or break your financial model. But if you get it right, you’ll be well on your way to a clean financial model.
Technology Isn’t the Only Thing That Should Be Agile.
We’ve talked about technology and how tech teams should be structured to get clean alignment, which will lead to financial clarity. This doesn’t mean that you, as a financial planner, are off the hook; you also need to be Agile! Maybe you’re not made up of scrum teams, but agility is key in order to keep up with the technology organization and its evolution. Some tips to increasing agility:
Technology is fast-paced. An Agile workforce is built to evolve and change. Chances are, you’re not going to build the perfect financial model to support the organization out of the gate. Even if you do, the organization might evolve, rendering your perfect financial model irrelevant.
Flexibility is key. You may even fail. That’s OK. Build something, see if it works, learn quickly, and pivot as needed. Shifting from the financial world of rules and black-and-white answers to the world of movement and change is tough. Allow for your own capacity to evolve and grow as well.
Build flexible technology.
Now that you’re living the Agile lifestyle, evolve your financial model accordingly, and make sure your technology can maneuver and adapt quickly also. Don’t get locked into technology that cannot adjust to the changing needs of your technology organization. Balance the cost/benefit of systems and tools with how rapidly they can adapt when you need to change directions quickly.
Create a minimum viable product (MVP) for time tracking.
You can approach time tracking in many ways. Most financial reporting requires a certain amount of scrutiny into the work being done, for which asset, and for how long. In the past, your resources may have charged time to multiple tasks within multiple projects. Now that your teams are aligned cleanly to business outcomes, you can track time at a team level.
But how low do you go? Should you track time against every card to understand exactly how much time goes into a specific piece of work? What if you just track time at the team level? How will you understand the type of work being performed? It is important to understand time charges enough to accommodate accounting rules, and make decisions based on productivity and utilization.
However, it’s also important to not track time at such a granular level that resources are mired in administrative minutiae. You want to enable Agile behavior—not prohibit it. For this reason, it’s important to strike a balance that works for you and your organization. Determine your own MVP and align to that. Just remember to maintain flexibility.
When you previously estimated project work, the standard best practice was to add in contingency based on associated risks. The same principle should apply in a capacity-estimating model also. You need to be able to make room for mistakes, change directions, and work iteratively to get it right. This will be a work in progress to figure out exactly how much contingency will give you enough flexibility and the room you need for iterative learning.
In summary, it’s critical to be flexible with your processes, tools, people, and product.
Mind the Gap!
Now that IT is Agile and you’re Agile, you might think you have conquered all! However, don’t overlook the gap that may exist between an Agile mind-set and other business colleagues, who may have no idea what Agile is or why they should care. The onus is on you (not your colleagues) to bridge the gap. A few considerations to help you do so:
Address reporting structures.
You will need to be able to support the existing financial reporting functions that the organization uses, and they will expect you to report in the same way as the rest of the business — including accounting and general financial principles. A few areas that may be particularly troublesome are:
Capital and operating costs
You must be able to create reports that reflect capital and operating estimates and actuals. This means taking a capacity-based financial model and translating it into a type of expense. A simple way to do this is to map the charge code to capital or operating expenses. This should give you an estimate of expected capital versus operating charges to use in the future.
You should also be able to adjust the estimates based on the evolution of the team. For instance, a team that is solely in production support mode will have very few capital expenses, whereas a team that is creating new assets will have primarily capital expenses. If you have set up your own reporting processes and tools to be flexible, then you should be able to get to an accurate model within several iterations.
It’s quite normal in an organization to use cost centers to differentiate financials across the organization. Take care to organize teams within cost centers to ensure clean alignment. For instance, if you have a cross-functional team, you should make sure that the head count on that team resides in the same cost center. Nothing will so much ensure confusion to both IT and the business as having to untangle the mapping of cost centers to teams, and therefore to business outcomes.
In order to capitalize assets, you will need to know when they were put into service. In a project-based world, this was easy: When did the project deploy? Now that you’re Agile, working in sprints, you’ll have to reconsider the definition of an asset and determine the best way to report its deployment without bogging down the team in administrative details.
One way to address this is to use a combination of systems and extrapolate actuals. For example, after you have reconsidered what constitutes an asset, you can use your card-tracking system to determine when a particular asset was released into service. Extrapolate the associated actuals based on the sprint timeline and time billed to the team’s charge code.
There will be additional requirements from your business to get to the level of detail it needs to understand and drive the business based on financial reporting. This may include tax reporting requirements, Sarbanes-Oxley dictates, etc. There is no right structure to meet your unique business needs. The key is to balance flexibility, ease of reporting administration for the team, and the business requirements. Look for the MVP who can meet all of these needs, and evolve toward that solution.
Financials are at the heart of all business discussions. You must be able to communicate to business colleagues in their terms. You partially address this with reporting structures; it’s also important to discuss the value of business outcomes. This was pretty straightforward in the world of projects. You could clearly articulate the scope, schedule, and budget performance of a project. It may not appear to be so clear-cut given the iterative nature of the Agile life cycle.
However, if you have cleanly aligned your teams with business outcomes, then you will be able to communicate how the work (and associated spending) aligns to the outcome the business seeks.
Additionally, make sure business colleagues understand the journey you are all taking. Partner with IT leadership to educate the business on the whats, whys, and hows of Agile—including language colleagues may hear in the new world. Assure them they will not lose visibility in the work being performed. Show how reporting will change (if it is changing). This may mean spending a little more time to get them up to speed with the changes, but ultimately should produce advocates as they see the efficiencies.
At the end of the day, colleagues need to understand the ROI of both going Agile and the results of an Agile environment. They should be able to see ROI for the business outcomes iteratively throughout the year. Initial setup of a charter for a team and mapping teams to business outcomes are a beginning. But IT should continually come back to the value that has been delivered throughout the year and the cost to achieve that value. This may mean that a shift is necessary in strategy or priorities. That’s completely fine. It’s better to shift now rather than later; that is the point of being Agile. Financial management should always be tied to strategy (regardless of the delivery method), so an iterative review of financial performance against business outcomes is critical to show progress against strategy.
There are many more ways in which business colleagues and IT can bridge the gap in understanding, but these guidelines will help.
Start with the Structure
Remember, there are no hard and fast rules. It’s about balance, flexibility, and the cost/benefit of accuracy. However, the one thing that will make or break you is the organizational structure. If you get the organization right, financial management will become increasingly easier—focus there before addressing the other sections. Once you’re comfortable that the organization is aligned cleanly to clear business outcomes, start on the remaining suggestions. You will not get this right out of the gate. It will be an iterative process, starting with the MVP and evolving into a structure that can support the changes of a healthy business, which is exactly what Agile is meant to be.