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.

Card sorting – agile BA technique 158

Card sorting is a simple and useful way to gather feedback on which features people want in a new system, which problems they want solve or generally speaking, what they want.

So I was surprised recently when some business analysts I was working with had not heard of the technique and I thought I would describe it here so they can look at it again.

All you need is something people want and a pile of cards to sort:

IMG_20160428_111205

Read More »

Is it enough to say that the BA is the “universal translator” between business and IT?

I often hear that we need a business analyst to translate what the business people say, so that technical people understand them. Then, I am told we need the BA to then translate what the technical people say, so that the business people understand them.

I guess it goes something like this:

It sounds good, but actually I don’t think it is true.

Read More »

Can I still use a use case on my agile project – even if the cool kids don’t use them anymore?

I have been told that use cases are very old fashioned now and that all the cool people have moved onto agile user stories.

But I am old school and I still like to pull the old approaches out every now and then and take them for a spin.

I found myself explaining use cases in both a lecture (where the company wanted me to explain them to the BA teams) and a small team where people had been doing use case diagrams but not really use cases. Then I got asked in a BA course – “do you use stories for agile projects and use cases for waterfall ones?”

My answer was “it depends – probably just ask the BA”. But the student responded that she was a BA and that all the other cool BA’s would make fun of her if she wore the wrong clothes to school or used the wrong tool on the wrong project.

Read More »

Using a moments of truth analysis to assess a team’s readiness for change

I have previously blogged about a number of approaches to assessing a team’s readiness for change, including the 7-S framework and the arenas of change approach, but today I thought I would explain a less well known approach – the “moments of truth” assessment.

Actually I made it up so it is not too well understood outside of my own loungeroom.  The approach is essentially the same as the 7-S style of assessing the interaction of the multiple systems, skills, stucture and other elements of the team’s whole ecosystem. But this is a little different because we start by looking at when (and why) the team’s internal or external customers interact with it.  Then we assess the team’s ability to support those interactions.

Moment of truth(n)  a moment when a person or thing is put to the test

Collins English Dictionary as quoted at http://www.thefreedictionary.com

Any interaction with a client is “a moment of truth” for the team. It tests the connection between the team’s value proposition, strategy, implementation, staff, skills and systems and it generates the experience that lasts in the customer’s memory until he or she interacts with the team again.

A “moments of truth analysis” therefore starts by identifying the interactions a team has with its customers, stakeholders and potentially vendors.

Read More »

Preparing for a stakeholder interview part two – using the GRIFT model

The goal of your interview is the single most important thing to know before the interview, but it is also useful to know a bit more about what you are hoping to achieve before you start the interview.

So that is where I use the powerful “GRIFT” model to do my preparations.

Actually it is not a very powerful model, it is simply a checklist of things to think about, in some sort of order, before interviewing someone. GRIFT is short for the following headings

  • Goal (as defined in my previous article)
  • Roles (What is your role in the interview? What about the stakeholder?)
  • Issues (What issues to you think you might encounter? What will you do?)
  • Focus (What is your focus for the interview?)
  • Takeaways (What will you deliver as a result of the interview? Are there any action items?)

Since I explained the goal in my previous article I will explain the remaing items in this one – RIFT, I guess.

Read More »

Preparing for a stakeholder interview part one – setting a clear goal

You might be surprised to find out that people often turn up to interview a stakeholder with little or no preparation.

You would probably not be surprised to find out though, that when the interviewer is poorly prepared, the interview results in a conversation without a real resolution and the interviewer has missed an opportunity to get off to a clean start.

So I thought I would add a simple (but very long) guide to some ways you can prepare for an interview. This article, and a couple that follow, are based on the “GRIFT” model that I developed while training BA’s.

Read More »

OODA Loops for fighter pilots, business analysts and testers

When I started to learn agile approaches to projects, OODA was all the rage, but it seems to have disappeared from view as modern agilistas move from Scrum to lean to Kanban to ultra-velocitus development.

I guess I am still a bit old school, because I still think the OODA loop is the essence of the agile approach.

So what is an OODA loop?

OODA loops began as an approach for fighter pilots to avoid dying. It is a way to train fighter pilots and also a way to design fighter aircraft, develop tactics for air combat and win wars in the air.  It turns out that it is also really useful for agile projects, production support teams and anyone rolling out a product in a competitive market.

Read More »

Famous BAs in history: Mark Twain on interviews

I stumbled on a letter from Mark Twain where he comments on “the interview”:

Inteviews are pure twaddle

Controversially, he claimed that interviews are appalling and should be completely abolished … which would seem to be a strong position for a business analyst to take these days. But then Mark Twain was around at the beginning of last century and we have learned a lot since then. Maybe he just didn’t know any better.

Read More »

User stories for production support part 2: PAC

I wrote an article on stories for production support teams quite a while ago.  But I always meant to add a couple more.

The problem with production support is that nobody has time to ask for what they want, but it is all urgent and super critical. So the last thing you often feel like doing is to slow down and understand the context that the user is in (annoyed, relaxed, sitting in a cafe, in their most important sales meeting ever etc). Instead the focus is usually on fixing “it” before you know what “it” really is.

But this often leads to rework. So whenever I am doing enhancements I always spend a little time understanding why the enhancement is needed, who it is needed by and when/how it is likely to be used in the real world. To do this though, I think we always need to spend a little time understanding the people who will use the system and why they need something new.

There are many approaches to doing this, but one I often find useful is “PAC” or “People, Activities and Context”.

Read More »