May 21, 1998

Troubleshooting where you work

Ron Mancini

A highly paid consultant commands management’s attention, but you’re just another
engineer subject to management’s whims.

Troubleshooting at your plant should be easier for you than for a consultant, but it just isn’t so. A highly paid consultant commands management’s attention, but you’re just another engineer subject to management’s whims.
  Because my company couldn’t ship equipment with failing power supplies, it was stacking the equipment instead. Management wasted six weeks studying the problem, then pulled me in from design and told me to immediately (if not sooner) fix the problem. I generated a three-section action plan covering the power supply, input voltage source, and load (Reference 1).

Four uninvited vice presidents attended the troubleshooting team’s kickoff meeting; I knew their appearance was bad news. I started presenting my action plan, but the vice president of manufacturing interrupted, stating that I needn’t fool with anything but the power transistor that failed most often. He and the vice president of engineering got into an argument concerning power-supply failure modes, and they settled their argument by deciding that I had license to investigate the complete power supply.

The vice president of quality discoursed on problems associated with mounting power transistors. After graphically describing failures resulting from poor mounting, he insisted that the team begin immediately to verify transistor mounting. What had he been doing for six weeks? The vice president of reliability quarreled with the vice president of quality, dismissing transistor-mounting problems because the reliability department had approved the mounting during design verification. The vice president of reliability admitted that, of course, if manufacturing did not follow the approved procedures, transistor mounting could be the problem.

The meeting droned on with the vice presidents arguing back and forth. At first, the team members contributed, but management shouted them down, and the team lost interest.

Management’s arguing and infighting convinced me that the program would be a boondoggle. After the vice presidents and their flunkies wound down, my boss summarized the meeting and asked me for a new plan.

I said, “I can find another job easier than I can deal with these people. I’m going back to my engineering project.” The arguments started again, with references to arrogant, young engineers. (Yes, I too was once young.) I held my ground, and we agreed that I would run the program per my action plan as long as it showed progress.

I gathered the troubleshooting team in a private meeting, and we took the following steps:

1. We revised my action plan until all team members signed up. They didn’t all get their way, but they all agreed that, given the circumstances, it was the best plan.
2. I assigned actions to all team members, and team members were to complete actions in parallel when possible.
3. We agreed upon completion dates for the actions.
4. We worked on the problem and met daily to interchange information and revise the action plan.

My team found the problem in four days. A defective connector in the load assembly shorted out the power supply, causing the power transistor to blow. We tested all configurations, thereby convincing ourselves that the connector was the only problem. We ordered replacement connectors, wrote an engineering-change notice, and replaced the connectors.

I never received a hero’s badge; rather, upper management considered me to be an uppity, arrogant, if competent, engineer who needed watching.

Continuing on my troubleshooting path, I will use my next column to discuss how to troubleshoot hardware at the component level.

Reference

1. Mancini, Ron, “Troubleshooting the consultant’s way,” EDN, March 13, 1998, pg 22.

| EDN Access | Feedback | Table of Contents |