Hanger Queens and Kings and Information Technology

When I worked in productionization, the step in the product development process when you figure out how to build cheap production versions of a costly prototype, we often accumulated a storage area filled with units called “hanger queens”. These hanger queens were prototypes or early product run units that cost a fortune, hence the “queen” title. There were several options for these units once production was in full swing. One option was to decommission them and destroy them, since they were obsolete. Another option was to try to find out why they failed. This consumed engineering time and testing resources that could often be better used to support production. A third choice was to use them as experimental units for repair processes, such as a new way to remove ball grid arrays or patch printed wiring boards. The fourth choice was to let repair technicians use them as practice, with the spare hope that the unit would become usable. In some cases, engineering couldn’t be persuaded to do anything except test, attempt to modify and then test some more.
Decisions on what to do with each unit didn’t resolve the underlying problems that caused a “hanger” or storage area full of “hanger queens”. Why did we end up with so many hanger queens? Why weren’t engineers willing to let them go? And how does these lessons apply to the IT realm?

Problem: Cost to Keep Troubleshooting

Hanger queens consumed engineering time, test labor and time on test sets. Yet there was always someone with a new idea to try to get one working. The objective was to decipher the root cause of a problem. Yet the problem might be unique to that unit and not relevant to the production design. The reason hanger queens continued to hang around was because there was no cut off point in the development process.
There wasn’t a strict cut off that said after a certain degree of testing and troubleshooting, we will stop and support production. There was no cost-benefit analysis as to where engineering and test personnel were better utilized, so the programs often defaulted to the engineers’ wishes.

Solution: Cost-Benefit Analysis

To avoid this problem, know the value of your people and their efforts. Determine when development is over and when you will focus your energies on production to maximize the quality of the final product. Know when to stop the development and focus on bug-fixes and production support. You should also determine what types of problems are not worth solving so that you can focus on those that are.

Problem: When Do You Quit?

There were initially no set criteria for determining when the effort is futile. Testing and troubleshooting continued on units that eventually became scrap, becoming wasted sunk costs.
Solution: Decide When Enough Is Enough

This was curtailed when management said that a unit could pass through the repair shop X number of times. If it didn’t work after X repair and test cycles, it was scrap to be sent for operator training or recycling. This lowered the repair shop’s costs, since they no longer spent operator time and spare parts on units that were later tossed. Know when to give up and walk away so that you focus your efforts on more profitable endeavors.

Problem: Continually Sinking Costs

When expensive prototypes exist, they represent a significant capital cost. Maintaining them becomes less important when production comes online. Yet engineering and IT talent can become consumed in supporting the familiar processes and products over the cheaper, simpler versions. The reason these nearly useless projects exist is simply familiarity and a dollop of pride. Engineers need to avoid emotional investments in projects.

Solution: Know When the Ship Is Sunk.

Adoption of pet projects for enterprise wide implementation or emotional investments by key personnel in a project leads to less than ideal asset and labor allocations. Take the emotion out of the decisions about which projects to pursue and problems to solve. Set a dollar limit on all ongoing projects that will kill it, regardless of whether it is the first attempt to salvage it or the tenth.