It is a common misconception that moving to agile delivery will increase an organisations opex, i.e. those costs that charged to the company immediately when they are incurred, this is as opposed to capex or capital spend which can be spread over a number of years.
In a traditional waterfall delivery costs can generally be capitalised once the project moves into delivery phase all the way until go live. However, we an agile delivery method the process blurs the lines between design, delivery, test etc. so how do you know what to capitalise and when?
So first a few accounting ground rules, and these will be more or less applicable to you and your organisation deepening on how embedded agile is within the company and how support is maintained.
- Project initiation and evaluation stages are always opex as you don’t know what the outcome will be, these are essentially R&D.
- Software development and configuration is potentially a capital cost, more on this later.
- Post implementation warranty periods are opex.
- Support and day to day running are opex e.g. licences (unless they are perpetual licences) and support/maintenance.
Software Development and Configuration
If the IT department are delivering value i.e. new products, new features etc. then these costs can be capitalised it is when the delivery consists of bug fixes and maintenance tasks that the costs should be taken immediately as opex.
The challenge therefore is to accurately capture these costs within the accounting records, and this is where agile delivery can partner successfully with Finance, maximise capital spend and satisfy auditor requirements.
This can be achieved whether you time record or not, but the easiest way to capture capex is to class work by roles e.g. developer and testers are capex as they add future value, their effort is easily linked to the output whereas a project manager is opex as their output is less easily identified within the delivery.
This is a simple, crude and effective methodology to follow in capitalising agile development costs.
Improved and Accurate Approach
A better way to capture costs for capitalisation would be to take advantage of the agile tools already in use within the business e.g. Jira, and have each story point flagged as either opex or capex, this will then allow reports to be run on a particular sprint or time period to give the percentage of the delivery that was capex. Taking this and applying it to the relevant people costs will give you the costs to capitalise for the delivery.
The definitions for opex and capex should be obtained from your Finance team and test runs done on previous deliveries to ensure they outcomes are as expected.
When deciding if costs can be capitalised or not this should always be done in conjunction with the finance professionals within your organisation.
Whether to capitalise costs or not should be based upon what is being delivered and not how it is delivered, if IT are delivering real business value then the appropriate costs need to be robustly identified, captured, pooled together and capitalised.
An interesting article on this topic by Dan Greening can be found at www.infoq.com/articles/agile-capitalization, dated 2013 but still relevant today as agilists continue to struggle with the progress of support functions to transform along with them.