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.

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.