Exercise to illustrate Deming’s 95/5 rule

July 24, 2013

Read time 3 min

W. Edwards Deming has said that 95% of variation in the performance of a system (organization) is caused by the system itself and only 5% is caused by the people.

This sounds counter-intuitive and training attendees often argue that having great people would solve the problems. Or at least people have greater impact than mere 5%. Many also argue that we should invest in people, coach them, motivate team members and do other “people stuff” to get better.

Unfortunately that will not work. “People issues are not the point of intervention“, says John Seddon and I fully agree. System is the point of intervention. By improving the system, we improve not only results but also motivation and well-being at the work.

Here is an exercise that I use in my trainings to illustrate how Deming’s 95/5 rule applies in knowledge work. This is a quick one, takes about 10-15 minutes including set-up and wrap-up.

1. Context: I draw the following picture on flip chart and tell the context. Joe works for an IT department of a large company. The IT system is used by customers to place orders on-line as well as company internal functions to manage invoices, inventory, sales forecast and marketing. Joe and the team have Product Owner who gets requests from customer help desk and suppliers.

(click to enlarge)

Context

I start drawing from Joe, then the team -> product -> Product Owner -> help desk -> customer -> suppliers -> logistics department

2. Case: I explain people that “help desk receives a call from customer saying that it would be nice to follow order status on the web-site, e.g. estimated shipping date. Product Owner thinks this is a cool idea and puts it to backlog, ready for next Sprint”.

3. Task: After explaining the context and the case, I ask people to pick a pair (or in their table groups) to think “What could go wrong?”. What could happen between customer requirement and Joe so that Joe can not complete the work on time, with agreed content and good quality. I give 2 minutes for the discussion.

I also explain that SW development is a team effort, but in this case we assume that we look at Joe’s work. For example, why Joe (or his boss) would feel at the end of the Sprint that things went wrong.

4. Collecting answers: After discussion I collect answers to flip-chart. Usually the list has something of the following

  • Unclear requirement
  • Conflicting priorities
  • Bad tools
  • Bad working habits in the team
  • To much work
  • Joe’s competency (lack of)
  • Misunderstanding customer need
  • Lack of testing
  • Interrupts
  • Poor communication with other teams
  • ..and so on

5. System or Joe: The last part is to ask people “Who’s fault is this?”. If we have two baskets, System and Joe, which is the cause of the problem. I write on the flip-chart on each line “System” or “Joe” based on what the participants shout. Pretty soon the list is full of “System” and very few “Joe’s”.

This is a powerful way to show what is the impact of work design: When things go wrong, it is because the system. The point of intervention is system, not individuals.

Credits go to Richard Moir at Vanguard System for telling me this exercise. I have modified the original story (about plumbing) to fit the IT industry.

Never miss a post