Examples of technological uncertainties in software research and development claims.
Malcolm Gladwell in his book Outliers popularized a 1993 psychology paper saying that anyone can master a skill with 10,000 hours of practice. I always find the opposite with my golf game, the more I practise the worse I get. I am also not sure he ever read the HMRC R&D CIRDs (Guidelines)! But hopefully, my 8 years of experience working on software R & D tax credit claims will make the opinions below useful.
Background.
A scientific or technological uncertainty is key to any R&D claim. R&D is about pushing boundaries and overcoming challenges, and in an R&D claim Guideline context these are the uncertainties. In this blog I will give my thoughts on how to express technological uncertainties correctly in software claims and where mistakes are made.
Firstly, giving specific case study or generic examples carries dangers. The R&D uncertainties have to relate to your project and not someone else’s. Giving someone an example runs the risk they will copy it, and that is ill advised. A good quality narrative cannot be a “boiler plate” job, it must be specific to the claiming company’s activities and should be genuine and real and not generic.
Secondly, as technology is always moving, judging if a technological uncertainty is qualifying or not is very “point in time” specific. For example, to say in 2019 that responsive website design was a technological uncertainty on a software project is unlikely. But I am always interested in specifics before making a judgement. Technologies around responsive website design are now well established. 10 years earlier, around the start of smartphone and tablet software development, that may have been a technological uncertainty, but now it would appear routine and well known, so the opposite of an uncertainty. Technology moves on.
Thirdly, “one liner” uncertainties are often hard to judge without a broader context. In other words, a good narrative is about answering all the qualifying questions well and cannot be boiled down to one detail. Confidentiality makes it hard to give entire reports as case studies, just some anonymised and edited examples.
Examples.
With these three caveats here are some examples.
- The software had been written to use microservices. But a requirement was to audit the processing of data. It was an uncertainty as to how to track processing through multiple microservices?
- The software integration sought to use the Microsoft XRM Tooling connector. This was poorly documented (At that point in time) and blogs did not answer the challenges we faced. It did not behave in the way a REST API would for example but delivered the advance we sought. This created uncertainties that were not readily deducible or a matter of public knowledge.
- How to impose a security regime on another application without having access to the source code of the other application or any obvious ability to modify its behaviour?
- How do we allow the system to parse the user-defined configuration and compile the data access method at run-time in an acceptable timeframe?
- How does the performance of the proposed storage models vary with increased metadata complexity? How do we minimise this impact?
- About Single Sign On (SSO), after baselining and researching the solutions available in the market, the initial plan was to use an off-the-shelf product with minimal-to-no customisation. The selected software was WS02. However, this strategy proved naive as many uncertainties arose when the integration process began and there was the need to modify long-established software, particularly on extremely sensitive dataflows (authentication and access management).
- Internet of Things (IOT). Could the selected technologies cost effectively scale to the number of systems, complexity and the amount of data generated by a single building, which could easily be in the Petabytes?
The right approach?
These are just snapshots from a several past R&D claims. They give some level of insight but are hard to judge as they are extracts from full reports. What can be learned?
- The language needs to be technical. A good technological uncertainty must imply an understanding of the technology. Specifically, that the knowledge comes from a competent technical professional. Explain in plain language and then get technical is a good strategy. I have avoided highly technical examples as without context they are not useful. Also, they don’t make good blog content.
- Talking about functionality (What the software does) and especially the application area is generally best avoided. High level over views are not technological uncertainties and they give an impression that a competent technical professional has not been involved in the project. This is “blood in the water” in terms of presenting a claim as being doubtful in terms of qualifying.
- Dig deep rather than take a high-level approach. Talk to your techies not the salesman. Detail is your friend. This is easier in small organisations. The most straightforward software claim I deal with involves a “one man” company, the MD is the techie and he lives the development process. The level of detail he knows produces a strong narrative. Counter to that a large development team with day to day work pressures and layers of management, you really have to dig deep to identify and collect the good experiences that explain the R&D. Effective processes to capture the R&D detail are particularly important in large organisations. If you rely on an individual recollection you run into two problems, they might forget, or they might leave. Neither is helpful if HMRC wish to challenge a claim.
- Struggling to write an uncertainty? Start with the word “How” outline a technical challenge and end with a question mark.
- The biggest own goal? “We did not know how to?” “It was new to us.” “We lacked experience in ….”. Technological uncertainties and advances must be broader that just the company’s skillset. The baseline from where and uncertainty has to be described and must answer “Is it readily deducible by a competent professional in the field?” not “Is it readily deducible by someone with no knowledge or experience of the issue they face”!
To correctly claim all that can be done is to case by case work through the Guidelines, make a case based on the work done, and then take a view on the strength of the claim. This is the process a good experienced R&D consultant helps you through. It is a two-way process. Get in touch today to see how we can help you claim the R&D Tax Credits you could be entitled to claim.