October 23, 2023
During this uncertain economic time, engineering leaders work with their financial controllers to ensure they acquire the resources needed to continue company growth. Finance teams are turning to an accounting practice called software capitalization, and engineering leaders need to understand the basics of it. What is it? Why is it necessary for my teams to do this type of cost reporting? What engineering work is capitizable? And are there ways to get the financial data necessary without taking time away from managers and developers for data collection?
This post gives you a brief “101-level” introductory course on software capitalization. To learn more about software capitalization, check out the presentation by Ryan Kuchova, and Michael Villalobos called, Defensible and Automated R&D Cost Capitalization for Finance & Engineering Teams.
Why Capitalize Software Investments?
Software capitalization is a way of handling and financially representing the investments made by your software team. In software capitalization, the costs associated with the investments you’re making into the business are measured to accurately represent when you realize the benefits of the investments themselves.
For example, a bakery wants to purchase a truck to offer delivery service to their business. They’re not going to see the full value of that truck in that single year, and while you might pay for the truck upfront in cash during that year, the truck’s costs will accrue over its expected lifespan. In other words, the upfront cash flow does not directly reflect the costs (or the total value) of the investment you’ll see from offering delivery as a service over the business’s life.
Applying this concept to software engineering and software capitalization moves the financial cost reporting of the feature work that will provide future gains for the business to when those gains will be realized. It’s the difference between reporting a time investment as a one-time cost or a long-term depreciating asset.
Software outpaced software capitalization.
You might ask, what makes software capitalization so hard? Shouldn’t it be as easy as adding up the headcount cost? In short, it’s difficult to get the key inputs needed for a few key reasons.
The rise of agile development
The rise of agile software development has made it very difficult for capitalization. It’s non-linear, complex, and involves many people across multiple teams to build, review, and deploy it successfully. Waterfall, when it was at its peak, was better suited for this practice. You could quantify the engineers who worked on the next big release. In Agile, within a few weeks, you will start a project, design, build, test, and revise it. And then fast forward even just a few weeks later, and you might be going back to the same project to re-factor something based on what you learned through the process.
Software development resource scarcity
Knowing how much time each person spent on this part of the work is nearly impossible. We work orthogonally with how the business tracks software engineering practices for capitalization. In some cases, you might know that a specific person worked on it, but then who reviewed it? How long did each person spend on it? Did it require any revisions, or what work was required by others to get it deployed?
Increase in required justification for software capitalization
We need a way to give the data to finance so they can do their calculations, but it’s also defensible when it comes time for an audit. Could you go into detail and defend your rationalization?
The two current methods for capitalization leave much to be desired, guesstimating and manual time-tracking, and we have an entire dedicated post to just this one topic. For reasons stated within that post, we need to move on to a better way of cost reporting.
What Software is Capitizable?
When it comes to software development, the output is intangible. You can’t put your hands on it, but you’re spending a lot to build our assets for your business. So, how do you determine what’s capitizable?
There are various regulations surrounding software capitalization, but as an engineering leader you can think of the core development work related to new products or significant improvements to your current product as capitalizable, as they are rooted in realizing future revenue and growth. It’s important to consider when the work occurred in the software development lifecycle. As a general guideline, new product or significant feature work that’s done after design but before release is capitalizable. In other words, it does not include activities and work after the launch, such as ongoing maintenance.
Streamline software capitalization with Allocation
Allocation is a collection of work signals that describe how much of a person’s effort went toward a specific category or issue. Jellyfish interprets these signals to understand holistically, across all teams working on capitalizable work, how much effort went into a given project and feature. The Allocation model does not care if you practice Agile, Waterfall, DevOps, or any other development model; it will be able to capture effort across all teams that work on developing that feature. It’s better than the current two methods: guesstimating and manual time tracking.
Streamlining software capitalization with Allocation is not just about freeing up capacity; it’s also about fostering successful collaboration between finance and your engineering organizations to achieve both teams’ goals. Software capitalization, along with close collaboration with finance and operations through the practice of DevFinOps, will help engineering teams secure the necessary resources to achieve business objectives.
