One of the most valuable skills in any employee is quality assurance (QA). Any student reading this and wondering if they will ever get an interview, let alone a job; QA is the key. It is the ultimate in transferrable skills. If you can demonstrate an understanding and how to apply it, you’re not only on the shortlist, but you’re very near, if not on the top of the list, which is where you need to be. But QA isn’t usually listed as a skill or a requirement for most positions, except in accredited environments and specific quality roles. Regardless, it’s a required skill, and it’s assumed that you have it, or you’ll get to know how to do it by the ‘follow-the-bouncing-ball’ method of training quality assurance.
When it comes to training in QA (if you get taught at all), it’s often taught from the wrong end of the stick, in my opinion. It often starts with diving straight into the minutia of detail contained within the clauses of the applicable standard and associated documents. The context, not to mention the actual how-to within the workplace or role may be lost on less experienced or enlightened team members. If they don’t get it, or don’t engage with the training because it’s confusing or boring (yes, even I find it a dry topic), you can add reluctance, procrastination, chronic eye-roll, and lots of chasing people up on your daily TO-DO list as a manager come audit time. In my nearly 25 years of experience in operational management, quality assurance, and technical training, I’ve learned it’s much easier to teach the application of a standard after built a solid framework in systems theory to hang it off. It’s a useful tool that teaches the context and the how-to applicable to any standard, regardless of industry. You don’t need to undergo extensive training in systems theory to gain a functional skill set either. Systems theory is an intuitive and simple concept for most people to grasp because it is simply how everything works. And I mean EVERYTHING!
Now, if you’re reading this and thinking that’s an overreaching statement, it isn’t. Or, that you don’t have anything to do with systems or QA in your current role, I can assure you, you do. We all do. We do it all the time, and not just at work. Everything we do, every moment of our lives, we are interacting with, impacting on, receiving from, feeding into, and operating within a mindboggling number of nebulous, interconnected systems. Systems that operate at monumental differences in magnitudes of scale and complexity. Infinite, overlapping, nested hierarchies, yet simultaneously operating as self-contained, whole systems. If you want a good demonstration of this concept, take a look at the video ‘From Atom to Universe – amazing scale video’, and try not to feel too insignificant.
Understanding systems is fundamental to the idea of QA; to faithfully record, securely store, and retrieve the records, created from actions applied to a tangible entity. Every action connects to three components; the tangible (usually a person or piece of equipment), the record created from the action occurring, and the repository for storing the record. The tangible can be involved with many actions, creating many records, being stored in many different repositories, creating multiple systems, all connected.
The ultimate point of QA is to drive efficiency, reduce errors, fix problems, and reducing the chance of it happening again, theoretically making life easier. However, if you can’t correctly identify or define the system you’re operating within, what the feedback is indicating, and how and where it connects to other systems, you have little chance of achieving any of those things. In fact, you will create more issues and the on-flow effects can be catastrophic. Can you think of an instance where a change made has not only failed to fix a problem, but made the situation worse? This is a direct consequence of targeting the wrong point within, or the wrong system completely.
Trying to fix a problem without a working knowlege of systems, is like trying to tune the engine of your car by removing a spark plug lead. It might have not been running smoothly to start with, but it now may not run at all.
You need to understand systems theory to design them too. And the best systems are robust and flexible, resilient to challenges to them, give prompt and clear feedback at the critical control points, and are only as complex as the process requires to execute faithfully, with the QA built-in. If you can achieve that, you should end up with an efficient, with minimal failures.
Of course, all systems fail at some point through natural entropy, even the best-designed systems degrade. Good systems design ensures when it does fail, the built-in QA should assist in troubleshooting and finding the root cause of the issue within it, where it’s occurred, and what the issue is or, it will indicate the issue is in another system.
Systems theory and quality assurance from a practical application perspective is a useful concept for every aspect of our lives. I would like to see it taught as a foundation concept within senior schools and universities. It will give students skills in critical thinking and analysis skills they might not develop until much older and will support and enhance learning, and retention of knowledge.
Jarvis Hunt Consultancy is in the process of expanding a seminar course on basic systems theory into a digital, self-paced format. Keep an eye on our training page for when the course becomes available.