Ross Woods, Rev. Mar 18
If you're either in an audit or contributing to program improvement, you might want to know what is going on. Here's how it works ...
Quality systems are basically about checking that you have proper ways of doing things and reviewing them so that they can improve. Systems tend to be cyclical; after you run the program, you check it and make improvements, run it again, and so on.
Quality Assurance (QA) systems are organizational systems of checking the quality of your services or products. Most QA systems incorporate continuous improvement that applies both to the organization and to the QA system itself. They always include procedures to check that workers work to a standard.
In other words, you need a simple system that is thoroughly integrated into what you do and that provides good value for the time you put into it. (The biggest single problem with QA systems is that they can take a lot of time without adding much value.) And it needs to be able to catch the points at which you are weakest and wouldn't otherwise notice, even if they are embarrassing and nobody likes it.
Continuous improvement is a system of having continual or regular reviews so that you can propose and implement improvements. It assumes that organizations don't reach a state of perfection where they can no longer improve.
Your QA system should keep your organization under review so you can make improvements.
Your whole organization needs to be subject to the QA system. However, it might be helpful to identify your range of systems. In a much smaller organization, the systems might be very effective, but not be particularly distinct. In contrast a larger organization has more formalized systems so are easy to identify.
Many quality systems for services have the components listed below. I have to admit that it is my own model.
External standards can be, for example, industry standards, ISO standards, quality specifications, industrial relations rulings, legislation, WHS guidelines, and endorsed competency standards. In some cases, they either don't exist or are unsuitable, so the organization develops their own set of standards.
The system has to work efficiently for the organization's goals. Consequently, organizations can be very different when they structure to meet different sets of goals.
The organization keeps its own written explanations and regulations on what and how it does things, for example, the business plan, operational plan, budget, policies and procedures. These only have to comply with the wider standards above, so they might look very different from them. In other cases, they might be little more than a specific version of the wider standards. Some procedures can be very simple and easy to use, looking more like sets of simple instructions on what to do. Some are forms, perhaps with a set of instructions at the top.
If policy and procedure documents are difficult to use (e.g. nobody reads them, they are too complicated to read and easily understand) then they are as good as useless and a quality auditor should pick this up.
In many cases, procedures are not written down. This is satisfactory for some kinds of implementation matters and in many small organizations. If a matter goes to court, the organization can be required to demonstrate that it is consistent in applying those procedures and in teaching them to employees.
This might be letters, policies, procedure statements, check-lists, risk assessments, meeting minutes, delivery notes, invoices, filled in forms, etc.
This is what actually happens, which the auditor finds out by observing and asking questions. This will be checked for compliance with policies and procedures. Actual practice reflects an organizational culture, especially when procedures are unwritten. If people are generally slack, getting detailed paperwork right is not much help.
Actual practice is also a basis for reviewing policies and procedures, because:
The organization routines collects and collates feedback from participants and stakeholders. It is used in reviews.
The organization regularly reviews its own standards and systems, looking for necessary changes in practice, policies and procedures, and review procedures. It normally uses the existing feedback from stakeholders. Reviewers may need to compile an issues register (i.e. list of things that came up) to keep track of all input, and to select specific priority needs for improvement. In some cases, it is best to include a risk analysis and focus on high risk areas of the organization. Many reviews also initiate additional stakeholder consultations. Some are more like requests for input, while others are more like moderation sessions.
Many systems have someone independent come in to do the review. It might be based on the organization own needs and goals, or an internal audit against a set of standards, or an external audit.
The organization improves its own standards and systems. This aspect can be listed as a separate element, because some reviews don't result in improvements, or result in superficial improvements.
An organization has a culture of quality when people in the system perceive quality in the same way and try to do better.
Each year, the program is required to improve in all matters covered by the standards. The effect is that standards become dynamic; they mean something different each year for you. To illustrate, if you were completely compliant last year, and this year decided to run the program in exactly the same way, you would now be non-compliant because you did not improve.
The 2007 version of the Australian Quality Training Framework took continual improvement a step further. It differentiated between legal compliance requirements (which were not subject to continual improvement) and standards that were subject to continual improvement.
This basic version is often assumed in the Australian training sector:
One flawed model comprises only two elements: 1. Written standards and 2. Documentary evidence that practice complies with standards. It has at least three problems. First, It ignores actual practice and looks only at documents. Second, it tends to require compliance with each standard separately rather than holistically. Third, it has no review and improvement system built into it.
In essence, TQM basically means that managers should gather feedback and suggestions from all stakeholders on anything the stakeholders see as important, consider them, and make improvements. TQM has waxed and waned in popularity. In many cases, it is still considered best practice, including many Australian training sector units.
It works very well if managers regulate the ways that people give input, and then periodically hold reviews and make improvements. It often generates ideas that are available through no other means.
However, TQM doesn't work if everybody wastes lots of time generating huge amounts of suggested improvements, giving management too many ideas to evaluate and implement. In other words, poorly-done TQM can take a lots of time, get nothing done, and make people frustrated that their ideas don't get considered.
The quality gates system presumes that a process takes place in stages. The end of each stage is a quality gate where products are checked. Defective products may not progress to the next stage.
Software-based policy is quite different again. In this approach, all staff use software that automatically follows the policy; they can't do the wrong thing because the software won't allow it. How the software works is the policy and the quality system. This is a useful approach even though it does not normally cover all aspects of a whole organization.
Control systems are ways of ensuring that people do things correctly. In a small organization, it may be as simple as checking regularly that you are on track according to the operation plan. Other kinds of control systems are:
SixSigma is a system of minimizing faults and errors, often aiming to ultimately remove them together. It assumes that it is more cost-effective to rectify faults and errors than to carry their long term costs.
Review your QA system regularly to make sure it produces value for the time and money you put into it. You might even have KPIs for your quality system. For example, you might use quantitative (statistical) measures:
A college Principal once asked for advice. "We are due for an external audit by the accreditor. But we have nothing documented. What shoud we do?"
This approach was designed to respond to that need by producing a large amount of documentation, including policy development, in a short timeframe. In essence, staff review an existing program in a two-stage workshop.
It works on these assumptions:
Opening:
Divide people into assigned groups with assigned topics. Each group should go to a separate room with a computer.
Establish policy: "Does the college have a written policy for your policy item?"
| Yes | If it complies with requirements, get a soft copy. You've now finished this stage for this item. |
| Yes, we have two policies. | Choose one and edit it if necessary. |
| No | Do you normally follow a procedure that meets the requirements? • If so, write it down and you've finished this stage for this item. • If not, write a new policy from scratch. |
Lunch
Review what happened last time. You can assume that some people have thought more about last week and now have better developed ideas. Some may have done substantial work. Other might have been distracted with other work and mightn't remember what they did.
In groups, collate suggestions, evaluate them, and edit good suggestions into your draft policy on computer.
Morning tea break
Implementation strategy
(This session will probably be quite long, and hard to plan, because implementation will vary greatly depending on the nature of the item.)
Lunch
Afternoon tea
Collate and edit the whole thing into:
This should be fairly easy. People have been asked to submit most things in soft copy, so a lot of the task is simply cut-and-paste.