This document discusses the need for standardized work breakdown structures (WBS) across project management tools and teams. It presents that without a common classification system, projects lack monitoring, scope management, prioritization, and the ability for stakeholders to exchange information. The document then examines the evolution of using multiple WBS, provides a case study analyzing the need for at least 3 WBS for effective project information management, and outlines considerations for defining rules for WBS use and linking deliverables to WBS for project handover. In conclusion, it emphasizes that complexity in projects requires project managers to have a strong professional background to effectively classify data and integrate information using WBS across systems.

1. Tracking project deliverables through
a standard definition of Project WBSs
Franco Concari – Technip & VP IPMA Italy
Luciano De Gaetano – Technip Italy

2. 2
Table of contents
1. Starting issue: people (and IT tools)
to speak the same language
2. Background & Evolution:
from “The WBS” to several WBSs
3. Objective & Scope: one tool for taking Project
Management decisions
4. A Case Study: the PM needs
at least 3 WBSs
5th PMS Steering Committee

3. OrganisationServicesShared
1. Starting issue
3
Background & origin
WBSs are a key for screening data and to allow PM to
elaborate information coming from different sources
Classification is a key for
project management
 Without classification
 No monitoring
 No ability to check scope fully
done
 No ability to prioritize and
decide on our actions
All projects need to classify
data
Discipline tools does not
prevent to built common
standards
 Identify what is common
 Let flexibility for adjustment
 Recollect information through
WBSs or screened Tagged
Objects
Different ways may exist
across different IT tools
Classifying give the ability to share
between project actors
 Establish a common vocabulary to
exchange
 On location
 On availability
 On % of achievments
 Some key classification shall be the
same between engineering /
procurement / construction / cost /
schedule / finance
Classification needs to be shared
by all project actors

4. 4
A pre-defined axis of similar properties allowing to sort object by groups
2. Background & Evolution
What is a Data Structure? - Simple but fundamental
I’ll put there
my blue
books
I’ll put there
my pink
books

5. 5
Allow ordering data so to find answer to questions easily and quickly
How many yellow pieces?
2. Background & Evolution
What are several Data Structures? - Like a Rubik cube

6. 3. Objective & Scope
 Giving access to Execution Project Data
 “Execution” data means raw data from E, P and C systems.
 Homogeneous reports for one or multiple projects
 Unified & exhaustive view of SOW
 Helping decision making by elaborating information
 Support project follow-up : PMs supported by actual & up to
date execution data
 Visualize plans and workloads
 Visualize unexpected events
Project Data 360° Browser6
Allow the PM to take decisions using data coming from
different technical and management IT systems

7. 3. A Case Study
 The question is: how many WBSs are needed to effectively
manage project information (in Oil&Gas industry)?
• The DDMS (Document&Data Man.System), based on SmartPlant Foundation as
developed in Technip, indentified 36 Data Structures possible for Project
Management and Execution. Too many ?
• A survey is under execution in Technip to identify which are the Data Structures
most commonly used by the E P C and PM stakeholders.
• A study was executed in Technip Italy with a Senior Project Director to understand
PM requirements:
• The rationale for a possible set of WBSs to be used in Project Management was defined
• The possible solutions for WBS use in EPC IT tools were proposed
• The scope is to “hand-over” all project deliverables to Client in an ordered and sequential
mode
Project Data 360° Browser7
Project Management needs at least 3 WBSs

8. 8
WBSs are split in two groups :
• 1st Group: SOW WBS - MANDATORY
Scope of Work Description based on 3 subjects, i.e.
• Operational (extended Process)
• Geographic
• Nature Code (Engineering, Procurement, Construction)
• 2nd Group: Execution WBS - OPTIONAL
“How to do” the Project based on SOW WBSs.
WBS
3. A Case Study

9. 9
SOW WBS
An example is given for the “Geographical” WBS (GBS) :
• Level 0 : The whole Project
• Level 1 : Block 1, Block 2, …. Etc.  Integer
• Level 2 : Area 1 in Block1, Area 2 in ..  1st, decimal
• Level 3 : Sub Area 1 in Area1 in Block 1, …..  2nd decimal
• Level 4 : Elevation 1 in Sub Area 1 ……  3rd decimal
This WBS is intrinsically :
• Structured in 5 levels;
• Homogenous because contains Geographical elements only;
• Consistent with the Project Plot Plan because gives names to each
portion of the Plot Plan with the required detail.
• Possible leading software: 3D Model
3. A Case Study

10. 10
An example is given for the “Operational” WBS (OBS) :
•Level 0 : The whole Project
•Level 1 : Group of Units (Utilities, Process, etc.) Integer
•Level 2 : Unit/System(Steam Prod., FCC, etc.)  1st, decimal
•Level 3 : Sub-System 1, Sub-System 2, etc. 2nd decimal
An example is given for the “Nature Code” WBS (NBS):
•Level 0 : The whole Project
•Level 1 : Design Disciplines, Materials, Works  Integer
•Level 2 : Discipline, Mater. Code, Works Code  1st, decimal
•Level 3 : Discipline, Mater. Code, Works Code  2nd decimal
•Level 4 : Discipline, Mater. Code, Works Code  3rd decimal
SOW WBS
3. A Case Study

11. TANKAGE
UTILITIES
PROCESS
OFF-SITE
Project Example
Example of Project WBSs
Process Unit 1
Off-site – Unit 3
Site 1
Site 2
Geographical WBS
Site 1 - Area 1
Operation WBS – Group of Units
3. A Case Study

12. Geographical WBS
Site 1 - Area 1 – Sub-
Area 3
3. A Case Study

13. 13
Geographical WBS – Site 1 – Area 1 – Sub-Area 3
Workfront Package 1 =
Process structure 33-04
3. A Case Study

14. 14
Structure 33-04 (E-W cross sect)(plan view)
Workfront Module 1
Geographical WBS – Site 1 – Area 1 – Sub-Area 3 - Workfront Package 1
3. A Case Study

15. 15
Process structure 33-04
Workfront Module 1
Geographical WBS – Site 1 – Area 1 – Sub-Area 3 - Workfront Package 1
3. A Case Study

16. Rules for WBSs use in management are to be defined (e.g.):
• All the 3 structures shall be consistently applied in the set-up of all Project
Management and Project Execution systems, at the different level required.
• It is highly reccomended that all project IT applications will be adequate to
manage the multiple WBS structure, in order to estabilish easy cross-links
among them.
• Engineering and Vendor deliverables, as well as physical deliverables, shall be
adequately identified for their use during Construction, Handing-Over and
Start-up, so to be properly associated to work-front and quality hand-over
processes.
• Construction and Subcontractor Work Package definitions shall respect the
boundaries of the areas defined by Geographical WBS.
• Others……
Mandatory WBSs management rules (examples)
3. A Case Study

17. 17
Issues and questions
Issues to be studied:
• Execute a proof of concept for WBSs use
• Define management rules
• Define types of tags to be managed: e.g. equipment, foundations,
structures, piping lines (or ISO’s?), cable runs ?, etc.
• Define types of tags parts needed for construction work-front
management: e.g. structures level, module, part of a packaged supply,
etc.
• Verify the possible application of Mandatory WBSs in the different IT
Systems
Questions:
• What to do in case an IT system is able to manage only one or
two of the mandatory WBSs ?
3. A Case Study

18. 18
A Deliverable is an item that needs to be handed-over to Client to
satisfy the scope of work according to Contract requirements.
The types of deliverables can be classified according to their nature:
1. Physical – An object (a pump, a foundation, a cable)
2. Descriptive – A drawing (engineering, fabrication, construction)
3. Certificate - A Quality Control Plan with relevant approved forms (for
fabrication, for erection, for commissioning/start-up)
4. Service – An activity (for technical assistance, for training)
Deliverables are to be properly tagged and attributed to the WBSs so to allow
the easy retrieval of information from the Project Execution Systems suitable.
This will allow to execute an easy control of their status of delivery up to the
“hand-over” to Client.
Deliverables
3. A Case Study

19. 19
A physical deliverable is an object that can be classified and
subdivided according to certain rules that allows to follow it
in the different IT tools:
• Parent Tag – A plant item needed to fulfill a specific process/mechanical/E&I
task (a package, a piping line, a process structure, a substation).
 Sub Tag – A plant sub-item needed to fulfill a specific
process/mechanical/E&I task (a vessel inside a package, a delivery package
of a process structure, a switchgear in a substation, an isometric, an
instrument).
 Component - A specific component with unique characteristics (a
spool relevant to an isometric, an electric breaker)
Sub-component “type” – A generic component with unique
characteristics (2” ASTM A105 pipe Sch. 40)
Sub-component – A specific component with unique
characteristics (Mark 236 of a steel structure)
Physical Deliverables
3. A Case Study

20. 20
It is usually handled by Company Material Data Management
Systems and it is univocally defined once it has been equipped
with the following information:
a) Located according to GBS
Example:
Run-down tank for FCC Wet Gas Compressor
GBS:
 Project: 2365
 Block: C
 Area: 061
 Sub-area: Zone 2
 Model Area: FA01
Physical Deliverables
3. A Case Study

21. 21
b) Classified according to OBS
Example:
Run-down tank for FCC Wet Gas Compressor
OBS:
 Function: Conversion
 Unit: Fluid Catalytic Cracking (FCC)
c) Linked to a material code, according to NBS
Example:
Run-down tank for FCC Wet Gas Compressor
NBS:
 Vessel: discipline code 08 (even if for compressor discipline code is 10)
 Small vessels: material code 11
Physical Deliverables
3. A Case Study

22. 22
A descriptive deliverable is a drawing that can be categorized according to
the following typologies:
• Engineering
• Requisitioning
• Procurement
• Fabrication
• Construction
• Precommissioning
• Commissioning
• Start-up
Some of the above deliverables are produced by the Engineering Contractor, some
by Vendor, others by Construction Subcontractors. The huge challenge is to
establish, since project initial stage, univocal rules for their codification according
to mandatory WBSs, in order to have them correctly assigned and retrievable.
Descriptive Deliverables
3. A Case Study

23. 23
They are produced by the Engineering Contractor (such as engineering
drawings) and a correct set-up of the IT Tools utilized during design stage,
according to standard & multiple WBSs, can allow an easy identification
and retrieval.
The descriptive deliverables produced by other entities (i.e. Vendors,
Subcontractors) are more difficult to be managed. In some cases these
entities can be requested to follow the project identification rules, but
sometimes these rules are not applied. In this case, an effort is required by
the Engineering Contractor to set-up in the Document Control System the
necessary associations of deliverables with the correct WBSs to allow their
handling.
Descriptive Deliverables
3. A Case Study

24. 24
A certificate deliverable is a signed form, part of an overall quality plan,
that attests the conformity of physical deliverables and works with
contract specifications during the following phases:
• Fabrication (provided by Vendor)
• Construction
• Pre-commissioning
• Commissioning
• Start-up
The fabrication certificates are provided by the Vendor and can be treated
as a Fabrication Descriptive Deliverables.
Certificate Deliverables
3. A Case Study

25. 25
Construction activities are subdivided in Work Categories (or Work
Classes), Subwork Classes, Work Steps and identified consistently with the
Nature WBS.
Quality Control Plans (QCP) are defined for Work Categories and are
including different Quality Control Forms (QCF), attesting different steps
and activities performed.
These deliverables to be easily retrievable shall use an identification code
containing the discipline code of the NBS. At the same type they must be easily
associated through IT tools to the physical deliverable certified to consolidate the
Quality Dossier at the project “hand-over” to Client.
Certificate Deliverables
3. A Case Study

26. 2626
Project Management needs
integrated project information
o To take decisions
• Correlating information coming from different
E P C discipline IT systems
• Aggregating information through WBSs
• Focusing the attention in the critical areas
o To proficiently deliver the Project to the Client
A Case Study: Conclusion
3. A Case Study

27. 27
The “hand-over” process to Client during the final stage of EPC execution is a
key factor for Project success.
• Physical Deliverables are to be correlated in Quality Dossiers with their relevant
Descriptive and Certificate Deliverables.
• Also the Punch Lists defined by Clients to accept the Physical Deliverables are to
be correlated.
• Hand-over IT Applications are needed to integrate information coming from
different project execution IT systems, to keep under control such critical activities
and to correlate them with all the involved deliverables .
The ability to easily recollect the information and status of any kind of deliverable is
essential in the “hand-over” process. A huge amount of data are to be managed,
collected, sorted, aggregated in short time.
This is possible ony if the Project Manager defined since the initial stage
proper Tagging rules for Deliverables and attribution rules to the multiple
WBSs and these are implemented in the set-up of IT project systems.
A Case Study: Conclusion
3. A Case Study

28. www.technip.com
Thank you

29. Conclusion as VP IPMA Italy
Project Management is more and more
a profession challenged by complexity

30. WBSs
Tagging rules
IT tools
Conclusion as VP IPMA Italy
Project Management is more and more
a profession challenged by complexity

31. 31
IPMA
Competence
Baseline
The ICB 3.0
Project Managers need a proper professional
background to face complex projects
(in IT or Oil&Gas Business)

32. 20 Elementi di
COMPETENZA
TECNICA
Metodologie,
tecniche e
strumenti di
Project
Management
15 Elementi di
COMPETENZA
COMPORTAMENTALE
Rapporti e interrelazioni
fra individui e gruppi che
operano all’ interno dei
Progetti
11 Elementi di
COMPETENZA
CONTESTUALE
Interazione del
project team con
il contesto in cui si
svolge il progetto
Competenze
Comportamentali
Competenze
Tecniche
Competenze
Contestuali
IPMA Italy is able to deliver this background

33. L’ENTE UNICO AUTORIZZATO
ALLA DIFFUSIONE IN ITALIA
DELLA CERTIFICAZIONE DEI
PROJECT MANAGER SECONDO
LA METODOLOGIA
IPMA
IPMA Italy