Parkinson's law and estimates

Each and every time I think about Parkinson's law, I think that Cyril Northcote Parkinson was a sort of genius, who could gain a great insight into people's heads.

For the few that have never heard about it, it's as simple as:

Work expands so as to fill the time available for its completion

I've not read the original book yet, but I've ordered it and I'll sure get back to the topic once I've read it.

What I'd like to talk about today is:

How does Parkinson's law influence software projects?

I believe that Parkinson's law is a major factor in delays in the software industry; that is, especially in situations where a turnkey approach is expected, but agile/iterative approaches are not exempt, it's just the effects that are smaller.

Whenever we produce an estimate and then give somebody a quote, be it a client or an internal customer, it's usually quite common to keep such estimate as a reference for the work being done.

If we're late, we cry and try to "do things faster". If, on the contrary, we are able to deliver faster than estimated, something weird happens: it's the "fraudphobia". If a customer is paying us for doing a certain work and we finish too early, it looks like we're scamming them, so we do unimportant things, maybe we refactor something or improve the product documentation.

This is true on the macro level (whole project estimates) as well as the micro level (single tasks that are individually estimated and whose sum produce the grand total for the project). This behaviour ignores the fact that estimates are usually wild guesses that should guide us during the project, but are not a detailed plan to be followed. It's perfectly normal for tasks to take longer than estimated. But, unless you're estimating a mythical scenario where nothing goes wrong, it's perfecly normal for tasks to take less time than estimated as well.

Let's suppose that we've got ten 100-man-days tasks in a project, and that half of those would be finished twenty days early, while the other half would finish with a twenty days delay. This would result on a perfectly on-time project.

But, most probably, if finishing before the estimated time, we would find other, possibly not-so-important things or improvements to do in order to fully employ the allocated time for each task. Hence, all tasks would take at least the time that was allocated for them, leading to a final 10% delay on the project. Parkinson's law along with estimates as references makes it impossible to finish a project on time.

Takeaway lessons

• If you never overshoot, you're consistently underestimating. Try harder.
• Plans are useless, but planning is indispensable (D.D. Eisenhower)
• It's done when it's done. How much we initially thought it would take us is irrelevant ¹

1: Of course comparing our estimates with the outcomes after a task is finished is a good idea, because it helps us at aiming better for our next estimate; but we should never use the estimate as a guidance.