Mistake proofing your process

I thought that I had already published this on my blog, so imagine my surprise when I told someone to look for this article and found that it was missing.

If only there was some way to anticipate and remove errors … ah yes there is. It is called mistake proofing.

Mistake proofing your process

You can apply this to a user story in an agile project or to anything you want, but the approach described here comes from old-school process modelling.

  1. Start with something to analyse – such as a value stream map or process model.
  2. Assess who is involved in the process – who does something, who gets something at the end. You can use a tool like PAC or just have a chat
  3. Look at what could cause something to go wrong from the end user’s perspective
    1. What could go wrong?
    2. How bad would it be?
    3. How often is that going to happen?
    4. What might cause it?
      1. What else?
      2. What if two bad things happen at once – how might they make it worse?
  4. Look at what happens when they try to recover from the problem
    1. When might someone notice?
    2. What might they do?
    3. What else might they do – what is the dumbest or worst mistake that they could make?
    4. Who else might get involved and how might they make things worse? Does that lead to a new risk.
  5. Record all of this in a lazy risk register or add post-it notes to a wall.
  6. Improve the process – rung through the questions in reverse to find where you can reduce risk. The closer you get to removing the impact the better but in some cases you might focus somewhere else
    1. What can we provide to guide people in what to do if something does go wrong?
    2. How can we predict or identify mistakes earlier?
      1. Are their symptoms or triggers we can look out for?
      2. How can we identify errors earlier in our process?
    3. How can we tackle causes – either by removing them or inoculating our process against them?
    4. How can we reduce the frequency of these errors?
    5. How can we reduce the impact of these mistakes if they do occur?
  7. Repeat the process above for each particular step of the process if you want to, since you will go to another level of detail.
  8. Now you have too much information and you might be overwhelmed. But let’s keep going. Look at all the things you could do and rename them options or ideas. Add two more options
    1. The slack option – accept all this can go wrong and go to lunch. Do nothing to improve the process
    2. Abandon the process because it is just not worth it
  9. Now go through the long list of options and prioritise them
    1. What could we realistically do?
    2. What should we do?
    3. What are we actually likely to do?
    4. Most importantly – what is the first thing we should do?
  10. Have a cup of tea and then commit to some kind of plan. You could use a plan on a page for this, or perhaps a capability improvement table. You might also decide to create a risk register or communication plan if you are serious enough.

Hopefully I will publish a related article soon – some of the tools or approaches you can use to apply the approach above with more flair, less hassle and more likelihood of success.

3 comments

  1. Hi James. Interesting! Doesn’t mistake proofing imply that you are removing all likely errors when it looks like what you are trying to do is to quickly identify and mitigate them? Mistake-proof also sounds to me like the language of unsafe to fail environment which does not, of course, mean being sloppy. So perhaps a new term is needed?

    • Hmm. You got me thinking Andy.

      Mistake proofing IS about removing likely errors because errors and failures are BAD.

      But I teach that it’s safe to fail and I also teach we should create a barely sufficient product (MVP) before getting carried away perfecting it.

      There seems to be a contradiction here.

      But I like the term mistake proofing or error minimisation, maybe because I’m used to it.

      I see a distinction between working in a way that encourages experiments and the Courage to fail and then learn.

      But when we build products (apps, web pages, new processes) I see teams deploy new features and experiences where the process/product itself has many defects or a design that encourages mistakes and even seems to make it hard to recover once a customer makes a small mistake.

      So I believe we can build a minimal set of features or a simple process … and then work to make t stable and resilient before adding more features.

      In other words, working in a way that encourages experiments, leading and mistakes while building a product that protects customers against mistakes.

      But maybe I am displaying to separate mindsets … I might ponder this a little more.

      Thanks for the comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.