A client wants to know how best to calculate their software capitalization. They had a “standard” approach when they used waterfall.
They no longer have all waterfall projects. They’ve started to use agile approaches. And, the projects don’t all look the same. Being somewhere in the middle means they’re having trouble reasoning about capitalization.
Why Capitalize?
Capitalization helps companies shift their investment from purely expense categories to an investment that the company can depreciate.
(I am not a finance person. If you need to capitalize, talk to your finance people. I’m not offering financial or legal advice. I’m only discussing the ideas of capitalization vs expense and how companies can use those ideas. There’s a great introduction article, Capitalization of software development costs.)
Capitalization is especially important for internal work.
You might have seen internal charge-backs of money if you work in IT. That’s because the company is attempting to determine how much of the work can be capitalized and how much must be an expense.
If the company has an asset, they can depreciate it. Companies cannot depreciate expenses. You and I might think of this as moving money around the org, but the depreciation makes a huge difference in taxes. Companies (and you and I) want to minimize our taxes.
Capitalization for Agile Work
Let me walk you through an example of a 5-person agile team. Let’s assume everyone works together, on one project (product, if you prefer). Let’s assume the team has a run rate of $2500/week.
Capitalization rules say you can’t capitalize the planning work. You can only capitalize the value creation work.
So, let’s assume the team spends a total of 4 hours planning, retrospecting, demoing, all that non-creation time out of the 40 hours the team works. (I would add demoing in as value creation, but I’m not sure how accountants categorize feedback loops. And, using the 4 hours works to make the math easier.)
4 hours is 10% of 40 hours. That means the team spends 90% of its time creating a capital asset. If the team’s run rate is $2500, then 90% of that time is worth $2777 and some cents. I don’t know if accountants are allowed to round up to $2800, but I’m going to.
The result: The team can capitalize 90% of its work, week in and week out.
Here’s what’s interesting. Because this is cost accounting, there is no accounting value in moving to a shorter cycle time.
However, the more the team reduces its cycle time, the more distinct pieces of value the team creates. That helps overall sales and support. (See Minimum Product Outcomes for more details.)
But, what happens if you don’t have an agile project?
How Some People See Software Projects
Let’s first discuss how some people see software projects.
When I used to work with company accountants, they thought the software projects followed this lovely trajectory for a serial project:
- We got all the requirements first.
- Then we analyzed them and created the architecture.
- Then we designed, coded, integrated, and tested.
- And, everything just worked.
Yeah, right. I never saw that. I always used incremental life cycles to manage risks.
At a client several years ago, I showed him this image of how serial lifecycles actually worked:
I explained that Alternative 1 was quite common, where we kept getting requirements until we were almost “done” with coding.
Alternative 2 is where you get more requirements way into Integration and then you cut Test short because you cannot tolerate more change and you have to ship the damn thing.
And, Alternative 3 is where you try to accommodate all the feedback all the way through the project.
(There are plenty more antipatterns for a serial lifecycle, but I’m not going to mention them. These three alternatives are sufficient.)
In all three cases, I asked the question: If we don’t stop planning and replanning, when can we capitalize?
Some of the more creative accountants grinned at me and said, “As soon as you start design, we can capitalize from there.”
I asked, “Even if we’re in 90% Done?”
One accountant actually cackled. “You bet.”
Long cycle time hurts the organization. Long cycle time does not hurt capitalization.
Some Alternatives for Capitalization
So, my client is trying to figure out what to do. How can they manage their capitalization if some projects use an agile approach and some use a waterfall approach?
I suggested these possibilities:
- Measure cycle time. Every time a team releases a feature, they can measure the cycle time and use that as an average for when they can capitalize the software.
- Make sure people work on one and only one project. Now, you can measure the run rate for the project. You know when you have which activities. You can calculate how much of the total run rate is expense and how much is capital.
- Shorten the project, so you know you can release something every quarter or even every month. Then, even if you “fake” the capitalization numbers, you can show a depreciable asset.
My concern with capitalization is that high capitalization doesn’t mean you’re releasing more often. And, in too many of my clients, if the team starts coding, the accountants take all the work as capitalization—even if the team is still replanning.
You might need to reason about capitalization. I have a suggestion: How can you make the ideas of capitalization work for you, to create smaller chunks of value and release them more often?
(If you have ideas about this, please do comment. Thanks.)
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Capitalizing Software During an Agile Transformation Opinions expressed by Java Code Geeks contributors are their own. |
