Missing Requirements

Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong.  To that end I am going to regale you with a tale of requirements gone astray.

Wearing Many Hats

I worked at a small company a long time ago. I am glad I did, as I wore many hats and learned something new every day while having this job at this small company.  This particular instance, we were to design and build an embedded control system for a large manufacturer, and the requirements were listed on a short sheet of paper as a bulleted list of the objective the constraints, and the general performance expected.

Product Development Input

The primary source of contact and the requirement was the head of marketing. This company generally had short communication and hierarchy chains.  However, the marketing person was essentially a customer advocate and not really an engineer.  In this instance, there will be some depending implications due to this limitation.

Objectives

We had the objective of designing and delivering an industrial application that would meet the requirements, which consisted of a number of pieces of hardware that performed discrete measurements and as long as the variation on that sample were within a certain tolerance, the system would operate accordingly.  However, when that variation went beyond the allowable in any one of the sampling components (more than 100) the system would send a control signal that would stop the machine and flag the operator that an error had occurred as well as direct them to the specific failure point.

Oops, Something is Missing

We proceeded to develop the system performing incremental tests at various stage. This included testing the system on a small-scale equipment believed to be identical to that of the customer.  The trials were very successful, and the final delivery date is established and our manufacturing line at the begins work on producing the system.  The first prototype system is packed up and put on the loading dock for shipping.  In a casual conversation with the marketing manager, the manager mentions the actual type of system the prototype system will be installed upon is not what it was designed and tested.  I scratch my head by this revelation that the system is significantly different from what we designed the product, and the testing was not on that type of system as well.  I inform the marketing manager that the product will not work on the system she disclosed, that the variation in speed is too significant and will likely cause errant false failures.  However, knowing that humans are fallible I go to the other engineer that was also working on the system for his perspective, and he agree.  The system will not work.

Clean Up and Conclusion

What happens next is just cleaning up of the mess created by missing requirements. The system is shipped.  The two engineers visit the customer’s facility for a week and takes along portable soldering irons and a variety of equipment and components to see how the system works and tailor fit the product performance to meet the system to which it is installed.  This consumed many hours and a small measure of dissatisfaction from the customer.

So what is the lesson?  Well, in this case, to design the product to meet quickly meet this need would have been quite easy. The original requirements, had these mentioned the machine type, would have gone a long way to understanding the actual application, perhaps additional questions or perhaps discussions with the proposed client.