How do you prove SR & ED? (1/2)

Contemporary documentation of SR & ED projects is the most recent hype for the RTA. You have to prove by documentary evidence that your research has taken place. Otherwise  there is no eligible SR&ED. Verbal testimonials are no longer enough. How do we do that?

In recent articles we have presented some ways to document your SR & ED projects. We have presented an inexpensive process, we have illustrated how to organize to document and how to document the deviation from current practice.

Here is another approach to gather your evidence for SR & ED. In recent years, the CRA has identified five questions to determine eligibility for SR & ED. We must now be ready, in audit, to answer each of these questions and to demonstrate our arguments. So here we propose to group your evidences according to these five questions.

Today we present the evidence for the first two questions. We will conclude with the evidence of the last three questions in a future blog

Before you start

Some warnings are needed before starting:

• Contrary to the CRA’s assertions, documentation of experimental processes is not “natural” in a commercial venture.
• Documenting your SR & ED projects is a new discipline to be implemented on a weekly or monthly basis in your company.
• Appointing a Technical Documentation Manager for each requested project is now a must.
• Paper is not the only acceptable support. A Word, Excel, Visio, Txt file, an e-mail, a picture or a Wiki will do the trick, the important thing is that it is dated,
• Be creative. Here we present a reminder, a source of inspiration from which you will build your bank of evidence, do not limit yourself to this list.
• Date all your documents.
• Finally, there is a great deal of overlap between the evidences presented here for each question, since we are talking about the same project in terms of uncertainties, experiments and advances and so on.

So let’s go for examples of documentary evidence for the first two questions:

1- Proof of uncertainty:

An uncertainty exists “if whether a given result or objective can be achieved or how to achieve it, is not known or determined on the basis of generally available scientific or technological knowledge or experience “

We have already discussed how to document current practice and how to overcome the knowledge base. Other examples of uncertainty documentation include:

Examples

Uncertainties are rarely described formally by the project staff. It is therefore necessary to create the habit of referring to them during the course of the project.

• From the beginning of the project, prepare a list (in the project’s birth certificate, which we will soon be discussing) stating the:
  • Main risks that the technological objective is not achieved within the technological constraints,
  • Anticipated problems and standard solutions for each,
  • Initial needs for testing of technologies, develop prototype (s)
  • Technical limits and known alternatives, in order to compare them later with the reality of the project.
• Write and update dated lists about:
  • Attempts (by others or by you) to resolve the problem raised,
  • Conceptual alternatives envisaged to solve the uncertainties,
  • Tests or serious analyzes to evaluate alternatives,
  • Constraints, peculiarities or problems specific to your environment (size, architecture, resources, adaptability, etc.) that prevent you from using the existing solutions,
  • Compelling specifications (performance, cost, stability, functionality, compatibility …).
• Identify and document conflicting constraints (eg performance versus reliability)
• Document the unpredictability of the environment to illustrate the interactions, reactions or behaviors of several components that could not be determined in advance in a given system. This may lead to the demonstration of systemic uncertainty,
• Clarify the status of the project and technology at the beginning and end of the year:
  • What uncertainties were resolved during the year
  • What uncertainties remain to be solved
• Document the reasons for abandoning prototypes.

2- Evidence of assumptions

An hypothesis is “intended to resolve scientific or technological uncertainty. An hypothesis is an idea, consistent with known facts, that serves as a starting point for further investigation to prove or disprove that idea. ”

We must therefore note the ideas, the options and the alternatives that we envisaged to solve the various uncertainties. Do not forget to :

• Date these documents,
• Specify to what uncertainty each hypothesis tries to answer,
• Identify who carried out the work,
• The best places to record the assumptions are the birth certificate, periodic reports and logbook that we will discuss in another page of this blog.

Examples

Examples of documentation of assumptions include:

• Describe the initial approach envisaged to resolve each uncertainty,
• Illustrate the alternative hypotheses envisaged (not necessarily tested, nor the final approach),
• State what tests or analyzes have been undertaken to evaluate the alternatives?
• Test plans or test reports: What results and conclusions have we drawn from them?
• At what point (following which results) was the hypothesis rejected? Or demonstrated?
• Describe what justified the initial need to develop a prototype(s)?
• Why was the prototype abandoned?

Conclusion

In conclusion, contemporary documentation of SR & ED projects is now a condition of acceptance according to the new RTAs. It is therefore necessary to prepare, enrich and save these traces of your projects during the year in order to reduce the risks of an unfortunate decision by the RTA.

We are honored to see the time you spent reading our page. The index of our blog (to the right of this page) contains several other solutions that are also intended for you. Did you like your reading? Tell us so. What should be added? What topics are you interested in? You did not like this reading? Tell us so. What is it that you disliked?