Document No.

Ver Date Status Page

PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 1 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

Guideline Scope Management

Business area Global

Location Global

CKN 100 Project Management

Management of this Document

Role Name Signature
Responsibility Title Date
Abgelaufenes Zertifikat
Dr. Jörg Klein,
Author
Senior Manager Jörg Klein
Subject Matter X
Corporate Project Management Office Jörg Klein
Owner B. Braun Melsungen AG Senior Manager PMO-C
Signiert von: kleijrde
20.04.2018
Freddy Listander
Reviewed Director
Subject Matter Operational Excellence and Project X Freddy Listander
Expert Management Office Freddy Listander
Director, Operational Excellence and Project...
Aesculap AG Signiert von: LISTFRDE
Abgelaufenes Zertifikat
Dr. Jörg Klein,
Approved
Senior Manager X Jörg Klein
CKN Workgroup
Corporate Project Management Office Jörg Klein
Lead B. Braun Melsungen AG Senior Manager PMO-C
Signiert von: kleijrde

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 2 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

Table of Contents

Page

1 INTRODUCTION ...................................................................................................................................... 3
1.1 DOCUMENT OWNERSHIP & AUTHORITY.............................................................................................. 3
1.2 PURPOSE & SCOPE .......................................................................................................................... 3
1.3 RELATIONSHIP TO OTHER DOCUMENTS ............................................................................................. 3
2 OVERVIEW .............................................................................................................................................. 3
3 PROJECT SCOPE MANAGEMENT ....................................................................................................... 3
3.1 PLAN SCOPE MANAGEMENT.............................................................................................................. 4
3.1.1 Beyond the PEM Guide ...................................................... Fehler! Textmarke nicht definiert.
3.1.2 How to apply it in practice ......................................................................................................... 5
3.2 COLLECT REQUIREMENTS ................................................................................................................. 5
3.2.1 Beyond the PEM Guide ...................................................... Fehler! Textmarke nicht definiert.
3.2.2 How to apply it in practice ......................................................................................................... 6
3.3 DEFINE SCOPE ................................................................................................................................. 7
3.3.1 Beyond the PEM Guide ...................................................... Fehler! Textmarke nicht definiert.
3.3.2 How to apply it in practice ......................................................................................................... 7
3.4 CREATE WBS .................................................................................................................................. 8
3.4.1 Beyond the PEM Guide ...................................................... Fehler! Textmarke nicht definiert.
3.4.2 How to apply it in practice ....................................................................................................... 11
3.5 VALIDATE SCOPE ........................................................................................................................... 13
3.5.1 Beyond the PEM Guide ...................................................... Fehler! Textmarke nicht definiert.
3.5.2 How to apply it in practice ....................................................................................................... 13
3.6 CONTROL SCOPE ........................................................................................................................... 13
3.6.1 Beyond the PEM Guide ........................................................................................................... 13
3.6.2 How to apply it in practice ....................................................................................................... 13
3.7 HOW IS SCOPE TREATED IN AGILE? .................................................................................................. 13
3.8 REQUIREMENTS ............................................................................................................................. 14
4 PRODUCT SCOPE MANAGEMENT..................................................................................................... 14
4.1 BEYOND THE PEM GUIDE ............................................................................................................... 14
4.2 HOW TO APPLY IT IN PRACTICE ........................................................................................................ 14
5 GLOSSARY & ACRONYMS ................................................................................................................. 17
M1 VERSION HISTORY .............................................................................................................................. 17
M2 CHANGE SUMMARY ............................................................................................................................ 17

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 3 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

1 INTRODUCTION

1.1 DOCUMENT OWNERSHIP & AUTHORITY

This document is part of the B. Braun Project Execution & Management (PEM) System. It is
produced and managed by;
Corporate Knowledge Network 100 Project Management

1.2 PURPOSE & SCOPE

This document defines;
 Scope Management

1.3 RELATIONSHIP TO OTHER DOCUMENTS

Input Documents
 PEM Guide V1
This document shall be read in conjunction with (further resources);
 PEM-2000.00.00-20X00-001-0-0 Guideline – Design Management
 PEM-1020.00.10-10B20-001-0-0 Template – WBS Dictionary

2 OVERVIEW
Project Scope Management covers the processes to ensure that the project includes all the work
required, and only the work required. This includes requirements management and the changes to
scope that occur during the project.

In the Project context, Scope includes:

 Product Scope which is the features and functions of the product, service or result, and
 Project Scope which is the work performed to deliver the product

This document will help the reader by

1. Elaborating on the description in the PEM Guide
2. Offering an approach to put scope management into practice

3 PROJECT SCOPE MANAGEMENT

Proper scope management helps the project manager to avoid delays and cost overruns. If scope
management is done poorly, then the project team performs a lot of unnecessary work (i.e. work that
will not contribute to successful completion of the project). Also, the lack of clarity about what needs
to be done and what not leads to increasing dissatisfaction among the sponsor, project team and
other stakeholders. Therefore, it is in the best interest of the project manager to apply good scope
management practices in the project.

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 4 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

Table 3-1 Overview of Project Scope Management tasks

Task Description Reference PEM @B. Braun module
Plan Scope Create a Scope Management Plan 02 Project Governance
Management that defines how the project scope (Project Request, Project Charter)
will be defined, validated and 04 Project Management
controlled
(Project Planning, Integrated Change
Control)
07 Design Management
(Requirements Management)
Collect Elicit, document, validate and 02 Project Governance
Requirements approve stakeholder requirements (Project Request, Project Charter)
and needs 07 Design Management
(Requirements Management)
Define Scope Developing a detailed description 04 Project Management
of the project and product (Project Planning)
07 Design Management
Create WBS Subdividing the project & product 04 Project Management
scope into deliverables and work (Project Planning)
packages 05 Commercial Management
07 Design Management
Validate Scope Validation & acceptance of project 04 Project Management
deliverables 07 Design Management
08 Project Quality Management
09 Validation Management
Control Scope Monitoring the status of the project 04 Project Management
and product scope and managing 07 Design Management
changes to the scope baseline 08 Project Quality Management

The reference in the PEM modules 02 Project Governance and 04 Project Management cover
mostly project scope while the other modules in table 3-2 (05, 07, 08, 09) address product scope.

3.1 PLAN SCOPE M ANAGEMENT

3.1.1 Why You Should Plan Scope Management

The scope management plan defines the processes, methods and general framework which is used
to manage scope in the project. The benefit of this plan is that all project team members and the PM
(Project Manager) will have a common understanding of how scope will be managed. The choice
whether the project will be managed using waterfall, agile or any hybrid approach, has a big
influence on how scope will be treated and it needs to be agreed among the project team and
documented. Specifically, the collection of needs, definition of requirements and the management of
changes to the requirements should be addressed. Sometimes, an additional document
(requirements management plan) is created for this. The final scope management plan should
answer questions like:
 How are we making sure that all the necessary work will be done?
 How are we making sure that ONLY the necessary work will be done (avoiding scope creep)?

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 5 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

 How will we define, approve and maintain the scope baseline?

 Who can make changes to the scope?
 When can changes to the scope be made?

3.1.2 How to apply it in practice

One way of fulfilling the PEM requirements is the following. Look at your project charter and identify
information on that is relevant for managing scope. Create a Scope Management Plan (e.g. a word
document) that defines more precisely than the charter how the project scope will be defined,
validated and controlled. File the document in the appropriate Project Folder and inform your team
that they have access to this document. It is highly recommended to discuss this document in a team
meeting (e.g. a planning workshop) to have everyone understand what they need to do to ensure
good scope management.
Figure 3-1 Conducting a planning workshop

3.2 COLLECT REQUIREMENTS

3.2.1 Why You Should Collect Requirements

Collecting and analysing requirements is mandatory to answer the question “Why should we do this
project?”. Going deeper in the analysis will provide answers to the question “What do we need to do
to fulfil the requirements?”. Being specific and clear when documenting the requirements will
increase the likelihood of understanding and meeting customer expectation. Being vague and sloppy
will make it unlikely to meet anyone’s expectations.
High-level requirements should already be documented in the Project Charter. A deeper
understanding of what customer, sponsor and other stakeholders expect the project to deliver is
obtained by asking them. There are various methods for gathering requirements from stakeholders:
 Interviews
This means meeting with someone and asking them “what do you expects to get out of the project?”
and then diving into more detail. The result of the discussion is not necessarily agreement between
the PM and the interviewee but rather an increased understanding on the PM’s side.
 Brainstorming sessions

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 6 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

This technique explores various ideas and is helpful to open up opportunities. Ideas around the topic
of requirements can be freely expressed without criticism and evaluative comments. A structured
approach to brainstorming is to ask one participant at a time to share their expectations and then
open the discussion. A less structured approach is that anyone can talk and whenever they want. It
is also possible to have everyone write down their requirements for the project on a piece of paper
and then share this on a white board.
 Focus groups
Stakeholders are gathered and the moderator focusses the group discussion around the
requirements for the project. The technique is more conversational than interviews and more
focussed and guided than brainstorming sessions.
 Surveys
Survey make it easier to involve opinions from stakeholders that feel uncomfortable to express their
ideas in a group setting. The contributions from introverts can be harvested using surveys.
 Data research
Business documents, the project charter etc. can be used to find requirements that are already
documented. They still need to undergo all subsequent steps until they are validated.
The collection of requirements can be very long and the requirements traceability matrix has proven
an efficient tool to document and track requirements. The requirements traceability matrix links
requirements from a stakeholder to a project objective. It should answer the questions:
 What deliverable satisfies which requirement?
 Do we have deliverables that cannot be linked to any requirement? Should we work on the at
all?
 Do we have requirements but no deliverables that satisfy them? How are we going to meet
this requirement?

Table 3-2 Example of a simple requirements traceability matrix (from drug development)
Requirements Business Need Project Objective WBS Deliverable
Description
Shelf life at least Our product needs to The launched product Stability report of
24months at 25°C, be at least as stable needs to have registration batches
60% rel. humidity as the competitor approval for this shelf
(marketing) life
Requirements are an important aspect and the relationship between the business analyst and the
PM plays an important role in defining requirements. In this context, the needs arising from the
organization’s strategy are first described on the Portfolio-level and then broken down to the
program- and eventually the project-level. On the project-level the cycle of elicitation, analysis and
evaluation is repeated throughout the project.

3.2.2 How to apply it in practice

Put simply, the PM needs to create one list with the requirements. As a starting point, high-level
requirements are defined in the project charter. Then, the PM asks the most important stakeholders
what they expect the project to deliver and documents their expectations. This list is then structured
as described in the next section, “Define Scope”.

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 7 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

Figure 3-2 Collecting requirements in practice

3.3 DEFINE SCOPE

3.3.1 Why you should define the Scope

“Defining the scope” can be described as turning the very long list of requirements into something
that can be realistically achieved by the project while staying within the available budget and time.
Unlike during requirements collection the PM needs to take decisions on what is important and what
is not. At this point product analysis techniques (see also the section about Product Scope
Management in this guideline) can be helpful to get a deeper understanding; product breakdown,
systems engineering, value analysis etc.. The final output is the project scope statement, where
deliverables, their acceptance criteria and project exclusions are defined. This is the key document
to manage stakeholder expectations at this stage of the project.

3.3.2 How to apply it in practice

As a PM, you start by prioritizing and shortening the “wish list of requirements” to what actually
should be done within the project. You need to align closely with the sponsor to define what should
and can be achieved with the resources, budget and time available for the project. Often it is also
good to involve the project team. The final result of this step is a detailed description of the project
and the product. Commonly, a Project Scope Statement is used for this purpose. It might cover the
following aspects.
 Project scope description – elaborates on the high-level content of the project charter
 Project deliverables – description of the deliverables that will lead to the final project result
 Acceptance criteria – defines what the deliverables need to fulfil to be accepted
 Project exclusions – defines what will not be done during the project. This section helps to
manage stakeholder expectations and avoid scope creep.

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 8 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

3.4 CREATE WBS

3.4.1 Why you should create a WBS

The Work Breakdown Structure is a hierarchical structure of the project independent of time. The
defined scope is broken down into smaller pieces (deliverables, sub-projects, tasks) that are more
manageable. This helps the PM to make sure that nothing is left out and no extra work is performed
(i.e. 100% rule). With each level the components are broken down into further sub-components until
an appropriate level of detail is reached. As a best practice, each work package of the WBS should
contain only one deliverable. Level 1 is the overall product and has only one WBS element. Level 2
is the first level of decomposition. Depending on the complexity of the project the WBS typically
between 2 and 5 levels. When numbering the different levels, please consider the PEM Guide
chapter 8.4 TECHNICAL WORK BREAKDOWN STRUCTURE (WBS). The following pages will
describe different forms of visualising a WBS and different approaches to creating them.

Different forms for visualization:

 Text (also called “outline view”):
‘Project Number’ - Project “Machine”
A0 Services
A1 Project Management
A2 Development
B0 Engine
B1 Turbo
B2 Water pump
B3 Radiator
B4 Engine block
B5 Connections
C0 Frame
C1 Coil
C2 Pressing tool
D0 Electronics
D1 Display
D2 Software
E0 Electricity
E1 Fuse system
E2 Power supply

To safe space the indent can be omitted.

 Tree structure
Figure 3-3 Tree Structure of a WBS

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 9 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

 Other representations include (only an illustrative part of the above content is shown)
 Tabular view
Table 3-3 Tabular view of a WBS, example 1
Level 1 Level 2 Level 3 Level 4
Project Machine
A0 Engine
A1 Turbo
A2 Water pump
A3 Radiator
A4 Engine block
A5 Connections
B0 Frame
B1 Coil
B2 Pressing tool

Table 3-4 Tabular view of a WBS, example 2

1 Project “Machine”
A0 Engine
A1 Turbo A4 Engine block
A2 Water pump A5 Connections

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 10 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

1 Project “Machine”
A3 Radiator
B0 Frame
B1 Coil B2 Pressing tool

 Horizontal Tree Structure

Figure 3-4 Horizontal Tree WBS

Different approaches to breaking down (break down logic)

 Phases/Chronological
If the project has sequential, stage-like phases a breakdown according to these phases might
be a good choice.
 Components
If the final objective of the project is a physical product that can be decomposed into sub-
components, then breaking down the system into components and subcomponents might be
a good choice.
 Departments
If the organisation has strong line functions it might be appropriate to structure the WBS into
deliverables that each functional department can contribute independently. If the organisation

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 11 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

is more projectized (e.g. a strong matrix in PMI terms) a different breakdown logic might be
preferred.
 Geographically
If the project has a clear separation between different geographies (e.g. a launch of a product
through independent sales organisations in Asia, America and Europe). Structuring the work
into different regions might be considered.

Regardless of the breakdown logic or visualisation that is chosen some principles should be taken
seriously:
 The WBS contains only necessary and sufficient deliverables (100% rule)
 All WBS elements are deliverable-oriented
 All element names are nouns. Verbs are not used to identify WBS elements
 No overlapping responsibilities. Each deliverables needs to have one person that is
accountable for it.
 The final deliverable should be decomposed into interim deliverables.
All elements of the WBS are described in more detail in the WBS Dictionary (what exactly is behind
this deliverable? Who is responsible? Critical acceptance criteria of the deliverable etc). The WBS
dictionary is attached to the WBS.

3.4.2 How to apply it in practice

Try different breakdown logics until you reach a structure that is sufficiently clear. Do this preferably
as a team exercise.
Figure 3-5: Determining the breakdown logic

Check that you have covered all necessary work and only that work. Once you decided on the
breakdown logic, check if all work-packages are deliverable-oriented.

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 12 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

Figure 3-6 Defining major deliverables

In the last step of the process work packages (and if needed activities are defined).
Figure 3-7 Defining Work Packages

It has proven efficient to use post-its to create a first WBS with the team members. Then convert it
into a digital WBS where team member can finalize it. Let the team members introduce the
completed WBS at the next meeting.
Use the document for the communication with your stakeholder to get the scope validated (next
section).

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 13 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

3.5 VALIDATE SCOPE

3.5.1 Why you should validate the Scope

Validating means getting formalizing the acceptance of the completed project deliverables.
Additionally, the connection to the requirements needs to be checked and confirmed. This is
important to avoid scope creep and manage stakeholder expectations. After this step the PM and the
stakeholders need to know what deliverables are an output of the project and which ones are not.
This forms the baseline against which the project manager can detect and manage change.

3.5.2 How to apply it in practice

Present the project scope statement and the WBS (incl. WBS dictionary) to your stakeholders and
ask them to approve it. After this step all deliverables are formally accepted by your stakeholders.

3.6 CONTROL SCOPE

3.6.1 Why you should control the Scope

Controlling the scope means monitoring the progress of the project and managing changes to the
scope baseline. This is critical to avoid scope creep, budget overruns and delays. All changes to the
scope baseline need to undergo a formal change control process before their implementation. There
are different sources of deviations from the scope baseline, for example:
 A stakeholder brings a new requirement and wants it to be considered in the project
 Project delays make the achievement of certain deliverables impossible
 Changes in the external environment (e.g. supplier factory burned down) require strategic
decisions in the project: descope (remove or change a deliverable while keeping time and
budget) or crashing the timeline (add resources to an activity to keep the time and scope but
increase costs)?
There will be necessarily deviations from the initial planning and it is a core responsibility of the PM
to make sure that the scope is not changed without information of all stakeholders, their approval
and documentation. The changes in scope have important impact on the following baselines
 Cost baseline
 Schedule baseline
If these impacts are not considered and made transparent to the stakeholders the project quality
suffers significantly and stakeholder satisfaction decreases.

3.6.2 How to apply it in practice

Check regularly (e.g. monthly) if there are changes to the baseline that was accepted by all
stakeholders. Use the change management processes to decide on whether to implement any
changes and inform all relevant stakeholder if there are changes to the approved scope.

3.7 HOW IS SCOPE TREATED IN AGILE?

In agile the scope is developed iteratively in close alignment with the customer and the two
processes validate scope and control scope are repeated with each iteration. A common format in
which requirements are documented are user stories. They have the format “I as a [role of user],
want to [feature], so I can [purpose of the feature]”.
In Agile the requirements are reflected in the backlog. For further information please consult the
following document:
 PEM-1900.00.00-19X00-001-0-0 PEM Agile Practice Guide

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 14 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

3.8 REQUIREMENTS

 Scope Management

Project Categories A B C D
Requirements 1. A Scope Statement is prepared
2. Other scope definition and management documents are employed as required to
adequately define and allocate scope to participating parties
3. Project plans collectively ensure that scope is defined, controlled and validated
(accepted)
Project Categories A B C D
Requirements 4. Scope is adequately defined in the Project Charter and the associated scope
statement
The best practice library offers the following templates to fulfil the PEM requirements
 PEM-1020.00.15-10B95-001-0-0 Scope Statement

4 PRODUCT SCOPE MANAGEMENT

4.1 WHY YOU SHOULD PERFORM PRODUCT SCOPE MANAGEMENT

In the PEM guide, product scope is mostly described in 07 Design Management. A detailed
elaboration of requirements management and its relation to configuration management is provided
there.

4.2 HOW TO APPLY IT IN PRACTICE

For small projects include the product scope into the steps described in section 3. For large projects
consider the techniques offered around requirements and configuration management.

5 DOCUMENTING SCOPE MANAGEMENT

There is a larger set of planning documents and scope management is cover in these documents:
Figure 5-1 Example Project Planning Documents
Internal Project Planning documents Shared coordination Instructions to External vendor’s
documents external vendor Plans
Project Management Contract Block Diagram Project Coordination Project Plan
Plan Organization Chart : Plan
Phase Y
Organization Chart :
Project Governance Project Scope Split in Scope of Work …
Phase X
Plan Statement Plan

Project Quality Work Breakdown Communication Matrix Procedure :

Plan Structure Change Management

Master Validation Project Process Map Master Schedule / Procedure : Validation

Plan Milestone Schedule Document & Data Mgt Plan

Procurement Budget & Cash Flow Procurement Planning & Schedule

Plan Tracking Log

Requirements Asset Definition & Cost Request For Information

Management Plan Allocation Rules Log

Configuration Risk Register Change Log

Management Plan

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 15 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

It is not mandatory to use exactly these documents but it is highly recommended that the project
manager plans for the following topics:
Table 5-1 Project Planning Topics
Subject Content
Project Data  Project number, short name, full name, location, other key
identification information
Overview  Purpose, objectives & scope overview, key milestone dates
References  References to Project Charter, contracts
Standards  Applicable regulatory, industry, customer guidelines & standards
Project procedures &  List of applicable internal procedures & standards
standards
 List of project specific procedures & standards
Subsidiary Plans  Definition of hierarchy of subsidiary plans & components
Organization  Contract Block Diagrams
 Organization Charts, Organization Matrix, Project Directory
 Definition of particular roles & responsibilities
Execution Narrative  A description of how the project will be performed, including
acquisition strategy, project phases, key milestones, key internal
parties, outsourced works …
Scope Baseline  Project Scope Statement
 Work Breakdown Structure + WBS Dictionary / Project Process
Map Key Point definitions
 Split in Scope of Work between parties
Schedule Baseline  Master Schedule & Key Milestones, or Project Process Map
Phases & Milestones
Cost Baseline  Approved Budget & Cash flow plan
Scope Management  Definition of process, responsibilities and tools to define & manage
Plan scope, including change management
Schedule Management  Definition of process, responsibilities and tools to define & manage
Plan project schedule
Design Management  Definition of the development model, responsibilities, interfaces
Plan
 Definition of the design & development baselines that will be
(Note 1) applied
Requirements  Definition of processes, methods, & tools for establishing and
Management Plan maintaining project level and solution requirements
(Note 1)
Configuration  Definition of processes, methods, & tools for establishing and
Management Plan maintaining consistency of project deliverables’ performance,
(Note 1) functional, and physical attributes with its requirements, design,
and operational information throughout its development &
realization
Quality Management  Definition of tasks, responsibilities, methods, & tools to ensure
Plan project deliverables meet requirements

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 16 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

Subject Content
(Note 1)  Monitoring of project execution to ensure defined procedures are
implemented
Validation Plan  Definition of tasks, responsibilities, methods, & tools to ensure
(Note 1) validated project deliverables meet requirements
Review Plan  Definition of the review program covering Planning / Readiness /
(Note 1) Verification / Validation reviews
Risk Management Plan  Definition of tasks, responsibilities, methods, & tools
Communication  Definition of information needs, communication channels and
Management Plan reporting requirements
 Definition of meeting schedules
 Definition of Document, Data & Information Security management
requirements, processes & tools
Commercial & Cost  Definition of commercial management tasks, processes & tools
Management Plan
Procurement  Definition of procurement management tasks, processes & tools
Management Plan
 Establish Procurement Planning & Tracking Log (List of
procurement items with sourcing approach & status tracking)
Human Resource  Particular activities to acquire and train personnel for the project
Management Plan execution, prior to participating in Inspection & Testing activities,
or subsequent operation & maintenance phase
Stakeholder  Define stakeholders & stakeholder engagement
Management Plan
Note 1 Requirements Management, Configuration Management (collectively
Design Management), Reviews, Quality Management & Validation
Management are intimately related. Appropriate Configuration
Management processes will fulfill part of the Quality & Validation
Management requirements

CKN 100 Project Management

Alternate Document No.
Document No. Ver Date Status Page
PEM-1020.00.00-10B00-001-0-0 1.0en 2018-01-18 DRAFT 17 of 17
Title
Guideline Scope Management
Source : PEM-9900.00.00-90x00-001-0-0-V1.0en

6 GLOSSARY & ACRONYMS

Acronym Description
PEM Project Execution and Management
PM Project Manager
WBS Work Breakdown Structure

M1 VERSION HISTORY

Ver Date Description Author

0.1 2018-01-04 Draft: Guideline Scope Management Jörg Klein
1.0 2018-01-18 Draft for release. Jörg Klein

M2 CHANGE SUMMARY

Ver Section Description

CKN 100 Project Management

Alternate Document No.