The 80/20 Rule (The Pareto Principle) Revisited

March 26, 2014 at 8:32 pm Leave a comment

Recently (time is relative), I wrote about the 80/20 rule. This states that it takes 20% of the time to do 80% of the work. The relatively short period of time taken to do the 80% of the work gives a false impression of the time necessary to complete the entire project. Also, it is very easy under time pressure to do the easiest 80% of the project. This means that 80% of work is done in significantly less than 20% of the effective project time; the time to completion is actually increased for a short-term benefit.
I just watched an interesting PluralSight video called “Architecting Applications for the Real World in .NET” by Cory House ( http://pluralsight.com/training/Courses/TableOfContents/architecting-applications-dotnet ), which takes a different approach to the 80/20 rule. It accepted that 20% of the time is all that it takes to complete 80% of the work. However, it states that in certain circumstances, 80% of the work is all that is required since the remaining 20% of features are not critical to the viability of the product.
This raises two interesting questions: what does complete mean, and must everything be 100% complete. If 80% complete provides the required features of the product, then 80% may be more than satisfactory.
Years ago, I worked on a project that produced certification papers for pharmaceuticals. The Products were produced by one system and then passed to another. However, no documentation was produced to permit tracking of the product. A simple program was written where the operator manually typed in the information and a document was printed. Over a period of two years, a new God product was designed to automate the production of this certificate. The project became so massive that it was never completed. In fact, the simple manual approach had already solved the problem.

So, I want to amend my concept of the 80/20 rule. It takes 20% of the time to do 80% of the work, but sometimes, 80% is enough. My proviso is that the 80% completed should be the most important part of the work.
Given that the most critical components of the project are solved in 20% of the time, it should therefore be possible to put software into production in 20% of the time it takes to produce a complete product. This will validate that the correct 20% was done.
The Minimum Viable Product (http://en.wikipedia.org/wiki/Minimum_viable_product) pushes this philosophy. The MVP is the minimal product that can be created to test the feasibility of a product. The classic example is a person evaluating if there is a market for a new product. He advertises his product to test the demand. He has no product available. If there is sufficient demand, he then produces the product. His upfront cost is minimal, as is his risk. He only commits to expenditure when he knows that there is a demand.
In software, we can extend the 80/20 rule by incorporating the concept of the Minimal Viable Product. We prioritize features into must-have, should-have and could-have. The Minimal Viable Product has all of the Must-Haves.
Often, customers place everything in the Must-have category. If the customer is guaranteed that the product will be in production once the must-have features are complete, the greater the incentive to create a realistic required features list.
Therefore, if 80% of the work is focused on the most important features, a Minimum Viable Product can be made available in 20% of the time that it will take to complete the 100% solution.
The Pareto Priority Index quantifies this (http://en.wikipedia.org/wiki/Pareto_priority_index):

 

PPI

 

This simply states that reducing time to completion and the cost increases the priority of a project. Also, providing the most essential value in the product will also increase the priority of the project by increasing the savings and probability of success (adoption).

For more information about risks of MVP see “Building a Minimum Viable Product? You’re Probably Doing it Wrong” by N. Taylor Thompson in Harvard Business Review Blog. http://blogs.hbr.org/2013/09/building-a-minimum-viable-prod/.
An interesting case study of a Minimal Viable Product is given in “What Drones and Crop Dusters Can Teach About Minimum Viable Product” by Steve Blank also in Harvard Business Review Blog. http://blogs.hbr.org/2014/02/what-drones-and-crop-dusters-can-teach-about-minimum-viable-product/

Advertisements

Entry filed under: Uncategorized.

Making A Start In Search of the Silver Bullet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


The Creative Site Administrator

Creative Time Management.

March 2014
M T W T F S S
« Feb   Jan »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

%d bloggers like this: