select an integrator guide

7/27/2019 Select an Integrator Guide

http://slidepdf.com/reader/full/select-an-integrator-guide 1/43

Guide for Selecting & Working with aControl Systems Integrator

Volume 2



Copyright 2000 Control System Integrators Association

First published in 2000 by:

CSIA640 Rice Boulevard

Exton, Pennsylvania 19341

All rights reserved worldwide. No part of this publication may be reproduced or transmitted in any form, or by any means, electronic or mechanical, including

photocopying, recording, or by any information storage and retrieval system, without the prior written permission of Control System Integrators Association.



CSIA Guide to Selecting & Working with a Rev. (00)Control Systems Integrator - Volume 2 October 9, 2000

VOLUME 2INTRODUCTION

The objective of the CSIA Guide for Selecting & Working with a Control Systems

Integrator has three major purposes:

Volume 1 -To provide the client with a method of identifying criteria to evaluateand select a Control Systems Integrator.

Volume 2 -To provide the client requiring a control system with an effectivemethod and guideline for development of a Request for Proposal and theevaluation of the proposals.

Volume 2 -To provide a suggested method to more effectively manage projectimplementation.

Industry professionals from various companies, product manufacturers andControl System Integrators have participated in the development of theRegistration Program & Criteria and the Guide to Selecting and Working witha Control Systems Integrator. The Registration Program & Criteria, and theGuide are referred to collectively as the "Documents". The Documentsreflect our view of industry requirements of the various companies involvedwith the implementation of controls systems.

These Documents are provided as a tool for selecting a Control Systems

Integrator, developing a Request for Proposal and managing projectimplementation. The Documents are NOT ALL ENCOMPASSING and cannotbe reasonably or solely relied upon to take into account every uniquerequirement of a project or company.

THE USERS OF THE DOCUMENTS ARE SOLELY RESPONSIBLE FORTHEIR OWN CRITERIA FOR THE EVALUATION, SELECTION,DEVELOPMENT AND DRAFTING OF THE REQUEST FOR PROPOSAL,PROCUREMENT OF CONTROL SYSTEMS INTEGRATOR SERVICES,MANAGEMENT AND IMPLEMENTATION OF PROJECTS. THE CSIAAND ITS PARTICIPANTS DO NOT MAKE OR OFFER

REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, OF

ANY

guide_spec_vol2 i




Table of Contents

Page

1. Preparing Request for Proposal ............................................................................ 1 1.1 Project Overview 1 1.2 Scope of Work 1

1.2.1 CSI Supply 2 1.2.2 Client Supply 2 1.2.3 Performance Criteria 3 1.2.4 Environment 4 1.2.5 Standards, Policies and Practices 4 1.2.6 Equipment Requirements 5 1.2.7 Hardware Requirements 5 1.2.8

Software and Configuration Requirements 6

1.2.9 Documentation 6

1.3 Commercial 7 2. Proposal Review...................................................................................................... 9

2.1 Proposal Review Criteria 9 2.2 Selection Process 12 2.3 Analysis Tool 12 2.4 Selection Criteria Structure Steps 13 2.5 Performance Scoring of Criteria 14 2.6 Decision 15

3. Award of Contract ................................................................................................. 16 3.1 Purchase Order/Contract Requirements 16 3.2 Terms & Conditions 16

4. Project Management ............................................................................................. 17 4.1 Introduction to Project Planning 17 4.2 Detailed Review of Estimate Vs. Scope 17 4.3 Identify Project Management Team 18 4.4 CSI Project Plan 18 4.5 Create Project Schedule 18 4.6 Identify Required Resources 19 4.7 Detailed Work Breakdown Structure 19 4.8 CSI’s Internal Meetings 20 4.9 Client Meetings 20 4.10 Submittals to Client for Approval 21 4.11 Client Responsibilities 22

5. Testing ................................................................................................................... 23 5.1 Test Documentation Requirements/Test Plan 23 5.2 Factory Acceptance Test (FAT) 23 5.3 Site Acceptance Test (SAT) 24

6. Site Installation...................................................................................................... 26 6.1 Responsibility of CSI 26 6.2 Responsibilities of Client 26

guide_spec_vol2 ii




6.2.1 Responsibilities of Client Subcontractors 27 7. Site Startup ............................................................................................................ 28

7.1 Responsibilities of the CSI 28 7.1.1 Develop Start Up Plan 28 7.1.2 Perform the Start Up 28 7.1.3 Generate “As Recorded” Documents 28

7.2 Responsibilities of Client 28 7.2.1 Plan the Start Up 28 7.2.2 Manage the Start Up 29

8. Acceptance/Sign Off ............................................................................................. 30 8.1 Testing 30

8.1.1 Acceptable Test 30 8.1.2 Failed Test 30 8.1.3 Good Test, But Modifications Needed 30

8.2 Acceptance/Sign Off 31 9. Training .................................................................................................................. 32 9.1 Operators 32

9.2 Maintenance 32 10. Warranty/On-Going Support................................................................................. 33

10.1 Warranty 33 10.1.1 Hardware, Equipment and Third Party Software Warranty 33 10.1.2 CSI Workmanship Warranty 33

10.2 Support 34

guide_spec_vol2 iii




<00> CSIA BELIEFS

The end customer must be the focus and ultimate beneficiary of our efforts.

Dedication to continuous improvement is a prerequisite to ongoingsuccess in the marketplace.

A quality management system that is broad based and effective willgenerate economic and competitive benefits for the CSI and thecustomer.

Quality efforts are more productive when directed toward preventionrather than correction.

A good reputation in the industry and in the community is essential toattracting the customers and the employees necessary for a healthybusiness.

Compliance with all local, state, and federal regulations is essential for being a respected and valued business partner and will preclude thepotential for service interruption due to non-compliant operations.

Our greatest resources are the knowledge, skill, creativity, andproductivity of our people.

Operations and execution to sound policies, practices, and standardsprovides a superior product and a reduced cost.

All employees have the right to a safe working environment. Allaccidents are preventable.

The use of benchmarks will raise the standard of excellence of our industry and the market we serve.

guide_spec_vol2 iv




guide_spec_vol2 v

CSIA Best Practices & Benchmark

Mission:

Provide Control SystemIntegrators a Means to Both

Evaluate and Continuously

Improve Their Practices by

Providing Sound CSI Industry

“Benchmarks”, to Be Used in a

Self-Deterministic Fashion for

the Markets They Serve.




CSIA Best Practices & Benchmarks

Objectives:

1) Establish CSI Industry Benchmarks

2) Develop Procedure for Self

Evaluation

3) Develop “Mechanism” To Facilitate

Outside Assistance

4) Establish “Mechanism” for CSIA toQuantify Progress / Results

5) Obtain Endorsement From Industry

Associations

guide_spec_vol2 vi




<00> CSIA PRACTICES AND BENCHMARKS: ACKNOWLEDGMENTS

Special thanks to:

Best Practices and Benchmarks Committee

Bob Zeigenfuse (Advanced Automation Associates, Inc.) Bob Sokoll (Advanced Automation Associates, Inc.) Duane Corcoran (Applied Control Technology) Denny Mosher (Bay-Tec Engineering, Inc.) Don Roberts (Exotek LLC) Bob Lowe (Loman Control Systems, Inc.) Tim Stout (Matrix Technologies, Inc.)

Contributions also made by:

Tom Albright (AI Controls) George Bowman (GE Industrial Systems)

Practices and Benchmarks Review Committee

Clients: DuPont Clorox Products Manufacturing Co. ConAgra, Inc. GRACO Children's Products, Inc.

Control Manufacturers: General Electric Automation Services Siemens Moore Process Automation, Inc. Eaton Corp./Cutler-Hammer National Instruments Corporation

Plus a number of other user clients from major industries.

guide_spec_vol2 vii




guide_spec_vol2 1

1. Preparing Request for Proposal

This section describes a suggested content for a Request For Proposal (RFP). Project overview, scope of work and commercial issues areaddressed.

At this point, qualified candidates should have been selected asoutlined in Volume 1.

<00>

1.1 Project Overview

The preparation of the Project Overview section of a request for proposal is critical to the success of the project. This should provide

the overall intent of the project. It consists of a brief descriptioncovering items such as:

• Overall Project Objectives/Goals

• Operational Overview

• Project Schedule Milestones

• System Performance Requirements

<00>1.2 Scope of Work

The Scope of Work section covers the details of the work required andassumes that the necessary preliminary budgetary work and fieldresearch has already taken place. Time spent in the thoroughpreparation of this requirement will improve the quality of theresponses, reduce later client/CSI misunderstanding, change ordersand renegotiations.

The scope must be fully documented. The materials or productsmanufactured or handled by the system must be fully defined. Allexisting documentations are of utmost importance in defining projectscope. They typically include, but are not limited to:

Plant Layout Drawings Hazardous Area Classification Plans Equipment List P&ID’s (PFD’s) One-Line Diagrams Motor List Device/Instrument List Input/Output List Interfaces to External Systems




Impacts to existing plant equipment must be clearly defined. Suchitems typically include, but are not limited to the following:

Power, Steam and Water Capacity Instrument/Plant Air Capacity Network Capacity Available Rack or Cabinet Space UPS Capacity

Changes and clarifications made to the scope as a result of candidates’ questions should be documented. All questions andanswers during the bid process should be copied to all candidates.

All candidates should be required to attend an organized pre-bid

meeting. This is a structured walk-through to formally present the

<00> 1.2.1 CSI Supply

The hardware, third-party software and services to be provided by theCSI must be fully and clearly defined in the request for proposal. Thiswill assure the client that all candidates are meeting the intendedrequirements of the RFP.

The CSI supplied services will typically include one of more of thefollowing:

Consulting Project Management Specifications Design/Documentation Software Development/Documentation Software Testing Procurement Panel Fabrication Construction/Installation Commissioning

Training On-Going Support

<00> 1.2.2 Client Supply

guide_spec_vol2 2

Most projects require interfacing to existing equipment or to newequipment provided by other suppliers through the client. Thisequipment must be fully defined in the request for proposal.Modifications required to existing equipment must be detailed includingdefining who is responsible for completion of modifications. The




availability for access to existing equipment for modifications shouldclearly be defined. Shutdown schedules should be identified as muchas practical.

New equipment should be defined by description, manufacturer,model, drawings, etc.

Define temporary utilities including electrical power, water, sewer, air and communications. Define available office and staging space thatmay be utilized by the candidates.

Define all materials and/or components that will be provided for testing.

Labor to be provided by the client for installation, start up assistanceetc. should be defined. Define project team resources assigned to the

project.

Project Manager Purchasing/Contract representative Process department representative Operator/User representative IT representative Maintenance representative Safety representative (where applicable) Environmental representative (where applicable) Human Resources representative (where applicable)

NOTE: A single point of contact for all communication should be

clearly defined. This is typically the client’s Project Manager.

<00> 1.2.3 Performance Criteria

Performance criteria represent the technical success or failure of aproject. Criteria must be fully defined and realistically stated. Over specifying will result in added project expenses.

Production rate criteria should be defined in parts/second, tons/hour,

gallons/minute, etc.

Consistence and tolerance criteria should be defined in plus/minusdimensions, temperatures, pressures, PH, etc.

Reliability criteria should be defined in terms of up-time, time betweenfailures, etc.

Requirements should be stated precisely enough so as to allowverification during acceptance testing (factory and site).

guide_spec_vol2 3




Define the acceptance testing method that is required.

Software simulation

Hardwired simulation Actual Process

Define the method of establishing substantial completion or clientacceptance.

<00> 1.2.4 Environment

The environmental conditions under which the components of thesystem will operate must be clearly defined to assure maximumreliability. The client’s past knowledge of what works and doesn’t workshould be included,

Temperature and humidity requirements should be defined for bothindoor and outdoor locations. Hazardous classification should beclearly defined where applicable. A hazardous classification area planshould be provided to determine battery limits to each classified area.

Dust, chemicals, or other substances affecting the system should bestated.

Seismic considerations should be reviewed and defined.

The site geography, including altitude, should be stated.

<00> 1.2.5 Standards, Policies and Practices

All applicable standards affecting the system should be stated.

Client design standards related to the hardware, software or commercial portions of the system should be provided.

Client policies such as safety, work conditions, refuse disposal, cGMP,labor relations, etc. should be provided. Any special training

requirements should be clearly defined.

Any special equipment to be supplied or used by the candidate shouldbe clearly defined (i.e., Nomex suits, respirators, gas sensingmonitors).

Client policies concerning confidentiality and exclusivity should beprovided.

guide_spec_vol2 4




Industrial standards such as ANSI, NFPA, UL, IEEE, ASME, etc.relevant to the system should be referenced including specific standardnumbers.

Local, State, and Federal standards such as OSHA, DER, FDA,USDA, relevant to the project should be referenced.

<00> 1.2.6 Equipment Requirements

Most clients specifying projects have established standards for equipment to which candidates must comply. In cases where thecandidate has latitude in determining the equipment, the client shouldindicate that an “or equal” will be considered.

Connectivity requirements for equipment should be specified.

<00> 1.2.7 Hardware Requirements

Most clients specifying projects have established standards for hardware and software manufacturers to which candidates mustcomply. In cases where the candidate has latitude in determining themanufacturer, the client should indicate that an “or equal” will beconsidered.

The client should specify specific manufacturers complete with type or model as applicable for all hardware that must comply with client

standards.

Specify level of redundancy required. Specify spare capacity (i.e., rackspace).

Connectivity requirements for hardware should be specified if the clienthas standards established or if the system must interface with existingnetworks. Firmware and software revisions must be specified to insurecompatibility to existing equipment.

Certification and labeling requirements of hardware such as UL, FM,

CSA, CE, etc. should be stated as applicable.

Spare part requirements for hardware should be stated if applicable.

The RFP should specify who provides development hardware andsoftware. It should also specify availability to client’s existingdevelopment stations for modifications to existing control systems.

guide_spec_vol2 5




<00> 1.2.8 Software and Configuration Requirements

Most clients specifying projects have established standards for software packages and development systems with which candidates

must comply. In cases where the candidate has latitude in determiningthese items, the client should indicate that an “or equal” will beconsidered.

Standards such as IEEE, FM, NFPA, or BLRBAC which are to becomplied with during software development and testing should bestated.

Development packages to be utilized in the development of applicationcode should be specified including version numbers. It should beclearly stated if the development package is to be included as part of

the contract.

The client should require the candidate to state the number and size of runtime software packages included in the proposal.

The client should address transfer of third-party software license.

The client should request a non-transferable, non-exclusive right andlicense to use and modify the CSI-developed application software.

<00> 1.2.9 DocumentationSystem documentation is critical to the implementation and on-goingsupport of a system. It is important that the client specifies andreceives adequate documentation. If there are any specialdocumentation requirements, such as PSM or FDA validation, theyshould be clearly defined.

Drawing requirements should be specified by the client including CADpackage or drawing format to be utilized, title block requirements,symbol library requirements, numbering sequences, layering, etc.Final documentation format, hardcopy and/or disk should be specified.

Calculations required to be performed and submitted as part of theproject should be specified by the client.

Software documentation requirements should be stated. These shouldaddress code annotation and commenting, source code vs. compiledruntime code, etc.

guide_spec_vol2 6




The client should specify requirements for operator and maintenancemanuals. The specifications should state the number of copiesrequired, word processor format, and content.

The client should state training requirements for operating,maintenance and technical staff. The requirements should include thenumber of staff involved, media utilized, etc. Multiple sessions may berequired to accommodate shift personnel. This should be definedclearly.

NOTE: Supplying a sample documentation package helps

provide clarification of client expectations.

<00> 1.3 Commercial

The preparation of the commercial section of a Request For Proposalis important to the success of the project. The commercial sectionprotects both the client and CSI against misunderstandings regardingpayment, deliverables, and intangibles. Time spent in the thoroughpreparation of this requirement will reduce potential client/CSImisunderstandings and negotiations.

There are several types of contracts that may be utilized for a project.Some examples are:

Firm Price Contract Pros: • Fixed cost

• Reduced financial risk

Cons: • Change order intensive

• Scope must be exact

Time and Material Pros: • Minimal definition of scope required

• Easy to administer

• Allows fast track

Cons: • Greater financial risk

Fee Based Contract Pros: • Shared risk

• Scope can be adjusted

Cons: • No ceiling to cost

guide_spec_vol2 7




The client should specify the desired pricing categories for the project if a pricing breakdown is required in lieu of a single total sum. The client

should request fee structures and applicable rates.

Systems of significant size will require progressive payments. Theclient should be prepared to suggest a payment schedule or acceptsuggested schedules from the candidates.

Client corporate buying agreements that may affect cost to candidatesshould be defined in RFP documents. Additional terms coveringfreight, FOB, escalation, penalties, etc. should be included in the RFP.

The delivery for the system should be detailed in the RFP. Delivery

should include project milestones for approvals, delivery of hardware,factory acceptance testing, shipping, installation, etc.

Define methods for contract change resolution. Define methods for contract conflict resolution.

Client to state priority of controlling documentation in the event thatclient-supplied documents conflict. An example conflict would bedrawings vs. specifications.

Guarantees for project performance and warranties for hardware,

software and services should be stated in the RFP.

Define warranty requirements. For larger and longer term projectsdefine the starting date of the warranty.

The client should specify any insurance coverage required by thecandidate. The client should require proof of insurance. It is beneficialfor client to be named as additional insured during project.

Include a sample contract in RFP documents to define terms andconditions to contractual agreement.

Confidentiality agreements, if required, should be included in therequest for proposal.

guide_spec_vol2 8




2. Proposal Review

This section provides information on a suggested decision process for choosing a CSI for a specific project. Both the proposal review criteria

and the selection process are addressed. It is assumed that the CSI has been qualified as a candidate.

2.1 Proposal Review Criteria<00>

• The criteria are the actual items that must be considered in makinga decision. Depending on the system requirements, some of thelisted criteria will not apply and/or other criteria may be added to the

list.• The following criteria can be applied to the Selection Process

defined in Section 2.2. These criteria are stated in alphabeticalorder and not by degree of importance.

Criteria Description

Basis of Proposal Has the CSI clearly stated the conditions on whichthe proposal was based?

Commercial Are any special terms clearly defined? They couldinclude:

• Time for which the proposal is valid

• Delivery conditions

• Terms of Payment

• Bonding

• Insurance

CompanyCapabilities

Does the CSI have the resources with theappropriate training and experience for the project?

Deliverables Has a list of all tangible deliverables been provided?

Delivery Has a project schedule been submitted? Is itacceptable?

Documentation Has a list of the documentation to be supplied beenprovided? Number of copies? Format?

guide_spec_vol2 9





EquipmentSupply

Does the proposed equipment list match therequirements of the RFP? Are manufacturersspecified where required?

Exceptions Are exceptions to the RFP clearly stated?

Hardware Supply Does the proposed hardware list match therequirements of the RFP? Are manufacturers andspare capacity specified where required? Examplesare:

• PLC/DCS

• Computer

•HMI

• Network (at all applicable levels)

• Motion Control

• Enclosures, including environmentalconsiderations

• MCC

• Motor controls

• AC and DC Motor Drives

• Power Conditioning, UPS

• Machine Vision

• Instruments

Location Is location an issue? If yes, what is the maximumacceptable distance to the CSI for this project?

Options Are options clearly described and priced?

Personnel Has the CSI project team been identified?

Rates or Cost Are the cost categories clearly stated? Are they inagreement with the RFP?

Are rates and fee structures clearly defined?

Have applicable taxes and freight been identified?

guide_spec_vol2 10





Services Do the proposed services match the requirements of the RFP and are they clearly stated? Examples are:

• Machine or process study (primarily applies toretrofits)

• Functional Specification

• Control System Design

• Computer System Design, including networking

• Drawings

• Interfaces to other equipment

• Selection of hardware and/or commercialsoftware

• PLC/DCS, Computer, Motion, Network

Software development (must be specific)• Human Machine Interface (HMI) development

• Control panel assembly

• Certification Requirement (UL, CE, CSA,NFPA)

• Simulation

• Installation planning

• Installation or On-site Installation Supervision

• On-site startup and test (must be specific)

• Factory Acceptance Test (FAT)

•Site Acceptance Test (SAT)

• Customer training

• Warranty, On-Going Support

Software Supply Is there a description of the Software to be provided,including application and third-party? Examples are:

• PLC/DCS

• SCADA/HMI

• MES/IT

• Database

• Software Drivers

• Communication/Network• Development Software

Spare PartsSupply

Are spare parts clearly listed?

Terms andConditions

Have they been provided? Are they acceptable?

guide_spec_vol2 11





Warranty Is the warranty explained in the proposal or in aseparate document?

<00> 2.2 Selection Process

• This section is not intended to provide a precise method of decision making in regard to selecting a CSI for a project. Manypeople and companies already have a method or process for making vendor selection decisions. This section will providesome thoughts on the topic that may be a foundation for thosewho don’t have a process. It may serve as a supplement for those who do.

• A process is a necessary sequence of steps by whichinformation and judgments are organized to reach a conclusion.

<00> 2.3 Analysis Tool

The objective of using a decision analysis tool is to plainly state thecriteria on which a decision will be based. These are:

• To assign a relative weight (i.e., classify) as to how important each

criterion is to the decision maker(s).

• To provide a structure to logically go through an evaluation andselection process.

• To provide a consistent scoring method to reach a conclusion..

Section 4.7 provides an easy-to-use table to organize

evaluation and scoring.

The CSIA Registration Program provides the customer with aneffective method for immediate evaluation of a CSI by determining if a

CSI meets the minimum criteria established by the CSIA BestPractices & Benchmarks. The Registration Criteria was jointlydeveloped by CSIs, customers and manufacturers to ensure that thecriteria is complete and reflects the requirements of the partiesinvolved with the implementation of control systems. The suggesteddecision analysis tool outlined in this section is based on Kepner

Tregoe's (KT) decision analysis methodology.

guide_spec_vol2 12




<00> 2.4 Selection Criteria Structure Steps

1) State the Decision:

Write a short statement describing the intended result of a decision.

Example: Select a CSI to implement your system.

2) Develop Criteria:

Identify criteria that will influence the choice.

Example Criteria:

• Services

• Exceptions

• Options

3) Classify criteria into "musts" (M) and "wants":

Determine the role criteria will play in the decision

Example Criteria:

• Services

• Exceptions M

• Options

4) Weigh the "wants" (1-10):

Assign relative values to "want" criteria.

Example Criteria:

• Services 9

• Exceptions M

• Options 6

5) Screen CSI through the "musts":

Determine if CSI meets the "musts".

Example: CSI A Acceptable Exceptions Go

CSI B Acceptable Exceptions Go

CSI CUnacceptable Exceptions No Go

(CSI C is no longer considered.)

guide_spec_vol2 13




6) Evaluate and score CSI against the "wants":

Evaluate relative performance of CSI (0-5).

Example: CSI Performance ScoreCSI A(9) Service (4) 9x4 = 36(6) Options (3) 6x3 = 18

TOTAL SCORE = 54CSI B(9) Service (3) 9x3 = 27(6) Options (4) 6x4 = 24

TOTAL SCORE = 51

7) Assess risks for the client to manage:

Every project involves risk to the client that the client must manage.Identify risks that need to be managed and evaluate your ability tomanage them.

Hint: Low performance score could indicate risk.

Example: CSI’sCSI A

• Evaluate value of options.CSI B

• Manage missing service component.

8) Make decision:

Select a CSI that has the best balance in meeting criteria (TOTALSCORE) with acceptable and manageable risks.

<00> 2.5 Performance Scoring of Criteria

The user may define a scoring system that will help the decision-

makers evaluate and score the CSIs in a fair and consistent manner.

Since the range of criteria is so broad, any one scoring system willhave its moments of questionable applicability to the criteria inquestion. The decision-maker(s) should use their best judgment andmove on.

guide_spec_vol2 14

To be consistent with the scoring system used in selecting thecandidates, it is suggested to use 0-5 with 5 being the most favorablerating.




2.6 Decision<00>

Sample Analysis Chart:

Criteria List Weight CSI 1 CSI 2 CSI 3

MUSTS

1. Exceptions2.3.4.5.

GO or NO GO

GO GO NO GO

WANTS

1. Service2. Options3.4.5.6.7.

1-10

9 (45)6 (30)

4 (36)3 (18)

3 (27)4 (24)

----

TOTAL (75) (54) (51) --

Percentage 100% 72% 68% --

guide_spec_vol2 15




3. Award of Contract

This section provides information on the steps taken after a CSI hasbeen selected.

<00> 3.1 Purchase Order/Contract Requirements

The purchase order issued to the CSI must include key information.Pertinent items include, but are not limited to, the following:

• Purchase Order or Contract Number

• Project Title or Specification Number

• Reference the accepted version of the CSI proposal

• Price

• Applicable taxes

• Required Delivery

• “Bill to” Address

• “Ship to” Address

• Authorized Commercial and Technical Contact Names and PhoneNumbers

<00> 3.2 Terms & Conditions

Differences or discrepancies may exist between the Terms andConditions of the CSI and the Terms and Conditions of the client.Differences must be discussed and an agreement on the differencesreached. The agreement must be expressed in writing and signed byauthorized personnel from both parties.

guide_spec_vol2 16




4. Project Management

This section covers the suggested project management methodology to be implemented by the CSI.

Every project is unique and must be planned and implemented with fullconsideration of its specific elements and constraints. Therefore, theProject Manager (PM) should develop his/her action plan by tailoringthe procedures contained herein to meet the needs of the project,without compromising the objectives of maintaining strict projectcontrols and organization.

Every project has a natural flow of work. Project constraints dictate thatcertain activities be completed before others. Of course, not all

activities apply to every project, and sometimes competing projectdemands will require deviation from this normal flow. This guideline isto be used as an overview of proven principles, as well as a means toassure that critical steps do not get overlooked.

<00> 4.1 Introduction to Project Planning

The PM is the key to completing a successful project. The PM isresponsible for managing a project to deliver to the client all purchaseddeliverables, meeting a defined schedule and budget. The PM isresponsible for establishing the project plan, detailing communication,

execution plan, work breakdown, schedule and budgets. The PM isalso responsible for communicating with the client, making sure bothparties are aware of any details that could affect the other. One of themost significant jobs of any PM is constant vigilance to the definedproject plan to ensure the success of the project.

<00> 4.2 Detailed Review of Estimate Vs. Scope

Many projects change from the time of bid to the time of purchase. Theclient and the PM for the CSI should review the client’s purchase order to determine that the client purchased what was proposed and what, if

anything, has changed. Any changes should be documented andclarified between the client and the CSI at the beginning of the project.

guide_spec_vol2 17




<00> 4.3 Identify Project Management Team

<00> 4.4 CSI Project Plan

A successful project will have a well-documented plan for how the workwill be accomplished. The project plan should be developed jointlywith the PM and the CSI technical project lead. The plan should detail:

Project Overview

Project Schedule CSI Project Team Identification CSI Project Team Training Client Project Team Identification Communication and information dissemination requirements

Project implementation Required resources Testing Installation Start up

Make efforts to cover all topics in as much detail as needed todocument the plan. This effort assures that the plan can becommunicated to all team members and used as a tool for thesuccessful completion of the project.

The project plan is a living document. Very few projects are completedwithout some change along the implementation path. Because of thesechanges, the project plan needs to be reviewed, revised and reissuedto the project team whenever appropriate.

<00> 4.5 Create Project Schedule

The project schedule is a key measurement tool for the PM to gaugethe progress of the team towards a defined end date. The schedulealso serves as a communication tool with a client to show CSI’s

progress on a project. The use of a commercial scheduling tool suchas MS Project is preferred.

The following are the suggested major milestones and responsibleparty in a project:

• Award (Client)

• Kickoff (CSI/Client)

• Functional Specification (CSI)

guide_spec_vol2 18




• FS Approval (Client)

• Detailed Design (CSI)

• Fabrication Submittal (CSI)

• Fabrication Approval (Client)

• Purchase of Panels and Equipment (CSI)

• Detailed Programming (CSI)

• Unit Testing (CSI)

• Integrated Testing (CSI)

• Factory Acceptance Testing (Client/CSI)

• FAT Approval (Client)

• Equipment Shipment (CSI)• Installation (Client)

• Checkout (CSI/Client)

• Start Up (CSI/Client)

<00> 4.6 Identify Required Resources

The client and the CSI need to work together early on in a project todetermine the resources required to complete the project. A tightschedule by the client might require more staff on a project by the CSI.If the client is supplying hardware, the CSI might not be able to startinto software development or testing until the hardware arrives.

As the project enters the installation phase and the CSI is on site,additional resources might be required to be supplied by the client.These include access to telephones and fax machines, modem lines,safety training, office space, copy machines, and most importantly, akey contact while on site.

<00>4.7 Detailed Work Breakdown Structure

This Work Breakdown Structure (WBS) takes the work assignments tothe detailed Activity Level. The Activity Level details the actualactivities or tasks to be performed in the project’s implementation. Thislevel will break the project down into measurable, manageable bits of work that can be defined by an action verb.

The WBS is typically defined by the Lead Technical resource on theproject. For example, activities may be as follows:

guide_spec_vol2 19




• Review Sequence of Operations

• Create I/O Database

• Setup/Load PLC Equipment

• Software

• Configure I/O

• Program PLC

• Make Post-Staging Program

• Corrections

Note that these activities are definable in the sense that a specificresource may be assigned to perform a budgeted task. This level of detail is imperative, as it will determine the scheduling, tracking,reporting and communications efforts throughout the project.

It is advisable to use critical path management techniques to determinepossible scheduling constraints.

<00> 4.8 CSI’s Internal Meetings

The CSI will typically have internal project meetings that include aninitial project kick-off meeting and periodic design review meetings.These meetings provide an opportunity for the CSI to discuss internaldesign issues, schedule and resources and are a normal part of asuccessful project. The CSI will notify the client of any issues thatrequire the client’s attention, such as design information needs or submittals that are a result of the internal meetings.

<00> 4.9 Client Meetings

The typical project will begin with a kick-off meeting and periodicreview meetings held between the CSI and the client. The CSI’s PMshould prepare and distribute minutes of all meetings detailinginformation presented in the meeting, assignments made, agreementsmade, and details affecting commercial issues.

• Kick-Off Meeting: The PM should prepare an agenda for the kick-off client meeting, detailing issues to be addressed. All matters of concern to the client or PM should be cleared up at this meeting.The meeting should ensure all parties understand what needs to beaccomplished. The PM and additional team members, as deemednecessary, should attend the meeting with the client’srepresentative to review:

guide_spec_vol2 20




Project team and roles Communication and reporting structure Scope of work Review risks

Billing/Payment Scheduling Change orders

• Design Review Meetings: Client design review meetings areessential throughout the project. Formal review meetings are ameans to help ensure communication is ongoing within andbetween the CSI and the Client. Items for discussion at designreview meetings can be any of following:

Project Status

Schedule review and percent complete Constraints holding up progress of specific task Any design detail requiring technical input or verification from

the client or from one of the client’s other contractors Scope Changes

<00> 4.10 Submittals to Client for Approval

Several forms of submittals are typically required on an integrationproject. They are a form of “official” communication between the CSI

and the client and many times are a commercial requirement. Thetypes of submittals are usually detailed in the proposal and thencarried out as part of the project implementation. The PM is in chargeof issuing and receiving approvals for any submittal. The scheduleimpact of missed submittal dates should be clearly defined andunderstood by all parties.

The typical submittals on a CSI project include:

Drawing packages Fabrication packages

Equipment Specifications Functional Specifications Test or Validation Plans Acceptance Documents Contract Completion or Release Documents

The schedule should detail the submittals, review periods andapprovals.

guide_spec_vol2 21




NOTE: In many cases, the review and approval of thesubmittal by the Client is required before the CSI can

continue work on a specific phase or task of a project.

<00> 4.11 Client Responsibilities

Both the client and the CSI have responsibilities and obligations inorder for a project to be successful. While each project is unique,some of the following items are more common requirements for aproject responsibility of the client:

• Timely response on commercial issues

• Resolution of all scope changes prior to implementation

• Review and agreement or disagreement of all project

documentation such as meeting minutes and telephone records• Timely notification of schedule changes

• Support of CSI while in the field

• Project review at the completion of the project

guide_spec_vol2 22




5. Testing

This section covers the testing and test documentation required todemonstrate to the client that the CSI’s system operates per the

project design documents.

<00> 5.1 Test Documentation Requirements/Test Plan

The Factory Acceptance Test consists of the Protocol or Test PlanSection and the Testing Sections.

In the Test Plan section the approach to testing is stated along with adescription of the general approach to testing all functions. This plan

gives the reader a good idea of how the testing will be conducted. Thedetails of the testing are in the Testing Sections. The Test Planincludes the following:

Purpose References Test Environment Statement Procedure Test Section Checklist

The body of the FAT is split into sections around similar functional test

areas. The sections contain a minimal amount of description of thetesting with the great majority dedicated to recording the data. Eachsection includes the following:

Test number and title Test purpose Acceptance criteria Detailed test procedure Data collection portion of the form Comments section Signature block

Date block Approval block

<00> 5.2 Factory Acceptance Test (FAT)

This test is performed once all panels and software are complete.Panels are checked for conformance to the drawings and operationallytested as much as possible. The entire system is wired together andtested simulating inputs and observing outputs.

guide_spec_vol2 23




The system is functionally tested against the design documents with awritten test plan that is pre-approved and filled out in detail by theperson performing the testing. This test is usually at the CSI’s facilityand should be witnessed by the client. Examples of test sections are

as follows:

• Panel wiring

• Panel power on operational test

• I/O check from panels through the software

• Testing of manual operations

• Testing of functional modules of programming (automatic andsequencing)

• History and reports verification

• Recipe function

• Security

• Power loss and restoration

The development of this test plan is the responsibility of the CSI. TheCSI should write the test plan from the controlling documents such asthe Functional Specification or Software Design Description (SDD) withthe object being to prove the system operates as described in thosedocuments.

The test plan should be sent to the client providing adequate time for the client’s input and comments prior to running the test. This alsogives the client a chance to become familiar with the test plan beforethe start of the test. Any discrepancies that appear during the FAT willbe documented, including party responsible and the date to becompleted.

<00>5.3 Site Acceptance Test (SAT)

Once the system is on site a test must be run to prove the systemtested with the FAT operates correctly with the actual equipment in thefield. This is a rewrite of the FAT and is generally a smaller document.This is a system level test and typically does not include any modulelevel testing. Most sections are a repeat of the FAT using the actualequipment instead of simulating inputs and outputs. Examples of testsections are as follows:

Input/Output check from the field device (can be replaced byLoop Check Forms)

Testing of modes of operation Testing of functional units of programming (automatic and

sequencing)

guide_spec_vol2 24




Power loss and restoration Communication loss and restoration

The format and layout of the SAT is similar to the FAT.

The SAT plan should be sent to the client providing adequate time for the client’s input and comments prior to running the test. This alsogives the client a chance to become familiar with the test plan beforethe start of the test. Any discrepancies that appear during the SAT willbe documented, including party responsible and the date to becompleted.

NOTE: The completion of the SAT is normally considered thepoint of client acceptance.

guide_spec_vol2 25




6. Site Installation

This section covers the Installation of the system at the client’s site.

<00> 6.1 Responsibility of CSI

Contracts vary from project to project, which may change theresponsibilities of both the CSI and the Client. Typically the followingare the responsibility of the CSI:

• Provide or coordinate with subcontractors for electrical, mechanical,and equipment installation. Scheduling considerations of theoverall project must be taken into account.

• Coordinate all construction tasks with other activities associatedwith the project to be sure to adhere to his schedule.

• Turn over field-mounted devices to the appropriate parties for installation.

• Coordinate with the appropriate parties for installation of instruments.

• Perform all Loop Checks (Input/Output checks) to verify proper operation.

• Inspect instrument and panel installations to assure they areinstalled properly.

•

Coordinate the calibration of instruments requiring post installationfield calibration. Review all Calibration forms to verify proper calibration.

• Install software and run Site Acceptance Test.

• Turn over Manufacturers’ Manuals to the Client.

<00> 6.2 Responsibilities of Client

Contracts vary from project to project, which may change theresponsibilities of both the CSI and the Client. Typically the followingare the responsibility of the Client.

• Provide a single point of authority to CSI.

• Receive and inspect all Client provided instruments and other material. This may include bench check and calibration.

• Turn over all instruments to appropriate party prior to the start of installation.

• Coordinate an installation schedule with the CSI that is attainablefor both the Client and CSI.

guide_spec_vol2 26




• Coordinate with appropriate client personnel for shutdown of facilities to allow the installation.

• Coordinate with appropriate client personnel to assure utilities willbe available for start up of equipment.

• Provide adequate production time and materials to complete theSAT.

• Witness Site Acceptance Test.

• Accept the installation.

<00> 6.2.1 Responsibilities of Client Subcontractors

Any of the work that is subcontracted by the client rather than placed inthe CSI contract, will require coordination and inspection.

• Contract with subcontractors for electrical, mechanical, andequipment installation. This must be started early enough in theproject to assure completion by the time instrument installation is tostart.

• Confirm all construction tasks with the appropriate parties and theCSI to be sure they adhere to the project schedule.

• Resolve all schedule, quality, and manpower issues involving clientsubcontractors.

guide_spec_vol2 27




7. Site Start Up

This section covers the start up of the system at the client’s site.

<00> 7.1 Responsibilities of the CSI

Contracts should define responsibilities of both the CSI and the Client.Typically the following are the responsibility of the CSI:

<00>7.1.1 Develop Start Up Plan

• Develop a start up schedule.

• Review safety requirements for the user's site and ensure proper safety training for the start up team.

• Review and coordinate lock-out/tag-out procedures

• Clearly define start up responsibilities.

• Review start up considerations listed in the Project Plan.

• Schedule completion and retesting of any open action items agreedto during the FAT.

<00> 7.1.2 Perform the Start Up

• Complete the system start up according to the Start Up Plan andany information provided by the Project Manager or the client.

•Complete and retest any open action items agreed to during theFAT.

• Perform SAT

• Generate list of changes identified during the start up.

• Review and resolve changes before implementation of changes.

• Make sure approved changes are tested and accepted after completion.

<00> 7.1.3 Generate “As Recorded” Documents

• Document all start up tasks completed.

• Document any system changes made during the start up.

<00> 7.2 Responsibilities of Client

Contracts should define responsibilities of both the CSI and the Client.Typically the following are the responsibility of the Client:

<00> 7.2.1 Plan the Start Up

• Develop a start up schedule.

guide_spec_vol2 28




• Review safety requirements for the site and ensure proper safetytraining of the start up team.

• Clearly define start up responsibilities between the CSI and theClient.

Provide a single point of authority to the CSI. Provide a clear set of expectations to the CSI for: Safety requirements and training Coordinate lock-out/tag-out procedures of client’s personnel Time approval and documentation requirements Expense approval and documentation requirements Change approval authority and process Shift coverage and schedule Use of facilities (office space, phones, etc.) Completion approval requirements

<00>7.2.2 Manage the Start Up

• Maintain the project start up schedule.

• Coordinate activities between all contractors.

• Inform contractors of any changes that may affect their work.

• Review and make timely decisions on any changes requested.

• Provide advanced notification of schedule changes that could affectthe start up.

• Witness any testing or start up activity that requires client approval.

guide_spec_vol2 29




8. Acceptance/Sign Off

This section covers the sign off or acceptance of the system.

<00> 8.1 Testing

Typical testing is performed in two stages, the FAT and the SAT.

As the system is tested, three different results may occur on each itemunder test.

<00> 8.1.1 Acceptable Test

The test result was as specified and is approved for this item. This isthe desired result.

• The approval of the test item should be noted.

• The Client and the CSI should both sign the acceptance form for this item.

<00> 8.1.2 Failed Test

The test result was not as specified and the function will need to bemodified and retested.

• The tester should note the fact that this item failed the test

• Any pertinent information gained in the testing should be noted.

• What is the severity of the error? Can the modification wait or doesit require immediate attention?

• Perform modification and retest the failed section.

<00> 8.1.3 Good Test, But Modifications Needed

The test result was as specified, but the Client wants to modify thefunctionality. As is sometimes the case, the process may functionsomewhat differently from what has been specified. When thishappens, the following must be done:

• The Client requests a change or modification.

• The CSI estimates the cost and schedule impact (if any) of thechange.

• The Client resolves the proposed change.

• The CSI performs the work if approved.

• The client and CSI test the change.

guide_spec_vol2 30




<00> 8.2 Acceptance/Sign Off

At the completion of the FAT or SAT the CSI must prepare and present

an acceptance or sign off document to the Client to complete theproject. This document will signify that the control system is completeand fully functional except where noted on the sign off. All deliverableshave been met or provided to the satisfaction of both parties.

This document is important from both the CSI and the Client standpointas it may signify the end of a project contract and the start of awarranty period. It may also trigger payment for fulfillment of thecontract.

guide_spec_vol2 31




9. Training

This section covers training of client’s personnel on the newly installed system. This can be either the responsibility of the CSI or the Client

depending on the contract.

<00> 9.1 Operators

The operation of the system is defined in the Software DesignDocument (functional specification). The CSI will use this document todevelop an outline for the training course and an operational manual if this is part of the contract. Typically the following are included:

• General description of the system

• Rough overview of the computer hardware

• Navigation of the screens

• Explanation of the variables on each screen.

• “Make ready” procedures

• Start up of the system

• Normal operation of the system

• Alarm and fault resolution

• Shutdown of the system

<00>

9.2 MaintenanceThis training and manual is directed toward the personnel that will bemaintaining the system. This is not a repeat of the operator trainingbut a focus on the maintenance issues. Typically the following areincluded:

• Detailed description of the hardware and communications

• Navigation of the maintenance screens (diagnostic screens)

• Operation of loops

• Utility software

• Back up and recovery

• Periodic and preventative maintenance• Vendor manuals

Note: This training is not intended to replace vendor specific

hardware, software and equipment training.

guide_spec_vol2 32




10. Warranty/On-Going Support

This section covers warranty and on-going support for the newly installed system. This can be included with the new system or part of

a support agreement between the CSI and the Client.

Systems are made up of many components supplied by many differentvendors. These devices are configured into a working system by theCSI. Support and warranty issues should be addressed as part of theoriginal contract between the CSI and the Client. A clear and mutualunderstanding is required by all parties involved as to what is includedin the project and by who it will be done.

<00> 10.1 Warranty

The CSI will typically provide warranty for two types of items.• Purchased hardware, equipment and third party software

• CSI workmanship

<00>10.1.1 Hardware, Equipment and Third Party Software Warranty

This would include all purchased hardware, equipment and third partysoftware, such as PLC or HMI. It would also include all purchased thirdparty software such as Microsoft Windows NT. The followinginformation should be considered and addressed when the Clientcontracts the CSI to deliver a system.

• Warranty start date

• Duration of manufacturer’s warranty period

• Transfer of licenses from CSI to Client

• Replacement policy for opened and unopened parts

• Costs to extend warranty periods

• Costs for software subscription/support services

<00>10.1.2 CSI Workmanship Warranty

This item addresses the warranty of the actual services that have been

provided by the CSI for the Client as part of the project. Warrantypolicies between the CSI and the Client must be agreed to, prior to thestart of any project. Typical items to consider include:

• Warranty start date

• Duration of warranty period

• Costs to extend warranty periods

• Determination of warranty vs. billable services

• Out of Warranty costs

guide_spec_vol2 33




• Documentation of Warranty problems

• Response time for Warranty problems

<00> 10.2 SupportThe CSI can typically provide several different levels of continuingsupport for systems before, during, and after start up depending on theneeds of the Client. Important issues to be discussed and agreed totypically include:

• Safety requirements and training

• Support level required: phone, on site, modem connection

• Response time requirements

• Dedicated CSI employees for client

• No hire policy

• Commercial terms

• Approval authority and process

• Shift coverage