Quality Goals

One of those so obvious you never noticed concepts that change your way of looking at quality forever. This is a really simple way to let quality shape the way you organise your activities and deliver results. (You may have head this spouted as complete waffle before but here it is true.)
Here are a set of Quality Goals for a specific application as an example : PDF 120Kb

Simple enough for everyone

How simple is this :
  1. What do you do?
  2. How do you judge if it is being done well?
The second item is not specifically about measuring but general principles of what it is you want to happen or avoid happening.

To take a tiny example : Suppose you (1) want to be available for clients. Here is a possible list of (2)s

  • Urgent issues can be dealt with quickly
  • Clients know what the appropriate contact methods and numbers are
  • If you're not available there's some fallback procedure
  • The need for clients to contact you should be kept to a minimum
  • You have the necessary background details to hand when they call
Notice that there is no particular order, no specification of detail and no reasoning. This is the level that most people who are involved professionally with doing a job can be persuaded to rise to if given a guide and enough wine. (For a systems analyst this is a doddle.)

This simplicity and everyday 'common sense' level means that I can easily talk to you about your QGs and ask things like "What are they" and "How do you address . . ."

Everyone should have some ...

QGs can be applied at all levels in an organisational level. This is one of the reasons you won't find it in use - because it shines a light into dark places. One really brutal (I speak from experience) use is to compare proposals: Firstly you ask for their quality goals and they look at you blankly, then you highlight the hidden agenda which gets the knives sharpened, then you point out where the plans don't deal with the issues listed in the QGs so exposing the political schemers for what they are which makes them absolutely mad.

QGs are really handy for developing training and auditing and you can explicitly put them into protocols: For example "At this stage we must be careful that . . . (see chapter 4 Quality Goals)" which is something that can be tested if you're seeing if someone is up to the job.

Quality goals gives is the answer to the question "Why do I have to jump through this hoop" - That is, we can justify our efforts and the obligations we put on others.

Quality goals are essential. They are not optional. They must be written down. Discussion is useful. Different organisations should knock-up (that's all it takes) their own. Absolute precision is not important - fundamental principles are.

Read the article and experiment. There's a bit of a knack in finding the right level and it looks a bit airy-fairy, but you'll soon get the hang of listing what matters in each aspect of operations.
CommentsPossibilities
  1. That bit about giving people wine is genuine. When you start asking people to describe what they do and why they can be a bit shy and uncertain. A systems analyst will automatically explore issues but for the ordinary bod-at-a-desk actually thinking about what they do and why is a bit of a strain.
  1. As an exercise try re-designing a form after asking yourself what is it trying to do then what will make it successful. You should find that your QG is a framework for:
    • asking why you're doing something
    • whether they method is the best one to achieve it
    • what the relative importance of the aspects is
    • how the information will get processed accurately (and anomalies fixed)
    • instructions for filling in
    • what sort of auditing is appropriate
Contact Peter@Vulpeculox•net