PCP 200 - Global

OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

Control & Information Software........................................6

SCOPE Control Hardware ..............................................................6
Control System Strategy (CSS) .........................................6
This design practice provides an overview of the time
Feasibility Estimate ...........................................................6
relationships between Power, Control & Information Systems
Fixed Bid Project ...............................................................6
(PC&IS) activities and overall project phases as defined in the
Logics Description.............................................................6
Engineering Work Process (EWP).
PC&IS Design Basis..........................................................6
This practice also describes the most common range of PC&IS Physical Process.................................................................6
project types and how to estimate and manage them to deliver a Piping & Instrument Drawings (P&ID) .............................6
working Control & Information system. It also describes the PSI (Pre Start-up Inspection) .............................................6
different project types, project management philosophy and PSU (Post Start-Up)...........................................................6
practices that may be encountered in delivery of a PC&IS Software Design Basis (SDB)............................................6
Software Project. Software Standards Document (SSD)................................6
Time & Material (T&M) Project .......................................6
INDEX Turnkey Project .................................................................6
User Requirements Document (URD) ...............................7
PC&IS Project Effort.................................................................7
SCOPE...................................................................................... 1 C&IS Software Project Management Flow Chart......................8
INDEX...................................................................................... 1 SCHEDULE OF PC&IS SYSTEM ACTIVITIES ....................9
GENERAL................................................................................ 1
PC&IS Software Project Management ..................................... 1
Overview............................................................................... 1 GENERAL
PC&IS Project Cost Estimating Challenges ......................... 2
Identify the PC&IS Project Scope ........................................ 2 Correct sequence of activities in proper time relationship with
1. Physical Process Project ........................................ 2 other project activities is necessary for successful PC&IS
2. Re-control Project.................................................. 2 results. Figure 2: “Activities, Deliverables and Relationships”
Characterize the Project Risks .............................................. 3 at the end of this document shows the relationship between
Identify the Project Resource Requirements......................... 3 project phases for the Physical Process, Control Engineering
1. No Development (ND)........................................... 3 events and Software Engineering. This diagram does not
2. People Development (PD) ..................................... 3 represent the actual time length of any project phase as that will
3. Technology Development (TD) ............................. 3 vary depending upon the type of project and its requirements
4. Technology & People Development (TD&PD)..... 3 PCP 225 details the many activities and deliverables needed for
Estimate PC&IS Software Project Cost ................................ 3 PC&IS hardware implementation. PCP 205 describes the
Decide Appropriation or Partial-Appropriation Funding...... 3 contents of a User Requirements Document. PCP 210 details
Identify Requirements for Development and Testing ........... 3 the requirements for the PC&IS Design Basis. PCP 230 details
Select a Project Implementation Approach........................... 3 the steps of software implementation and their relative
1. Time and Material.................................................. 3 sequence.
2. Fixed Bid ............................................................... 3 Conceptual and definition activity of the Physical Process is
3. Turnkey.................................................................. 4 detailed in Front End Engineering (FEE) as described by the
4. P&G Internal.......................................................... 4 Engineering Work Process (EWP). The Power and Control
Select the Automation Organization ..................................... 4 Practices manual (PCP) focuses on standards and practices for
1. Control System Vendor ......................................... 4 the design, construction, and commissioning phases of the
2. Independent System Integrator .............................. 4 Physical Process. Issuance of an approved design basis
3. Full Service Engineering Firm............................... 4 initiates the Design Phase of the Physical Process.
Select Formal or Informal PC&IS Project Management ...... 4
Create Supporting Documents .................................................. 5
Control System Strategy (CSS) ............................................ 5
Software Standards Document (SSD)................................... 5
PC&IS Software Project Management
Architectural Diagram (AD) ................................................. 5 Overview
User Requirements Document (URD) .................................. 5 The design and construction of a PC&IS automation project can
Logic Description (LD)......................................................... 6 take many different forms and paths depending upon the
DEFINITIONS ......................................................................... 6 Project approach and personnel involved. In many cases the
Architecture Diagram (AD) .............................................. 6 individuals who develop the User Requirements Document
Budgetary Estimate........................................................... 6 (URD) are not the same ones who will deliver the applications.

February 20, 2004 Page 1 of 9

PCP 200 OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

The URD thus becomes the “contract” between customers and automation using traditional logic diagrams. This expanded
the automation system suppliers with the Software Design scope lead to the development of the Software Design Basis
Basis (SDB) identifying how that “contract” is being fulfilled. and other tools to adequately describe the automation
There are many complex factors that will influence how a application. The number of qualified implementers decreased
project is managed. Depending upon these factors, it is not but there were more than enough to adequately meet
always clear when there will be enough information to requirements. Even with this increased capability estimating
accurately predict the best path that will lead to a successful and delivering applications were usually accomplished without
automation effort or what the final cost and timing will be to significant issues.
fulfill the needs of manufacturing. The following sections will In the late 80’s and early 90’s the power of the controllers
help in understanding, quantifying and managing these became such that it was possible to automate very large parts of
uncertainties. manufacturing operations, generate and collect large amounts
of data and present operators with interfaces that greatly
enhanced their efficiencies. Being able to accurately identify
the required effort for these more challenging applications
required skills that were rare and there were many projects that
greatly exceeded their worst case estimates. Buying a $25,000
controller might take $20,000 to program on one project and
the same controller could require $200,000 on the next
depending upon the application requirements and the people
involved. In many cases the application requirements did not
seem that different but the resultant effort was dramatically
different.
As we continue to automate the manufacturing “business” as
well as the physical process the difficulty to accurately identify
costs and effort increases. While not impossible, one must
make sure of the project scope and the ability of the resources
to deliver that scope.
Identify the PC&IS Project Scope
The scope of the PC&IS part of a project can vary greatly and
is determined during the Feasibility Phase. It is best if the
Preliminary URD can be started at that time as it will enable the
PC&IS engineers to more accurately predict project
Figure 1: Feasibility & Conceptual Phase requirements and develop viable options to meet project needs.
There are generally two project classifications for PC&IS
PC&IS Project Cost Estimating Challenges projects:
To understand the reputation of PC&IS automation projects as 1. Physical Process Project: In this case the PC&IS effort is
generally exceeding worst case cost estimates one must only a part of a new plant or process (10% to 30% of the
examine the history of process automation. capital/effort). In this case there are many teams of
During the early 70’s physical relays and single loop controllers engineers (Process, Mechanical, Power, PC&IS, and
were used to automate manufacturing and fixed panels were others) whose efforts must be closely coordinated. In this
used as an operator interface. Determining the number of case there are significant project resources in place which
components required and the cost of installing and configuring can be used to overcome “unforeseen” needs in any part of
the equipment was relatively straight forward and could be the project.
done with a fair degree of accuracy and certainty. There was 2. Re-control Project: In this case the PC&IS effort is the
also a large pool of people capable of successfully delivering dominant part of the project as the process doesn’t change,
these applications. The basic process control could be or changes very little, but the controls and automation
adequately represented in logic diagrams which became the software are totally upgraded. In this case there is generally
User Requirements Document and there was no “software” to only one engineering team (C&IS) and fewer resources
describe or program. available to address “unforeseen” needs. Also many of the
During the late 70’s and early 80’s the capabilities of deliverables of a larger project are not required.
controllers greatly increased and programmable operator In both of these cases the PC&IS effort and costs should be the
interfaces became available. With this new capability greater same but the first case generally has more latitude for mistakes
automation of the manufacturing operations became feasible and unforeseen issues.
and the amount of “logic” programmed in the controllers
greatly increased. It became difficult to document the

February 02, 2004 Page 2 of 9

PCP 200 OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

Characterize the Project Risks The PD type project has enough certainty by the end of the
Every project will have variations in the amount of technology Conceptual Phase for a reasonable estimate. The TD and
and/or people development required, from none at all to total PD&TD remain uncertain until well into the project.
development for both the technology being used and the people Percent error range of estimates at the end of a phase
applying it. This determination must be accurate and must be Project Type Phase
Feasibility Conceptual Definition Design Construct-C/Q
made very early in the Conceptual Phase as it will impact future
Type 1 - ND +30/-20 +15/-10 +10/-10 +10/-10 +5/-5
critical decisions. During the course of any project it is very Type 2 - PD +50/-20 +30/-10 +20/-10 +15/-10 +10/-5
important to have peer reviews using “qualified” resources to Type 3 - TD +200/-40 +100/-30 +30/-10 +15/-10 +10/-5
help identify and validate these critical assumptions. Type 4 - PD&TD +500/-50 +200/-40 +100/-30 +50/-20 +30/-10

If this is not done properly the risks are higher and the project
may experience significant cost overruns, up to 500% in some Table 1: Project Types and Error Ranges
cases, and in some extreme cases total project failure will Decide Appropriation or Partial-Appropriation Funding
occur. If the PC&IS project is a type ND, or enough is known about a
It is a good idea to always monitor and verify the assumptions type PD, it is reasonable to proceed with an Appropriation
of a project as it progresses and if they are ever found to be in request at the end of the Conceptual Phase. This is the approach
error to quickly bring it to the attention of the project manager. used by most large projects.
Identify the Project Resource Requirements All other project types should make a “Partial-Appropriation”
Almost all projects fall into one of the four following categories request for enough funding to cover all the development of the
with associated characteristics and risk: Preliminary Software Design Basis. At some point during the
1. No Development (ND): The project will apply proven development of this document there will be enough information
technology using people experienced with the technology. to ask for the full appropriation by the end of the Design Phase.
With this type of project there is little risk and any issues At this time project scope may be reduced if it is determined to
are usually easy to deal with. As can be seen in the Error be too costly, or too risky, to deliver, the URD should be
Ranges table 1 it is possible to have reliable estimates very updated to reflect the changes, and a final request for
early in the project. appropriation is made.
2. People Development (PD): While this type of project is very Identify Requirements for Development and Testing
manageable and common there is significant risk if the During development and for the factory acceptance testing
ratio of experienced people to inexperienced is low, if the additional equipment and software licensing maybe required. If
ratio of experienced to inexperienced is balanced or favors at all possible testing of the entire system should be done at the
experienced then the risk is low. Knowing the capabilities automation supplier’s facility. This should be identified and
of the technology and those who will use it to deliver the planned for.
automation is critical to making project decisions. One Select a Project Implementation Approach
must also allow for additional time in the schedule and cost P&G projects fall into one of the following four funding
in the estimate for this people development. approaches. No matter what approach is chosen an effective
3. Technology Development (TD): In this case the risk is low to method of identifying and managing change must be
moderate if identified early and managed properly. The documented, agreed to and rigorously followed.
people doing this work must have control technology 1. Time and Material: In many cases this will be the least
development backgrounds and deep understanding of expensive method to deliver a project. However this is only
automation applications. true if there is precise understanding of the requirements
4. Technology & People Development (TD&PD): This type of and the ability of the vendor/integrator to deliver these
project carries the highest risk and these projects should be requirements. There is some risk with this type of project,
avoided if at all possible. If it is absolutely necessary to go should issues arise that cause a delay and/or more effort
ahead with this type of project special management using than expected the cost will have to be covered. P&G owns
only the most experienced people is required and there will the risk associated with this type of project approach. With
be significant people development costs and the project some vendor/integrators it is possible to develop a “shared
should expect a longer than normal implementation time. risk” approach with a not to exceed cost. Should the not to
exceed cost occur, the vendor/integrator will operate at a
Estimate PC&IS Software Project Cost reduced charge rate for the remainder of the project.
During the project Feasibility phase the project type (ND, PD,
TD, and TD&PD) is identified. Based upon the project type and 2. Fixed Bid: In this approach P&G will provide the
information from the Preliminary URD Cost Engineers and vendor/integrator with a totally complete URD. The
PC&IS Engineers prepare estimates and decide on the funding vendor/integrator will respond with a Preliminary SDB to
strategy. As shown in the Error Ranges Table only the ND type make sure all requirements are well understood and a
project has enough certainty at the end of the Feasibility Phase Fixed Bid to deliver the automation specified in the
to allow a reasonable estimate for the automation effort/cost. Preliminary SDB. If P&G accepts the bid the
vendor/integrator assumes all risk in the delivery of the

February 02, 2004 Page 3 of 9

PCP 200 OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

requirements. It is critical that the detail in, and the same highly trained people the next time one uses their
understanding of, the URD / SDB be such that scope services.
changes are not required. If the URD or SDB are not Select Formal or Informal PC&IS Project Management
clearly understood by either party disappointment is P&G has used a variety of approaches to implement and
certain. Resolution of this disappointment can be lengthy manage PC&IS software projects. An evaluation of past project
and costly. performance indicates that some P&G projects did not provide
3. Turnkey: In this approach the vendor/integrator is an adequate balance between risks incurred and functionality
responsible for developing and delivering all aspects of the and quality of services obtained. The two dominant project
PC&IS part of a project generally based upon process management approaches are referred to as “Formal” and
requirements. This does not mean that P&G PC&IS “Informal”. Both have their benefits and shortcomings with the
Engineering is not accountable for the success of the extremes represented in the Project Management Models table
project, it only means they do not have any responsibility 2. The Formal Project Model is the most conservative, most
for its delivery. At a minimum reviews of the costly, and lowest risk and the Informal Project Model as the
vendor/integrator’s documents and approaches should be least costly, fastest, and highest risk.
requested as long as this does not impact project cost. Attributes Formal Model Informal Model
4. P&G Internal: In a very few cases P&G PC&IS Engineers Cost Mid-Priced but very
predictable.
Significant savings if done correctly
or very large cost overruns if done
will deliver the automation, or a significant part of it. In poorly.
this case it is a matter of effort and internal cross charges Time Mid-Length but very Very short if done correctly or very
predictable. long if done poorly.
and not an expenditure of P&G capital. A watch out for the Functionality Structured and rigid. Robust and fluid if done correctly,
project team is that P&G people are generally not as unstructured and costly to modify
and support if done poorly.
available as contractors because of the inherent overhead Change management Formal. Informal.
of a large company. Staff Size Midsize. Very small.
Staff’s operating level At proficiency level. Deep technical mastery across entire
Select the Automation Organization team to achieve benefits.
Depending upon your choice of an automation company or Dependence on individual Staff is more inter- Highly dependent on key staff
staff members changeable. members technically and for
companies the risk/benefit will vary greatly. Regardless of the continued project execution.
Automation organization the ultimate accountability for the Risk Low. High.
control system lies with the P&G Controls engineer.
1. Control System Vendor: Control system vendors generally Table 2: Project Management Models
have a large work force with varying strengths covering all In the Informal Model the assumption is that the people doing
of the products that they sell. When the Control System the implementation are “expert” at using the technologies
Vendor provides the automation there is less risk but involved and the requirements are already understood by all
generally greater costs. The Control System Vendor will parties. Generally little, if anything, is done during the
generally require a very firm URD and contract detailing Definition & Design Phases. Rarely is there a Final URD,
exactly what will be delivered with very strict change Preliminary or Final SDB with the actual Programming Code
management. If something unforeseen occurs the vendor substituting for the SDB at the end of the project. If done
will generally make good on the intent of the contract. properly this is adequate but often the project is left with only
2. Independent System Integrator: System integrators generally an updated Preliminary URD substituting for the “As-Built
have a small work force that is very strong in the areas they URD”. The quality of the final documentation often is
have chosen to operate. In these areas they often provide generally significantly less than what is received at the end of a
superior performance than the original supplier of the Formal Model Project. Because of the assumption that there
chosen control system. When a systems integrator provides will be insignificant issues there are few reviews with the
the automation one can realize significant savings, but expectation that issues will be minor and will be identified
there are usually more risks than with the Control System during the Commissioning & Qualification phases and
Vendor. Many systems integrators are also willing to corrected before Verification phase. This leaves the total
assume more risk and operate with less formal application project at risk if there is something significant that those
definition with an assumption that the project will share in delivering the application miss or misinterpret. To increase the
some of that risk. Should something unforeseen occur probability of success frequent reviews should occur just to
involving the control system the PC&IS engineer will make certain all is well.
become the intermediary between the supplier of the An informal project can deliver projects that are over 50% less
control system and the integrator to get the issues resolved. costly and require 50% less time to execute, which can make it
3. Full Service Engineering Firm: These companies generally very attractive. Under the right circumstances it is the right
have a staff that can address all aspects of a project, from thing to do. When attempting this type of project management
concrete to power and control. Their capability will vary it must be done with the right people and only be used on
and people movement is usually high so one may not see projects that require no development.

February 02, 2004 Page 4 of 9

PCP 200 OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

Use the “Formal” approach to manage a PC&IS project can Audience

provide a much higher chance of success independent of the The intended audience for this Control System Strategy (CSS)
technical capabilities of the design and delivery team. With the is the Control & Information Systems (C&IS) project and
right people use of the “Informal” approach, or a variation of technical managers.
the two, might be the right choice for your project. The key to
success in the “Informal” approach is the experience level of Software Standards Document (SSD)
those involved. The Software Standards Document (SSD) is specific to a plant
site, not for an individual project. The document is initially
In the Formal Model each project phase is completed before the generated once the User Requirements Document (URD) is
next is initiated with all required deliverables provided at the completed for the new plant construction project. For
proper time. Changes introduced during any project phase subsequent projects, the document is updated concurrently with
require updating all documentation produced during preceding the URD to show any additions or modifications to the
phases with economic and timing impacts evaluated and standards. The document includes both design and
compensated for. Because of the interaction between the P&G implementation standards. The attachments can include the
engineers and the deliverers of the automation potential upsets design of specific functions that are repeated throughout the
are identified early and compensated for, preventing site. Implementation standards generally deal more with the
unexpected project upsets. look and feel of the final software. The SSD template in the
For a visual understanding of these processes see the C&IS PCP Appendices provides a more complete list. A design or
Software Project Management Flow Chart at the end of this implementation standards that is specific just to a project is
PCP. generally included in the project URD as a design requirements
attachment and not in this document. If the existing SSD does
Create Supporting Documents not address the needs of the current project it should be updated
to reflect the requirements of the current effort.
Control System Strategy (CSS)
The Control System Strategy describes the overall automation Refer to the PCP appendix for a SSD template.
philosophy, specific control/microprocessor platforms, and Audience
integration of these systems. It will define the reliability and
The intended audience for this Software Standards Document
redundancy requirements of the Control Architecture. The CSS
(SSD) is the Control & Information Systems (C&IS) project
describes the general philosophy for many specific PC&IS
and technical managers and the automation organization..
deliverables such as electrical room or electrical panel designs,
wiring designs, motor control design, power distribution or Architectural Diagram (AD)
power monitoring and grounding requirements. The CSS This diagram describes the physical control system and the
template in the PCP Appendices provides a more complete list. location of the automation functions within the physical
The CSS describes the overall operational plan and the equipment as described in the SDB. The AD is an important
automation model that is intended to support the operation document used to communicate functional residency and
roles. This includes Startup and Shutdown automation, control interaction between software components as the project
information requirements, advanced control strategies, general progresses.
description of operator interface requirements. By its content Refer to the appendix for an AD template.
the CSS will drive all hardware and software scope and scope
definition for a project. Other documents are usually used to Audience
track all hardware and instrumentation standards but in their The intended audience for this Architectural Diagram (AD) is
absence, the CSS may also be used to document this type of used by the Control & Information Systems (C&IS) project and
information especially for a grass-roots facility. technical managers and the automation organization.
The Control System Strategy (CSS) is specific to a plant site. User Requirements Document (URD)
A plant site is defined as an operation or group of operations The first major activity for C&IS engineers in the Engineering
that share significant operating and support resources. Work Process is the collection of control system requirements.
Typically this would be for a making operation, a converting Requirements are generated from the needs of the process,
operation, or a packing operation. These strategies are needs of the users and needs of the manufacturing
necessary to guide the development of the User Requirements infrastructure. The User Requirement Document, or URD,
Document (URD) and electrical design. This document will captures those requirements. On a large project there may be
continue to be updated throughout the project and thereafter, separate URD’s for different blocks of scope.
such that it always represents the current best control system A URD is normally written in two versions. A preliminary
strategies for the site. Each new project should begin with a version is written in the conceptual phase and contains mostly a
review of the CSS and revise as appropriate as technology or high-level outline of requirements. A final version in the
the organization design evolves or new broad base definition phase adds detail to the outline. A URD serves as
requirements are identified. input to the physical design basis. A URD may provide
Refer to the PCP appendix for a CSS template.

February 02, 2004 Page 5 of 9

PCP 200 OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

sufficient detail to serve as the software design basis for some Feasibility Estimate – This is an early estimate developed
projects. during the feasibility phase that is used by management to
A URD differentiates between requirements and preferences. determine if there is enough potential value vs. cost in the
A URD does not address project scheduling, funding or project to proceed with further refinement.
justification. Fixed Bid Project - This is a method where a vendor will
The Preliminary and Final URD are developed during develop a bid based upon the Final URD. There is generally a
feasibility, conceptual, definition and design phases as significant amount of interaction with P&G as the vendor
described in PCP 205. develops the SDB. Generally the vendor will return to a T&M
basis after the Factory Acceptance Test is successfully
Audience completed and support Start-Up on a T&M basis.
URD’s are intended to be read and reviewed by a wide Logics Description – These documents consist of Logic
audience. They are written in a language easy to understand by Diagrams, written prose descriptions, Standard Device Logic,
any engineer or technician familiar with the process. It does Sequential Flow Charts, Block Flow Diagrams, Batch Sequence
not contain control technology acronyms or jargon. It does not Overview, Timing Charts, or any other means to describe the
generally specify control hardware devices or software detailed control requirements, including interlocks, permissives
packages. operator interactions, etc.
Logic Description (LD) PC&IS Design Basis – A collection of documents that defines
These documents consist of Logic Diagrams, written prose the detailed requirements of the scope of the work to be
descriptions, Standard Device Logic, Truth tables, Sequential designed.
Flow Charts, Block Flow Diagrams, Batch Sequence Overview,
Timing Charts, or any other means to describe the detailed Physical Process - The installation made up primarily of
control requirements, including interlocks, permissives operator hardware - such as vessels, pumps, heat exchangers, actuators,
interactions, etc. PCP 405 on Logic Diagrams is an example of motors, packing machines, conveyors, etc. that produces a
one way to provide these documents. desired product.
Audience Piping & Instrument Drawings (P&ID) – These drawings
identify all of the physical equipment, describe their inter
The intended audience for the Logic Description (LD) connections, identify all of the process instrumentation and
documents are the Control & Information Systems (C&IS) safety devices.
project and technical managers and the automation
organization. After Start-Up these documents are used by PSI (Pre Start-up Inspection) – This effort occurs after the
operations for support of the system. control system is installed, ready for operations and
construction has turned over the process for testing.
PSU (Post Start-Up) – This effort occurs after the system has
gone through CQV. Any issues identified during the CQV
DEFINITIONS process are addressed, at the end of PSU operations takes over
Architecture Diagram (AD) – This diagram describes the responsibility for the system.
physical control system and the location of the automation
Software Design Basis (SDB) – This collection of documents
functions within the physical equipment described in the SDB.
describes how the functions defined in the URD are
Budgetary Estimate – This is a refined Feasibility Estimate implemented in the automation system.
created during the conceptual phase and is a more accurate
Software Standards Document (SSD) - This collection of
estimate used for an Appropriation request. If management
documents defines how the resultant source and object code
determines there is too much uncertainty in this estimate, then
will be created and documented and how version control will
further work is required and a Partial Appropriation request is
be implemented.
made for enough capital to continue definition work.
Time & Material (T&M) Project – This is a method of
Control & Information Software - The programs and firmware
compensating contractors and vendors for work based upon an
that automates the Control hardware for the physical process
hourly/weekly/monthly charge rate. They are paid for their time
and acquires data for reporting and analysis.
independent of what they do or the results of their work.
Control Hardware - Programmable Logic Controllers (PLC),
Turnkey Project – This is a method where a vendor will bid on
Distributed Control System (DCS) controllers, Human Machine
and deliver a project with only the information from Feasibility
Interfaces (HMI), Data Base Servers used to collect and store
and Conceptual phases. These projects generally have little
data, sensors, actuators, control panels, etc. that physically
interaction with P&G PC&IS engineers until the factory
control the process and provide operator access.
acceptance test.
Control System Strategy (CSS) – This document describes the
basic automation philosophy that will be used to define and
develop the project.

February 02, 2004 Page 6 of 9

PCP 200 OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

User Requirements Document (URD) – This document

describes the control and automation functions, process
performance requirements, and information system
requirements for each unit operation.

PC&IS Project Effort

% of
Total
Deliverable Project Phase Effort
Preliminary URD Feasibility & Conceptual 10%
Final URD Definition & Design & 15%
Implement
Preliminary SDB Definition & Design 10%
Final SDB Implement & Test 20%
Program & Configure Implement 10%
Integrate and Test Test 15%
FAT Working System Install/CQ 15%
Running System V/PSU/Support 5%

Table 3: Normal division of effort for deliverables

February 02, 2004 Page 7 of 9

 PCP 200 - Global

OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

C&IS Software Project Management Flow Chart

February 20, 2004 Page 8 of 9

PCP 200 OVERVIEW OF PC&IS SYSTEM SOFTWARE PROJECT MANAGEMENT AND ACTIVITIES

SCHEDULE OF PC&IS SYSTEM ACTIVITIES

Figure 2: Activities, Deliverables and Relationships

August 20, 2003 Page 9 of 9