Not all R&D work you do is SRED qualifying work. How do we tell the difference?
Are you the type of person who likes to skip ahead and get right to the conclusion? Yes? Then this post is for you!
True story. My wife’s mom would read a book the same way every time. She would pick up a new book, read the last few pages, then go back to the beginning and read the book. Why? So, she always knew how the story turned out.
For a SRED claim to be valid, we must demonstrate that you have carried out “qualifying work”. The definition changes and can get convoluted, but essentially you have performed experimentation, prototyping, even trial and error to attempt to resolve a “technological uncertainty”. In other words, your project must have faced risk that you could not complete it satisfactorily due to technical obstacles or unknowns. There it is. The heart of the matter. There are secondary requirements. Your efforts should be systematic. You have some record of your work. But striving to resolve a technological uncertainty is the meat.
If you find this explanation fuzzy or abstract, remember the famous words of United States Supreme Court Justice Potter Stewart in 1964. He was writing about pornography but, stay with me, it works here: “I can’t define it. … Though I know it when I see it”.
Let us go through a couple examples of the types of projects that contain qualifying work.
Say you are a software developer. What types of software development work might qualify? Here are a couple tests. If your software project lead could go to a technical conference related to your project’s subject matter (Blockchain, computer security, node.js, hybrid cloud architectures, etc.) and present a talk or paper on lessons learned, problems solved, new developments in the space, etc. chances are he is describing SRED qualifying work. Another test is risk of project failure for technical reasons. Say you are attempting to integrate two different platforms, environments, or architectures to produce a new, third environment with novel/unique/hybrid properties. You are unable to hire this expertise, so you carry out the work in-house. If there is uncertainty regarding the successful technological completion of your project, this points to qualifying work. Three. Tools development is often qualifying work. Say you repeatedly do projects for customers that involves similar steps. Security scans, porting code from environment A to B, etc. If you undertake a project to build a tool to automate a set of tasks or jobs, it is often likely that this tools development represents qualifying work. Fourth, and last software test/example. Say you are developing new code which must operate within a technological constraint that involves scaling. This could be response time under load. Ability to develop code with X functionality that will fit within a given memory or disk constraint. You must build a minimum viable feature set of the app to test it to see if it meets the technological constraint(s). This would probably represent qualifying work.
Qualifying work is often easier to spot in physical projects carried out in manufacturing, engineering, or product development firms. If you are carrying out prototyping work so that you can test an MVP (minimum viable product) against technical requirements or objectives, that is probably SRED. “Shop Floor SRED” is qualifying work. You are engaged in normal production and you encounter a technical problem. This might be as simple as a printing company or a coatings company experiencing quality or adhesion changes in different seasons. If you undertake systematic testing/investigation/work to overcome the technical problem, that is likely SRED qualifying work.
Last thing on qualifying work. If you have a project which has failed for technical reasons, this likely is SRED qualifying work and it can be fully claimed for payroll, materials, and any subcontract work.