Category: Quality

blog post, Methods, New product development, Project Management, Project management tools, Quality

80/20 Principle – The principle with ever increasing use cases

With the innumerable opportunities to get diverted from what is relevant, I have seen many successful and not that successful organizations, teams and individuals working very hard on the irrevelant and getting buried there. The 80/20 principle or the Pareto Principle is for those who are willing to pause a while before jumping into action. Though many have written about Pareto principle and analysis before, I thought of writing this blog post for the benefit of many who plunge into action on irrelevant projects, indicators than on the relevant ones. There is time for everything, if we can prioritize, eliminate, delegate and decide on the mosr relevant work we ahould be doing.

Pareto Principle or the 80/20 Principle

The 80/20 principle or the Pareto Principle by Vilfredo Pareto in the year 1896 is the one which is always heard in all walks of life, time and again even after a century of its discovery. Last week I heard it in our senior management review when one of the senior managers used 80/20 to highlight the need to focus on the 20% of the customers contributing to 80% of the revenues. The use cases of 80:20 or the pareto principle is innumerable. Here are some;

  • By eliminating 20% of the root causes we can eliminate 80% of the defects in a product
  • 20% of the customers contribute to 80% of the revenue. It makes sense to focus on this 20% of the customers.
  • 80% of the customers uses 20% of the features of the products. The remaining 80% of the features are used only by 20% of the customers.
  • By focusing on 20% of the project health indicators proactively, 80% of the problems can be eliminated / prevented.
  • 20% of unhealthy practices contribute to 80% of the productivity loss. By controlling this 20% percentage of unhealthy practices, productivity can be improved phenominally.
  • 20% of the workforce does 80% of the work. Remaining 80% does only 20% of the work
  • 20% of the work we do produces 80% of the results. The remaining 80% of the work produces only 20% of the results.
  • During 20% of our worktime, we complete 80% of our work. During the remaining 80% of our work time, we complete only 20% of work.
  • Only 20% of the projects yield the desired results, 80% of the projects do not yield desired results.

Pareto analysis

Here are the steps involved in performing Pareto Analysis;

  • Identify the probable rootcauses – The best ways to do this is to brainstorm with the team to identify potential rootcauses leading to the situation. Ishikawa diagram or the Fishbone diagram can help to do structured brainstorming to arrive at the potential root causes.
  • Frequency of occurrence – With the help of data, identify how many times each rootcause occurred, resulting in the outcome.
  • Order on frequency – List the root causes based on the frequency of their occurrenece (in the descending order)
  • Prioritize and take action – Identify the 20% of root causes contributing to the 80% of occurrences. By controlling these 20% of the root causes, 80% of the problems can be eliminated.

80/20 at a personal level

Can be effectively used at a personal level to;

  • Eliminate unproductive activities
  • Focus on strengths
  • Finding time to work on Important and not urgent projects

Knowledge management, Quality

$31.5 billion lost by firms in knowledge lost – PM network

Price of poor knowledge management = $31.5 billion

Thirty one billion dollars is not not a small number. That is price of knowledge management, to be precise, poor knowledge management. It speaks volumes by itself. Every other software company is doing the lessons learned exercise at least at the end of the project, if not at the end of every phase. Thanks to CMM and ISO. With the adoption of agile, every team is doing the sprint retrospective at the end of every sprint. That means at least once in a month, every agile team is performing a lessons learned exercise.

For most of the teams, the awareness of root cause analysis and corrective actions are there and at the same time When I ask questions alike;

  1. What is the one problem you elimated from this company forever?
  2. What are the requirements management related lessons learned by the organization during the past 5 years?
  3. What are the design related lessons learned during the past 5 years?
  4. Can I see all these, category wise at the press of a button?
  5. Do you refer back to these, while planning for the next phase / project?
  6. Are these part of the induction programs?

none have a satisfactory answer, and the same problems continues at lest as potential problems, sprint after sprint.

It is more like a person who wants to improve and goes to the guruji for advice. He leaves with a lighter heart and with firm resolution to improve. After a period of time, he comes back again, and repeats the same old story. After some time he gets ashamed to meet the same Guruji again and goes to a new Guru.

In a way organizations / teams / individuals are like this. They want to improve and excel, and at the same time do not have the conviction on the ROI from these. Hence they end up adopting models after models from consultants after consultants, without much of a transformation. The story repeats again and again, with different actors.

Before venturing into any initiative, understand the need and have a business case which is in alignment with the project / organization strategy. Have only limited initiatives but focus on them with whole might.