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