We know that throwing additional resources at an already late project rarely makes the project run on time. Often it only makes it run later. Similarly, going with an aggressive project management schedule date for the purpose of actually hitting a later date is equally counterproductive.

What is often not noticed is that the productivity and quality of a project that runs, for example, for twelve months is not the same as a project that is planned for nine months and then takes three months more. Mathematically, to the project manager, those three extra months may look just like a linear extension of the cost of the project. If I keep a programmer on the project for three more months, the cost of keeping her is usually just the cost of those three more months. No problem, just add a few more weeks or even months, yes?

Too many folks, and I’ve seen this in the most senior of VPs, feel that aiming for an aggressive schedule and then slipping out a few months is a good approach. It was normal in a large multinational company I worked for that when wanting a product in the 4th quarter, they would aim for the 3rd quarter and then slip 3–4 months to ship in the 4th quarter.

This approach seems based on the “truism” that effort expands to fill the available time. Parkinson’s First Law states: Work expands so as to fill the time available for its completion. The Wikipedia entry for Parkinson’s law is presented in a way to suggest that it is a well-established principle.

I don’t think so. Or, at least for the last 30 years, I keep finding organizations and companies that simply don’t follow Parkinson’s law. I’m not saying some don’t. I’ve just observed that it is more often the exception rather than the rule.

The bulk of the evidence comes from those organizations I’ve helped move from late and low-quality project deliveries to on-time delivery. In most of these cases, the critical change to the approach was to get the right estimate of how long a project will take. This we usually found from researching historical records of past projects. It was not uncommon to hear “we average a few months” to deliver a product that turned out to be an average of nine months (an actual and typical example) once the real data was found.

For more on successful schedules see: Get The Schedule Right!

Once we started to use estimates that were close to the historical average, we started to deliver on time. In every case—every case in my 30 years—the quality did not just improve, it improved dramatically. So what exactly is going on here?

There are a lot of ways to explain this phenomenon. The most popular is that by rushing to get something done, we end up making changes and fixing things at the end of the project. Studies are then quoted saying that making changes at the end of a project is the most costly place to make a change. By giving the appropriate time at the beginning, we now have the time to get things right and have less need to make changes at the end. This is a very “waterfall” centered notion that I believe has some merit but doesn’t explain things well enough for me.

I describe it a little bit differently, based on my experience. Let’s call this Benson’s Bylaw. I’ve observed that most people will do the best job they can with the time given to them. Since too often the time one is given is too short, folks do the best they can, but it is not as good as they would do if given enough time.

Benson’s Bylaw: People will work at a quality deficit if given insufficient time.

When sufficient time is given, this quality deficit is less. Time given in small increments (the slipping period, those last three months, for example) is often also compressed (e.g., “fix it by Friday!”), and so there is little or no opportunity to make up the quality deficit. Giving sufficient time, the quality deficit is much smaller, and more things get done right the first time. We also don’t need to spend as much time fixing things that are broken (e.g., productivity improves). Finally, I’ve observed that process and productivity improvements increase noticeably when a team is given a realistic time frame to complete a project.

See related: Improving Quality Improves Productivity and How To Get It Right The First Time

What is useful about this observation is that it explains why Agile methods such as Scrum (or possibly Agile PM) can work well. Scrum, for example, uses a simple velocity, computed from previous completed sprints, to determine what the average capacity in a given sprint will be (think of a sprint as a sub-project; the velocity the number of requirements that can be accomplished in a fix time such as two weeks). It just captures history without trying to explain it, justify it or adjust it. I love it. The use and computation of velocity is a brilliant way to capture and use the experience I mention above. I know from use of what I call “past performance” that this works very well in software and non-software projects, even as folks often can’t believe something that simple could really be useful.

For more on simple averages, see Your Average Is Powerful

If you are still working in an organization that abides by Parkinson’s First Law and hence justifies overly aggressive schedules based upon it, suggest you tell them about Benson’s Bylaw. This bylaw simply states that if the project needs, for example, twelve months to get it done right then aiming for nine months and slipping by three months does not get us the same productivity, quality, and cost as does choosing an accurate schedule from the beginning.