Focus Time and Effort with the 80/20 Rule

By Jonathan Shoaf

The 80/20 rule, also known as the Pareto Principle, roughly states that 80% of the results are caused by 20% of the effort. This rule is applied commonly in business situations where for example, 80% of your income comes from 20% of your clients. This principle is meant to be a rule of thumb to guide decision making.

As a software developer, I use this principle.  In many cases 80% of the user's desired outcomes can be accomplished by 20% of the application. I've always believed the development process for software applications and e-learning have a lot in common. In particular, time and cost must be balanced with functionality and results.

The Pareto Principle can be used to help focus time and effort to get the outcomes most desired. Don't have time to sit in 100% of the meetings? Identify the 20% of the meetings that cover 80% of the results and spend the most time analyzing those meetings. The subject matter expert doesn't have a lot of time to give on the project? Ask them to identify the 20% that needs to be learned to cover 80% of the outcomes.

I'm not saying to ignore the other 80% that is needed to fully cover a topic. However, I am saying there are realities that may keep you from being able to spend the time you need on a topic. Identify and invest in the 20% and your learners will be prepared for 80% of the outcomes.

Here's an example of where training often fails the 80/20 rule. A new software application is implemented at your organization. You are expected to train on the application.

The vendor provides training content and you are to convert it to training. Do you know where that content comes from? Here's the process:

Functional specifications are created for a software product. These specifications cover every thing the software is functionally able to do. What the software can do is not what the user necessarily needs to do. Following the Pareto Principle, the user may only need to use 20% of the software to accomplish 80% of the tasks.

The functional specifications are turned into help and documentation. Again, covering nearly 100% of what the software can do. What the users need to do? That's still not identified.

Next the training is produced. This is where failure often occurs. Training is created based on the documentation from the vendor. The thinking is that everything needs to be covered. Its an easy trap to fall into. Considering the Pareto Principle, training poorly on 100% of the application is not as effective as training thoroughly on the most important 20% of the application.

Therefore, focus needs to be given on the 20% of the software application the learner will use to create 80% of the outcomes.

Do you apply the 80/20 rule during the instructional design process?