tracking project wbs
TRANSCRIPT
Tracking project deliverables through a standard definition of Project WBSs
Franco Concari – Technip & VP IPMA Italy
Luciano De Gaetano – Technip Italy
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
Organisation Services Shared
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
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
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
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° Browser 6
Allow the PM to take decisions using data coming from
different technical and management IT systems
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° Browser 7
Project Management needs at least 3 WBSs
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
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
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
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
Geographical WBS
Site 1 - Area 1 – Sub-
Area 3
3. A Case Study
13
Geographical WBS – Site 1 – Area 1 – Sub-Area 3
Workfront Package 1 =
Process structure 33-04
3. A Case Study
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
Process structure 33-04
Workfront Module 1
Geographical WBS – Site 1 – Area 1 – Sub-Area 3 - Workfront Package 1
3. A Case Study
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
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
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
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
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
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
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
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
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
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 26
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
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
www.technip.com
Thank you
Conclusion as VP IPMA Italy Project Management is more and more a profession challenged by complexity
WBSs
Tagging rules
IT tools
Conclusion as VP IPMA Italy Project Management is more and more a profession challenged by complexity
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)
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
L’ENTE UNICO AUTORIZZATO ALLA DIFFUSIONE IN ITALIA DELLA CERTIFICAZIONE DEI PROJECT MANAGER SECONDO LA METODOLOGIA IPMA
IPMA Italy