Specifying the task

In my experience the probability of project success is directly proportional to the time invested in defining what success will look like. In other words, take the time to document exactly what you are trying to achieve. Don’t just say, “inspect peanuts,” instead say, “identify and separate peanuts that fall outside size and color parameters as defined in QS N003.” (Always assuming your quality standards actually define and quantify what is and is not acceptable.)

However, and this is a matter of personal style, I prefer not to tell prospective vendors how to do the job, I just try to describe what I want achieved. That way I leave myself open to clever ideas from people who know more than I do.

That said, I do believe it is important to tell your vendors how you will measure the performance of the system. This means defining a set of acceptance tests which spell out what they will have to do. But don’t ask for the impossible. For example, it’s virtually impossible to achieve zero false accepts and zero false rejects, so be sensible and figure on rejecting a small percentage of marginally good parts.