How to do eligible R&D for Systematic Progression of Work
One of the ways AusIndustry assesses an eligible R&D activity is by ensuring that it follows a systematic progression of work. The recently released Software-related Activities and the Research and Development (R&D) guide provides insights into what this means, and how this can apply to software development.
What is a Systematic Progression of Work?
A core activity follows a systematic progression of work if it starts with a formulation of a hypothesis, followed by experimentation to test the hypothesis, evaluation, and finally, drawing of conclusions. The list below describes each component of a systematic progression of work:
1. Hypothesis
A hypothesis is usually a statement or set of statements that describes how you can achieve a particular outcome. It is useful to think of a hypothesis as (1) an idea or theory formed with the intention of achieving the outcome, (2) an explanation of how you can achieve the intended result/s, and (3) a description that shows why the result/s may be falsifiable or may not be achievable. The hypothesis should also highlight how you plan to conduct the experiments.
2. Experiments
These can be a series of activities i.e., different iterations or versions of the code, variations of a program, attempts at solving a technical problem, etc. AusIndustry expects applicants to detail how they conducted or how they plan to conduct experimentation. It is important to describe parameters you fine-tune during the experiments, parameters that are constant throughout the experimentation, and variables being measured and observed. It is worth noting that even if the experiments did not lead to a positive outcome or were abandoned, they are still valid as you only need to show that there was a process involved to make it a qualifiable core R&D activity. You must ensure that the experiments correspond to the hypothesis.
3. Observation and Evaluation
This is where the results achieved in the experimentation are observed, measured, analysed, and recorded. The information you write here can be descriptive and/or quantitative. In this section, you need to consider what the results of your experiments mean and explain your insights in relation to the hypothesis. AusIndustry expects your records to prove that a careful analysis of the results of the experiments has been conducted to determine why the desired technical goal of the core R&D activity was achieved or not.
4. Conclusion
This is the final part of the systematic progression of work that confirms your understanding of the core activity. Following evaluation, you are expected to provide a categorial or measurable outcome for each of the experiments undertaken. Your conclusions must include a statement about why your findings support or refute the hypothesis. And if it negates your hypothesis, you can show the need to look at different solutions or formulate a new hypothesis.
Is there a place for a systematic progression of work in modern software development life cycle models?
Although the term “systematic progression of work” may be easy to associate with scientific procedures or traditional software development life cycle approaches, it is not at all impossible to show that a systematic progression of work has taken place in projects developed in modern software development approaches such as Agile. For instance, recording a hypothesis statement before the sprint planning step of the Agile process is a great way to prove that the hypothesis part of a systematic progression of work was accomplished. Another example is writing an evaluation and observation report after every iteration of the sprint review to ensure that the evaluation aspect was also achieved. AusIndustry expects that you will be able to prove that the outcome cannot be determined in advance during the development process. You must also show that the methodologies you followed for software development were used as part of a systematic progression of work.
Any changes or updates in the interpretation of Systematic Progression of Work?
In the latest Software-related Activities and the Research and Development (R&D) guide, AusIndustry has shown that it recognises the following activities can be a part of what is considered an experimental work of a core R&D activity:
- System testing
- Testing of Requirements
- Data mapping and migration testing
- Evaluating the efficacy of various algorithms that have been proven to work
- Testing operational websites by counting the number of hits
- Digital transformation activities (manual process to a digital one)
- Technology upgrade
- Routine computer and software maintenance
- Data manipulation
Nonetheless, we suggest companies to be careful when claiming core R&D activities in which the experiment involves large parts of the activities above. This is because such activities, specifically testing and any routine activities, are traditionally considered supporting activities. Supporting activities are merely activities that support the core R&D activities.
We encourage all companies interested in AusIndustry’s R&D Tax Incentive program to read the Software-related Activities and the Research and Development (R&D) Tax Incentive guide that can be found on AusIndustry’s website below:
We will continue to provide our insights on the new software sector guide.
If you have any questions, feel free to contact us.
