Of all of the dysfunctional scheduling techniques used in our business, the very worst is that of capricious deadlines imposed by management 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, maybe, believable. No one actually thinks they have any meaning. Note the that 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. 80% 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.
Go to The Show one year. Whatever show your industry primarily patronizes. Watch the demonstrations of those fancy new products. The average demo lasts maybe 10 seconds. 20 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, that get potential customers excited. 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, 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.
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. Contact him at . His website is .
ok… A couple experiences come to mind.
1st. There is the client that says, “Gee, you can work as much as you want on this project, and we will pay for whatever hours you spend on this project…oh by the way, we have a hard, drop dead, dead-line in exactly 3 weeks time”.
So, if you are to calculate this, 3 X 7 X 24 = 504 hours. So, let us say, that instead of 'busy digging your own grave', we allow a down time of 6 hours per 24 hour cycle, (eat, go to bathroom, and sleep), That gives us 18 hour work days, so the actual hours worked is still a whopping 378 hours! This means you have worked on a project that would normally take 6-7 weeks, and compressed it into 2-3 weeks!
The reason my client gave for this was: “We can save a lot of money, and still get the development done in record time!”
Well… I fell for this when I was younger… Also, after this project, I got violently ill, was bedriddent for 2 weeks, and almost went to the emergency room of the hospital. Needless to say, doing this kind of stuff almost cost me my marraige and family!
ok… Another one:
One of my clients gave my team a project that was already 6 weeks behind schedule… And we didn't even start it yet! Sheesh! we were given this, and it was already way behind.
After much work, and some really clever hardware/code design and reuse, and other such stuff, we managed to come out, 4 weeks later 3-weeks ahead of schedule!
Well, guess what happened? When marketing got wind of our progress, they promptly told their customer that they had cut the schedule in half, and will get fully manufacturable units in another two-weeks. Then they came back 'smugly' I may add, and said. Hey! You fellows are now 6 weeks behind schedule! can't you get your act together!?
Needless to say, the division, for this company is now defunct. The director of embedded engineering for this company, 'my client', has quit, and is now working for an entirely different industry altogther!
headline : Shows
– Ken Wada
What really irks me isn't the kind of stuff you and Ken related, but the attitude of the sales pukes that “we must drive the engineers” like we're a bunch of cattle on the chute in the packing plant. I guess that's why I like to drive them back – “you aren't getting any new features (ie, engineering time) until you sell the 'essential' ones we already gave you.”
– Andy Kunz
There is one problem with your strategy, Jack. Often, in order to streamline the development of the few critical features, it is tempting to throw something together that can't be reused. If this happens, you are actually further behind after the Show, with Sales having the perception that a complete product is just around the corner.
The only solution is to design the framework for the system that's complete in itself, so that the final feature set will fit right in. This is the right thing to do, but takes more time, and it is usually the time crunch that led to the insane schedule in the first place!
– Douglas Schmidt