Adapting Pareto Principle For Project Management
By Kathlika Thomas
There are not many observable instances in our natural surroundings where we find an equal distribution of anything of value. Population, wealth, workplace productivity, even the harvest of a farmer’s plot - there is a concentration of produce generated by the minority that accounts for the majority of yield. This is just a way of re-stating the Pareto principle, a rule titled after its namesake who discovered the principle that, as managers, we’d be wise to apply in our own projects:
The majority of the effects seen in your projects will come as a result of a minority of the work that your team does.
The Pareto principle is the “law of the vital few”. More specifically, it asserts that by focusing on the 20% of work that most matters to your client, you will produce 80% of your project’s results. It’s extremely important to remember the significance of this principle in two specific areas as your project progresses: time management and quality control.
One of the figurative wires on which project managers have to balance throughout the project lifecycle is that fine line between meeting ever-mounting requests of a hard-to-satisfy client with constraints of a tight project schedule. So, what do you do when stakeholders add nice-to-have scope, small requirement changes, or requests for functionality that won’t necessarily add value or efficiency to their business processes? Or how do you address a perfectionist developer who has a tendency to pour hours of unneeded development into product enhancements to please a particular user or business owner? Unreservedly discourage gold-plating by enforcing and educating your teammates on the Pareto principle.
To apply it in your projects, consider what we learned earlier: identify the 20% of requirements or functionality that will most meet the project’s original business case and avoid tweaks and modifications that add little overall functional value. Make clear the impact that frivolous updates have on the project schedule, costs, and the success of the chartered project. Reasoning with stakeholders and teammates in this way will often win them over to your side and will help to protect your timeline.
Ensuring the quality of a final deliverable through first-rate development and thorough testing and verification is a given, right? A more difficult task, however, may be prioritizing resolution of defects found during testing. In this case, the Pareto principle can also be applied when addressing system issues: 20% of the defects cause 80% of the problems. What does that mean for your team? Although it may be tempting to tackle the “low-hanging fruit”–defects that are easy-to-fix but not necessarily important to the business–it’s wiser to funnel the bulk of your efforts into addressing the more difficult issues. Isolate the more important 20% that will bring 80% or the majority of the benefits to your client. This focus will result in increased success of your deliverables and a greater level of stakeholder satisfaction. The functionality most significant to their business should be delivered with the least flaws. Once the more difficult 20% have been tackled, you can address those easy-wins with the confidence of knowing that you’ve already met the majority of your client’s needs.
If there’s one thing that you can take away from this long-used rule, remember this: while I certainly don’t discourage working harder, being armed with the foreknowledge of the Pareto principle, you can channel your team’s efforts to work smarter. While not discounting the remaining 80% of work you’ll have to do after putting this principle into practice, your clients will thank you for prioritizing project tasks to meet the bulk of their needs first.
Kathlika Thomas has over a decade of business analysis and project management experience. She has roots at Accenture, one of the “Big Five” consulting firm and has managed numerous international projects. Kathlika has also developed a number of workshops and training programs related to business analysis, business intelligence and project management. You can read more from Kathlika at the IT Project Blog.
No comments yet.