This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Drastic Stretch Goals Can Do More Harm Than Good

Ogg, the Cro-Magnon ax designer at the Bison Valley Ax Works, developed a schedule for the Mammoth Whacker III (MWIII). He carefully examined his timesheets for previous ax design projects to estimate how long each subtask should take. He adjusted certain subtasks upward due to the unique challenges of the MWIII. Others were moved downward due to planned improvements in work methods.

He estimated that he could spend 75% of his time working directly on the project. This was because his records showed that 25% was typically used to provide engineering support for existing designs. Finally, he submitted his six-month schedule to Mr. Big, his general manager.

Mr. Big looked at it and said, "I'll give you three months to complete the design." Ogg looked puzzled and asked, "What do you know that I don't know?" Mr. Big puffed out his chest and said, "Too much to explain right now, but I can tell you one thing: engineers need stretch goals. They always pad their schedules. I've learned to cut their estimates in half."

Six months later, the MWIII was completed late and over budget. For his next project, Ogg submitted a preliminary estimate of 12 months, which Mr. Big reduced to six.

Like juggling chainsaws, this approach to cutting cycle time is effortless and occasionally painless, but more often it's rather messy. Since it has recently resurfaced in management literature in Eli Goldratt's fictional (is this a clue?) book The Critical Chain, I think it may be useful to shed some light on this matter.

First, cutting cycles in half is not illogical. Such reductions, however, usually come from architecting schedules with more overlap, improving work methods, reducing work queues, and resourcing teams properly. They do not come from arbitrarily cutting careful estimates in half.

Second, ridiculous goals don't motivate engineers. Instead, they cause them to disengage from the project. Remember, most engineers support multiple assignments. When they're assigned to one project with a realistic goal and another with an unrealistic one, what will they do? Spend more time on the doomed project? Of course not. If they did, both projects would go awry and they'd be blamed as the common factor in the failures. Therefore, they concentrate on the project with the realistic goal and ensure it succeeds. Then, when the unrealistic task fails, people will conclude the project was the problem, not the engineer.

Third, when people take care to generate a careful schedule, only to have it arbitrarily changed, they'll tend to treat planning as a joke.

Fourth, even if it were possible to get people to work 100-hour weeks in an effort to meet the unreasonable schedule, this could cause a burnout spiral. As more people leave, the workload on the remaining team members increases, exhausting them even faster.

Finally, how many nanoseconds would it take engineers to figure out that they can regain realistic time budgets by multiplying their original estimates by two before management divides them in half?

In practice, engineers respond well to stretch goals of 10% to 20% if they perceive them as realistic and important, and they participate in setting them. As a general rule, randomly cutting their calculations in half does more harm than good.