Pareto principle

Pareto’s principle, the 80-20 rule, is of course also true for projects. Some examples:

  • 80% of the project managers time is spend on 20% of the team.
  • 80% of the work is delivered by 20% of the team (and most of the time not the 20% in the above example).
  • 80% of what the client wants takes up only 20% of the budget.
  • The other way around it sounds more shocking: 20% of the requirements take up 80% of the budget.

But how can this help us?

Management time
In a team some people need more personal attention than other parts. That’s normal. But a big amount of the time is spend on a small part of the team. Why is that? This can have a lot of different reasons. The 20% part of the team might have the most difficult and risky part of the project, not the correct knowledge for the tasks, tasks that need a lot of coordination between teams, bad work attitude, need more guidance, are more pro-active in discussing progress, etc. So find out what’s the reason for all the communication and see if it’s normal for the type of tasks and knowledge level, probably. And if that’s not the case, there is a problem that needs fixing, because it can save a lot of management time that might be needed for other parts of the project or it can decrease customer costs.

Delivered work
On the other hand 20% of the team is delivering 80% of the work. Are they that efficient, overqualified or do they have easy tasks? The main point is that something is going really well here. Try to find what it is and have other people learn from that experience. Imagine what happens if you can get the high-delivering part of the team bigger!

Requirements/scope vs budget
Because we have a default set of portlets for delivering portals we try to do 80% out of the box, meaning the additional, custom, 20% will probably be the most expensive part. So indeed 20% of the work can take as much as 80% of the budget. If we focus on the 20% custom part to see how we can lower that, it can dramatically save money for the client. For example by discussing if some of the requirements are really so important they need custom work or can be met with a, much cheaper, out of the box solution. This is all about value for money.


By knowing Pareto’s principle we can try to break it and bring the bad part of the percentages to the good parts.

Focusing on results can look strict

In projects it’s important to focus on results. The business case is the main result we want to reach. But the teams also need to book smaller results, contributing to the business case, the work packages. Without finished work packages the business case is not fullfilled. So as a project manager I have to focus on getting the results, within time, budget, quality, accepted risk, etc.

So what to do when a work package is delivered later than planned or with a lower quality than agreed? Well, that depends. Of course there is a margin. While giving the work packages to the teams I am used to keeping a time margin, which means that some delay is possible, lower quality can be fixed in the time margin. So sometimes a problem with the delivery of a work package does not immediately mean a problem for the project, because it can be fixed within the overall planning.

But what if a team delivers the work packages not a as agreed for a longer time or with a difference too big to correct? Well, then they run out of tolerance and it is becoming a project problem. So when that happens most important is to find a way to have the team manager sticking to agreements. Unfortunately in IT the most used solution is overwork, the team has to work evenings or weekends. And I really hate it when that happens. On the other hand… why does it happen? The team is not delivering according to agreements (read: accepted work package). So it’s the team that feels the consequences.

Asking the team to work evenings or weekends… does it make you a good project manager, because it’s sticking to agreements? Or does it make you a bad project manager, because you don’t seem to care about the team? I guess I know what the team thinks (see the title of this post), because the team always has good reasons to not deliver according to planning. Work was estimated wrong, the experience level was too low, sheer bad luck, etc.

Probably a good project manager gets the work done this time, but also helps the team in finding out what wend wrong in accepting and delivering the work package and how to fix that in the future. If this works out nice the cooperation between the team and the project manager goes better next time. If not, either the project manager is not as good as he thinks, or the team is uncapable of learning from mistakes.