I like things that are practical but cannot be definitively proven by anyone with intials after their name. I like the Pareto principle, and I am starting to really like the 8020 model (or 80 / 20 or 80:20) of software development as a starting point.
See, Microsoft knows about it:
“One really exciting thing we learned is how, among all these software bugs involved in the report, a relatively small proportion causes most of the errors,” Ballmer wrote in his three-page memo. “About 20 percent of the bugs causes 80 percent of all errors, and–this is stunning to me–1 percent of bugs caused half of all errors.”
The CEO of Illinois Tool Works, Michael Davies, knows about it:
“We try to simplify everything, and use the 80/20 model across all the businesses, be it products, customers, or suppliers. An example is a manufacturing business we acquired in 2000. Our analysis showed that 80% of sales came from 802 products out of a total of 13,000. This means that people were spending a huge amount of time on the manufacture, sourcing, importing, warehousing, packing, shipping and dispatching around 12,000 products that probably didn’t add any value over the long term. Since then we have gone through a product line simplification process and within two years we had cut the number down to less than 4,500. You may still need to keep a lot of ancillary products that have a support role, but in this particular business there were clearly a lot that they didn’t need.
We also have a program where we analyse our customers and see which of them are profitable. The result was similar, in that of the 14,000 customers 80% of sales came from around 4000 of these. This doesn’t always mean that we just get rid of the other 10,000, as there are a number of ways in which you can manage it. If you have customers who are not buying from you in significant volumes, for instance, you may need to segment your customer service delivery accordingly. We reduced the number of customers down to 7,000 and, as a bonus, managed to eliminate most of the slow payers and overdue accounts in the process.”
Some guy I never heard of (Richard Koch) wrote at least 3 books on it, so they must sell, yeah?
And, of course, the originator of the term knows about it. Pareto noticed that 80 percent of the land in Italy was owned by 20 percent of it’s families.
The Pareto Principle states that 80 percent of problems are caused by 20 percent of possible causes. This has been extended to allow people to infer that 20 percent of products account for 80 percent of sales and that fixing 20 percent of the problems with a piece of software makes Customer Service’s life 80 percent easier.
Are these valid inferrences? I am not sure that they speak to the same kernel of truth, but they all do seem to express something valid, and the 8020 approach to development embraces this. With the 8020 appropach you have essentially 5 project phases:
- First shot
- Second shot (fixing first shot)
- Alpha release
- Beta release
- Release
Just because there are 5 phases, I do not think there is a tight correlation linking each to 20 percent of anything at all, but I guess it makes sense to see the model through. I like this, because in thinking about what actually happens in a project, there are distractions, “pet features”, and other things that are likely to be in the 20 percent that does not add appreciable value. However, and this is a pretty significant however, something seems wrong about setting out to get a B- on a product, at best.
And that is not the goal. At least, it is not when I think 8020. I am thinking of 8020 as sort of two phases, where the first is the 20 percent of the features that carry value and the second is the 80 percent where, if time or money runs out, at least 8 out of 10 stakeholders are happy.
I have *not* done a project under this paradigm, but we have all assigned priorities to tasks and I do tend to use the 1-5 rating. 5′s need to get done. Everything else is… well… not a 5. It doesn’t mean it wont get done. It just means it is not a 5. It is actually funny, the last project I ran over $250k had about 40 high to mid level features and 80 percent of them were 5′s. There were no 3′s or 2′s. There were 5′s, a few 4′s, and a few 1′s. Of course, some Client-rated 1′s were architecturally 5′s, so there was a bit of mediation required. When defined as “the project will be a total and absolute flop if this is not delivered,” I think the 5 ratings tend to be fairly accurate from the Client perspective.
So what about focusing on the 80:20 rule for projects you are developing for a Client? I don’t think it is viable without a dose of reality. The Client is not buying 80 percent of scope. Now, you can focus on that 20 percent of functionality as a first and second pass in either an agile, spiral, or almost any PM methodology. That does not mean they will not be looking for their automatically generated .xlsx everytime Bob in Accounting runs his report. Bob will be looking for it, if it makes his job easier. It might be all he really cares about.
So *AGAIN* we have a principle that needs to be tempered with all 5 senses and to reverse-engineer anything in technology management that comes packaged and look for the real value, leverage it, and use the skills that only come with experience to know how to apply those kernels of truth that may lie within. 8020, 80:20, 80 / 20 is a Management concept, not a development concept, and I would not even call it a Management concept if I was being truthful. It is a concept. I can apply it to how I spend my day, I am sure. I can apply it to my workouts in the gym, I am also sure.
Keep it simple 
All my best,
Josh