"You Bent the Leads!"

The Project Objectives Statement: It's important to state ALL the requirements before you start.

by Dann Gustavson

One of the directors I worked for years ago called them “fresh-outs” — recent graduate engineers, newly hired into their jobs.

There are these three fresh-outs (yes, one of them was me) in their first week working for the largest, most prestigious employer in the city. All of the fresh-outs (several dozen of us) work in a bull-pen of cubicles called the Tank, while waiting for someone to give us our assignments.

Monday and Tuesday are new employee orientation, and finding the cafeteria and the building exits. Wednesday we mostly walk around the enormous plant to see what is where, and browse trade journals to learn important things we didn’t learn in school.

Three fresh-outs with no written objectives statement.

Thursday, the nominal boss of the fresh-outs (he calls himself “the Tank Commander, heh-heh;” just like that) comes over to us and says, “Do you folks know how to get to the Lincoln Avenue plant?” We do, so he tells us to drive over there and meet with Jerry Something in the lab because he has a job for us to do. He will explain when we get there.

Finally, some real work!

Right after lunch we drive the 6 miles to the Lincoln Avenue plant and check in with Jerry. He’s been with the company for 3 years so he knows the ropes. He takes us to the lab and shows us around and explains what he needs us to do.

Jerry’s department is called Parts Reliability. Their mission is to write the specs for the military grade parts we need for the project, and to qualify the suppliers and parts. Jerry explains that he has bought 150 Zener diodes which were built to a lower spec than our product required, because he couldn’t get what he needed quickly enough, and he wanted us to screen them by a process called “burn-in.” He wants us to power them and run them for 168 hours (i.e., a week) at elevated temperature. The diodes that meet their specs after that are usable; the rest will be kept in the lab for breadboard use. He shows us the parts, the power supply to use, the resistors to put in series with each diode, and the temperature chamber that he laughingly refers to as the Pizza Oven. (Someone used it to heat up a pizza 5 years ago, now part of the Parts Reliability department “lore.”)

“Any questions?” he asks. The fresh-outs didn’t have any. Sounds simple enough.
(Thought balloon: We should get an ‘A’ for this assignment when we finish next week.)

It took us the rest of the afternoon and part of the following morning to get all of the Zener diodes and resistors hooked up to a bank of terminals that we could insert into the pizza oven. By lunchtime Friday we turned on the pizza oven, set it for 50°C, connected the power supply, set it for 4 volts DC, and flipped the switch. Nothing blew up – success so far! Let’s go to lunch. We found Jerry, told him our status, and headed back to the home plant to wait for the diodes to finish baking.

My new lab partners and I went to the Lincoln Avenue lab every afternoon to make sure the oven was still working, and found no problems. Friday morning, we waited until the 168th hour timed out, then turned off the oven to let it cool down. At 2:30 we opened it up and took out the rack of parts to inspect them and start the electrical test to see which ones displayed the specified diode curve on the scope.

While we were doing this, Jerry stopped in. Before we could proudly inform him that we were almost finished testing, he took one look at the diodes on our test bench and gasped!

Jerry exclaims:  “Oh crap!! – you bent the leads!”

Fresh-outs think:  “There goes our ‘A’…”

Jerry had neglected to mention that in order to be able to use the Zener diodes for assembling production units, we were supposed to keep the axial leads of the parts straight – no bending, no wrapping around a terminal, just attach them using clips that leave little or no mark on the leads. Seemed to him like too trivial a requirement to have to state – along the lines of “inhale, then exhale, then repeat.”

OK, Dann – What’s My Take-away?

Even on a low-complexity project, take some time at the outset to ensure that every requirement is stated, and fully understood by your project team. Major projects surely have comprehensive objectives statements, and small projects should follow the same practice, scaled to the complexity of the effort.

The problem that arose here could have been avoided with a simple change in communication at the outset. For example, Jerry (as project manager for the burn-in project) could have shown the fresh-out engineers how to do the first one or two parts, instead of just telling us and assuming we understood all the nuances. Or, we could have set up the first two parts and then asked Jerry to check our work, before proceeding to the entire 150-piece test sample, thereby sharing ownership of the outcome.

In retrospect, my fresh-out colleagues and I were fortunate to have learned the objectives statement lesson two weeks into our careers, at a very small cost to the company and no cost to us except having to do it again when another 150 parts arrived. Communicating the requirements, preferably in a written objectives statement, including any known restrictions or conditions that have to be avoided, should be a routine practice at the time of a project kickoff.

Usually, advanced technology appears to pose the highest risk in a development project, and though advanced tech certainly isn’t easy, it gets so much attention that it usually ends up working out. It’s frequently the little things that can inadvertently trip up projects, things we assume without stating, that will cost money, time, and lost opportunity.

Paying attention to the little things is part of Next Level Leadership!

Dann Gustavson, PMP®, Lean Six-Sigma Black Belt, helps Program Managers and their teams achieve superior results through high-impact program execution. Prepare, structure, and run successful programs in product engineering, manufacturing operations (including outsourcing), and cross-functional change initiatives.

Contact Dann@Lean6SigmaPM.com.