This article series introduces you to two problem analysis and management tools: the Fishbone diagram and the Pareto principle. In part one of the series, we introduced you to the Fishbone diagram and explained how you can apply it to your environment to help determine the root cause of an issue. As an example, we used the Fishbone diagram to determine the root cause of a Domino server crash. In part two in our series, we introduce you to the Pareto principle, a management tool to help you determine how best to tackle your software-related issues. This article assumes that you are an experienced Notes application developer or Domino administrator with little to no knowledge of the Pareto principle.

About the Pareto principle

Almost a century ago in 1906, Italian economist Vilfredo Pareto devised a mathematical formula to explain the uneven distribution of wealth among people in Switzerland. His observation was 20% of the people held 80% of the total wealth. Though the principle was initially applied to economics, it was hugely popular and successful in explaining the rationale behind other industry problems as well. Software application development, support, and maintenance are no different. The Pareto principle is also referred to as the 80/20 rule. Using this rule, when we analyze raw data of any business problem using Pareto charts, it gives us valuable information that helps us in management decisions. The 80/20 rule is basically empirical and not absolute. The figures 20 and 80 are not important; it may sometimes be 10 and 90 or 30 and 70. We are not concerned with the exact figures as long as it helps us to identify the key factors.

Some of the scenarios in which the Pareto principle can be used are listed below. Please note that it is not limited to the following cases.

• 80% of customer complaints are caused by 20% of our products or services
• 20% of a meeting’s duration results in 80% of its value
• 20% of your products or services generates 80% of your profitability

Applying the same principle in software, we can assume that a vital few factors cause most of an application's problems. If we can correct these few factors that account for 20% of the application design, then the product or the application will have greater probability of success. Because the principle is a generalized one, it can be used in any platform or technology, not solely Lotus Notes. But we are more interested in applying it to Domino application support and maintenance.

When to use it

You may find application of the Pareto principle useful in the following instances:

• Identifying those few components that cause the majority of the problems in a system
• When available data is too voluminous to identify those components that cause the majority of the problems and a mathematical method is needed to identify them

When not to use it

In the following instances, you may not find the Pareto principle useful because it may not yield desired results:

• Sample data for analysis is too low.
• Available data clearly shows a particular component causing most of the problems, so analysis is not required.

Back to top

Relevance of the Pareto principle to Notes application support

A typical day-to-day operation in application support is to identify the problem, to study and analyze the problem, to find the cause, and to fix it. The fix may be temporary or permanent. A temporary fix is provided when troubleshooting a problem takes a lot of time, and end users are looking for a quick fix. For instance, support personnel may provide a temporary solution (such as a patch), continue to work on the problem, and then fix it permanently at a later point in time.

An application support contract usually runs for at least one to two years. If the various metrics obtained during this period are not analyzed, then the performance and efficiency of the application will not improve. Therefore, there is a definite need to analyze the metrics. The 80/20 rule plays a bigger role here because it helps the project management team to analyze the metrics and to find those few key factors that contribute to more than 80% of the problems.

After the key factors are identified and fixed, the application will see an improved efficiency. The number of reported issues should decrease drastically. But the application of the 80/20 rule should not stop here. The project team should continue to gather metrics, to analyze, and to identify the next set of factors affecting the system most. The process is iterative.

As mentioned before, the Pareto principle is not used to find solutions to problems, but to find information about those modules, applications, or design elements that cause most of the problems, which can help to make the product or application more efficient.

How to use the Pareto principle

The various steps involved in using the Pareto principle are:

1. List and sort the problems and their categories
2. Calculate cumulative percentages
3. Draw a line graph
4. Identify the key categories

List the problem type and the module affected

This is the first step in analyzing and applying the Pareto principle. Gather information, such as problem type and the module that it affects in the system, for a period of time (for instance, six months to one year). Enter the information in a spreadsheet in two adjacent columns (one for problem type and the other for module). You can sort the problem types based on module in descending order. The module with the most reported problems appears at the top of the spreadsheet followed by others in descending order.

Calculate the cumulative percentage

In the second step, you find out the percentage of problems in each module. If the sampling contains 500 problems, out of which 100 falls in Module A, then the computation is Module A = (100/500)*100 = 20%. Compute all the modules that have reported problems.

We need to emphasize an important point here. We are using the Pareto principle to find which application module has the most reported problems. You can classify the problems in many ways. For instance, if you are supporting about 1,000 Notes applications, you might classify the problems based on the application. If you support applications across geographies, then you might classify based on geographies and so on. Based on the experience in supporting the applications, you may classify the problems in any category that helps you to identify the majority of issues.

After the computation for all the modules is done, a table is drawn using the details.

Draw line graph

After the cumulative percentage is calculated, you can plot a line graph. Use a graph sheet or spreadsheet to draw a horizontal axis (X axis) corresponding to different modules ordered from most problematic to the least. Draw a vertical axis (Y axis) corresponding to the percentage ranging from 0% to 100%. After the X and Y axes are set, you can plot the points.

For each module and cumulative percentage, plot the points on the graph. Then draw a continuous line joining all the points. Because it is cumulative, the line starts at a lower end and proceeds vertically upwards (exponential). That’s it. Now we are all set to find those key modules that account for most of our problems.

Identifying the key modules

The last step in the process is to find the most problematic modules in the application. Draw a line from 80% in the Y-axis until it reaches the cumulative percentage line graph, and then drop it vertically downward to the X-axis. All modules that fall to the left of the 80% divider line are the few key modules that create most of the problems in the application. The modules that fall to the right of the 80% divider line are less important modules. If those modules falling to the left of the 80% divider line are fixed permanently, there is a good chance that the other less problematic modules will be solved automatically. A major issue may have some regression, so fixing a major issue may sometimes eliminate a few minor issues, too. But this is not always the case.

Back to top

Example

Let’s take a look at the following example to better understand the Pareto principle’s relevance. The following example demonstrates how to analyze sample data to help us to find the few key factors that contribute to most of the problems in our system. For our example, we have chosen an On Leave application system that tracks when users are on sick leave, on personal leave, and so on. We've also gathered a few help desk call details.

List the problem and the related design element

The following table lists some of the help desk details logged for the On Leave application. The problems and the related design elements are listed and sorted based on the design element.

This table is only a sample, but when analyzing production support, it's best to use data gathered over a significant period of time (for instance, one or two years) to yield better results. The details provided here are restricted to one application for ease of explanation, but it is up to project management to gather data for various applications and to classify the problems based on different categories.

Calculate the cumulative percentage

The next step is to calculate the cumulative percentage of problems that occurred in the design elements listed in the preceding table.

Total number of problems in the sample = 35
Annual leave form % = (3/35) * 100 = 8.6%
Casual leave form % = (6/35) * 100 = 17.1%
ACL % = (1/35) * 100 = 2.9%
Help document % = (1/35) * 100 = 2.9%
Views % = (3/35) * 100 = 8.6%
Maternity leave form % = (2/35) * 100 = 5.7%
DB launch property % = (1/35) * 100 = 2.9%
Reminder agent % = (1/35) * 100 = 2.9%
Replication settings % = (2/35) * 100 = 5.7%
Web frameset % = (1/35) * 100 = 2.9%
Sick leave form % = (10/35) * 100 =28.6%
Report form % = (2/35) * 100 = 5.7%

The above lists the percentage of problems found in individual design elements or groups (for views). The next step is to calculate the cumulative percentage. Create a table with the percentage listed in descending order.

Draw a line graph

The following line graph is drawn from the preceding table data using Microsoft Excel and plotted with the cumulative percentage against the related design elements. The X axis is plotted with the related design elements and the Y axis as the cumulative percentage.

Identifying key design elements

The final step is to identify the few key design elements that cause most of the application problems. Applying the Pareto principle (80/20 rule), draw a line from 80% on Y axis until it meets the line graph. Once you reach the line graph, drop the line vertically down to the X axis as shown in the following graph.

All the design elements that fall to the left of the 80% line are the few key design elements accounting for most of the problems reported in the On Leave system. Now we have narrowed down the design elements that create most of the problems that annoy users. From the graph above, we can say that the following are the design elements accounting for more than 80% of the problems in the On Leave application:

• Sick leave form
• Casual leave form
• Annual leave form
• Views
• Replication settings
• Maternity leave form
• Report form

The project management team can now concentrate on analyzing these design elements. It is highly possible that working on the design elements will indirectly fix the issues occurring with other design elements.

Sometimes the 80/20 rule has to be slightly altered. For instance, if the 80/20 rule is applied to an application support project and the results indicate that the majority of problems are reported in 60% of the applications, then it does not help the team to identify those few applications creating the majority of the problems. In this case, the rule can be modified to 70/30 or 60/40, which will identify the few problematic applications.

Back to top

Conclusion

In this article series, we discussed two important software quality techniques: the Fishbone diagram and the Pareto principle and their importance in the Domino environment. We have also talked about the various steps involved in applying each of these techniques and used Domino examples to illustrate both techniques. We hope you found the introduction to the Fishbone diagram and to the Pareto principle useful.

Resources

Read part one of this article series, "Applying the Fishbone diagram and Pareto principle to Domino, Part 1."

For more information about the Pareto priniciple, see "Pareto's Principle - The 80/20 Rule."

About the author

Rate this article

Comments

Back to top

Table of contents

• About the Pareto principle
• Relevance of the Pareto principle to Notes application support
• Example
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Lotus on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers