Why Should Agilists Care About Capitalization?
[The author is not a financial professional. Work with a financial professional when acting on opinions stated in this article.]
In many companies, agile software development is misunderstood and misreported, causing taxation increases, higher volatility in Profit and Loss (P&L) statements and manual tracking of programmer hours. I claim Scrum teams create production cost data that are more verifiable, better documented, and more closely aligned with known customer value than most waterfall implementations. Better reporting can mean significant tax savings and greater investor interest. Agile companies should change their financial reporting practices to exploit Scrum’s advantages. It might not be easy, but I did it.
Scrum’s production experiment framework aligns perfectly with the principles of financial reporting.
When I restructured software capitalization according to the principles here, during an all-company Scrum transition at a 900-person software company, we delighted auditors, gave more insight to upper management and raised more internal money to hire developers. We gained millions in tax savings, by using Scrum Product Backlog Items to more accurately document and capitalize our software work.
I hope to arm you with perspectives and resources to make the accounting argument for agile capitalization, potentially reducing your company’s tax burden, increasing available funds for engineers, and making your auditors happy.
Software is a Capital Investment
Software development is an investment in the long-term future. We spend money up-front on engineer salaries and then (hopefully) profit later from cost-savings or revenue. If we invest wisely—converting cash (one type of asset) into software (another type of asset)—the company’s value should go up. Tax authorities and investors rely on financial reports to understand a company’s value, How we report development expenses matters.
First, let’s define capitalization and expensing. “Capitalization” means spreading investment costs (sometimes called “capital investments” or “capital expenses”) over a long-term asset’s life of returning value. Capitalization is used in tax filings and financial reports (such as Profit & Loss Reports). Capital investments become part of the declared assets of the company. “Expensing” means “taking the hit” of a cost immediately, as an “operational expense” that returns short-term or no value. A company that expenses all of its software development has a hard time arguing that its software is part of its long-term value.
Some software development projects are not long-term investments; it depends on whether the software remains an asset. For example, a software contracting shop that builds and sells custom software, retaining no ongoing rights, cannot capitalize it (but the purchasing company might be able to).
It’s easy to make damaging mistakes when classifying software costs. Some companies incorrectly treat all software investment as an operational expense, hiding its true value. Although this mistake could provide an opportunity for impropriety, classifying software investments as operational expense usually just results in the company overpaying taxes and understating its value, depressing its stock price and reducing its borrowing power.
Agilists Should Understand Capitalization
If finance people treat Scrum product development incorrectly, their policies could insidiously erode support for Scrum. Agile has confused some financial professionals who conclude agile software is somehow “temporary” due to its frequent release cadence.
Agilists should learn proper capitalization and teach colleagues. Misunderstandings in how to track and report agile project costs have cost many companies millions of dollars in improper taxation. Poor capitalization rules create choppy income statements for agile companies, making them look poorly managed. So-called “conservative” waterfall processes can rarely track which design efforts or management tasks led to which features, while agile methods can. And yet, accountants typically do not understand how to properly track and report labor in agile projects.
Companies can usually save on taxes, hire more developers and create value more rapidly when they capitalize software development. If they capitalize properly, they report their finances more responsibly to shareholders and regulators. To properly capitalize, we must capture labor costs involved in creating the asset and appropriately classify those costs as “capitalized” or “expensed”.
Product Backlog Items, which explain the value delivered to a stakeholder, can be easily classified. But waterfall—with its endless design period and confused phases (check out a RUP phase diagram, and you will see muddiness everywhere)—rarely can track which design efforts or project management tasks led to which features. One would think that finance people and tax authorities would love agile practices.
But most finance experts and technical accountants do not have a deep understanding of agile practices. Accounting standards use waterfall examples to explain capitalization principles. Misapplied waterfall language can lead people to misclassify software development. Unless corporate agilists help finance departments capitalize agile software development properly, the company could suffer excessive tax liability and engineering staff cuts; and risks of audit exception findings and subsequent re-reporting of earnings.
Misunderstandings of agile capitalization principles have led to dramatic staff cuts. Pat Reed (another agile enterprise consultant) and I recently discussed capitalization with a manager at a huge engineering company. This manager told us his finance department capitalizes waterfall development normally, but treats agile development as “operational expense,” because finance asserted (incorrectly) that all Sprints are effectively “Preliminary Project Stage” work. I asked, “So does this limit your headcount?” He admitted, “Yes, any department that choses to use agile practices expects its headcount to be halved.”
On the positive side, ScrumMasters and agile department heads who understand capitalization can fix this, because good agile practices can enable more verifiable capitalization and because spreading investment costs over time often reduces the overall tax and helps find earlier funding to hire additional engineers. Here’s why ScrumMasters have this power:
- ScrumMasters, often more than anyone else in the company, can correctly classify work as long-term investment or short-term expense, and usually have all the data needed to defend their classifications with financial staff and external auditors.
- ScrumMasters promote processes that align actual team behavior with documented goals more reliably. Scrum techniques have an adaptive statistical basis, backed by experimentation, which is absent in classic project management techniques. In my experience, auditors can trust agile-based reporting more than waterfall-based “actuals”.
If, as a ScrumMaster, you want to tackle this opportunity, labor classification will then likely become your responsibility along with other ScrumMasters in the company. You will likely become, by necessity, an expert on the topics of software capitalization, depreciation and impairment. Welcome to the world of finance!
Proper classification Creates a Bright Future
Tax authorities and investors use operational expense and capital expense concepts to make better decisions. They usually want companies to invest in the long term, so they let companies spread investment costs over time, to offset revenues roughly in parallel as the investment earns money.
Software work can provide short-term value (all ROI in under a year) or long-term value (ROI over a multi-year period). Here’s a short-term example: a contract software company might create a web site for a customer, get paid for it and retain no further rights. In this case, we say development cost is an “operational expense” .
Public companies usually must report yearly and quarterly profit to shareholders and tax authorities. Computing the profit seems easy:
profit = revenue – expense
Here’s a long term example: a toy retailer builds a web site to sells its toys. Years after it built the web site, the long-completed work keeps generating revenue. In this case, we say development cost is “capital expense,” a long-term investment. Computing the total profit, ex post facto, is easy:
total_profit = revenue(year_1) + … + revenue(year_n) – investment
Every year shareholders and tax authorities expect a financial report: what were our profits last year? If we have a long-term software project that gains no revenue in its first year, and if we have to treat it as an operational expense, we might post a loss. Fearful shareholders might sell shares of our company! Maybe we don’t have to pay taxes this year, great! But next year we might have no development expense and a lot of revenues from our toy retail site, in some jurisdictions taxed in full! If we had to treat development efforts this way, it would discourage us from investing long-term.
Wisely, tax authorities and accounting groups let us spread these capital expenses over time, in a system called “depreciation.” Most depreciation schedules spread a capital expense evenly over the expected lifetime of the software, so if the toy retail site we develop will likely stay in use over a 5 year period, we expense 20% of the development cost the first year after deployment, and 20% each year after through the 5th year. Contact an accountant for more information on depreciation schedules, which can vary depending on the expected lifetime of an asset.
An investment might not be usable immediately. Since we don’t immediately gain revenue from it, we can usually defer depreciation until it goes into use. Accounting shorthand for this time before deployment is the “capitalization period.” (Capitalization benefits continue after depreciation starts, by the way.) If we remove features in our web site software or stop using it entirely (possibly because we replaced it), either before or after deployment, we “impair” our old investment, and then we have to immediately expense all remaining costs.
Companies can gain tax advantages by capitalizing software development: by deferring costs they typically offset more taxable revenue and gain more interest income. Departments also gain some advantages in hiring: when a department can defer software investment costs, it often can spend that deferred cost on employee salaries (hiring more people, providing raises, etc.).
(Click on the image to enlarge it)
Profit and Loss with and without depreciation
The graph illustrates how profit and loss (P&L) can be affected by depreciation. The numbers shown are in thousands of dollars. As is typical for software projects, the major costs (Dev Cost) occur at the beginning of the project: $2 million in 2012 and $2 million in 2013. In 2014 and beyond, the costs are $200,000 per year, the cost of adding features to the software. The project doesn’t start earning revenue or cost-savings until it is deployed in 2014, and at that point it earns $1.2 million yearly.
If project costs are not depreciated, but expensed immediately, the blue line tells the P&L story: Huge losses in the first two years, then enormous profits in subsequent years.
When costs are depreciated, the green line tells a different P&L story. No costs are taken from P&L until the software is put into use. When the software is placed in use, we compute our profit by depreciating the cost over a five-year window.
Why is this important? Governments typically tax P&L on positive amounts, and make it difficult to use negative amounts to reduce future year taxable P&L (unless you can justify it with depreciation).
Finance people often over-expense by treating all software expenses as operational expenses, claiming this is somehow conservative behavior. It isn’t. If you are investing in the long-term, placing software investments in a short-term expense class will make your company look volatile—that’s irresponsible to your shareholders. It can generate higher tax liability, which is both irresponsible to your company and out-of-line with the goals of your host country, which wants you to invest long-term.
A company with high profits can offset a product development department’s production losses. This avoids the tax problem, but it doesn’t avoid the poor-planning problem. In my experience, executives pay attention to departmental profits and losses, driving headcount from that. Who among us have not seen boom-and-bust cycles of hiring and firing in large software concerns? In part, this headcount volatility is caused by failure to properly recognize software as an investment.
Finally, if agile software projects are expensed and waterfall projects are not, it essentially dooms any long-term enterprise adoption of agile practices. If waterfall projects can hire more employees, but agile projects can’t, guess what methodology managers will promote?
Recommended Accounting Practices Ignore Agile
Accounting practices are not completely dictated by tax and securities law. Instead, the US Financial Accounting Standards Board (FASB) interprets these laws to produce “generally accepted accounting practices” (GAAP). FASB guidelines for internal use software are in [ASC 350-40], and for externally sold software are in [ASC 985-20]. Their treatment is roughly equivalent for this discussion. The International Accounting Standards Board (IASB) produces the “International Financial Reporting Standards” (IFRS). FASB and IASB provide guidance on how to interpret law. Their recommendations, written before agile practices were popular, show how to classify work using waterfall examples.
(Click on the image to enlarge it)
Waterfall Capitalization Timeline
Misinformed people believe FASB and IASB guidelines force agile projects into a waterfall world of engineer time tracking, with RUP-like phases of analysis, prototyping, development, packaging and maintenance . Instead, guidelines state that market analysis prior to development is expensed, prototyping prior to a decision to invest is expensed, development for long-term value is capitalized, packaging for shipment is capitalized, and maintenance (fixing bugs) is expensed. The figure above shows capitalized items in green.
Auditors recognize that FASB and IASB guidance cannot be routinely applied to new situations. What tax authorities and auditors look for is conformance to law and its spirit, consistent application, and full transparency. We can give them all that, but because agile practice is new, we must understand the law and its motivations, document our capitalization policies and practices, track project work consistently, and be perfectly transparent. This aligns well with agile principles.
However, if you ignore the law and its motivations, inconsistently track work or fail to document processes clearly, you risk the wrath of tax authorities and investors. Adverse audit findings and the resulting submission of corrected financial reports can cause tax authorities and investors to lose trust in the company, subjecting it to higher scrutiny and a lower stock price.
If you are interested in the basis of FASB guidelines, and you are in the United States, refer to US Tax Codes [26 USC 167] [26 USC 197] [26 USC 179]. It turns out that most countries operate the same way for this topic.
Finance departments are justifiably conservative in their approach. If your finance department doesn’t like how you do things, they could
- force engineers to track hours (degrading their creativity and productivity with mind-numbing work-tracking),
- undercapitalize software development (leaving huge sums on the table), or
- reclassify past expenses (raising investor questions about the stability of the company).
It’s easy to make multi-million dollar mistakes in this area. Because the vast majority of companies make capitalization mistakes that increase tax receipts, the authorities don’t complain. Because agile software practices are arcane to investors, they don’t complain either. But they should.
If you involve at least one person that has a moderately good understanding of three fields—finance, engineering and process—you can dramatically improve your bottom line. Since the returns are so high, it may be worth it to hire a consultant to help get it right.
How to: Financial Reporting in the Agile Frontier
Until FASB and IASB guidelines are revised to explicitly discuss agile examples, responsible agilists must work directly with their own corporate finance departments and auditors to craft acceptable capitalization processes.
First, establish a clear and consistent bright line demarking when your company could start capitalizing work. ASC 350-40 states cost capitalization can begin when all work in the “Preliminary Project Phase” is complete, when management commits to funding it, and when “it is probable that the project will be completed … and used. Capitalization begins when you move from “what” to “how” you will design and develop the software asset.”
In most cases, capitalization should begin when the whole production team assembles for its first sprint. Your company has likely completed initial market exploration and architectural design before it invests in a full team of designers, engineers and testers. However, if a research team runs a “feasibility spike” sprint to determine which architecture to use or whether the market warrants further sprints before it can create something that could provide long-term value, you are likely in a “Preliminary Project Phase,” and your costs are operational expenses.
Once your company has committed funding to a project likely to be completed and used, you can start capitalizing the work. All work critical to designing, creating, testing and deploying the asset should be capitalized, including engineers, testers, user experience designers, product management, project management and ScrumMasters.
Second, establish whether the entire or only part of the project should be capitalized. In many cases after the “Preliminary Project Phase” the entire project cost can be capitalized. This happens when a significant percentage of the work (we felt 95% was sufficient) should be classified as capital expense. However, some common activities must be expensed.
If any of the following apply to you, you may have a mixed-mode project:
- Your team fixes regression bugs in a released product, while it develops new features,
- Your team is creating a product for international release, and is localizing the product for multiple languages,
- Your team (not just its software) manually converts data from one form to another,
- Your team helps train people to use the software,
- Your team participates in operations activities beyond deployment, such as monitoring, reporting, backup, machine configuration,
- Your team performs routine Sarbanes-Oxley (SOX) or security reviews [15 USC 7211],
- Your team refactors code unlikely to be relevant to new functionality (you probably shouldn’t do this anyway),
- Your team modifies software to support individual customers.
Whether these items or others should be expensed or capitalized will depend on your finance department and technical accounting advisors.
How to: Classify Mixed-Mode Projects
If you have mixed-mode projects, establish a way to apportion labor to operational or capital expenses. If you have strong Scrum practices within your organization, you can likely defensibly use proportional allocation of estimation points (also called “story points”) for each team. If each team has a different point-scale, it can be accommodated. For a quarter, divide the total cost of the team by the total points completed by the team, (including product owner, ScrumMaster, team members and the appropriate percentage of part-time contributor salaries). You now have the “cost per point”.
|1||Add international language capability||8||Y|
|2||Fix regression bug in English-language version||5||N|
|3||Localize for Spain, France, Germany||13||N|
|4||Customize software for Acme Corp client||3||N|
|5||Restructure site with better graphics, information flow||13||Y|
|6||Fix bug that “export” never worked on Mac OS X||8||Y|
|7||Implement import function||13||Y|
In this example, the team completed 63 estimation points in its 4 week Sprint. 42 points were capitalizable. If the total team cost (the total salaries for the team) for those 4 weeks was $112,000, then the capital expense was $112,000 × (42 ÷ 63) = $75,000.
If product owners write Product Backlog Items in a ritualized story form, it can be easier to determine whether it is a capital or operational expense. My preferred PBI story form, a variation of a form promoted by Chris Matts and Dan North [North 2006], helps clarify most classification work. It looks like this:
As a <stakeholder>,
I can <perform an action>,
so our company <receives business value>
- <acceptance test 1>
- <acceptance test 2>
In this format, you substitute specific values for <stakeholder>, <perform an action>, <receives business value> and <acceptance test …>. The stakeholder is never the team, but can be anyone else consuming the product: a user, a customer, a systems operator, a business analyst, or an administrator. If you aren’t serving someone outside the team, it isn’t really a “user story”. <Perform an action> should be something that the stakeholder can do that they couldn’t do before the Product Backlog Item was completed. <Receives business value> is a phrase usually articulated with the developing company in mind: Why are we building this? Will we get more users? Will users pay more for the product? We will gain a competitive edge or match a competitor’s features? Will we save operations costs? On rare occasions, the <stakeholder> can be a future developer, this accounts for focused efforts to reduce technical debt, however, make sure the acceptance tests confirm that future developers benefit.
Finally, we have acceptance tests. I counsel teams that acceptance tests should be written so stakeholders (usually non developers) can verify that the work was done, ideally in the Sprint Review. An acceptance test written for a team member to verify is not really an acceptance test.
Here’s an example:
As a systems operator,
I can monitor the current load on the system,
so the company can add machines if the load approaches the point where new users will be denied access.
- From the administration screen, a systems operator can easily find the load.
- If the load is in the green area, at least 50% more users can be added to the system without concern. If the load is in the yellow area, at least 20% more users can be added to the system without concern.
- When the load is in the red area, additional machines can be added to bring the load back to the yellow or green region.
This story should be capitalized, because it adds functionality not previously available, even though it serves a stakeholder inside the company. This subtlety is sometimes missed, but is clear from thoughtful reading of ASC 350-40, which contains the concept in its title “Internal Use Software.” Because most cloud computing and web site development projects run in the developer company’s machines, they are characterized as internal use software.
This format not only serves well for financial classification, but also has benefits in helping the team understand the context of its work.
What about tracking hours?
Whenever capitalization comes up, someone usually suggests that we “just track programmer hours.” This is a mistake, not only because it disrupts agile behavior, but also because measurement is likely inaccurate and not as verifiable.
Hour-by-hour financial monitoring slows down software development. Software development is creative work, and interruptions to track hours disturb the creative process. If we enforced hour-by-hour tracking with engineers, we would pull developers from their Zen state of thinking about the stakeholder, stakeholder actions, the acceptance tests and the code into a self-conscious state of thinking about what they did in the last hour.
So, to avoid the disruption, companies almost always simply ask engineers to fill out time cards at the end of the week, at best. By this time, the work they’ve done is lost in the fog of the past. In my experience, their weekly reporting is quite inaccurate.
Auditors support accounting practices that provide honest transparency while maintaining high productivity. Those auditors I’ve encountered acknowledge that hour-by-hour tracking is problematic. When I have suggested that proportionally allocating actual cost by story points would provide honest transparency, they have, at first, cautiously agreed.
In doing so, I make an assertion that “estimated effort” is highly correlated with actual work time. This assertion is defensible. The Scrum framework is designed to help teams drive toward high correlation between estimation points and actual time. Scrum provides better forecasting accuracy than waterfall, and teams that embrace Scrum principles examine their estimation points and outcomes, trying to ensure that their sprint forecasts are roughly met by the sprint result.
Auditors become enthusiastic supporters of this approach when they see the effect. When we track PBIs, estimation points and completion dates (sprint end dates), we know exactly which team did the work, we usually have a day-by-day task burndown and we have a proportional allocation. The PBIs we report are well documented and understandable (thanks to the story form). When auditors visit team members, the team members say the same thing executives say. This is an auditors dream: that managers and executives reporting aggregate data are verifiably backed by statements from individual contributors.
What happens in a transition to agile?
If you are about to embark on a transition from waterfall to Scrum, this is a great opportunity to consider changes in financial reporting. Agile approaches to software development are radically different from waterfall, and so justify a significant change in financial reporting methodology.
First, you can create a nearly bulletproof system for tracking engineering costs that eliminates the need to track actual hours. Auditors and financial staff will at first be wary with this new approach, then delighted when they realize that everyone—from developers to ScrumMasters to Product Owners to managers to finance staff—discuss the work your company does consistently and thoughtfully.
You may find that transitioning to a more accurate and responsible capitalization approach dramatically increases the amount of work capitalized. Your finance department should expect a high rate of capitalization, because the work of software development is usually an investment in a long-term future. However, a dramatic change can be seen as a red flag to them and auditors.
Address these concerns head-on. Explain that agile software practices make this detailed approach feasible. It can be difficult for waterfall teams to responsibly track which design efforts or project management tasks led to which features, while agile methods expose this information naturally through sprint backlogs. So, for example, in the past your company might have lumped post-investment-decision design work into the “Preliminary Project Phase.” This is not appropriate anymore.
Furthermore, because agile practices create releasable software every month, they can tie infrastructure development work with individual features, making them capitalizable. Some waterfall companies have felt that infrastructure work was so indirectly connected with user features that it had to be expensed.
Regardless of your situation, be completely frank with finance and auditors. If you expect your capitalization rate to increase dramatically, share that information with finance and auditors. Discuss why this will happen. And finally, explicitly connect it to your company’s transition to agile. Your commentary may actually appear in a company shareholder report, which you should welcome, proud agilist that you are.
If you have read this far, you are likely an enterprise agilist; comfortable with the idea that agile thinking should affect not just engineering, but also finance and other departments. Welcome!
Now that you know more about agile capitalization, your company has an opportunity to report its activities more responsibly to shareholders and tax authorities. It can require a lot of negotiation, planning and process changes to do so. However, your engineering group may be able to hire more engineers; your company may be able to reduce its tax burden significantly; and your company’s financial reports may stabilize. The value of these improvements may be in the millions.
For agility and the greater good, I remain your humble servant.
About the Author
Daniel R Greening, Ph.D. is Managing Director of Senex Rex, a management consultancy operating in the US and Europe. He designed and implemented the capitalization strategy used at Citrix Online, and advises companies on this topic. Dan leads enterprises in sustainable agile transformations. He is currently Product Owner for agile coaching internationally at one of his clients, a large software company. Dan previously led all-engineering process transformations at Citrix Online and Overstock.com. He can be reached at email@example.com.
Thanks to Dr. Mark Lane, Pat Reed, Walt Wycoff, David Starr, Erik Gibson and Vince Mills for their editorial help. Thanks to Citrix Online for its permission to share this information.
- [ASC 350-40] Financial Accounting Standards Board, 350 Intangibles–Goodwill and Other; 40 Internal-Use Software, (paywalled).
- [ASC 985-20] Financial Accounting Standards Board, 985 Software; 20 Costs of Software to Be Sold, Leased, or Marketed, (paywalled).
- [North 2006] Dan North, Introducing BDD.
- [15 USC 7211] 15 USC Chapter 98 – Public Company Accounting Reform and Corporate Responsibility (related to Sarbanes-Oxley)
- [26 USC 167] 26 USC § 167 – Depreciation
- [26 USC 197] 26 USC § 197 - Amortization of goodwill and certain other intangibles
- [26 USC 179] 26 USC § 179 - Election to expense certain depreciable business assets
Excellent idea, couldn't be more timely.
The question that comes up in mind is -
Is there not the danger that this exposes managers to start comparing team velocity in the endeavor to create uniformity in the "story point" sizing across teams and feel for productivity? Not only that but doesn't this also lead teams to game the sizing of stories, score everything big as after all it is relative size, and now give the appearance of attaining higher value.
Currently many environments have gotten in the habit of having their teams report time spent using time cards, usually wanting to pull this data from their agile tool of choice. This hinders agile adoption more than most realize, and as you rightly point out is inaccurate - mainly due to human nature and a thing called Goodhart's law. In essence, ask anyone "how much time did you spent?" is in a sense an onerous question and seen as micromanagement. This often leads to a defensive mindset, and focus on justifying time spent. Here in U.S and in particular California many companies do the time card thing without realizing they may open themselves to a rude awakening one day with the labor board on employee categorization viz-a-vi time carding.
Fundamentally, It is difficult to tease away the time measure given that taxation is based on $ spent/accrued over time. This aside were you able to verify this technique by looking back at the data and P&L charts?
Re: Excellent idea, couldn't be more timely.
Regarding Tarang's concern that managers will feel the need to unify story point sizing, we did not see this at Citrix Online. The practice I described in the paper allowed us to satisfy Finance, while also allowing each team to use different story point units. In fact, it removed some pressure and showed that more innocuous questions could be responsibly answered. For example, "what proportion of the time are engineering department employees working on Feature X?" could be answered without interfering with individual teams or exposing them to dangers. (Of course, when a team is operating as Scrum-of-Scrums from a single backlog, you <em>want</em> them to use the same reference stories and the same point scale. But that is a different topic.)
On the gaming question, no this does not lead to gaming. Each team has its own story point unit. We are interested in the relative amount of time a Scrum team spends on different features, we then compute the cost per PBI, we classify as expense or capital, and then we roll up. I suppose one concern could be that technical debt repayment, if put in a separate story, could be disadvantaged if classified as "expense". In our case, technical debt repayment leads to long term productivity improvements, so most such stories were classified as "capitalize". At the same time, our primary pressure was not to drive more capitalization or more expensing. People were most interested in accurate classification.
We did not process time cards. Of course, this would have been an interesting experiment, comparing reported actuals against pre-work relative estimates, but my motivation for creating this story-point based process was to avoid people having to use time cards. I was loath to introduce time-reporting as an acceptable behavior, because of the cost to productivity.
Thanks for your interest in this topic. It encourages me.
Capitalization and Software Development
Question on bounding iterations.
How do you determine which iterations should be part of the software asset? For some large development projects the iterations seem to continue on for a long time and it's difficult to set a date for when the capitalization effort should be stopped, i.e. when the project has ended.
Re: Question on bounding iterations.
All iterations following the "prototyping phase" should continue to be classified as capex or opex. In agile there isn't really a time when capitalization efforts should be stopped (unlike RUP/waterfall, where there's a "maintenance phase" that is only about fixing bugs, agile work has no such distinction). It's possible that your company can set a minimum spend when you stop trying to classifying work, and just send everything to the expense category. If you do this, you should document it.
I'm happy to chat about specifics by email firstname.lastname@example.org or phone +1 (415) 754 8311.
NO, NO, NO! Capitalization of software is a bad idea!
Capitalization can, in theory and in very specific circumstances, be useful, but for the most part, it should be avoided like the plague.
Item 1)In general, capitalization leads to less income, not more.
What? How can that be? Capitalization does not reduce expenses, it simply spreads them out over time. So instead of having $100,000 in expenses this year, you'll put down $20,000 for 5 years. Why is this bad? Expenses reduce your tax burden. So without capitalization, you pay less this year and more in the next 4 years. In econ class, we learned about the "time value of money". 1$ today is worth more than $1 in the future. So if we can arrange our taxable income over a 5 year period, ideally, we want our lowest taxable income to be this year and the highest to be 4 years from now. Capitalization does exactly the opposite. It increases our taxable income this year, thereby going against the time value of money.
The special exception to this rule is when tax brackets or losing money are involved. If you have enough expenses that it drops your income below zero, then the government doesn't give you extra for your losses. Similarly, if you can use capitalization to prevent tax bracket jumps in future years, then it may make sense.
Item 2) It forces managers to incorrectly prioritize work. I works at a company where software capitalization is a priority and can verify this first hand. An employee wants to take a 3-day course on Node.js and proposes it to the manager. Well, "I would," says the manager, "but training expenses are not capitalizable and Bob has been sick, so we haven't met our cap numbers for the month. Maybe next month." Similarly, another employee wants to spend some time investigating whether a switch to a CQRS architecture would be appropriate. That is not capitalizable and likely to be declined. A 20% free time policy, like Google has. Nope, not capitalizable.
The follow up result is then to play games with the work. Well, you can't learn about Node, but let's add a feature to an upcoming project that requires Node and then we'll throw the expense for Node training under that project. Let's make a CQRS architecture investigation part of another project. Play games with the work so that you can get what's most important to be capitalizable.
Item 3) It is a method of stock manipulation. This is the main reason for capitalizing software expenses. By capitalizing the expense, only part of the expense goes down as a expense and the rest gets classified as an asset on the books. This makes your company seem more valuable. When you buy a building worth $100,000 and depreciate it over 10 years, you do it, because you know that the building is going to last 10 years. Someone buying the company knows that they've got a building that has value and, if necessary, sell that building. At any time, an auditor can go out and say, look, there is the building that we've got on the books.
Classification software development as capital puts on the books holds no such reassurances. I can spend $1million on software development for a new section of the site and then shut down that section of the site 1 month later and yet it will remain on the books as an asset, because actual classification of the true value of software isn't done, because it is too difficult.
Re: NO, NO, NO! Capitalization of software is a bad idea!
- Argue that waterfall software development isn't capitalizable either (John W's argument). Companies that can invest in software development and non-software assets will favor non-software assets, leading to less profitable outcomes. Executives should be free to make unbiased decisions to help the company succeed.
- Show that agile software development is capitalizable (my argument). This creates an even playing field for agile and non-agile software development. If agile generates more long-term value, agile will eventually win. If software generates more money than non-software assets, software will eventually win.
Let's go point-by-point through John's claims:
- Item 1: Thoughtful capitalization can lead to lower taxes and more stable P&L statements. My article shows this. The "special exceptions" John mentions are more common that he implies, because few companies make money every year. You can't suddenly decide to capitalize software because you happened to have a money-losing year. You have to decide how you are going to handle software and stick to that practice long-term.
- Item 2: John cites that training is not capitalizable. True enough, and appropriately so. If programmers were required to stay at the company after we invested in their training, i.e., if people were "assets" we could own, we could claim training should be capitalized. However, they can easily leave and take their learning with them: slavery is outlawed in most countries. Research has a similar problem, that we have little certainty whether it will generate an asset.
- Item 3: Classification can be misused, but misuse can go either way. A company developing a slam-dunk software package with market evidence showing large future profits could elect to expense its development, resulting in a loss, making the company's stock unattractive and causing its price to drop. Insiders could then buy the stock at a low price, knowing that the stock will have big gains later on. Now we have stock manipulation by applying John's absolute that all software development is expense.
Of course, some software efforts are speculative, just as many non-software investments are speculative, but impairment takes care of those. John cited a false example: If we invest $1M in a new section of our website, then shut it down a month later, this is called an "impairment" of our asset, and we must immediately expense our previously capitalized development. This is discussed in the article.
I wrote this article carefully, recognizing that capitalization wasn't necessarily the right answer for all software development.
We treat shareholders and tax authorities most responsibly when we capitalize long-term investments. Software development is often a long-term investment, otherwise most companies wouldn't do it. If software development was just an expense, copyright and other types of intellectual property protection would be pointless.
Agile practices make software's value apparent very early in development, making agile software a better investment. Agile development creates more predictable outcomes, like most good assets.
Re: Question on bounding iterations.
Regarding bounding iterations, the approach I'm taking is using the idea of themes or epics. Bottom line, when the epic or theme is "released" to customer facing product, I send info to finance stating how much of the accumulated sw cap applied to that feature and should be amortized. Released in our form, is available for sale and customer use so I believe it lines up with the finance terminology. I track accumulating sw cap using a similar approach with story points and ratio-ing them to the hours logged in the time system. Yes, we are logging our hours but I think it is not excessive and still provides appropriate control for the finance folks. The part that is eating me up a bit is stuggling with the granularity of our themes and epics. However, I like your approach of tagging sw cap within the product backlog tool. Our problem is our backlog doesnt overtly address grooming, which we have categorized as non sw cap. Additionally, we have several roles like BAs and algorithm engineers that support the team who's work is not represented on the back log.
I love the thread and will be watching for more insights!!!
I do have one question that relates to User Experience. I understand that design time should be capitalized, but what about the time expended during testing. We typically have outside users (docs and nurses) testing our releases, lead by our UEX staff. Should our UEX staff time also be capitalized during the “testing process”?
Thanks again for making this difficult concept more understandable!
Re: Great Article
In cases where the outcome of UX testing intends to learn more and thus direct how to improve the value of the asset and where the overall project is budgeted and approved, User Experience testing is capitalizable. This is the majority of cases, in my experience.
In cases where UX testing is used to qualify products for purchase, to assess whether to invest in otherwise speculative prototype projects, or to tune a particular bespoke solution for one customer, of course, UX testing would be expensed.
In short, if you are capitalizing the software development, you should be capitalizing the UX testing, as well.
How do you handle threshold requirements for capitalization?