Experimentation with software: where does R&D Tax fit in?

When developing new software; differentiating every day run-of-the-mill activities from research and development can be complicated. Good governance and administration is key to sorting out this difference. Sometimes attempts at recording experimentation get lost in the supporting documentation. This can be attributed to a number of reasons, like a business cherry picking in the agile approach, or developers keeping records loosely in GitHub or inherent undocumented knowledge due to staff turnover.

We thought it would be a good idea to give you, the software company, examples of different approaches for good data capture. To ensure that you are capturing the experiment, to keep an evidence base and to prove that you are indeed eligible whilst keeping on top of your admin to ensure good governance and review.

This follows an article we posted in 2017 that told you the truth behind the ATO taxpayer alert in Feb 2017 in addressing whether software businesses were claiming the right activities in the right context. That is for activities to be claimable they need to be conducted to solve a technical hypothesis. Today we address another part of the taxpayer alert – whether you’ve applied “adequate levels of governance and review to the registered activities and the claims made for the R&D Tax Incentive.”

Here are four workable easily integrated approaches:

• Problem scoping
• Technical roadmaps
• Technical blogging
• Hackathons.

Problem scoping

This tackles defining the problem – because effectively you want to determine the best solution that ensures it provides the best business outcome. An R&D project should make a rigorous assessment of the known facts and come to the conclusion that there’s still a probability it won’t work. But despite the uncertainty, you’re going to crack-on anyway.

Every business we work with already approaches problem scoping in their own way, relating it to features, functionality, time and schedule, resources and budget. However; what specifically needs to get captured for the purposes of good R&D governance is that there are technical unknowns prior to development despite having performed the due diligence of research.

The Government asks for a hypothesis, however, a common approach in planning software is for scoping to provide a certain path of development with the least unknowns. In light of this, it’s time to switch up the approach to problem scoping to an experimental mindset. It’s OK to attempt solutions which might fail!

Practically speaking, here are some approaches to aid defining the problem in an effective way when claiming for the R&D Tax Incentive:

• Research and document existing tools and competitors
• Identify why existing tools don’t adequately solve your problem
• Scope out the knowledge gap prior to picking up tools
• What have you tried in the past that has worked and why?
• What are some of the unique limitations you face?

Our tip: Spend time on the scope before diving into the problem, this can help minimise the work needed to pull together info come R&D application time.

Technical roadmaps

A technical roadmap is a visual tool to represent the action plan to achieve business objectives. Essentially, to help organise and prioritise your ideas and objectives into a high level strategic plan.

It helps stakeholders understand how they partake in the project to reach the strategic goal and what the priorities are along a timeline and what activities are required.

With respect the R&D Tax Incentive; what makes a good technical roadmap for R&D governance is the overview. A roadmap makes a good starting point as a list of all the activities conducted throughout the year. This list can then be broken down in to Core R&D activities, Supporting R&D activities and activities not related to R&D. A good technical roadmap us is one with the right balance of broad overview and detail and where the activities are grouped by technical function rather than by user facing feature.

Our tip: Think big picture, then drill down into detail if you really need. A roadmap also helps when and if you are talking with investors – they can see clearly where your focus lies.

Technical blogging

R&D requires a “systematic progression of work”. Blogging captures a narrative of the progression which is useful not just for R&D governance but also for the professional development of both the writer and their teammates reading it. A good blog post, whether for an internal blog or published to the internet, will fill gaps where information is not recorded in GitHub or software tracking tools like Atlassian’s Jira.

Essentially; a technical blog is a simple way to keep a record of the working brain behind the development. It also means that the learnings, and even failings, of a developer can be used to help bring the whole team up a notch through increasing professional development.

A few things that make a good technical blog;

• Describe the problem
• Write about the selected architecture
• Narrative of development/iterations/decisions made – good and bad
• Solution
• Appraisal of your own solution
• Write about how you’d tackle things differently knowing what you now know.

Our tip: Keep it simple, make it accessible, keep references and make it a regular activity. And consider taking the best of the blogs and getting your developers to present their work at technical conferences.

Hackathons

Yes, hackathons are valid, bankable R&D, and can count as a supporting activity if some of the ideas flow into a other Core R&D activities. To be valid there needs to be an  intention that some of the ideas from the hackathon will be picked up and developed further. This intention is of course why any business should be committing time to hackathons. Capture the time spent on formal hackathons and keep a record of the output from those sessions.

Our tip: Document all ideas, people who attended and time spent.

These are just a few ways to help focus, keep good governance and essentially maximise your understanding of eligible activities for the R&D tax incentive.

For more information you can read the Government’s software specific guidance.