Getting your team to confirm they’ve read and understood documents is only half the battle.
Granted, it’s an important battle to win. It’s why we love getting feedback like this on our Read & Understood Training Genius app for Confluence:
“It’s great — one of our developers was behind with 69 read & understood trainings. After I nagged her, she was able, using the Training Genius, to sign-off these 69 read & understood docs in one evening.”
So while the developer was able to get through her mandatory trainings, it’s hard to imagine that she actually read and understood 69 procedures, work instructions, and guidances in one night.
This points to a harsh reality: Read & understood trainings tend to be a tick box exercise for trainees because compliance usually trumps comprehension. Writing to suit the auditor’s standards often stands in direct conflict with what trainees need — which is brevity, clarity and relevance.
It doesn’t have to be this way. The gist of it is this: you can cater to both trainees and auditors by putting the essence of the training right up front.
The truth about trainings
The first step to writing better trainings is to embrace the facts:
On the one hand, quality system documents often must be lengthy and chock full of dense details and boring language. That’s what regulations demand and auditors expect, and you can’t necessarily change that.
On the other hand, your team members must truly read and understand trainings not just for compliance-sake, but also to create products that are safe and effective.
This is complicated for several reasons:
- Productive team members are too busy to read all of their read and understood docs.
- Even if they do read the trainings in full, they won’t retain most of the details. When it’s something they do all the time, it might be more resonant, but still unlikely that they’ll remember every last instruction.
- While it would be nice to develop interesting training materials for each topic, it’s not realistic.
- Read & understood trainings are a proven way to comply with regulatory requirements.
With all of that in mind, it makes sense to decide what you can realistically expect from an effective read and understood experience. This boils down to awareness, whereby your trainees either realise a procedure on a given topic exists and is there for them as needed, or if it’s a daily task, they can quickly spot what’s new.
Putting these core objectives into the heart of your documentation practices can dramatically increase the effectiveness of your training program and of your processes as a whole.
There are several writing habits you can adopt, which will increase the effectiveness of your read and understood trainings (and stay tuned to this blog to read them all!). Our #1 favorite is to craft a short, concise gist section.
What is a gist section?
If you understand that a typical trainee will spend a minute or less reading a given document, then the best way to convey the essential aspects of the training is to place an informative paragraph, potentially called “Gist,” somewhere very close to the top of the document.
While traditional opening sections such as “Purpose,” or “Scope” are usually aimed at auditors and are full of complicated regulatory language, the Gist section is written solely for trainees.
The gist section answers the following questions:
- How does the information apply to the trainees? What’s in it for them, and how does it change or improve their daily workload?
- When should this document be used?
- Why this new version/update?
- Are there any timelines, and are they clearly highlighted? e. in a Complaints procedure, you would include something like, “If you ever encounter a situation where our device has put someone in danger, contact the COO immediately, as we need to move fast.”
Examples of gist sections
The following examples give you an idea of how to craft an effective gist section:
For a CAPA Process
The CAPA process is used when things are not up to par. For example: If we see that our customer shippings are missing the deadlines too frequently, then we will initiate a CAPA for this. We’ll involve everyone who can help us figure out why this happens and fix it. Anyone can initiate a CAPA if they think something needs improving in our system. This new version reflects the recent organizational changes and assigns responsibilities to the current roles.
For a Software Development Life Cycle Procedure
We explain here how we develop and ship the XYZ App. All the documents we need and the tools we use are also explained here. If you are involved in the development of our App, make sure you are familiar with this document. Appendix A includes a summary table, which can help you get started. This new version reflects the update to the Jira tooling we use to manage the product requirements.
Get the gist? If you have questions about how to simplify your training process while at the same time strengthening it, please feel free to contact us.