Software Capitalization in Atlanta
Yesterday’s Agile Success Tour event in Atlanta was characterized by quite a strong interest of various participants in software capitalization. While the topic came up in previous success tour events, it was more pronounced in Atlanta. A subtle shift seems to be taking place: from technical aspects of rolling out Agile to business aspects the Agile champion needs to be aware of and prepared to address.
In the course of exploring software capitalization, participants in the Atlanta event brought up related questions about “the business of Agile.” For example:
- Cost accounting for Agile
- Return on the Agile investment
- Agile Portfolio Management
- Governance of the Agile project/initiative
Some of the participants were quite thoughtful about the dividing line between project-level Agile implementation and Enterprise-level implementation. They grasp that scaling Agile changes the nature of the questions one wrestles with. A few of them are actually considering top-down approaches to implementing Agile. They do not necessrily subscribe to rolling Agile in a bottom-up manner. They devote quality time to wrestling with Agile scaling issues prior to starting the first Agile project.
I am hesitant to draw general conclusions based on a single event in a particular city. For example, I wonder whether the emphasis on capitalization might be related to the concentration of Supply Chain Management firms in Atlanta.
As the Success Tour “train” continues its journey (next stop: Washington, DC on July 23) we will soon have additional data points. Stay tuned…
The Agile Executive 
Israel, Can you provide more detail here? I know software capitalization rules and SOP’s differ for ISVs (FAS 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed), and IT (SOP 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use).
I also believe data suggests fewer than 30% of ISVs capitalize R&D expenses, but those that do are often aggressive, capitalizing at a high rate so that their expense lines look better than if they did not capitalize these costs.
What I’m most interested in is their questions on “what changes?” with Agile, and how we can help.
Richard
Richard Leavitt
June 30, 2009 at 8:40 am
Well, Richard, if you only knew how much scar tissue I got on the subject of software capitalization…
The fundamental issue is what criteria need to be satisfied in order for software to be capitalized. Much depends on how strict or lenient an auditor is with respect to “working software over comprehensive documentation.” The rule of a thumb I use is that demonstrable software qualifies for capitalization. Practically useful that a rule of a thumb might be, it is not a substitute for broadly accepted criteria.
Perhaps the thing to do is ask the Agile Alliance to start a working group on the subject. Much of the work could be done by volunteers from the Agile community. However, the group is likely to need access to and cycles of a competent professional auditor.
It would be a little speculative on my side to assume we will be seeing more companies capitalizing software. However, as so many companies nowadays are looking at various ways to improve their balance sheets, software capitalization is an avenue which is being considered in various places.
Israel
Israel Gat
June 30, 2009 at 12:08 pm
Israel,
I agree this can be a huge issue. Actually in my experience, I’ve seen a few issues. First, what type of work can be capitalized? In the past, I’ve capitalized new products and major new features. Maintenance is often excluded. The challenge, however, with Agile teams is making this distinction when Quality ( aka defects ) is baked into the process and backlog. Simply capitalizing stories ( and not defects ) is often not an accurate representation.
The second issue is getting accurate data. This is both a tooling and a process issue. I remember speaking with a software executive last year that had a multi-million fine from the IRS because they had almost no record of the time they capitalized.
It’s for this very reason that Rally just released the Beta of a new Time Tracking capability. Our theory is that if developers can easily enter their time while they’re updating their task status and work remaining that it will be inculcated in their daily routine. No developer wants to be bothered with time entry, so it needs to be light and easy.
The fact is that many Software executives cannot simply ignore governance or “business” issues. We’re spending lots of time figuring how to meet those requirements while balancing the empowerment that Agile teams need to achieve success.
-Todd
Todd Olson
June 30, 2009 at 12:59 pm
Todd, I think you put your finger on an extremely important issue – capitalization in the context of software evolution. Best I know we don’t have
a broadly accepted definition what “new” is for evolving software.
This is huge – the cost of evolving (and maintaining) software trumps the cost of “pure” development.
Israel
Israel Gat
June 30, 2009 at 2:37 pm
[…] Capitalization of (Agile) software […]
Agile Considerations for CXOs « The Agile Executive
July 1, 2009 at 10:45 am
See http://tr.im/qUxb for additional coverage of the Atlanta event by Nate Skinner.
Israel
Israel Gat
July 4, 2009 at 4:43 pm
Click http://tr.im/qUy8 for additional comments by Nate on the Atlanta event.
Israel
Israel Gat
July 4, 2009 at 4:48 pm
[…] a comment » Darren Shipp made an astute observation during the recent Agile Success Tour event in Atlanta: The problem is not transitioning from Waterfall to Agile. The real problem is transitioning from ad […]
From ad hoc to Agile « The Agile Executive
July 9, 2009 at 7:46 am
[…] a comment » Various posts in this blog (click, for example, here, here, and here) brought up noteworthy threads from the Q2 Rally Agile Success Tours events in Santa […]
Q3 Agile Success Tour: Boston, Seattle, Chicago and London « The Agile Executive
August 9, 2009 at 7:09 pm
An employee allocated to a project, but has been idle for 20% of his or her time. Can the salary paid on these idle hours be capitalized under SFAS86.
Babu Muralidharan
January 13, 2010 at 3:03 am
I don’t know that there is a black or white answer to this question, Babu. Much depends on the flexibility (or lack thereof) of the company’s auditor. A critically important factor is how well the CFO stands up to pressure from the auditor.
Israel
israelgat
January 13, 2010 at 6:34 pm
Hi Israel,
Capex vs opex for Agile and iterative dev is a subject dear to my heart (right next to the scar tissue …). Do you know if any progress has been made in the Agile community on this, either formally (eg a working group) or informally (someone coming up with proposals in a public forum)?
Thanks,
Michael Gentle
Michael Gentle
March 10, 2011 at 4:59 am