Home » Schedule » In Project Management 9+3 Is Not Equal To 12

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.

project management tools parkinson's lawThis 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 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.

Squeezing project management schedules squeezes quality

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.

Thank you for sharing!

16 thoughts on “In Project Management 9+3 Is Not Equal To 12

  1. Bruce Benson says:

    Software Development Times, Sep 1, 2010 “It’s time to change … but how?” by Alexander Weber Morales

    “studies have found that creative solutions to problems actually decrease under external pressure such as deadlines ….” pg 19

    This is similar to what I’ve observed with teams moving from compressed schedules to realistic schedules. While the realistic schedule is still a challenge, more productivity improvements happen in the process as people have the time to innovate and improve how they work, rather than just “get it done” as best they can.


  2. Benson’s Bylaw – I shall remember that! I think the real nugget here is to plan based on previous experience.

    If I asked you how long it might take to commute home from work and you’d never driven before but knew the car could do 150mph you might answer 10 minutes. If you’re driving every day your experience world be the better judge: and might answer 30-40 minutes.


    1. Bruce Benson says:


      The key to previous experience I’ve found, is to really know that experience. A lot of very experienced folks have given me some very dubious estimates. When I ask them to go dig up evidence (past projects, etc.) they inevitably come back and give me significantly different estimates. Usually, much longer than the original estimates!

      Thanks for the comment.


  3. Victor E Felix says:

    The tenets as presented are correct and are present in those project that tend to be structured open-ended. Therein lies the problem.
    Every project requires clear, well communicated milestones which are to be completed on time and per specification. Like the classic saying goes, “without a destination, any map will get you there.” Therefore, reasonable milestones must be spelled out and include well defined deliverables, identification of who is responsible and clear direction for early escalations when milestone and/or deliverable tactivities are falling behind.

    1. Bruce Benson says:


      The challenge I’ve found is to get accurate durations between those”reasonable” milestones. The trick I’ve discovered is that while those multiple milestones might not all be met exactly as intended, if the overall schedule is in the right ballpark, then the variations in the individual milestones average out, and we are very close if not on our deadline. This works especially well in organizations that have a history of consistently missing their deadlines – to concentrate first on getting the overall schedule accurate (usually by using past demonstrated project performance as realistic benchmarks).

      Thanks for the comments.


Leave a Reply

Your email address will not be published. Required fields are marked *

Name *
Email *