A few years ago, I was observing the implementation of a
major Enterprise Resource Planning (ERP) implementation. The implementation
team knew that there would be problems–hundreds of them–and they were not
disappointed. After the application went live, the ERP helpdesk was inundated
with problem calls. One way to resolve the problems was simply to use a
problem-by-problem approach. The team could have taken the first problem and
solved it, then the second, then the third, and so on. Since many of the
problem calls were related, this approach would have ultimately led to the
resolution of all the problems.

But the team decided that the approach was not the best use
of their scarce time and resources. It wouldn’t have made sense to spend
resources solving the first call if that was the only occurrence of that
problem. It made more sense to solve the problems that were causing the most
frequent errors. The team decided to use Pareto Analysis to help make more intelligent
decisions.

Looking for expert IT project management? Get the help you need from TechRepublic’s free Project Management newsletter, delivered each Wednesday.

As I mentioned, the support tickets were coming in fast and
furious. The team attempted to solve the problems they could, but they also set
up a process to start counting and categorizing each problem. Within a very
short time, they started to notice the patterns. The purpose of Pareto Analysis
is to observe the problems and determine their frequency of occurrence. This,
in turn, gives you the information you need to prioritize your effort to ensure
you are spending your time where it will have the most positive impact. Pareto
Analysis is based on the classic 80/20 rule. That is, 20 percent of the
instances usually cause 80 percent of the problems.

Let’s assume for our ERP implementation, that the team
noticed that there were five major categories of errors. (This example is
simplified. On the actual ERP project, there were dozens of distinct categories
of errors.) Let’s further say that the distribution of the errors looked
something like this:

• Error
#1 — 5 occurrences
• Error
#2 — 25 occurrences
• Error
#3 — 70 occurrences
• Error
#4 — 15 occurrences
• Error
#5 — 50 occurrences

Notice that this gives you important information. Even
though there are five total problems identified, it probably makes most sense
to try to resolve Error #3 first, and then Error #5 second. If you solve these
two problems, you have actually solved over 70 percent of the total occurrences
(120/165 total errors). Under the first approach, the time you would have spent
solving problem #1 first would have had a negligible impact on the total
occurrences.

Of course, you might ask, “What if error #4 would only
take an hour to solve?” In that case, solve it by all means. It’s
low-hanging fruit. However, the Pareto Analysis now gives you some facts to
know what the impact is of solving that particular error.