Using the 80/20 Rule to Analyze Events

One of my students told me about a technique that he uses in requirements sessions with SMEs and users, and I thought it was a great idea and wanted to pass it on!

At that start of the meeting, he writes 80% on the white board in the room. When the users start talking about something that only happened once or is some sort of anomaly, he points to the 80%, and says, “Given time and budget constraints, not every event/problem/issue is going to be able to be handled in the solution. We need to focus on those that happen at least 80% of the time.”

In our discussion, he pointed out that the most traumatic events – things the users never want to happen again – are the ones that they tend to remember since they were so traumatic! BUT those anomalous events often occur less than 20% of the time, so spending a lot of time analyzing them distracts from the main events that need to be analyzed. So, using the 80% rule is a rough way of prioritizing and focusing the discussion.

I use the following template for listing events that a solution must respond to:

Event Name:

Event Description:

Criticality:

Frequency:

Response Needed:

Response Time:

Both the criticality and frequency can help you determine whether the event is part of the 80% you need to focus on. Criticality is the importance of the event, and a correct and timely response to it, from the business viewpoint, and frequency is how often it occurs. Some events might be highly critical but only happen very infrequently, so you need to do enough analysis of this type of event to see if it should be handled in the solution or if it can be handled in some other manner.

At first glance, this approach seemed to contradict the Pareto principle, or the law of the vital few, which states that roughly 80% of all consequences come from 20% of possible causes. However, using the event template can help you discover events that are both critical and very frequent – those 20% that cause 80% of the problems the solution needs to address. Root cause analysis can also be applied to determine the underlying causes of these critical events.

The Pareto principle applied to software also states that 80% of the users use only 20% of the features of an application. Discovering that “vital few” is a critical part of the business analysis role.

Marsha Hughes, CSM, CBAP, PMP

Marsha is a senior instructor and consultant for Watermark Learning, and has more than thirty years of experience in the software, technology, telecommunications, and Internet business sectors. She has numerous accomplishments in Agile methods, project management, business analysis, software development, methodology development, process improvement, and courseware development and training. She is a Certified Scrum Master and Professional, a Certified BA Professional, and a Certified PM Professional. She is also a contributor to the IIBA’s Agile Extension to the BABOK, and the agile perspective in version 3.0 of the BABOK.