In this example of a first-time software claimant, let’s assume the client is managing their backlog and sprint planning in technology like Jira, Asana, or Azure DevOps, and employs an informal agile methodology. Here is a good primer on agile software development, if you’re new to this space.
Onboarding.
Given they are a first-time claimant, onboarding to a recent claim will not be possible and a new activity framework is required. In addition to developing the substantiation plan, your clients’ systems and technology can be a great source of information pertaining to their current or planned eligible activities, and more importantly, can result in an activity framework that resembles their own project schema.
In this example, the activity framework could come in the form of the software features or components within the client’s product road map or backlog that contain or correspond to current or planned R&D initiatives. In agile methodology, these are often called epics or stories. Activities need not be strictly eligible at this point, and wherever possible, an existing project or product name should be used so they appear familiar in Synnch.
Substantiation Plan. (What)
Delineating evidence at its source is achieved by tagging epics, stories and tasks likely containing R&D activities. An R&D component column can be established, along with a tag for each core activity. Tagging Should take place at the time of requirements gathering then again at sprint planning or reflection and can be thought of as your clients’ process of contemporaneous self-assessment of development activity. It’s also highly recommended to tag or label the entire backlog when your client first onboards to Synnch, or as early as possible.
Recordkeeping Strategy. (Who & When)
Recordkeeping responsibility should be placed with the team members who possess the necessary technical oversight of the whole product, at the relevant point in the software development lifecycle.
Requirements gathering
BA’s and Product Managers should have carriage of the initial identification of potential R&D activities during the requirements gathering process and can assess and tag the corresponding epics, stories, or tasks at their time of creation. When contract developers are used, the R&D requirements and their corresponding scope can also be delineated at the invoice level for a clear separation of the associated costs from BAU.
Design
Designers should have some awareness of R&D activities identified in the backlog and their relevance to the broader project. Although unlikely to undertake any core activities, designers may record their time on R&D epics, tasks and stories as supporting activities. *This is of particular importance when a design-led requirements gathering process is in use, as wireframes are likely to precede written stories or tasks.
Development
Product Owners or Senior Developers should have carriage of R&D recordkeeping during sprint planning, development, testing and release, and can continuously assess and tag R&D activities while grooming the backlog. Often R&D tax eligibility only becomes apparent during technical responses to failure throughout development, and this requires some technical understanding of the broader R&D objectives to assess quickly.
Pre-release Testing
Given that R&D software projects often span multiple development initiatives within a given product, automated and unit testing are often too granular to offer effective evidence of R&D activities and are often considered BAU as they must take place either way. Nonetheless, if effective delineation is achieved earlier in the development cycle, any testing effort can be tracked and delineated into Synnch with relative ease.
Release
It is often at release when unknown unknowns are likely to inhibit a smooth release or expected operation. At these critical times, teams can burn through resources to affect a quick fix. These moments can often be the source of technical responses to failure that explore new areas of eligibility or validate current hypotheses.
Post-release Testing
Where a live dataset is required to effectively test a given product component, acceptance testing post-release can be key to validating or invalidating a given hypothesis and drawing logical conclusions. In some cases, an experiment can’t take place until after release. Assessing and capturing evidence of R&D activities at this time is also critical and emphasises the importance of building the R&D compliance process into existing agile rituals.
Agile and R&D Recordkeeping
Although the high-volume iteration and trial and error often associated with agile software development may not be strictly compatible with the systematic progression of work within RDTI guidance. Some useful comparisons can be drawn between any agile process, and the continuous and contemporaneous self-assessment and recordkeeping required by R&D tax claimants.
In essence, pure agile is a contemporaneous process of team and self-management, preferencing the removal of obstacles to success, rather than predictive management.
It is through this similarity with contemporaneous self-assessment of R&D activities, and the avoidance of predictable outcomes, that a strong compliance regime can be designed and implemented into existing rituals with great effect.
If you’d like to learn more about effective use cases for Synnch in software claims, please reach out, we’d love to hear from you.