The new board met our expectations, but the customer asked for changes and we accommodated. One day the lead project engineer called to tell me that he needed the current version's TDP for immediate release to configuration management (CM). The current version had errors and changes requiring cut and jump wiring on the PCB, so I argued with him because the next iteration with all the changes incorporated would be available in little more than a week. He refused to wait, demanded a TDP immediately, and promised that the release would never be used for production. I reluctantly provided the ugly TDP and he had it released.
Change requests to permit use of four-line and eight-line LCD displays and a full alphanumeric keyboard soon followed. Consequently, I changed the microprocessor's pin assignments and rotated its package 90 degrees. Over time we incorporated numerous changes, built and demonstrated numerous prototypes, and delivered numerous updated TDPs. Unbeknown to us, however, our firmware was dutifully being released to CM, but not our hardware changes.
The bad news came down fast and hard. The customer reassigned the former lead product engineer and hired a replacement who ordered PCBs from the released hardware TDP for a production contract. Once built and programmed, the boards didn't work. The new lead called and demanded we fix the failed boards. We quickly found that they had built the PCB version I'd been promised would never be used and mated it to the latest firmware release. Economically, there was no way to fix the boards they had built. They had to do another run with the latest PCB layout and firmware code, all of which they had on hand but had not released to CM. The new lead was not pleased with us, spread the word, and our reputation was tarnished.
Lessons, lessons, lessons. There are times when you have to say no to your customer. Knowingly providing your customer defective documentation for release cannot be justified, and the consequences are potentially quite unpleasant. Make sure your vendors can deliver on time and on budget. Development CM needs to be at least as good as production CM, and change synchronization with the customer must be checked.
Jay B. Swindle does hardware and software consulting in the Dallas/Fort Worth area. He is especially interested in integrating hardware and software design, manufacturing, and manufacturing support involving knowledge and configuration management, quality, project planning, and bids and proposal systems. He studied computer science at Baylor University and is a private pilot.
Tell us your experience in solving a knotty engineering problem. Send stories to Lauren Muskett for Sherlock Ohms.