A common theme that I come across is that Software is not Research and Development. However software is actually a large portion of claimants of the Research and Development Tax Incentive. While the words Research and Development are not known as a typical software development methodology, it certainly does occur in many different types of software development.
When it comes to determining if you are doing software research and development, it doesn’t matter which software development method you use whether it is an agile methodology, waterfall or whatever. You can also do research and development on any platform, using any language or type of database. The main thing is what you are aiming to do and how you go about it.
There are two major requirements for us to claim the research and development Incentive. The first one is the knowledge gap. A knowledge gap is that in what you are trying to create, there is knowledge that you need as part of the project however it is not available to you. The knowledge that is required for the project cannot be researched, Googled or easily obtained by asking your regular experienced professional.
This means that you have a challenge in trying to create some new knowledge. The technical challenges that I have come across from companies claiming have been very diverse, almost unique for each company’s projects. They might be trying to create a link between a program written in a new language and a legacy language program. They might be trying to overcome latency issues or want to develop an experimental user interface. The challenges remaining in software development will always be countless.
The other major requirement to claim the Research and Development Tax Incentive is how the company responds to that challenge. The scheme requires that part of that response needs to include experimentation. Experimentation boiled down means that you wish to create function or encounter a challenge, to create that function or to overcome that challenge you try different things to determine which would be the best solution. This is very much a case of “not what you’re creating” but “how you’re creating it”!
For example with your experimental user interface, you might design multiple layouts with the aim of determining which one is the easiest to navigate through. You might then run a series of timed tests to determine how long users might need to find certain information. By designing and testing multiple possible solutions, you are doing experimentation.
The key thing is that experimentation and knowledge gaps do not need to be the entirety of your project. We usually settle for at least some of the project. If you want to talk more about R&D projects, leave a comment or drop me an email at Andrew@innercode.com.au