This has been my experience. Especially when doing something new, management is NEVER satisfied with a REALISTIC schedule. That's always too long. Well, one can squish the lines around on a Gantt chart all one wants, force-fitting a project into an arbitrary timespan...but things still take as long as they take. Working 20 hour days is NOT sustainable. Hire more people, accept less features, or spend more money (this sounds like, "Good, cheap, fast - pick two" :-) )
Usually the problem is that when engineering provides the Basis of Estimates (BOE's), the reality of what it takes to successfully complete the jobs clashes with the program management's Price to Win (PTW). Guess which always wins ??? Then of course later, engineering gets a black eye for being behind schedule and over budget. There is so much fodder for Dilbert cartoons we can't even begin to list it.
Making predictions is hard, especially about the future. Such is the problem of planning development (i.e. new designs).
It is much easier to plan how long it will take to do 'the same thing' again.
The hard bit is identifying which parts are 'the same thing' and which parts are 'new and unknown'.
Even then, you still need to know how long it took / what it cost last time, which usually isn't available anyway as such data is fudged, hidden, held by others who aren't telling, etc.
The end result is to make a guess, double it, and then double again, so the programme manager can halve it, which then allows for when your optimism (guess) meets reality!
If you want to survive as a practicing engineer you had best get good at recovering gracefully because there will be first-pass failures, especially if you're the first to try (and where else would you want to be?). Planning-in the most sensible and cost effective mitigations (spares on chip, late-levels reworkability, backup lots and so on for the semiconductor types) will make some managers whine about cost (ditto telling them you need twice as much verification time and the tools to do it) but it's on you, so act accordingly.
"No battle plan survives contact with the enemy"
But you had better learn how to pack.
WKetel, I agree with you. Our focus was strictly success wrt initial project plan (ie. planning/execution) to measure effectiveness of planning approaches. Obviously that's just 1 component of success that should include product quality, etc.
thanks sparky_watt. we contend hardware planning approaches are broken and I think your opinion that very few companies plan supports that idea. planning to fail, failing to plan, they both end up at the same place.
thanks for reading!
One additional fact is that having a really good plan does not by any means assure that the project itself is a one that will succeed. I have seen very good plans that carried out very dumb ideas very well. So even if it is possible to cover all of the individual things that must be done for a project, none of that effort makes the original idea a good idea that will certainly succeed.
This is fundamentally flawed. The flaw is that I have seen very few companies that PLAN a project. They put together "project plans" but they haven't planned the project. They just take a wing at what they think they can do and call that a plan. Often the plan includes make-or-break constraints that are put there by someone that has no clue (we have to have this in six months, or our effort is wasted, failure is not an option). Let's face it. Planning is hard work and largely unproductive. What it really does for us is set expectations and allows us to prepare. And it allows us to choose intelligently. But, it can't be done in a half hour by a group sitting around a table. You need to research the requirements, estimate the needs and the uncertainties. It can then be assembled by that group, but it almost always is unacceptably long and expensive, so it gets arbitrarily cut. Then it isn't a plan anymore, it is a wish.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...