GDF 002 (J)_PMC AMP_Configuration Management

GDF 002(J) – PMC AMP – Configuration Management
(refer to GDD 002 – section 6.2.4)

[CLIENT NAME & PROJECT NAME]
CONFIGURATION MANAGEMENT
Procedure No. X-XX-XX-X-001
Version [v0]
Reviewed by:
Program / Project Director: Date
Approved by:
General Manager: Date
Rev. Description Author Date

V0
V1
V2
V3
V4
Procedure No. Revision No. Date Author Page

X-XX-XX-X-XX 0 Page 1 of 13
GDF 002(J)_R0
1. This policy and procedure is controlled and centralized by the Quality Assurance Department.
2. Only the controlled electronic version is true and correct.
3. All printed or other copied versions are uncontrolled and should be destroyed when finished with.
4. The user is responsible for consulting the latest electronic version online.

GDF 002(J)_R0
CONTROL OF MODIFICATIONS
Version Page Modifications
V0.1

GDF 002(J)_R0
CONTENTS
1. Purpose..........................................................................................................................................4
2. SCOPE............................................................................................................................................4
3. DEFINITIONS AND ABBREVIATIONS...............................................................................................4
4. RESPONSIBILITIES AND AUTHORITIES............................................................................................4
5. POLICY AND PROCEDURE...............................................................................................................4
5.1 Products managed in configuration.......................................................................................4
5.2 Flowchart of the configuration management procedure.......................................................5
5.3 Configuration status..............................................................................................................6
5.3.1 Basic configuration.........................................................................................................6
5.3.2 Benchmark configuration...............................................................................................6
5.3.3 Applicable configuration................................................................................................7
5.3.4 Actual configuration.......................................................................................................7
5.4 Management of modifications...............................................................................................7
5.4.1 Definitions......................................................................................................................7
5.4.2 Types of modifications...................................................................................................7
5.4.3 General process.............................................................................................................8
5.4.4 Deviations impacting several entities / contracts..........................................................8
5.4.5 Contracts amendments..................................................................................................8
5.4.6 Follow-up of modifications / deviations.........................................................................8
5.5 Configuration management and recording of the configuration status.................................9
5.5.1 General description of the configuration management process....................................9
5.5.2 Notification of a change.................................................................................................9
5.5.3 Change form..................................................................................................................9
5.5.4 Building non-compliance form.....................................................................................10
6. ATTACHMENTS............................................................................................................................11
7. REFERENCES................................................................................................................................11

GDF 002(J)_R0
1. PURPOSE
A configuration management system has to be adopted to monitor the status of the work according
to the customer specified requirements by the customer. All divergences are documented and must
be approved by the customer.
The specified requirements include technical or management requirements of the Contract, agreed
with the customer, or established in any document in connection with the Contract.
2. SCOPE
The aim of the configuration management process is to identify the description of the product and
enable participants to use consistent, approved data. The product to which this configuration
management guideline is all the scope that make up the project.
The configuration management process starts at the beginning of the description stage and, for the
purpose of the project, from the first task, that of appropriation. There are four steps to this:
 Identifying the configuration, i.e. stating the products (and components) concerned and
drawing up specific documentation (technical description).
 Mastering the configuration, i.e. characterizing the benchmark configuration, establishing
change procedures, handling instances of non-compliance and finding solutions.
 Recording and monitoring the configuration, i.e. detailing all changes in set documents.
 Reviewing the configuration, i.e. checking consistency between the various considerations,
and making sure that measures are applied.
The configuration management process is used until completion of the contract with the customer.
3. DEFINITIONS AND ABBREVIATIONS

PNC: Product not concerned by safety
RFI: Request for information
NCR: non-conformity report
4. RESPONSIBILITIES AND AUTHORITIES

The configuration management process is led by PMC Project Director, for application within their
activities, with the operational assistance of the technical coordinator for the monitoring of changes
within the technical scope.
5. POLICY AND PROCEDURE
5.1 Products managed in configuration

Configuration management is based on a list of products that will form the basis of the monitoring
processes to be followed throughout the project. These products, which are subject to ongoing
GDF 002(J)_R0
checks, are referred to as configuration items.

The definition of configuration items obeys some of the rules given below:
a) The definition of configuration items must be attached to the plant’s product tree diagram.
b) The exhaustive list of items must cover the full range of the prime contractor’s services.
c) Items must be systematically attached to Safety Important Components whenever these are
available or failing this must be marked PNCS (product not concerned by safety).
d) Each item must be matched to the documents (written and graphic) that describe it.
e) At the very least, each piece of equipment whose construction may require a special industrial
contract must be identified as a configuration item in its own right.

GDF 002(J)_R0
5.2 Flowchart of the configuration management procedure

No WHO WHAT HOW RECORD
Configuration
1 PMC’s
management
Project
planning
Director
Identify configuration Issue RFI if required

items Issue NCR if
2 Technical
required
coordinator,
Approve
3 Customer Customer approves the Engage issues a list
configuration items
list of suggested items of approved items
identified by Engage
PMC’s Control changes Change control

Project procedure
Director
4 Technical Record configuration Configuration

coordinator status management table
Data base
5 PMC’s Review configuration For: Minutes of meeting

Project during project
Director  Improvement of
reviews
basic configuration
 Applicable
GDF 002(J)_R0
configuration
 Actual configuration
5.3 Configuration status
5.3.1 Basic configuration

This is the benchmark configuration described in chapter 5.2 below, but which is managed only at a
contracting authority level, i.e. based on documents accompanying the prime contractor’s
contractual deal.
Whenever the Engineer gets involved with initial documents and uses them, this basic configuration
becomes a benchmark.
The basic configuration is made up of:
 The special technical clauses applying to the deal.
 The Final Functional Requirements.
 The customer preliminary safety report.
5.3.2 Benchmark configuration
5.3.2.1 Information on the benchmark configuration

The benchmark configuration is initialised by the customer Initial Functional Requirements and will
then be supplemented with engineering documents drawn up during the project’s research stages.
In particular, these include:
 Safety documents issued by customer;
 Engineering documents issued by the Engineer and Contractors;
 Companies’ research documents and other information packs, etc.
5.3.2.2 Changes in the benchmark configuration

As the project moves forward, the benchmark configuration changes and is updated with the help of
updated lists of written and graphic documents, with each revision being tracked in the project's
document management system. During the design evolution the lessons learned coming from the
configuration management system operation are evaluated in order to implement improvements in
the system leading to the optimum configuration.
It is important to note that any change in the benchmark configuration must systematically be
explained by the requestor, and then studied by PMC’s Change Committee so that any decision and
its repercussions is understood by all parties concerned. The Change Committee includes the
following participants:
 The PMC Project Director and/or his deputy.
 The configuration Manager
GDF 002(J)_R0
 The cost control Manager.

 The contract Manager
 The Schedule Manager
Only the Change Committee is authorised to approve or reject a change.
All changes are systematically recorded in a summary table.
5.3.2.3 Written and graphic documents

The list of written documents with their revision indices is updated in real time and issued whenever
necessary. This list is based on the document management system brought in for the project.
5.3.3 Applicable configuration

This is the benchmark configuration taking into account changes accepted over the course of the
project, whether these relate to intentional modifications or corrective measures.
5.3.4 Actual configuration

This is the applicable configuration taking into account changes linked to submission for as built
(construction, testing and handover stages).
5.4 Management of modifications
5.4.1 Definitions
A modification (or variation) is defined as a planned alternative to one of the following items:
 The requirements of the technical and management specifications.
 Any document issued by PMC and approved by the customer.
 Any document issued by a Contractor and accepted by PMC.
A modification with a significant impact on cost, schedule, interfaces, liabilities, and / or contractual
requirements is called a contractual deviation (or deviation).
Modifications and deviations can be initiated by Customer, PMC, and any Contractor and can be for
Engage or Contractors implementation.
5.4.2 Types of modifications

The table below summarizes the different types of modifications / deviations used within the
project.
Initiator Customer PMC Contractor
Type
Modification N/A Modification File (MF) Proposal of Field
Modification (PFM)
Deviation with Ordre de To Contractors: PMC instruction N/A
GDF 002(J)_R0
mandatory Service (OS)

execution
Deviation Deviation For PMC’s Contract: Supplier Supplier Deviation
without Notice (DN) Deviation Request (SDR) Request (SDR)
mandatory
To Contractors: Deviation
execution
Notice (DN)
5.4.3 General process

For each detected modification or deviation, its originator (Customer, PMC or Contractors) issues a
form corresponding to the type of modification as described in the above table, describing the
proposed modification (such the precise technical definition of works to be modified, the
foreseeable duration, the nature of materials, the products to be used and the processes to be
implemented).
The entity in charge of the implementation of the modification or deviation provides an impact
analysis in terms of interfaces, schedule, performance, cost, safety, documentation, etc…
Each impact analysis is then assessed and accepted/rejected according to the following table:
Modification / Deviation Originator of the impact Impact analysis to be assessed by
analysis
Modification PMC N/A
Deviation PMC Customer
Modification Contractor PMC
Deviation Contractor PMC + Customer
When the impact analysis is officially accepted, the modification or deviation is implemented by the
concerned entity.
5.4.4 Deviations impacting several entities / contracts

When a deviation initiated by Customer, PMC or a Contractor impacts several Contracts, PMC
performs a detailed impact analysis of the deviation supported by a Modification File.
This detailed analysis allows determining the different impacts of the deviation regarding technical
issues, time schedule, cost, nuclear safety, quality, etc… and determining the different Contracts
impacted by the deviation.
For the impacts regarding PMC’s Contract, PMC issues a Supplier Deviation Request to the customer
and for the impacts regarding Contractor(s)’s Contract(s), PMC issues a Deviation Notice or PMC
Instruction to each concerned Contractor.

GDF 002(J)_R0
5.4.5 Contracts amendments

An amendment to the PMC’s Contract or Contractors’ Contract is required when a deviation leads to
a modification of the provisions of the contractual ‘Specific Conditions’ and ‘General Conditions’ – in
particular a variation on the overall Contract value, payment modality, duration of the Contract (if
mentioned in the specific conditions) or substantial change to the scope of the Contract.
The implementation of the deviation may under no circumstances begin before the date of the entry
in force of the associated amendment.
5.4.6 Follow-up of modifications / deviations

The status of all modifications and deviations is monitored by Engage through a dedicated register
and reported to the customer monthly.
5.5 Configuration management and recording of the configuration status
5.5.1 General description of the configuration management process

Configuration management is based on the establishment of a benchmark configuration. All of the
changes made to this benchmark are then recorded.
When aspects of the project fail to meet expectations, Non-Conformity Reports (NCR) are issued.
A deviation is something that affects the status (technical, deadline, cost, performance, safety) of
the benchmark configuration.
The deviation management process is triggered as soon as the configuration baseline is identified. It
is led by the Project Director with the help of the technical coordinator and applied by all Project
staff.
5.5.2 Notification of a change

The origin of a “change” may lie with PMC, customer, or a Contractor. It may involve a need for a
technical change (suggested improvements, order to modify), PMC observations or a Contract
discrepancy against the contractual benchmark during design, construction, and testing stages. It
should be noted that the Engineer and customer alone are permitted to draw up Deviation notice.
With CF, the change request will be forwarded to the customer, along with the relevant cost (via a
CF), either for information or for acceptance. If granted, this acceptance will permit PMC to prepare
the change request. Change forms submitted to customer for prior acceptance are those that affect
costs, deadlines, performance or safety, or which concern material that customer wishes to monitor
closely.
It is important to note that the prime contractor is forbidden from preparing any contractual change
request that it has not already been formally approved by the contracting authority.
The CF determines whether there is a contractual impact (cost, deadline, performance, safety),
whether the CF affects a SIC Component and whether it concerns or impacts a piece of equipment
that the operator wishes to monitor more closely.
GDF 002(J)_R0
5.5.3 Change form

The creation of a CF involves the following information:
 Numbering the form in accordance with the document identification procedures.
 Entering the issuer, issue date and possible impact on the configuration, stating the purpose
of the request, specifying the parts of the plant concerned, circumstances that justify the
requested change and documentary justification.
 Criteria affected, specifying in particular whether the functional need has been affected or if
Safety Important Components are concerned by the impact of the form.
 Contractual documents affected and documents to be updated or created.
The CF must also be characterised technically and economically to examine the impact on the
contract, deadlines, costs, risks, and safety.
As stated above, the preparation of a change request is a technical/economic study in itself and to
this end; preparation must cover all of the following points:
 Technical study of the change, characterising the repercussions for each discipline or area of
work.
 Economic study showing the difference between engineering costs and expected completion
costs and distinguishing between the following three scenarios:
o Before consolidation of prime contractor building estimates.
o After consolidation of prime contractor building estimates and before construction
deals are concluded.
o After construction deals have been concluded.
 Specific examination of potential impacts of the request on identified project risks.
 Scheduling study, including the consequences in terms of deadlines for engineering and
construction, with a special study of the critical path.
CF are examined internally and approved by the PMC’s project director. They are saved in the
document management database for identification, and then forwarded to the contracting authority
for information or acceptance.
CF examined internally and rejected by the prime contractor’s project manager shall be forwarded
to the contracting authority for arbitration.
5.5.4 Building non-compliance form

During the building stage, instances of non-compliance are detected by the contracting authority,
prime contractor, regulatory supervisors, and organisations responsible for checking compliance.
The non-compliance form is opened by the person who detects it.
The creation of an NC initially requires the following information:
 Name, date, and stamp of the author in the “file opened by” box.
 Contract reference in the “deal” box.
 Designation of the work or part of work concerned by the non-compliance in the “subject”
GDF 002(J)_R0
box.
 Reference document against which the non-compliance has been noted, in the “reference"
box.
 Numbers and references of attachments in the “attachments” box.
 Heading and description of non-compliance.
 Criteria affected.
 Effects of non-compliance.
 Identified causes.
 Action proposed by the prime contractor in the “proposal” box.
The completed Form shall be numbered by the contracting authority’s management department.
After opening an NCF, the prime contractor analyses and researches the causes of the non-
compliance in question and makes a proposal to the contracting authority. There are two possible
scenarios:
Either
 The prime contractor proposes repairs to the contracting authority. A corrective action file
can then be opened by the prime contractor, in the form of a CF.
Or
 If repairs are impossible and the prime contractor proposes to leave the work in question as
is. In this instance, the prime contractor shall present the contracting authority with all
evidence to show that usage is possible as things stand.
In the previous two examples, a CF could (or must, depending on the case) be opened to accurately
characterise the operational and contractual repercussions expected.
For a Non-Conformity on a SIC item, the acceptance of Customer is required on analysis and
proposal of treatment made by the contractor.
6. ATTACHMENTS
7. REFERENCES

GDF 002(J)_R0

GDF 002 (J)_PMC AMP_Configuration Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GDF 002 (J)_PMC AMP_Configuration Management

Uploaded by

Copyright:

Available Formats

GDF 002(J) – PMC AMP – Configuration Management

(refer to GDD 002 – section 6.2.4)

Program / Project Director: Date

General Manager: Date

Rev. Description Author Date

Procedure No. Revision No. Date Author Page

Procedure No. Revision No. Date Author Page

Procedure No. Revision No. Date Author Page

Procedure No. Revision No. Date Author Page

3. DEFINITIONS AND ABBREVIATIONS

4. RESPONSIBILITIES AND AUTHORITIES

5. POLICY AND PROCEDURE

5.1 Products managed in configuration

checks, are referred to as configuration items.

Procedure No. Revision No. Date Author Page

5.2 Flowchart of the configuration management procedure

Identify configuration Issue RFI if required

PMC’s Control changes Change control

4 Technical Record configuration Configuration

5 PMC’s Review configuration For: Minutes of meeting

5.3 Configuration status

5.3.1 Basic configuration

5.3.2 Benchmark configuration

5.3.2.1 Information on the benchmark configuration

5.3.2.2 Changes in the benchmark configuration

 The cost control Manager.

5.3.2.3 Written and graphic documents

5.3.3 Applicable configuration

5.3.4 Actual configuration

5.4 Management of modifications

5.4.2 Types of modifications

mandatory Service (OS)

5.4.3 General process

5.4.4 Deviations impacting several entities / contracts

Procedure No. Revision No. Date Author Page

5.4.5 Contracts amendments

5.4.6 Follow-up of modifications / deviations

5.5 Configuration management and recording of the configuration status

5.5.1 General description of the configuration management process

5.5.2 Notification of a change

5.5.3 Change form

5.5.4 Building non-compliance form

Procedure No. Revision No. Date Author Page

You might also like