There’s an old saying in the legal profession: the best contracts are written between parties who don’t trust each other. People who are friends can leave things vague because they assume they share mutual understandings. Those with less trust are more specific, and thus avoid potential problems down the road.
The same concepts apply to relationships between automation solutions providers and customers. The best automation projects are those in which all expectations are clearly spelled out upfront in the contract. This increases the chances of the customer getting the improvements that it hoped for at the expected price, and the provider completing the project using expected resources and making a reasonable profit.
Such is not always the case. Here are some guidelines to maximize satisfaction while minimizing risk for any kind of project. Let’s consider what might be a medium-sized project – bigger than replacing a PLC, but smaller than a DCS migration.
Projects are evaluated based on three main points:
- Cost: Did the project stay on budget?
- Capabilities: Did the project deliver the promised functionality?
- Schedule: Did the project finish on time?
A good project delivers on all three. Less successful projects might miss on one, two or three. Here are some steps necessary to stay in the successful category on these three points.
Start with a clear scope
A project with any degree of complexity must have the scope defined up front, but it is surprising how often this process doesn’t happen. Why? Because writing a complete scope can be hard work for the plant owner. It’s easier to jot down something vague, hoping the provider can fill in the gaps. If the provider is working in the plant all the time, this approach may work.
A vague project scope creates the opportunity for change orders and the total cost could be far higher than originally budgeted. The results will also be disappointing.
Writing a scope is difficult because it requires critical self-examination: the more complex the project, the more extensive the analysis. Plant personnel must figure out the real condition of the affected areas. This kind of analysis requires facing the workarounds created to avoid having to deal with larger problems, opening the cabinets nobody wants to open, and digging out drawings and documentation that have gone years without being updated. Individuals that must do the digging tend to be sent outside their area of specialization. A process engineer might have to evaluate the instrumentation condition, or a lead control room operator might be asked to sift through piles of drawings. Even facilities with effective maintenance and good change management find writing a scope a daunting undertaking, but it must be done.
One way to make sure the scope is done right is to make it a project of its own. This is where the provider can help from the start. The objective viewpoint of an experienced outsider can make a huge difference, and a scoping project should not add much to the overall cost of the main project. If this scope is created in the context of the specific larger project, the resulting work and cost will be far more accurate than anything done without the necessary homework, regardless of who does the actual project work.
What a scope should cover
The scope for a project should list in detail:
- The goals of the project regarding what it can accomplish
- How and when the project should happen
- What resources the customer can provide
- What is expected from the provider
The provider’s quote should respond to all those points, and a well-thought-out quote from an experienced company will take issue if the scope is missing things or glossing over potentially difficult areas. For example, if it doesn’t include time for operator training, the project may be headed for trouble. The provider should identify the omission and suggest something to fill the gap. It may raise the price, but it is better to deal with issues up front rather than later.
Say that a project goal is to raise output for a given process unit by 10%. Someone must determine what’s required to achieve the goal: the company’s process engineers, or maybe a consultant or the provider. In most cases, it is a group effort.
Usually the price of a project is the most important element, but scheduling is close behind. An experienced provider with a thorough understanding of the plant can stick to a reasonable schedule along with the quoted price. Again, knowledge of the operation makes a critical difference.
The performance aspect of a project has not been addressed yet because it is often harder to define. Dollar figures and dates on the calendar are easy to pin down, but functional success can be fuzzier. Nonetheless, performance metrics must be included in the scope alongside the other considerations.
Creating an automation vision
One of the best things a company can do to achieve effective projects and better operation is to create an automation vision. This vision describes where the plant will be in the future—maybe 10 years or more. While this process sounds ambitious, it provides focus and direction for every project and is thus well worth the effort.
An automation vision can address a given plant or maybe just a single process unit. It can assess the present operation, determine where the problems and opportunities are, and lay out a plan for improving the operation. Some elements may be comprehensive, such as migrating to a new DCS, while others more modest, such as improving the flow instrumentation on a reactor. It can include various items, building on each other in a rational sequence.
Any new project can be part of the vision, and a provider bidding should tell the customer when something doesn’t align with the goals, or if another approach would be better.
Avoiding the “black box”
When working on the project implementation, a good provider will work with the customer to make sure everyone knows how things work. The provider should not use complex programming methods with the intent that they are the only one able to modify the system. This kind of “black box” approach can create major expenses for the customer over time, while fomenting trust issues between the provider and customer.
There are exceptions, such as sophisticated advanced control algorithms where proprietary capabilities using intellectual property from the provider or automation system OEM call for a locked system. These exceptions must be clearly understood and explained at the outset. There must also be provision for gaining access if the original provider ceases support.
If the customer is to sustain the improvements, the people working with the new equipment and automation system must understand it. The provider’s technicians should work closely with the plant’s people through the whole implementation process, so they understand how it all goes together. Less positive situations leave the customer with no recourse other than returning to the OEM or provider whenever there is a question or problem, which turns out to be counterproductive for all parties concerned.
When things go wrong
Problems can develop on any project, and they may come from either side. However, with thorough preparation and a good working relationship, they will be fewer and smaller. When they emerge, it is important to keep them from escalating. Either side can be responsible for a problem, so the customer may need to accept a legitimate change order and its resulting cost.
Similarly, the provider may find itself having to perform an additional service at its own expense. Where both sides share blame, costs should be shared.
The best projects result when a customer and provider trust each other as partners, but still hold each other at arm’s length when it comes to defining projects and making agreements. Keeping understandings clear in all phases makes the difference.
A sample of a project scope document
Here’s an example of a simplified project scope document, which lays out the parameters of an integration project.
1. Scope of Work
XYZ Company manufactures compressors for the HVACR industry. XYZ currently manufactures two models of compressors and is now seeking to integrate a third model into the existing supervisory control and data acquisition (SCADA) system.
1.1. Definition
This scope of work will define the project objectives and requirements. XYZ will provide a formal functional description of the coordinated operation of the production machines, which will include the sequence of operation for the new compressor model with data descriptions data types, addresses, and expected data state/value exchange descriptions for the process controllers interface to the SCADA system. The functional description and sequence of operation will be the controlling documents for the development, integration and testing of the functions to support the new compressor model in the SCADA system.
1.2. Development
The SCADA programming will encompass the following items:
- Modify the existing SCADA HMI application to perform the blueprint operations on machines; 1-02, 1-14 and 1-10.
- Develop SCADA tags and screens (maximum of six including pop-ups) for the new model.
- Develop the required SCADA scripts to automate the steps in the process.
- Integrate communication between the process controllers and the SCADA system to comply with the functional description, sequence of operations and data definitions as described.
- Integrate linear gage communication for the new model.
- Integrate Serial Numbering logic for the new model.
- Develop MS SQL Server tables in the existing database for storage of the new model’s blueprint dimensions and process tool requirements.
- Configure the SCADA application to push the data to the MS SQL Server database.
- Update the Assembly Line Architecture Document to include the new model.
It is imperative that the associated tag lists, flow diagrams, references to P&IDs, architecture diagrams, functional descriptions, as is screen shots, and to be screen wireframes (or mark ups) are included at a minimum.
1.3. Documented testing and training
Verification of proper functionality will be coordinated with XYZ, with the functional description and sequence of operation providing the testing and acceptance criteria.
Off-site preliminary testing will include remotely loading the updated software and will require XYZ personnel to provide support during the remote testing. Remote access to the XYZ system will be via a secure VPN connection to the XYZ network. XYZ must host the VPN connection.
ABOUT THE AUTHOR
R. Tim Gellner (tim.gellner@rockwellautomation.com) is a Systems Integration Consultant in Rockwell Automation’s Global Professional Services group with more than 25 years of experience in discrete and continuous manufacturing processes, systems integration, manufacturing execution systems, and process improvement.
