In order to answer this question, let us examine the following:

• The PMBOK, considered by many as the final word when it comes to defining Project Management and its terms, is also divided on the subject. In the PMBOK version 3, task and activity do not mean the same thing. However, in the PMBOK version 4, the term task is not defined. Activity is defined as a work package (the lowest level WBS activity).
• As stated earlier, some Project Managers believe that a task is a work package, and may comprise (or may decomposed into) one or more activities. Their supporting argument is that a task clearly has a starting date and an ending date by definition, while an activity is vague from that perspective.
• It is unknown why there’s another group of Project Managers thinking that an activity is a work package that can be split into more tasks. This definition is the weakest as it has no logical grounds.

What Should I Do?

As one can see from the above, there are 3 different opinions and there’s definitely no consensus. However it seems that the PMI (who, again, has a huge say when it comes to Project Management) has moved towards unifying the meaning (again, from a Project Management perspective) by solely using activity to denote a work package. Having said that, it is important to note that it’s not a case of who’s right and wrong, and the best thing a Project Manager can do is to follow the standards of his company for the for the proper usage of Project Management terms, and if there are no standards set, then he can set his own. In that case, probably a good idea would be to use these terms interchangeably, along with job and operation, which also mean the same thing.

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

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 were 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.

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

An example of Project Progress would be: “The project is 72% as of today, December 3rd” (note that Project Progress refers to “Movement towards Completion”). An example of an activity in the Project Schedule would be “We will start the working on the interface on Monday, December 7th, and we will be finished by Thursday, December 17th.”

© 2009 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.