Good advice from Johanna Rothman on conference proposal writing.
Giving back to the profession, sharing best practices and lessons is an important part of being an ethical practioner, and also a great way to build your career. Preparing and speaking at a conference is also a great way to build connections with the material and to stretch in order to build expertise.
Recently I’ve seen a few inspection observations that have provided an observation on the title of quality record (e.g. deviation, CAPA, change control).
The title might seem the most basic part of a quality system record – a simple task – but instead it should receive some serious thought. This is any inspector’s first interaction, it serves as a historical flag that generations of readers will use to become familiar. And everyone falls prey to “judging a book by its cover.” This cognitive bias tends to make readers considerably susceptible to allowing the quality systems title to function as the sole factor influencing their decision of whether to read or skip a record. A bad title could shape an inspection or deprive an important historical record from being evaluated in the future. We can do better.
A good quality systems record title:
Condenses the record’s content in a few words
Differentiates the record from other records of the same subject area
Some general tips:
Keep it simple and brief: The primary function of a title is to provide a precise summary of the record’s content. So keep the title brief and clear. Use active verbs instead of complex noun-based phrases, and avoid unnecessary details. Moreover, a good title for a record is typically around 10 to 12 words long. A lengthy title may seem unfocused and take the readers’ attention away from an important point.
Avoid: Wrong label issued
Better: Sample ABCD was issued label 1234 instead of label X4572
Use appropriate descriptive words: A record title should contain key words used in the record and should define the nature of the quality systems event. Think about terms people would use to search for your record and include them in your title.
Avoid: No LIMS label for batch ABDC
Better: Batch ABDC was missing label Y457 as required by procedure LAB-123
Avoid abbreviations and jargon: Known abbreviations can be used in the title. However, other lesser-known or specific abbreviations and jargon that would not be immediately familiar to the readers should be left out.
It sometimes surprises folks how simple things can have ripple effects. But they do, so plan accordingly and ensure your users are trained on writing a good title. Trust me; it will make things easier in the long run.
Johanna Rothman recently provided some insightful thoughts about Project Work vs Product Work. While focused on software, Johanna has some points that are valuable outside of software as she focuses on the importance of long-lived teams, applying a product work mindset to team functions.
The more we create long-lived teams who have already learned how to work together, the easier it is to work together. Even if that work is project-based work.
I think the critical thing for me is how much we have to view each team, each project as having as one of it’s key deliverables knowledge management.
However, we also need to recognize that in this day-and-age the modern corporation is a transient collective. Companies do not do a great job of showing loyalty, there are a lot of options for the modern knowledge worker, and people regularly move on.
For me, this is why it is so important for not just projects, but day-to-day work to have as part of the inherent ways of working, processes to bring the tacit to explicit. The lessons-learned is a great place to start but we should be constantly be striving to identify “what have we learned”, “what do we need to make explicit” and “how do we make it explicit” as part of our work.
Returning to the 6 stages of knowledge management:
Have a way to capture what knowledge bits. For example, if you have a visual board, make sure this is explicitly part of the board. Make it part of your day-to-day.
As a team assess the collected captured (and generated) knowledge and determine what is suitable for retaining.
Share it – pass it up, pass it down. Make it available by tying it into your companies knowledge management system.
Turn it into artifacts that are reusable. Pre-job briefings, procedures, work instructions, whatever is relevant.
Live it. Confirm you are using it.
Remember knowledge management artifacts are living. Things change and need to be updated. We can always refine. Continuous improvement is key.
One of the key parts of any change (process improvement, project, etc) is preparing people to actually do the work effectively. Every change needs to train.
Building valid and reliable training at the right level for the change is critical. Training is valid when it is tied to the requirements of the job – the objectives; and when it includes evaluations that are linked to the skills and knowledge started in the objectives. Reliability means that the training clearly differentiates between those who can perform the task and those who cannot.
A lot of changes default to read-and-understand training. This quite bluntly is the bane of valid and reliable training with about zero value and would be removed from our toolkit if I had my way.
There are a lot of training models, but I hold there is no single or best method. The most effective and efficient combination of methods should be chosen depending on the training material to be covered and the specific needs of the target group.
For my purposes I’ll draw from Edgar Dale’s Cone of Experience, which incorporates several theories related to instructional design and learning processes. Dale theorized that learner’s retain more information on what they “do” as opposed to what is “heard,” “read” or “observed.” This is often called experiential or action learning.
Based on this understanding we can break the training types down. For example:
Structured discussions are Verbal and some Visual
Computer Based Trainings are mostly Records
Instructor Led Trainings are a lot about Demonstration
On-the-job training is all about the Experience
Once we have our agreed upon training methods and understand what makes them a good training we can then determine what criteria of a change leads to the best outcome for training. Some example criteria include:
Is a change in knowledge or skills needed to execute the procedure?
Is the process or change complex? Are there multiple changes?
Criticality of Process and risk of performance error? What is the difficulty in detecting errors?
What is the identified audience (e.g., location, size, department, single site vs. multiple sites)?
Is the goal to change workers‘ conditioned behavior
This sort of questioning gets us to risk based thinking. We are determining where the biggest bang from our training is.
Building training is a different set of skills. I keep threatening a training peer with doing a podcast episode (probably more than one) on the subject (do I really want to do podcasts?).
The last thing I want to leave you is build training evaluations into this. Kilpatrick’s model is a favorite – Level 4 Results evaluations which tell us how effective our training was overtime actually makes a darn good effectiveness review. I strongly recommend building that into a change management process.