Parkinson’s Law in Project Management

What Is Parkinson's Law in Project Management?

Parkinson's Law was coined in 1995 by Cyril Northcote Parkinson, an English historian. Parkinson's Law, in its general definition, means that Work expands so as to fill the time available for its completion.

 

So how does Parkinson's Law affect Project Management?

It is very easy for any Project Manager to relate to Parkinson's Law. The most common example is the following: A resource is given a task that takes only a few hours at worst, but was allocated a week of work in the project schedule. Miraculously, the time spent on this task will expand and the task will be finished at the last minute of the last day of the allocated week (and sometimes not).

 

The definition of Parkinson's Law can also be adapted to constraints other than time, for example the budget. So another definition may very well be: Total costs expand so as to exhaust the total budget available for the completion of the project.

 

Again, any Project Manager can easily relate to the above definition: How many projects out there was finished under-budget? Not too many, in fact, very few. Even when the Project Manager adds so much contingency to the budget and accounts for every possible risk and issue, the project is either finished on budget or (more likely) over-budget.

 

Why does this often happen in Project Management?

Many Project Managers make the mistake of creating a lot of slack in the schedule (for contingency) and creating a huge buffer in the budget (as much as they can get approved), thus projects get finished way beyond their normal finish date and at an inflated cost. There are several reasons why Project Managers make this mistake:

 

• Keeping promises. Since managing expectations is an important characteristic of a successful PM, Project Managers try their best not to disappoint the stakeholders with a project that is behind schedule or over-budget, so they greatly inflate all the estimates.

 

• The lowest common denominator mentality. This means that Project Managers expand the time allocated for tasks to match the speed of the slowest team member. Naturally this impairs the rest of the Project team, and creates a lot of unnecessary slack, and consequently inflating the overall cost of the project.

 

• Skepticism about the team members' own estimates. Almost every Project Manager learned this the hard way, team members in any project are optimistic in their estimates (team members often say "sure, it'll take 1 day" for a 3 day task), they are over-confident and they don't see the big picture. Project Managers tend to buffer extensively their team estimates. Tripling and quadrupling the initial estimates of the team members is not unheard of.

 

 

• Laziness and ignorance. Some Project Managers are too lazy to know the members of their project team personally and/or to spend some time to study the technology being used which they're completely ignorant of, so again, they protect their numbers by largely inflating the estimates. Parkinson's Law thrives most in this case (which is the worst case).

 

There are many other reasons out there that make the Project Managers unnecessarily inflate their estimates, but they are all derived from the first reason, "Keeping promises".

How should Project Managers address Parkinson's Law?

 

In short, Project Managers should do their job properly. They should be sure to know each and every team member personally, his weaknesses, his strengths, his real output, his reliability under stress. Project Managers coming from a technical background are the best candidates to beat Parkinson's Law, simply because they know the real ins and outs of any task, if it's easy or hard, if it takes an hour or a week, and they'll be able to assess objectively the estimates given by the team members and deduce some near-accurate estimates themselves. Needless to say, experience in Project Management plays a huge factor in overcoming Parkinson's Law and finishing the project within a reasonable time-frame and on a realistic budget.

 

Thanks & Regards,

Arun Manglick