Planning to fail is planning to fail

2/1/2013 7:09 PM EST

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.

2/2/2013 10:33 PM EST

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.

2/4/2013 1:14 PM EST

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.

2/4/2013 4:59 PM EST

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!

2/7/2013 2:40 PM EST

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.