Effective Engineering - e-Newsletter eN-071004

Effective Engineering e-Newsletter – 10/4/2007

This is your monthly e-Newsletter from Effective Engineering Consulting Services (www.effectiveeng.com). If you would like to receive Effective Engineering e-newsletters as they are published, please send an email to e-newsletter@effectiveeng.com, and we will add you to our distribution list. Comments and suggestions are welcome and encouraged!

eN-071004:

The Schedule Estimate Extortion Game
By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]

As a Project Manager or an Engineer, have you ever been caught up in the schedule estimate extortion game? This game works is as follows:

(1) Boss asks Project Manager for project schedule estimates.

(2) Project Manager in turn asks Engineers and others for their estimates, and working jointly with them, develops what he/she believes to be aggressive yet realistic schedule estimates.

(3) Project Manager submits the schedule estimates and Bosses at each level of the management hierarchy wince at the estimated date of product release and delivery, which they disparage as way too late.

(4) The bosses respond vigorously (“That date is simply unacceptable! You need to do significantly better to “improve” the schedule estimates!”).

[Note: Of course in this case their use of the code word “improve” means to shorten the date (the bosses may actually suggest the shortened date that they feel must be met), not to increase the accuracy of the schedule estimates. Shortening the date almost always actually decreases the accuracy. What is extraordinary about the entire game is that time and energy is spent to decrease the accuracy of the schedule!]

(5) In response to coercion from the many Bosses, the Project Manager tries to “improve” the schedule estimates to eliminate the Bosses’ wincing. In presenting the “improved” schedule estimates, the Project Manager lists all of the caveats, assumptions, feature changes, necessary pre-conditions, etc. that are required in order for the “improved” schedule estimates to possibly be met.

(6) The coerced and extorted “improved” schedule estimates that give the desired outcome are redefined by the many Bosses as precise commitments of schedule, costs, market share, sales targets, etc. The lists of caveats, assumptions, feature changes, necessary pre-conditions, etc. are promptly forgotten and/or ignored, and requests for help and assistance go unanswered.

(7) The real world happens and these schedule estimates are missed. Few if any of the caveats, assumptions, feature changes, necessary pre-conditions, etc. materialize, and other unanticipated problems develop along the way.

(8) The Project Manager and the Engineers are blamed and shamed for missing their “commitments”. The fact that the caveats, assumptions, feature changes, necessary pre-conditions, etc. failed to occur is ignored (“This is your schedule, not mine! I didn’t force you to make these commitments!”). The Project Manager and the Engineers are punished for their failure to deliver.

(9) The Bosses talk about what a great job they did in planning a good project, missed only due to poor execution by the Project Managers and Engineers.

(10) Strong sales roll in despite the delays, and the Bosses take big bonuses. The Project Managers and Engineers do not because they didn’t deliver as they “committed”.

OK, so maybe the game described above is just a bit on the cynical and sarcastic side (OK, maybe more than a bit), but there is still truth (often too much truth) in that cynicism and sarcasm. Something along these lines happens all too often in planning and carrying out projects. When it does, part of the problem is certainly due to the extortion and coercion exerted by the bosses. However, a significant part of the problem also clearly lies with the Project Manager and the Engineers for caving in to the extortion and coercion.

What are some ways that extortion and coercion can be effectively reduced or pushed back against so that all parties (including the bosses) can come away satisfied that they have done their part in planning an aggressive yet viable project?

Do you remember back in middle school science classes where you learned to use error bars on graphs to show the ranges of uncertainty for class project outcomes, or where you learned to be careful in the number of significant digits to be used to report experimental results? The idea was to carefully report the uncertainty inherent in any measurements, calculations, or estimates. The principles of knowing and reporting uncertainty are fundamental, well understood, and routinely practiced in science and engineering, except for project management (and among bosses J ).

The same lessons regarding uncertainty apply in developing schedule estimates (and in estimating costs, prices, market shares, sales volumes, competitor responses, etc.). As you define the tasks (and their dependencies) necessary to carry out a project you recognize that some tasks have very little uncertainty about them; you know exactly what must be done to carry out these tasks and exactly how much time will be required. However, there are other tasks where you know there is inherent uncertainty; you have a good idea of how long it will take if everything goes well, but recognize that it can take significantly longer if problems arise (e.g. if something must be invented along the way).

There are ways to reflect levels of uncertainty at the individual task level in many project management tools, such as Microsoft® Project, but many (most?) people are either not aware of these capabilities or don’t use them. Such tools have the capability of entering durations for each task for the Best Case, Expected, and Worst Case estimates. When task duration is known with absolute certainty, all three estimates would be the same. When there is uncertainty, different estimates can be entered for each of these cases. The tool will then use a weighting algorithm to generate a most likely estimated duration for each task (e.g. {best case + 4*expected + worst case}/6), but can also show what the Best Case, Expected, or Worst Case overall schedule estimates are based on these duration estimates, the task dependencies, and all of the other factors that go into schedule estimating. You will need to examine how such capabilities work for the tool you are using. The main point is to make use of such capabilities to make clear to yourself and others the error bars associated with your project schedule estimates and the specific areas in the project schedule where the uncertainty is highest or has the biggest overall schedule impact.

When you have identified the biggest areas of uncertainty, tell your bosses where these high levels of uncertainty lie and why. Show how these uncertainties can impact the schedule. Use this additional information as the basis for problem solving by making it evident to all. Discuss ways to reduce the level of uncertainties (e.g. add a specific person to the project who has dealt with a specific problem area before, or get work started on the uncertain tasks earlier and out of the critical path of the project, or get more key resources applied to critical but uncertain areas of the project, etc.). You may need your boss’ help to get specific people or other resources applied to specific needs of your project. By working with your boss on this, he/she will now better understand the areas of risk and buy into what you’re doing to minimize the risk. Make your boss a part of the solution and not part of the problem (see also eN-030508 – Are You Part of the Solution, or Part of the Problem?).

You also need to exercise your strong spine and be prepared to stand up to extortion and coercion. In the real world, stuff happens, and it can’t always be anticipated. You need to be prepared for the unanticipated to the degree possible (see also eN-041104 – Project Planning: Plan Based On What You Do Know, and On What You Don’t!). When you strip time from a schedule you further increase the risk, and make missing your schedule more likely. Before you “improve” your schedule, push back, but do so with data that shows you know what you’re talking about, or plainly indicates what it is that you don’t know. Showing the error bars of your project can give you the ammunition to stand up to extortion and coercion. Have the courage to speak truth to power, and to the maximum degree possible, refuse to play the schedule estimate extortion game!

[See also eN-021121 – Late Projects Kill Companies!, eN-050303 – Project Management: When Bad Things Happen to Good Projects, eN-060608 – Unrealistic Expectations, and eN-070503 – Sunny Day Scenarios.]

I would like to greatly thank Lee Beaumont for suggesting this topic and for providing much of the information contained here. Lee is a friend and ex-colleague from my days at Bell Labs in Holmdel, NJ. Lee owns and manages a consulting practice called Simply Quality (see www.SimplyQuality.org). I recommend that people interested take a look at his website and the services he offers. Thank you Lee!

[Note –Lee believes a key aspect of the fraudulent nature of this “game” is that the extortion explicitly removes responsibility from the Bosses and lays it on the Project Managers and Engineers. If the Boss were to collaborate, he/she would become complicit and could not as easily escape the blame. Lee addresses the specific issue of blame at www.EmotionalCompetency.com/blame.htm. He discusses this and other Emotional Competency issues at www.EmotionalCompetency.com. Take a look!]