IDM UID

22F4E5
VERSION CREATED ON / VERSION / STATUS

19 Dec 2018 / 8.1 / Approved

EXTERNAL REFERENCE / VERSION

MQP Working Instruction

Project Change Procedure

This procedure defines the process of introducing changes into the ITER Baseline under
configuration control. Its purpose is to ensure that the proposed change is properly
documented, its impacts are identified and assessed and the decision concerning the change
status is taken at the appropriate level of authority. It aims to ensure an accurate and traceable
implementation of approved changes.

Approval Process
Name Action Affiliation
Author Salamon B. 19 Dec 2018:signed IO/DG/COO/CIO/CMD/DCC
Co-Authors
Reviewers Lee G.- S. 20 Dec 2018:recommended (Fast IO/DG/COO
Track)
Previous Altfeld H.- H. 11 Dec 2018:recommended v8.0 IO/DG/RCO/PCO
Versions Chiocchio S. 06 Dec 2018:recommended v8.0 IO/DG/COO/CIO/CMD
Reviews Elbez-Uzan J. 13 Dec 2018:recommended v8.0 IO/DG/RCO/SD/EPNS
Lamotte P. 13 Dec 2018:recommended v8.0 IO/DG/RCO/FPD
Maas A. 07 Dec 2018:recommended v8.0 IO/DG/CAB
Onozuka M. 10 Dec 2018:recommended v8.0 IO/DG/COO/CIO
Tada E. 07 Dec 2018:recommended v8.0 IO/DG/RCO
Zhao Z. 12 Dec 2018:recommended v8.0 IO/DG/QMD
Approver Bigot B. 20 Dec 2018:approved IO/DG
Document Security: Internal Use
RO: Fabre Nadine
Read Access LG: Quality Control Group, AD: ITER, AD: External Collaborators, AD: IO_Director-General, AD: EMAB,
AD: OBS - Quality Management Division (QMD) - EXT, AD: OBS - Quality Management Division (QMD),
AD: Auditors, AD: ITER Management Assessor, project administrator, RO, LG: CIE-TF, LG: Configuration
Man...

PDF generated on 20 Dec 2018

DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
 Change Log

Project Change Procedure (22F4E5)

Version Latest Status Issue Date Description of Change

v1.0 In Work 25 Feb 2005

v2.0 In Work 06 Oct 2005

v2.1 In Work 06 Oct 2005
v2.2 Approved 12 Oct 2005
v2.3 Approved 14 Jul 2006
v3.0 In Work 28 Jul 2008
v3.1 In Work 28 Jul 2008
v3.2 Signed 28 Jul 2008
v3.3 Signed 01 Aug 2008
v3.4 Approved 30 Sep 2008
v4.0 Signed 08 Jul 2010 This revised procedure incorporates the evolution of the Project Changes
management in ITER. It includes a new change level dedicated to minor
changes. It gives an overall description of the way Project Changes shall be
managed in ITER. The detailed working instructions related to this
procedure are provided in separate documents.
v4.1 Signed 15 Jul 2010 (i) The PCR template for level 0, level1, level 2 and minor changes, and (ii)
the PCR template for level 3 changes, have been merged into a unique PCR
template. This allowed simplifying the workflow of the procedure.
v4.2 Approved 16 Jul 2010 The workflow has been corrected as follows: level 0 changes accepted by
CCB1 for implementation shall be endorsed by the ITER Council first,
before being implemented in the Current Configuration.
v5.0 Signed 09 Jun 2011 Main changes:
(1) The management of design developments is added to the scope of the
procedure;
(2) Additional tracks are added to improve the speed of the process where
possible;
(3) The PCR implementation process is improved;
(4) The relationships between deviation requests and project changes are
clarified;
(5) The compliance with System Design Development, Earned value
management, schedule management, QA, safety, and regulatory
requirements is improved;
(6) Approval and applicability are separated to allow a better management of
the baseline.

Since the procedure now covers both baseline changes and baseline
developments, its name is changed into "Baseline Management Procedure".
v6.0 Disapproved 31 Jan 2012 The new version documents the current approval process of changes to the
ITER baseline under configuration control based on Project Change
Requests. It refers to Deviation Requests Procedure as both processes are
complimentary to each other.
v6.1 Disapproved 29 Mar 2012 The document addresses the comments accepted by R. Haange and R.
Hawryluk.
v6.2 Signed 30 Mar 2012 Mr Alekseev and Mr Bak added to teh reviewers' list on the DG's request
v6.3 Signed 12 Apr 2012 Reviewed by T. Shirao, K. Yamaura. M. Dentan and A. Alekseev comments
addressed. Mr Bak's oral comments considered and chief engineer role
included.
v6.4 Approved 12 Apr 2012 Comments from previous reviews considered and addressed whenever
possible. Table of contents updated. Formatting.
v7.0 Approved 03 Sep 2015 • Introduction of discussion and the value engineering studies/technical
activities to resolve identified issues prior to PCR process;

PDF generated on 20 Dec 2018

DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
 • PCR criteria;
• Co-responsibility of PCR for RO, system engineer and area manager;
• Modifications of reviewers;
• Reduction of the decision steps in the process;
• Executive Project Board role;
• Mandatory information for PCR approval;
• Full and well defined Implementation Plan mandatory before approval
• Mandatory information for PCR closure;
• Automatic closure when all items updated and documented;
• Minor PCRs approved by the CCB;
• Introduction of mandatory dissemination of information.
v7.1 Approved 14 Oct 2015 As requested by the reviewers:
- procedure for Deviation requests to the references;
- with a link in §7.1;
- indicate that the SRO is the IO-CT SRO;
- Clarification on roles and responsibilities for PT TRO;
- PBS RO explicitly mentioned as affected interfaces;
- Cost related PCR criteria replaced by the reference to ToR and
Management Plan for the Reserve Fund.
Version with track changes attached to the metadata.
v8.0 Signed 06 Dec 2018 Main changes vs current v7.1 version :

Introduced the Level 3 PCRs and associated CCBs

Removed the Minor PCR
Clarifications on the management of PCR families
Refinement of the flowchart, in particular to better incorporate DA’s
feedbacks before CCB decision to implement
Inclusion of the IO Configuration Management core team CMCT to support
the PCR process
Development of the roles and responsibilities
introduction of PLM as tool to produce PCR
v8.1 Approved 19 Dec 2018 Spelling corrections
Clarification of the need for CCB chairman to obtain DG's agreement prior
to dropping a PCR

PDF generated on 20 Dec 2018

DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
 Table of Contents

1 PURPOSE ..........................................................................................................................2
2 SCOPE................................................................................................................................2
3 DEFINITIONS AND ACRONYMS ................................................................................3
4 REFERENCE DOCUMENTS .........................................................................................4
4.1 REFERENCE DOCUMENTS....................................................................................................4
4.2 APPLICABLE DOCUMENTS...................................................................................................5
5 BASIC PRINCIPLES........................................................................................................5
5.1 MANAGEMENT OF COMPLEX CHANGES VIA PCR FAMILIES ...............................................5
5.2 PCR LEVEL CRITERIA ........................................................................................................6
5.3 CONFIGURATION CONTROL BOARDS (CCBS) ....................................................................7
6 WORKFLOW....................................................................................................................8
7 RESPONSIBILITIES......................................................................................................16
8 LINK WITH OTHER PROCESSES.............................................................................17
8.1 INTERACTIONS WITH THE DEVIATION REQUEST (DR) PROCESS .......................................17
8.2 INTERACTIONS WITH OTHER PROCESSES MANAGING MODIFICATIONS OF DATA IN ITER
PROJECT ...........................................................................................................................18
8.3 INTERACTIONS WITH THE ISSUE MANAGEMENT PROCESS ................................................18
8.4 INTERACTIONS WITH THE PROCESSES THAT MAY BE USED FOR PCR IMPLEMENTATION IN
THE BASELINE ..................................................................................................................18

9 OUTPUTS ........................................................................................................................19

Page 1 of 20
1 Purpose
Configuration Control is a set of actions and decisions (product and responsibility trees) meant
to permanently preserve and maintain the consistency between:
 Various configuration baselines of the same Configuration Item (CI);
 Successive configuration statuses of this CI;
 The items breakdowns linked to this item;
 The specimens of this item.
These actions and decisions are mainly dedicated to process voluntary and involuntary changes.
[Source: European Configuration Management Standard EN 9223]
NOTE: Configuration Control is the process of managing the product and related
documents, throughout the lifecycle of the product. An effective Configuration Control
Process ensures that:
 The correct authorized version of the document and its components are used at
all times;
 A clear audit trail of all proposed, approved or implemented changes exists.

The purpose of this MQP level-3 procedure is to present the procedure for Project Change
Requests (PCR) that is part of configuration control process1, in accordance with principles of
Configuration Management (CM) as described by upper level MQP procedures (QAP [1],
sect. 3.1).
This procedure ensures that any proposed PCR is:
 Properly documented to provide a clear audit trail and configuration status accounting;
 Reviewed and its impacts are identified, analyzed and assessed;
 Approved at the appropriate level of authority (see paragraph 5.2 PCR Level Criteria);
 Implemented accurately at all levels of documentation and structures up to the
manufacturing data and through all configurations (proper propagation) in a timely
manner;
 Traceable at all steps, from decisions regarding the change request through the
implementation and closure processes.

2 Scope
This procedure defines the process of controlling the changes to the ITER baseline through a
PCR.
It applies to changes proposed by ITER Organization – Central Team (IO-CT) or Domestic
Agencies (DA) that impact the ITER technical baseline, Overall Project Cost (OPC), Overall
Project Schedule (OPS), or the performance baseline as defined by the Performance Baseline
Change Control Procedure [7]. This includes the cases that require the use of the Reserve Fund
or change the allocation of funds between Procurement Packages. This does not apply to the
management baseline that is changed via the MQP Control Board dedicated process as defined
by the MQP Documentation Management Procedure [3].
This document is applicable to IO and DA staff, as well as any other party participating to this
process, performing activities impacted or potentially impacted by PCRs.

1To be noted: Change control is the process of identifying, documenting, approving or rejecting, and controlling
changes to the project performance and management baselines. [Source: Project Management Body of
Knowledge PMBOK of PM Institute]
Page 2 of 20
This procedure fulfils the requirements for CM as stated in the ITER Quality Assurance
Program (QAP) [1], ITER Project Management Plan (PMP) [2], ITER Configuration
Management Implementation Plan (CMIP) [4], the Procedure for configuration control, review
and audit [5] as well as the rules of the ITER Reserve Fund [22,23].

3 Definitions and Acronyms

The full list of definitions related to this process is provided in Configuration Management
Glossary [8]. The list of acronyms used in this procedure is listed below; see also the approved
list of ITER abbreviations [17].

Acronym Term

ASN Autorité de Sûreté Nucléaire

BCP Performance Baseline Change Proposal
CA Change Action
CCB Configuration Control Board
CI Configuration Item
CIO Central Integration Office
CM Configuration Management
CMAF CAD Model Approval Form
CM CT Configuration Management Core Team
CMD Configuration Management Division
CMM Configuration Management Model
CN Change Notice
DA Domestic Agency
DG Director General
DR Deviation Request
EPB Executive Project Board
FCR Field Change Request
GBS Geographical Breakdown Structure
IC ITER Council
IP Implementation Plan
IO ITER Organization
IO-CT ITER Organization Central Team
NCR Non-Conformity Report
OPC Overall Project Cost
OPS Overall Project Schedule
PA Procurement Arrangement (BtP : Build to
Print, FS : Functional Specifications, DD :
Detailed Design)
PBS Plant Breakdown Structure
PCMS Project Change Management System
PCR Project Change Request
PIA Protection Important Activity
PIC Protection Important Component
Page 3 of 20
PIM Project Issue Management
PLM Project Lifecycle Management
PPRE Project Plan and Resource Estimate
PT Project Team
RPrS Rapport Préliminaire de Sûreté
RO Responsible Officer
SCR Streamlined Change Request
WBS Work Breakdown Structure

4 Reference Documents
4.1 Reference documents
# Document Reference
[1] QAP – Quality Assurance Program 22K4QX
[2] PMP – Project Management Plan 2NCR3F
[3] MQP Documentation Management Procedure 7M445D
[4] Configuration Management Implementation Plan (CMIP) 27LHHE
[5] Procedure for Configuration Control, Review and Audit TZY7YV
[6] Procedure for the management of Deviation Request 2LZJHB
[7] Performance Baseline Change Control Procedure U24XQQ
[8] Configuration Management Glossary: Preliminary WS89U3
version
[9] Working Instructions for Applying Change Notices AN54UJ
(CNs) Based on Project Change Requests Procedure
[10] Procedure for management of Nonconformities 22F53X
[11] Working Instruction for Construction Field Change EBUK3B
Request
[12] Scope Management Procedure U2RADM
[13] ITER Planning & Scheduling Procedure 2DWMCW
[14] Project Controls Cost Estimating and Cost Control U33AUM
Procedure
[15] Streamlined Budget Change Control Process 323ERX
[16] Project Issue Management Procedure SSU96T
[17] ITER abbreviations 2MU6W5
[18] Sign-Off Authority for Project Documents 2EXFXU
[19] Design Change Control Procedure U2QPDS
[20] Procedure for the Approval of CAD data - CMM, 3D 2E3UCH

Page 4 of 20
 Models & Drawings
[21] Procedure for Implementation of the Reserve Fund S2JSZ5

4.2 Applicable documents

# Document Reference Revision
[22] Terms of Reference ITER Reserve Fund RYSMB3 V1.1
[23] ITER Reserve Fund Management Plan RZ2YUL V1.0
[24] Terms of Reference - Executive Project Board R7FJJ6 V1.0
[25] Management of the Modifications of Safety Files U34EB9 V1.2

5 Basic Principles
A PCR is a set of information that proposes a well-defined change to the ITER baseline. There
are 4 levels of PCRs with the criteria defined in section 5.2 of this procedure.
Level 0 and 1 PCRs are preliminarily approved for endorsement by the ITER Council (IC),
Autorité de Sûreté Nucléaire (ASN) or Director General (DG) and only after their final
acceptance the decision is fully valid. Level 2 PCRs are approved by Configuration Control
Board (CCB) II. Level 3 PCRs are approved by CCB III and CCB II is informed.

In some circumstances a draft PCR or a PCR that has yet to be approved, can be dropped by
the CCB Chairman’s decision after approval of his/her proposal by the IO DG. The proposal is
fully abandoned and cannot be implemented. The CCB is informed.
Additionally, an approved PCR can be superseded by one or several PCRs. In general, these
are approved at a later stage and this decision is contradictory or impossible to execute together
with the PCR that needs to be superseded. In this case, the PCR is closed even if its
implementation has not started or has been done partially. A clear description of the reasons for
superseding, of what has been implemented and what will not be implemented or will be
replaced by the superseding PCR(s) shall be recorded together with the justification on the
actions approved and implemented. The decision is communicated to the relevant CCB
members and all who were involved in the PCR processing.

5.1 Management of Complex Changes via PCR Families

Complex changes may be managed in a consolidated manner using several interlinked PCRs.
When such a change is proposed, the CCB Chairman gives his consent to create a PCR Family
and appoints a PCR Family RO to coordinate all relevant work.
The PCR Family is called by the number of the first PCR that becomes “Parent PCR”. The
PCR Family RO prepares the global PCR-XXX Family Implementation Plan where it indicates
how the whole complex change will be managed, by whom and by when every action shall be
accomplished. It shall include the list of coming possible individual PCRs with identified
scope, “Daughter PCRs”. This PCR Family implementation plan will be attached to the “Parent
PCR” so that to be approved at the same time as the “Parent PCR” is approved for
implementation. The CMCT then ensures that the PCR family implementation is kept on track
and liaises with the PCR family RO to launch each step of the PCR family implementation
plan.

Page 5 of 20
Every Daughter PCR needs to have the PCR-XXX Family reference in the title and be
interlinked. However, the individual PCRs within the family may be processed in different
times. Every daughter PCR is managed and controlled as any other PCR having its own
Implementation Plan, but consistent with the PCR-XXX Family Implementation Plan.
The lineage between Parent and Daughter PCRs is transparent and clearly defined. Their
progress can be tracked together providing an overview for the whole complex change and its
status at any time via PCR Family Implementation Plan.
The PCR Family Implementation Plan is acknowledged as complete by the CCB II Chairman
once all actions are implemented and all PCRs daughters are closed.

5.2 PCR Level Criteria

PCRs are defined across 4 levels, depending on the baseline impacted (for baseline levels see
[4]), and the level of involvement across various organizations.
Level 0 PCRs
Level 0 PCRs shall be used whenever level 0 baseline documents require to be modified or are
contradicted by the proposed change (for safety documents):

 Project Specifications
 Rapport Préliminaire de Sûreté (RPrS)
 Overall Project Schedule (OPS)
 IC Milestones
 Overall Project Cost (OPC)

To be noted that Project Plan and Resource Estimate (PPRE) is also level 0 baseline document.
It is updated on an annual basis with approved changes and submitted directly to the IC for
approval.
Level 1 PCRs
Level 1 PCRs shall be used whenever level 1 baseline documents require substantial2 changes
or are contradicted by the proposed change (for safety documents):

 Project Requirements & annexes

 Level 1 Safety baseline
 ITER Research Plan
 IO Work Breakdown Structure (WBS) as indicated in [7]
 Performance baseline level 1 as indicated in [7]

Level 2 PCRs
Level 2 PCRs shall be used when level 2 baselines documents are impacted.

Level 2 PCRs shall also be used when level 3 baseline documents are impacted and none of
the CCB III has authority on the entirety of the impacted items (for example when cost,
schedule or contractual impacts occur to manufacturing, procurement, construction, PT or DA
related activities)

2 Typos and corrections not changing the scope nor meaning of the information are not substantial
Page 6 of 20
Level 3 PCRs
Level 3 PCRs shall be used when level 3 baseline documents require changes and all of the
following apply:
1) The impact on systems is limited (within the authority of an existing CCB III) and
there is a confirmation by the interested parties of the absence of cost, schedule or
contractual impact (PA, Subcontract modification) for PTs, DAs and other interfaces;
2) Level 0,1,2 Baselines are not affected
Level 3 PCRs cannot impact, in any circumstances, regulatory requirements, performance,
safety, environment, reliability, operability & maintainability, traceability, interchangeability,
critical path or near critical path activity.

5.3 Configuration Control Boards (CCBs)

The DG of ITER Organization (IO) is responsible for the overall management of the Project
and making decisions related to the management of the Project.
At ITER, the body that has been delegated from the DG with the authority for change control
and Configuration Management (CM) is the CCB.
The CCB exists in different modules and for different levels of the Project.
For scope management the CCB modules are the following:
 CCB Technical (CCB Tech),
 CCB Project Issue Management (CCB PIM),
 CCB Project Performance (CCB PP),
 CCB Risks and Opportunities (CCB Risk).
For the decisions on technical and performance baselines changes, the CCB levels of
authorizing bodies are:
 Level-0 Committees: Science and Technology Advisory Committee [STAC]/IC /
Management Advisory Committee [MAC]/ASN: for level 0 baselines (IC baseline);
 Level-1 Committee: EPB: it has approval authority for level 1 baselines (DG baselines).
In addition, DG has been given authority from the IC to approve for implementation
PCRs involving the reserve fund
 Level-2 Committee: CCB II: it has approval authority for level 2 technical and
performance baselines (with technical support of CM Core Team (CM CT); In addition,
CCB II has authorization to approve for implementation a PCR involving a PAR
(Procurement allocation refinement). This approval being subject to final approval by
the IC
 Level-3 Committee: CCB III: for level 3 technical and performance baselines (Plant
Breakdown Structure [PBS] level) and with technical support of CM CT.

The CCB Technical module is supported by the CM CT. The CM CT is led by Central
Integration Office (CIO) and the members are IO representatives of key technical areas of the
Project, capable to provide technical expertise for the relevant scope.
The CM CT is responsible for Technical Issues (PIMs) management (including CCB PIM and
Info sessions), analysis of the proposed PCR and pre-impact assessment of every draft PCR,
recommendation for the PCR formulation and approval, content, level and RO. In addition, the
CM CT coordinates the full impact assessment of PCRs for CCB II and tracks the
implementation actions for approved PCRs. CM CT reviews and validates the evidence for
PCR closure.

Page 7 of 20
The CM CT decides on items proposed to be elevated from CCB IIIs to CCB II.
The PCRs are reported to the CCBs Technical at the steps described in section 6. Namely, CCB
decision is required to authorize PCR full impact analysis, PCR implementation, and PCR
closure.

6 Workflow

[Start 1] The need for launching the PCR process is signalized to CM CT.

The need for a PCR can be formulated in different ways: as a result of an Issue
Resolution Action Plan, as a result of a Field Change Request (FCR) [11], as a result of
a Non-Conformity (NCR) [10], as a result of a Deviation Request (DR) [6] or as a request
directly formulated and submitted to CM CT. A PCR is needed whenever a modification to
the baseline is necessary and this needed modification fulfills one of the PCR level criteria
(see section 5.2).

In every case, this need must be presented by the PBS initiator (who is by default the PCR
Responsible Officer) to Configuration Management Core Team (CM CT).

At this stage the PCR RO needs to provide:

 A Preliminary description of the change

 A preliminary justification for this change

 A Preliminary impact description

 A subsequent proposed PCR level

[2] PCR needed? CM CT authorizes to start the PCR process.

When a need is communicated, CM CT discusses the proposal within the Project in order
to get the information allowing the authorization to start the PCR process.

 If the CM CT confirms the necessity to create a PCR:

o CM CT opens a PCR form
o CM CT sets the title
o CM CT preliminary fills the PCR level
o CM CT identifies the PCR RO and notifies him
 If the criteria for a PCR creation are not met, the CM CT does not create a PCR (See
[End 1])
[End 1] Draft proposal is not created.
If the need for a PCR is not confirmed by CM CT, the draft proposal is not formalized
neither the PCR form created.

[3] PCR RO formulates the proposal. PCR status: Draft.

The PCR RO fills the PCR draft based on all available information.
Page 8 of 20
  The following information must be filled:
o The description of the change
o The justification / reason for the change
o The technical configuration from which there will be a departure
o The intended new technical configuration
o PCR proposed level
o The PCRs related to the current PCR (PCR family)

 In addition, the PCR RO must identify the impacted domains, whose Responsible
officer will be required to perform a pre-impact assessment.
A checklist with the most often impacted domains is made available by CIO/CMD

 Finally, the PCR RO must identify the impacted items (PBS/GBS nodes or
components, Configuration Items, procurement scopes)
Once the information is filled, the PCR RO notifies the safety RO and the CM CT that the draft
is completed.

[3a] Safety related DR is needed?

Safety RO confirms if the PCR draft requires modifications to Protection Important
Component (PIC) or Protection Important Activity (PIA) defined requirements and if a
safety related Deviation Request must be launched according to reference [25].

[3b] Proposed PCR RO raises the DR if not yet existing (follow up as DR procedure).
If the PCR draft requires modifications to Protection Important Component (PIC) or
Protection Important Activity (PIA) defined requirements, a safety related Deviation
Request must be launched before or at the same time as the PCR. ITER Safety assessment
must be provided (through the normal application of step [9]) before the PCR approval for
implementation.

[4] CM CT: PCR pre-impact can be launched? .

CM CT decides to launch the PCR pre-impact assessment based on the completed draft.
 If an amendment is required by the CM CT, the PCR is sent back to draft at step [3]
 If the PCR content is accepted by the CM CT, the CM CT authorizes the PCR for
Pre-impact assessment [5]
 The PCR RO and CMCT will make sure that adequate presentation of the PCR will
be done to the impacted domains so that they can perform the pre-assessment. This
information can be done via the CCB for particularly complex technical changes.

[5] Domains ROs (IO and DAs) review the draft PCR. PCR status: Pre-impact
Domains ROs (IO and DAs) make a pre-impact assessment: They provide the following
information:
Page 9 of 20
  Confirmation that they are indeed impacted
 If it is the case, rough assessment of the impacted activities
 Domains RO must provide in their rough assessment the expected impacted
Configuration items and procurement scopes (PA, In-Cash Contract)
A typical duration of 1 to 2 weeks is expected for this step.

[6] PCR RO finalizes the draft PCR.

PCR RO finalizes the draft PCR taking into account pre-impact assessment (addition /
removal of impacted domains/items)

[7] CM CT: PCR recommended for full impact?

Upon the information provided by the pre-impact assessment, the CM CT recommends to
the CCB Chairman the draft PCR for full impact status (Step [8]) or requests PCR RO for
further modifications related to the pre-impact assessment (Step [6]).

[8] CCB Chairman at CCB: PCR Full Impact launched and PCR number generated? PCR
status: Full impact
CCB Chair at CCB meeting reviews the draft PCR. He can decide to:
 Authorize the PCR for full impact analysis (Step [9]). The PCR number is
generated and its status changes
 Send the PCR back to Draft (step [3])
 Drop the PCR (Step [End 2])

[End 2] Draft PCR Dropped or go to step 3. Draft PCR status: Dropped

When CCB Chair does not agree to launch full impact analysis and generate the PCR
number, draft PCR is dropped at CCB meeting based on discussion involving PCR RO and
available information. The basis of dropping the PCR must be recorded.

[9] Domains ROs (IO and DAs) perform full impact analysis and create Change Actions (CAs)
of the Implementation Plan. PCR status: Full Impact
Domains ROs (IO and DAs) finalize impact analysis. They create Change Actions (CAs)
and assign them to a technical assignee and a reviewer.
A CA includes, at minimum, the following information:
 The technical assignee responsible for the action (usually the author of the data to
be modified or the person responsible for the contract that will require
modifications) and the reviewer;
 The object to be modified (can be a document, a PBS/GBS/WBS node, a PA, a
physical component, etc...);
 The description of the data and how it shall be modified if the PCR is approved
(requirement to be changed, design to be updated, manufacturing drawing to be
changed, PA content to be changed or make obsolete/replaced etc.). Whenever
possible the version “before” and “after” is to be provided;
 The due date for the required modifications.
Page 10 of 20
 All necessary actions to implement a PCR, if approved, are captured in the Implementation
Plan under the PCR RO’s coordination. For the PCR propagation, the domain RO (IO or
DA) needs to clearly define what actions are needed to be performed, with regards to his
scope but also to his suppliers (first tier).
The PCR implementation into documents, whenever convenient, is executed by using
Change Notices (CN) as defined in Working Instructions for Applying Change Notices
(CNs) Based on Project Change Requests Procedure [9].

[10] PCR RO improves the PCR and its Implementation Plan.

The PCR RO is in charge of checking that the list Change Actions is exhaustive and
consistent amongst the various contributing domains. He requests revision of Change
actions whenever required to reach this goal.

Once all change actions are satisfactory to him, the PCR RO:
 For PCRs with a financial impact:
o Collects the estimation of cost as per Project Controls Cost Estimating and
Cost Control Procedure ref [14] and schedule impact level including the
affected milestones in the schedule when applicable;
o Defines the financing strategy, including the possible transfer of scope
through a Procurement Allocation Refinement (PAR), the use of Reserve
Fund or Undistributed Budget, the creation of an “Earmarked Fund”, or the
use of internal budget as agreed with Finance. This information is made
available through the Finance department impact analysis.
 Estimates the risks and opportunities linked to the PCR;
 Validates the action plan for next step [11].

[11] CM CT: PCR and Implementation plan (IP) verified for no additional impact/change and
ready for review before approval for implementation?
The CM CT reviews the PCR and the synthesis information collected in step [10] to ensure
that changes to the ITER configuration are properly assessed and there is no future impact
foreseen. The verification shall state if there is a need for an additional delta-gate review
(specific actions to be set in that case).
 If the PCR requires modifications, CM CT sends the PCR back to step [9]
 If the PCR is ready for review, CM CT releases the PCR for review before
approval (step [12]), granting the minimum time allotted for a review (5 working
days), unless an urgent action is required.

[12] The affected CCB DA members review and make their position on the PCR.
The relevant CCB DA representatives shall provide their position on the PCR. The PCR
RO responds to every recorded comment and decides when the comment needs to be
addressed.

[13] CCB Chairman at CCB: PCR approved or escalated to upper level CCB?
CCB Chairman approves or not the PCR.

Page 11 of 20
The CCB chairman can:
 Approve the PCR for implementation, leading to step [15]

 Ask the PCR action plan to be reworked, leading to step [13a]

 Drop the PCR leading to step [End 3] with traceability on the reasons to do so.

 Escalate the PCR, leading to step [14]

[13a] PCR RO correct the PCR and its Implementation Plan

The PCR reworks the PCR content for presenting again the PCR for implementation, back to
step [13]

[14] Upper CCB Chairman at CCB: PCR approved for implementation?

The upper level CCB can :
 Approve the PCR for implementation, leading to step [15]

 Drop the PCR leading to step [End 4], with traceability on the reasons to do so.

 Ask the PCR action plan to be reworked, leading to step [14a]

[14a] PCR RO corrects the PCR and its Implementation Plan

The upper CCB Chair can request further modifications to the PCR and its Implementation
Plan before approving the PCR. Once done, step [14] (Upper CCB Chairman at CCB:
PCR approved for implementation?) is repeated.

When a PCR is approved in step [13] or [14]:

 The PCR content including Implementation Plan becomes valid.
 The relevant CCB members, the next upper level CCB members and other persons as
deemed useful, are informed about all decisions made by the CCB Chairman.
The decisions on level 3 PCRs shall be communicated to CCB II, similarly, level 2 PCRs
shall be communicated to EPB and level 1 PCRs shall be communicated to IC.
 Once approved at the relevant level of authority the described change is applicable. The
necessary implementation is on-going according to the Implementation Plan. The CCB
is informed about any necessary update of the Implementation Plan that shall be
authorized by the CCB Chairman. The technical and performance baseline
(scope/schedule/cost) implementations are running in parallel and may have different
closing dates.

[15] Change Actions assignees implement the PCR (close change actions) and execute
Implementation Plan PCR status: In Implementation
The implementation of a PCR must follow the Implementation Plan and CAs. The PCR
RO is responsible for the coordination of the PCR implementation, including the flow
down of the PCR to PAs and contracts performed by the relevant IO PA or Contract ROs.

Page 12 of 20
 CAs assignees in the IO and DAs are responsible for executing those actions as planned
and informing the PCR RO. All CAs of the Implementation Plan must be implemented in a
smooth, accurate and timely manner. If any of the CAs risks to be delayed or is delayed the
CA assignee shall inform the PCR RO at the earliest convenience. PCR RO shall report the
situation to CM CT to decide on the possible countermeasures and/or reporting to the
CCB.
Periodic reports on the PCR implementation are available.
The PCR implementation, whenever convenient, is executed by using Change Notices
(CN) as defined in Working Instructions for Applying Change Notices (CNs) Based on
Project Change Requests Procedure [9]. However, this mechanism cannot be applied for
PA amendment.

Specific case of need to update the implementation plan:

During step [15], if the PCR RO has the need to update the implementation plan, it is
required that he presents these modifications to CCB and obtains CCB approval.

[16] PCR RO notifies CM CT about readiness for closure.

The PCR RO monitors the evidence of implementation of the PCR in technical and
performance baselines. Once all actions are executed, the PCR RO submits the PCR for
full closure to CM CT.

[17] CM CT: PCR implemented and can be released for closure?

CM CT reviews the evidence for closure to ensure that changes to ITER configuration are
properly issued, implemented, verified, recorded and incorporated and validates it for
closure, leading to [END 5]
In case CM CT does not validate the PCR for closure, this leads to step [15].
Mandatory information for PCR closure
The technical, financial, and performance baseline (scope, schedule, cost) [12], [13], [14], [15]
implementations are running in parallel.
CM CT performs a holistic verification that:

I. On the standpoint of the technical baseline:

 Technical baseline documents were updated
 The updated technical baseline was duly propagated and made applicable to
downstream activities (PAs, Subcontracts, Construction, Commissioning, Operation)
 Already delivered physical components requiring modification (including spare parts)
were modified

II. On the standpoint of financial closure

 In the case of the use of Reserve Fund, a PCR can be closed only when the related
payments have been fully executed according to [23]. The IO finance department
follows this step according to [21].
 For Procurement Allocation Refinements, a PCR can be closed when it has been
approved by the Management Advisory Committee under delegation from the ITER
Council
 For other financial impacts, a PCR can be closed when the relevant budget actions are
taken
Page 13 of 20
The PCR ‘financial’ closure may be declared after the PCR ‘technical closure’. In these cases,
the ‘technical closure’ must include all elements except those mentioned in the section II
above.

III. On the standpoint of the performance baseline (with support from PCO):
 The Cost, scope, schedule documents/data were updated and related Performance
Baseline Change Proposals (BCPs) (if any) as defined in the Performance Baseline
Change Control Procedure [7] are completed;

[End 5] CCB Chair closes the PCR at the CCB meeting based on the presented evidence. PCR
status: Implemented (Closed) (End of the process).
When the PCR is fully implemented and the evidence recorded, the CCB Chairman closes
the PCR. The PCR gets the status “Implemented’. CCB members and other persons, as
deemed useful are informed.

Page 14 of 20
 Responsibilities

Domains ROs (IO and Change Action assignees (IO

PCR RO Safety CM Core Team CCB
DAs) and DAs)

S1. The need

for launching E1 Draft
the PCR proposal
process is not
signalized to created
CM CT 2.
Yes PCR needed? No
CM CT authorizes
to start the PCR
process
3. PCR RO
formulates the
proposal: PCR
status: Draft
No

3.a
4.
Safety related No Yes
CM CT: PCR pre-
Deviation
impact can be
Request
launched?
needed?
3.b PCR RO raises the
Deviation Request if Yes
needed and if not yet
existing (follow up as
DR procedure)

5. Domains /
PCA ROs (IO and
DAs) review the
draft PCR

7.
6. PCR RO
CM CT: PCR Yes
finalizes the draft
recommended for
PCR
full impact is ?
8.
No CCB Chairman at
No
CCB: PCR Full Impact
launched and PCR
9. Domains ROs number
perform full generated?
impact
assessment and
create Change
Actions (CAs) of Yes No
the
Implementation
Plan E2 Draft
PCR status: PCR
Formulation/ Full Dropped
10. PCR RO Impact
improves the PCR
and its
Steps

Implementation
Plan

11.CM CT:
PCR and IP ready for Yes
review before approval
for implementation?

12. The affected CCB

DA members review
and make their position
No
on the PCR

CCB Chairman at
CCB: PCR Approved
approved or
escalated to upper
level CCB?

Upper level
13a. PCR RO
corrects the PCR No No
and its
Implementation
Plan
E3. PCR
dropped

14. Upper CCB

Chairman at Yes
CCB: PCR
approved for
implementation?
14a. PCR RO 15. Change actions
corrects the PCR assignees
No No iimplement the PCR
and its
Implementation in the
Plan documentation and
E4. PCR execute
dropped Implementation
Plan
PCR status: In
Implementation
16. PCR RO notifies CM
CT about readiness for
closure
E5. CCB Chairman
17. CM CT : PCR closes the PCR.
implemented and can be PCR status:
released for closure ? Implemented (End
of the process)

Page 15 of 20
Flowchart 1: PCR process

Page 16 of 20
7 Responsibilities
Director General (DG)
The DG has the authority to make decisions on all PCRs. The DG may delegate this authority
to lower level CCB chairmen. However, for level 0 PCRs modifying the ITER parties’
procurement responsibilities, the approval of the MAC as delegated by the IC is also required.

PCR Responsible Officer (PCR RO)

The PCR RO is either IO or DA staff. The PCR RO is a person responsible for the definition of
a PCR, for preparation of the PCR Implementation Plan and its timely execution. They are also
responsible for ensuring the quality of the PCR submitted.
PCR RO prepares the draft PCR, identifies potentially impacted Domains and submits the draft
for decision to go for full formulation and impact assessment, approval for implementation,
closure or dropping; The PCR RO edits the proposal when necessary and coordinates the work
to be performed, liaises with all involved stakeholders in IO and in the DAs, defines the
Implementation Plan and ensures that the PCR is dealt with in a timely manner through the
whole process. PCR RO is supported by systems engineer and CM CT.
PCR RO of a PCRs’ Family has the responsibility of coordinating the work of the PCR ROs of
each PCR of the PCR Family, ensuring consistent and timely implementation of the full PCR
Family Implementation Plan.

Systems Engineer
The Systems engineer supports the PCR RO in performing duties throughout the full process.
In addition, the systems engineer, along with the PCR RO, ensures that IO and DA ROs are
involved in the process and support the definition of the change, when their scope is identified
as impacted.

Domains ROs (IO and DAs)

Once PCR RO (with systems engineer and CM CT support) identified the domains, the
responsible officers review the initial proposal.
Domains ROs can come from IO and DAs, be members of Project or Integrated Teams in
charge of the scope that is identified as potentially impacted or DA representatives.
They are for example responsible for safety, performance baseline, project requirements,
design integration, main impacted PBS, DAs or PTs impacted scope.
They review the PCR impact and create draft CAs for their relevant CA assignees that will
constitute the PCR Implementation Plan. Proposed CAs are reviewed in order to make sure that
they are clear and due exactly to the subject PCR.

CM CT
The CM CT is responsible for analyzing proposals for PCRs, the draft and formulated PCRs.
CM CT performs and coordinates works related to technical pre impact assessment and
formulation of every draft PCR (from IO and from DAs), full impact assessment of PCRs and
tracking of implementation actions for approved PCRs. CM CT manages PCRs in the database
through the full lifecycle. It opens the PCR forms and validates the PCR closure based on the
provided evidence of PCR implementation.
The CM CT manages CCB II Tech Info sessions and CCB II PIM module.

Page 17 of 20
CCB II and CCB III Members
CCB Members support the CCB Chairman in responsibilities.
IO members represent their departments’ positions and provide technical expertise when
needed in their relevant areas.
DA members are representatives that are authorized to present formal DA positions in CCB
discussions.

CCB II and III Chairmen

The CCB Chairman has the delegated authority from the DG to make decisions on PCRs
submitted to the CCB of the relevant level.
The CCB Chairman is responsible for ensuring that PCRs are managed in compliance with this
procedure and all other relevant rules and procedures.
The CCB Chairman authorizes the start of the PCR process and the creation of the draft PCR
based on CM CT recommendation. CCB Chairman assigns the PCR RO and, when necessary,
the supporting systems engineer. CCB Chairman decides if the draft PCR can be submitted to
full impact assessment. CCB Chairman can elevate the PCR to upper level CCB for decision
when deemed necessary.
The CCB II Chairman recommends level 0 and 1 PCRs to EPB and the DG for final decision.
The CCB Chairman validates the PCR closure based on the evidence of its implementation.
The CCB Chairman is in charge of the organization and control for the quality of the technical
matters of the Project that fall under his responsibility. Any technical issue or inconsistency in
the configuration that could require a change shall be brought to the CCB Chairman’s attention.

CAs assignees (IO and DAs)

CAs ROs that are part of the PCR Implementation Plan are ROs from IO and DAs. CAs ROs
are responsible for timely execution of CAs identified as planned and informing the PCR RO
about the progress and completion. If any of the CAs risks to be delayed or is delayed the
relevant CA RO shall inform the PCR RO at the earliest convenience providing also
justification for the unplanned situation.

8 Link with Other Processes

8.1 Interactions with the Deviation Request (DR) Process
Changes to a PIC or PIA defined requirements shall be assessed by ITER Safety Department
and safety related DR is required as per Procedure for the management of Deviation Request
[6]. They shall be approved at the right authority level, implemented in the baseline documents,
communicated and recorded in Design compliance matrix for PIC defined requirements.
Records of Project Change Requests and relevant documentary evidence related to
modifications of PIC/PIA or their defined requirements implemented during the design phase
via PCR process shall be stored and traceable in ITER relevant system.
Changes to PIC/PIA defined requirements raised during the manufacturing phase, shall be
assessed by the Nuclear Operator, agreed, implemented and recorded in the manufacturing
dossier (demonstration of compliance with defined requirements matrix) in the approved
project configuration.

Page 18 of 20
8.2 Interactions with Other Processes Managing Modifications of Data in
ITER Project
Changes to the data not being part of the baseline are managed via other existing processes, for
example via planned update of documents during the design development process.
Changes of a document via version control and normal approval process are defined in the
procedure Sign-Off Authority for Project Documents [18]. The modifications have to be
recorded in the Version Change Description. The level of approval is the same as for the
original document.
The notification about the new version of the document shall be received by everyone to whom
the document had been distributed before and who needs to know about it as having impact on
relevant area of his or her responsibility.
Urgent changes directed and authorized by the DG with all relevant documentation, also those
that fulfil PCR criteria, shall be recorded, stored and traceable in ITER relevant system.
Changes to the construction worksite baseline are managed via FCR process [11]. When an
FCR is classified as major, provision exists for IO-CIO to review the FCR to determine
whether the change proposal shall trigger a PCR, or whether the FCR can be progressed
through the FCR implementation process only.
If the FCR was initiated by an already approved PCR, then no further review is required. IO
CIO shall mark the FCR as “Proceed with FCR Process” with a comment referring to the
initiating PCR in the Decision Comments field.
If the FCR is not initiated by an already approved PCR but the CIO analysis concludes that the
change proposal shall follow the PCR process (though there is not a construction need to
expedite the approval of the change), the IO CIO shall mark the FCR for “Transfer to Other
Process: PCR” and then coordinate the transfer.

8.3 Interactions with the Issue Management Process

ITER Project issues are managed via Project Issue Management Procedure [16]. If the action of
Issue resolution Action Plan shall trigger a PCR, the Issue Action Plan RO submits the request
to follow the PCR process. The issue can be closed (“RESOLVED”) once the PCR is approved
for implementation. The Issue does not need to stay open until the PCR is completed.

8.4 Interactions with the Processes that may be used for PCR
Implementation in the Baseline
Once the PCR is approved, the proper implementation in the baseline may need to be executed
by using other existing processes, for example:
 New version of the data following normal approval process defined in the procedure
Sign-Off Authority for Project Documents [18];
 Use of CN when convenient [9];
 Use of BCP when required by Performance Baseline Change Control Procedure [7];
 Use of SCR when required by Streamlined Budget Change Control Process [15];
 Use of CMAFs when required by Procedure for the Approval of CAD data - CMM ,
3D Models & Drawings [19], [20];
 Use of FCRs as required by Working Instruction for Construction Field Change
Request [11].

9 Outputs
Name of Is there a Where this If IDM, How do Accountable Retention
the output need for output which you name team for the period (1)

Page 19 of 20
 template? If stored? document this file? availability of
yes, UID type? (naming the output
conventio
n)
Project N/A ICP PCMS N/A N/A Configuration Over the
Change Management project
Request Division lifecycle
PLM
(CMD)

PCR content shall be traceable at all steps of its lifecycle, from decisions regarding the change
request through the disposal process. Records of PCRs and relevant documentary evidence of
the implementation shall be stored in ITER relevant system and retained through the full ITER
Project lifecycle.
In addition, the periodic progress reports or the record of decisions of the meetings are to be
available to the whole ITER Project members.

Page 20 of 20