SCRAPPY PROJECT MANAGEMENT
Project Management Dialogues with ATTITUDE!

by Kimberly M. Wiefling, M.S.


This Month's Featured Noggin' Floggin':
Why Schedules Are Always Late and What to Do About It –
Timeline Risk Analysis for Predictable Project Schedules


When is the very first moment that you know a project will be late? For most projects, it's day one. My first project management text book proclaimed "A well run project takes from 50 to 100% more time to complete than predicted, and poorly run projects require two to three times as long as planned." Every year I ask my project management classes "Who has worked on a project that finished on time?" Very few hands go up. In spite of intellectually fascinating developments in scheduling theory and more sophisticated software tracking tools, most projects still finish much later than originally expected. In my experience, most schedules are obsolete the moment the Send button is pressed, and are nothing more than an exercise in documenting the project's demise.

Sometimes projects are late before they even start because they should have been started months sooner. Once they are finally started, teams can be loath to spend the time required to properly plan the project. Given a choice, most people will either under-plan or not plan at all, and many crises experienced during a project can be traced back to poor planning. Recognizing that most projects are under severe time constraints means that planning must be accomplished quickly in order to meet today's challenging project completion dates. In time-urgent situations it is natural to want to jump into activity without sufficient planning. Activity can be a comfortable, if temporary, substitute for progress. But every hour spent planning saves between six to eight hours of misdirected effort and rework. As a project leader, your role is to assure that enough planning occurs to optimize results regardless of how busy people are. Some people even become addicted to the adrenaline rush of firefighting. Beware: Firefighters carry matches!


Why Schedules are Late

There are some causes of schedule slips that are completely unpredictable and unavoidable. But most of the time the beast that bites us could have been anticipated. Think about it. When things don't go according to plan you can usually find some smarty-pants who will say, "I could have told you that was going to happen." Or you'll happen across the list of risks and, there it sits, the cause of your schedule slip, identified but not mitigated. These completely predictable and largely avoidable delays are responsible for no end of late nights, weekend work and anxious hand-wringing bouts, many of which still fail to avoid the missed deadlines. As project leaders, we owe it to our project teams to eliminate these déjà vu experiences.

In my experience, the most significant preventable causes of unachievable schedules are:

  1. Human brains are lousy at making estimates.
  2. Bottoms up scheduling methods give too little attention to handoffs and integration points.
  3. Executives and project teams engage in "The Lying Game."
  4. Teams wait until the schedule slips before intervening.
  5. Lessons learned from previous project AREN'T!

1. The Estimation Game

The human brain is notoriously poor at accurately estimating probabilities. Left untrained, our brains are wired to make guesses based on a 50% chance of success. As a result, people tend to underestimate the duration of a task, or over-estimate the likelihood of completing a task in a given period of time. There is an exercise that illustrates this beautifully. Ask your project team to guess a dozen or so commonly known quantities, such as the number of feet in a mile, the circumference of the earth, or the weight of a Ford Mustang. Rather than a single number, instruct them to provide a range that they believe has an 80% chance of containing the actual value. This is done by setting a lower limit that has only be a 10% chance of being higher than the actual value, and an upper limit that has only a 10% chance of being lower than the actual value.

Tally up the number of actual answers that are "IN RANGE" and OUT OF RANGE" for the entire group. What percentage fall within the estimated ranges? If people truly could estimate accurately, 80% of the actual values would fall within the predicted ranges. If we think that we're making 80% confidence estimates when in fact we are only making estimates with a 60% chance of being correct, it's no wonder that even well run projects stretch to twice their predicted length. What's worse, probabilities combine in such a way that the overall chance of a string of tasks being completed as predicted can quickly fall to less than 10%. For example, for independent tasks, if one task has a 60% chance of completing on time, and the next task also has a 60% chance, there is only a 60% x 60% chance (36%) of both completing on time. For 5 such tasks in a row, 60% x 60% x 60% x 60% x 60%, the odds of the entire chain of tasks completing on time plummet to less than 10%. Programs like @Risk or Risk+ enable ranges of estimates, but most software tools only require a single number estimate for each task, resulting in a less than a 5% chance of an on-time completion for the project overall.


2. Frankenstein Schedules

Individual departments, such as Marketing, Engineering, and QA, estimate their part of the project. The project manager then stitches them together into a schedule Frankenstein by linking interdependencies between departments. Quite often these different departments don't even meet to discuss the overall schedule. This widely used bottoms-up scheduling practice typically underestimates the difficulty and duration of key integration points. The lack of cross-functional review can easily result in overlooked interdependencies. As any systems thinker can tell you, the best way to reduce the length of a schedule is to first eliminate tasks, overlap tasks, reduce interdependencies, and eliminate points where too many tasks come together simultaneously. Frankenstein schedules don't have the benefit of any of these systems thinking approaches. Rather than seeking a better overall plan, when disaster strikes the individual departments and tasks are squeezed to crash the critical path, a sub-optimal approach to shortening the schedule at best


3. The Lying Game

There is a codependent dance that occurs during the scheduling process that obscures the truth about how long a project will take. Executives are routinely frustrated by the project team's inability to predict completion dates for critical milestones to which they can then be held accountable. They put pressure on the teams to meet critical business needs regardless of the risks. In a misguided attempt to head off random schedule cuts that could jeopardize project success, project teams insert buffer throughout their schedule in "salami slice" style that puts an unmanageable bit of buffer into each task duration. This approach to reducing schedule risk ignores the well-know student syndrome, where tasks are not started until just before they are due, as well as Parkinson's Law, which states that the duration of a task will expand to fill the time allotted.

Executives, suspecting that their teams are sand-bagging in this salami slice fashion, push back on what they assume to be inflated schedules, sometimes arbitrarily cutting significant chunks of time out of the project without making accommodations in scope, resources or risk tolerance. The dysfunctional extreme of this behavior is to add even more buffer prior to the random cuts. Layer upon layer of deceit accumulates, until no one is quite sure how long anything should take. Successful projects can't be built on the quicksand of this kind of mistrust. When the project train inevitably jumps the tracks, attention turns to the blame game instead of dealing productively with the issues plaguing the project. By this time, the team feels almost no responsibility to meet the schedule, which has lost all credibility.


4. Schedules Are Wrong on Day One

When do you know a schedule is going to slip? The first day of the project. Why? Because they pretty much always do! And yet many teams don't implement schedule compression tactics until they are so far off track that the odds of recovery are slim. Schedules slip by months an hour or a day at a time. Before anyone realizes how bad it is, it's worse! And failure is not an option. With cycle times shrinking, there is little chance to do it over, and a great deal of pressure to get it right the first time. This is at odds with the pressures to take risks with the schedules.

You don't need to be a fortune teller to know that all schedules using single number estimates for durations and due dates are wrong from day one. In the early days of PERT charts it was known that using estimates of a "most likely" duration as well as a range from best case to worst case enabled far more accurate estimates than single number estimates. Unfortunately the widespread use of scheduling software that requires only a single number has made implicit the uncertainty and variability that was contained in the original PERT chart 3 number estimates. This has contributed to the illusion that schedules are highly accurate and precise even though most of them belong in the fiction section of the local library.

Shall we just accept the status quo? After all, you'd be hard pressed to find anyone who willingly admits that they are contributing to fictitious schedules. If no one's causing this, who's in a position to do something about it? Look in the mirror, project managers. You get the tough job once again!

A project leader who asks for a duration estimate for a task and is content with an answer like "2 weeks" has just increased the odds that the schedule will be late. She asked the individual to lie to her, and the individual obliged. In order to obtain a meaningful duration estimate the conversation needs to be more along the lines of the following scenario:

Project Manager (PM): "How long do you think this task would typically take to complete?"

Individual Contributor (IC): "About 2 weeks." (Remember, the typical human brain gives a 50% likely estimate.)

PM: "What are all of the things that could make it take longer?" (Do the downside first - most people find this easier!)

IC: "Blah, blah, blah, blah, blah, blah . . ." (on and on about all of the myriad things that could go wrong).

PM: "Hmmm . . . Good points. Given all of that, what's the longest it could take supposing that we wanted to be sure that 9 times out of 10 we could finish within the estimated time?"

IC: "About 4 or 5 weeks."

PM: "Great! Now what could make go faster than 2 weeks?"

IC: (Usually a long pause and then ... ) "I can't think of anything." (Which, if true, means 2 weeks isn't even 50% likely to happen!)

PM: "Come on. Suppose you had a magic wand and all of the resources and money in the world at your disposal. What could make it faster?"

IC: "Well, if we didn't have to go to so many meetings, or if my computer was faster, or if I had some help with the documentation, or we could have a test shift at night so I could get feedback the next morning on my work each day."

PM: "Great – given all of that, how much shorter could it be, say supposing that only 1 time in 10 we could expect to do it faster than that?"

IC: "About a week and a half." (Notice the asymmetry - it's easier to significantly lengthen a task than to shorten one. Herein lies another underappreciated reason that projects are rarely completed before the schedule predicts.)

PM: "Thanks! You've been a big help."

Let's face it, project leaders can't pay attention to all possible threats to the schedule with equal devotion. Project leaders need to know which tasks are the ticking time bombs so that they can focus their limited energies on managing those risks. The conversation above provides tremendous insight into the potential variability of each task. If a particular task could run from 2 days to a week to as long as a month, you can bet you'll want to pay a lot more attention to it than if the variation is from 25 to 28 days. And holding this kind of conversation immediately enrolls the team member in thinking through potential risks and accelerators associated with their tasks. The Timeline Risk Analysis Dialogue illustrated above enables the scheduling process to incorporate thoughts of what might go wrong early enough in the schedule for the individuals involved to make plans to avoid or reduce those risks. The discussion of possible upside, which granted, requires a great deal of trust between team members and the project leader, gets each person thinking about what can go right. After such a conversation people naturally start to think about how they can make it more likely that this project avoids risk and enjoys some upside.


5. Lessons Not Learned

Frequently the cause of today's project schedule slip can be found on the last project's "lessons learned" list. Time and again project teams fall prey to the same "unanticipated", yet predictable, delays. How many times does it take to "learn" that people take vacations in the summer, that less work gets done during the holidays, and that individuals tend to fall ill during the winter? How often must we run a project with one design spin or QA test cycle in a schedule when the odds of needing two or more are practically 100%? Organizations have an amazing ability to combine a great many intelligent people that create an aggregate that has the approximate intelligence of an insect. My speculation is that the "lessons not learned" phenomenon is a result of either perpetual hopefulness, unabashed lack of humility about how much less talented the previous team was, or mass amnesia. Hope is not a strategy! Whatever the cause, allowing your team to fail for entirely predictable reasons is inexcusable.


If You Fail, Fail In New and Exciting Ways!

Failing due to unpredictable surprises is disappointing, but failing due to predictable, avoidable, and recurring mistakes undermines morale and productivity. Teams become understandably cynical when they give their heart and soul to a project only to see it led down a well-worn path of past project mistakes. If on-time delivery is critical to success, the project leader must facilitate the creation of a challenging, yet achievable, schedule that enjoys the commitment of the people who must carry it out. It can be done, and it must be done! Here are 5 easy ways to assure that your project doesn't end up on the "I could have told you so" scrap heap.

  • Use the Timeline Risk Analysis Dialogue. Humans need help to make accurate estimates. Make allowances for known biases in human estimating capabilities and enable your team to make better estimates by the way that you ask for their inputs.
  • Avoid the Frankenstein Schedule. Don't give up the most powerful leverage that you have in scheduling, the opportunity to optimize the PERT chart before compressing individual tasks. Include the cross-functional parties in a shared dialogue about the most advantageous overall schedule rather than stitching together independently prepared Gantt charts from each functional silo.
  • Be absolutely committed to achieving the business-driven schedule that the executives require, but make sure that it is based on a sound plan, not wishful thinking. Executives will push for the business goals to be met, but you must engage them in a dialogue about how to achieve these goals by design. The honest, albeit awkward, discussions that ensue will increase the respect between them and the project team, and put an end to "The Lying Game."
  • Launch pre-emptive strikes against disaster! Start preventing and mitigating schedule slip at the very first moment that you become aware that the schedule may slip, usually the first day of the project.
  • Review the "Lessons Learned" from previous projects and scrutinize the schedule to assure that the same time bombs are not planted in the new project plan.

Critical Path Hot Potato

Fortunately many supposedly "time-critical" projects won't amount to a death sentence to the project or the company if the schedule slips. But occasionally a project deadline IS more than an arbitrarily established executive hallucination set to "motivate" the team to "go the extra mile." There are times when a schedule absolutely MUST be met in a predictable way. That's when you need to cut through the all too prevalent web of lies and self-delusion that cause most schedules to earn smirks and derision from the team. When you need a schedule that you can stake your reputation on, it's time to cut the B.S., pull out your scrappy scheduling skills and unmask the naked truth. In these circumstances, placating executives who demand an unrealistic schedule that will ultimately slip week by week to the original realistic date just won't do. Don't let the critical path hot potato land in your lap! Take these sensible steps in creating your schedule, or it's déjà vu all over again for you and your project team.





Related Links
Estimating and Scheduling
Estimating Process and Methods
Pete's Estimating Laws
Scheduling Checklist

More scheduling and WBS resources

Risk Assessment and Mitigation
Product and Project Risk Assessment and Mitigation Tables
Risk Management Model
Project Alternatives Tradeoff Table




©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy