#120 from R&D Innovator Volume 3, Number 10          October 1994

Crash Programs:  Managing the Unmanageable
by Harvey Gittler

Mr. Gittler of Oberlin, Ohio, retired a few years ago after 40 years as a manufacturing executive.  He now writes and lectures on management issues.

It happens in manufacturing with frightening regularity, it's a regular feature of design engineering, and it's surprisingly common in R&D work.  Breathes there a manager, engineer, researcher, or production worker who hasn't been involved in a crash program?  Of course not.  Crash programs are a way of life in industry.  And one crash program inevitably begets another, and a third.

What is a crash program?  My abridged dictionary doesn't define it, but it does tell us that, as an adjective, crash means "marked by concerted effort and effected in the shortest possible time." 

Although the definition stresses "in the shortest possible time," it ignores the quality of work that must be produced in that time.  When a new product or project is launched, the managers who run the operations (who know what has to be done and how it will get done), may estimate that they will need 12 months to bring the project from concept to reality (even to virtual reality).

"Totally unacceptable," bellows a voice of authority at headquarters, who doesn't have to do the work and has no idea of what’s needed.  Seldom are the managers or others involved in the project asked if the new schedule can be met.  Why confer with the troops who must take part in the battle? 

So the 12-month calendar shrinks to nine months, and a crash program is born.  To be sure, managers scrupulously avoid talking about "crash programs."  Management simply announces a revised schedule and directs that everything possible be done to meet the new deadline. 

Any objections are quickly quashed, and the wave-makers are accused of being uncooperative, obstructionist, certainly not team players.

Are You on the Team?

Most experienced workers, whether in R&D, engineering, or manufacturing, can smell a crash program from a mile away.  They are told to put other work on hold.  They are told that mistakes cannot be made.  Perhaps they are offered a carrot of a bonus for completing this project on time.

Most employees recall other such programs and regale each other with stories of them.  "Here we go again," they say.  "Can't this company do anything right?"  They will all rise to the challenge, but with little enthusiasm, because they know their efforts will be largely wasted. 

Indeed, management almost guarantees failure from the start with the way it schedules the stages of the project.  Managers receive a specific date for completing each step, from R&D and product design through tooling, the pilot run, the start of production and distribution. 

Usually, problems cause delays almost from the start.  The R&D folks decide to accept the first thing that works--whether or not it's the best design, as long as it works, even if just for the moment, the problem is solved.  If something does go awry, they'll correct it during the next crash program.

By the time it reaches tooling, the project is running weeks or months late--just as everyone expected.  In a reasonable world, this would delay the start of production, but never in a crash program.  Any manufacturing manager will tell you that no matter how much slippage precedes the production date, the calendar remains sacrosanct.  And the easiest way to meet that date is to skip the pilot run, which some people deemed a luxury to begin with.  The result?  As my quality-control friends have quipped for four or five decades, "We never have time to do it right, but we always have time to do it over."

Meanwhile, all the energy going into the crash program diverts attention from day-to-day activities.  No one has time to check out design or production snafus on other products, which inevitably suffer.  "We must never forget our regular daily duties," management intones at least once a week, but experienced employees see these warnings as empty rhetoric.

Crash Programs Should be the Exception

Crash programs are very, very expensive--a fact usually ignored by everyone, particularly since accountants have not yet figured out how to measure their costs.  And their true value, as measured by the most important business yardstick--profits--is questionable.  Yes, sometimes crash programs are necessary, but they should be the exception, not the rule.  And they must be well organized to have any chance of success.

First and most obviously, crash programs must be carefully evaluated by top management in advance.  Executives must understand the burden and risks involved and decide whether the company can afford them.

Some caveats should be heeded.  Don't start one crash program hot on the heels of another.  And above all else, don't promise your staff that there will never be another crash program.  They know better and you can't deliver on that promise anyway.

Once a decision is made to launch a crash program, the various steps should be scheduled into blocks of time--three months for design, say, two months to complete drawings, three months for tooling, and so forth--with enough leeway to allow bottlenecks and mistakes to be corrected, not papered over.  Otherwise, you'll be manufacturing and selling mistakes.

Finally, management must be honest and compassionate when dealing with the people involved in the project.  Employees should be told straight out that this is a crash program, and why it's necessary.  Employees should be made to feel--really feel--that management understands the burden the project will place on them.

Keep these factors in mind, and maybe you can manage the unmanageable.