Do you poka-yoke?

pokayokeMany public service providers’ approach to quality management falls somewhere on a continuum between “waiting” for users to report issues on the one hand, to internally inspecting outputs for errors on the other. Even though the latter approach is much better than the former, it is best to “build” quality into the process.

Whilst it is good to do things right the first time, it is even better to make it difficult to do it wrong the first time.
One of the best ways to build quality into a process is to make it ‘error-proof’ (The Japanese term “poka-yoke” translates to “mistake-proofing”). A process can be described as “error-proof” when it contains a mechanism that prevents a mistake or makes the mistake obvious. It provides instantaneous feedback, prevention or correction.

Examples of these abound in everyday life from the cash machine that accepts a card only if it is inserted the right way to the gas pump nozzle that only fits either a petrol or diesel car. What other examples of error-proofing can you think of? Answers on a postcard please! Just kidding, please share them in the comments section below.

From a service delivery perspective, one of the main drivers of poor service is incomplete / incorrect data inputs from the service requester. Many of us are familiar with online form validation (e.g. being asked to supply a missing mandatory piece of information, whilst completing an online transaction), which is now a ubiquitous example of error-proofing.

In addition, the following validation tips are useful for error-proofing data input from a service requester:

1. For any given data field, if the possible options are a defined set, only allow the requester to select from a list (instead of entering free text).

2. If a list is not available but the data is in a known format (e.g. post code data) validate that the data supplied is in the expected format (for example by using regular expressions).

3. Derive the information where possible. For example, see the screenshot from Public Service Request where the requester can click on the ‘Use your current location’ button which obtains their current location and populates the required information on the request. This feature can be used if the requester is at the same location as the issue they are reporting. As well as a time-saving feature, it eliminates incorrect / incomplete location information (e.g. typos)

So do you think you can do more to “error proof” your processes? If so, how? What examples of error-proofing do you currently apply within your organization?

We look forward to reading your comments