For example, a company that uses a highly structured software development process such as CMMI might capitalize more of its software development costs than would a company using rapid prototyping techniques such as Agile.
This is because structured development approaches often separate product requirements and program design from program development, whereas coding and design often occur simultaneously with newer development techniques such as rapid prototyping.
Under the former scenario all of the software development costs are eligible for capitalization. None or much less of it is eligible for capitalization under the latter scenario.
Accounting Guidelines
Firms follow Financial Accounting Standards Board (FASB) guidelines when accounting for the costs of computer software developed (or obtained) for internal use.
First, they consider the following two characteristics to classify software as internal use software:
There are three stages identified in the development of qualifying software:
Costs associated with the preliminary project and post-implementation/operation phases are expensed as incurred. Costs (internal and external) associated with the application development stage are capitalized.
Capitalization of costs begins when the preliminary phase is complete and management has implicitly or explicitly committed to funding a software project with the intent it will be completed to perform the planned functions.
Capitalization ceases no later than the time when substantial testing is complete and the software is ready for its intended purpose or rendered in service.
Capitalization intensity (capitalized development costs/sum of capitalized and expensed development costs) is a proxy measure for the success rate of software projects.
This ratio is of interest to senior management because it provides an evaluation of a project (or portfolio of projects) that’s somewhat independent of the report provided by its project management office.
It may be somewhat heretical to point out that even a good-faith collaboration between IT management and it’s financial counterpart can undermine the very compliance they’re charted to automate.
This thought is even more apropos of software that’s developed for sale. In this latter case, the guidelines are different from those outlined in the previous section and can produce even more variable results … but this is a subject for another discussion.
Marcia Gulesian has served as software developer, project manager, CTO, and CIO over an 18-year career. She is author of well more than 100 feature articles on IT, its economics and its management, many of which appear on CIO Update.