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 in a project that runs, for example, 12 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 to keep her is usually just the cost of those three more months.  No problem just adding 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 to then 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 upon the “truism” that effort expands to fill the available time.   Parkinson’s 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 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 right the 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 turn 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 phenomena.  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” centric notion that I believe has some merit but doesn’t explain things well enough for me.

Squeezing project management schedules squeezes qualityI describe it a little bit differently, based upon 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 were 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 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. Sharing and comments tells me which articles are most helpful to my readers:
Facebook facebook   Twitter twitter   Linkedin linkedin   Tumblr tumblr   Pinterest pinterest   Stumbleupon stumbleupon   Reddit reddit   Email email  

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

  1. 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.

    Bruce

  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.

    D

    1. D,

      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.

      Bruce

  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. Victor,

      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.

      Bruce

Leave a Reply

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

Name *
Email *
Website