R&D record keeping during 'agile' software development

R&D record keeping in agile software development 

A practical guide:

As detailed in the last blog post and in response to the Tax Payer Alerts issued last year (see our summary here), RSF has developed a simple and practical guide to better assist companies with R&D record keeping.

Increased regulator activity from AusIndustry and the ATO means heavier scrutiny is being placed on R&D claims and reviews. In the interest of improving claim strength and facilitating quick responses to regulator reviews, it is necessary to retain simultaneous documents that substantiate both:

1.     The R&D activity occurring, and

2.     Employee effort attributed to it.

This guide aims to leverage existing IT project management processes where possible for easy record keeping.

Firstly, the requirements on Record-Keeping and R&D Planning as defined by AusIndustry can be found on the business gov website, with particular reference to Record-keeping requirements;

“The R&D Tax Incentive operates on a self-assessment basis. This means claimants are responsible for determining whether their activities and expenditure meet the eligibility criteria* of the program, and for maintaining records to support their registration or claim.”

*More information on which entities are eligible for the R&D Tax Incentive can be found on Page 7 in the AusIndustry Customer Information Guide.

During the progression of an R&D project, activity and efforts are captured across various modes, however, typically not in a format commonly recognised by the regulator. It makes sense to utilise existing systems for record keeping, whilst minimising the introduction of alternative measures.

IF IT AIN’T BROKE, DON’T FIX IT

Four commonly used methods are detailed below, along with how to leverage these for record keeping purposes. This creates substantiating documentation over the course of an R&D project.

1. AGILE AND STAND-UPS

It is not uncommon for companies to have regular stand-up meetings as a key part of their R&D project development methodology. During these short meetings, each developer identifies that they are working on, challenges they have encountered, and what happened to issues discussed in the previous stand-up. This allows team members to identify issues within the development. It is also a great opportunity to document work and challenges in real-time.

It is also useful after each 1 to 4-week Sprint of work to have a formal review to assess performance and plan any changes to future plans. For larger companies, the minutes of board meetings relating to the progress of R&D activities may also be recorded.

In a spreadsheet, the stand-up leader should record a line for each developer on a weekly basis, detailing what technical issues they are encountering and quickly classify them according to its feature area. Some of these areas should be previously claimed activities, if they are continuing into this year.

Copy formal reviews and/or board minutes, especially any discussion  of technical challenges that arise into your ongoing R&D  documentation folder.

2. VERSION CONTROL AND MANAGEMENT TOOLS

Two common applications of version control and project management tools are Git and JIRA. Git, including hosted services like GitHub, manages committing code to project repositories. A developer can export all of the commits made on a report by using the following code into terminal (for the relevant time period):

git shortlog -sne --since="01 Jul 2017" --before="30 Jun 2018"

The balance of commits against R&D repos and non-R&D repos can give a regulator an indication as to how much of a developer’s time can be claimed.

Likewise, JIRA - depending on the particular implementation - enables issues to be filtered by sprint, type or a custom classification key. It is also capable of recording who was assigned and how much time was taken to resolve the issue. Issues can be filtered for a selected time period and exported to Excel, which can be classified on the basis of the categorisation method chosen. Individual percentages and efforts can be derived from there.

If a classification does not currently exist that maps closely to the activities being worked on, it is advisable to add a new key or tag to issues that do. This allows very strong substantiation to be assembled quickly, with minimal disruption to existing workflows.

Which option is best depends on what you are able to classify against the R&D activities. If your GitHub repos aren’t granular enough, then classifying JIRA issues by sprint may be preferable.

This allows a time-apportionment to be calculated against each developer.

Copy documents detailing assignment up to date into your ongoing R&D documentation folder.

3. TESTING SUITE AND CONTINUOUS INTEGRATION TOOLS

Many software companies run testing environments that allow hypotheses to be articulated, implemented in code, and tested against pre-defined suitability criteria in a rapid fashion. This development paradigm enables companies to run hundreds of such experiments each day.

This allows companies to find and address bugs more quickly but is also great from a documentation perspective, with industry regulators reemphasising the importance of R&D being done within a formal experimental structure.

There are many different testing and CI tools, as well as tools to monitor server resources. Consider how your system may be able to compile a log of tests – both successful and failing builds over time – against Git commits or JIRA issues, especially if you already have a good R&D assignment in place. Ideally, we would then be able to show identified performance metrics such as page load improving over design iterations.

4. CONTRACTS AND CONSULTING

When writing contracts and invoices, adding a reference to the specific R&D activity it contributes to amounts to strong record keeping. This is because the ATO seeks specific references to “R&D. Note that while certain roles absolutely contribute to the research that defines technical requirements and direction of R&D activities, the regulator may frown upon association if they have been misreported in the accounts as “marketing” or “sales”. As such, it is important to ensure that the role description is accurate with regards to R&D activity contribution and appears consistent across contracts, invoices and the books.

On the other hand, when undertaking R&D while consulting for someone else, there are two areas where eligibility for the R&D Tax Incentive may be undermined:

1.     Remuneration for the work must be “at risk”

·       Meaning it is entirely contingent on being able to attain a specified outcome, where failure to achieve said outcome would result in a fee to not be paid out; and

2.     To claim the incentive for the development of any IP, you must have effective ownership of it

·       Meaning you have retained the right to commercialise it outside the niche implementation you were contracted for.

The above two points should be discussed with lawyers to best cover for future engagements.

The finance team should also consider the ideal classification of expenses generally as they occur. For example, instead of recording server costs under the one-line item, split off the servers supporting your R&D under “R&D Expenses”. Remember, in order to claim capital expenses under the R&D Tax Incentive, they must be nominally depreciated under Division 40, rather than the small business write-off.

Copy contracts and any research artefacts produced into your ongoing R&D documentation folder.

[disclaimer: the measures for record keeping above should be used as a guide only, with specific examples only used to illustrate direct application of the principles described. Further information on record-keeping can be found at AusIndustry source]