Legalities in automation: Know your project delivery method
It is important to fit the upcoming project into the right legal category. In automation terms, think of the project delivery method as the operating system, with the contracts or purchase orders being executable software. Each of these "operating systems" carries with it advantages and disadvantages, and for the automation project in particular, a unique set of risks. There are at least four reasons this is important.
If you were circulating at a social gathering and—forgive me for this—find yourself cornered by someone else connected to the automation industry (I know, it sounds like a rather bleak party), how would you casually describe the project you were about to embark upon?
You might say (using the shorthand of fellow automation people): "We're migrating from an X to a Y platform."
Or you might say: "We are replacing legacy infrastructure with fieldbus technology."
Each of these is an attempt to begin defining the playing field—yet in the world of legal risk does not say very much. That is because these descriptions are entirely technology-based; the important legal relationships that, knowingly or unknowingly, are being carved out, are left unstated.
Now, if one is interested in giving attention to that topic (and one of course should be interested if controlling legal risk is anywhere on the radar screen), it is important to fit the upcoming project into the right legal category. The million-dollar, front-end question is literally this: What is the project delivery method?
Although the term "project delivery method" can mean a number of things, a useful definition for our purposes is to think of it as a decision to allocate legal responsibility in a particular way among a given set of project participants. In automation terms, think of the project delivery method as the operating system, with the contracts or purchase orders being executable software. Each of these "operating systems" carries with it advantages and disadvantages, and for the automation project in particular, a unique set of risks.
Design-build. Many, perhaps most, automation projects are design-build. At its core, this method simply means that the same outfit that is designing the automation system is also installing it. (You may know this project delivery method by at least two other names: turn-key or EPC, engineer-procure-construct—although the meanings are not exactly the same). For the system provider, identifying the project as design-build means realizing that your company has effectively bitten off two very large mouthfuls of risk: the design risk ("Was this thing designed correctly?" "Is the HMI user-friendly?" "Did we adequately assess the end user's performance needs?) and construction risk ("Did we do a professional job? "Did we follow the manufacturer's recommendations?" "Did we install this right?").
For the purchaser of automation services, the "turn-key" label is perhaps the most descriptive term because it reflects the essential advantage of the design-build method. What the end user theoretically has purchased is the ability to "turn the key" and the system will work. Or, to use a consumer term, it is "one-stop shopping." When there are problems (and, again, this is only in theory), there can be no finger-pointing because both design and construction are delivered by the same player.
Design-bid-build. Add an outside designer to the mix and you have what lawyers refer to as "design-bid-build." Here, the design is decided upon first between owner and engineer, then the "builder" (in our world, the automation service provider) bids on that job. Although this is the most prevalent system in the realm of sticks and bricks construction, it is less used on technology projects—for the simple reason that system design and execution can be difficult to separate. The indispensable (and frequent) exception to this is what I would refer to as the uber-designer/sub-designer split in larger projects, in which the layout and conceptual engineering for an entire range of systems is worked out in advance—with the automation service provider for a particular application constrained to fit its own solution into the pre-determined framework (often with particular platforms and devices already specified).
Although these are the "big two" project delivery methods applicable to automation projects, there are others:
Construction management. Similar to the use of an "uber-designer" in the design-bid-bid project delivery method, this adds an "uber-contractor" to coordinate installation, particularly in projects where there is competition for access and numerous dependencies between deliverables.
Design-build-operate-maintain. This is the ultimate in "turn-key" arrangements. Not only does the automation provider agree to design and install a system that will do what the owner requires, it agrees to remain on site beyond commissioning—and (for an additional fee of course) run and maintain the system for an extended period of time (typically training the owner's forces in the process).
Integrated project delivery. This project delivery method has received a lot of attention recently because it proceeds from a radical model. Take a large project with multiple key designers and contractors, then put them in the same room at the possible earliest stage to collectively design, manage and construct a set of systems—even going to the extent of signing a single contract. Sounds great, doesn't it? Well, before you begin singing "Kumbaya," try to wrap your mind around how exactly that would be set up. If you are having difficulty doing that, you are recognizing the essential weakness of integrated project delivery—which is that the devil can be in the details (I know—I am working on such a project now). But the idea is certainly intriguing, and the gains (on paper at least) potentially enormous.
Why go through the exercise of identifying what "project delivery method" your project fits into? There are at least four reasons:
First, matching the appropriate project delivery method to the end user's goals is vital. It literally can mean the difference between the success or failure of a project.
Second, it forces reflection on important risk fundamentals that either are or should be in the contracts. Are we asking this provider to design anything? Is design split between two entities? Who is coordinating installation? Do the warranties match the contractual obligations?
Third, it impacts insurance. For instance, from the end user's perspective: add one part important design deliverable and one part smaller engineering firm and it should be quickly concluded that professional liability insurance covering the engineer is essential.
Four, before you can cut down a tree, you need to find the forest. It’s that simple.
- Mark Voigtmann is a lawyer with Baker & Daniels llp (Indianapolis, Chicago, Washington, DC, and China). His group assists the automation and process industry in structuring projects and resolving disputes. (Mark.Voigtmann@bakerd.com or 317-237-1265). www.bakerd.com.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.