Project Management Institute

Accounting for agile projects


Ram Srinivasan, Terry Quan2, and Pat Reed

To keep up with business demands, companies are increasingly moving towards adopting Agile methodologies, where the emphasis is on iterative and incremental software development. Agile software development has many benefits including increasing responsiveness to customer needs, lowering risks and costs, and providing greater visibility. However, for companies adopting Agile methodologies, accounting (particularly capitalization of development costs) can be challenging. Existing accounting guidance addresses software development that occurs in longer-term and more discrete phases, rather than rapid development.

Traditional Software Development Life Cycle and Accounting

Traditionally, companies developed software applications in phases. Software was developed after an idea was analyzed, deemed feasible, and approved. A pictorial representation of this long-term, phased approach, often known as waterfall software development life cycle, is shown below.

Exhibit 1: Waterfall software development life cycle

Waterfall software development life cycle

This approach assumes that all requirements are known up front and that the software will still be valuable when delivered. Based on these requirements, project plans are created, and cost, time, and resources are allocated. However, the actual software may be delivered many months later.

Exhibit 1 corresponds with the three phases of accounting (AICPA's Statement of Position 98-1) for software development: (1) preliminary, (2) application development, and (3) post-implementation. Feasibility analysis matches the preliminary (expensed) phase; requirements analysis, architecture and design, and coding and testing match the application development phase (expensed and capitalized); and deployment and maintenance (expensed) matches the post-implementation phase.

Agile Software Development

In many industries, the traditional, phased approached to software development can no longer meet market and consumer expectations. Companies cannot invest tens of millions of dollars in software that is obsolete by the time it is deployed. This is particularly true of companies use web and mobile platforms for offering their services.

To increases the responsiveness and decrease the risk, companies are increasingly moving to Agile software development methods. Agile methods may differ in implementation, but they are iterative and incremental, and share the same values and principles as outlined in The Agile Manifesto. Agile methods/frameworks include Extreme Programming (XP), Scrum, Adaptive Software Development (ASD), Crystal, Dynamic System Development Method (DSDM) and Feature Driven Development (FDD). Scrum is the most popular Agile framework. Scrum emphasizes on building software with a dedicated cross-functional team, and the software itself was built in an iterative-incremental way.

An Agile project begins with a charter and a business need. The charter identifies the customers, feasibility, high-level features, and source of revenue, as well as why the project may be valuable to the organization. Unlike traditional waterfall development, the requirements are never frozen and requirements are always progressively elaborated. New requirements may also be discovered as and when the project is getting executed. Once the charter is approved, the project moves into the “application development phase,” where the product is developed in iterations or sprints

The goal of each sprint (or iteration) is to build a small increment of the application, get feedback from relevant stakeholders and learn from it, and modify the next set of requirements for the next sprint.

Challenges in Accounting for Agile Software Development

The move to greater use of Agile methodologies has at least two accounting issues. First, there is a difference in the completeness of requirements defined up front compared to traditional, phased development. Second, in traditional, phased development, the preliminary phase, the application development phase, and the post-implementation phase are distinct. In an Agile project, it may be hard to disentangle some of the application development and post-implementation phases.

In the phase-based approach, all the requirements are known up front before coding begins. In Agile software development, not all requirements may be known up front. Some of the most important requirements are known up front, but through each Sprint (or iteration) more requirements may emerge, and some requirements may be dropped.

Secondly, with Agile frameworks, there is an emphasis on getting feedback from customers and stakeholders. Many organizations also adopt continuous integration and deployment practices. In fact, the entire build and deploy may be automated, thereby reducing the chances of manual errors. The build and post-implementation phases appear to merge. For example, teams that are adopting continuous deployment strategies may deploy and get feedback many times in a short time span, sometimes as short as a day. This feedback helps the team become more responsive to business needs, but now the development and post-implementation phases may not be clear.

Possible Solution

To meet the challenge, accountants and project managers can revert to the definition of an asset and capitalization. Let's examine Agile in the setting of a three-phase software development project, including (1) the preliminary project phase, (2) the development phase, and (3) the post-implementation phase.

Projects begin with a charter and the preliminary project phase, in which the team examines the feasibility, technical viability, and potential customer benefit. If it is determined that there is enough stakeholder benefit, management (or its designee) approves the project. Expenses, including costs related to the strategic decision to initiate a project, are estimated; requirements of performance and systems are determined; vendors are identified; and technical capability is shown. Also, alternatives to building are explored. Consultants, if any, are selected. Because all the costs related to these activities are exploratory, they are expensed.

The development phase comes after the preliminary project phase. The funding decision signifies the start of this phase. In the traditional, phased approach, requirements are known before funding is approved for the project. In an Agile project, all requirements may not be known upfront. However, managers approve the budgeting for the project and know that requirements may be added, removed, or adjusted after each Sprint. In an Agile project, after the approval decision, some activities in the development phase are capitalizable and others are expensed. Capitalizable expenses include design, coding, and testing costs. They also include the purchase and installation of hardware and software, and data conversion to the system. However, some costs cannot be capitalized, such as training costs, auxiliary data conversion, and general, administrative and other overhead costs.

The post-implementation phase includes deployment support, training, and evaluation. The post-implementation phase is expensed. Examples of post-implementation phase activities include completion of documentation, certifying that the system is operational, training, post-implementation review, and routine maintenance activities. In the traditional phased development, this phase is clear, but in an Agile project, especially with rapid development and near continuous deployment, the beginning and end of this phase may not be as clear.

However, even in cases where there are many threads of development and implementation going at once, teams almost always keep track of a period of stability before they move to maintenance. Once a thread moves into maintenance, it is expensed as part of the post-implementation phase.

Benefits of Certainty

The certainty of how to account for software development costs, expensed or capitalized, can affect project approval. Companies, including their accounting and finance departments, are usually concerned about budgeting and reporting financial results. Expensing or capitalization of software development costs, especially when they are rising, can affect net income.

Accounting and finance departments have other important objectives, such as reporting results to investors, either directly or indirectly through analysts. In cases where management has already given guidance to analysts on earnings for the quarter, not meeting these expectations can have significant stock price effects. How a software development project is accounted for may affect the timing of the project approval.

Moreover, accounting for software development is increasingly becoming a concern, even for companies that are not in software development. These include companies that are not in the software development industry but whose core business is in retail, financial, healthcare, or other industries. Some of the larger companies pay millions if not hundreds of millions of dollars in software development each year.


1 Disclaimer: This document does not offer specific accounting advice, but presents a practical and viable approach to capitalization of Agile project labor costs. However, each project is unique and company policies may differ. Please consult with your technical accounting, financial reporting, and internal audit staff to review your internal capitalization policies.

2 Ram Srinivasan has a unique distinction of being a Certified Scrum Trainer, an Innovation Games® Instructor, and a professional coach specializing in coaching organizations. His mission is to help his clients build great organizations, and he does this by focusing on people, process, and product development. He also holds multiple Agile and project management–related certifications.

Terry Quan is currently a partner with EAmmune, an IT security company, and regularly works with those in the application development process. Terry has passed his qualifying exams at The University of Chicago Booth School of Business, and he has taught financial accounting theory to MBAs at Fordham University.

Pat Reed is on the board of directors of the Agile Alliance and a principal at iHoriz

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2014 Ram Srinivasan
Published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA



Related Content

  • PMI White Papers

    How Agile are Companies in Germany?

    By PMI Cologne Chapter Until recently, Agile was considered as a set of principles and practices relevant only to software development projects. However, Agile is now spreading to other parts and types of organisations,…

  • PM Network

    Agile Capacity

    By Parsi, Novid Wrong resources? Right resources at the wrong time? Both can cripple project momentum—and send shock waves across the project portfolio, even threatening the organization's bottom line. And the…

  • White-Paper-Cologne-thumbnail.jpg

    How Agile are Companies in Germany?

    By PMI Cologne Chapter Until recently, Agile was considered as a set of principles and practices relevant only to software development projects. However, Agile is now spreading to other parts and types of organisations,…

  • Design Thinking to Improve Your Agile Process

    By Vukosav, Denis Agile project teams interact with users and deliver incrementally. This paper is an introduction to how design thinking, combined with agile, will further reduce the risk of failing.

  • PM Network

    Practical Guidance

    By Fewell, Jesse The debate about processes—when to follow them versus when to bend them in favor of deeper principles—has been an age-old, fundamental tension in project management. Those of us contributing to A…