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?

Two Simple Rules for Evaluating E-Learning Project Changes

By Jonathan Shoaf

Let's face it, most requests for e-learning are vague at best. The client wants an e-learning about a particular topic, they put some PowerPoint slides together with lots of words and bullets (and no graphics!) and say "turn this into e-learning." Although the client will not admit it, they are thinking they'll figure out as the project goes along. This is why its important to have a development process.

1. Background
2. Project Description & Scope
3. Storyboard
4. Prototype
5. E-learning

The earlier in this process you "figure it out", the less amount of work the developer needs to do and the less cost to the client. The goal is to work out the big hairy important details early. Later on in the process you want to be tweaking the details and not making major changes.

When change comes you will need to manage it and keep it from sabotaging the project. Handle all of the changes and the expense goes up leaving the client unhappy.  If you do not handle enough of the changes the client feels like they are losing control of the project to the developer.

I have found two rules to follow for prioritizing change in a project.  You can apply these when you see too much change coming and you need to sort out what changes to implement first.

1. If the client says it is important, the change should be at the top of the list.

You're not the client. You don't know why its important but the client does. The client will not be adament about something unless they have reason to be. If they are being a stickler about a change, ignore at your own peril. The reasons for the change can range from past mistakes made, past feedback given, company culture, or a better understanding of the learners. These are things the client knows but you don't.

If the client says it is important, then make the change. It can go a long way to building a relationship of trust between the developer and client.

2. If you think it is important, the change should be the next item on the list.

The client is relying on you to be the e-learning expert. They are not. You may know why a change is important, but the client does not. The reason it is important to you may include your understanding of how learners interact with e-learning, your understanding of bandwidth issues, your understanding of how the change impacts the clients most important requirements, your experience with iPads versus desktop computer, and more. Trust yourself. The client will learn to trust you.

The rest of the changes are less important. Trust me. What seemed important at a review, may seem less important over time if it doesn't fit these two criteria. I often purposely ignore changes that are not critical to the client and not critical to me to see if opinions will soften over time. It saves work and expense.

How do you prioritize change?