Parkinson’s Law in Project Management: How to Fight It

What is Parkinson’s Law, exactly?

parkinson’s law in project management is a key topic in modern project management and teamwork. It is a 1955 satirical essay that turned out to describe something real. Parkinson, a naval historian, opened with a domestic example: an elderly lady of leisure can spend an entire day writing and posting a single postcard — an hour finding the card, an hour hunting for spectacles, half an hour locating the address, an hour and a quarter composing, twenty minutes deciding whether to take an umbrella. The same effort would occupy a busy man for three minutes.

From there he moved to administration. Using British Admiralty estimates, he observed that the number of officials grew from about 2,000 in 1914 to 3,569 in 1928 — roughly 78% — while the fleet they administered shrank. His explanation had two engines: officials multiply subordinates rather than rivals, and officials create work for each other.

The sentence everyone quotes is the first one. The mechanism worth remembering is the second: the time available becomes an input to how the work is done, not just a boundary around it. If duration shapes effort, every padded estimate is an instruction to work more slowly.

Is there real evidence behind it?

Yes, though narrower than the folklore suggests. The claim that survived testing is not “employees pretend to be busy” but “people adjust effort and pace to the time allowed.”The cleanest field evidence comes from Gary Latham and Edwin Locke, whose 1975 study in the *Journal of Applied Psychology* examined 379 logging crew members. Crews produced significantly more when mill deliveries were restricted to one or two days a week than when no such constraint applied. Same workers, same equipment, tighter time boundary, higher output.

Laboratory work points the same way. Brannon, Hershberger and Brock, publishing in *Psychonomic Bulletin & Review* in 1999, gave participants photo-judging tasks and told one group that a later set had been cancelled. That group dawdled on the current set, taking longer than controls. The effect replicated three times. Earlier studies in the 1960s found similar results when subjects were accidentally given extra time.

None of this proves that every padded schedule is wasted. A faster pace can produce worse work, which is why the countermeasures below include quality gates rather than pure speed pressure. But the core mechanism is not a management myth: it reproduces in the lab and in the field.

Where does Parkinson’s Law hide in a project plan?

In four places, and they compound.

Two observations about that table.

First, padding is not dishonest. Contributors add safety because they are punished for being late and rarely rewarded for finishing early, which is why asking people to “estimate honestly” changes nothing.

Second, the symptoms interact: padding makes early starts feel unnecessary, which produces student syndrome, which consumes the padding, which makes the next estimate more padded. The loop is self-reinforcing.

Why does padding make projects later rather than safer?

Because safety held at the task level is invisible, unmanaged, and usually spent. The arithmetic makes it concrete.

Worked example: ten tasks, one day of padding each

A team plans ten sequential tasks, each estimated at four days of real work. Each estimate is padded by 25% to five days, because nobody wants to be the person who underestimated. The plan is 50 working days.

What happens in practice:

• Actual work per task: 4 days
• Scheduled window per task: 5 days
• Work starts on day 2 of each window (a mild case of student syndrome) and finishes on day 4
• Each task still occupies its full 5-day window, because the next task does not start early
• Elapsed time: 10 × 5 = 50 days
• Idle time embedded in the plan: 10 × 1 = 10 days, or 25% of the 40 days of real work

The project finished exactly on the padded date, with ten days of slack that nobody saw evaporate. No individual was late. The plan absorbed the available time precisely as predicted.

Now change one variable: report early finishes and let the next task start immediately. If half the tasks finish a day early and the successor starts that day, the project ends around day 45 — a 10% schedule improvement from a reporting rule, not from working harder.

> Important note: Cutting estimates is not the same as cutting scope. The countermeasure here is to remove *invisible* safety and manage it *visibly* in a buffer — not to demand that people work faster than the work allows.

What is the student syndrome, and why does it matter more than procrastination?

Student syndrome is delay that happens because the deadline looks comfortable. It differs from procrastination in one important way: it is rational within the plan. If a task has five days and takes four, starting on day two is not irresponsible — it is what the schedule permits.

The damage is structural. Individual buffers exist to absorb variance, and variance is highest at the end of a task, when the remaining work is least understood. A late start removes exactly the buffer meant to cover late-stage surprises, so the task finishes late even though it never needed more time.

The project-level consequence is worse. When every task starts late, the protection is spent before the first real problem arrives — which is why generous schedules often fail with less resilience than tight ones.

Does Parkinson’s Law apply to meetings as well?

Yes, and the meeting version is often more expensive per hour saved. Parkinson described a related principle — triviality — where a committee spends disproportionate time on small items because everyone can comment on them, and approves the large, complex item in minutes because nobody can. The time-allocation version is easy to see: a one-hour slot with eight attendees has no reason to end at 25 minutes, even if the decision was ready at 20.

Worked example: the cost of a default hour

Eight people in a one-hour meeting, at a loaded cost of $75 per hour each:

• One-hour meeting: 8 × 1 × $75 = $600
• Same agenda timeboxed to 25 minutes: 8 × 0.417 × $75 = $250
• Saving per meeting: $350
• Across 90 similar meetings a year: 90 × $350 = $31,500

It also excludes eight people losing a 35-minute block.

The fix is not “shorter meetings” as a slogan but a timebox with a required decision per agenda item, a pre-read, and 25- or 50-minute defaults. A meeting that cannot state its decision should be cancelled.

What is the critical chain response, and does it work?

Critical chain project management, developed by Eliyahu Goldratt in the late 1990s, is the most direct structural answer to Parkinson’s Law: remove safety from individual task estimates, then pool it into shared buffers managed at the project level.

Worked example: pooling buffer on a 15-task chain

A project has 15 sequential tasks on its critical path, each estimated at three days with safety included. The naive plan is 45 days.

Apply the critical chain method:

• Cut each task estimate by roughly half, removing task-level safety: 15 × 2 = 30 days of aggressive-but-achievable work
• Aggregate the removed safety into a project buffer: 15 days of removed time × 50% = 7.5 days
• Protected plan: 30 + 7.5 = 37.5 days

The project keeps the same protection — 7.5 days instead of 15 spread invisibly across tasks — but it is visible, owned by the project manager, and consumed only when a real problem occurs. The plan is 17% shorter without asking anyone to work faster than the original estimates allowed.

Three rules make buffers work rather than decorate a Gantt chart: the buffer has an owner and a trigger (one-third consumed means review, two-thirds means recovery plan); early finishes are reported and passed forward, or the pooled buffer behaves exactly like task padding; and the buffer is not a slush fund for scope changes.

The trade-off is real. Critical chain requires discipline across the whole chain and can feel artificial where local efficiency is rewarded. Teams that cannot report early completion honestly will not get the benefit.

How do you estimate without padding?

You replace intuition with data, and separate the estimate from the commitment. Three techniques do most of the work.

Reference class forecasting. Instead of asking “how long will this take?”, ask “how long did the last twelve things like this take?” Use the distribution, not the average. If similar integrations took 9, 11, 14, 10, 22, and 13 days, the honest answer is a range with a long tail — and the 22 is the most informative number in the set.

Three-point estimation with a stated confidence level. Optimistic, most likely, pessimistic. The arithmetic matters less than the conversation it forces about *why* the pessimistic case exists. “Five days at 80% confidence” is more useful than “five days, hopefully.”

Historical throughput. If a team completes about 34 story points per two-week sprint, promising 60 is arithmetic denial, not ambition. Throughput commitments are self-correcting because the data comes from the same system that has to deliver.

Then keep the estimate and the date separate. The estimate describes the work; the date describes the business constraint. When they are the same number, safety migrates into the estimate and disappears. When they are separate, you can say “this is 22 days of work and we have 16” and have a real conversation about scope.

> Practical tip: Keep a simple table of estimated versus actual duration for each task type. After about 30 data points, your estimates stop being opinions. This is the highest-return habit in project planning, and almost nobody does it.

How do you set time boundaries that resist expansion?

Four mechanisms, in rough order of impact.

Timeboxing. Give work a fixed, short window rather than an open-ended one. A specification that has been “in progress” for three weeks gets a two-day timebox and a decision: ship what exists, cut scope, or kill it.

Definition of done. Most task expansion happens at the blurry edge of “nearly finished.” An explicit checklist — reviewed, tested, documented, accepted by X — makes completion binary.

Work-in-progress limits. If a team can only hold three items in progress, new work waits in a queue rather than stretching existing work. WIP limits attack the multitasking version of the law.

Decision deadlines. Approvals expand because nobody sets a date for the decision. “We need to decide by Thursday” is often worth more than a timebox on the work, and weekly demos expose expansion while it is a week old rather than a quarter old.

When is Parkinson’s Law the wrong diagnosis?

Three situations where applying it does damage.

Genuinely uncertain work. Discovery, research, and first-of-a-kind engineering have wide variance no timebox can compress. Cutting the estimate produces optimism, not speed. Fix a timebox for the *investigation*, then re-plan with what you learned.

Work where quality is the point. Safety-critical testing, accessibility review, and regulatory validation should not be accelerated to satisfy a scheduling theory.

When the constraint is elsewhere. A task that takes longer because it is waiting on an approval or a missing environment is not expanding to fill time — it is blocked. Shortening the estimate will not help; removing the blocker will.

> Common mistake: Responding to a late project by compressing every estimate by 20%. That produces optimistic plans, missed dates, and a team that learns to distrust the schedule. Compress the *plan structure* — remove task padding, pool the buffer, cut scope — not the arithmetic.

Common mistakes in fighting the law

• Treating it as a motivation problem. Slogans do not change the incentive to pad.
• Cutting estimates without pooling safety. You get an aggressive plan with no protection, which fails worse than a padded one.
• Removing buffers entirely. Zero buffer means the first surprise becomes a crisis.
• Timeboxing without a definition of done. The box ends, the work does not, and boxes become decorative.
• Measuring utilisation instead of flow. If everyone must be 100% busy, queues grow and everything slows.

How do you make the boundaries visible in practice?

Parkinson’s Law thrives on invisible time. When planned durations live in one document, actual work in another, and early finishes in a chat thread, nobody can see expansion happen. The fix is to put the planned window, actual start, actual finish, and reason for variance in the same place.

That is the practical case for keeping tasks, estimates, due dates, dependencies, and status history in one workspace. Doitify is our product, so discount accordingly — but the relevant features are ordinary: explicit start and due dates, checklists that act as a definition of done, dependencies that show whether a delay moves the critical path, and reports comparing planned against actual. Nothing exotic; it just makes the invisible visible.

Conclusion

Parkinson’s Law is not a moral failing, and fighting it with effort is a category error. The law describes what happens when a plan gives work more time than it needs and then makes early finishing invisible.

The countermeasures are unglamorous: estimate from data, separate the estimate from the date, shorten the timebox, define done precisely, pool safety where it can be managed, and report early finishes as loudly as late ones. Do that and you stop paying for slack you never used.

The test is simple. Look at your last completed project and ask how many days were spent waiting inside a task’s own window. If the answer is more than a handful, the law was not working against you — your plan was working for it.

If this post on parkinson’s law in project management was helpful, you might also enjoy Project Timeline: How to Create One (Step-by-Step Guide) and Social Media Campaign Project Template.