Wait Until The Last Possible Moment

Here is some good system level advice as it pertains to electronic engineering. I think it is true of other branches of engineering as well.

System-level design is all about thinking early and implementing later. So why not apply what we already know? We even have statistics. Fifteen years ago, I was part of projects where we measured how effective methods like manual code inspection were in preventing bugs from propagating into the next project phase.

Everybody seems to know and agree that it becomes more difficult to find and fix defects the further a project has progressed. More recently, studies sponsored by NASA show that an embedded software bug introduced in the requirements phase is 130 times more expensive to fix during integration and 368 times more expensive after rollout of the embedded device.

So what do you do? Prototypes for one. And not just hardware. Software too. Sometimes it is only in the process of implementing a solution that you come up with a better idea. How do you make sure that idea does not wind up on the drafting room floor? Delay the decision to commit big resources to the last possible moment. Which means a manager must not only be a master of technology. The manager must also be a master of logistics and the PERT Chart.

You also have to recognize the pressures to decide quickly: top management asks, "what is your plan?" and you have to say "I don't have one yet, I'm looking at the options." It requires a lot of trust. And a lot of program time discipline when it comes to execution because you will be using a lot of your project time margin to make sure you get it right the first time.

Engineering Plan

I was having a discussion with a correspondent about how to organize a Polywell Fusion engineering program. I though I had discussed that here but it turns out that I made my remarks at NASA Spaceflight. So I would like to revise and extend those remarks.

==

Since I'm thinking along Manhattan Project lines I think we need a name for our little venture. I propose the "Rock River Engineering District". I don't know, it just came to me. So how should the Rock River Engineering District be organized?

We start with a project management (PM) team with representatives from each of the labs and the main functional groups. Project management is above all responsible for results. Budgets and schedules too. The job of PM is to make sure all the horses are pulling in the same direction.

Now what about project teams? Start with a power reactor group. A thermal group. An electrical group (power and control). A test reactor group. And a support group consisting of mathematicians, metallurgists, electronic design, etc. and administrative support - purchasing, contracts, etc.

The reactor group alone is going to have to have subgroups: electron guns, fuel injection, vacuum group, magnetics group, collection grid group, plasma physics. Possibly others - all working with the thermal group. Plus you want to have some mathematicians on staff for helping the engineers with the hard stuff. Reduce the engineering to algebra/trig or computer programs with graphical and table outputs.

Then you have to have some one who can ride heard on this collection of prima donnas. If they aren't prima donnas I don't want them on the program. Think Manhattan Project. Or Rickover re: nuke subs. We want very smart experienced people with an excess of confidence. With a pessimist riding herd.

I think it took the Naval reactor group from 1948 to 1953 to get delivery of the sub reactor prototype. With 6 years prior experience in low power and low power density reactors.