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.
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) thats 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 its financial counterpart can undermine the very compliance theyre charted to automate.
This thought is even more apropos of software thats 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.