Discipline

Controls &
Assurance
Framework

Guide
ROYAL DUTCH SHELL plc
DCAF GUIDE

INDEX

SECTION 1 INTRODUCTION ................................................................................................... 2

1.1 BACKGROUND ........................................................................................................................ 2

1.2 ABOUT THIS GUIDE ............................................................................................................... 2
SECTION 2 CONTROL POINTS ................................................................................................ 3

2.1 CONTROL POINT HIERARCHY ........................................................................................... 3

2.2 MANAGEMENT OF CHANGE PROCESS ......................................................................... 3
2.3 GLOBAL DISCIPLINE HEAD: KEY DCAF RESPONSIBILITES ...................................... 4
SECTION 3 DISCIPLINE AUTHORITIES MANUAL ......................................................................... 5

3.1 TA LEVELS & KEY DCAF RESPONSIBILITIES .................................................................. 5

3.2 RECORDING OF TECHNICAL AUTHORITIES .................................................................. 5
SECTION 4 PCAP CREATION AND EXECUTION ........................................................................ 6

4.1 ROLES & RESPONSIBILITIES ............................................................................................... 6

4.2 PCAP CREATION PROCESS ................................................................................................. 7
4.3 PCAP EXECUTION PROCESS ............................................................................................ 10
SECTION 5 NON-SHELL OPERATED VENTURES AND CONTRACTORS ........................................ 14

5.1 NON-OPERATED VENTURES (NOVs) ............................................................................ 14

5.2 CONTRACT STAFF AND ENGINEERING CONTRACTORS ....................................... 16
SECTION 6 GLOSSARY ........................................................................................................ 17
APPENDIX 1 DELEGATIONS OF TA AUTHORITY ........................................................................ 19

APPENDIX 2 TA APPOINTMENT REGISTRATION ........................................................................ 20

APPENDIX 3 GUIDANCE ON PCAP SCALING ........................................................................... 21

APPENDIX 4 ESCLATION PATHS FOR DISPUTES ........................................................................ 23

APPENDIX 5 PCAP CREATION SESSION AGENDA .................................................................... 24

APPENDIX 6 TEMPLATE - QA REVIEW EXPECTATIONS ............................................................... 25
APPENDIX 7 ALTERNATIVE CONTROL POINT DEVELOPMENT & QA REVIEW FORMATS ................. 26
APPENDIX 8 DOCUMENT MANAGEMENT & WORLFLOW SYSTEM ............................................. 28

APPENDIX 9 BEST PRACTICE ASSURANCE................................................................................ 29

APPENDIX 10 ANNUAL ASSURANCE ON THE DISCIPLINE HEALTH ............................................... 30
APPENDIX 11 DISCIPLINE AUTHORITIES MANUAL ADMINISTRATOR .............................................. 31

1
DCAF GUIDE

SECTION 1 INTRODUCTION
1.1 BACKGROUND
The Discipline Controls and Assurance Framework (DCAF) is part of the quality assurance framework focusing on
business- and safety-critical decisions and deliverables (referred to as Control Points) in Exploration, Capital
Projects and Assets. The framework stipulates the Control Points that are to be considered by the project team
and facilitates effective collaboration between projects teams and Disciplines.

Quality Assurance (QA) is an important element of delivering affordable, credible and competitive projects as
well as for delivering safe and efficient production in our Assets. Assurance is all about helping to make sure that
we make the right promises and deliver against those. It is a supporting and value protecting/creating role. In
DCAF this translates to the assurance provision of Technical Authorities (TAs) that focuses on the intent of Control
Points, risk management and decision quality. The project team needs to ensure that the TAs are sufficiently on
boarded such that they understand the specific project risks, drivers and objectives and further ensure continuous
engagement with TA’s throughout the development of the critical business decisions and deliverables. The TA role
is an assessed competence that can be exercised independent of the position in the organisation, and therefore
the QA in DCAF may be provided by TAs from within the project team.

1.2 ABOUT THIS GUIDE

This guide must be read in conjunction with the DCAF Standard. The guide contains directions on how to create
and execute a Project Controls and Assurance Plan 1 (PCAP), management of deviations, escalations and other
key procedures in DCAF. Also it provides clarity about the key roles and responsibilities related to DCAF. It is
designed to help anyone in one of these roles to understand what is expected from them.

More information can be found on: http://sww.shell.com/dcaf

1
PCAP is applicable for the project ORP phases (Identify, Assess, Select, Define and Execute). Asset Controls and Assurance List (ACAL) is
applicable for the Operate phase. The term PCAP is interchangeable with ACAL throughout this document.

2
DCAF GUIDE

SECTION 2 CONTROL POINTS

Control Points in DCAF are critical Functional requirements with multi-disciplinary content that are globally
applicable and originate from existing Group/Business Standards, Manuals or established in the Discipline. For
each Control Point all contributing Disciplines are specified; per Control Point there is one single Accountable
Discipline (the accountable Technical Authority or ATA) and contributing Responsible Disciplines (responsible
Technical Authorities or RTAs) defined.

Control Points support key project decisions and are directly linked to one or more Controls defined in the
governing standards. Controls define critical risks to business and safety outcomes and describe the intent which
needs to be met in order to manage those risks. A Control Point, under the DCAF Framework, assures that the
intent has been met in order to effectively manage the critical risks to business and safety outcomes. The final
evidence for the development of the Control Point is recorded in deliverables.

Control Points in DCAF are selected based on their multidisciplinary and integrative nature. DCAF is not a one-
stop shop for all mandatory requirements originating from our governing standards.

2.1 CONTROL POINT HIERARCHY

In DCAF, Control Points are categorized as either scalable or non-scalable. The non-scalable Control Points are
expected to be applicable (by default) for all projects, and as such quality assured by TAs regardless of the
project risk profile and assurance level. Note that only a small set of Control Points are marked as non-scalable
per ORP phase.

Scalable Control Points are less generic and need to be made commensurate with the project risk profile; project
teams together with the appropriate Discipline/Functional representatives should consciously de-select or roll-up
scalable Control Points. The non-scalable Control Points can act as the “masters” allowing hierarchy and structure
to be established in the PCAP (see appendix 3 for more details on PCAP scaling).

Non-Scalable Control Points Scalable Control Points

 Are generically applicable  No formal approval is required to de-select or
 Cannot be deviated2 or marked as ‘N/A’ without deviate a scalable Control Point
a formal TA1 approval3  May not be applicable for all project profiles
 Are expected to be always quality-assured by TAs  Selected based on value drivers, key project
 Cannot be rolled-up into other Control Points decisions and risks

2.2 MANAGEMENT OF CHANGE PROCESS

Changes in the list of Control Points for the DCAF framework are administered through the DCAF Change Panel.
As the Control Points in DCAF have multi-disciplinary content, the Global Discipline Head (GDH) representing the
Discipline holding the ATA role per Control Point must consult with other impacted Disciplines around the change
management.

The DCAF Change Panel4 meets twice a year, vets the Control Points for consistency and advises the DCAF
Decision Executive (DE) for final approval on the proposed changes. The approved changes are released to the
DCAF Global Administrator, who publishes them in the online DCAF Tool. The supported changes are also
published on the DCAF website for audit trail purposes. Deadlines for submitting change requests are made
available on the DCAF website.

2
Control Point is deferred to the next phase or the default ATA role is swapped with another Discipline
3
TA1 of the Discipline that holds the ATA role for the non-scalable Control Point
4
DCAF Change Panel comprises of functional representatives appointed by their Function

3
DCAF GUIDE

Examples of proposed changes to the list of Control Points featuring in DCAF are:

 Introduction of a new
Control Point or removal of
an existing one
 Moving a Control Point from
one ORP phase to another
 Changes to TA levels by a
Discipline
 Merging Control Points

2.3 GLOBAL DISCIPLINE HEAD: KEY DCAF RESPONSIBILITES

GDHs are appointed by the Head of their respective global (technical) Functions. They lead the global Discipline
community and with respect to DCAF are accountable for their Discipline specific content management in DCAF.
This includes:

1. ensuring that the Control Points are fully aligned with the governing standards and the driving requirements
therein, and
2. creating and maintaining concise but comprehensive supporting guidance material and best practise
examples for the Control Points that their Discipline is accountable for (this can be done through the Shell
Enterprise Encyclopedia5 which contains references to documents, processes, templates, examples etc.). To
do so, they usually appoint a number of Principal Technical Experts or Subject Matter Experts to manage and
maintain the supporting information quality.

The following changes are entirely within the remit of the GDHs and do not require approval from the DCAF
Change Panel:

 Updates to supporting information (Shell Encyclopedia) of a Control Point for which the Discipline is
accountable for,
 Updates to Control Point descriptions (DCAF central team needs to be informed), and
 Renaming a Control Point for which the Discipline is accountable (DCAF central team needs to be informed)

Role Key DCAF Responsibilities

 Communicate changes related to DCAF to their Discipline community globally
GDH  Set the multi-disciplinary, business-critical Control Points and the appropriate TA level
 Ensure maintenance of information supporting Control Points

Note: GDHs are expected to define the global expectations for the competency of TAs at levels 1, 2 and 3
respectively as per the BMS procedure “Manage Technical Authorities” and ensure that appropriate competence
development resources (training, knowledge management) are in place as per the competence section of the
HSSE & SP Control Framework.

5
Shell Wikipedia to be replaced by Shell Encyclopedia platform. After this transition, Wiki pages of Control Points will be referred to as
Encyclopedia pages

4
DCAF GUIDE

SECTION 3 DISCIPLINE AUTHORITIES MANUAL

The Discipline Authorities Manual (DAM) contains a list of Discipline professionals (TAs) that are positively
assessed against certain competence levels, and as such have been assigned a Technical Authority Level. The
authority level governs their involvement in the DCAF assurance process and the type of Control Points they are
authorized to assure on behalf of their Discipline.

3.1 TA LEVELS & KEY DCAF RESPONSIBILITIES

TA Levels Key DCAF Responsibilities

 Ensures that DCAF Standard is correctly applied in his/her entity (quality of
TA0 implementation and periodic compliance checking)
 If required, takes decisions on escalated inter-Discipline disputes
 Approves deviations of Non-Scalable Control Points
 Provides annual assurance on the Discipline health (to the TA0 and GDH)
TA1  Supports changes proposed by the project on the Discipline RTA involvement. e.g.
lowering or removal of RTA level, adding RTA for a Discipline
 Provides integrated assurance to the project for Control Points for which he/she is
designated ATA6. Provides his/her Discipline input to other ATA(s) for integrated
assurance as RTA
 Provides input during PCAP creation
 Supports changes proposed by the project on the Discipline RTA involvement. e.g.
lowering or removal of RTA level, adding RTA for a Discipline
TA2
 Provides integrated assurance to the project for Control Points for which he/she is
designated ATA. Provides his/her Discipline inputs to other ATA(s) for integrated
assurance as RTA
TA3  Provides his/her Discipline inputs to other ATA(s) for integrated assurance as RTA

3.2 RECORDING OF TECHNICAL AUTHORITIES

Per the Business Management System procedure “Manage Technical Authorities”, organizations, which have
established their TA Framework and appointed their Technical Authorities, shall record and maintain their list of
TA’s in an easily accessible controlled electronic format. Whenever possible, the Discipline Authority Manual
(DAM) section of the Discipline Controls and Assurance Framework Tool shall be used as the TA repository

Note: Although the DCAF Tool serves as the single online TA repository, it is worth recognising that DCAF is just
one of the standards that make use of the TAs listed in the various DAMs. In DCAF the prime role of TAs is to
provide quality assurance. The procedures in other (Group-) standards and manuals may require them to provide
quality control and formal sign-off on specific requirements or derogations (e.g. derogations on DEPs).

6
See section 4 for ATA and RTA role explanation

5
DCAF GUIDE

SECTION 4 PCAP CREATION AND EXECUTION

The PCAP is the project specific outcome of the DCAF application. The quality and selectivity of the PCAP is
critical to the successful (value-adding) operationalization of DCAF. It focuses on the assurance effort to those
areas and control points where the risk and need for decision quality are highest, and where the project would
benefit most from Functional assurance. The PCAP Creation session requires close collaboration between project
and the appropriate Functional experts, to generate a well-tailored list of Control Points from the DCAF inventory,
using a pre-scaled PCAP archetype7 as a starting position.

The PCAP is essentially a list of carefully selected Control Points covering the respective ORP phase with the
names of the TAs assigned to each of them, who are responsible for providing quality assurance. It is the prime
responsibility of the Technical Lead8 to tailor the contents of the PCAP according to the scope, complexity and
risk profile of the project; producing a truly well-tailored PCAP. A well-tailored PCAP means that only Control
Points that link to the project’s premises, risk profile, and value drivers are selected that support critical project
decisions.

Standard Operating Procedures (SOPs) have been developed to guide a uniform and structured “way of
working” in effectively applying DCAF. Two distinct SOPs for PCAP Creation and Execution have been
developed based on the global best practices for DCAF application in projects. It is therefore strongly
recommended to follow the SOPs when DCAF is applied. Refer to section 4.2 and 4.3 for further details
regarding the SOPs.

4.1 ROLES & RESPONSIBILITIES

The table below provides an overview of the key roles and responsibilities involved in the PCAP Creation and
Execution process.

Role Key DCAF Responsibilities

 Approves final PCAP (whilst ensuring that the PCAP Creation SOP has been followed)
DE
 Holds final decision accountability on Control Point
 Accountable to produce a well-tailored PCAP at the beginning of the ORP phase
BOM
 Responsible for obtaining PCAP approval from the DE
 Oversees and facilitates the PCAP Creation and Execution processes
Technical
 Responsible for PCAP creation and execution using the SOPs
Lead
 Responsible for obtaining TA1 approval for deviating from non-scalable Control Points
 Responsible for decision-making and risk management of the project under single point
Project Team
accountability of the DE
Control Point
 Accountable for development and Quality Control of the assigned Control Point
Owners
Document
 Responsible for document management
Controller
 Act as Functional experts and provide input around selection of appropriate Control
Points that would improve project value and help better manage risks
TAs
 Provide Quality Assurance on assigned Control Points
ATA: Accountable for providing integrated assurance based on RTA’s input
RTA: Provides quality assurance input to the ATA for their Discipline perspective

7
A PCAP archetype is a pre-scaled template based on Line of Business, Project Assurance Level and scope
8
Depending on the ORP phase, the Technical Lead can be the Exploration Lead, Project Manager, FEDM or Asset Manager. The Technical
Lead can delegate his/her tasks (e.g. to a Quality Engineer or Project Engineer) but remains accountable

6
 DCAF GUIDE

Note: Double-hatting allows an individual to provide self-assurance to his/her work, meaning the contributor of a
Control Point can also provide assurance as an ATA or RTA. The self-assurance option should however be a
conscious choice based on team capacity, risks and lateral learning and must be taken during the PCAP
Creation session with the Functional expertise and BOM / Technical Lead involved. It may be easiest to assign
the TA role to staff within the project team, who holds the required TA capability. This keeps the assurance
provision “in house” i.e. within the immediate sphere of control of the business opportunity manager, intimate and
efficient. However, this also potentially diminishes the value-add and effectiveness of the whole process, where
DCAF is used then primarily as an administrative tool that checks and formalises the capability already residing
in the project team and records the level of self-assurance that is conducted. The recommended alternative would
be a very conscious decision around the need for external assurance by a TA, which is expected to bring a
complementary set of skills and experience to the project team and as such significantly improves the decision
quality. The latter behaviour and more conscious use of DCAF would really improve the leverage of our
corporate experience and knowledge base.

4.2 PCAP CREATION PROCESS

This section provides an overview of the PCAP Creation process. The PCAP creation SOP can be found on the
DCAF website. Alternatively, click on the link PCAP Creation SOP to download the SOP.
STEP 1 STEP 2 STEP 3 STEP 4
CREATE FIRST PASS PCAP BY ORGANISE PCAP RUN PCAP CREATION COMPLETE
(DE)SELECTING CONTROL POINTS CREATION SESSION SESSION WELL-TAILORED PCAP

Complete assignment of
Refresh DCAF knowledge Invite participants Record participants TAs to Control Points
(if required)

Retrieve PCAP template Align understanding of Request assigned TAs to

from DCAF Tool Send out pre-read
Project Premises accept role

Incorporate project details Prepare for PCAP Creation Obtain TA1 approval on
Create well-tailored PCAP
in PCAP Session deviations

Assign TAs to selected

Create Project TA List Seek DE Approval
Control Points

Assign Control Point

Select Control Points owners to selected Publish DE approved PCAP
Control Points

STEP 1: CREATE FIRST-PASS PCAP BY (DE)-SELECTING CONTROL POINTS

A first-pass PCAP should be created before the PCAP Creation session by the Technical Lead in collaboration
with the BOM (and optionally the Project/Quality Engineer). This provides a balanced opening position for an
efficient PCAP creation session. A first-pass PCAP is created by scaling the PCAP archetype obtained from the
online DCAF Tool. The tool contains a number of archetypes that help to create a good starting position for the
scaling effort based on line of business and assurance level. A weighted decision must be taken for each Control
Point whether marked as either select, roll-up, deviate, or N/A with brief justifications recorded (see appendix 3
for guidance on PCAP scaling).

STEP 2: ORGANISE A PCAP CREATION SESSION

A PCAP creation session needs to take place with the key Functional representatives (TA2s from Functions that
cover the critical project risks) and project team members to ensure that the right Functional expertise is leveraged
and key risks or knowledge gaps are not overlooked by the project team. Besides the Functional representatives,

7
DCAF GUIDE

the Technical Lead and the BOM are mandatory participants. The Technical Lead is responsible for selecting the
Functional representatives to participate in the PCAP scaling session which can be done in three steps described
below:
1. Identify the appropriate key Functions that contribute to the Opportunity maturation and hence need to
participate in the PCAP Creation session.
This should be done considering the project risks and value drivers, using the OAP and ORS trigger list
as aids for selection.
9
2. Select the appropriate individuals to represent these key Functions.
Choose 1 or 2 TA2(s) from each of the selected key Functions
 For a Function with multiple Disciplines, choose an individual from a Discipline that can represent
his/her Function best. Multiple Discipline representatives from one Function can be selected if it is in
line with the project risks.
3. Consult Discipline TA1s (as per DAM) if TA2s for the selected key Functions cannot readily be identified.
The TA1 should then select a suitable TA2 to represent the Function in the PCAP creation session

Once the Functional representatives have accepted their roles and the list of participants is finalised, the
Technical Lead sends out pre-read materials to all participants. This is done at least two weeks in advance before
the session to ensure that the participants have sufficient time to prepare for the PCAP Creation session. The pre-
read typically includes:

 First-pass PCAP (including links to OAP and Risk & Opportunity Register)
 Project Premise Document
 PCAP Creation Session Agenda10

STEP 3: RUN A PCAP CREATION SESSION

A well-tailored PCAP should be developed in collaboration with the project team and Functional representatives
(TAs) to stimulate co-ownership and early Functional involvement. The PCAP Creation process benefits from
constructive dialogue between the project team and Functional experts around the selection of critical Control
Points that will improve project value and result in better risk management.

The first-pass PCAP must be critically evaluated by assessing the selected, rolled-up, deviated and ‘N/A’ Control
Points and adjusted as appropriate; whilst ensuring valid justifications are provided in line with the project
premises and risks. Note that the assignment of TAs to all selected Control Points has to be completed to finalize
the PCAP. It is ultimately the responsibility of the Technical Lead to ensure completion of TA assignments outside
the session as it might not always be possible to complete this during the PCAP Creation session.

Conflicts that arise during the PCAP Creation session must be effectively resolved to prevent disruption of the
session. Escalation of a disagreement provides a solution if a dispute between individuals in the application of
DCAF cannot be resolved. The escalation path described in appendix 4 can be followed if no consensus is
reached (during or outside the PCAP Creation session). Note that the resolution of disagreements ultimately falls
with the DE (as final holder of decision accountability for all project decisions).

STEP 4: COMPLETE WELL-TAILORED PCAP

Prior to seeking DE approval, all selected Control Points must have TAs assigned to all the RTA and ATA required
roles. The Technical Lead (or delegated) informs the assigned TAs and request their acceptance for taking the
role. In case of any deviations on non-scalable Control Points, the Technical Lead is responsible for obtaining the

9
As a default, the individuals must be at TA2 level.
10
Refer to appendix 5 for a PCAP Creation session agenda.

8
DCAF GUIDE

respective TA1 approval(s). Once the above mentioned actions are completed, the PCAP Summary Report
(Functionality in the PCAP template) is sent to the DE for approval.

The following sub-sections provide guidance on the key tasks to be carried out during PCAP Creation Process.

4.2.1 CONSIDERATIONS IN SELECTING A CONTROL POINT

Control Points are selected based on
discussions between project team
members and Functional (Discipline)
representatives during the PCAP
creation session (and possibly in
follow-up engagements). The
flowchart provides general guidance
on the Control Point selection. Refer
to appendix 3 for guidance on how P
to ‘Select’, ‘Mark N/A’, ‘Deviate’, or
‘Roll-up’ a control point.

4.2.2 SPLIT CONTROL POINTS

The selected Control Points can be split into two or more Control Points that must be developed and assured
separately. This option is predominantly applicable for larger projects with distinct scope elements to split a
Control Point over the work streams. For example, an upstream offshore development with a gas terminal on
land can have the Basic Design Engineering Package split into separate documents covering the distinctive
scopes and with different TAs involved to provide quality assurance.

4.2.3 PROJECT SPECIFIC CONTROL POINTS

In practice, Control Points in DCAF cover a wide range of project risks and decisions globally. However,
specific Control Points such as those that stem from local legislation or Joint Venture (JV) requirements can justify
the inclusion of project specific Control Points which benefits from TA quality assurance from multiple Disciplines.

4.2.4 INVITATION OF FUNCTIONAL REPRESENTATIVES

The Technical Lead invites the appropriate Functional representatives to the PCAP Creation session and can use
the ORS Trigger List to determine which Functions should be present. Note that the Functional representatives
ought to be fully aware that they will have to represent their Function during the session before accepting the
role.

4.2.5 GUIDANCE ON TA ASSIGNMENT

TAs must be assigned to all selected Control Points during (or shortly after) the PCAP Creation session to complete
the PCAP. A weighted decision is required when assigning TAs (RTA and ATA) for each Control Point by either
choosing:

1. An individual within the project team who holds a TA certification

2. An individual external to the project team who:
 holds a TA certification
 brings a complementary set of skills and experience to the team, thereby significantly improving the
decision quality

Note 1: The default TA level set in DCAF is the minimum level required to provide quality assurance on the
corresponding Control Point. It is therefore allowed to assign a TA from a higher level without TA1 approval.

9
DCAF GUIDE

However, assigning a TA below the default minimum assurance level is possible but is deemed as a delegation
(see appendix 1).
Note 2: DCAF holds both a Discipline and a Functional representation. For example, Functions such as
Discipline Engineering are represented on a Discipline level (e.g. PFAS, CSO and Electrical Engineering);
whereas Maritime, HSSE&SP and Wells are represented on a Functional level. However, only one TA should be
assigned per required TA role at Control Point level (ATA/RTAs) to represent their Discipline or Function. It is
expected that the assigned TA can provide assurance on behalf of the required Discipline or Function on the
Control Point.

4.3 PCAP EXECUTION PROCESS

This section provides an overview of the PCAP Execution process. . The PCAP execution SOP can be found on
the DCAF website. Alternatively, click on the link PCAP Execution SOP to download the SOP.
STEP 1 STEP 2 STEP 3 STEP 4
INCORPORATE CONTROL
DEVELOP SELECTED QA OF FINALIZE CONTROL POINTS
POINTS IN OVERALL PROJECT
PLANNING CONTROL POINTS CONTROL POINTS BY TAs AND CLOSE-OUT PCAP

Inform and clarify Control

Develop Control Points (in RTA provides Discipline Produce final version of
Point owners of delivery
collaboration with TAs) Assurance Input Control Points
accountability

Link Control Points to ATA provides Integrated

Inform TAs of review Issue finalized control
Decision-Based Roadmap & Assurance and Assurance
timing points for use
Project Planning Risk Rating

Align QA review
Initiate review cycle Resolve High Risk Rating Close-out PCAP
expectations

Prepare document
management system

STEP 1: INCORPORATE CONTROL POINTS IN OVERALL PROJECT PLANNING

The Technical Lead informs the Control Point Owners (within the project team) assigned to the selected Control
Point of their delivery accountability, ensuring alignment of roles and responsibilities. It is recommended to link the
Control Points to the project’s decision-based roadmap and to update the project planning accordingly. The
PCAP template has a Functionality to export the PCAP content into planning tools such as Primavera and MS
Project.

At this stage it is recommended to define expectations such as review timing and document management system
which will be used for the quality assurance comments to ensure clarity around roles and responsibilities during
the PCAP execution. For detailed guidance on setting up review expectations, see appendix 6. Alternate Control
Point development and quality assurance formats are described in appendix 7. Guidance on selecting an
appropriate document management system can be found in appendix 8.

STEP 2: DEVELOP SELECTED CONTROL POINTS

The Control Point Owner (within the project team) is accountable for the delivery of the Control Point; ideally pro-
active engagements are initiated by the Control Point Owner with the ATA during the development of the Control
Point to validate decisions in order to avoid surprises and unnecessary review cycles late in the process. The
Control Point owner is expected to have a firm version (decision(s) clearly documented, risks appropriately
addressed and sound mitigations proposed) before initiating the QA review cycle. The Document Controller

10
DCAF GUIDE

uploads the draft Control Point in the document management system for audit trail purposes. It is advised to
inform the TAs at least 2 weeks before the Control Point deliverable is issued for QA review.

STEP 3: QA OF CONTROL POINTS

The role of TAs assigned to selected Control Points in the PCAP is to provide quality assurance, ensuring that the
 key project decisions captured in the Control Points are sound, and
 project risks are managed/mitigated.
Risks are to be managed to an acceptable level and the TA should consider the effectiveness of the
mitigation measures selected.

The focus of the QA process should be on the decision quality and whether the control intent of the Control Point
is met. Where relevant, the TA can decide to consult other TAs, SMEs or PTEs within their Function/Discipline.
The TA quality assurance is ultimately a set of review comments comprising of observations and
recommendations.

Below is a highly simplified example on providing quality assurance on a Control Point which supports a project
decision. This is done by considering key factors such as project objective, risks and value drivers.

Project Objective Provide transport for four persons from A to B

Value Drivers Risks Control Point Project Decision

 Arrive on Time  Late Arrival Selection of (Shell approved)

 Safety  Accident Transport Taxi
(Injury/Death)

Assurance In practice, the quality assurance is not for the car in general. Rather, the intent of the assurance
Comments is to analyse whether the selected option (in this case, a taxi) meets the project objective while
mitigating the risks and preserving the value drivers.

Note: The objective of a quality assurance by TAs is not:

 To take charge of the Control Point quality and delivery. These responsibilities rest within the project team
(with the Control Point owner)
 A means to demonstrate disagreement with the decision but to enhance collaborative behaviours between
Functions/Disciplines and projects to enable the project to deliver its promises and value

RTA AND ATA ROLES

The role of the RTA is to provide input and perspective from his/her Discipline into the integrated quality
assurance of the ATA. The RTA should only focus on the parts of the Control Point that are relevant to his/her
Discipline. The RTA provides his/her review comments preferably in the project’s document management and
workflow system within the agreed review period. These review comments will then be integrated by the ATA.
The RTA gives the criticality of his/her comments explicit with an assurance risk comment (explained in the next
section).

The role of the ATA is to provide integrated quality assurance on the Control Point by taking the assurance review
comments of the RTAs into account. Note that each final review comment must have an assurance risk rating. As
the ATA is responsible for providing integrated assurance, he/she must obtain Discipline input from all RTAs and
resolve any inconsistencies between the review comments of the RTAs. If no agreement on the solution of
inconsistencies is reached, the escalation path described in appendix 4 should be used.

11
DCAF GUIDE

ASSURANCE RISK RATING

The assurance risk rating clarifies the criticality of the assurance review comments. A description of the assurance
risk ratings is below.

Note 1: The assurance risk rating is not linked to the project risk matrix.

It is mandatory for the project team that concurrence takes place on any given High Ratings with the ATA, ideally
within a week. The outcome of the concurrence can be either:
 include the QA review comments and no new QA review cycle initiated
 include the QA review comments and initiate a new QA review cycle (the ATA will review the revised Control
Point)
 ATA agrees that control intent is met (after discussion with project team) and changes the risk rating to a
‘Medium’ or ‘Low’ rating

Note 2: The expectation is that resolutions to high assurance risk ratings are sought between ATA and project.
However, only an ATA can close-out the high risk rating. By exception, if no resolution is reached, the escalation
paths described in appendix 4 should be followed. In principle, all high risk ratings should be closed out by the
end of the ORP phase. By exception, the project can decide not to include a high assurance risk comment in a
Control Point, so the ‘High’ risk comment stays open. This should be a conscious, ‘eyes wide open’ decision
taken by the project team (ultimately the DE).

Note 3: Accountability for Quality Control lies with the project and is not managed through DCAF.

12
DCAF GUIDE

STEP 4: CLOSE-OUT PCAP

Control Points are “finalized” and all high risk ratings are either resolved with the ATA or the risk accepted by the
project (ultimately by the DE). Note that all high assurance risk ratings will be validated at the stage gate review,
thus it is mandatory for the high risk rating to be resolved or the risk accepted by the DE before the PCAP can be
closed-out at the end of the project phase.

13
DCAF GUIDE

SECTION 5 NON-SHELL OPERATED VENTURES AND CONTRACTORS

5.1 NON-OPERATED VENTURES (NOVs)
Non-Shell controlled projects or non-operated assets (NOVs) are expected to have a DCAF equivalent to ensure
(technical) quality assurance. The Shell NOV governance team should use DCAF to assess the quality assurance
framework used by the JV or the operator and use its influence to mitigate the shortcomings that create intolerable
risk(s) to Shell. How this is done, depends on the role Shell has in a NOV setting. Using the following NOV
governance archetype classification, two scenarios are identified on how to apply DCAF:

1. Scenario 1: Applicable to [Archetype 4]

DCAF is the standard chosen in the NOV and therefore should be applied in the same way as in a Shell
Operated Venture (SOV)-setting, except for one element: Discipline Authorities Manual (DAM). Any
significant gap in the DAM related to lack or missing competences should be addressed, possibly by using
specific Shell expertise. The NOV’s management and board are solely responsible for the appointment of
their TAs. Where Shell staff have been appointed in a NOV TA role, they act in an advisory capacity. Legal
authority to take decisions and undertake activities in NOVs resides with the NOV management.

2. Scenario 2: Applicable to [Archetype 1, 2 and 3]

First and foremost the focus should be on compliance with the JV’s processes and standards for quality
assurance. But in case the Operator has a less defined assurance approach in place, the Shell NOV
governance team is expected to create a NOV PCAP. This should be done by adopting a risk based
approach in assessing the extent of the NOV assurance framework, identifying exclusion and gaps
compared to Shell’s requirements (e.g. requirements for GIP, reserves booking, (shareholder) risks or scope

14
DCAF GUIDE

excluded by the NOV or social performance) that require mitigation. Ideally, there is no duplication between
the Controls Points identified by the Operator and Shell (but assure that Shell NOV governance is satisfied).
NOV deliverables with evidence of equivalent Discipline control and assurance should be considered
acceptable. However, the Shell Governor may still find reasons to complement the Operator’s assurance
approach with some Shell-only Control Points (depending on the level of influence that Shell has over the
Operator) and/or build-in some conscious duplication for monitoring the effectiveness of the Operator’s
control layers or in case of misaligned objectives.

Developing the NOV PCAP means in practical terms:

1. Review the list of Control Points and decide the deliverables to be generated by the Shell governance
team itself. Such deliverables shall follow the Shell DCAF process for review and assurance.
2. Map Control Points to equivalents (NOV Control Points) in the NOV process, recognizing that this is not
always a one-to-one relation).
3. Based on the risk profile, decide which NOV Control Points Shell wants to review and which of those
are critical “essential to have’s”. Where we decide that no Shell TA involvement on the Operator’s
work is required, move the Control Point to N/A and include in the comment “accountability of delivery,
Quality Control and Quality Assurance rests with the Operator and no need for Shell to duplicate”.
Where we decide that Shell TAs will quality assure some of the Operator’s work, leave those Control
Points in and include in the comment field that the “accountability of delivery and quality control remains
with the Operator”. This assurance provision by TAs for NOV Control Points enables the Shell
Governance team to decide Shell’s influencing strategy towards the Operator and adjust Shell’s risk
mitigation if NOV Control Points are not up to Shell’s minimal level.

It is important to be critical and selective in this process, keeping in mind that Shell is not the Operator. We do
not want to create non-value adding work for the Operator just to “satisfy the Shell system”. This NOV PCAP is
necessary for any NOV project to be able to manage the Shell shareholder value and exposure. NOV PCAP
helps to guide the discussion with the Operator and ensures comprehensiveness of the Control Points as part of
risk management.

Note 1: Technical competence assurance of TAs in a NOV falls under the accountability of the NOV. Under the
terms of a Technical Service Agreement with Shell, the NOV management can request Shell to advice on TA
competence gaps against the Shell TA Competence Framework. The outcome is an advice from Shell that
identifies any potential competence gaps and recommended mitigations for the TA. However, no certificate will
be given or documented in SOU. In short, a NOV TA can be held against the Shell TA competence framework
and this allows the NOV to make their judgment on translation (whether a person will be appointed as a TA or
not).

Note 2: It is also possible that Shell will provide services to a NOV (to which Shell is shareholder) via a service
agreement. In this case, Shell will do studies or analysis and will produce deliverables that are issued to the
NOV and for which Shell is paid or reimbursed. In this case the Shell DCAF will fully apply to Control Points
(deliverables/decisions) issued to the NOV.

Note 3: SECONDEES IN SHELL ORGANIZATIONS

Staff seconded from JV or NOV partners into Shell organizations may also serve in the capacity of TAs and
similar requirements as in section 5.2.1 will apply.

15
DCAF GUIDE

5.2 CONTRACT STAFF AND ENGINEERING CONTRACTORS

5.2.1 CONTRACT STAFF
Contract staff in Shell may serve as members of the project team and/or as TAs providing assurance on Control
Points within PCAP. Contract staff serving the role of TA shall be assessed against Shell’s Discipline competence
assessment criteria and registered in DAM with appropriate TA level as per the TA appointment process.

5.2.3 EPC CONTRACTORS

As the framework comprehensively allows project teams to create well-tailored PCAP to optimally fit the risk
profile and competencies available for the project delivery, it should also seamlessly interface with the technical
quality (assurance) plans used by EPC contractor(s). Ideally, there should be no duplication between the Controls
Points identified by the EPC and Shell. However, conscious duplications may be built in for monitoring the
effectiveness of the EPC’s control layers or in case of misaligned objectives if there are reasons to complement
the EPC quality assurance process with some Shell-only Control Points. Be cautious not to dilute the (technical)
accountability of the delivery party when exercising this.

Assuming that a competent and seasoned contractor is in place (part of the Shell’s Contractor selection process),
a well-tailored PCAP can be developed based on the actual risk/gap analysis to determine Shell’s minimum TA
involvement and Control Point requirements. In practise this means:

For controls where no Shell TA involvement on EPC’s work is required:

 Move Control Points to ‘N/A’
 Include a comment “accountability of delivery, Quality Control and Quality Assurance is done by the
contractor and no need for Shell to duplicate”.

For controls where Shell TAs are required to QA some of the EPC's work
 Mark Control Point as selected
 Include in the ‘Comments’ field that the “accountability of delivery and quality control remains with the EPC”.

Example: Delivery of piping and instrumentation diagrams/drawings (or P&IDs) – the contractor is fully
accountable for developing these and on case-by-case basis it needs to be decided whether or not Shell TAs are
required to Quality Assure the content (either take a 5% sample size and then depending on the perceived
quality increase/decrease that) or to trust in the EPC’s quality control system and hence; no additional quality
control or assurance by Shell TA is required (risk trade-off).

16
DCAF GUIDE

SECTION 6 GLOSSARY
Accountable Technical Authority (ATA)
The ATA role is fulfilled by an authorized Technical Authority who consolidates the responsible Disciplines’ input and provides
integrated quality assurance to the project team

Asset Controls and Assurance List (ACAL)

Risk based listing of Control Points for the Operate phase owned by the asset team specifying who are on point in providing
quality assurance

Asset Manager (AM)

Appointed individual, responsible for the full day-to-day management of the Asset

Business Opportunity Manager (BOM)

The individual responsible for the overall management of the opportunity, who is responsible to the Decision Executive

Capital Project
Any opportunity that involves the development of a technical concept and the realisation of hardware

Control Point
In DCAF control point refers to a critical Functional requirement with multi-disciplinary content that is globally applicable and
originate from existing Group/Business Standards, Manuals or established in the Discipline

DCAF DE
Appointed by the Projects & Technology Director, ultimately accountable for DCAF and approves/rejects DCAF Change
Panel recommendations

DCAF Tool
Online web-based tool to retrieve 1) list of Control Points in DCAF 2) list of Technical Authorities 3) PCAP Archetype

Discipline Authorities Manual (DAM)

An established list of Technical Authorities (Level 0, 1, 2 and 3) within an organisation

Decision Executive (DE)

The individual who provides steer, supervision and support and is fully and personally accountable for the decisions made
relating to the opportunity, the overall delivery of the opportunity and for quality decisions

Engineering, Procurement and Construction (EPC)

The EPC contractor delivers engineering, procurement and/or construction. It is a common form of contracting arrangement
within the industry

Group Investment Proposal (GIP)

A Proposal involving the acquisition of shares or the assets and liabilities of any company or the creation of a joint venture
with either a headline size exceeding US$ 20 million or involving unusual risk

DCAF Change Panel

DCAF Change Panel endorses Control Point change requests and comprises of Functional representatives appointed by their
Function

Global Discipline Head (GDH)

GDH is appointed by the Head of the respective global (technical) Functions and who leads the global Discipline community

17
DCAF GUIDE

Line of Sight
The clearly documented chain of accountable relationships that exist during the lifetime of an opportunity from each member
of the Opportunity Team, upwards via the BOM and DE, to the individual in the Shell organisation with the appropriate
delegated organisational authority

Non-Shell Operated Venture (NOV)

Non-Shell controlled project or non-operated asset is operated in compliance with principles, policies and standards
acceptable to Shell considering the NOV’s risk profile and Shell’s minimum requirements as per the Shell JV Guide

Opportunity Assurance Plan (OAP)

The plan, approved by the Decision Executive of the opportunity, that sets out the control framework and specific assurance
activities that will be undertaken to enhance the decision quality around the opportunity

Opportunity Realisation Process (ORP)

The six phase, stage gated process (Identify, Assess, Select, Define, Execute, Operate) for managing business opportunities

Opportunity Realisation Standards (ORS)

ORS set out the mandatory rules and provide a practical approach for managing and delivering opportunities

PCAP Archetype
A PCAP archetype is a pre-scaled template based on Line of Business, Project Assurance Level and scope and retrievable
from the online DCAF Tool

Principal Technical Expert (PTE)

Recognised expert with deep technical skills in an area of significant impact for the business and encompasses a number of
Subject Matter areas

Project Controls and Assurance Plan (PCAP)

Risk based listing of Control Points per project phase11 owned by the project team specifying who are on point in providing
quality assurance.

Responsible Technical Authority (RTA)

The RTA role is fulfilled by an authorised Technical Authority who provides quality assurance from his/her respective
Discipline’s perspective to the ATA

Subject Matter Expert (SME)

Acknowledged expert in a very specific area of the business

11
Identify, Assess, Select, Define, Execute

18
DCAF GUIDE

APPENDIX 1 DELEGATIONS OF TA AUTHORITY

A1.1 DELEGATION OF AUTHORITY - TA1
A TA1 can delegate (part of) his/her authority on a permanent/longer term basis by appointing a Delegated
TA1, which gets recorded in the DAM (on the basis that the assessment criteria are the same for a TA1 and
delegate TA1). Examples appointing a delegated TA1:

 when the Discipline has a very wide technical remit in the entity, with distinct sub-areas of expertise (e.g.
Process Engineering & Technology and Civil, Structures and Offshore Engineering),

 when an entity has a large geographical spread and/or contains a number of distinct business areas (e.g.
Deep water and Oil sands),

 Other specific reasons due to which such appointment is justified and will improve the service the TA1 can
provide (frequent absence, periods of high workload, etc.).

The TA1 remains ultimately accountable for the actions and decisions taken by their delegate(s) under the
delegation of authority. It is therefore important that every appointment is accompanied by a clear description of
its scope. The appointment process of a Delegated TA1 is in principle identical to that described for TA2 and
TA3 appointments as per the BMS procedure.

A1.2 DELEGATION OF AUTHORITY - TA2

TA1s can also delegate part of their authority related to a specific project to a TA2. This delegation includes the
approval of deviations from Control Points by the Project. The TA1s remain ultimately accountable for the actions
and decisions covered under that delegation of authority. As the delegation is project specific, there is no need
for any appointment or registration in the DAM. The delegation can be recorded in the PCAP/ACAL in the
“comment boxes” of the relevant Control Points.

A1.3 DELEGATION OF AUTHORITY - TA3

A TA2 can delegate his/her RTA2 role on a specific project to a TA3. The TA2 remain ultimately accountable
for the actions and decisions covered under that delegation of authority. As the delegation is project specific,
there is no need for any appointment or registration in the DAM. The delegation can be recorded in the
PCAP/ACAL in the “comment boxes” of the relevant Control Points.

19
DCAF GUIDE

APPENDIX 2 TA APPOINTMENT REGISTRATION

A2.1 INSIGHT BROWSER
It is mandatory that all TA appointments are auditable. To prevent administrative burden of this process, TA
appointment registration is automated by Insight Browser replacing the past practice of issuing emails and
appointment letters. The audit trail of the appointment is then stored in Insight Browser.

The process is as follows:

1. The appointing TA (TA0s or TA1s) in an entity still need to notify the Local DCAF Administrator of that
particular entity first of any appointments (entry in the DCAF database), as this initiates the Insight Browser
appointment-record procedure.
2. The appointee will be then prompted by an e-mail to confirm the appointment via Insight Browser.
3. The appointing TA and the local admin can monitor the status of the appointments
(pending/rejected/accepted) and act upon where required

Reference Material
Slide packs with detailed instructions for Technical Authorities
 Technical Authority Level 0
 Technical Authority Level 1
 Technical Authority Level 2 & 3

Note 1: The registration of non-Shell TAs in the DCAF database (individuals without a GID account and
consequently do not have a profile in Insight Browser) should be done in the conventional manner (via email or
letter).

Note 2: Competence Assessment of Technical Authorities (requirement from the BMS procedure “Manage
Technical Authorities” and Competence section from Shell’s HSSE&SP CF) and the registration of appointed TAs
in Insight Browser are two separate things.

A2.2 EMAIL OR LETTER

In the absence of the Insight Browser Functionality:
1. TA appointments must be signified to the appointee and acknowledged by him/her and that a record (email
and/or letter) of that appointment and its acceptance must be kept locally for audit purposes.
2. It is the responsibility of the TA1s (for the TA2s and TA3 appointment) and TA0s (or their delegates for TA1
appointments in consultation with the GDH) to manage the appointments and the records thereof in their
Discipline at entity level.
3. The Local DCAF administrator’s responsibility is to translate the appointments in the Discipline Authorities
Manual (entries in the DCAF database), based on the input from the right TA level (TA0 or delegated TA0 for
TA1s and TA1 for TA2s and TA3s).

There is no set format for the appointment document; however the DCAF web site gives access to examples of
appointment letters templates, which can be tailored to fit specific Discipline and/or entity needs.

20
DCAF GUIDE

APPENDIX 3 GUIDANCE ON PCAP SCALING

This section provides the guidelines for scaling a PCAP to make it well-tailored for the project. Always ensure that
valid justifications are recorded for each decision under the ‘Comments’ field in the PCAP.

A3.1 SELECT CONTROL POINTS

Selected Control Points feature on the “Select” tab in the PCAP and can be marked as a “Master Control Point”,
under which other selected Control Points are rolled-up12. The rolled-up Control Points will be assured together
with the Master Control Point13 (refer to section A3.2 below).

A Control Point requires quality assurance by TAs and should be ‘selected’ if it meets one or more of the criteria(s)
below:
 manages a specific project risk
 supports a critical project decision

A selected scalable Control Point can require quality assurance as a standalone document if there is a timing
difference for the decisions that are to be made based on this particular scalable Control Point compared to the
other Control Points (either non-scalable or scalable Control Points).

A3.2 ROLL-UP CONTROL POINTS

Rolled-up Control Points are Control Points that will be quality assured as part of a so called “Master” Control
Point. In practice, the rolled-up Control Point can be either a chapter of the Master Control Point, an appendix or
a separate document that is issued for assurance to the same group at the same time as the Master Control Point.

A Control Point can be “rolled-up” if it supports the same (interim) critical project decision(s) as the Master Control
Point. By rolling up Control Points under a Master, the level of assurance is not diminished but its timing is put
backwards. This increases the risk of recycle for the project. Therefore, the project needs to make a conscious
decision during the PCAP creation to what extent they want to front-end load the TA quality assurance process.

Rolling up Control Points can result in better integration of related information and reduce the overall “volume” of
documentation. However, be practical in rolling-up Control Points in terms of review process, ensuring that it
does not produce large and complex documents that are difficult to review. The figure below shows a snapshot
of a PCAP with a Master Control Point and three rolled-up Control Points.

For illustration purposes only

In this example, the default ATA role remains with the Master Control Point. However, if the Master Control Point
has no default RTA for a Discipline of which the rolled-up Control Point does require an RTA, the RTA of the
rolled-up Control Point will be added to the Master Control Point.

12
Only scalable Control Points can be rolled-up under Master Control Point
13
The Master Control Point can either be a scalable or non-scalable Control Point

21
DCAF GUIDE

A3.3 ‘N/A’ CONTROL POINTS

A Control Point is marked not-applicable (‘N/A’) when it does not require quality assurance as it
 is not part of the project’s scope
 does not support a critical project decision 14
 is not linked to high project risk(s).

For example, for a brownfield expansion project of an operating facility, existing IT infrastructure may be used
and therefore development of IT architecture solutions may not be applicable.

A scalable Control Point can be marked ‘N/A’ based on collaborative decisions taken during the PCAP creation
session. However, a formal TA1 approval is required to mark a non-scalable Control Point as ‘N/A’. A Control
Point should also be marked as ‘N/A’ when the work is outsourced to a contractor (see section 5.2 on working
with Contractors). The contractor is then responsible for the delivery, quality control and quality assurance of the
Control Point. It is advised not to provide additional quality assurance by Shell TAs unless duplication is
consciously built-in to test the QA robustness of the contractor.

A3.4 DEVIATE CONTROL POINTS

A Control Point is deviated when it is deferred to the next phase or the default ATA role is changed to another
Discipline. Note that TA1 approval of the relevant Discipline (who holds the default ATA role) is required for
deviations on a non-scalable Control Point.

Deferment to next phase: The underlying decision supported by the Control Point cannot be taken in the current
phase of the project. This could be due to the lack of key input data, timeline of the project or specific sensitivities
and thus decisions need to be deferred to the next project phase so as to proceed with remaining activities in the
current phase. Once marked for deviation, the Control Points are shifted to the “Deviate” tab of the PCAP and
will come up for consideration again at the start of the next project phase.

Swap in ATA role: The ATA role of a selected Control Point can be changed from the default Discipline to
another Discipline.

14
Control Point becomes a standard project deliverable, and therefore not subject to TA quality assurance

22
DCAF GUIDE

APPENDIX 4 ESCLATION PATHS FOR DISPUTES

Conflicts that arise during the application of DCAF (on matters such as PCAP scaling and review comments on
Control Points) should be managed as early and effectively as possible to ensure smooth project execution. If no
resolution is achieved through dialogues, escalation paths described in this section can be used to reach a
decision. Although escalations should be treated as a ‘last resort’, it is advised not to postpone the escalation on
issues that may cause major project disruptions. Thus, complex issues that require expertise of more senior
individuals should be escalated promptly for effective management. The escalation paths below have a distinct
difference in terms of resolution for issues between the project team and Functions (or Disciplines); or between the
Disciplines.

Dispute between Disciplines within a function: should be Dispute between project team and functions (or
escalated to the TA1 (Discipline lead). However, if no Discipline): on a deviation control or concurrence on a
resolution is reached, the ultimate decision authority lies high assurance risk rating falls to the project’s DE (or the
with the delegated TA0 (Functional Head). VP of Productions in case of an Asset), who ultimately
holds the final decision accountability
Dispute between Disciplines from different functions:
follows the same escalation path as below but the final
authority lies with the TA0.

Note: The escalation paths described in this guide are only suitable for DCAF related disagreements.
Derogations, exceptions or deviations from requirements in other (Group-) standards and manuals should follow
the procedures defined in those standards and manuals.

23
DCAF GUIDE

APPENDIX 5 PCAP CREATION SESSION AGENDA

The table below provides a recommended agenda for a PCAP Creation session. It includes suggested elements
that contribute to a successful session. The content and time spent on each of the topics may be tailored as per
the project requirements. The project team can also opt to use facilitator to conduct the PCAP Creation session
and can reach out to their DCAF focal point for more information on this.

Suggested Time
(minutes)
TOPIC Intent
(For guidance
ONLY)
 Welcome To establish team
Set the 10
 Introductions alignment on the required
Scene outcomes from the session
 Establish Goals for the Session
 Clarify Roles & Responsibilities as per DCAF
(for both DAM and ORS roles) 30 Develop common
 Discuss SOPs understanding about the
R&R and
roles and responsibilities in
Behaviours Highly recommended
DCAF and the expected
 Building Strong Teams session (incl. dilemma 60 behaviours
role-play)
(Facilitation guide can be found on the DCAF website)
Create aligned
Grounding 10 - 30 understanding of project
 Project Premises and Risks
Session risks for an effective PCAP
scaling session
 Record participants
Co-create the PCAP with
PCAP  Select Control Points
60 -150 the team and ensure that
Scaling  Add project-specific Control Points
team feels the ownership
Session  Assign TAs to the selected Control Points for it
 List the Control Point delivery owners
 List deviated, non-scalable Control Points and
Ensure all open/action
Next Steps assign owners to obtain TA1 approval
10 - 20 items are properly
and  Assign owners for other open action items
captured with the expected
Close-Out  Set expected PCAP approval due date follow-up
 Thank all participants for their input
Total Time 180-300

24
DCAF GUIDE

APPENDIX 6 TEMPLATE - QA REVIEW EXPECTATIONS

Clear QA review expectations should be defined in advance between the project team and TAs to ensure timely
and efficient review process; besides preventing multiple review cycles. Below is an example template that can
be used to generate an overview of the agreed QA review expectations.

General QA Review Expectations

Project Name:
No. Topic Project Expectations Action Owner
1 Notification of Assurance Request
Minimum notification period <Minimum 2weeks prior to issue
of Control Point for review>

Communication Method <Chosen as appropriate e.g.

email or alerts via the document
management system>

2 QA Review Period
RTA Review Period <Generally 1 – 2 weeks>
*Depends on factors such as project
complexity and TA location. Project
specific Control Points may require
additional review time.
ATA Review Period <Generally 1 – 2 weeks more
than the RTA QA review time>
3 QA Review Process
Document Management System <Chosen as appropriate e.g.
ASSAI, DCCM>
*More information in appendix 6
Alternate Review Format for specific Control Points < Chosen as appropriate e.g.
Review in One Touch>
*Rationale for alternative review formats
can be found in appendix 5
4 Other Expectations

25
DCAF GUIDE

ALTERNATIVE CONTROL POINT DEVELOPMENT & QA

APPENDIX 7
REVIEW FORMATS
This section provides alternative Control Point development and QA review formats that have been successfully
implemented by projects. Although it is strongly recommended that the development and review of Control Points
are done according to the PCAP Execution SOP, project teams can choose opt to implement alternative
development and QA approaches tailored to project requirements.

A7.1 FAST TRACK CONTROL POINT DEVELOPMENT

The Control Point is developed within 3-4 consecutive days due to a constrained project schedule which only
allows a limited time for the development of a Control Point. This format can be implemented if all relevant (and
co-located) project team members and TAs are able participate in the development session. The Fast Track
Control Point Development ensures that the Control Point is ready for assurance by the end of the Fast-Track
Development session led by a member from the project team.

It is essential that all the participants of the development session are well-prepared to ensure a successful Fast
Track Control Point development. Below is a checklist to guide a Fast-Track Development Session. Note that this
list is not exhaustive.

FAST-TRACK DEVELOPMENT SESSION CHECKLIST

Phase Action Completed Action Owner
(Y/N)
Start of PCAP Execution Relevant project team members and TAs informed Project Team
Phase of alternate development approach
Fast Track Development Session organized Project Team
*according to the availability of relevant project
team members and TAs
Familiarize with ‘SOP BfD in 1 week’ Project Team
See A7.3 - attachment
2 weeks – 2 months Kick-Off Session organized to start pre-work (incl. Session Lead
before the Development data collection) required for development session
Session Pre-read sent out to the participants at least 2 Session Lead
weeks before the session.
*The pre-read should include the agenda,
project premises and other relevant documents.
0-2 weeks before All participants aware of objectives of session; Session Lead
the Development and familiarize with project premises and pre-
Session read material.
‘Fast-Track Development’ Led by Control Point owner Control Point
Session Owner
After the Session Developed Control Point sent for assurance or Session Lead
follow-up session with ‘assurance review in one
touch’ (described in the following section)

26
DCAF GUIDE

A7.2 ASSURANCE REVIEW IN ONE TOUCH

This assurance review format allows the entire review cycle for a Control Point to be completed in a single
session, typically lasting between 4 to 8 hours. This format is most appropriate for the large, complex Control
Points which would benefit from all the assigned TA reviewing the Control Point together to provide QA and
solutions to any pertaining issues. This format can be implemented if most (or ideally all) assigned TAs and
relevant project members are able participate in the review session. The session is led by the ATA with the
objective to have the Control Point assured at the end of the session. Key benefits of this format:
 Avoids non-value-add review cycles and minimizes re-work
 Speeds up the assurance process
 Ensures thorough assurance of complex Control Points

Below is a checklist to guide a ‘Review in One Touch’ Session. Note that this list is not exhaustive.

‘REVIEW IN ONE TOUCH’ CHECKLIST

Phase Action Completed Action
(Y/N) Owner
Start of PCAP Relevant project team members and TAs informed of alternate Technical
Execution assurance review approach Lead
Phase ‘Review in One Touch’ session organized according to the availability Technical
(and location) of relevant project team members and TAs Lead
2 weeks – 2 Connect with ATA to start preparation for session Technical
months before Lead
the Review Prepare session agenda ATA
Session Pre-read sent out to the participants at least 2 weeks before the Technical
session. Lead
*The pre-read should include the Control Point to be reviewed,
agenda, project premises and other relevant documents.
0-2 weeks All participants aware of objectives of session; and familiarize with Participa
before Control Point to be project premises and pre-read material. nts
Review Session
‘Review in One Lead by the ATA ATA
Touch’ Session
Assurance review comments recorded in the document management ATA
system
After the All final assurance review comments tracked in document ATA
Session management system
In case of a ‘high’ assurance risk rating, ensure a quick follow-up with Technical
the ATA to discuss how to close the comments Lead

A7.3 INTEGRATING ‘ASSURANCE REVIEW IN ONE TOUCH’ WITH ‘FAST TRACK CONTROL POINT
DEVELOPMENT’
Projects can opt to combine the ’Fast Track Control Point Development’ with the ‘Review in One Touch’ assurance
process for efficient project delivery. This alternative development and review format has been successful
implemented in several projects in RDS. Attached is the agenda and SOP from a best practice example for ‘BfD
Development and Assurance in One Week’.

Agenda for BFD in 1 SOP BfD in 1 Week -

week.pptx shortened.docx

27
DCAF GUIDE

APPENDIX 8 DOCUMENT MANAGEMENT & WORLFLOW SYSTEM

Projects should have a document management & workflow system in place (examples are ASSAI or DCCM). The
role of the Document Controller is to ensure that Control Points are stored and distributed for QA review through
the chosen document management system. The system ideally caters for:

 Support workflows in line with the endorsed PCAP and QA review expectations
 Log QA review evidence
 Keep track of document version control
 Report status of assurance risk ratings

An appropriate document management system should be chosen according to the project requirements. For
example, DCCM (SharePoint based) is generally used for routing a maximum 100 documents whereas ASSAI is
implemented if external access is required. Other factors such as contractor tools and risk rating process should
also be considered. Below is a general guidance on setting up a document management and workflow system.

1. Prepare workflows in line with endorsed PCAP and QA expectations

 Align workflows with the PCAP and QA expectations such as QA review deadlines and access
requirements. For example, some document management systems allow pre-populating the QA review
deadlines for the Control Points.

2. Ensure that assurance risk rating Functionality is included in document management system
 ATAs should be able to provide an assurance risk rating for each review comment.
 The project can opt for a document management system that allows the ATA to enter comments (and
assurance risk ratings) separately; or a system that provides a single comment box for the ATA to fill both
the comments and the assurance risk rating.

3. Set up reporting process on the number and status of received assurance risk ratings
 To enable tracking of assurance risk ratings received (number and status) and open items that need to
be closed out by the end of the phase.
 For example, the workflow system should clearly reflect any High risk ratings and its status
(open/closed). If such a comment is not closed out by the end of the phase, it should be reflected
clearly on the document management and workflow system and a rationale should be provided.

28
DCAF GUIDE

APPENDIX 9 BEST PRACTICE ASSURANCE

Quality assurance on the Control Points is linked to the project’s specific value drivers and risks. This requires an
understanding among all Technical Authorities (regardless of being part of the project team or sitting remote) of
the project premises, value drivers and risks. Successful and impactful quality assurance therefore is highly
dependent on collaboration between the project team and the TA. Below some examples of collaborative
behaviour that avoids common issues in the application of DCAF.

Issue Best practice behaviour

Project Team TAs

 Request for the relevant information to assure
 Provide timely and sufficient
TAs provide generic, non- the Control Point, if not already provided by
project information to the TAs.
value adding assurance the project.
 Ensure proactively collaboration
review comments  Ensure early and continuous engagement(s)
with the TAs during the
with the project team and Control Point owner
development of the Control Point
during the development of Control Point

 Provide TAs with a QA review  Request for a QA review deadline if not

TAs do not provide timely
deadline provided by the project team.
assurance review comments,
 Notify TAs at least two weeks in  Provide review comments within the set time
causing schedule overruns
advance of upcoming review frame

 If the quality of the Control Point is deemed

 Ensure that the Control Point is
Multiple, unnecessary review unfit for a quality assurance review by the TA,
developed up to a firm version
cycles initiated the TA is fully empowered to return it to the
before it is sent for review by
Control Point for improvement without initiating
TAs
a review cycle

Unnecessary time and effort  Only for the ATA: Supplement each review
 Request for assurance risk rating
spent to close-out non-critical comment with an assurance risk rating to clarify
of the ATAs review comments.
review comments (project, the criticality of the comment (High, Medium,
 Focus effort on the critical items
contractors etc.) Low; refer to appendix A7.2)

 Follow up on ‘High’ assurance

Highly critical assurance  Only for the ATA: Ensure that the project team
risk rating comments with the
review comments are not follows up with the ATA on all ‘High’ assurance
ATA within a week after the
followed up risk rating comments
comment has been provided

29
DCAF GUIDE

APPENDIX 10 ANNUAL ASSURANCE ON THE DISCIPLINE HEALTH

Once a year TA1s issue an assurance report to the (Delegated) TA0 with a copy to the GDH on the health of the
Discipline in his/her entity. This typically covers 4 elements:

1. The status of the TA population:

 Whether the number of TAs is sufficient to meet demand and the TAs scope of assurance is clear
2. A documented overview of how projects and assets work their PCAPs and ACALs for his/her Discipline:
 This can either be by direct access to the PCAPs/ACALs, direct involvement in the creation of these documents or
indirectly by obtaining regular feedback from his Disciplines TAs, that are involved in these projects, on progress
and any specific Discipline issues.
3. Technical Authorities have the required skills to execute their role:
 Competencies have been assessed, and in case of competency gaps a plan is in place to fill these gaps. TAs have
sufficient DCAF understanding, e.g. had the appropriate DCAF training, to effectively fulfil their role in the relevant
projects and assets, and understand the responsibilities and expectations therein.
4. Assess the compliance of projects/assets with the own Discipline Standard:
 Review PCAP/ACAL deviations and derogations
 Review TAs selected to support assurance
 Review Control Points in DCAF whether they cover sufficiently the Discipline requirements

For Discipline Authorities Manuals owned by Shell this process has been automated through Insight Browser, the
TA1s will be asked to fill in a questionnaire with the data being centrally collated and the individual assurance
reports produced. These reports will mailed to the respective GDHs and (delegated) TA0 as input for further
discussion with the Discipline lead if necessary. The yearly process starts in November giving the TA1s
approximately 6 weeks to provide their input prior to distribution.

30
DCAF GUIDE

APPENDIX 11 DISCIPLINE AUTHORITIES MANUAL ADMINISTRATOR

Organisations, which have established their Technical Authority Framework and appointed their Technical
Authorities (TA), shall record and maintain their list of TA’s in an easily accessible controlled electronic format.
Whenever possible, the Discipline Authorities Manual (DAM) section of the Discipline Controls and Assurance
Framework Tool shall be used as the TA repository.

The DAM administrator’s primary responsibility is maintaining an Entity’s Discipline Authorities Manual (DAM).

This responsibility encompasses the following tasks:

 Registering assessed Technical Authorities in the Entity’s Discipline Authorities Manual he or she is appointed
to by strictly following the registration process; evidence of support/approval of the appointing TA is
required:
 (del.) TA0 appoints TA1s in consultation with the respective Global Discipline Head
 TA1 appoints TA2/TA3 in his/her discipline

 Prior to registration verifying the presence of a valid discipline competence certificate in SOU* via the
certification check tool [link].
This certification check is not required for all levels and/or disciplines. The following overview [link] lists the
relevant certificates per Discipline and TA level

In the case the report shows that appointed TA has no certificate, the admin should “decline” this registration
accompanied by the appropriate communication (via email) to the appointing TA and to be registered TA.
The escalation path is to the respective GDH if the appointing TA insists.

 Monitoring the statuses of the TA appointments (pending/rejected/accepted) via Insight Browser and act
upon where required (if Insight Browser is used to track the acceptance of a TA role).

 Removing Technical Authorities in cases where the role is declined accompanied by the appropriate
communication via email to the appointing TA and registered TA.

 Updating Technical Authorities’ information when being requested by the appointing TA.

DAM Administrator appointment

The DAM Administrator is appointed per entity by the respective TA0 (or by the person to whom the TA0
delegated this appointment).

References:
 BMS Procedure - Manage Technical Authorities [link]
 Certification check tool [link]
 Overview of existing certificates per Discipline and TA level [link]

31
DCAF GUIDE

32
DCAF GUIDE

The Value & Project Assurance department (PTE/V) is the custodian of the Discipline Controls and Assurance Framework
Guide. This guide may change over time. The authoritative version of this document is available at:
http://sww.shell.com/DCAF

This document has been classified Restricted. Full or partial communication of this document outside the Group requires
prior consent of the custodian. Copies or extracts of this document, which have been downloaded from the website, are
uncontrolled and cannot be guaranteed to be the latest version.

© Shell International B.V. 2015

33