Of all of the dysfunctional scheduling techniques used in our business, the very worst are the capricious deadlines imposed by management in order to be ready for “the show.”
You've heard it before. Maybe it's the primary motivating factor at your company. The boss says something like, “Well, it'll have to be done by January 21 for The Show.” Suddenly a mad rush of engineers fire up the project management software and start diddling with triangles, moving them nervously back and forth, bent on making a schedule that's believable, maybe. No one actually thinks they have any meaning. Note that the last triangle on the chart-the due date-is the first set instead of the last. No one ever diddles with it. The show sets the pace for the entire project.
This is the Show Myth: the hysterical response of the engineering director to marketing's panicked call for a new or upgraded product.
At first blush it's almost a reasonable schedule-driver. The company will, after all, spend astronomical sums on The Show; why shouldn't engineering deliver a new widget to help justify those costs? Why not introduce a new product to make a splash rather than a whimper?
Any capriciously assigned deadline is a joke, an exercise in futility. Eighty percent of embedded systems are delivered late, even in those (rare?) cases where careful estimates override marketing's giddily optimistic promises to customers. When The Show's inflexible date sets the project's completion time, we're creating a recipe for disaster.
Hey, go to The Show one year, whichever show your industry primarily patronizes. Watch the demonstrations of those fancy new products. The average demo lasts maybe 10 seconds. Twenty, tops.
How much needs to work for a successful 10-second demo? Face it-if the red light comes on when the salesman presses the blue button, you don't need an awful lot of working firmware.
If The Show is indeed important for business reasons-as they often are-then maybe we should rethink the schedule. Instead of saying “let's complete this by then,” isn't it more reasonable to implement a subset of features? Just a few things that demo very well, that look cool. Identify features knowing that the goal is passing a 10-second demo, not an in-depth evaluation that could only really take place at a customer's site over the course of weeks.
If you do go to that show, get an exhibitor's badge and visit the day before the event opens. Walk the floor and watch the chaos as vendors scramble to get booths assembled, carpet down, and phone lines installed.
And look very carefully at the sales people pulling the latest new shiny widget from its packing crate. Watch the fear in their eyes, the sweat beading on their brows. They know, with certain clarity, that this is yet another product rushed to The Show with inadequate testing via crazy deadlines. Salespeople have huge egos; bigger even than engineers. All fear the crash when even that 10-second demo fails.
So identify the significant show features, implement those, and only those, very carefully.
And get them right.
What do you think? Is setting deadlines around The Show reasonable? Does your company schedule products that way?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at His website is .
I do agreee that the schedule of the project is mostly decided by the “SHOW DATE”. One should understand the getting the product for demo on the “SHOW DATE” enables the product salebility to wider audience at quicker pace.
But that's the Catch 22 situation , you can't have all the features crammed into the system at short time without proper evaluation. Better Wisdom should be that one should target in the beginning of the project itself what features one should highlight on the “SHOW DATE” so that it can be eventually delivered and builds the Marketing Engineer confidence to demo the produc t better.
Srinivas Rao Kudvelly
Philips Consumer Electronics
Most engineers, I suspect, resigned themselves long ago to the inevitable 'show deadline'. It's so inevitable they just get on with it and hope they can producesomething that kind-of works. MUCH worse than 'the show' is when someone in Sales casually informs you that they've just made a sale on the basis offeature X or widget Y – even though we don't have that feature and never planned to. Oh, and by the way, we need it by next month…
Many Engineers are detatched from the financials of a company. They often underestimate the value of a “Good show”, especially if that show is only once ortwice a year. Often buyers will hold off purchases until a show and decide afterwards. If you have the oportunity to show new features that present acompeditive advantage, it can be worth much to the company. Consider that you present smoke and mirrors at a show, but forge ahead and plan around areliable release date. Do not sacrifice the ultimate quality of the product or the release date for the show and make it CRYSTAL clear to the marketingdepartment. STAND BY your dates and tell them they affect your quality. A couple bad quality product releases will remind them of how they should respectyour dates!
Someone has to speak up for Marketing!
Project scheduling, in any form, can be done well or done poorly. I think it's unfair to label “show-scheduling” as bad. In the article, and in the previousresponses, examples of bad implementation are used to support the contention that show-scheduling is bad. At Green Hills, we've used show-scheduling forselected projects, targeting a 30-minute live-audience demo at the show (not a “5 second” demo), and a deliverable, supportable product within 30 days of thedemo. This proves to work, driving developers to meet a “fixed” schedule, and resulting in company revenue within 30 days after the show.
It's not uncommon to see developers cringe at the thought of a schedule that won't slip. It's amazing to see what they can achieve, though, when they realize theyhave a real deadline.
Green Hills Software, Inc.
You have obviously been there. So have I. Most schedules have a capriciously chosen end date which never slips. Start dates slip, commitments to providesupport slip, but if end dates change, the new date is earlier, not later. Why can management not see that unrealistic schedules do more harm than good?
DIVA Automation, Inc.
There are two extremes on this scale: a show box, on which there is a button that activates a light, and a real scalable and robust system. None of these is desirable, since we may have to deliver the next day after the show. So, often times we end up building a system that has all parameters hard-coded and a throughput of only 5% what a usable system requires. On the other hand, doesn't the subsequent clean up provide extra job security?
David J. Liu
As a further comment on what Harry Jones said about sales from a show – it's even worse when they come back WITh substantial sales – committing your company to deliver unverified and untested systems. And then wondering why the engineering department is so upset – after all it worked for the show!
Global Payment Tech, Inc.
Hey, are we twin sons of different mothers? It's frightening how often my viewpoints & opinions completely agree with yours! The “Show Myth” has always been one of my pet peeves. Talk about an artificial & capricious deadline! I have always felt that taking an unstable & untested product to a show was almost suicidal, & seldom results in any appreciable sales.
You mean there are other ways of developing a schedule besides delivering a 100% working unit to THE SHOW!
I told a friend recently that I thought the reason Brooks' seminal book The Mythical Man-Month, published in 1975 was so timeless was that management is so clueless. On a proposed project I pointed out to management that their required schedule was impossible. I suggested your approach, tell me what features had to be implemented, and I would start from there. He replied without a second's hesitation, “All of them”.
I don't know what they teach them in business school, but “Project Scheduling in the Real World” still isn't a required course.
Only a disciplined approach to scheduling, such as the Capability Maturity Model, with the full and strong support of upper management will change how projects are scheduled. Any company that does not have the above is doomed to the cruelty of Show scheduling.