Software Capitalization for PMOs: a Not-So-Quick Primer

by September 5, 2017

As agile becomes a way of life for IT organizations, more PMOs and IT senior management have been revisiting their understanding of how to correctly implement the Accounting Standards Executive Committee’s Statement of Position (SOP) 98-1. Essentially, this SOP allows companies to capitalize internally developed software in the same manner as purchased application software. On the surface, the ins and outs of how to handle this SOP should be easy to understand, especially since, in theory, it mirrors an earlier ruling (FASB-86) on capitalizing software developed for sale.

According to my reading of SOP 98-1, all the preparation and time spent on the front end of a software development effort should be treated as a period expense, and everything that happens after the development effort reaches production (bug fixes, etc.) is excluded from capitalization. When SOP 98-1 was first implemented, many organizations used their waterfall lifecycle to define when capitalization should begin and end. Today, with more organizations adopting business agility, insisting that waterfall methods are the only ones supported by SOP 98-1 is simply incorrect. But many organizations are struggling on where to draw the lines.

A clear understanding of the original principles that underlie agile software development will quickly prove that applying the few stated guidelines of SOP 98-1 to agile should be simple. The envisioning phase is an expense, work done during the build/create phase should be capitalized and the post implementation phase should be expensed. I’ve glossed over a few corner cases and some details, but in principle, it really is that simple.

So why is SOP 98-1 coming back on everyone’s radar after all these years? Like everything else in life, the answer is complex and includes politics, poor agile practices, horrendously bad resource management practices, EBITDA and, finally, what I refer to as “the smartest guys in the room syndrome.” All of which is making what should be a simple concept more difficult than it should be.

Counting down the complicating factors

Politics: Many PMOs don’t want to let agile in the door and invoking the fear of internal audit can be very effective. On the flip side, many development teams see agile as a way to get the PMO off their back and are looking for ways to use SOP 98-1 to their benefit, which we’ll discuss later in this blog.

Terrible resource management: Everybody in IT is too busy doing too many things, which makes planning the right work and later tracking that the “right” work is getting done difficult. This situation, in turn, makes the politics worse and makes everyone unhappy.  Unfortunately though, not unhappy enough to change things.

EBITDA: Wall Street has adopted a non-GAAP financial reporting measure (earnings before income taxes, depreciation and amortization) that effectively creates the illusion that IT capital expenses are free. They aren’t, but there is a great deal of pressure to make sure that everything that can be considered capital is capital, which is driving some agile pundits to get a little creative.

The smartest guys in the room syndrome: Given that capital is good, the smart individuals associated with agile are now purporting that agile methods will let organizations capitalize more of their development work than they can with conventional standards around waterfall development. While this concept sounds great in theory, it will not have a pretty ending in practice, when the auditors and senior management get involved. Real-time capitalization based on a Scrum Master determining that something should be capitalized honestly makes me shudder, not because I don’t believe the Scrum Master will try to do a good and honest job but because what to capitalize, when and how much is a complex, multifaceted decision with potentially significant financial ramifications.

A better way to approach software capitalization

What everyone, including the Accounting Standards Executive Committee, wants is a simple way to get reliable information about how the company’s money is being used. This reliable information must include budgets, actuals and forecasts as well as what’s capital and what’s operating expenses. In today’s digital business world, good financial reporting must also include what’s being spent on running the business and what’s been spent on innovation and development of digital products.

I contend that we can’t come up with a simplified approach to SOP 98-1 until we understand that it’s not just how much we spend on operating expenses and how much we spend on capital. It’s how much money we spend improving back-office systems that could be better spent on new capabilities or new digital customer-facing software. We need tools and practices that allow us to define why money is being invested in capital and the value that will be returned from the investment. 

These tools and practices will let us define how the money we planned to spend is being spent. We also need the ability to do real-time updates (forecasts) that allow us to make more effective decisions and changes to keep from wasting our money. In the final analysis, the crux of SOP 98-1 is that we shouldn’t have to recognize the cost of a long-term asset as a period expense. Whether we create that asset using waterfall, Scrum or some future approach to software isn’t relevant, and SOP 98-1 was never intended to dictate a specific development method.

In a future white paper, I’ll explore in more detail how the concept of the business value of the asset as defined by its contribution to the enterprise strategy is what we should be attempting to optimize in how we approach SOP 98-1. Once we know exactly why we are developing the software and how valuable it will be to the enterprise, capitalization approaches will become much clearer.