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.

Yes, 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 ? 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.

The 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 counter intuitive, 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.