Instead of addressing project problems as they crop up, you can use Pareto Analysis to spend your time more wisely. 

A few years ago, I observed an 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.

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. 

You can see that Pareto Analysis doesn't help you resolve all problems. It works especially well when you have multiple problems that can be counted and categorized. The benefit of the technique is that it provides you with important information to determine which problems to resolve first.