Manage expectations for a project scope
When a client and system integrator share goals, the potential for success is maximized for a scope project if the expectations are managed and the project has a clear vision.
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 may 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 system integrators and clients. The best automation projects are those in which all expectations are clearly spelled out upfront in the contract. This increases the chances of the client getting the improvements it hoped for at the expected price, and the integrator completing the project using expected resources and making a reasonable profit.
Such is not always the case. Given the number and variety of projects Maverick has delivered, the company has formulated some guidelines to maximize satisfaction while minimizing risk for both sides in any kind of project. Let’s consider what might be considered a medium-sized project—bigger than replacing a single 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 all three. Let’s consider the steps necessary to stay in the successful category on all three points.
Start with a clear scope
A project with any degree of complexity needs to have the scope defined up front, but it is surprising how often this doesn’t happen. Why? Because, for the plant owner, writing a complete scope can be hard work. It’s easier to jot down something vague, hoping the integrator can fill in the gaps. If the integrator 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 also will be disappointing.
Writing a scope is difficult because it requires critical self-examination: the more complex the project, the more extensive the analysis. A plant must figure out what are 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 may have gone years without being updated. Individuals tasked with doing the digging may be sent outside their area of specialization. A process engineer might need to evaluate 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 integrator 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 with respect to what it should accomplish
- How and when the project should happen
- What resources the client can provide
- What is expected from the integrator.
The integrator’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 integrator should identify the omission and suggest something to fill the gap. It may raise the price, but it is better to deal with issues now rather than later.
The goal of a project may be 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 integrator. 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 integrator with a thorough understanding of the plant should be able to 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 need to be included in the scope alongside the other considerations.
Creating an automation vision
One of the best things a company can do to ensure effective projects and achieve better operation is to create an automation vision. This describes where the plant wants to be in the future—maybe 10 years or more. While this may sound 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 should assess the present operation, determine where the problems and opportunities are, and lay out a plan for improving 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 should include a variety of items, building on each other in a rational sequence.
Any new project should be part of the vision, and an integrator bidding should tell the client when something doesn’t align with the goals, or if a different approach would be better.
Avoiding the "black box"
When working on the project implementation, a good integrator will work with the client to ensure everyone knows how things work. The integrator should not use complex programming methods with the intent that it remains the only one able to modify the system. This kind of "black box" approach can create major expenses for the client over time, while fomenting trust issues between the integrator and client.
There are exceptions, such as sophisticated advanced control algorithms where proprietary capabilities using intellectual property from the integrator or automation system OEM call for a locked system. These exceptions should be clearly understood and explained at the outset. There must also be provision for gaining access in the event of the original provider ceasing support.
If the client is to sustain the improvements, the people working with the new equipment and automation system must understand it. The integrator’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 client with no recourse other than returning to the OEM or integrator 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 client may need to accept a legitimate change order and its resulting cost.
Similarly, the integrator 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 client and integrator 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 provide definition of 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 blue print operations on machines; 1-02, 1-14 and 1-10.
- Develop SCADA tags and screens (maximum of 6 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 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 blue print 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.
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.
Offsite 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.
Tim Gellner is a senior consultant for Maverick Technologies.
Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.