Parkinson's law says that all work expands to fill all time available for its completion.
This has be proven statistically to be very true, so nobody can doubt it. However some of the consequences of this law often go unnoticed as the law's wording and meaning gets twisted and turned over to suit one's needs.
We all know that project estimation is akin to solving NP-complete problems. You only know the exact answer after you have finished all the work. There are many shortcuts around the problem, but the exact answer requires you do all the work, like in an NP-complete problem the exact answer can be found only by examining ALL combinations.
Now suppose you have a project to do, that *really* needs 5 calendar months to complete, working at the best of your abilities, no interruptions, etc. What Parkinson's law says is that if your manager gives you 6 months to complete it, then your work will 'somehow' expand and you will do 6 months instead of 5, still working at the best of your abilities. You might add a few extras here and there, some more performance testing, whatever, it doesn't matter what. The work will expand to 6 calendar months.
From your point of view, this extra month adds significant value to the end result. However from your manager's point of view it adds more COST than value. And your manager is trying to get everything done at both the absolutely minimum quality level acceptable by the client and at the absolutely minimum cost so that she can maximize profits for the company (and her fat bonus too).
But there are costs and costs. One cost your manager cares about is the actual grand total, but then there is another cost she cares about: unpaid overtime, or to put it diplomatically 'human capital utilization'.
The grand thinking of high-level managers is that when developers are working normal hours the company is losing money. It is clearly losing money because according to Parkinson's law it is clear that the developers are doing less actual work, expanding it to fill their day, up to 'normal working hours'.
If developers could be pushed to work 10 hours instead of 8 every day, then even though Parkinson's law still applies, they will get more work done every day. This means the company improves it's human capital utilization and thus saves costs.
Now let's get back to the project level. No one knows the time required, so the manager, the client and the development team negotiate and agree to an estimate. Let's say 12 months.
After 12 months the project is ready, up and running, and the development team is celebrating. The manager might be celebrating too, but at the back of her head one thing is clear. She overestimated the project and the project expanded to 12 months according to Parkinson's law. If it could be done in 12 months then it could easily be done in 11 months or even 10 months.
The manager clearly FAILED to minimize costs. The manager will now be perceived by her peers (and her boss) as being SOFT because she clearly didn't push the team hard enough.
The project succeeded but the manager FAILED!
Now comes the nice part... Suppose that a time traveler from the near future visited the manager at the negotiation phase and told her "You can do it in 11 months". The manager fancied this guess and in fact the project was successfully completed in 11 months. On Time again... Failure again... for our poor manager... If it was done in 11 months then it can clearly be done in 10, maybe even 9 months...
So you can now see the great corollary to Parkinson's law, which we could call "The Law of Late Projects":
Management will always try to make a project late.
This is usually done by choosing a very optimistic deadline or, if the project seems to run smoothly, by introducing more work, changing the requirements, changing key people, replacing experienced team members with rookies, etc. You name it. As soon as a project appears to be on track the manager starts to panic; She is losing money for the company; She appears soft; She must ACT.
Have Fun!
Dimitris Staikos
Personally I don't believe in Parkinson's Law on a task level. I work as a software developer and when I get a task that I can complete faster than was estimated I don't sit there and do nothing just because estimation would allow me to work e. g. 2 days longer on it. On a project level however I have the impression that there is never enough time to really complete a project. Most of the time a project is released before it really is done. I guess your law of late projects explains that now.
So I would say the following is true:
If there is more time than needed to complete the work, the work is delivered earlier.
If there is less time than needed to complete the work, the work will be delivered unfinished (maybe polished a bit to hide that it is unfinished) and project management will accept all risks because they are only measured if they deliver something on time.
Posted by: Michael | November 29, 2009 at 04:22 PM
It is an interesting view ... but differs from what I've seen in my experience.
The reason for the "infinite expansion" of work is that no project ever gets to the point where there is nothing to improve:
1. You built a website. It would be cool if users could leave comments on different pages.
2. Users can leave comments. It would be cool if they could subscribe to receive further comments by email.
3. Users can subscribe to comments. It would be cool if they could see all their subscriptions on one page
4. etc., etc.
Once a project is declared "complete", manager's thoughts are usually with the features the team didn't implement, the bugs that were closed without fixes, the performance issues in rare scenarios, etc.
She understands (or at least should understand) that if the deadline was a month sooner, most of the difference would be made up by even harder functionality cuts, rather than by developers working longer hours.
Igor Ostrovsky
-- http://igoro.com/
Posted by: Igoro | November 30, 2009 at 01:10 AM
Fascinating article. Thanks for posting it. I have posted a link to it in my 'other' blog, unless you object and instruct me to remove it.
From my limited experience in the industry what you say is at least statistically correct.
Posted by: Boris Liberman | November 30, 2009 at 08:45 AM
The inverse Parkinson's law also work, and sometimes it does so 200%:
"A client expands its feature list to occupy all the planned time of the project. Most even go beyond and ask for features that often make the schedule impossible.
There's nothing wrong with it, its just the client's job: maximize value in the product they are buying.
Its up to you and your contract to educate the clients.
Posted by: Bruno Cassol | December 01, 2009 at 06:09 AM
Most of the time a project is released before it really is done. I guess your law of late projects explains that now.
Posted by: parkinson illness | March 09, 2010 at 11:22 PM
If there is added time than bare to complete the work, the assignment is delivered earlier.
Posted by: Vimax | May 25, 2010 at 08:04 AM