Freigeben über

An inverse to Parkinson’s Law?

  • Artikel

I asked in a previous post if Parkinson’s law (Work expands to fill the time available) also worked inversely – i.e. Does the work get done more efficiently given less time to complete it.

The answer, like the answer to most questions I ask, is “It depends”. I think we can all relate to situations where a deadline forced us to focus more on the task at hand than we would have otherwise, allowing us to accomplish our work in a shorter amount of time than we thought it may take. Sometimes this happens because of unanticipated deadlines, and sometimes it happens because of simple procrastination. I think we all have had situations where the shorter amount of time to complete our task caused us to be more efficient with that time.

But the “anti-Parkinson law” still doesn’t hold water. First off, it doesn’t sustain. If I just chop all of my estimates by 20% and count on the anti-Parkinson law to force me to be more efficient, I may get the first deliverable on time, and I may even get the second or third deliverable on time. But the burnout factor is increased, and at some point the whole remainder of the project goes way south. Another failure of the anti-Parkinson law is that it’s limited. I have a two-week project, it doesn’t work to cut the project to 2 days and rely on efficiency to make up the time. In fact, the opposite usually happens. If you only give me two days, you may want two highly productive days working towards the 2-week goal, but what you get is chaos and little output while I try to figure out what I can possibly accomplish in 20% of the time originally allotted.

OK – the anti-Parkinson law doesn’t work, so now what. I do believe that reasonable estimates (and reasonable deadlines) can force efficiency – but it’s a fine line between forcing efficiency and forcing burnout. To use yet another music metaphor, it’s like mixing as loud as you can without going “into the red” – i.e. distorting. You need to watch the estimates and know which buffers are realistic, and which buffers are padding too much and creating inefficiency.

I don’t have a great answer on how to control those levels well, but I do know that if you talk to teams that are using Scrum (really using scrum), that some of these folks are close. Cranking on all cylinders throughout a release shouldn’t be an unreasonable goal for anyone – unless, of course, you don’t care about delays or cost overruns.

Comments