Make this or make it do this?

Sometimes looking at the legalities side of your business is just a matter of figuring out all the various things that can go wrong. But anyone in the automation or control business who decides to spend an afternoon actually making a list of potential meltdowns usually ends up calling us lawyers—say, by about three o’clock. Alternatively, they go straight to happy hour.

Of course, that’s true in any business. But the automation business has a particularly scary situation that many others don’t. It has to do with the difference between "make this" and "make it do this."

Imagine, if you will, a project with problems. The end-user is unhappy. The widgets that were supposed to be happily finding their way into commerce are being thrown out as unacceptable. The project’s SCADA and manufacturing execution systems are not on the same page. Worst of all, the lawyers have begun to show their ugly faces. (At this point you are, of course, looking at the picture accompanying this article. You’re not allowed to say anything.)

So how bad is it?

For the companies involved in this mess, how bad can it be? Well, it depends on whom you ask. There is a rather major fork in the road between those fighting over what lawyers call a "design spec" vs. what is called a "performance spec."

A simplified design spec might say: "Best Integration Solutions Inc. will integrate the widget production lines with the warehouse automation system in accordance with the detailed design of Premier Consulting Services." Translation: "Make this."

A simplified performance spec might say: "Best Integration Solutions Inc. will integrate the widget production lines with the warehouse automation system such that the combined system will operate at a rate of 100 widgets per hour." Translation: "Make it do this."

For integrators, the problem with performance specs ("make it do this") is that they put integrators on the hook for meeting the owners’ exact output needs. If anything causes the widgets to move slower or less efficiently than desired, the integrator faces a boatload of potential liability. For this reason, integrators would be well advised to avoid performance specs. End-users, on the other hand, would be well advised to embrace them.

Design specs ("make this") reverse the situation. The integrator is following the plan or design of a consultant. As long as the integrator installs the exact system that was specified, whether it works or does not work is someone else’s problem. For obvious reasons, therefore, integrators would be well advised to embrace design specs, while end-users would be well advised to avoid them.

In-between

Is there a middle ground? One way is to pair a performance spec with a hard limit on liability for the integrator. Another approach is to pair a design spec with a set of production-based compensation incentives.

Now, what happens when, as is often the case, there is no detailed contract on these points, but instead an exchange of a one-page proposal and a one-page purchase order, without a clear spec at all?

Hate to say this, but it depends. Depends on what was said and what was done. It could also depend on industry custom and the law of the place where the project is being done. In some circumstances, the law could "imply" something called a "warranty of fitness for a particular purpose." What’s that? Think of it as an implied "make it do this" spec: Bad for integrators. Good for end-users.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.