I certainly didn’t make up the concept of the 80/20 rule, but I use it quite often!

At a high level, 20% of any group requires 80% of the effort or resources, while 80% of the group require only 20% of the effort or resources.

Some examples where the 80/20 rule is useful:

• If you are migrating data, such as e-mail, 20% of the users will consume 80% of the space.  Forcing everyone to trim down their mailbox to a fixed size BEFORE the migration might make the migration go significantly faster!
• If you are migrating a group, identify the people that will require additional effort up front, and save them for last.  This allows you to charge through the majority of the project quickly, applying lessons-learned to the more complex or effort-intensive people toward the end.

From a management perspective, it’s often difficult to obtain consensus or approval for a new policy, because someone invariably points out the exceptions.

Create policies and rules that easily apply to the 80%, with a simple exception process or alternative for the 20%.   Demonstrating how the policy will be applied, and having the exception process defined up front makes it a no-brainer for stakeholders to buy in to your approach.

For example, let’s say that you want to set a mailbox size limit, to try to make sure people don’t use e-mail as a filing system, and thus maximize your Return On Investment for the mail server hardware.

If you pick a number at the 80% mark, let’s say that 80% of all of your mailboxes are less than 500 meg, the problem is that your key stakeholders may be the ones whose mailboxes exceed that size today!

Conversely, if you pick a size LARGER than all of your current mailboxes, for example, let’s say that all of your mailboxes are less than 2 gig (each), setting the limit at 2 gig is ultimately ineffective.  Everyone can store up to 2 gig of stuff.

A better approach is to set an initial limit at 500 meg, with a built-in exception for the 20%.  Create a policy where the user must seek additional approval, or their cost center will be charged a utility cost in order to go above 500 meg.  This allows for flexibility to go outside the policy, where there is a valid justification or business need, while expressing a general limit that covers most cases.

Although this is a good hypothetical example, it’s somewhat dated.  For e-mail, I specifically recommend the following:

• You should purge e-mail at 6 months, for legal purposes.  Any e-mail that exists on backup tapes or mailboxes where someone is storing every message since 2003 creates some level of risk that these could be subpoena’d in the event of a lawsuit or criminal proceedings.  If the e-mail simply doesn’t exist, it can’t be subpoena’d.  The 6 month time limit also tends to keep mailbox sizes under control.
• Storage is cheap.  From a business standpoint, using quotas to force people to juggle their data around means that they will either store it somewhere else, that they will waste company time and resources shuffling it around, or they will seek outside services WITHOUT narrow limits, such as Yahoo or Google mail.  In the long run, it’s better to provide extra storage if needed, making it easy, and encouraging people to use your services instead of seeking outside services.

Solving some problems requires a detailed series of interdependent steps, or a careful arranging of resources at each step, in order to be successful.

There is a game, using blocks, called the “parking lot” puzzle.  You arrange the blocks on a board of fixed size, according to the layout depicted on one of many cards.  You slide each block in one direction at a time, without overlapping the blocks, to try to get a specific “car” (block) out of the parking lot.  Solving each challenge often requires a long series of well-planned steps in order to accomplish the goal.

Several situations, where there are limited resources or tight constraints, can become a “parking lot” problem:

• Migrations involving leap-frogging servers or other resources.  Leap-frogging means that you migrate from server A to server B, freeing up server A to be used as the target of the next migration.
• Many steps must be accomplished in a narrow window.
• Sufficient people resources to staff a specified level of concurrency.
• Specified number of migration windows, where multiple steps or specific work effort must be accomplished within each window.
• Combinations of the above.

Sometimes, a goal-oriented approach, with detailed planning for resource allocation across multiple steps, is required in order to solve resource-constrained problems.

For “parking lot” problems, have a thorough and complete plan, detailing sequence, task assignments, and resource allocation.

Sometimes, the problem you end up needing to solve, is not the problem you set off to solve.

In the 80’s there was an adventure game (those of you who played it will recognize the description), where you needed to get in to the castle.  The castle had a moat with a bridge.  The bridge had a stubborn goat, that wouldn’t let you pass.  So, to get in to the castle, which is the ultimate objective, you have to go find a carrot to feed to the goat, to get the goat off the bridge, so you can cross the bridge, to get in to the castle, to win the game.

This Rube Goldberg approach to problem solving works well in video games, but is not practical nor effective in the business world.  Simple processes are usually more reliable and repeatable.

If the objective is in the castle, figure out how to get the carrot, goat, and bridge OFF the critical path.

Likewise, maybe whatever is in the castle can be sourced in another way, bypassing the whole problem.

This is my way of saying “simplify the problem“.