In my personal experience, this situation has actually improved a lot over the years. Yes, marketing still dictates a market window that must be hit, and the scheduling works backwards from there -- from end of qual, to system validation, to first prototypes, fab cycle time, tapeout, verification time, design time, and to product definition and spec writing before design even gets started.
When that back-to-front scheduling process reveals that design has a negative or unrealistically small positive number of weeks or months to do their job, then the number of choices are very few. If a re-evaluation of the lifetime revenue based on a later market entry still makes business sense, proceed with a new schedule that has the later date. If the resourcing was intentionally lean, add headcount to appropriately resource the project and/or re-define the feature set & scope if a lesser product can still satisfy a segment of the market by meeting the market window.
If none of those business tests pass, then the right answer is to kill the project and put your engineering resources on a different project where you have better odds of making money. Sales will complain that "we're going to lose that socket," but the reality is that you have already lost that socket before you even started the project...because you waited too long to start.
No doubt that customers frequently request/demand an accelerated schedule, which is natural -- they're reacting to the changing competitive forces they themselves are facing. Such requests/demands trigger a chain reaction within the chip supplier's organization -- marketing, engineering, program mgmt., senior mgmt., etc. must respond -- and the common response is naturally "yes, we can do it." That's not surprising either. Everybody wants/needs to please their customers. However, what often happens is that difficult decisions are avoided. Instead, the organization pretends that somehow ten pounds will fit into a five-pound bag. RC
I remember an argument with my manager:
- We need to tapeout in 1 week
- Sorry, with the machine power and license number we have, I need 2 weeks for running all the backannotation simulation
- Can't do it in 1 week?
- Then only run part of the sim!
Sim results? There was one pattern with a glitch. Of course in respect this Muphry's law the glitch was on a pattern I ran after tapeout.
Marketing: "Company X is making a fortune with this. We gotta have something similar in six months or we will miss the Market Window."
Engineering response: "Company X has had a whole year to develop this. We need the same. Why the heck didn't you guys ask for this six months ago?"
That's basically it. Schedules are generally DICTATED, not requested. A true schedule would be an exercise in impartial forecasting, guessing when some other design team of which you have no stake - will finish. but for many reasons, most of which have already been mentioned, scheduling a project that you have a personal stake in is inherently problematic. If you really want to know how long a project will take, ask the other department, or start a betting pool then watch what the odds tell you. I guarantee it will be dead on every time!
My favorite excuse for the unrealistic schedule is from the Sales or Marketing person who says, "if we don't deliver it by this date we will lose the socket and be out of the product's lifecycle!" My response, "let the race to failure begin!"
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.