OKADiA

Time
Management
Knowledge Brief
PROJECT MANAGEMENT #04
OKADiA
L’Essentiel Okadia - Module 4/12
™

Project Schedule Network

REQUIREMENT TRACEABILITY MATRIX Activity ID Description PLM WBS
1.0
Project Name 1.0
Project Description 1.1 1.1

#01 PM FUNDAMENTALS
Requirement Business & Project 1.2
ID Sub-ID Project Activity PLM WBS 1.2
Description Customer Needs Objectives
2.0
1.0
2.1 2.0
001 1.1
2.2

#02 PM ADVANCED
2.1
1.2
3.0
2.0 2.2
3.1
002 2.1
3.2 2.0

#03 PROJECT CHARTER

2.2
4.0
2.1
3.0 4.1
003 3.1 4.2 2.2
3.2

#04 TIME MANAGEMENT 004

4.0
4.1
FS : Finish to Start 1.0 1.1 SF : Start to Finish 1.0 1.1 FS Lead : 2 weeks 1.0

4.2 1.1

#05 QUALITY MANAGEMENT

5.0 FF : Finish to Finish 1.0 SS : Start to Start 1.0 SS Lag : 2 weeks 1.0
005 5.1
1.1 1.1
5.2 1.1

#06 COST MANAGEMENT Project Schedule Critical Path Milestone Schedule

Activity ID Description Skills Resource Duration Project Schedule Time Frame - PLM
Activity ID Description Unit

#07 RISK MANAGEMENT

1.0 Period 1 Period 2 Period 3 Period 4 Period 5
1.0 1.0 0
1.1
1.1 0
1.2
1.2 0

#08 VALUE BASED MANAGEMENT

2.0
2.1 1.2 Summary Schedule
2.2 Project Schedule Time Frame - PLM
Activity ID Description Unit
3.0 Period 1 Period 2 Period 3 Period 4 Period 5

#09 LEADING PROJECT

1.0 Develop 120
3.1
1.3 1.0.1 WP 1.0 - X 67
3.2 2.0
1.0.2 WP 1.0 - X 53
4.0
Detailed Schedule

#10 CHANGE MANAGEMENT

4.1
Project Schedule Time Frame - PLM
4.2 Activity ID Description Unit
2.1 Period 1 Period 2 Period 3 Period 4 Period 5
1.0 0

#11 PERFORMANCE MANAGEMENT

1.0 Develop 120
Early Duratio Early
Start Start n 1.0 Finish 1.0.1 WP 1.0 - X 67
2.3 1.0.1 – A Activity 13
Late Start Float Late Finish
Finish

#12 CPM CERTIFICATION PREPARATION

1.0.1 – B Activity 20

1.0.1 – C Activity 20

REQUIREMENT TRACEABILITY MATRIX – SEQUENCE ACTIVITIES – ESTIMATE ACTIVITIES

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

Project Name Sponsor Project Leader

La Gestion des Temps Projet nécessite
Core Team
un certain nombre d’inputs « clés » et
matures (données d’entrée) formalisés Name Organization Role
et validés par l’équipe Projet au travers Objectives and scope
du Project Charter :
PROBLEM STATEMENT PROJECT OBJECTIVES (AS-IS / TO-BE)
Problem Statement I
• Project Core Team
I I Project Plan
• Problem Statement
Milestones PLM Maturity Date
• Project Objectives QUALITATIVE BENEFITS
Initiating
Business need
• Business Needs Planning
I Executing
• Project Scope I
I Closing
• Qualitative Benefits Estimated Cost
• Quantitative Benefits Project scope (IS / IS NOT) QUANTITATIVE BENEFITS Cost PLM Maturity Budget
IS: Initiating
• Major Milestones
Planning

I Executing
IS NOT I
* La définition et la formalisation de ces Closing
Inputs est expliquée dans le module PM#03
: Project Charter. Estimated Benefits
METRICS MSA VALIDATION
Target PLM Maturity Confirmed
Sponsor
Initiating
Project Leader
I Planning
INPUTS PMO
Executing
Finance Closing

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

La Gestion des Temps Projet

PROBLEM TO SOLVE SOLUTION
nécessite un certain nombre d’inputs
« clés » matures (données d’entrée)
formalisés et validés par l’équipe
Projet au travers du Business Model :

I I
• Problem to solve
ADDED VALUE
• Opportunity
• Solution
• Main Characteristics
OPPORTUNITY MAIN CHARACTERISTICS

* La définition et la formalisation de ces

Inputs est expliquée dans le module
PM#03 : Project Charter.

I
I

I INPUTS INVESTMENT & ROI

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

La Gestion des Temps Projet nécessite un REQUIREMENT TRACEABILITY MATRIX

certain nombre d’inputs « clés » matures
(données d’entrée) formalisés et validés Project Name
par l’équipe Projet au travers de la Project Description
Traceability matrix :
Requirement Business & Project
ID Sub-ID Project Activity PLM WBS
Description Customer Needs Objectives
1.0 I I I
• Requirement Description
001 1.1
• Business & Customer Needs
1.2
• Project Objectives
2.0

002 2.1
* La définition et la formalisation de ces 2.2
Inputs est expliquée dans le module PM#03 :
Project Charter. 3.0

003 3.1
3.2
4.0

004 4.1
4.2
5.0

I INPUTS 005 5.1

5.2

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

WBS

La Gestion des Temps Projet nécessite un INITIATE - PLAN EXECUTE CLOSE

certain nombre d’inputs « clés » matures
(données d’entrée) formalisés et validés par
l’équipe Projet au travers du WBS:

• WBS Architecture
WP1 WP4 WP7
• WP Description
I I I
* La définition et la formalisation de ces Inputs
est expliquée dans le module PM#03 : Project
Charter. WP2 WP5 WP8

I I I

WP3 WP6 WP9

I I I

I INPUTS

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

REQUIREMENT TRACEABILITY MATRIX

Project Name
Project Description
Business & Project
ID Sub-ID Requirement Description Project Activity PLM WBS
Customer Needs Objectives
Détailler la Description des Activités 1.0
1 pour les Transformer en Action - RACI
001 1.1 1 2

Indiquer quel WBS est concerné par ce 1.2

2
plan d’Action. 2.0

002 2.1 3
Indiquer quelle Phase du PLM est
3
concernée par ce plan d’Action 2.2
Vérifier que l’ensemble des Besoins & 3.0
4 Exigences est associé à un plan
d’Action – RACI 003 3.1
Vérifier que l’ensemble des phases PLM 3.2
5 et livrables Critiques sont considérées
dans le plan d’Activités 4.0

Vérifier que l’ensemble des Work 004 4.1

6 Packages sont considérés par le plan
d’Acticités.
4.2
5.0

005 5.1
5.2

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

Project Schedule Network

Activity ID Description PLM WBS
1.0
1.0
1.1 2 1.1
Valider et Communiquer la Matrice 1.2
d’Activité auprès de l’équipe Projet en 1.2
1 vérifiant que le plan d’action est clair et
2.0
SMART 2.1 2.0
Positionner l’ensemble des Activités 2.2 1
2 2.1
Plan d’Action sur une surface Vierge
3.0
Définir la logique d’enchainement de
3.1 2.2
chaque activité et sa dépendance avec
3
les autres activités en fonction des lien
logiques 3.2 3 3.0
Utiliser uniquement les liens logiques 4.0
4 3.1
standards afin de permettre le pilotage
Projet. 4.1
4.2 3.2

4
FS : Finish to Start 1.0 1.1 SF : Start to Finish 1.0 1.1 FS Lead : 2 weeks 1.0

1.1

FF : Finish to Finish 1.0 SS : Start to Start 1.0 SS Lag : 2 weeks 1.0

1.1 1.1
1.1

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

Project Schedule Critical Path

Activity ID Description Skills Resource Duration
1.0 1 2 3 4
1.0
1.1
1.2
Reporter la description du plan d’action
1 associés à chaque Activité
2.0

Identifier les Compétences,

2.1 1.2
Connaissance, Expérience et Expertise 2.2
2
nécessaire à la réalisation de chaque
plan d’action 3.0
Identifier les ressources nécessaire et 3.1
3
leur disponibilités 1.2
3.2 2.0
Définir la durée nécessaire de l’activité 4.0
4 pour finaliser le plan d’action en
fonction de la disponibilité des 4.1
Ressources.
4.2
5 Définir le Chemin Critique du Projet
5 2.1

Early TF Early
Start Start 1.0 Finish Finish
2.2
Late FF Late

TF = TOTAL FLOAT / FF = FREE FLOAT I

I INPUTS

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

Milestone Schedule
La Gestion des Temps Projet permet Project Schedule Time Frame - PLM
d’aboutir à la formalisation d’un Planning Activity ID Description Unit
Period 1 Period 2 Period 3 Period 4 Period 5
qui doit comporter 3 dimensions :
1.0 0

1.1 0
• Milestone Schedule (Communication) 1.2 0
• Summary Schedule (Pilotage)
Summary Schedule
• Detailed Schedule (Management) Project Schedule Time Frame - PLM
Activity ID Description Unit
Period 1 Period 2 Period 3 Period 4 Period 5
1.0 Develop 120
La formalisation d’un planning basé sur la
disponibilité des Ressources donne 1.0.1 WP 1.0 - X 67
toujours lieu à un besoin d’optimisation.
1.0.2 WP 1.0 - X 53
Cette phase d’optimisation doit être
réalisée uniquement dans un second Detailed Schedule
temps et ne doit jamais être considérée
Project Schedule Time Frame - PLM
comme une donnée d’entrée. Activity ID Description Unit
Period 1 Period 2 Period 3 Period 4 Period 5
1.0 0

1.0 Develop 120

1.0.1 WP 1.0 - X 67

1.0.1 – A Activity 13

1.0.1 – B Activity 20

1.0.1 – C Activity 20

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

Project Name Sponsor Project Leader

La Gestion des Temps Projet doit Core Team
permettre de mettre a jour le Project
Charter : Name Organization Role
Objectives and scope

PROBLEM STATEMENT PROJECT OBJECTIVES (AS-IS / TO-BE)

• Project Scope Problem Statement M
• Metrics
Project Plan
• Core Team
Milestones PLM Maturity Date
• Major Milestones QUALITATIVE BENEFITS
Initiating
Business need
Planning
M Executing
Closing

Estimated Cost
Project scope (IS / IS NOT) QUANTITATIVE BENEFITS Cost PLM Maturity Budget
IS: Initiating
Planning

M Executing
IS NOT
Closing

Estimated Benefits
METRICS MSA VALIDATION
Target PLM Maturity Confirmed
Sponsor
Initiating
M Project Leader M
Planning
PMO
Executing
Finance Closing
M MISE A JOUR
This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

La Gestion des Temps Projet doit

PROBLEM TO SOLVE SOLUTION
permettre de mettre a jour le
Business Model :

• Solution
• Main Characteristics M
ADDED VALUE

OPPORTUNITY MAIN CHARACTERISTICS

INVESTMENT & ROI

M MISE A JOUR
This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

La Gestion des Temps Projet doit REQUIREMENT TRACEABILITY MATRIX

permettre de mettre a jour la
Traceability Matrix: Project Name
Project Description
Business & Project
• Project Activities ID Sub-ID Requirement Description Project Activity PLM WBS
Customer Needs Objectives

• PLM 1.0 M M M

• WBS 001 1.1

1.2
2.0

002 2.1
2.2
3.0

003 3.1
3.2
4.0

004 4.1
4.2
5.0

005 5.1
5.2

M MISE A JOUR
This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

WBS

La Gestion des Temps Projet doit INITIATE - PLAN EXECUTE CLOSE

permettre de mettre a jour le WSB :

• WBS Architecture
• WP Description
WP1 WP4 WP7

M M M

WP2 WP5 WP8

M M M

WP3 WP6 WP9

M M M

M MISE A JOUR
This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

SYSTEM

La Gestion des Temps Projet doit SUB SYSTEM 0 SUB SYSTEM 1 SUB SYSTEM 2
permettre de mettre a jour le PBS :
M M M

• System
• Sub- System
COMPONENT 0.1 COMPONENT 1.1 COMPONENT 2.1
• Components
M M M

COMPONENT 0.2 COMPONENT 1.2 COMPONENT 2.2

M M M

COMPONENT 0.3 COMPONENT 1.3 COMPONENT 2.3

M M M

M MISE A JOUR
This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
Guideline Okadia - Module 4/12
™

PM PMO
M
M ASSISTANT

La Gestion des Temps Projet doit LEADER LEADER LEADER

permettre de mettre a jour l’OBS :
M M M

• Core Team
• Multi Functional Team
WP LEADER WP LEADER WP LEADER

M M M

WP LEADER WP LEADER WP LEADER

M M M

WP LEADER WP LEADER WP LEADER

M M M

M MISE A JOUR
This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 8/20
™

CREATION OF THE SPECIFICATION

You and the core team define the work and services to be performed, specify the main
prerequisites to be met and identify all the things which have to be taken into
consideration. You prepare a performance specification. Sometimes, if the organization
has a quality management system, the performance specification will have a standardized
format. If there is no standard format, the following structure can be used. All it takes is a
little imagination and adaptation and you have the basis for a summarization of all
expectations and requirements.

What is a specification?

The specification forms the bridge between good performance, cost control and
scheduling. It also determines goal-based requirements. Specifications are a means of
ensuring that project outcomes (goals) are determined before the project is carried out.

There are two types of specifications:

• Requirement specification
• Performance specification

The requirement specification is from the customer's point of view, the performance
specification from the supplier's perspective. In the tender process, the requirements
specification is prepared by the customer and the performance specification is prepared
by the supplier in response to the customer's requirements specification.
A specification is important for a project in order to define and quantify characteristics
(tolerance values) of the work or services performed by the supplier which are checked by
the customer or buyer in the hand-over procedure prior to acceptance or purchase, i.e.
the supplier can demand payment if the characteristics in the specification are met. So, a
specification is like a checklist for your project.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 8/20
™

CREATION OF THE SPECIFICATION

Quality management

The conformity of the requirement and the performance specification is called quality.

Quality is important to satisfy the customer and - maybe - guarantees deals with this
customer in the future. That's the reason why the quality in a project needs to be planned
carefully. A quality management system as well as a project management manual is
helpful for this undertaking.

Configuration management

The specifications are written down, the quality is clear. But how to check, if you're still on
the right path?

For this, you can use configuration management.

In this context, a configuration is defined as the

• functions and physical features of a product or service as described in the supporting

documents and implemented in the product,
• detailed and complete compilation and documentation of project results and their
systematic updating when project changes are implemented.

Configuration management is a management discipline that is applied throughout the

entire lifecycle of a product to ensure transparency and guarantee that it incorporates the
agreed functional and physical features. The main objective is to document the current
configuration of a product, as well as the extent to which it satisfies physical and
functional requirements and to ensure absolute transparency in these respects.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 8/20
™

CREATION OF THE SPECIFICATION

Configuration identification

This comprises the following tasks:

• Defining the product structure and selecting configuration units (= reference

configuration)
• Documenting the physical and functional characteristics of configuration elements
(in clearly identified configuration documents)
• Establishing and usage of rules for:

o Numbering configuration elements and sub-elements

o Structuring documents
o Interfaces
o Changes
o Approvals during and after realization (e.g. parts-list structures for the
production team or document identification systems)

• Establishing reference configurations based on formal agreements that constitute

together with the approved changes to the latest version of the agreed (i.e. valid)
configuration

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 8/20
™

CREATION OF THE SPECIFICATION

Configuration control : This comprises the following tasks

• Documentation of the cause or reason for changes (e.g. customer request or design
defect that had not been previously identified)
• Assessment of the impact of changes (e.g. with/without consequential changes)
• Approval or rejection of changes (with reasons, e.g. additional benefits or costs of the
consequential changes are higher than the projected benefit)
• Processing of special approvals before or after implementation (e.g. additional services
or features that were only identified as necessary after the first tests were carried out)

At this point, configuration control and change control overlap: configuration control
adapts interfaces in terms of data and shapes, while change control relates to changes in
documents.

Configuration accounting : This ensures the traceability of individual changes (e.g.

changes that must be approved by state supervisory authorities). In this case,
configuration accounting and document management overlap.

Configuration auditing : There are two types of configuration audit:

1. Function-related configuration audit

Formal audit of a configuration unit to ascertain whether it satisfies the performance and
functional characteristics which were specified in the configuration documents (e.g.
acceptance certificate in respect of work performed).
2. Physical configuration audit
Formal audit of the as-built configuration of an element to ascertain whether it
corresponds to the information provided in the configuration documents (e.g. design
drawings with the status "as built").

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 9/20
™

CREATION OF THE PHASE MODEL

Process models

Over the past decades, numerous process models have been developed that can be used
by project managers. There are company-specific and industry-specific variants (e.g.
phase or process models, stage gate models), they should each be used for a specific
project type (e.g. IT-projects, projects in plant construction). However, there are
also general procedure models (e.g. PRINCE 2) that can be adapted to the respective
project type.

Overall, process models can consist of the following elements:

• Project phases / Activities / Milestones / Milestone results

The advantages of process models are amongst others:

• Manageable complexity by structuring

• Establishment of a common understanding in the organization
• Assistance and instructions for the project manager
• Risk minimization
• Transparency for the controller and key quality management tool
• Error recognition and defect elimination
• Interim results provide project team members with guidance and aid their fast
integration in the project
• Procedures involving sequential phases correspond to the behavior of humans when
solving complex tasks

There exist two models for the realization of projects. The evolutionary model is based on
a stage-by-stage upgrades (versions) and often used in software development. Whereas
the incremental model specifies the requirements at the beginning of a project.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 9/20
™

CREATION OF THE PHASE MODEL

Phase plan

If the project budget and the timeframe have to be planned, a simple yet effective way of
doing this is to create a phase plan. This process model divides a project up into
individual phases, each phase begins or ends with a milestone or another measurable
event. A new phase cannot start until the previous one is completed.
To do so, it is advised to create the phase model in a workshop with the team, maybe a
standard phase model is useful here. As an orientation on how to name the phases, here
is an example for each project type:

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 9/20
™

CREATION OF THE PHASE MODEL

After each phase is defined, the next step is to estimate how much time and budget each
phase needs. Estimating in a team offers great benefits, like creating a common basis for
communication, bringing light to as many undisclosed assumptions and prerequisites
relating to the project or it provides the earliest possible ascertainment of the total project
costs.

To do this, there are two approaches for making an estimate.

Bottom-up
Starting from scratch, the values for each phase are estimated separately and later
summed up.
Top-down
Starting from a total of 100%, each phase is set in relation to each other. Then it is
estimated, how much (in %) each phase contributes to the whole project.
Then all together is written down in a table:

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 10/20
™

CREATION OF THE WBS

Conscientious people often write a checklist containing all the tasks to be performed
before any major personal project (e.g. a holiday, a family celebration).

In the same way, project managers and their teams should prepare a similar list at the
earliest opportunity - in other words, a work breakdown structure (WBS) containing the
activities that a project involves. In contrast to personal checklists, a WBS
generally consists of several levels, i.e. it has a hierarchical structure.

There are a number of rules to be observed when developing a WBS. To avoid that
important sub-tasks are overlooked, mostly this is the centrepiece of many extensive
projects.

• Project structuring is the process of breaking down a project into work units and tasks.
• WBS is a chart or table showing the structure of the project and a systematic answer to
the question: "What work does our project involve?".
• It is a hierarchical representation of the project, broken down into several levels.
• The structure can be based around objects, sub-tasks or business units.

The WBS is a useful tool for organising related work packages and the overall project, for
uncovering ambiguities in the target definition or for preparing work packages for
external processing.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 10-11/20
™

CREATION OF THE WBS - WP

"What do we have to do to solve the problem? »

Remember that the answers to the question do not initially provide any information about
expected costs or time required. The WBS does not contain project objectives nor
process objectives. This information is obtained on the basis of the defined work
packages, which will be dealt with later on.

In the first step, every team member individually writes down his or her answers, ensuring
that they don't just write keywords, but phrases (wrong: "list", right: "create list"). This is a
classic creativity technique called brainwriting. The first step of the process can also be
supported by mind mapping or similar methods. All answers are then written on Metaplan
cards.

Then a moderator is nominated. He or she has to compile the individual team members'
answers into clusters and define headings for each cluster. When all the topics have been
clustered, another check is made to see whether any more headings or tasks will be
necessary to ensure completeness.

The now defined work packages are delegated to the team members for precise
definition.

The lowest hierarchical classifications in each branch of a WBS are known as work
packages (WP). They cannot be sub-divided any further. On the other hand, tasks that are
sub-divided are called sub-tasks (ST). WPs can be found at any hierarchical level and
responsible persons can be project team members, departments of the company or even
external companies. Persons responsible for the respective work package (work package
owner) report to project management on progress and don't need necessarily to know
the holistic context of the project.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 11/20
™

WORK PACKAGE DESCRIPTION

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 11/20
™

WORK PACKAGE DESCRIPTION

Remember that the answers to the question do not initially provide any information about
expected costs or time required. The WBS does not contain project objectives nor
process objectives. This information is obtained on the basis of the defined work
packages, which will be dealt with later on.
Routine work packages must always be included in the WBS, since they also have to be
performed and will consume resources. If work packages are non-routine, it is necessary
to provide a detailed description of them according to a specific scheme. There are no
firm rules, however, for formulating such descriptions. Each organisation can define them
in accordance with its own requirements. As a minimum, however, the descriptions should
always include:

• Name, number, version and status (planned, tested, released) of the work package
• Brief description of content
• Projected results to be obtained
• Prerequisites for performance (e.g. deliveries required)
• Projected commencement and completion dates or projected duration
• Projected costs (generally unit costs, e.g. person days)
• Person responsible for the work package

Often, further information is given, such as

• regulations that staff must observe when performing the work packages (e.g. safety
regulations or the organisation's quality management manual), or
• specific activities which need to be performed by the person responsible for the work
package so that the work package can be executed.
The organisational unit with responsibility for the work package is in charge for preparing
a detailed description of the activities that must be performed, in order to realise it. If a
work package is further divided, in general the project management office (PMO) has not
to be informed. By the time that the work package is specified, the person in charge
provides the work package description to the PMO. After all, the project manager is
responsible for the timely implementation of the project within budget and in compliance
with the agreed quality standards and has to make sure everything is on track.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 11/20
™

WORK PACKAGE DESCRIPTION

Rules for work package creation

The following general guidelines can be formulated for the creation of WPs:

Only one person should be accorded responsibility for each work package - irrespective
of how many people will be working on it.

1. In phase-oriented project management, it should be possible to assign each work

package to one specific phase. Exceptions are multi-phase tasks, such as the ongoing
monitoring of costs.

2. Tasks that are outsourced should be labelled as stand-alone sub-tasks or work

packages.

3. A clear specification should be formulated for each element of the WBS so that third
parties can easily monitor, whether the work package or sub-task has already been
carried out (otherwise the project manager will not be able to track the project's
progress).

4. A work package should be, if possible, defined as a closed-end performance element

that differentiates from another and is linked to other work packages in a clear and
straightforward way.

The time allocated for completing the work package should be appropriately short in
comparison to the overall project lifecycle. Otherwise, there is a risk that the project
manager identifies a delay too late to implement effective counter measures. Work
packages that are performed throughout the entire project, such as "planning and
monitoring time schedules" are exceptions.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 12/20
™

PROCESS & TIME SCHEDULE

You as a project manager, will need a toolbox to plan, control and monitor the
implementation of the project. Taking technical and economic considerations into
account, the project is set up
• within a specific timeframe (deadlines),
• with limited budget or resources and
• by focusing on the objectives.
You remember these three terms? Great! That's the magic triangle of time, cost and
quality, which you already know. The methods and processes of time scheduling are the
key to the operational realisation of these objectives.
Process scheduling is a valuable aid to project planning in the early phase of the project
and it enables you to consider alternative schedules and solutions taking deadlines, costs
and resources into account. It supports the project planners and coordinators because it
enables them to clarify the critical interfaces between individual parts of the project well in
advance. It is based on project structuring. If necessary, the planner breaks down the work
packages into even smaller units, which are called activities. This simplifies the process of
estimating implementation times and resource requirements, thereby creating the basis
for cost estimates.
When the process sequences have been established and times have been allocated to
the tasks to be performed, the process schedule becomes the time schedule - and
therefore the timetable for the project. Time scheduling delivers targets and, based on
the cyclical acquisition of feedback data, provides an on-going record of the project's
current status. This provides a platform where you and your team can monitor and
manage deadlines, resources, costs and activities.
Network analysis plays a central role in time scheduling. With the assistance of the
network diagram it is possible to map interdependencies between processes and
deadlines and calculate the scope available for time scheduling and deadline
management. If deviations from the planned project lifecycle are ascertained, your project
team can use the network diagram to forecast possible consequences for subsequent
work packages, sub-projects or project close-out, as well as test countermeasures. This
acts as an early warning system so that the team can implement timely corrective
measures.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 12/20
™

TIME SCHEDULE STEPS

Time scheduling is a step-by-step approach to obtaining the above mentioned
information.

Network diagram : The network diagram shows processes and activities and their
interdependence is visualised in a graph or table. Activities can be work packages or even
smaller units which are visualised in the network diagram according to their chronological
position. Based on the network diagram, communication instruments can be worked out
which will support the project in its further course.
Anyone who has ever seen a network diagram knows that it can look intimidating. But
don't worry - follow the steps below and you'll see that even the network analysis is not
witchcraft.

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 12/20
™

TIME SCHEDULE INTEGRATION

• Activity number (e.g. taken from the WBS)

• Person responsible/work package owner (responsibility for the performance of each

activity is allocated to an individual, department or other unit)

• Duration of the activity (can be stated in time units such as days, weeks or months,
sometimes hours or minutes are used); activities with a duration = 0 are so-called
events, i.e. milestones

• Activity description (description of an activity states briefly what the activity comprises,
more detailed description is given in WP description)

• Deadlines:
• Fixed earliest start time (EST) or latest start time (LST) can be specified for every
activity in the network diagram
• Based on the EST and LST the earliest finish time (EFT) and the latest finish time
(LFT) can be calculated

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 12/20
™

TIME SCHEDULE INTEGRATION

The precedence relationships determine the logical sequence in which the project team
realizes the individual activities. There exist four different options.

• Forward pass calculation: Calculation of the earliest points in time or deadlines for all
activities in the project network diagram

• Backward pass calculation: Determination of the latest reference dates for all activities in
the network diagram

• Forward and backward pass calculations are prerequisites for the definition of the critical
path and reserve (= float).

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
OKADiA
L’Essentiel IAPM – Thème 12/20
™

TIME SCHEDULE INTEGRATION

Calculate floats and determine the critical path. There exist two types of floats which need to
be calculated first
.
Please Note: AC means activity and SA stands for subsequent activity

• Total float (TF): The time between the earliest and latest position of an event or activity
(predecessor activity in earliest position and successor activity in latest position)
TF = LSTAC - ESTAC = LFTAC - EFTAC

• Free float (FF): The time by which a predecessor activity can be delayed from its latest
position without altering the latest position of other events or activities
FF = ESTSA - EFTAC

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.
 OKADiA
L’Essentiel
™

Project Time Management Schedule Types : Milestone – Summary - Detailed

Milestone Schedule
Le Project Time Management fait partie intégrante de la gestion globale du Project Schedule Time Frame - PLM
Activity ID Description Unit
projet et vise principalement à établir un « calendrier » permettant 1.0 0
Period 1 Period 2 Period 3 Period 4 Period 5

l'achèvement d'un projet. 1.1 0

1.2 0

Le Project Time Management se compose de six composantes : Summary Schedule

• Définition des Activités Activity ID Description Unit

Period 1
Project Schedule Time Frame - PLM
Period 2 Period 3 Period 4 Period 5

• Définition des Séquences d’Activités 1.0 Develop 120

• Estimation des Ressources d’Activités 1.0.1 WP 1.0 - X 67

1.0.2 WP 1.0 - X 53
• Estimation des Durées d’Activités Detailed Schedule
• Définition et Surveillance du « calendrier » d’achèvement du Projet. Activity ID Description Unit
Project Schedule Time Frame - PLM
Period 1 Period 2 Period 3 Period 4 Period 5
1.0 0

1.0 Develop 120

Activity Sequence 1.0.1 WP 1.0 - X 67

Project Schedule Network 1.0.1 – A Activity 13
Activity ID Description PLM WBS
1.0.1 – B Activity 20
1.0
1.0
1.0.1 – C Activity 20
1.1 1.1
1.2
1.2
2.0
2.1 2.0
Le Project Time Management doit être impérativement dynamique &
2.2
2.1 proactif tout en impliquant la contribution d’équipes multi fonctionnelles
3.0
3.1
2.2 permettant d’intégrer l’ensemble des composantes et contraintes pouvant
3.2 2.0 impacter la gestion du temps au sein du projet.
4.0
2.1
4.1
4.2 2.2

OKADIA ™
FS : Finish to Start 1.0 1.1
By Okane Consulting Group
SF : Start to Finish 1.0 1.1 FS Lead : 2 weeks 1.0

1.1

FF : Finish to Finish 1.0 SS : Start to Start 1.0 SS Lag : 2 weeks 1.0

1.1 1.1
1.1
www.okadia-exed.com contact@okadia-exed.com

This document is the property of Okane Consulting Group. It may not be used, reproduced or transmitted without their approval.