Home » Schedule » It Must Be Something Other Than The Project Management Schedule

The notion that an inadequate project management schedule is often the root cause of other problems in the project generated some insightful responses.   While insightful, they also illustrate what I consider to be the typical misconceptions we have about how project problems are just too complex to ever be “simply the schedule.”

The article on It Is The Project Management Schedule, Stupid produced some great discussions.  One particular comment that gets to the heart of what I advocate went like this:

Underestimates are rarely the root cause of anything. There is almost always a deeper cause that you need to correct to avoid underestimating.

For example, someone once said that in planning a project you only ever leave things out. In other words, a very common cause of underestimating is failing to identify the full scope of work.

Getting More Project Management Tool Schedule DetailsYes, I’ve found that errors of omission are much more typical than errors in execution. When we know what to do, we generally do it well. The normal solution is to plan more, get more people together, capture more details in Gantt charts, spreadsheets and databases. Based upon all these details, we lay out a plan and that gives us our schedule and costs.  (For more on how this often does not work as expected, see: Three Ways Project Management Estimates Fail And How To Avoid Them.)

If an organization is consistently late with low quality in its projects, I’ve never seen this approach – get more details up front – ever move them up to on time projects. I’m not saying that this can’t work – it certainly seems logical and sold by a lot of vendors – but I’ve simply not experienced it in large projects in my practice, career or in my research.

What has worked consistently and quickly is taking these same organizations and first putting in place realistic schedules. Gee, goes the thinking, if we don’t know the details, how can we produce a realistic schedule? This is traditional bottom up thinking. Work out the details, make the plan, execute the plan.

Instead, what works surprisingly well for many (all that I’ve worked with or for) is a past performance approach. The first and primary step is to ask ourselves how long has similar projects taken in the past (the article talks about what to do if we don’t have a history to draw upon)? If we put out multiple products in a year (even taking multiple years to produce) we have a lot of examples – past data – to work with.

In these companies, what we notice is that when we took recent past performance (how long it actually took) and compared it to the original past plans, there was always a significant and consistent shortfall between the plan and the actual (typically 20%-100%). And, some of these companies had huge and complex planning and tracking processes to try and solve this problem.

The “solution” to get them to on time schedules? Use the average project duration, for similar projects, from past completed projects. The initial observation, after the disbelief, was that the “new” overall schedule was always longer than past planned schedules. Typically longer than *any* past planned schedule. Once we got them onto an average schedule, they went from missing schedules by many months (typically 3 to 9) to at worst missing a schedule by two weeks.

Root Cause Of Late Project Management Tool SchedulesThe root cause? I agree – it was not the use of poor estimating techniques, but often a culture of “it should/must only take us X months!” where the plans often reflected that sentiment. I once watched as a great Monte Carlo based estimate was “tweaked” back to meet senior management expectation and then came in about 4 months late in an organization that averaged 3.5 months late. The use of “averages” to break them out of this mind set and to illustrate the disconnect is as much the benefit as finally delivering a product on time, with good quality (which is another benefit of hitting a schedule).

While it always seems somewhat counterintuitive, getting the schedule estimate right (in the right ballpark) helped solve (or actually, minimized the impact of) all the “normal” reasons given for why past projects were always late.

Thank you for sharing!

2 thoughts on “It Must Be Something Other Than The Project Management Schedule

  1. Bruce Benson says:


    “sandbagged the project” – I was hitting all my personal objectives for the year and my boss then accused me of “sandbagging.” I asked him how many of my objectives should I then miss? He hesitated, thought, and then said “none.”

    What I’ve found is that most projects of any size have “significant” changes. I like to argue that we can account for these unknowns, just like we can for known scope.

    How? Often by using past project performance. The best indicator is when we plan another “big” project, as big as any we had in the past, and yet the estimates are for a shorter schedule and lower cost. The argument is often, “we’ve learned and improved.” The telling question becomes “didn’t we say the same with the last project, that ran late and buggy?” Often, the answer is “yes, but this time it is for sure ….”

    Using a technique such as past performance takes into account all the normal things that go wrong, including regular and significant changes in scope. It sounds a bit counterintuitive, but it is equivalent of calculating risk (from hard historical data) and factoring it into the estimates. The final indicator is that the project goes along just as hectic and crazy as it ever has in the past — the difference being that when the smoke clears we are on time with good quality.

    The project takes about the same amount of time as previous projects and based upon how hard everyone worked, anyone suggesting “sandbagging” would find said bag in hand as one sank into the nearby lake!

    Good points.

    P.S. I think “first contact” quote goes all the way back to Clausewitz

  2. Gary Bernier says:

    Hi Bruce,

    Your note used one of those noreply Linkedin things.

    I had left a comment regarding; “It’s the schedule, stupid”

    I talked about the need to clearly establish the scope, budget, and deliverables at the beginning of a project. Your note suggested that I was indicating that a project must be ‘nailed down’ by doing that. You wrote:

    “The ability to change as the project went without significantly impacting the schedule became a competitive advantage.”

    To be clear, I fully understand that projects always change. It’s the nature of the beast. When teaching project management I often paraphrase Eisenhower, ” planning is essential, but plans are worthless after the first contact with the enemy.” The point being, you can do all the planning you want, but you better be prepared to change them based on changing circumstances.

    My comment regarding scope, budget, and deliverables is that any schedule you offer is based on those items. Everyone needs to understand that. If they change, the change needs to be agreed to and the implications understood.

    If you can accept significant changes in scope, budget, or deliverables and still meet your original schedule, then you sandbagged the project.


Leave a Reply

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

Name *
Email *