MPP Management Par Projet

QMS
PROJECT MANAGEMENT GUIDELINES

MPP - MANAGEMENT PER PROJECT
Rfrence: DOC-MPP-ManagementParProjet-EN.doc
V 1.0
Rfrentiel de gestion de projet - MPP - Management Par Projet
Revisions
Date
Revision
Subject
Drafted by
April 01,
2007
1.0
Approved by
Document created using procedures from the QMS guidelines

Soudy Eric Quality Director
Fleury Didier - CIO
Reference documents
Title
Origin
Project
CMMI Capability Maturity Model Integration

MPP Management By Project guidelines poster
MPP Management By Project guidelines
SEI
Company
Company
CMMI
QMS
QMS
COMPANY/DSI
TABLE OF CONTENTS
1
FIELD OF APPLICATION ......................................................................................................................... 6

1.1
1.2
1.3
IDENTIFICATION ....................................................................................................................................... 6
BASIC POINTS ABOUT QMS ...................................................................................................................... 6
BASIC POINTS ABOUT THE DOCUMENT ..................................................................................................... 6
GENERAL PRESENTATION OF MANAGEMENT BY PROJECT ..................................................... 7
TERMINOLOGY ......................................................................................................................................... 8
3.1
PRODUCT/PROGRAM ................................................................................................................................ 8
3.2
PROJECT OWNERSHIP ............................................................................................................................... 8
3.3
CATEGORY ............................................................................................................................................... 8
3.4
CONCEPT OF CRITICITY ......................................................................................................................... 9
3.5
PROJECT ORGANIZATION ........................................................................................................................ 10
3.5.1
Project referencing ........................................................................................................................ 10
3.5.2
PBS (Product Breakdown Structure) ............................................................................................ 10
3.5.3
WBS (Work Breakdown Structure) ................................................................................................ 11
3.5.4
OBS (Organizational Breakdown Structure) ................................................................................. 12
3.6
GLOSSARY ............................................................................................................................................. 13
DEFINITIONS OF FUNCTIONS AND ROLES ..................................................................................... 14

4.1
PROJECT MANAGER ............................................................................................................................... 14
4.1.1
Job description .............................................................................................................................. 14
4.1.2
Positioning and relational modes.................................................................................................. 14
4.1.3
Tasks and responsibilities ............................................................................................................. 15
4.1.4
Capabilities ................................................................................................................................... 17
4.2
WORK PACKAGE MANAGER .................................................................................................................. 17
4.2.1
Job description .............................................................................................................................. 17
4.2.2
4.2.3
4.2.4
Capabilities ................................................................................................................................... 19
4.2.5
Examples of work package scopes ................................................................................................ 20
4.3
PROJECT QUALITY MANAGER ................................................................................................................ 20
4.3.1
Job description .............................................................................................................................. 20
4.3.2
4.3.3
4.3.4
Capabilities ................................................................................................................................... 22
4.4
PROJECT COORDINATOR ........................................................................................................................ 22
4.4.1
Job description .............................................................................................................................. 22
4.4.2
4.4.3
4.4.4
Capabilities ................................................................................................................................... 23
4.5
CONFIGURATION MANAGEMENT LEADER .............................................................................................. 24
4.5.1
Description of the role................................................................................................................... 24
4.5.2
Primary tasks and responsibilities ................................................................................................ 24
4.5.3
Who may occupy the position of CML ........................................................................................... 25
4.6
CHANGE REQUEST MANAGEMENT LEADER ........................................................................................... 25
4.6.1
Description of the role................................................................................................................... 25
4.6.2
Primary tasks and responsibilities ................................................................................................ 25
4.6.3
Hierarchical and operating positions ........................................................................................... 26
4.6.4
Who may hold the position of CRML? .......................................................................................... 26
PROJECT AUTHORITIES ....................................................................................................................... 27

5.1
THE STEERING COMMITTEE (COPIL) .................................................................................................... 27
5.2
THE PRODUCT MANAGEMENT COMMITTEE (CODIR) ........................................................................... 27
5.3
IMPACTS ON STANDARD HIERARCHICAL RELATIONSHIPS ....................................................................... 29
5.3.1
Diagram of established relationships (not including Project Coordination and Project Quality) 29
COMPANY/DSI
5.3.2
5.3.3
5.3.4
6
Impacts on the hierarchical authority of the Project Managers supervisor ................................ 29

Impact on the hierarchical authority of the Work Package Managers supervisor ...................... 29
Positioning of Project Coordination and Project Quality ............................................................. 30
MANAGEMENT BY PROJECT PROCESS ........................................................................................... 31

6.1
DESCRIPTION OF THE PROCESS ............................................................................................................... 31
6.2
AUTHORITY CHARTS.............................................................................................................................. 33
6.3
PROJECT PROCEDURE ............................................................................................................................. 34
6.3.1
STEP 1 Definition of the projects target ................................................................................... 35
6.3.2
STEP 2: Definition of the project reference .................................................................................. 44
6.3.3
STEP 3: Tracking the projects progress ...................................................................................... 46
6.3.4
STEP 4: Project Reviews and Reports .......................................................................................... 48
QUALITY ASSURANCE PROCESS ....................................................................................................... 52

7.1
DESCRIPTION OF THE PROCESS ............................................................................................................... 52
7.2
ROLES AND RESPONSIBILITIES ................................................................................................................ 52
7.3
PROCESS ACTIVITIES ............................................................................................................................. 53
7.4
DETAILS OF ACTIVITIES ......................................................................................................................... 53
7.4.1
Setting up QA for the project ......................................................................................................... 53
7.4.2
Specific QA activities .................................................................................................................... 54
7.4.3
Evaluation of processes ................................................................................................................. 54
7.4.4
Evaluation of products .................................................................................................................. 55
7.4.5
QA Reporting: definition of reporting and escalation rules .......................................................... 55
7.4.6
QA report ...................................................................................................................................... 56
7.5
REPORTING ............................................................................................................................................ 56
7.6
MEASUREMENTS .................................................................................................................................... 56
7.7
DEFINITIONS OF STANDARD PROJECT MEASUREMENTS .......................................................................... 57
7.7.1
Date / Date Diagram (45 curve) .................................................................................................. 57
7.7.2
S-curve .......................................................................................................................................... 58
7.7.3
Diagram of fault management....................................................................................................... 59
7.7.4
Adherence to processes ................................................................................................................. 60
ENGINEERING AND SUPPORT PROCESSES .................................................................................... 61

8.1
REQUIREMENT MANAGEMENT PROCESS ................................................................................................ 61
8.1.1
Presentation of the process ........................................................................................................... 61
8.1.2
Roles .............................................................................................................................................. 61
8.1.3
"Initialization" phase .................................................................................................................... 62
8.1.4
"Evaluation" Phase ....................................................................................................................... 63
8.1.5
"Specification phase .................................................................................................................... 65
8.1.6
"Execution" phase ......................................................................................................................... 68
8.2
CONFIGURATION MANAGEMENT PROCESS ............................................................................................ 68
8.2.1
Description of the process ............................................................................................................. 68
8.2.2
Configuration component .............................................................................................................. 69
8.2.3
Configuration management spaces ............................................................................................... 69
8.2.4
Configuration management levels ................................................................................................. 73
8.2.5
Teamwork ...................................................................................................................................... 75
8.2.6
Software products.......................................................................................................................... 75
8.2.7
Management of compatibility between elements ........................................................................... 78
8.3
THE CHANGE MANAGEMENT PROCESS .................................................................................................. 79
8.3.1
Description of the process ............................................................................................................. 79
8.3.2
Roles .............................................................................................................................................. 79
8.3.3
Request information ...................................................................................................................... 82
8.3.4
Request statuses ............................................................................................................................ 83
8.3.5
Process step details ....................................................................................................................... 85
DELIVERABLE PROJECT DOCUMENTS ........................................................................................... 90

9.1
PROJECT SHEET...................................................................................................................................... 90
9.1.1
Document purpose ........................................................................................................................ 90
9.1.2
Document evolution....................................................................................................................... 90
9.1.3
Model ............................................................................................................................................ 91
COMPANY/DSI
9.2
PROJECT QUALITY PLAN ........................................................................................................................ 92
9.2.1
9.2.2
9.2.3
Model ............................................................................................................................................ 93
9.3
RISK MANAGEMENT SHEET .................................................................................................................... 94
9.3.1
9.3.2
9.3.3
Model ............................................................................................................................................ 94
9.4
STEERING SHEET .................................................................................................................................... 95
9.4.1
9.4.2
9.4.3
Model ............................................................................................................................................ 96
9.5
OBS (ORGANIZATIONAL BREAKDOWN STRUCTURE) ............................................................................. 97
9.5.1
9.5.2
9.5.3
Model ............................................................................................................................................ 98
9.6
PBS "PRODUCT BREAKDOWN STRUCTURE" ........................................................................................ 100
9.6.1
Subject of the document............................................................................................................... 100
9.6.2
Modification of the document ...................................................................................................... 100
9.6.3
Model .......................................................................................................................................... 100
9.7
SCHEDULING ........................................................................................................................................ 104
9.7.1
Estimate sheet.............................................................................................................................. 104
9.7.2
MS-Project Schedule ................................................................................................................... 104
9.8
CONFIGURATION MANAGEMENT PLAN ................................................................................................ 106
9.8.1
Subject of the document............................................................................................................... 106
9.8.2
Modification of the document ...................................................................................................... 106
9.8.3
Model .......................................................................................................................................... 107
10
MANAGEMENT BY PROJECT AND CMMI ...................................................................................... 108
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
THE CMMI REFERENCE FRAMEWORK .................................................................................................. 108

REQM - REQUIREMENTS MANAGEMENT ............................................................................................. 110
PP - PROJECT PLANNING ...................................................................................................................... 111
PMC - PROJECT MONITORING AND CONTROL ..................................................................................... 112
CM CONFIGURATION MANAGEMENT ................................................................................................ 113
PPQA - PROCESS/PRODUCT QUALITY ASSURANCE ............................................................................. 114
MA- MEASUREMENT AND ANALYSIS .................................................................................................. 115
SAM - SUPPLIER AGREEMENT MANAGEMENT..................................................................................... 116
GENERAL OBJECTIVE: INSTITUTIONALIZE A MANAGED PROCESS ......................................................... 116
11
REFERENCES .......................................................................................................................................... 118
12
LIFE CYCLE SYNOPSES ....................................................................................................................... 119
COMPANY/DSI
1 FIELD OF APPLICATION
1.1 Identification
Project:
Subject:
QMS
Presentation of MPP methodology
1.2 Basic points about QMS

The Information Systems Department (DSI) for the Company group has decided to implement project
management methods and tools in order to achieve the following objectives:
o
o
o
o
o
o
o
o
Improvement in the quality of developments;

Respect of commitments;
Process for releasing new projects;
Better visibility of the departments activity;
Optimization of resource allocation as a function of priorities;
Better addressing of market expectations;
Increased formalism between the teams that make up the group;
Ensured synchronization between the various stakeholders.
To do this, the DSI used the SEIs proper practice guidelines, entitled CMMI.
1.3 Basic points about the document

This document presents the processes and procedures required to constitute and follow up on a
project within the COMPANY group. This methodology was defined under the designation MPP for
Management by Project.
One chapter of this document has been devoted to the traceability between the CMMI guidelines and
MPP practices.
COMPANY/DSI
2 GENERAL PRESENTATION OF MANAGEMENT BY PROJECT

The goal of the projects for which the DSI is the general contractor is to permanently improve
COMPANYs competitiveness, either by:
o
Enhancing its commercial offer in terms of products or of new capabilities, whether for
generic or specific use, with the goal of acquiring new market shares and/or maintaining its
current positions, or by
Transforming its internal organization or giving it methodological or software tools designed to
strengthen its productivity.
As part of this goal, Management By Project is a process designed to ensure that projects are
undertaken which have the best possible fit with the companys strategic objectives, and that the risks
incurred are identified and managed.
Activities that involve insignificant expenses or present a low degree of risk can be considered to be
projects or tasks generated under the authority of a given department. Projects of a wider scope,
such as for example the development of a new release of an existing product, involve numerous
departments both within and outside the DSI, and because of this, require a different approach from
beginning to end, through various organizational components.
This approach, which consists of managing all projects in one coherent investment portfolio, is
commonly designated by the term project portfolio management, shortened to "management by
project".
Management by project is intended to identify, evaluate, prioritize and manage projects in progress
within the corporation, using a set of methods consisting of verifying that the projects that the
corporation decides to undertake are in agreement with its strategic objectives and lead progressively
to the expected results. Each project can be considered to be an isolated investment, whose return
must be very closely followed.
Breakdown into phases completed by milestones makes it possible to evaluate the potential
advantages and risk level of projects, define clear responsibilities, divide and organize the work to be
performed, appropriately involve all the participants concerned, optimize resource commitments,
validate work completed, resolve any conflicts, and decide whether to pursue, terminate, defer or trim
down certain projects.
Reaching the milestone that marks the end of each phase is conditional upon approval by
management, or by authorities acting by delegation, of a certain number of documents (management
and deliverable documents) which show or state that the agreed work was completed in compliance
with the objectives set, with good standards of practice, and within the agreed time and budget (or
cost) limits.
The management by project process is supported by other processes, such as quality assurance
processes or engineering or support processes, but is not replaced by them. It constitutes a
new methodological instrument that provides legitimacy, credibility and authority for project managers
whose task is to coordinate the progress of projects through the various departments or subsidiaries
of the COMPANY group.
COMPANY/DSI
3 TERMINOLOGY
3.1 Product/Program
"Product" shall be taken to mean:
o
o
o
All parts of COMPANYs market offerings, as well as those of its subsidiaries, that have or will
have a permanent presence over time, and whose development is governed by an outline
document or a multi-year roadmap.
Any service provided.
Any internal application having to do with DSI management in the COMPANY group or with
finances.
Software products originating from the development process often have the objective of being generic
and being used by the majority of our clients.
This product may be used as-is, after configuration for the end customer, or may be modified in
response to a customers specific needs.
The "roadmap" shall include all improvements expected for the product, in successive releases. These
are major developments that involve the companys strategy as well as Companys position as a
solution provider in the pharmaceutical and medical fields.
Sometimes a group of projects that combine to bring about a given strategic objective, in the same
location or in geographically distinct locations, and/or which do not necessarily lead to the emergence
of a new product offering, can be designated by the term program (of investments).
A product is distinguished from a release in the sense that:
o
o
A product is regarded as a permanent, generic offering that meets the requirements of a

market segment.
A release represents the product as it is presented on the market for a given period of time.
3.2 Project Ownership

This concerns the sponsoring entity of the project, namely:
o
o
A subsidiary of the Group responsible for marketing a product, its configuration and all other
aspects of the contractual relationship between COMPANY and its clients.
A subsidiary of the Group responsible for marketing and customizing a product, or for carrying
out specific developments for a given client, in response to a call for bids or according to any
other formalism.
An internal department.
3.3 Category
The category defines the scope of the project and, indirectly, the level of risk and the steering
authorities associated with it. The following categories are used:
o
Creation: This category includes any development of a new market offering within the scope
of the Company strategy. This category shall include, for example, any project that exhibits an
innovative functional nature, makes use of an emerging technology, or is intended to
penetrate a given market, and which consequently is the subject of particular attention.
Development: This category includes any development of a new release of an existing

product, or any extension of an existing product made to a clients specific requirements.
COMPANY/DSI
Companys clients and prospects can request that additional work be done beyond the
standard context of a software product. This may involve improvements or adding new
features. This may also involve the DSIs participation in the startup of the application
software for a particular company, for example during a configuration phase. A "major"
development may be categorized as a creation upon the decision of the Project Manager, the
Steering Committee or management, depending on perceived risk.
o
Maintenance: This category includes all corrective maintenance work for products in use.
Minor improvements may also prove to be necessary as time goes by. They involve short
developments with an impact on resource scheduling. These minor corrections and
improvements are deliverable in the form of patches, service packs or complete applications.
Since these activities concern impromptu developments in response to operating
requirements; they cannot be planned or managed according to the same formalism as
developments or creations, and shall be subject to specific procedures that are less stringent
as related to size and associated risk level. Certain regular or basic tasks fall into the scope of
an annual budgeting process and monthly follow-up by product or family of products,
according to a framework that will be determined at a later date.
R&D: This category includes all activities of research, technological experimentation or tool
testing, including all initiatives for documentation, awareness or internal training. These
activities are associated with a design or development project, are of a prospective nature
that is independent of a given project, or are executed to produce a result applicable to
multiple projects.
3.4 Concept of criticity

Beyond the "product," "project ownership" and "category criteria is the concept of project criticity.
Many factors are used to evaluate the level of criticity, both qualitative and quantitative and involving
both the technical and marketing domains. They express the risks perceived at the start of the
project, in terms of strategic, financial, marketing, operational or technical impacts.
Some examples of factors that tend to increase the level of criticity are:
Budgetary factors
o Cost much higher than the average for current projects
o Sales generated are greater than the usual contract average
Commercial factors
o Product visibility on the market
o Delivery date resulting from a commitment to a key client
o Delivery date imposed by a Call for Bids
o Requirements regarding certification, regulation, or confidentiality imposed by a client
or a call for bids
Project organization
o Multiple components, division into a large number of modules, increasing the need for
coordination among several teams
o Recourse to innovative methods
Technical factors
o Use of emerging technologies
o Use of technologies that have not been fully integrated into the company
o Level of performance or service expected is greater than average
o Required security levels
Firstly, the projects shall be identified as having "normal" or "increased" criticity, as evaluated
jointly by the Project Manager, Steering Committee or Management Committee.
COMPANY/DSI
The level of criticity will affect the projects steering parameters.

The level of criticity is subject to modification depending on the projects progress or modifications
occurring in its exterior environment, and this decision shall be by the authority of the Project
Manager, the Steering Committee or the Management Committee when a milestone has been reached
or whenever any other event affects the course of the project.
3.5 Project organization

3.5.1 Project referencing
The term "project" shall be used to designate any development in the products/services offered by
COMPANY or any regrouping of activities that fall into one of the categories defined above.
This concept encompasses the creation of new products/services, market launch of new releases of
existing products, development of service packs, performance of external or internal studies,
experimentation on new tools or technologies, or execution of a specific development for a given
client, whether or not this development is intended to become generic through later development.
A project is distinguished by a limited existence in time, a beginning, an end and a technical objective
that are clearly identified. A Project Manager is assigned to it, who is responsible for production
coordination for all deliverables and for the organization and proper execution of all tasks and
participants involved in the execution of the project, from inception to completion. Implicitly, this
means that a project includes not only tasks related to software development, but also all
communication, documentation and industrialization activities upstream or downstream from the
production of the software.
Note: The role of the Project Manager is distinct from that (those) of expert(s) or technical leader(s)
who usually participate in the course of developments.
A typical COMPANY project consists of developing a release of an existing product.
A project defined in this way must first of all have four key points of reference:
o
o
o
o
A
A
A
A
Product (in the broad product/program sense)

Project Owner
Category
level of criticity
3.5.2 PBS (Product Breakdown Structure)

The PBS lists all deliverables produced by the project in a hierarchical representation.
The first breakdown levels include the following elements:
COMPANY/DSI
10
PBS type
Level 1
Description
1
Project file
"Product" deliverables
Level 3
Description
1.1
Economic documentation
1.2
Project Documentation
1.3
Development Cycle
1.4
Launch
2.1
2.2
Software
Packaging (PC/PDA/HOST)
2.3
Packaging Documentation
2.4
Documentation
2.5
Internal and external training support materials
"Marketing/commercial" deliverables 3.1

3.2
Pamphlets
Demonstration and evaluation kits
3.3
Sales assistance
3.4
Pricing
3.5
Contractual documents
3.6
Launch kit
Third and fourth levels detail the generic elements of a project. This "PBS type" lists all deliverables
that a project is likely to produce. The Project Manager is responsible for identifying, at the start of
the project, the PBS type elements that he will select for his project.
3.5.3 WBS (Work Breakdown Structure)

A project is broken down into a primary level of Work Packages.
A work package consists of the production of one or more of the projects deliverables, by a single
team placed under the authority of a single operating manager. These deliverables may be software
or any collection of accompanying documents, for example:
o
o
o
A software application module produced by developing one or more components: "Preliminary

activity, Weekly Agenda, Cost Configuration, etc.
Creation of support materials: "marketing documents," "training support materials," etc.
Performance of specific operations: "acceptance," "transfer to operations, etc.
A typical project may consist of about ten work packages, with each of these packages itself
representing a workload of several man-weeks.
Each package will represent its interdependence points between packages in the same project or two
different projects in the form of planning milestones.
The WBS Work Breakdown Structure (Technical Flowchart) of a project consists of breaking it down
into activities, all of which contribute to producing one or more elements of the PBS. The first
breakdown level divides the work to be performed between the various COMPANY operating entities
contributing to the project.
The example below is that of a project where BU Pharma CRM represents the project owner.
COMPANY/DSI
11
WP
WP00
WP01
WP02
WP03
WP04
WP05
WP06
WP07
WP08
WP09
WP10
WP11
WP12
WP13
Title
Project management
"Upstream" Marketing
Engineering studies
Developments
Developments
Developments
Developments
Developments
Developments
Validation
Industrialization
Support materials
Documentation
Managing entity
PRO
MOA/PSP
DSI/BET
DSI/DEV/DATA
DSI/DEV/TM
DSI/DEV/PDA
DSI/DEV/OTC
DSI/DEV/ATL
DSI/DEV/ONE
DSI/DDO/REC
DSI/DDO/IND
MOA/PRD
MOA/STC-ITS
MOA/MKT
Project OBS
"Project" cell
Product Specification
DSI Engineering Design Department
DSI - Data Development
DSI - TM Development Teams
DSI - PDA Development Teams
DSI - OTC Development
DSI ATLAS Development
DSI - ONE UP
DSI Acceptance
DSI - Industrialization
Product Release Department
STC/ITS
Marketing
3.5.4 OBS (Organizational Breakdown Structure)

The purpose of the OBS is to present all the roles and players in the project. The Project Manager will
customize his OBS by indicating:
o
o
The choice of players for the project starting with a generic proposal
The addition of roles specific to the project, or elimination of certain generic roles that are too
general
This document is initiated during the evaluation phase and updated if necessary as the project
progresses. It constitutes an appendix to the Project Quality Plan (in particular, the Project Manager
creates a hypertext link from the PQP to the OBS).
COMPANY/DSI
12
3.6 Glossary
Abbreviation
AQ
BU
CdCF
Check-list
CML
CMPL
CODIR
COPIL
COTS
CP
CRML
DDO
DRH
DSI
EBF
MOA
MOE
MPP
MTF
NC
OBS
PBS
PQP
PV
RQO
PQM
WBS
WPM
COMPANY/DSI
Definition
Quality Assurance
Business Unit
Functional Specifications
Verification tool for a process or product, used by QA
Configuration management leader
Configuration management plan
Management Committee
Steering Committee
Commercial Off-The-Shelf or product from the catalog
Project Manager
Change request management leader
Operations Department
Human Resources Department
Information Systems Department
Emergency Bug Fix
Project ownership
Project management
Management By Project
Functional tracking matrix
Non-compliance
Organizational Breakdown Structure
"Product Breakdown Structure"
Project Quality Plan
Minutes
Organization Quality Manager
Project Quality Manager
Work Breakdown Structure
Work Package Manager
13
4 DEFINITIONS OF FUNCTIONS AND ROLES

4.1 Project Manager
4.1.1 Job description
The goal of the Project Managers position is leadership of the project in its entirety (from definition of
its objectives to release of the solution and closure), according to the process and tools defined for
this purpose. His function is pivotal to this process, and he is responsible for the organization, tracking
and confirmation of the proper execution of all tasks necessary for the completion of the project, and
in particular the production of deliverables.
4.1.2 Positioning and relational modes

The function of the Project Manager is defined in relation to a specific overall project, as described in
the Terminology. It appears at the start of the project after the designation of the Project Manager
and disappears at the end of the project.
4.1.2.1 Hierarchical authority

Depending on the case, the Project Managers function is entrusted to either:
o A DSI employee, assigned by the corresponding division manager and at the request of the
project owner; or
o an employee of the project owner, assigned by the projects initiator in accordance with his
hierarchy and with the DSI development manager.
o
In all cases, the Project Coordinator must be informed of this assignment.
Throughout the duration of the project, the employee retains his permanent hierarchical position.
Nevertheless, the authority of the Project Managers hierarchical supervisor co-exists, for tasks that
are part of the Project Managers function, with the operating authority exercised collectively by the
Steering Committee and by the Product Management Committee.
Likewise, and barring a decision to the contrary by his "permanent" hierarchical supervisor, the
employee who is Project Manager shall retain his "permanent hierarchical authority and his other
functions throughout the duration of the project. On the other hand, he shall not, as Project Manager,
have any hierarchical authority over the various employees involved in the project, and in particular
over the Work Package Managers or the Project Quality Manager.
4.1.2.2 Operating authority

The Project Manager shall be subject to the collective operating authority of the project decisionmaking authorities, i.e., depending on the case, the Steering Committee and the Product Management
Committee (see Authority Chart).
The Project Manager shall, within the scope of the project, have operating authority over the various
Work Package Managers and the Project Quality Manager:
o in association with the hierarchical supervisors as part of the selection of Work Package
Managers and resource allocation;
o directly, within the scope of progress tracking and validation of the projects deliverable
elements;
o collectively as a member of the Steering Committee on the decisions that are part of his
responsibilities.
He can act alone as needed on behalf of collective management by delegation from the project
authorities (Steering Committee, Management Committee, MOA). For example, he may authorize that
COMPANY/DSI
14
an end-phase milestone has been reached, and have this decision confirmed a priori or a posteriori by
the authority involved.
4.1.3 Tasks and responsibilities

4.1.3.1 Definition of project target
o
o
o
o
o
Define the projects scope in compliance with project ownership and the hierarchical
supervisors of the mobilized participants.
Identify the deliverable elements of the project (PBS) in association with project ownership
and the Work Package Managers.
Coordinate and check the definition, planning (without constraint on resources for the first
pass) and budgeting (man-days and other expenses) of the projects tasks by phase:
work packages, tasks and activities;
expenses, capabilities required by activity;
planning milestones (critical milestones, interdependencies).
Consolidate these elements over the entire project to the end (milestones) after confirming
their validation in compliance with the defined cycles.
Validate and integrate the elements of the quality plan after confirming their validation in
compliance with the defined cycles, and ensure that the various participants are aware of all
procedures in force.
Obtain the cooperation of the project owner, project authorities and various hierarchical
supervisors regarding the elements listed above, in compliance with the defined validation
cycles.
4.1.3.2 Establishing a reference

o
o
o
o
Ensure that the various work packages are correctly supplied with resources (human and
material resources, capabilities):
coordinate the allocation of resources available for activities in association with
the Work Package Managers and the hierarchical supervisors of the employees
assigned to the project;
define the resource acquisition policy in association with the Work Package
Managers, the DSI hierarchy and the Human Resources Department;
select sub-contractors in association with the Work Package Managers and the
Project Coordinator.
Perform the risk analysis and define solutions in association with the Work Package Managers
and Project Quality Manager
Consolidate project management elements (WBS, PBS, OBS, planning, budget) after allocation
of resources and incorporation of tasks associated with risk management.
Obtain the cooperation of the project owner, project authorities and various hierarchical
supervisors regarding the elements listed above, in compliance with the defined validation
cycles.
Communicate with the various stakeholders and communities (internal or external) interested
in the results of the project.
4.1.3.3 Progress tracking

o
o
o
o
COMPANY/DSI
Confirm the progress of the work in the various work packages compared to planning
(progress, time elapsed) in association with the Work Package Managers.
Coordinate and confirm the re-estimation carried out by the Work Package Managers:
Evaluation of work remaining to be supplied by task;
Updating of planning and budgets by phase;
Adjustment of the PBS.
Consolidate updates of project management elements.
Produce and distribute tracking charts (specifically to his hierarchical supervisor and to the
Project Coordinator) and maintain the project file.
15
o
o
o
Process exception reports (major alteration or crisis) submitted by the Work Package
Managers, working with the projects authorities, Project Coordinator and hierarchical
supervisors, depending on the case.
Validate the results produced by the work packages and monitor their validation in compliance
with the defined cycles.
Ensure that the procedures in force are respected by the various players, in compliance with
the quality plan.
Identify and qualify the sources of submitted or potential modifications and ensure that they
are monitored.
4.1.3.4 Reviews and Reports

o
o
o
o
o
o
o
o
o
o
o
o
o
Organize and conduct phase-end reviews (reaching a milestone) as part of a meeting (regular
or special) of the authority indicated by the authority chart:
o Collection and monitoring, in cooperation with the Project Quality Manager, of the
completion and full validation of the documents required for reaching the
milestone (deliverables for the phase being completed and project management
elements for the following phase);
o Report on the reservations and actions to be taken that were decided at the time
the previous milestone was reached;
o Transmission of decision-making elements to the members of the authority
involved;
o Leading the review.
Upon request from Work Package Managers, participate in progress reviews conducted per
work package.
Organize and lead Steering Committee reviews (project progress tracking, deliverables to be
validated, difficulties encountered and conflicts to be resolved).
Formalize, record and announce to the project team, to his hierarchical supervisor and to the
Project Coordinator, the plans of action formulated and decisions made by the Steering
Committee and ensure that they are actually carried out.
Inform the Project Coordinator about the requirements of inter-project conflicts to be
resolved, identified specifically during Steering Committee reviews.
Insofar as is possible, address these requirements with the Project Coordinator and in
association with the various DSI division managers, upstream of the Product Management
Committees.
Report to the Product Management Committee (project progress tracking, difficulties
encountered) and have it make the necessary decisions (conflict resolutions, plans of action).
Notify all project participants about the decisions made and plans of action set up by the
Product Management Committee and ensure that they are carried out.
Maintain the Project file.
Organize and coordinate phase-end and project-end reports with all members of the Steering
Committee.
Formalize the actions decided upon in the phase-end reports and ensure that they are actually
carried out.
Take initiatives for actions that are not under the sole jurisdiction of the Steering Committee,
specifically through the Project Coordinator.
Communicate with the Product Management Committee regarding the phase-end and projectend reports: diagnostics, decisions made and actions taken.
Note: as a member of the Steering Committee and the Product Management Committee, the
Project Manager contributes with full validity to the decisions they make.
COMPANY/DSI
16
4.1.4 Capabilities
4.1.4.1 Methodology capabilities
o
o
o
In-depth management of the overall project-management process, roles, procedures and

tools.
Superficial knowledge (on an overview level) of the procedures and conditions for
accomplishing all the tasks included in the project.
Overall vision of the organization, potential resources and their technical capabilities.
4.1.4.2 Managerial and performance-related capabilities

o
o
o
o
o
o
o
o
Exert non-hierarchical authority.

Mobilize resources and launch a project or tasks.
Provide training as needed in methods, procedures and tools.
Perform intermediate tracking.
Prepare reports (diagnostic and plans of action).
Chair meetings in different positions (subordinate, equal-to-equal, authority)
Manage conflicts and negotiate in these same positions.
Written and oral communication: redraft and record progress, difficulties and decisions,
including those with regard to subjects that are not fully technically mastered.
4.2 Work Package Manager

The purpose of the Work Package Manager function (WPM) is the management of a work package
(work package comprising one or more project deliverables) within the scope of an overall project.
He shall be responsible for the organization, tracking and confirmation of the proper execution of all
tasks required for the completion of the work package by a team (MOA or DSI) placed under his
responsibility.

The function of the Work Package Manager is defined relative to a particular overall project and work
package, as described in the Terminology. It appears at the start of the project, after the project has
been divided into work packages and Work Package Managers have been designated, and it
disappears upon completion of the project.

According to the work packages, the Work Package Manager function is entrusted either to an
employee of the project owner or to a DSI employee assigned by his hierarchical supervisor, upon the
request of the Project Manager and with the employees acceptance.
Throughout the duration of the project, the employee retains his permanent hierarchical position.
Nevertheless, the authority of the hierarchical supervisor of the Work Package Manager co-exists, for
tasks that are part of the WPMs function, with the operating authority of the Project Manager and the
operating authority exercised collectively by the Steering Committee and by the Product Management
Committee.
Likewise, barring a decision to the contrary from his "permanent" hierarchical supervisor, the
employee acting as Work Package Manager shall retain his "permanent" hierarchical authority in its
entirety, as well as his other functions throughout the duration of the project.
In particular, he shall have authority over all employees contributing to the work package tasks,
hierarchical over most of them and operational over the rest (resources from other teams called upon
as reinforcements for the work package).
COMPANY/DSI
17

The Work Package Manager shall be subject to the collective operating authority of the projects
decision-making authorities, i.e., depending on the case, the Steering Committee and the Product
Management Committee (see Authority Chart explained in document CEG_PROJ_Terminologie.doc).
He is also subject to the operating authority of the Project Manager:
o in association with the hierarchical supervisors as regards resource allocation;
o directly as part of progress tracking and validation of the projects deliverables;
o collectively, as a member of the Steering Committee on decisions that are part of his
responsibilities.
The Work Package Manager contributes with full validity to the collective operating authority exercised
by the Steering Committee, of which he is a member.

4.2.3.1 Definition of the target
o
o
o
o
o
Assimilate the scope and content of the project, its objectives and its organization.
Identify the deliverable elements in his work package, working with the Project Manager and
project owner.
Provide the definition, planning (without constraint on resources for the first pass) and
budgeting (man-days and other expenses) of his work packages tasks by phase, in
coordination with the Project Manager:
Tasks and activities, associations between activities and deliverables;
Responsibilities, capabilities required by activity;
Planning milestones (critical milestones, interdependencies with the other work
packages).
Submit these elements to the Project Manager for validation and consolidation.
Participate in the validation activities for the various constituent elements of the project,
either directly or as a member of the Steering Committee, in compliance with the defined
validation cycles.
4.2.3.2 Reference establishment

o
o
o
o
o
Ensure that the various tasks to be performed as part of his work package are correctly
supplied with resources (human and material resources, capabilities):
allocation of resources available for activities, working with the assigned
employees, the hierarchical supervisors and the Project Manager;
participation in defining the resource acquisition policy, working with the Project
Manager, the DSI hierarchy and the human resources department;
participation in selecting sub-contractors, working with the Project Manager and
the Project Coordinator.
Contribute to risk analysis and to preparing the corresponding risk management plans.
Update the management elements of the work package (WBS, PBS, OBS, planning, budget)
after resource allocation and incorporation of the tasks associated with risk management.
Submit these elements to the Project Manager for validation and consolidation.
Participate in validation activities for the various constituent elements of the project, either
directly or as a member of the Steering Committee, in compliance with the defined validation
cycles.
4.2.3.3 Progress execution and tracking

o
o
COMPANY/DSI
Initiate, attend and track the progression of the various tasks in the work package as they
relate to the plan (progress, time elapsed, explanation of discrepancies).
Ensure a primary level of coordination with the tasks in the other work packages, working
with the corresponding Work Package Managers, especially around the identified
interdependent milestones.
18
Produce tracking elements (management chart, steering sheet) and submit them to the
Project Manager for analysis and consolidation.
o Prepare the re-estimate, working with the Project Manager:
Evaluation of the work remaining to be provided by work package task;
update of the plans and budgets of the work package by phase;
adjustment of the PBS.
o Issue exception reports intended for the Project Manager in case of a major problem or crisis.
o Verify the results produced by the tasks in the work package and confirm their prior validation
if applicable (for example by technical experts) in compliance with defined cycles.
o Distribute the results produced by the work package for validation in compliance with defined
cycles (Project Manager, authorities, etc.).
o Identify and qualify the sources of potential or completed modifications and ensure that they
are inspected.
Note: depending on the case, the Work Package Manager can also take responsibility for or
participate directly in the performance of certain tasks/deliverables and/or provide regular
technical expertise.
o
4.2.3.4 Reviews and Reports

o
o
o
o
o
o
o
o
o
Organize and conduct progress reviews (weekly or bimonthly) for his work package. As part of
this, he may request the participation of the Project Manager.
Submit to the Project Manager all information that may be useful to the preparation and
performance of Phase-end reviews (reaching a milestone).
Formalize and present an update on progress, difficulties encountered and requests for
conflict resolution during Steering Committee reviews.
Participate, during these Steering Committee reviews, in decision-making and in defining any
future plans of action.
Inform his team of all decisions made during Phase-end, Steering Committee and Product
Management Committee reviews, and ensure that they are carried out.
Prepare phase-end reports, working with the Project Manager, and present them during
Steering Committee reviews conducted for this purpose.
Participate in formulating plans of action resulting from difficulties identified during the phaseend reports.
Inform his team of these plans of action and implement them.
After any relevant amendments are made, validate the project completion report and the
closure report prepared by the Project Manager.
4.2.4 Capabilities
o
o
o
o
o
In-depth understanding of the overall project management process and of roles, procedures
and tools.
Detailed knowledge of the procedures and conditions required for accomplishing all the tasks
in the work package.
In-depth technical mastery of subjects to be handled in his work package.
Detailed knowledge of the resources and capabilities available for performing the tasks in his
work package.
Overall vision of the entire organization (and the project organization).

o
o
o
o
o
COMPANY/DSI
Mobilize resources and initiate tasks.

Perform intermediate tracking.
Chair meetings (in a position of authority).
19
o
o
Manage conflicts and negotiate (in a position of authority or between equals).

Communicate in writing and orally: redraft and record progress, difficulties and decisions,
including those regarding subjects that have not been entirely mastered technically.
4.2.5 Examples of work package scopes

As an example, the following paragraphs indicate the primary tasks to be completed in the various
types of work packages (besides project management tasks indicated in the first part of the
chapter).
4.2.5.1 "Upstream Marketing" work package

o
o
o
o
o
Definition of the projects scope and objectives, from an "economic" point of view (market
study, opportunity study, request for intervention) as they relate to a generic or customerspecific need.
Preparation of the launch strategy and project constraints associated with it (for example
deployment plans, translation needs).
Definition and formalization of functional specifications (improvements/corrections to be
made, configuration requirements, operating environments required, etc.).
Definition of any possible modeling/prototyping needs.
Validation of models/prototypes presented.
4.2.5.2 "Development" work package

o
o
o
o
o
o
o
o
Preparation and formalization of operating specifications based on the specifications validated

by the MOA.
Design of the solution to be implemented, working with the various technical experts required
(architecture, tools, languages, components, data modules, etc.).
Completion and review, with the MOA, of any models/prototypes executed.
Development and availability of the solution (overall or by module) in the various successive
architectures (for example: development, acceptance/pre-production, pilot, deployment).
Internal acceptance of the solution (unit and integration testing).
Validation of operating acceptance plans.
Handling of defects/discrepancies detected by the various acceptance teams (operating,
user/client, maintenance).
Technical documentation of the completed solution (DVL).
4.2.5.3 "Validation" work package

o
o
Preparation of operating acceptance plans (scenarios and test batteries) based on the
operating specifications validated as part of the Development work package.
Iterative execution of operating acceptance scenarios and return of detected operating
defects/discrepancies to the Development team for correction.
4.3 Project Quality Manager

The goal of the position of Project Quality Manager (PQM) is the definition, maintenance and
inspection of the application of the quality assurance policy to the projects in which he is participating.

The function of Project Quality Manager is defined relative to a specific overall project. It appears at
the start of the project and disappears when the projects closure phase has been completed. Just one
COMPANY/DSI
20
Project Quality Manager is designated per project, although the same employee can assume this
function for several projects simulatenously.

The function of Project Quality Manager is entrusted to either;
o A Quality-Safety division employee upon proposal by the Project Manager and after validation
by the Quality-Safety division manager; or
o An employee in another DSI division upon proposal by the Project Manager and after
validation by his hierarchical supervisor and the Quality-Safety division manager.
The employee acting as Project Quality Manager shall, throughout the duration of the project in which
he is participating, retain his permanent hierarchical position.
Nevertheless, the authority of the hierarchical supervisor of the Project Quality Manager co-exists, for
tasks that are part of the PQMs function, with the operating authority of the Project Manager and the
operating authority exercised collectively by the projects decision-making authorities.
Likewise, barring a decision to the contrary from his hierarchical supervisor, the employee acting as
Project Quality Manager retains his hierarchical authority and his other functions in full throughout the
duration of the project.

As indicated earlier, the Project Quality Manager is subject to the collective operating authority of the
projects decision-making authorities, i.e., the Steering Committee and the Product Management
Committee.
He is likewise subject to the operating authority of the Project Manager with regard to tracking the
progress of quality tasks and to validating the corresponding deliverable elements.
If the Project Quality Manager is not an employee of the Quality-Safety division, he is still subject to
the operating authority of the Quality-Safety division, from which he receives directives on the quality
assurance policy and to whom he reports any difficulties encountered and improvements to be
implemented.
The Project Quality Manager has no direct operating authority over the various participants in the
project beyond his tasks related to validating the deliverable elements provided by the various work
packages.
He is also a member of the Steering Committee and as such participates with full validity in the
decisions made by it.

o
o
o
o
o
o
COMPANY/DSI
Prepare the project quality plan (covering compliance with requirements, specification
compliance, acceptance plan compliance, configuration management and traceability matrix),
have it validated according to the defined cycles, and then distribute/submit it, working with
the Project Manager.
Working with the Project Manager, ensure that the procedures to be applied are known to
and mastered by the various players.
Contribute to the analysis of project risks and to the development of corresponding risk
management plans.
Monitor/evaluate the compliance of deliverable elements (documents and tools) produced by
the various work packages relative to the rules defined in the projects quality plan (contents
and prior validation according to predetermined cycles), throughout the project and more
specifically before the milestone (phase-end) reviews.
After this evaluation, detail and record any non-compliances detected and ensure that actions
are implemented until compliance is achieved.
Contribute to the preparation of phase-end and project-end reports and to defining the plans
of action for improvements that follow them.
21
Periodically formalize and submit to the Quality-Safety division manager, reports regarding
difficulties encountered during the project and non-compliances that cannot be resolved
within the scope of the project.
4.3.4 Capabilities
o
o
o
o
o
In-depth understanding of the overall project management process and its related roles,
procedures and tools.
Superficial knowledge of the procedures for all tasks included in the project.
In-depth knowledge of the pre-requisites and conditions for completing these same tasks.
Mastery of quality assurance principles to be implemented during software development
projects for internal and external use.
Overall vision of the organization, resources and capabilities available within the various
entities that can be mobilized for projects.

o
o
o
Communicate, in writing and orally, including to people with limited capabilities in his own
areas of expertise (ability to communicate in laymans terms).
Prepare and file reports (diagnostic and plans of action) in various positions (equal-to-equal,
operating authority relationship).
4.4 Project Coordinator

The goal of the primary Project Coordinator function is to coordinate the Management By Project
process and to contribute to inter-project coordination.

Unlike the Project Manager and Work Package Manager functions, the Project Coordinator function is
not defined relative to a specific overall project, but covers all projects.

The Project Coordinator function shall be entrusted to a DSI employee by the Information Systems
Director.
The Project Coordinator does not, as such, have any hierarchical authority over the various project
participants. He may, if applicable, have hierarchical authority within the scope of other functions
entrusted to him.

Since his role is essentially a supporting one, the operating authority of the Project Coordinator over
the various project players and authorities shall be limited to:
o Distribution and monitoring of the application of modifications to the project management
process;
o His tracking of the progress of the various projects, based on the elements that the various
Project Managers must submit to him
o His participation in the decisions of the various Product Management committees, of which he
is a full-fledged member, and of the various Steering Committees to which he is invited by the
corresponding Project Managers.
COMPANY/DSI
22
The Project Coordinator may act alone, as needed, on behalf of a group by delegation of the Product
Management Committee.

o
o
o
o
o
o
Maintain the Management By Project process and the reference materials associated with it
(documentation, available tools, communication and training support materials involved in the
process), specifically based on phase-end and project-end reports.
Train the various participants in the Management By Project process and associated tools,
then assist them with implementation, upon their request or by his own initiative.
Participate in selecting sub-contractors, providing an overall vision of their quality of service
and their capabilities.
Contribute to decisions and conflict resolution during Product Management Committee
meetings.
Collect the various project tracking elements (steering committee presentations and meeting
minutes) and prepare overall multi-project tracking (shown with charts).
Facilitate project management and contribute to project coordination, at his own initiative or
upon request from any Project Manager or even a Work Package Manager or Project Quality
Manager. As part of this, the Project Coordinator must, insofar as is possible, work with the
Project Leaders and the various DSI division managers to handle requests for inter-project
conflict resolution upstream of the Product Management Committee. On the other hand,
depending on urgency, he may ask for the organization of a special Product Management
Committee or initiate an escalation procedure for conflict resolution by the directing
authorities.
Inform and communicate regarding the Management By Project process in general as well as
the projects themselves.
4.4.4 Capabilities
o
o
o
o
o
Mastery of project management fundamentals, general principles and good practices and
ability to apply them within the scope of the reevaluation of existing processes.
In-depth understanding of the overall Management By Project process and the roles,
procedures and tools related to it.
Superficial knowledge (on an overview level) of the procedures and conditions for performing
all tasks included in the project.
Detailed overview of the entire organization of the corporation, various authorities, relational
modes and decision-making mechanisms.
Overall view of potential project resources and their technical capabilities.

o
o
o
o
o
o
COMPANY/DSI
Communicate in writing and orally, including:

o To people with limited capability in his own areas of expertise (ability to
communicate in laymans terms);
o Conversely, regarding subjects that have not been fully technically mastered.
Regularly train and provide assistance regarding methods, procedures and tools.
Conduct intermediate tracking, summarize and record progress and decisions regarding any
difficulties/problems encountered.
Chair meetings in various positions (subordinate, between equals, authority).
Manage conflicts and negotiate in these same positions.
23
4.5 Configuration Management Leader

4.5.1 Description of the role
The Configuration Management Leader (CML) is the administrator in charge of project configuration
management.
As such, he is in charge of:
the projects configuration management system
the creation of "baselines" and related inspections
the generation of all configuration records
ensuring that all product elements are in place for its creation and delivery
4.5.2 Primary tasks and responsibilities

4.5.2.1 Configuration management planning
The CML plans the configuration management requirements for the life cycle phases of the project.
This plan is prepared either in writing and/or by updating an existing configuration management plan
(CMPL)
In response to the requirements defined by the Project Manager, the CML:
Indicates in the CMPL the list of indicators to be set up.
Ensures that these measures are executed and monitored.
Once the CMPL has been completed, the CML has it validated by the Project Manager. Then he
organizes the implementation of the CMS (Configuration Management System) by performing the
following actions:
Creation of various CMS spaces.
Installation and configuration of CMS tools for the various spaces (work, construction,
reference, etc.)
Implementation of access policies. If the creation and/or use of these spaces has an impact on
other projects, the CML must ensure that the people working on the other projects are informed
about it.
The CML organizes the implementation of data backup policies as defined in the CMPL. Once the CMS
has been validated, he distributes the CMPL to the projects participants.
4.5.2.2 Act according to planned tasks

The CML creates "baselines" within the CMS; this step includes the creation of the "baseline" in the
configuration management tools, and also triggers the construction of the various products. The CML
initiates construction of the product and generation of construction reports; this construction must be
in compliance with the product matrix. If there are any construction errors, the problems must be
analyzed, and corrective actions taken.
The CML creates the configuration management reports listed in the CMPL. Once the baseline" is
complete, the CML locks it. He can then make it accessible and distribute the information to the
projects stakeholders.
4.5.2.3 Conduct configuration audits

To guarantee proper configuration management, and depending on the requirements defined by the
Project Manager, the CML implements configuration audits in the following forms:
Systematic inspections (when a milestone has been reached, when a baseline is set up, etc.)
Regular inspections performed after problems are encountered or when external visibility
requests are made regarding the project.
COMPANY/DSI
24
The CML analyzes the content of the CMS to check the correlation between what is actually in it and
what is authorized by:
Change request management
Requirement management
MPP process tasks
He records all inconsistencies encountered and reports them to the Project Manager.
4.5.2.4 Maintain information system integrity

The CML organize updates for tools from other systems:
The change request management system must make reference to the new "baselines" so that
requests may be entered.
The list of requirements associated with a "baseline" must be locked.
The planned task for creation of a "baseline" must be concluded.
4.5.2.5 Participate in project meetings

Whenever necessary, configuration management is addressed during meetings of the Project Steering
Committee (COPIL), in which case the CML is invited to the COPIL meeting by the Project Manager.
4.5.3 Who may occupy the position of CML

The role of CML shall be entrusted to a DSI employee by his hierarchical supervisor, upon the request
of the Project Manager and with the employees acceptance.
4.6 Change Request Management Leader

4.6.1 Description of the role
The Change Request Management Leader (CRML) is the change request management administrator
for the projects.
The role of the CRML is associated more with the organization than with any project in particular;
change request management shall apply to all projects handled by the various project teams that use
change request management in their organization.
4.6.2 Primary tasks and responsibilities

4.6.2.1 Ensure that a Change Request Management System (CRMS) is set up to
track all change requests
Ensure that a CRMS is set up for each new project.

Guarantee that the system is properly utilized, maintained and dynamic.
Ensure that each role is properly defined.
4.6.2.2 Manage users
Manage CRMS users (login) and the creation of releases.
4.6.2.3 Participate in project meetings
COMPANY/DSI
Participate in Steering Committee meetings when it is necessary for change request

management to be addressed, in which case the CRML is invited to the COPIL meeting by the
Project Manager.
Provide change elements to the COPIL and update the CRMS accordingly.
25
4.6.2.4 Perform change request management audits
Implement change request management audits to guarantee proper process management

and address the requirements defined by the Project Manager through the use of:
o Systematic inspections (when a milestone is reached, when a baseline is set up,
etc.),
o Regular inspections performed after problems are encountered or when external
visibility requests are made regarding the project.
Analyze the contents of the CRMS to ensure the correlation between what is actually in it and
what is authorized by:
o Configuration management,
o Requirements management,
o MPP process tasks.
Record all inconsistencies encountered and report them to the Project Manager.
4.6.2.5 Act according to planned tasks
Announce releases and distribute requests among the various processing managers (RESPTRT).
Centralize requests regarding upgrades and defects.
Provide the list of requests for upgrades.
Manage changes.
Ensure traceability:
o Record the request,
o Track the changes affected (test batteries, documentation, etc.).
Apply good practices through the use of an appropriate tool.
4.6.3 Hierarchical and operating positions

Throughout the duration of the projects, the CRML shall retain his permanent hierarchical position;
however, the authority of his hierarchical supervisor shall co-exist with the operating authority of the
Project Manager.
Likewise, barring a decision to the contrary by his "permanent" hierarchical supervisor, the CRML shall
retain all of his usual hierarchical authority and other functions throughout the duration of the
projects.
4.6.4 Who may hold the position of CRML?

The role of CRML shall be entrusted to a DSI employee by his hierarchical supervisor, upon the
request of the Project Manager and with the employees agreement.
COMPANY/DSI
26
5 PROJECT AUTHORITIES
5.1 The Steering Committee (COPIL)
A Steering Committee is put together for each project at the end of the initialization phase. It consists
of the following:
o Project Manager;
o All Work Package Managers (including the project owners WPMs);
o Project Quality Manager;
o Project Coordinator, upon the request of the Project Manager;
o Other representatives of Clients, the project owner or the DSI depending on the subjects
addressed and upon invitation from one of the permanent members of the Committee.
The Steering Committee has collective operating authority over the entire project. Its primary tasks,
collectively, during or outside of regular or special meetings, are as follows:
o Initial validation and, if necessary, revision of the constituent elements of the project
submitted by the Project Manager: objectives/orientations, scope, contents and project
criticity (summarized in the project sheet), project organization (OBS), definition of tasks to be
completed (WBS) and of deliverables to be produced (PBS), planning and budgeting.
o Validation of key deliverables according to the cycles defined in the PBS.
o Tracking and confirmation of proper project execution (respect of objectives and scope,
overall progress and cost control).
o Confirmation that capabilities/resources (human and technical) are adequate to meet project
needs.
o Addressing of any difficulties encountered and resolution of operating and technical issues
submitted to him by the Project Manager or by the Work Package Managers as well as
preparation of corresponding plans of action.
o Initiation of an escalation procedure so that the Product Management Committee can make a
decision as soon as necessary. These problem resolution requirements must be submitted to
the appropriate Project Coordinator, whenever possible, to be handled in cooperation with the
various project participants and the DSI division managers.
o Authorization to pass a project milestone (according to the defined authority chart) in relation
to the elements submitted to him by the Project Manager (simple or conditional authorization)
with the possibility of a priori or a posteriori authorization.
o Preparation of end-of phase and end-of-project reports, and the development and tracking of
plans of action allowing, within the scope of the project, for the handling of identified points
of improvement.
Note: in the interest of reactivity and efficiency, deliverable validation activities are carried out
primarily by members of the Steering Committee as they are submitted by the Project Manager.
Steering Committee meetings are primarily devoted to tracking progress and handling problem issues,
resolving conflicts and achieving milestones.
The Steering Committee may routinely decide to delegate one of its responsibilities to any individual
(for example to the Project Manager).
Steering Committee meetings shall be organized and chaired by the Project Manager, who is also in
charge of formalizing and distributing the decisions made there.
5.2 The Product Management Committee (CODIR)

The Product Management Committee is the highest project control authority. In contrast to the
Steering Committee, it is not dedicated to one project. Its responsibility covers all projects carried out
for the same project owner. It consists of the following:
o The directors of the DSI (the DSI and the division managers involved in the projects);
o The project owners directors;
o The Project Coordinator;
COMPANY/DSI
27
And by project: the Project Manager and other Client, project owner or DSI representatives,
depending on the subjects covered and by invitation from one of the "permanent members
of the Committee.
The Product Management Committee has collective operating authority over all projects. Its primary
tasks, collectively, during regular or special meetings are:
o Validation or return for adjustment of the constituent elements of projects:
objectives/orientations, scope, content and project criticity (summarized in the project sheet),
project organization (OBS), and key deliverables to be produced (excerpts from the PBS),
summary plans and budgets.
o Tracking and monitoring proper project procedures (respect of objectives and scope, overall
progress and cost control).
o Handling difficulties encountered and resolving issues submitted to it by the various Steering
Committees (escalation procedure) as well as developing corresponding plans of action. In
this regard, it can be led to define priorities between the various projects, with corresponding
resolution of resource conflicts.
o Validation or return for adjustment of plans of action developed by the Steering Committees
for handling major difficulties encountered (sticking points, crisis situation, etc.).
o Authorization to reach a project milestone (according to the defined authority chart) with
regard to the elements submitted to it by the Project Manager (simple or conditional
authorization) with possibility of a priori or a posteriori authorization.
o Validation of end-of-phase and end-of-project reports tracking of the corresponding plans of
action.
o As manager of the product life cycle (encompassing the project life cycles), determination of
the end of the product, allowing the project elements to be archived.
The Product Management Committee may routinely decide to delegate one of its responsibilities to
any individual (for example to a Project Manager or to the Project Coordinator) or committee (for
example to a Steering Committee).
The Product Management Committee meetings shall be organized and chaired by the project owner in
collaboration with the various Project Managers, who will propose items for inclusion in the meeting
agenda and will then see to the presentation and handling of these items. The project owner is also
responsible for formalizing and recording the decisions made during these meetings.
COMPANY/DSI
28
5.3 Impacts on standard hierarchical relationships

5.3.1 Diagram of established relationships (not including Project Coordination and
Project Quality)
Product
management
Committee
The PMs supervisor

member of the CODIR
is
usually
Inter-projects
Steering for progress

decisions
and
arbitration
including
passing milestones
Steering
Committee
PMs
supervisor
Dsignation
Validation
of
key
project
management
deliverables
(project
sheet,
schedule,
resource
acquisition
plan,
steering sheet, project reviews)
Steering for collective progress

decisions and arbitration including
validating deliverables and passing
milestones
Project
Manager
Deliverable validation
progress tracking
Work Package
Manager
Proj
et
Designatio
n
Hirarchique
WPM
Designation
Allocation of project resources
Validation of key deliverables
(projects, development cycle,
products)
Operating
authority
Hierarchical
authority
Fully
valid
participation
Fully
valid/project-dependent
participation
5.3.2 Impacts on the hierarchical authority of the Project Managers supervisor

o
o
o
The function of the overall Project Manager does not introduce any reduction in the
operational hierarchical authority of his supervisor over the current scope of the position
held by the employee acting as Project Manager, no matter what it is.
His supervisor also retains his full hierarchical human resources authority (evaluation,
career management, team management, administrative management).
As is already the case for the other functions of the employee acting as Project Manager,
his supervisor must play the role of coach/advisor in his new role, from both a
methodological and managerial point of view.
o As such, he must see to the adequacy of his skills and capabilities in relation to this
role.
On an "operational level, the Project Managers supervisor:
o Possesses a certain number of direct project management prerogatives indicated in
the previous diagram;
o Is in most cases a member of the Product Management Committee and as such
participates in high-level project control;
When this is not the case, he is within his rights to require that the
Project Manager communicate his projects tracking element and
participate indirectly in controlling the project through his own supervisor,
who is himself a member of the Product Management Committee.
5.3.3 Impact on the hierarchical authority of the Work Package Managers

supervisor
o
COMPANY/DSI
The Work Package Manager function is not, strictly speaking, a "new one. The
Management By Project process adds a control and cross-coordination layer.
29
The Work Package Managers supervisor retains his full hierarchical authority:
o over the "technical" part of the WPM function, which is retranscribed into the
validation cycles for development cycles and products deliverables;
o over the "HR" part, especially with regard to resource allocation, evaluations, team
management and careers.
On the other hand, authority over "work package control" is primarily assured
operationally by the Project Manager and the project authorities, to whom the WPM
reports and from whom he receives conflict resolutions and other decisions associated
with cross-coordination (achievement of milestones, for example).
o Nevertheless the WPMs supervisor retains his authority over the validation of
schedules and cost plans.
o He is also the recipient of work package tracking elements (control sheets, COPIL and
CODIR project reviews) as well as decision statements.
o ON the other hand, he participates in the Steering Committee only when he is himself
a Project Manager and does not fully participate in the Product Management
Committee.
o Since he has no hierarchical or operating association with the Project Manager and
the authorities, he must express any disagreements with their decisions and conflict
resolutions using his own hierarchical line which is itself represented to the Product
5.3.4 Positioning of Project Coordination and Project Quality

The Project and Project Quality Coordinator (Project Quality Manager or manager of the Quality-Safety
division) both have a duty to alert and to escalate if they detect any difficulties or malfunctions which
are not handled under the relationships defined earlier, whether hierarchical or operational.
The Project Coordinator also plays the role of facilitator in coordination and conflict resolution, and
that is included in his job description. Because of its "neutrality", this role can also, to a certain extent,
be played by Project Quality.
COMPANY/DSI
30
6 MANAGEMENT BY PROJECT PROCESS

6.1 Description of the process
The management by project (MPP) process can be broken down into seven essential phases. Each
phase is concluded by a review meeting to evaluate the projects performance with regard to its
objectives, and decide upon its continuation. This review takes place when a milestone is reached that
indicates the projects maturity status.
Reaching every milestone is conditional upon:
o
o
The production of certain deliverables or management documents,

Approval from a pre-determined authority,
both of which depend upon project characteristics (product, project owner, category, criticity).
These phases are as follows:
INITIALIZATION, abbreviated INIT
The purpose of this phase is to specify the reasons for the potential commitment to the
project.
It is concluded by the BSR (Business Review) milestone, which marks agreement on the
economic relevance of the project.
EVALUATION, abbreviated EVAL
The purpose of this phase is to assess the feasibility of the project with regard to
COMPANYs strategic orientations, its capabilities and the foreseeable return on investment. It
is concluded by the FSR (Feasibility Review) milestone, which indicates agreement about the
projects feasibility.
SPECIFICATION, abbreviated SPEC
The purpose of this phase is to define the projects precise content and decide on its
technical choices. It is concluded by the DFR (Definition Review) milestone, which indicates
agreement about the projects definition.
EXECUTION, abbreviated EXEC
This phase covers most of the component production operations (software and nonsoftware) of the project. It is concluded by the EXR (Execution Review) milestone, which
indicates agreement about the projects execution.
ORGANIZATION PREPARATION/READINESS, abbreviated PREP
This phase covers all the intermediate operations between the production of a tested code
and its availability to clients in the form of an operating, sustainable, documented and
supported product. It concludes the final documentation steps and most of the steps for
acceptance, industrialization, production, putting into operation, making available to test
customers (development partners, beta-tests), transfers of knowledge and responsibility to
operational divisions, etc. It is concluded by the VLR (Validation Review) milestone, which
indicates agreement on the projects validation and the fact that the entire organization is
ready to market and support the release.
COMPANY/DSI
31
LAUNCH, abbreviated LAUNCH

This phase covers all the marketing, commercial and customer relations operations
surrounding the market introduction of a new product or new release: press activities,
conferences, user training. Note: the processes of installation, configuration, updating client
configurations are not part of this phase. It is concluded by the LNR (Launch Review)
milestone, which indicates agreement on the fact that the launch operations have been
completed and that the release is now in full operation.
CLOSING, abbreviated CLOSING
The purpose of this phase is to produce a technical and organizational report on the project,
in order, primarily, to take stock of difficulties encountered and suggest directions for
development or improvement. It is concluded by the FPR (Final Project Review) milestone,
which indicates agreement about completion of the project.
This life cycle is summarized in the following diagram:
INITialization
Definition of the
opportunity
BUSINESS
REVIEW
FEASIBILITY
Initial decision about

REVIEW
interest and feasibility
Execution
EXECUTION
REVIEW
VALIDATION
Verification & Development

REVIEW
Industr. & Customer Transfers
CLOSING
LAUNCH
Market introduction
DEFINITION
Precise
Identification
REVIEW
of content & final
decision
PREParation
EXECution
LAUNCH
REVIEW
COMPANY/DSI
SPECification
EVALuation
Report
FINAL PROJECT
REVIEW
32
6.2 Authority Charts

The validation of each of the milestones presented above is subject to the approval of a specific
authority, who thus assumes the responsibility for authorizing a project to reach an end-of-phase
milestone.
This authority is predefined for each milestone as a function of the product/program associated with
the project, its project owner, its category and its level of criticity.
Four responsibility levels have been identified at the COMPANY in project management:
MOA
PM
CoPil
CoDir
Individual representative of the Project owner: PSP Director, Product Manager,

Marketing Manager, DSI Manager
Project Manager, in general an authorized representative of the MOA or of the DSI:
BET, DDO, Developments
Steering Committee of the project consisting of the Project Manager, work package
managers, and a quality manager, including, if applicable, representatives of clients or
of project ownership
Management Committee for "products" consisting of DSI and project ownership
executives
Note: a responsibility can be transferred routinely to any committee or individual acting by delegation
for one of the authorities named above.
The chart below defines the levels of responsibility required to validate the achievement of a
milestone, depending on the category and criticity of the project being considered.
For simplification purposes, the combination of a "development" project and an extreme criticity
(Extreme Development) project is managed as a creation.
COMPANY/DSI
33
MOA
Creation
Update
Maintenance/R&D
MOA
MOA
MOA/PM
BSR
Subsidiary/Product
Subsidiary/Client
Internal
MOA / PM
MOA
MOA/PM
FSR
Subsidiary/Product
Subsidiary/Client
Internal
CoDir
DFR
Subsidiary/Product
Subsidiary/Client
Internal
CoPil (*)
EXR
Subsidiary/Product
Subsidiary/Client
Internal
CP
CoPil
CP
VLR
Subsidiary/Product
Subsidiary/Client
Internal
MOA / PM
MOA
MOA/CP
CoDir
CoDir
CoPil (*)
CoPil (*)
CoPil (*)
PM (*)
PM
CoPil
CP
CoPil (*)
CoPil (*)
CoPil (*)
LNR
Subsidiary/Product
Subsidiary/Client
Internal
FPR
Subsidiary/Product
Subsidiary/Client
Internal
INIT
CoDir
CoDir
CoPil (*)
CoPil (*)
CP (*)
CoPil (*)
PM (*)
PM
CoPil
PM
PM
PM
CoPil
PM
PM
Note: The blue background indicates the validation authorities for a "normal" project such as a
biannual product release.
(*) indicates, for a project of high criticity, that authorization depends on the higher level (CoDir
instead of CoPil, Copil instead of PM)
6.3 Project procedure

The major steps in the procedure for a project are defined as follows:
Step 1 Define the target: This step describes an ideal view of the project, independent of
resource constraints. It consists of the following procedures:
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Define the scope of the project

Define the PBS Product Breakdown Structure (deliverables)
Define the WBS (Work Breakdown Structure ) and the overall budget
Establish a general macro-plan and a macro-plan by work package
Position the key Milestones (phase, integration, interdependencies, etc.)
Identify resource requirements
Identify risks
Step 2 Establish a reference [baseline]: This step describes a view of the project in
harmony with resource capacities, to which the Project Manager is committed. It consists of
the following procedures:
2.1 Allocate resources to tasks
2.2 Develop risk management plans
2.3 Update the PBS, WBS, and milestones
COMPANY/DSI
34
Step 3 Track progress: This step evaluates the performance of the project from two
different angles: physical (what is actually produced) and consumed (resources). It consists of
the following procedures:
3.1 Tracking the progress of a work package (deliverables & intermediate
milestones).
3.2 Tracking project progress (deliverables & end-of-phase milestones)
3.3 Tracking and summary of time elapsed
3.4 Re-estimate at end-of-phase and end-of-project (planning and costs)
Step 4 Project Review / Phase/Project Closure: These steps evaluate each phase of the
project, in terms of both deliverables produced and subjects associated with the operation of
the project itself. During these steps, reports and reviews are prepared. They consist of the
following procedures.
4.1
4.2
4.3
4.4
4.5
End-of-phase review (milestone reached)

Steering Committee review
Product Management Committee review
End-of-phase report
End-of-project report
These steps will be detailed in the following paragraphs.
6.3.1 STEP 1 Definition of the projects target

6.3.1.1 Step 1.1: Definition of the projects scope
This procedure consists of the following steps:
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
Identify the stakeholders: Project Owner, Project Manager and potential members of the
Steering Committee.
Define the product/program, the category and the level of project criticity.
Agree with the Project Owner on a description of the project and expected advantages for
customers.
Identify the primary deliverables of the project and especially the relative importances of
software and non-software deliverables (user documentation, training support materials,
marketing documentation).
Identify the key success factors (KSF) and the key performance indicators (KPI)
corresponding to the project. The most immediate ones concern the release date (LNR
milestone) and the project budget. Other KSFs may involve:
o
o
o
o
o
o
o
o
o
o
o
1.1.6
COMPANY/DSI
The number of pending improvements processed

The number of corrections made
The amount of code resulting from the project
Technologies to be considered with regard to the project
Capabilities to be acquired as part of the project
Performance provided
Levels of service required
Database volume
Operating constraints and costs
Localization
Etc.
Identify the critical risks and milestones that involve a dependency or a factor that is external
to the project:
o Customer commitment (delivery date, SLA, etc.)
o Access to the development environment
35
o
o
o
o
1.1.7
Identify sources of information needed for the INITIALIZATION and EVALUATION phases:
o
o
o
o
o
o
o
1.1.7
Acquisition of equipment or software for development

Integration of external software components
Acquisition of capabilities
Integration of components originating from geographically distant locations
Expressions of requirements
Marketing teams
Subsidiaries
Technico-commercial
User associations
Market studies
Competitive items
Constitute, based on these elements, a primary version of the PROJECT SHEET, in agreement
with the Project Owner and the Project Manager, and distribute it to the Steering Committee
for information and validation.
6.3.1.2 Step 1.2: Preparation of the PBS

This procedure involves the preparation of the PBS (Product Breakdown Structure), an exhaustive list
of project deliverables derived from a PBS_type model.
This "PBS_type" model identifies all the deliverables that are likely to be produced by a project.
Nevertheless, projects are not called upon to systematically produce all the deliverables in the PBS.
The model should be used by the Project Manager as a reference guide to follow with the purpose of
identifying the elements that the project must produce. This reference provides the starting point for
identifying the tasks to be performed in order to complete the project.
1.2.1
Starting with the "PBS_type" model, the Project Manager / MOA Representative / Work
Package Manager together identify the constituent elements of the project. Depending on the
category of the project, some elements are mandatory, others are optional. Responsibilities
must also be identified in terms of:
o
o
o
Drafting/development (document author/developer) of the PBS component

Participants in the review and validation cycle
Supervision of the manufacture of these components
It is likely that the projects PBS will not be completed on the first attempt. It may be updated
and completed until the end of the evaluation phase. After this phase (FSR milestone),
changes will be possible if they respect the monitored modification management procedures.
1.2.2
For purposes of later progress measurement, it may be useful at this stage to evaluate the
relative weight (contribution to value) of each component of the PBS in the final result.
1.2.3
Distribute the PBS to the attention of the members of the Steering Committee.
COMPANY/DSI
36
6.3.1.3 Step 1.3: Definition of the WBS

This procedure allows the necessary activities to be determined for producing the components of the
PBS. It consists of a vertical hierarchical breakdown (from top to bottom) of the work to be done,
starting with the overall project and proceeding by levels that are more and more detailed. The
detailed WBS is established progressively, phase-by-phase, as the components to be produced are
indicated and specified.
The lowest level describes the nature of the activity to be performed and the component to which the
work is applied.
At this level, it is appropriate to indicate the capabilities required and estimate the work load and the
time required to accomplish the task. This information allows a budgetary envelope to be calculated
for each phase of the project.
1.3.1
Break down the work to be performed into a primary level (level 1) of work-packages covering
the entire project, for example:
WP
WP00
WP01
WP02
WP03
WP04
WP05
WP06
WP07
WP08
WP09
Title
Project management
Engineering studies
Database development
Development, Front office module
Validation
Industrialization
Development of training support materials
Documentation
"Downstream" Marketing
1.3.2
At the next level down (level 2), in cooperation with the Work Package Managers, identify the
tasks and task sequences. At this level the WBS component must be associated with a
management phase (INIT, EVAL, SPEC, EXEC, PREP, LAUNCH, CLOSING).
Example: detailed specifications (associated with the SPEC phase)
1.3.3
At the next level down (level 3), identify the component to which this task sequence shall
apply. At this level, the WBS component must be associated with a PBS component.
Example: detailed specifications of the Front office module.
1.3.4
At the lowest level (level 4), identify the detailed sequence of activities required to produce
the component.
Example: Draft, Review, Modification, Validation of detailed specifications.
1.3.5
For this lowest level, identify the capabilities required to produce the component.
Example: Analysis, writing, java/J2EE/Jsv capabilities
1.3.6
Estimate the work load in days required for the completion of each activity.
Also estimate the number of persons likely to be working simultaneously on this activity, so
that a probable time required for the task can be deduced. Do not fail to incorporate a safety
factor, taking into consideration the time required for coordination between individuals, if
applicable.
The function points method is used and corresponds to the standardized technique which
measures the size of a software component using quantification of the functions from the
users point of view. The function point is based on a logical view, and not a technical one, of
the functional features of the software.
COMPANY/DSI
37
1.3.7
Finally, assign a unit rate to each type of capability allocated to the task (optional). Adding
them at the project level will provide part of the components that constitute the projects
budget, with the other components consisting of purchases for equipment, software,
supporting documentation, travel and lodging expenses, etc.
6.3.1.4 Step 1.4: Planning and scheduling

The goal of this procedure is to introduce the logical relationships between the various activities from
the lowest level of the WBS, in order to obtain detailed schedules and estimate a target duration for
each phase. At this stage we shall not yet preoccupy ourselves with availability of resources. The
execution of this procedure is the responsibility of the Work Package Managers in close collaboration
with the Project Manager.
1.4.1
Introduce logical scheduling between the lowest-level tasks of the WBS. This logic is applied
by defining constraints associating the activities with each other. Four types of constraints can
be considered:
o End to Start
o End to End
o Start to End
o Start to Start
These constraints may be instantaneous or cause positive shifts (lead time) or negative shifts
(lag time) to appear.
Example: End of design associated with Start of development (End to Start)
1.4.2
Use this to fine-tune the time required for all activities and analyze the schedule obtained.
Proceed with adjustments, involving for example the durations or constraints between tasks,
until a satisfactory result is obtained.
6.3.1.5 Step 1.5: Planning milestones

The objective of this procedure is to allow the identification and location of milestones indicating a
significant step in the progress of the project. The execution of this procedure is the responsibility of
the Work Package Managers in close collaboration with the Project Manager.
1.5.1
Identify all planning milestones. Unlike the end-of-phase milestones, they can be
distinguished either by obtaining a given component or by the fact that they mark an
interdependence between several tasks in the project. Typically, these milestones are
positioned relative to a level-3 component of the WBS.
Examples:
M01
M02
M03
M04
M05
M06
M07
M08
M09
M10
M11
M12
M13
M14
M15
M16
COMPANY/DSI
Operating Specifications
Project Sheet (1st edition)
General Operating Specifications
Detailed Operating Specifications
Acceptance Notebooks
Development Environment Availability
Design File
Configuration Management Plan
Integration Environment Availability
Software Integration (Alpha DVL Release)
Acceptance Environment Availability
User Documentation (Draft)
Internal Training Plans and Support Materials
Functional Acceptance Record (Beta version)
Operating Notebooks
User Acceptance Record / Release Note (Production version)
38
M17
M18
M19
M20
1.5.2
Pre-production environment
Production Environment
User Documentations (copy)
External Training Plans and Support Materials
Identify the interdependency milestones that involve a constraint imposed by a factor that is
external to the project.
Examples:
o
o
o
Availability of a specific piece of equipment or environment (development, production)

Development Task conditional upon Acceptance of a New Server Task
Integration of external software components
1.5.3
Position these milestones in the plans (tasks with no duration), ensure that they are
acceptable to the various stakeholders. The plan obtained in this way shall be designated the
Target Plan."
1.5.4
Distribute the target plan to the Project Manager for validation and consolidation before
distribution to the Steering Committee.
6.3.1.6 Step 1.6: Resources and budgets

The purpose of this procedure is to define a budgetary profile that takes into consideration the
allocation and potential valorization of project resources. The execution of this procedure is the
responsibility of the Work Package Managers in close collaboration with the Project Manager.
1.6.1
Adding the capability needs and the unit rates indicated in paragraph 3.3 Definition of the
WBS results in a task plan that is broken down into phases over time.
1.6.2
Assign all other forms of expenses, purchases, costs etc. that do not involve man-hours to any
tasks to which they apply.
1.6.3
Consolidate all preliminary expenses or costs into an expense or budget plan for each phase.
This is how the target budget is obtained.
1.6.4
Distribute for consolidation and validation by the Project Manager before distribution to the
Steering Committee by the Project Manager.
6.3.1.7 Step 1.7: Identifying risks and vendors
6.3.1.7.1 Risk management method

Risk Analysis is performed by the Steering Committee, under the responsibility of the Project Manager,
according to the following seven steps:
1. Examine the "Client Requirements"
2. Identify risks by sector, using for example the check-list proposed at the end of this
document.
3. Rate the "probability that each risk will appear from 1 to 4, where 1 is the lowest probability
and 4 the highest. If a consensus is difficult to reach, use the average of the "probability"
scores given by participants.
4. Identify the impact of each risk in terms of effect or consequence to the project that could
influence the achievement of the objectives.
5. Rate the "impact" of each risk from 1 to 4, where 1 is the lowest impact and 4 the highest. If
a consensus is difficult to reach, use the average of the impact scores given by the
participants.
6. Calculate the weights of the risks: weight of risk = probability x impact
COMPANY/DSI
39
7. Identify palliative actions and these actions managers to be proposed in a summary, in

response to weights of risks greater than 8 that correspond visually to the colors red and
black.
6.3.1.7.2 Diagram of the risk management process

Risk Management Process
28/06/2007
Identify context
Identify risks
using the checklist
Determine probability
Determine impact
Estimate risk level (weight)
N=P
Fill in the summary table
Risk summary
table
Track and monitor
Communicate and consult
Analyze risks
Evaluate risks
by priority
Accept risks ?
oui
non
Manage risks
assigning a manager
Fill in the action tables
Action tracking
table
Titre
CEGEDIM/DSI
Auteur : Soudy Eric
Date : 21/12/2005
6.3.1.7.3 Risk summary

The summary chart shows the results by sector of steps 2 through 6 of the analysis method.
In it are recorded the ratings for "probability" that each risk will appear and for impact in terms of
effect or consequence on the project, and finally the calculation of the weight of risk:
COMPANY/DSI
40
weight of risk = probability x impact

Example: Analysis of risks in the sector: Management, organization and
partnership
Risk Analysis
Management, organization and
partnership
Weight of risk
=
probability x impact
1-4
low
5-8
medium
9-12
high
13-16
critical
++
--
Ref.
Action
Risk - probability from 1 Note Impact from 1 through 4 Note Weight

through 4
RSK01 Time required for results of
2
Revision of specifications and
4
8
experiments with prototype
budgetary evaluations
RSK02 Non-synchronization of interface
projects (4)
Integration blocked, the team

is on hold, cost overruns and
plan deviation (3)
Summary of risk analysis (= maximum of weights)
12
N
1,3
2
12
6.3.1.7.4 Tracking actions

The action tracking chart shows the results from step 7 of the analysis method. It restates the actions
numbered in the previous chart, describes them and assigns responsibility and a deadline date.
Actions for risks with weight greater than 8 must systematically be documented. Actions defined in
this way shall be grouped in the tracking chart.
Example:
N
1
2
Proposed action
Synchronize with the prototype so as to
incorporate its conclusions in the base
evaluation.
Identify synchronization constraints, plan
with
safety
margins,
taking
into
consideration the system integration plan,
and track at the detailed level.
Present the prototype to the entire MOA,
in particular to the representatives of the
end users.
Manager
J. Dupont
When?
July 31,
2005
Completed on
August 16,
2005
G. Durand
September
30, 2005
In progress
J. Dupont
August 15, August 16, 2005

2005
6.3.1.7.5 Observations on risk management

6.3.1.7.5.1 Ephemeral risks
Now we draw the readers attention to a type of technical risks known as "ephemeral risks." They
have a high probability of occurrence and a heavy impact; they appear suddenly because they are
unexpected and disappear just as quickly once they are solved. This type of risk appears frequently in
the technical sectors that are rapidly evolving; they seem to upset the establishment of management
charts but contribute to the enrichment of the return of experience.
6.3.1.7.5.2 Client and supplier perception

The perception of project risk may be different depending on the outlook of the MOA or the project
manager, and this must be taken into consideration when communicating with all of the project
stakeholders. Risks must not be evaluated from the viewpoint of the project manager alone.
COMPANY/DSI
41
6.3.1.7.5.3 Categorizing of actions

Every action proposed must correspond to one of the following types:
Communication action
These actions allow opinions to be expressed, misunderstandings to be resolved, specific points in the
project to be clarified (roles, responsibilities, etc.). This can take place during meetings (brief
statement) or scheduled for later presentation.
Client requirements action
These actions are an opportunity to explain to project management about the importance of a client
requirement. The purpose of these explanations is to improve project quality by re-centering it around
the clients requirements and thus by avoiding deviations from potential artists.
Risk-related action
The purpose of these actions is to decrease the risks associated with the project. This decrease in risk
can be done in two ways. As with safety, we can speak here about "Active quality" and Passive
quality.
Actions associated with "Active quality" allow the risk to be addressed before it even happens, by
decreasing the likelihood that it will occur (example: Action of training the project team to decrease
the risk of inadequate project team skills).
Actions associated with "Passive quality" allow the effects of the hazard associated with the risk to
be minimized (example: Action of reserving human resources to ease the consequences of a risk of
failure to respect deadlines).
Risk-taking action
Certain risks cannot be decreased. They are in fact a characteristic of the project (example: risk of
"lack of technological maturity for a project based on XML technology if the standard does not lead to
a stable revision). In this case, these risks must be explained to the project owner so that he may
better understand them and, if they cannot be minimized, accept them.
Proposed actions must be "SMART" actions, i.e.:
Simple: They must respond to a type of action (see above) and a risk or client
requirement identified in the various analyses.
Measurable: Proposals for action must be accompanied by cost and results estimates (in
terms of decrease of risk for example).
Acceptable: They must be realistic, not guesswork, with regard to the problem being
posed, in particular as regards the costs of the proposed action.
Revisable: They must not be firm and may be reevaluated and revised depending on
events occurring during the project.
Scheduled: A deadline must be set for the completion of these actions, as well as a
manager for tracking the action.
A cost evaluation and estimate variations must be reviewed by the Steering Committee.
6.3.1.7.6 Vendor management (Sub-contracting)

Sub-contractor management consists of evaluating, selecting and efficiently managing vendors as a
function of their ability to provide a product or service in compliance with the companys
requirements.
The management process for vendor relations describes the activities expected and the various
applicable factors. This process is generic, and each project must adapt it to that projects
requirements in its development plan.
The vendors referred to here belong to specific categories. These are:
COMPANY/DSI
42
o
o
Development or consulting projects performed on a one-time basis by a third-party

organization as part of a contract specifying the nature of the work to be performed.
Here we are referring to sub-contracting.
Third-party products selected for integration into an existing application or one that is
under development. Here we are referring to "OEM" or "ISV".
In the case of a "Commercial Off-The-Shelf" product or one selected out of a catalog,
refer to the procedure COTS Management Process.
The integration of temporary external resources into projects, often referred to as temporary
staffing is not part of the scope of application of this process.
Roles
Responsibilities
Project
Manager /
Manager of
Vendor
Relations.
Handles all the defined functions and responsibilities of the Project

Manager. As such, he plans and delegates the internal activities associated with the
management of sub-contractors (drafting of the business case, drafting of the
specification and call for bids, selection of sub-contractor, transfer of capabilities,
making test platforms available, acceptance, etc.).
More specifically:
He is the operating manager for sub-contracting.
He monitors the sub-contractors work.
He ensures that the contract is implemented.
He guarantees that the party who placed the order will respect its
commitments with regard to the sub-contractor.
Above all, he promotes the successful achievement of the subcontractors objective in the interest of maintaining balance between the contracting
parties.
He manages change orders and any conflicts that may arise, with the
approval of the Steering Committee.
He reports to the Steering Committee.
Purchasing
Manager
Ensures the coherence of the call for bids with the standards of the
organization.
Prepares the selection with the Project Manager.
Manages financial negotiations.
Participates in sub-contractor selection.
Participates in managing change orders and conflicts.
Documents the sub-contractors performance in the organizations

tracking base.
Legal
Counsel
Ensures the legal coherence of the contract.

Participates in managing change orders and conflicts.
The vendor management process is defined as follows:
COMPANY/DSI
43
Start of process
Project Manager
and Steering Committee
Project Manager,
Steering
,
Commitee
and BET
Project Manager
and Steering Committee
Project Manager,
Purchasing Manager,
Steering Committee,
and sub-contractor
Project Manager
and sub-contractor
-t
Project Manager,
Conference Manager,
Steering Committee,
and sub-contractor
-
Initiation
Make the decision to sub-contract;

Business case.
Preparation
Draft specifications;
Prepare call for bids.
Management
Selection
&
Contract preparation
Transfer of
capabilities
& coaching
Tracking & monitoring
Project Manager,
Purchasing Manager,
Steering Committee
and sub-contractor
-
Transition
Project Manager
and sub-contractor
-
Restitution
Issue call for bids and

monitor response
to call for bids
Make sub-contractor
- selection
Sign the contract.
Provide sub-contractor
swith
information and equipment
necessary to participate
in the project.
Track and monitor progress.
Set up indicators.
Prepare acceptance reports;
Transfer sub-contractor
skills to the client. Take care to ensure clients
property is returned.
End of process
6.3.2 STEP 2: Definition of the project reference

6.3.2.1 Step 2.1: Allocation of resources to tasks
The purpose of this procedure is to replace the general capability and cost profiles, identified in the
previous steps, by individual resources whose capabilities and availabilities allow the tasks to be
performed as they are described at the lowest level of the WBS.
Taking into consideration the availability constraints of human resources, it is probable that the plans
resulting from this allocation exercise will present discrepancies relative to the target plans resulting
from the previous step. This reference therefore represents the best possible compromise, in
comparison with which progress will be evaluated.
Execution of this procedure is the responsibility of the Work Package Managers in close collaboration
with their hierarchy and with the Project Manager.
COMPANY/DSI
44
2.1.1
Identify individuals possessing the capabilities required for each activity.
2.1.2
From among these individuals, identify those that are available during the period of time
being considered for the activities in which they are to participate. If there is no precise
correlation between needs and availability, alter the task as little as possible.
2.1.3
Assign individuals to tasks, and then adjust the plan so as to minimize deviations from the
target plan. The resulting plan shall be designated the Baseline Plan.
2.1.4
Contact each resource individually (and/or his manager) to get his agreement on the nature
of the work to be performed, the corresponding cost and the time window(s) during which
these tasks must be performed. No scheduling margin should be announced. However, it is
important that all the resources participating in critical-path tasks be notified of it, so as to
promote good awareness of the impact of any possible delay. Project organization can then
be finalized (OBS issued).
2.1.5
Ensure that availability profiles are updated after resources have been allocated.
2.1.6
Publish the Baseline Plan and distribute it to the members of the Steering Committee.
2.1.7
Recalculate budgets or expense plans based on the Baseline Plan. In this way the "baseline
budget" is obtained, whose total must not differ significantly from that of the target budget.
6.3.2.2 Step 2.2: Risk assessment

Experience has shown that a project never proceeds exactly in compliance with its initial plan. A
project always experiences unanticipated unknowns of various causes: inaccuracies in estimates,
delays in availability of resources, risk occurrence, etc.
In order to protect the project from the impact of these potential unknowns, it is strongly
recommended that provisional tasks, sometimes called plug tasks, be incorporated into the plan.
It is clear that these provisional tasks must be compatible with the commercial requirements and
client commitments. In an extremely competitive environment, the incorporation of this type of tasks
remains an exercise that is difficult but well worth completing.
Part of this maneuvering margin can be left to the discretion of the Project Manager, and the
remainder shall remain the responsibility of the Management Committee.
Execution of this procedure is the responsibility of the Work Package Managers in cooperation with
the Project Manager and the Project Quality Manager.
2.2.1
Identify a list of potential risks and milestones likely to be affected by these risks.
2.2.2
Identify measures that will allow prevention or compensation of the effects of each risk,
determine their duration, and deduce tasks that constitute as many provisions as possible for
unanticipated unknowns.
2.2.3
Incorporate these "plug" tasks into the plan. A reasonable number of these tasks, with
reasonable duration, may for example be scheduled after review or integration tasks have
been completed, thus freeing up time which can be devote to a rework or to the completion
of a task without that jeopardizing the plan. They may also be systematically integrated
before any major milestone.
COMPANY/DSI
45
6.3.2.3 Step 2.3: Project update

Allocation of resources and incorporation of preliminary tasks involve substantial modifications in time
and expense planning. This is why it is necessary to update certain project management components.
Executing this procedure is the responsibility of the Work Package Managers in cooperation with the
Project Manager.
2.3.1
Update milestone scheduling after resources have been allocated.
2.3.2
Update the PBS after the incorporation of provisional tasks when these tasks involve the
production of new or alternative deliverables.
2.3.3
Update the WBS, schedules and especially milestones, after provisional tasks have been
incorporated.
2.3.4
Update expense plans and budgets as required after WBS update.
2.3.5
After this adjustment, distribute the baseline budgets and schedules to the members of the
Steering Committee and the Product Management Committee.
6.3.3 STEP 3: Tracking the projects progress

Tracking the progress of a project consists, on the one hand, of physically measuring the progress
accomplished in the completion of deliverables to be provided, and on the other hand, evaluating the
work put into it.
6.3.3.1 Step 3.1: Tracking the progress of a work package

The purpose of this procedure is to clarify how to evaluate the physical progress of the work
completed. The concept of arithmetic mean has no meaning in terms of accumulating progress
percentages, so it is necessary to refer to the deliverables and to their contribution to the entire
project in order to evaluate the overall progress of the work package, or of a set of tasks belonging to
the same work package.
The execution of this procedure is the responsibility of the Work Package Managers.
3.1.1
Determine in advance what is the relative importance of each task within the work package.
Then consider the contribution of the task to the progress of the work package.
For example, a Work Package may consist of 50 tasks, each of which contributes 2% of the
final result. In practice, this determination is not as simple, since some tasks contribute more
than others.
3.1.2
Then determine what will be the evaluation rules for each tasks within a given work package.
From among the possible formulae, 2 options may be selected:
0100%: the task remains at 0% progress as long as the corresponding deliverable is
not validated by the work package manager.
0X100% or any other progress scenario: the task is estimated at X% when a
certain level of development is reached (for example a document before review, a
component before unit testing).
3.1.3
COMPANY/DSI
For each task, evaluate the work completed by multiplying the percentage of progress of the
task by its contribution to the work package. This is how we obtain homogeneous
measurements that can be added to provide a view of the physical progress of the work
package.
46
Example: in this case, the physical progress to be declared is 57%

contribution % progress
% completed
2
100%
2%
5
100%
5%
5
100%
5%
5
100%
5%
10
100%
10%
10
50%
5%
10
50%
5%
20
50%
10%
10
50%
5%
10
50%
5%
8
0%
0%
5
0%
0%
57%
100
task 1
task 2
task 3
task 4
task 5
task 6
task 7
task 8
task 9
task 10
task 11
task 12
6.3.3.2 Step 3.2: Tracking the progress of a Project

3.2.1 The execution of this procedure is the responsibility of the Project Manager. Measuring the
physical progress of the project itself can be done using two formulae:
Values assigned to end-of-phase milestones: According to this formula, the Project Manager and
the Steering Committee decide arbitrarily, before the FSR milestone, what will be the total value
produced by the project at the end of each phase.
Example:
Milestones
BSR
FSR
DFR
EXR
VLR
LNR
FPR
Cumulative value
5%
20%
40%
70%
90%
95%
100%
Weighted accumulation of work packages: According to this formula, each work package is
assigned a weight within the project. Physical progress is then calculated according to a mechanism
similar to that used for calculating the weighted progress of the package from that of the tasks, as
defined in the previous section.
6.3.3.3 Step 3.3: Tracking of time elapsed

This procedure allows us to determine the time elapsed and to re-estimate the work remaining to be
provided in order to complete each task. Execution of this procedure is the responsibility of the Work
Package Managers.
3.3.1
Log the time (number of days or hours) actually spent by each individual for each scheduled
task.
3.3.2
At the same time, evaluate for each task the work remaining to be supplied by each individual
in order to complete the task, and the corresponding completion date.
It is recommended that this tracking and these re-estimations take place on a weekly basis.
COMPANY/DSI
47
6.3.3.4 Step 3.4: Re-estimation

Execution of this procedure is the responsibility of the Work Package Managers in cooperation with
the Project Manager.
3.4.1
Recalculate schedules and budgets, taking the new factors into consideration.
3.4.2
If the re-estimated schedule reveals deviations of a significance likely to jeopardize the

remainder of the project, it shall be the responsibility of the Work Package Manager to issue
an exception report and to notify the Project Manager as soon as possible.
During this step, it may become necessary to review the contents of the project, or even
eliminate some deliverables and consequently update the PBS, in order for example to adhere
to the deadlines imposed.
6.3.4 STEP 4: Project Reviews and Reports

6.3.4.1 Step 4.1: End-of-Phase Review (milestone)
This procedure must be followed by the Project Manager. Its purpose is to allow the Management
Committees or the Steering Committee to pass judgment on the achievement of an end-of-phase
milestone.
4.1.1
It shall be the responsibility of the Project Manager to hold meetings on reaching a milestone,
either as part of the regular meetings of the Steering Committee or of the Management
Committee, or by convening one specifically if the status of the project requires it.
4.1.2
The Project Manager shall assemble the deliverables and documents indicated by the PBS and
required for the milestone to be reached, attesting to the fact that the phase has been
completed.
4.1.3
He shall verify, along with the Quality Manager, that all the documents to be submitted have
been reviewed and validated according to the procedures indicated in the PQP, and especially
that the various technical experts and operating managers involved have contributed to the
development and validation of these deliverables as they should.
4.1.4
In particular:
o
o
o
He shall also prepare the schedules and budgets corresponding to the following
phase, and update the schedules and budgets as a function of the information
gathered from the Work Package Managers.
He shall ensure that the record of [sic] and the record of monitored modifications are
up to date.
He shall ensure that the actions agreed upon when the previous milestone was
reached were in fact implemented, or that he has satisfactory explanations if this is
not the case.
4.1.5
He shall ensure, with Project Coordination, that the achievement of the milestone is recorded
in the agenda of the next Steering Committee or the next Product Management Committee
meeting, if the approval of one of these committees is required.
4.1.6
Along with Project Coordination, he shall take the necessary steps to bring all the documents
required to achieve the milestone to the attention of the members of the Committee at least
one week before the meeting, if the approval by that Committee is required. If necessary,
additional individual explanations may be requested by a member of the Committee before
the meeting.
COMPANY/DSI
48
4.1.7
The Management Committee or the Steering Committee shall authorize the achievement of
milestones upon proposal by the Project Manager, validate the documents and deliverables
proposed, or else announce reservations or postponements. It shall if applicable render any
arbitrations requested.
4.1.8
The Project Manager shall update the summary sheet.
6.3.4.2 Step 4.2: Steering Committee review

This procedure must be tracked by the Work Package Managers. Its purpose is to:
o
o
Allow the Project Manager to consolidate all the progress information coming from the
work packages, and to initiate any necessary corrective actions.
Allow the Steering Committee to collectively pronounce its agreement on the
achievement of a milestone under its authority.
4.2.1
It shall be the responsibility of the Work Package Managers to hold regular progress meetings
(weekly or bimonthly) according to the procedures described in step 3. The Project Manager
may or may not participate in these reviews, at his own convenience or that of the WPM, and
depending on the known or estimated difficulties in the project.
4.2.2
It shall be the responsibility of the Project Manager to hold regular meetings (monthly) of the
Steering Committee, establish an agenda for them, and prepare and distribute the minutes of
the meetings.
4.2.3
The Steering Committee meeting shall allow all WPMs to produce tracking charts, fill out the
steering sheet and submit, to the attention of the other WPMs and the Project Manager, a
progress update on their work in progress, point out any problems and bring to light any
difficulties associated with an interface with another work package or with an external
dependency.
4.2.4
Each WPM shall prepare for the meeting of the Steering Committee using the steering sheet.
If applicable, the Project Manager or the Steering Committee shall validate the documents and
deliverables proposed and render any arbitrations requested, or shall decide to submit the
decision to the Management Committee.
4.2.5
A specific time in the Steering Committee meeting may be devoted to the achievement of a
milestone.
4.2.6
The Project Manager shall draft and distribute the minutes of the meeting.
6.3.4.3 Step 4.3: Product Management Committee Review

This procedure must be followed by the Project Manager. Its goal is to allow the Management
Committees to consolidate all progress information about the projects in progress, and initiate
necessary corrective actions, if applicable.
4.3.1
It shall be the responsibility of the Project Managers to hold regular (monthly) progress
meetings according to the procedures described in the previous step (COPIL).
4.3.2
It shall be the responsibility of Project Management to hold regular (bi-monthly or quarterly)

meetings of the Management Committee, draw up its agenda, and prepare and distribute
meeting minutes.
4.3.3
The Management Committee meeting shall allow all the Project Managers to give a progress
update for their projects, point out any problems and bring to light any difficulties of such
nature as to affect the scope of the project, and request any corresponding decisions.
COMPANY/DSI
49
4.3.4
Each Project Manager shall prepare for the Management Committee meeting using the model
provided for this purpose (Steering Sheet and Summary Sheet).
4.3.5
The Management Committee shall validate all proposed documents, deliverables or plans of
action, pronounce reservations or postponements, and render any requested arbitrations.
4.3.6
The Management Committee meeting shall also allow the Project Manager to obtain formal
validation from the Management Committee on the achievement of a milestone, either in
advance or a posteriori, when the date for reaching a milestone and a meeting of the
Management Committee do not coincide by a few days.
4.3.7
Project Management shall draft and distribute the minutes of the meeting.
6.3.4.4 Step 4.4: End-of-Phase Report

The purpose of this procedure is to allow the Project Manager to establish a consecutive report for
each of the major management phases of a project. The purpose of this report is to improve both the
production of deliverables and the function of the project itself.
4.4.1
To draft the end-of-phase report, the Project Manager shall convene a meeting of the
Steering Committee, or shall include this profile in the agenda of the upcoming meeting.
4.4.2
He shall ask each WPM to prepare a report on his Work Package, addressing the deliverables
to be supplied during the phase, deliverables actually provided, and difficulties encountered if
any.
4.4.3
During the meeting, he shall go around the table and ask each attendee to present the list of
deliverables provided with regard to the objectives, explain any discrepancies observed and
then express what he feels to be positive or negative in the previous phase completed.
4.4.4
He shall note any points that caused difficulty, then after going around the table, he shall ask
all the participants to take some time to reflect on the identification and analysis of any
difficulties encountered.
4.4.5
He shall then ask the group to formulate improvement procedures in the form of plans of
action, responsibilities and time horizon.
4.4.6
He shall summarize, in the form of a phase report, all difficulties encountered and the
proposed improvement procedures, distinguishing, with the approval of the Steering
Committee, between what constitutes possible short-term improvements under the authority
of one or more members of the Steering Committee and what falls under the category of
longer term or requires authority outside of the Steering Committee.
4.4.7
He shall make the contacts and take the initiatives necessary within the company in order to
evaluate the follow-ups assigned to the actions that are not short-term or under the Steering
Committees authority. He shall report these actions to the Management Committee.
4.4.8
The Project Manager shall draft and distribute the minutes of the meeting.
6.3.4.5 Step 4.5: End-of-Project Report

The purpose of this procedure is to allow the Project Manager to prepare the overall report for a
project and to draft its closure report. These documents involve both the production of deliverables
and the operation of the project itself.
4.5.1
COMPANY/DSI
To prepare the end-of-project report, the Project Manager shall convene a meeting of the
Steering Committee, or shall include the report in the agenda for the next meeting.
50
4.5.2
When preparing for this meeting, he shall take all the end-of-phase reports and consolidate
them into a project report:
o
o
o
o
o
o
Any difficulties encountered

Difficulties resolved during the project
Unresolved difficulties
Actions agreed to in a phase report and completed during the project
Actions agreed to in a phase report and not accomplished during the project
Reasons for which these actions could not be accomplished.
4.5.3
Before the meeting, he shall receive a specific update from each WPM on the part of the
report involving him, and shall review the contents of the document with him.
4.5.4
Before the meeting, he shall prepare the Project Closure Report, whose purpose is to
document the performance of the project with regard to contents, deadlines and baseline
costs. To this end, he shall assemble the following components:
o
o
o
o
o
o
o
o
Project objectives, and the level to which these objectives were attained.
Deliverables produced vs. deliverables expected.
A document issued by the Project Quality Manager evaluating the quality of the
deliverables provided.
Schedules achieved vs. expected, indicating all milestones.
Costs incurred vs. planned.
Values of other key success indicators vs. objectives.
Any explanation related to analyzing and understanding any discrepancy.
A list of pending problems and actions arising from the project report.
4.5.5
He shall distribute this closure report to the WPMs for comments and validation before the
meeting.
4.5.6
He shall update the report based on the remarks issued by the WPMs.
4.5.7
During the meeting, he shall go around the table and ask each attendee to comment on the
project report and closure report and, if applicable, proceed with suggested adjustments. The
final report must be distributed to all members of the Steering Committee and the
4.5.8
The Project Manager may then declare the project to be formally completed.
4.5.9
It then becomes the responsibility of Project Management and the Quality Manager to how to
follow up on the pending difficulties and actions indicated in the closure report and to archive
this information if necessary.
COMPANY/DSI
51
7 QUALITY ASSURANCE PROCESS

7.1 Description of the process
The Project Quality Assurance Process defines all the activities and roles to be fulfilled in order to
implement the Quality Assurance function throughout the lifetime of a project.
The primary objective of Quality Assurance (QA) is to accompany the project team, throughout the
lifetime of the project, as project procedures and standards are implemented, and provide objective
visibility of the process and product quality status to the project team and to management.
The major activities in this process are accompanying the project as its processes are implemented,
and regular evaluation of project process and product compliance.
This process shall include a model of the Project Quality Plan (PQP) as well as check-lists that
shall serve as a guide to the process and product evaluations.
7.2 Roles and responsibilities

Roles / Authorities
Project Manager (PM)
Project Quality Manager (PQM)
Organization quality manager (OQM)

PQM Committee
Members of the project team

Acceptance Manager
COMPANY/DSI
Responsibilities
Responsible for the achievement of project
objectives (external and internal quality) and
for measurement of these objectives.
Defines or reviews and approves the quality
objectives of the project.
Reviews and approves the documents
provided by quality assurance.
Decides on and plans corrective actions.
Defines or assists in defining the quality
objectives for the project.
Plans reviews with the Project Manager.
Conducts reviews and quality audits on the
project.
Ensures the implementation of corrective
actions in the project.
Person designated as the manager of
organization quality objectives and arbitration
in case of unresolved non-compliances
Committee that meets regularly on the order
of the OQM. Consists of the OQM, the QA
process manager and all the PQMs
designated for projects in progress. Allows
for reporting and arbitration of noncompliances brought up during QA activity
and for completion of the Quality Tracking
Chart.
Contribute to the quality of supplies
Perform document reviews
Perform testing.
Person responsible for conducting all
validation testing, ensuring test coverage
relative to requirements, and issuing the
Validation Report.
52
7.3 Process Activities

Project
initiation
SQA1
Establish QA for
the project
SQA2
Specific QA
activities
SQA3
Process
evaluation
SQA4
Product
evaluation
SQA5
QA Reporting
SQA6
QA report
End of project
7.4 Details of Activities

7.4.1 Setting up QA for the project
SQA1 01: the PM and/or the PQM shall define the product and process quality objectives
for the project, starting with project quality requirements; they define the quantifiable
measurements that allow the attainment of these objectives to be verified.
SQA1 02: the PM and/or the PQM identify the QA activities to be conducted during the
project, the players involved (with delegation mechanisms if applicable), necessary resources,
and expected deliverables; they estimate work amounts and deadlines for these activities.
SQA1 03: the document including all the above components, the "Project Quality Plan"
(PQP), is submitted for review and approved by the projects Steering Committee (CoPil).
SQA1 04: The PQM gives the PQP to the teams.
Inputs
Project quality requirements
Project Quality Plan (PQP)
Project Schedule or Tracking Chart
Standards and procedures that apply to the project
COMPANY/DSI
Status
Draft
Draft
53
Output
Project Schedule or Tracking Chart updated with QA
activities
Mgr. and approval

Mgr: PM or PQM
Approv.: CoPil
Mgr: PQM
Approv.: PM
7.4.2 Specific QA activities

SQA2 01: the PQM implements the activities defined during initialization and whose
purpose is the achievement of quality objectives. In particular, he assists the project team in
properly understanding the expected processes and deliverables, he assists in the
development of certain documents, participates in project tracking meetings and, especially,
contributes to quality updates. He participates in organizing the client audit and internal audits
as a function of requests made.
Inputs
Standards and procedures applicable to the project
Status
Validated
Outputs
Communication or training support materials
Mgr. and approval

Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
Audit reports
7.4.3 Evaluation of processes

SQA3 01: the PQM regularly checks the compliance of project activities as they relate to
applicable processes; verification takes place using checklists that have been adapted to each
process to be evaluated.
SQA3 02: the PQM drafts a report of the review, has it validated by the participants and
distributes it to the stakeholders; non-compliances are listed, corrective actions are taken by
the PM.
SQA3 03: The PQM checks that corrective actions have been taken, and may decide on a
new review to formally ensure project compliance.
Inputs
Project documents from the processes evaluated
List of non-compliances (Checklists filled out during
previous passes)
List of corrective actions in progress (Project tracking
chart)
COMPANY/DSI
Status
Validated
Version from past reviews
54
Outputs
Updated Project Schedule or Tracking Chart
Review report: checklists completed
Updated list of non-compliances
Updated list of corrective actions (Project Tracking
Chart)
Mgr. and approval

Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
7.4.4 Evaluation of products

SQA4 01: The PQM regularly verifies the compliance of the projects products compared to
applicable standards; verification is conducted using checklists adapted to each product being
evaluated
SQA4 02: The PQM drafts a report of the review, has it validated by the participants and
distributes it to the stakeholders; non-compliances are listed, corrective actions are taken by
the PM
SQA4 03: The PQM checks that corrective actions have been taken, and may decide on a
new review to formally ensure project compliance.
Inputs
Products to be evaluated
List of non-compliances
List of corrective actions in progress (Tracking chart)
Status
Validated
Outputs
Updated Project Schedule or Tracking Chart
Mgr. and approval

Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
Review report
Updated list of non-compliances
Updated list of corrective actions

7.4.5 QA Reporting: definition of reporting and escalation rules

SQA5 01: The PQM shall regularly communicate with the project team and the organization
quality manager (OQM) regarding quality actions completed: results from process and product
evaluations, project quality indicators, difficulties encountered, planning for the upcoming
month. Communication to the OQM is formally made during the meeting of the RQP
committee.
SQA5 02: The PQM may, if applicable, initiate the escalation of unresolved problems from
the project to the OQM or any other person in the organization designated for this type of
problem resolution.
SQA5 03: The OQM shall meet regularly with the PQM committee, which shall consist of
the OQM, the QUAL Process Owner and all PQMs designated for the projects in progress.
This committee shall prepare a summary of non-compliances observed in the projects, decide
on actions required to resolve these non-compliances and add that information to the
organizations Quality Tracking Chart.
COMPANY/DSI
55
Inputs
Report on process and product evaluations
List of non-compliances
List of corrective actions in progress
Status
Validated
Validated
Validated
Validated
Outputs
Project quality indicators
Mgr. and approval

Mgr: PQM
Approv.: PM
Mgr: PQM
Approv.: PM
OQM
Reporting support materials

Quality Tracking Chart
7.4.6 QA report
SQA6 01: the PM shall coordinate a project quality report with the teams and the PQM, if
applicable as part of the project report; the quality report is focused on lessons learned,
strengths and weaknesses associated with quality activities and processes.
Inputs
Project quality tracking documents
Status
Validated
Outputs
Project quality report
Mgr. and approval

Mgr: PQM
Approv.: PM
7.5 Reporting
Project quality tracking chart
This tracking chart consists of:
o Records of non-compliances (NC)
o Corrective plans of action for resolution of NCs
o Schedule for auditing processes and deliverables produced
Organization quality tracking chart
This tracking chart contains:
o Names of the project, the PQM and the Project Manager
o Name of the MPP milestone, date it was passed and the PQP version on that date
o Results of process checklists
o Verification that checklists for deliverables produced have been submitted
o Number of NCs in progress and completed.
7.6 Measurements
The measurements tracked in the organization quality tracking chart are:
o Percentages of process and product compliance compared to the checklists.
o Number and status of corrective actions for the project.
A project measurement plan exists that defines all of the measurements to be implemented for the
project.
The list of standard measurements is as follows:
COMPANY/DSI
56
Project objectives
Deadline management
Cost management
Quality management
Adherence to processes
Project Measurements
Date / Date Diagram
S-curve
Diagram of fault management
Results of process checklists
7.7 Definitions of standard project measurements

7.7.1 Date / Date Diagram (45 curve)
Graphic illustration:
Indicateur de jalons
Lancement projet
Jalon 2
Jalon 4
Fin de projet
Jalon 1
Jalon 3
Jalon 5
bissectrice
12-m ars-05
05-fvr-05
01-janv-05
27-nov-04
23-oct-04
18-sept-04
14-aot-04
10-juil-04
05-juin-04
01
/0
5/
20
04
01
/0
6/
20
04
01
/0
7/
20
04
01
/0
8/
20
04
01
/0
9/
20
04
01
/1
0/
20
04
01
/1
1/
20
04
01
/1
2/
20
04
01
/0
1/
20
05
01
/0
2/
20
05
01
/0
3/
20
05
01-m ai-04
Description: Representation of the derivation of the projects primary milestone at a given

frequency.
Data collection:
o Input data: primary milestones taken from MS-Project.
o Who: the Project Manager.
o Frequency: each time the schedule is updated in MS-Project before each COPIL meeting.
o Storage: XLS file along with the Project Steering Sheet.
o Tool: MS-Project Macro.
Measurement analysis:
o Guide: the goal here is to have horizontal curves that cross the bisector. When there is
deviation regarding a milestone, we must verify that this deviation is compatible with the
planned dates for the other milestones. A horizontal curve that starts to follow the
bisector as it approaches the bisector translates into an absence of control of the
milestone.
o When: at COPIL and CODIR meetings.
o How: formalized in the COPIL and CODIR meeting minutes.
COMPANY/DSI
57
7.7.2 S-curve
Indicateur d'effort
2100
Initial (nb
jours)
1800
1500
Ralis (nb
jours)
1200
Re-estim
(nb jours)
900
600
300
8
at
e
9
D
at
e
10
D
at
e
D 11
at
e
12
D
at
e
D 13
at
e
14
D
at
e
15
at
e
D
at
e
D
at
e
D
at
e
D
at
e
D
at
e
D
at
e
D
at
e
Description: comparison of actual workload to planned workload according to the re-estimate.

Data collection:
o Input data: workloads taken from MS-Project: initial, achieved and re-estimated plans.
o Frequency: each time the schedule is updated in MS-Project before each COPIL meeting.
o Storage: XLS file in addition to the Project Steering Sheet.
o Tools: MS-Project Macro.
o Guide: the discrepancy between the actual and the planned must remain under control;
typically, a gap of more than 10% shall be considered significant. The S-curve is a project
management tool and, especially, a project tracking tool. The idea is to graphically
represent the progress status of the project. An S-shaped curve is used here because, in
general, the project follows this S-shape with a gradual startup, followed by acceleration,
then finally by deceleration when the project reaches completion. This curve is drawn
during the pre-project phase, resulting in a preliminary project progress curve to which
we can refer over time as the project progresses in order to identify any possible delays
and thus manage any possible deviations. The more the second curve, which represents
the actual progress of the project, is shifted to the right, the more delayed the project is.
o When: COPIL and CODIR meetings.
COMPANY/DSI
58
7.7.3 Diagram of fault management
Number of serious and critical faults

12
10
8
Nbre total d'anomalies
Nbre d'anomalies rsolues
4
2
0
Mar- Apr- M Jun- Jul- A
S Oct- N
D Jan- Feb05 05 ay- 05 05 ug- ep- 05 ov- ec- 06 06
05
05 05
05 05
Number of major faults

120
100
80
Nbre total d'anomalies
60
Nbre d'anomalies rsolues
40
20
0
M Apr- M Jun- Jul- A
S Oct- N
D Jan- F
ar- 05 ay- 05 05 ug- ep- 05 ov- ec- 06 eb05
05
05 05
05 05
06
Description: Number of serious and critical faults, both major and minor, found and then
resolved over a sliding period.
Data collection:
o Input data: total number of faults, number of faults resolved by criticity.
o Who: CRML.
o Frequency: before each COPIL meeting.
o Storage: XLS file in addition to the Project Steering Sheet.
o Tool: JIRA requests.
o Guide: the number of unresolved faults must remain under control (gap between the 2
curves) as must the total number of faults (slope of the curve).
o When: in COPIL and CODIR meetings.
COMPANY/DSI
59
7.7.4 Adherence to processes
CHANGE - Gestion du
Changement
1
0.8
0.6
REQM-Gestion des
Exigences
0.4
0.2
CONF-Gestion de
Configuration
QUAL-Management de la
Qualit
MPP-Management Par
Projets
Description: for each process, percentage of adherence by the project.

Data collection:
o Input data: result of process checklists.
o Who: PQM.
o Frequency: to be defined in the project quality plan.
o Storage: XLS file Process Adherence Radar in addition to the project Steering
sheet.
o Tools: process checklists.
o Guide: analyze discrepancies identified, tending towards 100% for each process.
o Who: The PQM and the Project Manager.
o When: after the process checklists have been concluded.
o How: non-compliances formalized in the Aqualogic discussions.
COMPANY/DSI
60
8 ENGINEERING AND SUPPORT PROCESSES

8.1 Requirement Management Process
8.1.1 Presentation of the process
BSR
INIT
FSR
EVAL
DFR
SPEC
RLR
REAL
Divers Expr. of need

MKT
Opportunity study
CdCF (1)
CdCF author (RCC)
CdCF (2)
Top level
spec.(DSL)
RFS author (RSP)
Detailed spec.(DSL)
Acceptance designer(CREC)
Test plan/scenarios (REC)
Development designer(CDEV)
Software design doc (CLOG)

Functional traceability matrix(MTF)
All
General project glossary (GGP)
CdCF
GGP
CdCF
GGP
CdCF
DSL
DSL
DSL
MTF
MTF
MTF
GGP
GGP
GGP
MTF
The documents in dotted lines correspond to intermediate or working versions. For example, the BSR
is passed with requestors functional specifications that have only recently begun to be written.
During the initialization phase, statement-of-need documents must be assembled. An opportunity
study document must be written by the requestor (marketing).
During the first four phases of the cycle, the following deliverables are developed and maintained by
various participants:
o Requestors functional specifications (RFS)
o Functional specification (including the Story Board)
"General" version
"Detailed" version
o Test plan and scenarios
o Functional traceability matrix (FTM)
Throughout the middle phases (EVAL, SPEC), new technical terms will be added to the projects
general glossary.
8.1.2 Roles
The following roles have been created for the requirements of this process:
COMPANY/DSI
61
Role
Definition
Author of
Requestors
Specifications (ARS)
Author of Functional
Specification (AFS)
Acceptance Designer
(ACCD)
Development
Designer(DEVD)
Ergonomics
Project Owners employee, writes the requestors functional specifications

Writes the specification document using the requestors functional specifications
Writes the test plan and scenarios using the specification document
Writes the software design document using the specification document
In general, ergonomics is the science devoted to the search for better adaptation
between a function, a piece of equipment and its user. In software applications, the
purpose of ergonomics is to ensure that what appears on the screen, through the
graphic interface, is comprehensible and even pleasant for the user. This is why we
refer to a user-friendly interface. Ergonomics participates in defining the applications
specifications, assembling preliminary models and developing interactive scenarios,
establishing target groups and defining criteria adapted to the type of application and
to the physical environment. It generates evaluation grids for the technicians assigned
to tests and validations, and tracks problems and corrections through the quality
manager.
8.1.3 "Initialization" phase

8.1.3.1 Summary of requirements
At the start of the "Initialization" phase, the client or his representative (hereinafter referred to as the
"client") has produced an expression of need, described in a set of documents. The manner in which
the need was reported and the expression-of-need documents were formalized does not enter into the
scope of requirement management as implemented by the DSI in the COMPANY group: in general it is
not possible to constrain the client to our methodology.
These documents originate from various sources, as indicated in the following diagram:
Subsidiaries
Laws/good practices
marketing
General/DSI
management
Customers
Communication of need
Other sources
This notification of need may be received by means of the change management tool (change
requests, reports of bugs).
These documents must be considered working documents that serve as an entry point for defining the
project. They are one of the sources used in writing the requestors functional specifications (RFS). In
all cases, the RFS must without fail refer to these documents, which constitute the proofs of the
original request. This reference is the first traceability element established in the project.
8.1.3.2 Agreement on expression of need

The expression of need is reviewed by the participants designated by the Project Manager or by the
person who is assumed at this time to be the Project Manager.
Reading of the expressions of need is formalized by each reader preparing a reading sheet. These
reading sheets are stored in COMPANYs portal in the directory where the documents are located.
These reading sheets (as well as the reading process) are the sole components that provide proof of
agreement between the author of the expression of need and its recipients.
COMPANY/DSI
62
8.1.4 "Evaluation" Phase

The "Evaluation" phase starts as soon as the BSR milestone has been reached.
8.1.4.1 Requestors functional specifications

During the Evaluation phase, one or more Requestors Functional Specifications (RFS) are produced
for the project: if the project involves several distinct functions, a RFS could be written for each
function, at the discretion of the Project Manager.
If the project (or part thereof) should involve an existing functionality of the product, and a RFS
already exists, that RFS shall be taken for the project (or part thereof) and modified during this phase.
If no RFS exists for the project (new project or previous documentation non-existent), a new RFS shall
be created.
A RFS shall be developed or modified by the Author of the Requestors Specifications (ARS) assigned
to the project or to the function based on the expression-of need documents indicated above. The
development of a RFS constitutes a primary phase of client need analysis. Consequently, the ARS
must be able to communicate as often as he desires (in person, by telephone, etc.) with the client
and/or future users and/or their representatives in order to clarify the need. These interviews may be
reported in the form of minutes, whose formalization shall be at the discretion of the ARS or the PM.
Control checkpoint: The RFS is clearly broken down into two distinct parts: the presentation of the
project and the functional statement of need. When the ARS is almost finished writing the first part
(presentation of the project), the various participants may consult with each other in order to reach a
preliminary agreement about the contents of the document. This phase does not correspond to an
official milestone, but may be considered an intermediate milestone during the Evaluation phase.
This control checkpoint is optional.
The PM may, on a case-by-case basis, set up measures that are more constraining than those defined
in this document. The requirement management process imposes nothing regarding the way in which
all of the information that the ARS deems necessary for the development of his RFS is collected. For
example, the Project Manager or the ARS may request that their contacts validate the meeting
minutes sent to them, although this validation is not required here.
All documents that provide evidence of meetings between the various contacts during the RFS writing
phase, with the goal of clarifying the need, may be cited as references in the corresponding RFS.
8.1.4.2 Glossary
The author of the RFS shall make reference, in the general project glossary (separate document), to
the elements recorded in the glossary and included in his RFS. If conflicts exist on the subject of the
glossary between two ARSs, they shall reach an agreement by consulting the appropriate participants
if necessary.
Industry-specific terms defined in the glossary must be those used by future users of the product.
8.1.4.3 Agreement on the RFS

When the ARS decides that the RFS has reached a sufficient level of quality (he may use the
deliverable verification checklist to make this decision), he shall publish his document through the
COMPANY portal. At the same time, he shall organize the documents review by a group of readers
selected by the PM, which must include at least the PM and the author of the Functional Specification
(AFS).
The tasks related to reviewing the RFSs may be assigned, from a planning point of view, to the lines
of planning that correspond to the RFS. Specifically, if the AFS shall draft the start of the general
COMPANY/DSI
63
specification to validate the content of the RFS, this task must be invoiced to the EVAL phase and not
to the SPEC phase.
8.1.4.4 General specification for clarifying and validating the RFS

Control checkpoint: As indicated above, at the end of the "Evaluation" phase, when the development
of the RFS is nearing completion (the ARS, project owners PM and client are in agreement about its
content and consider it to be exhaustive), the ARS shall approach the author of the Functional
Specification (AFS) designated to draft the functional specification document. The AFS shall then begin
his analysis of the RFS as soon as possible (general specification phase). This handover allows the AFS
to check the quality of the RFS and, if applicable, request additional information from the ARS before
the FSR milestone is passed. The AFS is based primarily on the user case diagrams which he writes in
the general specification to verify the completeness of the need expressed.
It is important for the RFS and the functional specification document to be written by two different
people. If the two documents are written within the same organization, the temptation will be great to
have both of these documents developed by the same author. This practice does not guarantee good
quality of the RFS, which should allow any reader to handle the entire project without any additional
information. The contents of the RFS must be minutely and systematically detailed.
However, it shall be the responsibility of the Project Manager to designate the managers for the
various deliverables. There are some cases (very small projects) where just one author is sufficient for
both of these deliverables.
The RFS is part of the deliverables required for achievement of the FSR milestone. This milestone
constitutes, except for a few exceptions, a point of no return in the project: the scope of the project is
fixed starting from the moment this milestone is reached. It cannot therefore be reached without
everyone agreeing on the requirements defined in the RFS. Once the FSR milestone has been
reached, the RFS cannot be modified except under the conditions defined in the Management of
Faults & Developments section.
8.1.4.5 Functional traceability matrix (Phase 1)

As soon as the general specification is completed, the ARS initializes the functional traceability matrix
of the project or of the WP in a separate document.
All of the functions indicated in the RFS must be placed in the first three columns of the chart:
o Function code
o Function reference (reference of the request if it exists, N/A if not)
o Explanation of the function
The following column (status) indicates whether the function has already been implemented as part of
another project or must be implemented during the course of this project. If a traceability matrix
already exists for the project, it must be modified as follows:
o Add additional functions and mark them to be implemented (TBI)
o Mark existing, non-modified functions as "already implemented" (AI) and add the version
involved
o Mark existing modified functions as to be implemented (TBI)
o Mark functions that must not be implemented as "not implemented" (NI), with an explanatory
comment in a fifth comments column.
In the opposite case (new requestor specifications), all the functions must be marked as to be
implemented (TBI).
For example:
Function Ref Description of function
Stat Comments
F12
F13
TBI
DI
COMPANY/DSI
N/A Invite participants

N/A Invite health professionals
V7.2
64
Function Ref Description of function
Stat Comments
F14
TBI
F15
N/A Invite individuals not in the health

professions
N/A Modify the status of the invitation
NI
Declared non-priority by MOA on

7/7/2003
8.1.5 "Specification phase

The "Specification" phase shall begin as soon as the FSR milestone has been reached.
8.1.5.1 General Specification

The General Specification constitutes the first part of the functional specification document. At the
beginning of the "Specification" phase, work on writing it has already been begun, by the AFS in close
collaboration with the ARS, before the FSR milestone has been passed, in order to assure good quality
of the RFS. At this stage, functional additions to the RFS can no longer be allowed. It can no longer be
modified except by applying the rules defined by the management of faults & developments working
group.
In all cases, the PM or, if there is none, the WPM responsible for this document, shall be the sole
judges.
The General Specification consists, starting from only the components present in the requestors
specifications, of identifying the players, principal use cases, and data manipulated within the system
and defining the list of screens, without detailing them, by indicating the interactions between them.
Control checkpoint: As soon as he considers the General Specification to be sufficiently stable, the AFS
shall contact the Work Package Manager (WPM) who is responsible for project development or
functionality and the ARS who wrote the RFS. These three participants, after they have familiarized
themselves with the General Specification document, must reach an agreement about the contents of
the document (operating scope, precision, organization, comprehension, etc.). The AFS shall modify it
if a satisfactory consensus cannot be reached. This phase does not correspond to an official
milestone, but may be considered an intermediate milestone in the Specification phase.
8.1.5.2 Glossary
The AFS makes reference, in the general project glossary (separate document), to the elements
included in the glossary and integrated into his specification document. In the case where conflicts
exist on the subject of the glossary between two functional analysts, these analysts shall reach an
agreement by consulting the appropriate participants if necessary.
8.1.5.3 Functional traceability matrix (phase 2)

When the general specification is completed, the AFS shall initiate the second point of the functional
traceabiity matrix for the project or WP.
All functions from the first point (see [sic]) marked "to be implemented" must be placed beforehand in
the first column of the chart (the function code is indicated).
In the two following columns, the author enters the use case references and their explanations. For
each function stated in the RFS, the author of the functional specification shall indicate:
o If the function is referred to in at least one use case, the identifier and explanation for each
use case that refers to the function.
o If the function does not correspond to any use case, the author shall indicate N/A in both
columns (this case is probably an abnormal one)
For example:
Function UC
F12
F13
COMPANY/DSI
UC description
UC23 Invite
UC41 Invite health professionals
65
In the third column, the author enters the references to the entities identified. Every requirement that
names an object manipulated by the user or the system must be connected to the corresponding
entity:
o If the function names at least one entity, the names of the named entities shall be indicated.
o If the function does not name any entity, the author shall indicate N/A.
For example:
Function UC
F12
F13
UC description
Entity
UC23 Invite
Order
UC41 Invite health professionals N/A
The functional traceability matrix shall accompany the project throughout its life until the last
milestone. New components will be added to it at each step of the project.
8.1.5.4 Detailed specification

When the general specification has been completed (it satisfies all interested parties), the AFS moves
on to the detailed specification phase.
The detailed specification phase consists of:
o Clarifying the use cases
o Writing the product story-board
o Documenting the story-board
Clarifying the use cases (detailed use cases) is a task that leads to the description of the graphic
interface for the application: a detailed use case states primarily the situation in which the user must
be in order to enter the use case. The ergonomic choices should have been settled at the time the use
cases were clarified.
In parallel, the ergonomist shall write the story-board for the project or function. This story-board may
be included in the specification document or may be the subject of a separate document. By
convention, and even if a separate document is involved, we must consider the story-board to be part
of the specification document.
Control checkpoint: As soon as the AFS considers his work to be sufficiently advanced, he shall so
notify the following participants:
o The ARS, who must give his agreement on the contents of the document
o The Acceptance Designer in charge of writing the test plan and the scenarios
o The Work Package Manager in charge of project or WP execution.
The specification document shall not be completed until all of its participants (the client or those who
must work on the basis of this document) are in agreement about the documents quality.
8.1.5.5 Functional traceability matrix (phase 3)

When the specification document has been completed, and before the DFR milestone has been
passed, the AFS shall complete the functional traceability matrix by indicating the association between
a function code and the screen code that will represent it.
Function CU
CU Description
Entity
F12
F13
UC23
UC41
Invite
Invite health professionals
Invitation E03
N/A
E12
F15
F16
F23
UC34
UC35
N/A
Modify participation information

Modify participation information
N/A
Invitation E17
Invitation E17
Invitation E17
F14
COMPANY/DSI
Not implemented declared non priority by MOA on 7/7/2003 N/I
MMI
N/I
66
Remark: some constraint functions may express ergonomic constraints that have no relation to a use
case, but rather to one or more MMIs.
8.1.5.6 Agreement on the specification

When the AFS decides that the functional specification has reached a sufficient quality (he may use
the deliverable verification checklist to make this decision), he shall publish his document through the
COMPANY portal. At the same time, he organizes a review of the document with a group of readers
selected by the PM who must include at least the PM, the Acceptance Designer (ACCD) and the
Development Designer (DEVD).
The work involved in reviewing the functional specification can be assigned, from the planning point
of view, to the planning lines that correspond to the functional specification. Specifically, if the ACCD
drafts the start of the test plan to validate the content of the functional specification; this work should
be invoiced to the SPEC phase and not to the EXEC phase.
8.1.5.7 Test plan

Based on the detailed specification document, the Acceptance Designer shall develop a test plan,
which describes the test strategy deployed for the project, and the documents that will be used for
product validation (test scenarios). At least one test sheet shall be produced for testing a function.
The level of granularity for what is called a "function" is the use case; a test sheet allows one use case
or a group of them to be tested (just one scenario is tested at a time).
These documents are organized as follows:
A heading that describes the functionality being tested

Operating module1
Sub-module2
Identification of the use case(s) being referenced
Identification of the test sheet
Test sheet title
Number
Version
Drafted by/validated by
Conditions allowing the test to be performed
Path allowing the function to be accessed in the application
Version / Release of the application
Information on the platform used
A list of steps to be completed for the execution of the test, with, for each step:
Sequencing for the step in question
Results expected
An zone for entering the results obtained at the time of the test
Comments
A chart that allows the test result to be recorded:
Identification of the tester
Test date
Identification of the user on which the test was performed
Test results (Valid / Not valid)
An area for entering a comment
An area for indicating approval (date and manager)
Designates a product function, for example: agenda, costs, report entry, etc.
Designates a part of a functional module such as, for example, for the agenda: making
appointments, Outlook synchronization, etc.
2
COMPANY/DSI
67
8.1.6 "Execution" phase

The "Execution" phase starts after the DFR milestone has been reached. It includes designing and
coding.
At the time this phase begins, the functional specification is completed and stable. It can no longer be
modified except by applying the rules defined by the management of faults & developments working
group.
8.1.6.1 Function design and traceability matrix

The designers work primarily from various UML diagrams included in the functional specification.
These diagrams are fine-tuned and software items are created:
o Tables in the data models
o Functions or classes of access to the database (DAO)
o Functions or classes for technical services
o Functions or classes for application services
o User interfaces
Traceability must be assured between use cases, classes in the class diagram, MMIs and the software
items indicated above.
8.1.6.2 Test plan and functional traceability matrix

Writing the test plan shall be completed during the Execution phase. Each test is identified.
A specific functional traceability matrix makes it possible to indicate the correspondence between a
use case and the various test scenarios in the test plan to which they are connected (there are several
test scenarios for a given use case).
8.2 Configuration Management Process

8.2.1 Description of the process
The configuration of a project is the total of all components that constitute the project at any given
time.
Any change made to one or more components constituting this configuration generates a new status
for this configuration.
Configuration management is all of the activities used to manage the various statuses of a projects
configuration.
The goal of configuration management is therefore to establish and maintain the integrity of the
deliverables.
Configuration management involves:
Identifying the components constituting the configuration.
Monitoring changes to the configuration
Recording successive statuses of the configuration
Performing inspections and audits of the configuration.
Without configuration management:
Developments take place on incompatible interface versions (for example, applications are
developed using the wrong version of the databases, etc.)
Since the impact of a change is not monitored, all of the necessary components are not
corrected
The product constructed is incomplete or does not contain what was planned.
Construction is not reproducible.
Correction of a previous release is impossible.
COMPANY/DSI
68
Since the product tested is not the one delivered, bugs are discovered when the product is
installed at the clients facility
etc.
8.2.2 Configuration component

A configuration component is an item or group of items managed as a single entity by configuration
management.
All of these components taken together constitute the configuration.
The configuration therefore consists of:
o Source components. These are original components, written by the participants:
Word-processed documents
Application and packaging source codes
Images
etc.
o Constructed components. These are components generated from source components:
Compiled executables
Installation programs
ISO images for the installation CD
Program libraries (API)
etc.
o Tools:
Compilers
Editors (Word, Excel, PowerAMC, Eclipse, VisualStudio, etc.),
Configuration management tools (SVN, CVS, VisualSourceSafe, AQUALOGIC,
etc.)
etc.
According to the configuration management system in place, a configuration component may be:
o A portion of a software file (a function, a requirement in a requirement management tool,
etc.)
o A software file (a Word document, a source code file)
o A group of files (all source code files leading to the creation of a DLL, etc.)
Each configuration component must possess its own identification, allowing it to be distinguished from
other components.
8.2.3 Configuration management spaces

Two broad categories of configuration management space:
o The workspace, in which components are edited
o The reference space, in which components are stored.
The configuration management system (CMS) is the link between all of these spaces.
COMPANY/DSI
69
Work space
Storage space
branches
Execution space
Acceptance space
baselines
Code storage spaces
Tool storage spaces
Pre-production space
Construction space
Constructed component
storage spaces
Integration space
Production space
Espace de rfrence des sources
8.2.3.1 Policy for accessing configuration management spaces

The default policy for accessing configuration components at COMPANY is as follows:
o No access to unauthenticated persons
o Read-only access to all projects for all authenticated persons
o Read/write access to all configuration components of a project for all its members (at the
branch level and not the baseline level)
A project may decide to restrict access:
o globally (restricted-access project)
o to a group of components (restriction of access and/or editing rights to a directory)
o to one specific component.
In all cases, these restrictions must be indicated in the Configuration Management Plan CMPL (overall
rule for a type of component) or in the PBS (rule that is specific to one component).
8.2.3.2 Workspace
The workspace may be divided into several sub-spaces with different functions:
Execution space
COMPANY/DSI
This is the space in which the source configuration components are

created and modified. Once completed, they can be delivered to the
70
source component storage space.

This space is associated with a development branch.
Construction space
Integration space
The execution space consists of all the workstations for the participants
in the project.
Note: When the participants are developers, this space is also called the
development space.
This is the space in which the source configuration components are
gathered to make the constructed configuration components (also
called products or artifacts). Once they have been assembled, these
components are delivered to the constructed component storage space.
This space must allow for the construction of sources that come from
development branches and baselines.
This is the space where the constructed configuration components are
gathered to perform the product integration tests. These are the tests
that verify that all constructed components are functioning correctly
with each other in a complete environment.
Load and performance testing may be performed in this space.
Acceptance
(validation) space
Pre-production space
Production space
These tests may be conducted on products that have been constructed

on branches (products not clearly identified because they are
upgradeable) or on baselines (products fixed and clearly identified).
This is the space where tests are performed that allow the project
owner to validate the product.
Acceptance tests shall always be performed on a product constructed
from a baseline (pre-release, or release).
This is a space used for the first implementations, which allows a real
environment to be reproduced (client-specific, etc.). Once the
implementation has been validated, it is applied in the production
space.
In the pre-production space, only products constructed from baselines
(pre-release, or release) shall be installed.
Real functioning space of the application.
In the production space, only products constructed baselines (release)
are installed.
8.2.3.3 Reference space

The reference space may be divided into several spaces, each having different functions and designed
to store different components:
o Source components
o Constructed components
o Tools
8.2.3.3.1 Source component storage space

This space is used to store source configuration components. It consists of branches and baselines.
8.2.3.3.1.1 Development branches

A branch is a storage space, for all of the participants in the project team, to which the modifications
made in the workspaces are sent. A branch is therefore a shared dynamic space (it evolves over
time).
COMPANY/DSI
71
Note: For example, night construction takes place on the contents of the branches (continuous
integration process).
Also, a branch is a hermetic space for configuration management. Therefore, by creating multiple
branches, we obtain several hermetic spaces in which components may evolve independently. The
same element therefore can have divergent development branches.
This diagram shows 4 branches:

o The original (or primary)
o Branches "1" and "2" taken from the primary
o Branch "3" taken from branch "1"
Finally, we therefore have 4 divergent evolutions for the same component.
Branches thus allow for the simultaneous development of corrective and upgradeable versions of a
product.
Finally, the branches must be clearly identified:
o To differentiate them from each other.
o To logically reach the identification of baselines emanating from these branches.
Note: Since the branches are hermetic spaces, modification of a configuration component on a branch
does not cause the modification of this element on the other branches. Transfer operations may prove
necessary (for example, to correct bugs). The creation of a new branch (and maintenance of old
ones) must therefore be monitored.
8.2.3.3.1.2 Baselines
Since branches are dynamic spaces, we cannot use them as a base for representing a stable
reference. Therefore we create "photos" of these branches (or of a part of the content of these
branches) which are stored in fixed spaces: these are the baselines. A baseline is therefore a static
space.
By assigning a unique identifier (name + number) to each baseline, we formalize a configuration
status (i.e., a component or group of components taken in very precise and immutable revisions).
The list of components included in the baseline will give a precise direction to this baseline. For
example, a java source file baseline will represent the code of a component or of a java application.
Since the official distribution of a configuration component (or group of components) must be based
on a stable and clearly identified content, it cannot take place except on the contents of a baseline.
Consequently, spaces for acceptance, pre-production and production must use only products based on
baselines.
Note: The tag concept is very widespread in configuration management systems. A tag is a label
placed on a component revision in order to differentiate this revision from others. Placing the same
tag on various components makes it possible to define a baseline.
COMPANY/DSI
72
8.2.3.3.2 Constructed element storage space

This space is for storing configuration components constructed from source components.
8.2.3.3.3 Tool storage space

This space is for storing all internal or external tools used by the project.
8.2.4 Configuration management levels

Depending on the nature and "criticity" of the configuration components, a more or less rigorous
management program is required.
For example, management associated with the requestors specifications must be much more rigorous
than that applied to the minutes of the progress meeting. In fact, not agreeing on the same revision
of this specification has much more impact on the project. Likewise, modifying this specification
without notifying all the participants will not have the same consequences.
This is why we define levels of configuration management.
These levels are incremental: each level respects the preceding level. There are 5 levels, from the
simplest to the most rigorous:
o Archiving: assures that components will be saved. This is the simplest level.
o Historical: assures that all revisions of components will be stored.
o Identification: components are part of a clearly defined set
o Version: components have their own version.
o Validation: the components follow a validation process. This is the highest level.
A very specific level is associated with a configuration component, so that all the participants in the
project know how to manage (modify, distribute, etc.) all the components.
8.2.4.1 "Archiving" level

An "archived" configuration component is:
o Clearly identified and localized
o Saved
o Only one revision of this file is retained: the last one.
Example:
The configuration file for the trace level of an application that rotates in the integration space:
depending on requirements, this file may be changed (to increase or decrease the trace level).
It is not necessary to know the contents of the preceding revision (what is important is the
current content!).
8.2.4.2 "History" level

A "historized" configuration component is an "archived" component whose various revisions are:
o archived
o documented:
traced (who is responsible for this modification)
dated (date this modification was made)
commented (why was this modification made), and
possibly, it refers to a change request.
The last "revision" is the only active revision. The others are saved only for information purposes.
A CMS that applies the "historic" level of configuration management must support:
Modification of a components content
Modification of a components identifier (name change)
COMPANY/DSI
73
Modification of a components location (movement)

Deletion of a component
Access to any revision of a component
Viewing of information regarding a revision
Note: The interest in the history is to facilitate the understanding and if necessary the cancellation of
modifications. This is why it is important (but not mandatory) to create a new revision for each
modification, and not to combine several modifications into a single revision.
Example:
o A model of a tool configuration file: it may be necessary to track the development of this file,
in order to relate the modifications to the existing situation.
o The CVS HEAD or SVN trunk development spaces correspond to this level of management
(the target version is not clearly identified).
8.2.4.3 "Identification" level

An "identified" configuration component is a "historized" component that is part of a clearly defined
set (Branch or Baseline).
The change management process may be applied to configuration components, managed at this level,
that have already been part of a baseline.
Example:
o The source code for an application: any modification of the code must be monitored, and it is
the entire code, not just one file, that represents the version
o A specific branch in CVS or SVN corresponds to this level of management.
8.2.4.4 "Version" level

A "versioned" configuration component is a component that is part of an "identified" set that has a
version specific to the level of its identification and/or its content. Once production of the component
is complete, it is locked. Any subsequent modification shall take place on a new configuration
component with its own version.
Only a "versioned" component may be officially distributed, since it is only at this level of configuration
management that a component remains clearly identifiable outside of its context.
A mechanism must permit a completed component (final revision of this component in this version) to
be differentiated from a component that is in the process of execution.
The change management process must be applied to the components managed at this level.
Examples:
o A designing document
o A component (DLL, JAR, etc.) that is not subject to specific acceptance testing
COMPANY/DSI
74
8.2.4.5 "Validation" level

A "validated" configuration component is a "versioned" component that has undergone a validation
process. Only a "versioned" and locked component may begin the validation process. Only one
validated version of this component can be officially distributed.
One mechanism should be enough to make the difference between a versioned component (which
may or may not be in the process of being validated) and a validated component.
Examples:
o The requestors specifications: validation is very important because it is contractual.
o The products executable: its execution phase is very short (compilation step) whereas its
validation phase is very long (acceptance).
8.2.5 Teamwork
The various workspaces, storage spaces and the CMS set up should allow for teamwork.
There are two operating modes:
o Lock Modify Deliver
o Modify Merge Deliver
8.2.5.1 Lock Modify - Deliver

In this
o
o
o
operating mode, the operator:

Locks a configuration component in the CMS (no one else can modify it)
Modifies the component in his own work space
Delivers (and unlocks) the component to the storage space
This operating mode has the advantage of being simple because by preventing concurrent work on
the same component, it excludes merge operations.
8.2.5.2 Modify Merge Deliver

In this operating mode, the operator:
o Modifies a component in his own work space
o Merges his component with the stored component (locally transfers all modifications that may
have been in the storage space)
o Delivers the component to the storage space
This operating mode has the drawback of being more complex (modification merge phase), but has
the advantage of allowing concurrent modifications on the same component.
Note: this operating mode is disabled when the configuration components are binary files (and no
merge tool exists)
8.2.6 Software products

8.2.6.1 Definition of content
Any deliverable release (being accepted or delivered to a client) must be fixed, clearly identified, and
its content checked (the implemented requirements are known). Such a release must therefore be
taken from a baseline and not a branch.
"Release" baselines are specific baselines: these are baselines that define a product. Therefore they
generally combine baselines of the lowest level:
o component baselines (internal or external to the project and/or COMPANY),
o document baselines,
COMPANY/DSI
75
o
o
packaging baselines (installers)

etc.
These baselines must therefore clearly identify the sub-baselines that compose them: this is the
product matrix.
This matrix must also define the type of product dependency as it relates to sub-baselines:
o Construction dependency: this component is required during the construction phase.
Example: a compiler, a unit test API, etc.
o Execution dependency: this component is required when the product is executed:
Integrated execution dependency: this dependency is integrated into the
product, so it is always available. In this case, it involves a well-controlled
version of this component.
Ex: a Framework API, an external API, etc.
Execution dependency supplied: this dependency must be available in
the integration, pre-production acceptance and production spaces in request
for the product to function. If this is the case, the components version is not
necessarily controlled: we can define a range of compatibility, i.e., a group of
versions with which the product will function.
Example: the database engine (Oracle, etc.), an application server, a
database on which the application operates, etc.
8.2.6.2 Construction
Some project deliverables are obtained from source configuration components in a construction
phase. This construction phase must therefore be reproducible.
It must:
o Manage the construction tools as a configuration:
Compiler
Construction coordinator (MAKE, ANT, MAVEN, or similar type)
Packager (RPM, InstallShield, etc.)
o Manage the construction environment as a configuration
o Describe the various steps in this construction (starting from a development branch or a
baseline) and how to initiate them.
8.2.6.3 Identifying releases

Since products and components are changed, it is essential that they be clearly identified and
therefore that their versions be clearly identified as well. Consequently the CMPL must indicate the
policy to be followed. In general, the identifier (the products "release number") is generated
according to the following concepts:
8.2.6.3.1 Upgradeable releases

The purpose of an upgradeable release is to improve the functions and quality of the product.
There are two types of upgradeable product releases:
o The "major releases," involving major functional upgrades of the product.
o The "minor releases," involving minor functional upgrades of the product.
The upgradeable release number is generally obtained through a consensus between the PM, the
project owner, and the marketing and/or commercial teams. In all cases, this version number must
allow the user to distinguish the type of upgradeable release, and to respect the compatibility rules.
An upgradeable release is developed in its own development branch so as to allow the development of
corrective releases for old upgradeable releases.
8.2.6.3.2 Corrective releases
COMPANY/DSI
76
The purpose of a corrective release is to improve product quality.

A corrective release contains only corrections and no improvements. In fact, an upgrade is likely to
introduce new bugs, so it is more difficult to stabilize the quality of a product if improvements are
introduced. Finally, since it has a narrower spectrum than an upgradeable release, a corrective release
can be developed faster. Responsiveness to client correction requests is therefore better.
A corrective release must respect the compatibility definitions.
A project may result in the decision not to create a corrective release, but must then manage two
additional risks:
o one regarding stabilization of the quality of deliverables, and
o the other regarding responsiveness to client correction requests.
Note: not creating a corrective release does not mean that bugs will not be corrected; it means they
will be corrected in the next upgradeable release.
Corrective releases originating from the same upgrade release shall be successively developed on the
branch of the upgradeable release. This will allow "de facto" accumulation of all previous corrections,
without manual carryover.
Tip:
In request to be sure that corrections are carried over between corrective and upgradeable releases
and to avoid regressions, it is preferable that the upgradeable release be corrected during
development first (if the defect still exists) and the correction carried over in the expected corrective
releases (by making the necessary adaptation if applicable).
8.2.6.3.3 Management of Emergency Bug Fixes (EBF)

The production rate for corrective releases does not necessarily allow a solution to be applied to a
defect as quickly as it needs to be. In effect, correcting several bugs requires more development and
testing time than correcting a single bug. If need be, it is therefore possible to create an Emergency
Bug Fix (EBF) which is a corrective release dedicated to the correction of a single serious bug.
An EBF must remain only a temporary response supplied in an emergency. Its distribution must
therefore be as limited as possible, and stopped as soon as the corrective release is issued.
An EBF is constructed in its own branch taken from the baseline of the release to be corrected. The
bugs identifier is used to identify this new branch and the new release.
If several serious bugs are detected, it is strongly recommended that development of a corrective
release be accelerated (by decreasing its correction spectrum), rather than issuing multiple EBFs or
incremental EBFs (where the EBF accumulates the corrections).
In all cases, the corrections are carried over to the following corrective release and to any releases
under development.
8.2.6.3.4 Managing pre-releases and releases

For products subject to a validation process (acceptance), the concept of the pre-release version is
introduced in request to identify and manage all of the releases provided for acceptance. This concept
allows intermediate deliveries to be made that are official, but not public. It is very important that a
releases identifier clearly indicate whether it is a pre-release (non-validated version) or a release
(validated version). This specific identification takes the form of an additional index which is removed
to designate the release.
Once a pre-release has been validated:
o It serves as a direct base (not a product modification) for the creation of the official release.
COMPANY/DSI
77
No other pre-release version may be constructed. If corrections are necessary, a new

corrective release must be issued.
There are several distinct pre-release levels:

o Alpha: This is a version with no release date yet, functionally incomplete and of unpredictable
quality. This version is usually constructed for demonstration purposes. All it does is show
development progress.
Note: After an alpha version has been created, development continues normally, i.e.,
systematic change management is not mandatory: modifications can be made without making
reference to a change request.
o Beta: This is a schedulable release (which therefore has a release date, even if it appears in
the form of a milestone), that corresponds to a work package. As such, it is considered
functionally complete, although its functional spectrum is restricted relative to that of the
project.
Note: here again, systematic change management is not mandatory, but it is strongly
recommended, at least for all the content (work package) that has already been developed.
o Release Candidate: This is a schedulable release, functionally complete, whose quality is not
yet satisfactory.
Note: Once the first "release candidate" has been constructed, systematic change
management must be terminated in request to guarantee improvement in quality.
8.2.6.3.5 Management of compatibility with external software

An external system or software package name may be added to the identifier of a release in request
to indicate exclusive compatibility.
For example: 1.2.3 linux Redhat 4.0, 1.2.3 Oracle 10i, etc.
8.2.6.4 A specific product: "packaging"

Packaging (an installation product) installs another product. Its identification must therefore reflect
that of the product installed (name and release).
A packaging product may also include errors, so it is important to be able to correct it.
This is why a packaging release consists of:
o The product release
o A release that is specific to the packaging
For example, the release number 1.5.3-1 is for the first packaging software for a product in release
1.5.3. A corrective packaging release (same installed product) will then be numbered: 1.5.3-2.
8.2.7 Management of compatibility between elements

A revision of a component is incompatible with a previous revision when it causes a malfunction of
other components (problem with construction or execution).
In practice, incompatibility of an internal component in a product does not pose a problem, because
the products other components can be adapted (see change management). On the other hand, this is
no longer the case if the incompatible component is part of the product interface, because the
products environment cannot always be controlled.
Incompatibility is therefore understood to designate only interface incompatibility.
Examples:
COMPANY/DSI
78
o
o
o
For an API type of component, this may involve modifying a function: changing its name,
changing the number or type of its arguments, etc.
For a database type of component, this may involve a change to a table: changing the name
of a column, adding a new constraint, etc.
etc.
The following rules are defined:

o For a major upgradeable release, compatibility is not necessarily respected.
o For a minor upgradeable version, incremental compatibility is respected (for example, a
function is added in an API interface, a cancelable column is added to s database, etc.).
o A corrective release guarantees complete interface compatibility (an API interface does not
change, no diagram upgrade, etc.).
An exception to the compatibility rule is possible in the case where correction of a bug is
inevitably accompanied by incompatibility with the previous version. In this case, an impact analysis
must be performed, and agreement by all stakeholders is required (actions are the responsibility of
the PM). If approval cannot be obtained (or if it is impossible to convince the stakeholders), the
correction is made in the next major release. If approval is obtained, it is integrated into the next
corrective or minor release.
8.3 The Change Management Process

8.3.1 Description of the process
This process is based on various cycles defined by a succession of request statuses.
Depending on the organization in place for Change Request Management, several cycles can be
considered depending on the criticity of the request and/or the type of request. These cycles
meet the requirements for management of both malfunctions and improvements.
It is advisable, however, to use the Project Quality Plan to define the criteria that will allow the various
cycles to be tracked for a request.
o
A four-step cycle: Creation, Inspection, Evaluation and Processing

Its purpose is complete handling of the request. Subsidiaries, external clients or a
Hotline originate these requests. A primary filter is applied before the request is
submitted to the project owner for evaluation and processing
A three-step cycle: Creation, Evaluation and Processing

Its purpose is to allow the project owner to create its own requests and ensure
evaluation before submittal for processing
A two-step cycle: Creation and Processing

Its purpose is quick direct handling of the request. This cycle is designed for
[PROC_MGR]s, [DEV]s and [TEST]s on the same development team or between DSI
teams, for example
8.3.2 Roles
8.3.2.1 General
The various request participants belong to a group of users working with the same software project.
The roles assigned to each player are essential for optimum request processing.
Description of these roles shall be compliant with the OBS document.
COMPANY/DSI
79
8.3.2.2 Roles associated with a project
8.3.2.2.1 Requestors [REQ]

o
o
o
Receives a request directly from a client or a person inside the COMPANY group (regular mail,
E-mail, fax, telephone, etc.) or wishes to submit his own request.
Drafts the request for consideration
Consults the project requests (two levels of visibility depending on whether the project is
"public": the requestor sees all of the project requests together or, depending on whether the
project is restricted access, the requestor may sees only the requests that he has issued).
Participants who originate a change request:

o A developer [XXX]
o A client (to be defined in the PQP if authorization to open the CRMS to the outside is granted)
o The project owner
o The Hotline
o An Operating Manager
o A Maintenance Manager
o A Project Manager [PM]
o A work package manager [WPM]
o An Acceptance Manager
8.3.2.2.2 Verification manager [VER_MGR]

o
o
Players
o
o
o
Ensures the verification step for the request entered by the [REQ]
Then, submits the request to the [EVAL_MGR] for his evaluation
who could handle this role:
The project owner
A Project Manager [PM]
A work package manager [WPM]
8.3.2.2.3 Evaluation manager [EVAL_MGR]

o
o
Players
o
o
o
Ensures the requests evaluation step

After decision to assign the request to a release at a COPIL meeting, submits the request to
the [PROC_MGR] for processing
that could handle this role:
The project owner
8.3.2.2.4 COPIL
o
o
Analyzes the change requests evaluated by the [EVAL_MGR] and communicates the
information about the releases to the [CRML]
The COPIL (Project Steering Committee), depending on the project, can include:
the Project Manager [PM]
operating and technical work package managers [WPM]
The CRML
The project owner
The PQM
Test Managers
The Technical Support Manager
8.3.2.2.5 Change Request Management Leader [CRML]

o
o
COMPANY/DSI
Ensures that a CRMS is set up for each project

Ensures that each role is properly assigned
80
o
o
Ensures that the system is properly used and that dynamics are maintained
Manages users of the CRMS (login) and the creation of releases
o
o
Manages requests that are related to a product

Provides change components to the COPIL and consequently updates the CRMS: enters
releases and distributes requests to the various processing managers [PROC_MGR].
Players
o
o
o

A technical referring agent [TRA]
Note: The role of the [CRML] is associated more closely with the organization than with any project in
particular.
8.3.2.2.6 Processing manager [PROC_MGR]

o
o
Tracks the processing of requests referred to him by the [COPIL] or directly by the [REQ]
Assigns request to developers
Players who can fill this role:

o A Project Manager [PM]
o A work package manager [WPM]
8.3.2.2.7 Developers [DEV]

o
Players
o
o
o
o
Processes the request referred to him by his [PROC_MGR] or which he assigns to himself if his
[PROC-MGR] so authorizes him.
who can make corrections
A developer [XXX]
A Maintenance Manager
8.3.2.2.8 Testers [TEST]

o
Manages the processing test performed by the [DEV]
Players who could handle this role:

o The requestor
o The acceptance manager
8.3.2.2.9 Observer [OBS]

o
o
Tracks the processing of the request but without intervening

Is kept apprised of the requests progress
Players who could handle this role:

o The Project Quality Manager [PQM]
o The client (not the requestor) if the CRMS is open to the Internet
8.3.2.3 Roles associated with an organization
8.3.2.3.1 Administrator [ADM]

o
o
o
COMPANY/DSI
Manages the data required for operation of the CRMS

Ensures data integrity
Ensures, through the Operations division, that the architecture set up for the CRMS is reliable
at the server, database and system backup levels.
81
o
o
Ensures the confidentiality of the requests from an organization

Works in close collaboration with the various CRMLs in his organization
8.3.2.3.2 Supervisor [SUP]

o
o
Players
o
o
o
May view all requests issued on the entire CRMS

Works with the various CRMLs in his organization to obtain statistics on requests for sensitive
projects
A representative of the Quality & Safety division
The Director of Information Systems
The Group Quality Director
8.3.3 Request information

The request information is essential in order to best qualify the request and facilitate its management
and resolution. If a request is incomplete, its processing is stopped while awaiting additional
information.
Depending on the organization in place, request information is mandatory or optional and

other specific components can be added to qualify it in the PQP.
This information can be classified into themes, with each step in the life of a request saved in a
history that records the date, participant or change request manager, and action taken:
8.3.3.1 Origin of the request

o
o
o
o
o
o
o
o
o
o
request type (Development or Fault), indication given by the requestor but may be modified
later
requestor
issuer (customer, subsidiary, etc.)
issue date
date drafted
product(s)
version(s) where the fault was detected
priority
severity (determined when the fault is analyzed)
observers
8.3.3.2 Request description

o
o
o
o
o
o
o
o
request reference (identifies that particular request)

status
description
request subject (summary)
attachments
note (post-it type of note for including comments on the request)
comments
commercial impact
8.3.3.3 Request processing

o
o
COMPANY/DSI
correction expiration date

version(s):
- targeted decided at a COPIL meeting
- version(s) for which the request was processed
- acceptance confirmed
modified or added requirements (see REQM)
82
o
o
o
o
o
o
modified design elements

list of modified source codes (module, etc.). Traceability with regard to Configuration
Management (includes all sources and documents affected by a fault correction)
list of unit tests added for testing the correction
scenario identifiers for a fault detected from a test scenario (the same scenario can be used to
verify the correction)
updated documents because request processing involves systematic updating of
documentation produced during the development cycle
related requests or the reference request
8.3.4 Request statuses

The status indicated in the various steps of the process are represented in the CRML by status
indicators, fields, or request results. These elements make it possible to obtain the end
information needed to qualify the status of a request.
Status
Linked
Original
Step
Creation
Verification
Evaluation
Comments
Destination
Creation
Verification
Evaluation
To
be
verified
Creation
Verification
To
be
verified
Verification
Verification
1.
2.
To
be
evaluated
Creation
Evaluation
To
be
processed
Creation
Processing
To
be
processed
Evaluation
Processing
To
be Processing
processed
Processing
1.
2.
3.
COMPANY/DSI
The person who is handling

the request links the request
to an existing request; this
child request does not
develop any furtherit is
attached to a parent request
whose child inherits its
status. This person adds to
the request depending on his
role (his rights).
The [REQ] has entered his
request, which will be verified
by a [VER-MGR]
The [REQ] has completed his
request, which will be verified
by his [VER-MGR]
The [VER-MGR] changes the
request type, and the request
is verified again by a [VERMGR] who may be different
depending on the organization
request,
which
will
be
evaluated by an [EVAL-MGR]
request,
which
will
be
processed by a [PROC-MGR]
During
the
Assignment/
Planning phase, the [CRML]
submits the request to the
[PROC-MGR] designated at a
COPIL meeting to process it
The [PROC-MGR] puts the
request on hold
If the [REQ] is not able to
correct the request, he sends
it back to his [PROC-MGR]
If the test conducted by the
[TEST] after processing is not
83
To
be
specified
Verification Verification
Evaluation Evaluation
To
be Verification
evaluated
Evaluation
To
be Evaluation
evaluated
Evaluation
1.
2.
Rejected
Verification
Final status
Rejected
Evaluation
Final status
1.
2.
Rejected
COMPANY/DSI
Processing
Final status
To
be Evaluation
assessed
Evaluation
Assessment Evaluation
in progress
Evaluation
To
be Evaluation
assigned
Evaluation
Deferred
Evaluation
Evaluation
satisfactory, the [TEST] sends

the request back to his
[PROC-MGR]
The
request
is
poorly
qualified. It is returned to the
[REQ]
for
additional
information
After various verifications, the
[PROC-MGR] submits the
request for evaluation by an
[EVAL-MGR]
The [REQ] has completed his
request,
which
will
be
reevaluated by his [EVALMGR]
The [EVAL-MGR] changes the
request type, and the request
is submitted for a new
evaluation by an [EVAL-MGR]
who
may
be
different
depending on the organization
The request has reached the
end of the process.
Case of a request type that is
not managed (for example, an
application
configuration
problem)
The request has reached the
end of the process.
The
request type is not managed
(for example, an application
configuration problem or nonreproduced fault, etc.)
The request is rejected in the
assignment phase, because
the COPIL believes that it
does not need to be
processed
(discontinued
classification)
The request is rejected by the
[PROC-MGR]
because
he
believes that it does not need
to be processed (discontinued
classification)
After various checks, the
[EVAL-MGR]
submits
the
request for assessment by the
appropriate [PROC-MGR]s and
[TEST]s
The request is being assessed
by the [PROC-MGR]s and
[TEST]s
After assessment, the request
is submitted to the COPIL to
determine its assignment
During
the
Assignment/
Planning phase, the [COPIL]
84
Assigned
Processing
Processing
Correction Processing
in progress
To
be Processing
integrated
Processing
To
tested
Processing
Close
be Processing
Processing
Processing
decides to defer the request

The [PROC-MGR] assigns the
request to a [REQ] to be
processed
The [DEV] indicates that he is
starting the correction
The [DEV] has corrected the
request, for which the [PROCMGR] can do a code review
and/or
integrate
the
correction
After integration, the [PROCMGR] indicates to the [TEST]
that the request is ready to be
tested
If the test run by the [TEST]
after processing is passed, the
[TEST] closes the request
8.3.5 Process step details

Verification
Its purpose is to permit the verification or validation of a request before it is submitted for
evaluation
After verification, several cases may occur:
o The request type is not managed (for example, an application configuration
problem)
the request is rejected
o An already-identified request
the request is linked to an existing request
o A fault request is a development (or vice versa)
the request type changes
o The request is poorly qualified
the request is returned to the requestor for additional information
o Evaluation
Its purpose is to permit analysis of the requests relevance before it is submitted for
processing
After evaluation, several cases may occur:
o The request type is not managed (for example, an application configuration
problem)
o An already-identified request
the request is linked to an existing request
o A fault request is a development (or vice versa)
the request type changes
o A non-reproduced fault
o The request is poorly qualified
the request is returned to the requestor for additional information
o Processing
Its purpose is to allow the request to be processed until it is closed.
o
COMPANY/DSI
85
[DEM]
ENTERING A CHANGE
REQUEST
[RESP_TRT]
[DEV]
[TEST]
[RESP_TRT]
[DEV]
[TEST]
MONITORING
[RESP_CTL]
EVALUATION
[RESP_EVAL]
EVALUATION
[RESP_TRT]
[DEV]
[TEST]
PROCESSING
PROCESSING
KEEP THE CIRCUIT GOING
8.3.5.1 Creation steps
CREATION
[DEM]
Request entry
Search
Existing ?
Yes
No
Create the
request
Add to the request
To be checked or
To be evaluated or
To be processed
COMPANY/DSI
86
Specify: The manner in which requestors can add to existing requests must be specified depending on
the organization implemented. The type of requestors with the authority to complete the request must
also be specified.
8.3.5.2 Verification steps
COMPANY/DSI
87
8.3.5.3 Evaluation steps
COMPANY/DSI
88
8.3.5.4 Processing steps
COMPANY/DSI
89
9 DELIVERABLE PROJECT DOCUMENTS

9.1 Project Sheet
9.1.1 Document purpose
The Project Sheet is a summary illustration of the work accomplished during the opportunity definition
phase.
First, the detail level must be sufficient to allow the BSR milestone to be achieved, thereby committing
the resources needed to execute the Evaluation phase.
The complete sheet is required in order to pass the FSR milestone at the end of the evaluation phase.
The following information and sections must be included as a minimum:
o
o
o
o
o
o
o
o
o
o
o
Project title
Name of project manager
Product
Project owner
Category
Planned Beginning/End/Budgets
Project content, functions desired
Confirmation of advantages expected
Known, needed, or hypothetical technical orientations
Risks that may jeopardize proper project execution
Key success factors
An Expression-of-need document may be attached to the project sheet, explaining in greater detail
the clients needs to be considered within the scope of the project, the risks predicted, or the technical
orientations to be evaluated. In this case, for example for a development project, this attachment can
be a substitute for the OSD (Opportunity Study Document).
Its signature by both the DSI representative (Project Manager level) and the Project Owners
authorized representative marks the end of the initiation phase and represents the start of the
project, i.e., the commitment of the resources needed to execute the evaluation phase.
9.1.2 Document evolution

Any event with an impact on the projects objectives or scope will trigger an update to the project
sheet.
COMPANY/DSI
90
9.1.3 Model
Project Title :
Version :
Updating :
Division of Project
Owner
Resp.
budgetary
commitment
Project Manager
Product/Program
Category
Criticality
1
00/00/00
Division of Project Executor

Manager
Project Manager
Code Projet
Top target (BSR)
End
target
(LNR)
Signature
Project Executor
Signature Project
Owner
Number
Days
target
General
Management
Agreement
Reason General Management :
Description
Ref. Expressing Needs :
Motivations
MOA
MOE
Deliverables
Technical Directions
Risks approached
Factors and key indicators of success

Owner (PRODUCT)
COMPANY/DSI
Executor (PROJECT)
91
9.2 Project Quality Plan

The purpose of the PQP is to plan a project, i.e.:
o Identify the scope of the project.
o Identify the project objectives in terms of:
Content,
Quality,
Cost,
Deadlines.
o Formalize Who does What? Where? When? How? Why?
The PQP formalizes in particular the quality stipulations to which the Project Manager, project
participants, external persons, and management are committed.
It is used to present the project to the various parties involved and as a reference for project tracking.

Any event with an impact on the projects objectives will trigger an update to the PQP.
Le PQP is valid for the following milestones:
o FSR in its draft version
o DFR in its final version.
The PQP is reviewed and updated if necessary whenever a milestone is passed.
Any major change to the PQP will cause a return to the relevant milestone, which must be passed
again.
COMPANY/DSI
92
9.2.3 Model
The typical table of contents for a Project Quality Plan contains:
1
SCOPE OF APPLICATION
1.1
1.2
1.3
IDENTIFICATION
GENERAL INFORMATION ON PRODUCT / PROJECT NAME (CONVENTIONS)
GENERAL INFORMATION ON THE DOCUMENT
GLOSSARY
INTRODUCTION
3.1
3.2
DOCUMENT PURPOSE
RELATED AND REFERENCE DOCUMENTS
3.3
EVOLUTION OF THE PROJECT QUALITY PLAN
PROJECT SCOPE
4.1
4.2
PROJECT OBJECTIVES
HYPOTHESES AND CONSTRAINTS
4.3
PROJECT DELIVERABLES
PROJECT ORGANIZATION
5.1
PROJECT TEAM
5.2
PROJECT INTERFACES
PROJECT START-UP
6.1
6.2
6.3
6.4
6.5
6.6
RESOURCES
7.1
7.2
7.3
HUMAN RESOURCES
EQUIPMENT AND SOFTWARE RESOURCES
TRAINING PLAN
PROJECT STEERING
8.1
8.2
8.3
8.4
DEVELOPMENT CYCLE AND DEFINITIONS OF PHASES

TASK FLOW CHART (WBS)
ESTIMATES
MILESTONES AND SCHEDULING ELEMENTS
CRITICAL DEPENDENCIES
TOOLS, METHODS AND TECHNIQUES
PROGRESS MEETINGS
COMMUNICATION
MEASUREMENT PLAN
RISK MANAGEMENT PLAN
QUALITY ASSURANCE
9.1
GENERAL INFORMATION
9.1.1
Purpose of the chapter
9.1.2
Applicability
9.2
DEFINITION OF QUALITY OBJECTIVES
9.3
STIPULATIONS APPLICABLE TO THE PROJECT
9.3.1
Quality assurance tracking tools
9.3.2
Procedures applicable to the project
9.3.3
Verification of quality objectives
9.3.4
Tests
9.3.5
Quality records
10
CONFIGURATION MANAGEMENT
11
VENDOR MANAGEMENT
12
APPENDICES
COMPANY/DSI
93
9.3 Risk management sheet

The risk sheet consists of two sections:
o the summary table, presenting the results for each of the first six steps in the risk
management process.
o the action tracking table, presenting the results for the final step in the process. It lists the
actions necessary for resolving the risks in the summary table, describes them, and assigns a
manager and due date to each.

The risk summary table is initialized and sent during the projects evaluation phase; it is then reviewed
each time a milestone is passed. The action tracking table is tracked and updated by the Project
Manager throughout the project.
9.3.3 Model
Risk Summary Table
Risk Analysis
[field]
Ref. Risk probability of 1-4

RSK## [Description]
Risk weight =
probability x impact
COMPANY/DSI
5-8
medium
9-12
high
13-16
critical
++
--
Note Impact weight of 1-4

#
[Impact]
Risk analysis summary (= maximum weight)

Action Tracking Table
No. Proposed action
##
[Description]
1-4
low
Note
#
Wt.
##
No.
##
##
Manager
When?
Done on
[Name or position] ##/##/## ##/##/##
94
9.4 Steering sheet

The steering sheet is where the projects steering and tracking measurements are recorded for
presentation at the Steering Committee (COPIL) meeting.

The Steering Sheet is updated and tracked at each steering committee meeting; the project manager
records all steering measurements on it and can attach measurements from the measurement plan.
COMPANY/DSI
95
9.4.3 Model
Period
from
to
Project scope
Service:
Entitled:
Project manager:
MS Project reference:
Progress summary work stopped on

Initial
Revised
Revised
budget
budget
-1
(m-hrs)
(m-hrs)
Situation at end of
preceding period (m-hrs)
Situation at end of period

(m-hrs)
Conso.
Conso.
RSB
RAF
RSB
RAF
Status
Change
tendency
Schedule
Milestones or components included in project scope
Progress/
Status
Scheduled
end date
Revised
end date
Actual end
date
Situation compared to objectives

Objective
Current situation
Comments
General summary of current situation and project plans
Actions for handling risks and events

Problem description
Action decided
Status
Mgr.
Date
Principal work performed in the elapsed period
Principal work performed during the next period
Human resources (entries, departures, needs, training)
COMPANY/DSI
96
9.5 OBS (Organizational Breakdown Structure)

The purpose of the OBS is to present all of the projects roles and participants. The project manager
customizes the OBS for his project, indicating:
o
o
The choice of project participants from a generic proposal

The addition of project-specific roles, or division of certain generic roles that are too general

This document is initialized during the evaluation phase and updated if necessary as the project
proceeds. It constitutes an attachment to the Project Quality Plan, and the Project Manager creates a
hypertext link from the PQP to the OBS.
COMPANY/DSI
97
9.5.3 Model
Entity
This is a generic descriptive model of the organization of a project:

Alias
St Com Mgt Description
Missions/comments
com
Generic Roles
o
o
PM
PM
CP
WPM
DEV
CPR
PM
PM
PM
RQP
RQO
CML
PM
Admin JIRA
PM
CRML
PM
PM
PM
PM
PM
PM
RESP_EVAL
RESP_CTL
RESP_TRT
TEST
SUPER
RCC
PM
RSP
PM
CREC
PM
PM
PM
PM
PM
PM
PM
PM
PM
PM
PO
PO
PO
PO
PO
PO
DEV/MGR
DSI/RTE
DSI/MGR
MGR
BET/MGR
DDO/MGR
DDO/SYS
DDO/IND
DDO/MNT
DDO/REC
PO
CPMOA
MOA/MGR
PM
PM
PM
PM
PM
COMPANY/DSI
Project Manager
Work Package Manager
Developer
Project Coordinator
Project Quality Manager
CML: Configuration Management
Leader
CRM: JIRA Administrator
CRM: Change and Request
Management Leader
CRM: Evaluation Manager
CRM: Control Manager
CRM: Processing Manager
CRM: Responsible for acceptance
CRM: Supervisor
REQM: Prepares the
Functional/Technical Specifications
REQM: Functional Specifications
writer
REQM: Acceptance Designer
Manages the principal Work Package

Operational member on the project
Manages the Information Systems Managements project
portfolio
Nominated Quality Manager for the project
Guarantees the configuration of the deliverables and
lends his expertise to the stakeholders
Administers the JIRA platform and guarantees the
integrity of the data
Guarantees the proper application of the request and fault
management process
Prepares the functional/technical specifications in

accordance with the Project Owner's statement of
requirements.
Designs and writes scenarios for functional acceptance

tests
QMOA
RCO
RFO
TEC
INT
STC
Developments Manager
Technical Supervisor for the project
Director of Data Processing
Hierarchical Manager
Technical Research Department
Director of Operations
DDO Systems assistant
DDO Industrialization assistant
DDO Maintenance assistant
DDO Acceptance assistant
Project Owner
PO Project Manager
PO Management
PO Marketing
PO Product Release Department
PO Product Specification/Product
Manager
PO Quality Department
PO Sales Manager
PO Functional Supervisor
PO Technical Management
PO Integration
Customer Technical Support
WPM 2
WPM 3
DEV 2
DEV 3
Work Package Manager 2 (optional) Manages Work Package 2

Work Package Manager 3 (optional) Manages Work Package 3
Developer 2 (optional)
Developer 3 (optional)
MKT
PRD
PSD
PO
PO
PO
PO
PO
PO
Specific Roles
o
o
Director of the Gegedim Group's Data Processing

Project Manager's hierarchical Manager
Sponsor of the project
Packages and documents version releases

Prepares the Statement of Requirements and the
Specifications
Responds to and processes customers' technical requests
98

DEM
PM
PO
COMPANY/DSI
CM: Requester
PO-specific participant
Initiates the change request
99
9.6 PBS "Product Breakdown Structure"

9.6.1 Subject of the document
The PBS (Product Breakdown Structure) contains an exhaustive list of the project's deliverables, taken
from a "PBS_type" (standard PBS) model. This model identifies all the deliverables which might be
produced by a project, although projects do not necessarily have to produce all the deliverables in the
model.
The model should be used by the Project Manager as a reference guide to be followed in order to
identify the elements which should be produced by the project.
9.6.2 Modification of the document

The project PBS is updated by the Project Manager each time a deliverable is produced which is not
referenced in the initial PBS.
9.6.3 Model
This is a standard example of a PBS. The CEMR columns correspond to the category of the project:
Creation, Evolution, Maintenance, Research and Development. The authors are referenced in the OBS.
Code
Title
CEMR
Project file
1.1
Economic documentation
EMA
EMA-Market Research
DEO
DEO-Opportunity Study Document
Request for intervention/project (Project Sheet + Appendix)
Phase
Author
Init (BSR)
[MKT]
Init (BSR)
[PSD]
x x x Init (BSR)
[PSD]
Involvement strategy/Customer support plans
x x
Evaluation (FSR)
[MKT]
Strategy document for modeling and prototyping
x x
Assessment (FSR) [PSD]
Translation and localization imperatives
x x
Assessment (FSR) [MKT]
National and international deployment plans
x x
Assessment (FSR) [MKT]
1.2
Project Documentation
FPJ
FPJ - Project Sheet
x x x x All
[CP]
OBS
OBS - Organization Breakdown Structure
x x
All
[CP]
PBS
PBS - Product Breakdown Structure
x x x x All
[CP]
PLA
PLA - Phased scheduling
x x x x All
[WPM]
PLA
PLA - Phased Workload schedules/Budgets
x x x x All
[WPM]
PLA
PLA - Final schedule and budget (global planning)
x x x x All
[CP]
PLA
PLA - Recruitment/training/sub-contracting schedule for the project team
PLA
PLA - Detailed, phased resource allocation schedule
x x x x All
[WPM]
RSK
RSK - Risk Sheet
x x x x All
[CP]
PQP
PQP - Project Quality Plan
x x x x All
[RQP]
CHK
CHK-QUAL - Quality Management
x x x x All
[RAQ]
CHK
CHK-PQP - Project Quality Plan
x x x x All
[RAQ]
CHK
CHK-PQP - Compliance with requirements
x x
Assessment (FSR) [RQP]
CHK
CHK-PQP - Compliance with specifications
x x
Specification (DFR) [RQP]
CHK
CHK-PQP - Compliance with technical approval specification
x x
Execution (RLR)
[RQP]
CMPL
CMPL - Configuration management plan
x x
Execution (RLR)
[CML]
CHK
CHK-CMPL - Configuration Management
x x x x All
[RQP]
CHK
CHK-CMPL - Configuration Management Plan
x x x x All
[RQP]
MTF
MTF Tracing Matrix
x x
COMPANY/DSI
Specification (DFR) [CP]
x Assessment (FSR) [RCC]
100
Code
Title
CEMR
Phase
Author
FPG
FPG - Control panels/Control sheet
x x x x All
[CP]
CHM
CHM - Register of controlled modifications
x x x x All
[CML]
CHK
CHK-CHANGE - Change Management
x x x x All
[RQP]
FRP
FRP - Summary sheet (on passing a milestone)
x x x x All
[CP]
BIL
BIL - Phase assessment
x x
[CP]
BIL
BIL - Final assessment of project
x x x x Closure (FPR)
[CP]
BIL
BIL - Final closure report
[CP]
FRL
FRL - Proofreading sheet
x x x x All
[CP]
CHK
CHK-MPP - Management by Project
x x x x All
[RQP]
CHK
CHK-MPP - Supplier Relations Management
x x x x All
[RQP]
FRL
FRL - Proofreading sheet
x x x x All
[CP]
1.3
Development cycle
CDCF
CDCF - Functional Technical Specification(s)
x x
x Assessment (FSR) [RCC]
DSF
DSF - Functional Specifications Document(s)
x x
x Specification (DFR) [RSP]
DCO
DCO - Design file
x x x x Execution (RLR)
[CP]
MPD
MPD - Physical Data Model (PDM)
[DEV]
DCO
DCO - Other design documents
[DEV]
MAQ
MAQ - Simulation(s)/Storyboard(s)
x x x x Specification (DFR) [RFO]
PRO
PRO - Prototype(s)
x x x x Specification (DFR) [DEV]
REC
REC - Integration test schedules
x x x
Execution (RLR)
[DEV]
REC
REC - Technical acceptance test plans (inc. test decks and scenarios)
x x x
Execution (RLR)
[DDO/REC]
REC
REC - Test reports (unit & integr.)
x x x
Preparation (VLR) [DEV]
REC
REC - Unit test reports
x x x
Execution (RLR)
[DEV]
REC
REC - Integration test reports
x x x
Execution (RLR)
[DEV]
DVL
REC - Software Validation Document
x x x
Execution (RLR)
[DEV]
REL
REL - Evolution and correction document
x x x
Execution (RLR)
[DEV]
PV
REC - Technical acceptance report/Functional validation
x x x
Preparation (VLR) [DDO/REC]
DVV
DW - Version Validation Document
x x x
Preparation (VLR) [STC]
1.4
Launch
PLA
PLA - Detailed schedules for internal briefing meetings
x x
x Execution (RLR)
[PRD]
PLA
PLA - Detailed schedules for internal training
x x
Execution (RLR)
[PRD]
PLA
PLA - Detailed schedules for communication and launch
x x x
Preparation (VLR) [MKT]
PLA
PLA - Detailed schedules for external training
x x
Preparation (VLR) [OPS]
1.5
Minutes - Communication
CRR
CRR - Meeting minutes & actions log
CRR
CRR - Meeting minutes & LAUNCH actions log
COPIL/CODIR
COPIL - COPIL/CODIR Project Reviews
x x x x All
COM
COM - Communication plan
x x x x Assessment (FSR) [CP]
COM
COM - Project presentations and communication
"Product" deliverables
2.1
Software
COMPANY/DSI
x All
x x x x All
[CP/WPM]
Launch (LNR)
[CP/WPM]
[CP/WPM]
All
[CP]
LOG - Development architecture product
[DEV]
Source Code --> SVN link: Example: onekey-srv-1.0 component source code
[DLOG]
Executables --> SVN link: Example: onekey-srv-1.0.0 component executable code
[DLOG]
Example: onekey-srv-rpm-1.0.0.0 packaging
[DLOG]
Acceptance/pre-production architecture product
x x x
[DEV]
Source Code
[DLOG]
Executables
[DLOG]
Deliverable product on beta test site, pilot or for controlled deployment
x x x
[DEV]
Source Code
Execution (RLR)
Execution (RLR)
101
[DLOG]
Code
Title
CEMR
Author
Executables
[DLOG]
Production architecture product
x x x
[DDO/IND]
Source Code
[DLOG]
Executables
[DLOG]
Deliverable product for general deployment
x x x
Source Code
x x x x Preparation (VLR) [DLOG]
Executables
x x x x Preparation (VLR) [DLOG]
External components
x x
Execution (RLR)
Security mechanisms - anti-copy protection
x x x
Preparation (VLR) [QUA]
Installation utilities
x x x
Preparation (VLR) [DDO/IND]
Migration utilities
x x x
Preparation (VLR) [DDO/IND]
Other utilities (settings, communication etc.)
x x
Execution (RLR)
[DEV]
Localization Kit
x x
Execution (RLR)
[PRD]
Copy of the source codes for registration with the APP, the French Program Protection Agency x x
2.2
Phase
Execution (RLR)
[DLOG]
Preparation (VLR) [PO]
Packaging
2.3
Blank CD(s)
x x
CD labels
x x
CD sleeve
x x
Guarantee/registration card
x x

Box/File
x x
Packaging Documentation
x x
Manuals
x x
Files
x x
Inserts
x x
Cover
x x
Packaging
x x
Update pack
x x x
OF & production quantities
x x x
Content, media, formats
x x x
Execution (RLR)
[PO]
Parts list for assembly
x x x
Execution (RLR)
[PO]
2.4
Documentation
DOC
DOC - User manuals
x x x
Execution (RLR)
[STS]
HLP
HLP - On-line help
x x x
Execution (RLR)
[STS]
REL
REL - List of Improvements and Corrections made
x x
Execution (RLR)
[PRD]
DOC
DOC - Technical documentation (inc. Requirements, size etc.)
x x x
DOC
DOC - Installation manual
x x x
Execution (RLR)
[STC]
EXPL
EXPL - User handbook(s) for internal use (DDO & subsidiaries)
x x x
Execution (RLR)
[DDO/REC]
EXPL
EXPL - User handbook(s) for external use (customers)
x x x
Preparation (VLR) [DDO/REC]
EXPL
EXPL - Maintenance handbook(s)
x x
Preparation (VLR) [DEV]
COM
COM - Version launch note (subsidiaries info)
x x x
Preparation (VLR) [PRD]
COM
COM - Version launch note (customer info)
x x x
EXPL
EXPL - Support Procedures update (level 1)
x x
Preparation (VLR) [DDO]
EXPL
EXPL - Support Procedures update (level 2)
x x
Preparation (VLR) [DDO]
INT
INT - "Integrator" documentation inc, customer standard deployment schedule (maj)
x x
Preparation (VLR) [BIS]
2.5
Internal and external tutorial support
DOC
DOC - User Level - Documentation/PPT pres.
x x
Execution (RLR)
[PRD]
DOC
DOC - Administrator/Parameterising Level - Documentation/PPT pres.
x x
Execution (RLR)
[PRD]
DOC
DOC - Support/Operational Level - Documentation/PPT pres. [Internal]
x x
Execution (RLR)
[PRD]
DOC
DOC - Support/Operational Level - Documentation/PPT pres. [External]
x x
FOR
FOR - Test decks/demo companies
x x
Execution (RLR)
COMPANY/DSI
102
[PRD]
Code
Title
CEMR
Author
FOR
FOR - Trainer's Guide
FOR
FOR - Training on the new version
Execution (RLR)
[PRD]
REL
REL - Product Information Sheet (Info on the version) [Internal Doc]
x x x
Execution (RLR)
[PRD]
COM
COM - PPT briefing presentation
x x
Execution (RLR)
[PRD]
"Marketing/commercial" deliverables
3.1
Brochures
Sales brochures
x x
Technical brochures
x x
Other documentation (examples of reports, screenshots, blank books etc.)
x x
Mailing/Newsletter
x x
Computer graphics
x x
Content-data & demo companies
x x
Media
x x
Installation Guide
x x
Scenario/demonstration script
x x
Packaging
x x
PPT presentations
x x
Execution (RLR)
[MKT]
Demo Storyboard/Flash
x x
Execution (RLR)
[MKT]
Demo script
x x
Execution (RLR)
[MKT]
Demo CD/EXE
x x
Execution (RLR)
[MKT]
CUS
CUS - Sale and implementation cycle
x x
Execution (RLR)
[MKT]
CUS
CUS - Sale aid manual, selling points
x x
Execution (RLR)
[MKT]
CUS
CUS - References and customer case studies
x x
Execution (RLR)
[MKT]
CUS
CUS - Analysis & Positioning vs the competition
x x
Execution (RLR)
[MKT]
3.4
Pricing
CUS
CUS - Reference pricing
x x
Execution (RLR)
[MKT]
CUS
CUS - Discount grid
x x
Execution (RLR)
[MKT]
CUS
CUS - Local pricing
x x
Execution (RLR)
[MKT]
3.5
Contractual documents
JUR
JUR - Agreements on controlled availability (partners, pilot sites)
x x x
Execution (RLR)
[OPS]
JUR
JUR - License contracts (Demo/Evaluation)
x x
JUR
JUR - License contracts (definitive)
x x
JUR
JUR - Service contracts (training, parameterising)
x x
JUR
JUR - Maintenance and assistance contracts
x x
JUR
JUR - Partner contracts and royalty agreements
x x
JUR
JUR - Copyright declarations
x x
JUR
JUR - Certificate of registration with the APP, the French Program Protection Agency
x x
3.6
Launch kit
COM
COM - Commercial launch pack
x x
COM
COM - Website update
x x x
COM
COM - Press file
x x
COM
COM - Technical launch file
x x x
3.2
x x
Phase
Preparation (VLR) [PRD]
Demonstration and evaluation kits
3.3
Sales aids
All gadgets
x x
COM
COM - PPT presentation for conferences/customer presentations
x x
CUS
CUS - Subsidiary feedback report
COMPANY/DSI
[PO]
103
9.7 Scheduling
9.7.1 Estimate sheet
An example of the use of the estimate tool to assist in the definition of the project schedule.
The global estimate spread over all the phases is worked out from the development charge
(Coding/Unit Tests/Configuration Management) calculated, for example, by the function points
method, based on the Functional Specifications.
STANDARD CEGEDIM (dm)
Work loads
Per work package
MPP Phases
CROSSOVER
Major Work
Per phase
standard
Work loads
standard
Work loads
Coeff
in dm
coeff
in dm
15%
50,0
Supervisors
Technical and application support
2%
7,0
Quality Assurance
Process & Product Check-lists / audits / PQP
3%
10,0
Requirements
Traceability monitoring
1%
4,0
Monitoring and control
Management / Steering committee / Mgmt committee
4%
13,0
5%
16,0
INITIALIZATION Statemant of needs
Operational WP monitoring Operational WP and HR monitoring

Statement of needs / Opportunity study document
4%
13,0
4%
13,0
EVALUATION
feasibility study
2%
7,0
4%
14,0
Technical specifications
2%
7,0
General specifications
6%
19,0
8%
26,0
Modeling
2%
7,0
43%
133,0
17%
54,0
8%
28,0
SPECIFICATION Specification
REALISATION
Design
Design and configuration management
DEVELOPPEMENTS
Coding/ Unit Tests / CM
4%
13,0
33%
100,0
Tests
Documentation
Intgration tests
3%
10,0
Product and operating documentation
3%
10,0
IT Functional acceptance
7%
22,0
User acceptance
8%
25,0
Training
Internal training
2%
7,0
Delivery
Installation
1%
4,0
Training
User training
2%
7,0
Promotion
Promotion
2%
7,0
Production
Vrification in normal service - Corrections
3%
10,0
Bilan
Report
PREPARATION Validation
LAUNCH
CLOSING
TOTAL
Budget (in dm)
1%
4,0
1%
4,0
100%
322,0
100%
322,0
9.7.2 MS-Project Schedule

An example of a model project, implementing all the phases in the Management by Project lifecycle:
COMPANY/DSI
104
COMPANY/DSI
105
9.8 Configuration Management Plan

9.8.1 Subject of the document
The aim of this document is:
o To provide all information necessary on the project's configuration management to all actors
involved in the project.
o To anticipate (define and plan) the configuration management requirements and the tasks to
be carried out for the next phase of the project's lifecycle. Indeed, writing this document
serves to ask questions even before any problems arise.
9.8.2 Modification of the document

Configuration management requirements change at each milestone. For this reason, the document
must be reviewed before the start of each phase, because this is when requirements can be most
clearly seen.
The DFR milestone is good example:
o Before DFR, requirements are at a minimum: all that is required is to manage the
documentation.
o After DFR, requirements increase as there is much more to be managed:
source code
databases
binaries
etc.
The configuration management plan is known by the acronym CMPL. A specific role is defined as a
project resource, to create and maintain this plan and to support configuration management activities;
this role is known by the term CML (Configuration Management Leader).
COMPANY/DSI
106
9.8.3 Model
The following is a standard summary of a Configuration Management Plan:
1 CONTEXT
1.1 GENERAL POINTS ON <PUT PROJECT NAME HERE>
1.2 GENERAL POINTS ON THE REFERENCE DOCUMENTS
1.3 REFERENCEs
1.4 GLOSSARY
2 SPACES
2.1 THE WORK SPACE [CONF0-3-2]
2.2 THE CONFIGURATION SPACE [CONF0-3-3]
2.3 THE INTEGRATION SPACE [CONF0-3-4]
2.4 THE ACCEPTANCE SPACE [CONF0-3-5]
2.5 THE PRE-PRODUCTION SPACE [CONF0-3-6]
2.6 THE PRODUCTION SPACE [CONF0-3-7]
2.7 THE SOURCE COMPONENT STORAGE SPACE [CONF0-3-8] et [CONF0-3-9]
2.8 THE CONSTRUCTED COMPONENT STORAGE SPACE [CONF0-3-10]
2.9 THE TOOL STORAGE SPACE [CONF0-3-11]
3 TOOLS [CONF1-1-16]
4 TEAMWORK [CONF0-5]
5 TYPES OF CONFIGURATION COMPONENTS [CONF1-1-2]
6 PRODUCT CONSTRUCTION [CONF1-1-3]
7 DEFINITION OF BASELINES [CONF1-1-4]
8 PRODUCT MATRIX [CONF1-1-5]
9 INDICATORS [CONF1-1-6]
10 RECORDS [CONF1-1-7]
11 CONTROLS [CONF1-1-8]
12 BACK-UP [CONF1-1-9]
13 ARCHIVING [CONF1-1-10]
COMPANY/DSI
107
10 MANAGEMENT BY PROJECT AND CMMI

10.1 The CMMI reference framework
"Capability Maturity Model Integration (CMMI)" is a process improvement approach which provides
organizations with the essential elements to implement effective processes. It can be applied to guide
the improvement of processes through a project, a division or an entire organization. The CMMI model
helps to integrate distinct organizational functions in the traditional way, to establish process
improvement objectives and priorities for its implementation, to advise on defining quality processes
and to provide a framework for the evaluation of operational processes in the domain of software
development project management.
The model is sub-divided into maturity levels, rated 1 to 5, and into process domains:
Name of process domain
Abbrev.
Category
ML
Requirements Management
REQM
Engineering
Project Planning
PP
Project Management
Project Monitoring and Control
PMC
Project Management
Supplier Agreement Management
SAM
Project Management
Measurement and Analysis
MA
Support
Process and Product Quality Assurance
PPQA
Support
Configuration Management
CM
Support
Requirements Development
RD
Engineering
Technical Solution
TS
Engineering
Product Integration
PI
Engineering
Verification
VER
Engineering
Validation
VAL
Engineering
Organizational Process Focus
OPF
Process Management
Organizational Process Definition +IPPD
OPD
+IPPD
Process Management
Organizational Training
OT
Process Management
Integrated Project Management +IPPD
IPM
+IPPD
Project Management
Risk Management
RSKM
Project Management
Decision Analysis and Resolution
DAR
Support
Organizational Process Performance
OPP
Process Management
Quantitative Project Management
QPM
Project Management
Organizational Innovation and Deployment
OID
Process Management
Causal Analysis and Resolution
CAR
Support
CL1
CL2
CL3
CL4
Level 2
Level 3
Level 4
Level 5
The implementation of the Management by Project reference framework aims to align at an early
stage the maturity level of the COMPANY Information Systems Management with level 2 of the staged
CMMI, called the "Managed" level, then to define and deploy all the organizations level 3 processes,
called "Defined". The first tier lists good practices in software development project management in
seven key domains, which are detailed later in this chapter.
COMPANY/DSI
108
CL5
This is the report on the achievement of level 2 evaluation:
COMPANY, level 2 CMMI Evaluation

Boulogne-Billancourt, France, 13th March 2007
Within the context of its strategy for development based on the CMMI quality reference framework,
COMPANY's Information Systems Management has just obtained Level 2 evaluation, which makes this
the first department in the group to attain this professionally-recognized maturity level.
An industrial and quality strategy for growth

As part of its rationale of continual improvement, the COMPANY Group is now a trail-blazer among
French service companies in the health sector, being the first to adopt a "Total CMMI" production
strategy for all the IT developments in its "New Offer", giving it a unique market position.
And so from one end of the chain to the other, every COMPANY Group customer is now guaranteed
the same degree of quality, adding one essential concept to its systematic respect of commitments
and delivery times: reactivity.
A strong return on investment expected

By achieving the CMMI Maturity Level 2, COMPANY is reaping the fruits of its significant investments,
committed in 2005 and 2006, particularly in training for all its employees. Significant effort is being
put into implementing the good practices of the CMMI, with a strong return on investment expected
to be delivered from 2007.
In fact, the Level 2 concerns all the stakeholders of a project, and it has been decided to roll out the
practices to all the "New Offer" projects run by the Group in order to obtain a Level 3 CMMI evaluation
in 2008.
In the
meantime, there are real, quantifiable benefits to the CMMI Level 2. These have a bearing on:
Sharing the key indicators of a project, for optimized and transparent management,
The anticipation of risks to implement corrective actions before these risks become a reality,
The verification of the suitability of the deliverables, and traceability, with functional
requirements, to the testing and acceptance strategy
Control of the application of Quality processes within the projects themselves,
User satisfaction, anticipation of evolutions in the functional scope by improved Requirements
Management.
Bringing together expertise and technological solutions.
Advantages for the future

One of COMPANY's founding values is the respect of the needs of its customers and a strong desire to
innovate; this is why the group has always placed customer satisfaction and innovation at the heart of
its strategy. So above and beyond the simple maturity level, the important thing really is that its
teams are involved in a rationale of improvement on an ongoing basis, to maximize the benefit to the
customers who have placed their confidence in them. By basing itself on CMMI, an internationally
recognized reference framework, COMPANY has demonstrated its determination to strengthen its
expertise, methods and organization so as to be in a position to offer ever more innovative and
efficient solutions. These elements will be the key to the group's future success and growth.
COMPANY/DSI
109
10.2 REQM - Requirements Management

Requirements Management concerns all the requirements in advance of a project or produced by it.
Requirements Management touches on functional and technical requirements.
The following is the specific objective of "Requirements Management" activity:
SG 1
Manage requirements: Requirements are managed and any inconsistencies

with the project plan or the products are identified.
The practices associated with this objective are:
SP 1.1
Understand the requirements: reaching agreement with the order giver as to

the precise meaning of the requirements
Agreement with the order giver is assured by permanent dialogue, which is established in
introductory phases of the project. The requirement is identified by the customer or
representative, then analyzed and reformulated by a Specifications Writer in agreement with
customer. Subsequently, each deliverable is developed in collaboration between upstream
downstream stakeholders.
SP 1.2
the
his
the
and
Obtain a commitment to the requirements: obtain a commitment to the

requirements from all participants in the project
This commitment can be obtained on a project on which all the stakeholders have the same level of
understanding and one which is properly framed by specifications supplied by the requester (Project
Owner). This commitment involves all participants within the scope and feasibility of the project. The
project starts after all participants have agreed on the meaning of the functional specifications, and on
the consequences (elements in the possession of the Project Management must be sufficient to assess
the cost of the project, and the associated risks).
This practice follows from SP1.1: the commitment can only be made if the requirements are correctly
and equally understood by all.
This practice concerns the way the lifecycle management demands of all participants in the project
that they validate the requirements, as they are expressed, and jointly agree on the ensuing project.
The constraints of the previous practice, which guarantee the same level of understanding of the
requirements by everyone, affect the application of this practice.
The "Project Monitoring and Control" domain, defines and implements the procedures which enable,
specifically, this commitment to be obtained and formalizes it in the document (report on passing BSR
milestones for the Functional/Technical Specifications and DFR for the functional specification).
SP 1.3
Manage modifications to the requirements: managing modifications to the

requirements as they evolve during the project
Any modifications which arise during a project must follow the process defined by the "Management
of faults and evolutions" working group.
The documents provided identify the requirements in such a way that any new requirement is easily
identifiable in the project.
Any change in a requirement after the FSR milestone must follow the process defined by the
"Management of faults and evolutions" activity.
COMPANY/DSI
110
SP 1.4
Maintain the bidirectional traceability of requirements: maintaining traceability

between requirements, project planning and the products
The methodology put in place requires the identification of each requirement, regardless of level, in a
unique and stable way.
All elements described in the various deliverables, and which contribute to the execution of the
project, are identified.
A tracing matrix is implemented, throughout the life of the project, to make the link between the
various identifiers present in each of the deliverables of the project (use cases, entities, screens etc.).
SP 1.5
Identify inconsistencies between the project planning, products and

requirements
Inconsistencies between requirements and the project planning must be identified and corrective
actions taken if necessary.
This practice is linked to the "Project Monitoring and Control" domain, which insists on verification that
the requirements correspond to the project planning, and the implementation of corrective actions
(Project Manager and Steering Committee).
10.3 PP - Project Planning

The following is the specific primary objective of "Project Planning" activity:
SG1
Estimates of the project planning parameters are established and

maintained
SP1.1
Draw up a high-level flow chart of the tasks (WBS) to estimate the scope of the
project
SP1.2
Draw up and maintain estimates of the attributes of the work products and of
the tasks
SP1.3
Define the phases in the project's lifecycle on which planning will be based
SP1.4
Estimate the expenses of the project and the costs for the work products and
tasks, on the basis of a logical analysis of the estimates
The following is the second specific objective of the "Project Planning" activity:
SG2
A project plan is drawn up and maintained as a reference for the

management of the project
SP2.1
Draw up and maintain the budgets and schedule (in delivery times) for the
project
SP2.2
Identify the risks of the project
COMPANY/DSI
111
SP2.3
Plan the management of the project data
SP2.4
Plan the resources needed for the execution of the project
SP2.5
Plan the knowledge and skills needed for the execution of the project
SP2.2
Plan the involvement of identified stakeholders
SP2.7
Draw up and maintain the content of the global project plan
The following is the third specific objective of the "Project Planning" activity:
SG3
Commitments relating to the project plan are drawn up and maintained
SP3.1
Carry out a review of all the plans affecting the project, in order to gain a clear
understanding of the commitments of the project
SP3.2
Reconcile the project plan to reflect the estimated and available resources
SP3.3
Obtain the commitment of interested stakeholders, who are responsible for

executing the plan, or for supporting the execution of the plan
10.4 PMC - Project Monitoring and Control

The following is the primary specific objective of the "Project Monitoring and Control" activity:
SG1
The actual performance and progress of the project are monitored against
the project plan.
SP1.1
Monitor the actual values of the project planning attributes against the plan
SP1.2
Monitor the commitments against those identified in the project plan
SP1.3
Monitor the risks against those identified in the project plan
SP1.4
Monitor the management of project data against the project plan
SP1.5
Monitor the involvement of stakeholders against the project plan
SP1.6
Carry out periodic reviews of the project's progress, performance, problems

and critical points
COMPANY/DSI
112
SP1.7
Carry out a review of the developments of the project at selected milestones
The following is the second specific objective of the "Project Monitoring and Control" activity:
SG2
Corrective actions are managed until closure when the results or the
performance of the project deviate significantly from the plan.
SP2.1
Collect and analyze problems (stumbling blocks) and determine the necessary
corrective actions
SP2.2
Take corrective action on stumbling blocks which have been identified
SP2.3
Manage corrective actions until closure
10.5 CM Configuration Management

The following is the primary specific objective of the "Configuration Management" activity:
SG1
Identified reference versions (baselines) of the work products are

established.
SP1.1
Identify the items of configuration, components and work products related to

it, which will be placed under configuration management
SP1.2
Establish a configuration management system
SP1.3
Create or deliver baselines for internal use or for delivery to the customer
The following is the second specific objective of the "Configuration Management" activity:
SG2
Changes to the work products placed under configuration management are

monitored and controlled
SP2.1
Monitor the requests for changes to items of configuration
SP2.2
Control the changes to the items of configuration
The following is the third specific objective of the "Configuration Management" activity:
SG3
The integrity of the baselines is established and maintained
COMPANY/DSI
113
SP3.1
Establish and maintain records describing the items of configuration
SP3.2
Carry out configuration audits
10.6 PPQA - Process/Product Quality Assurance

The following is the primary specific objective of the "Project Monitoring and Control" activity:
SG1
The compliance of the process executed, and of the associated products and
services, is objectively evaluated against the descriptions of applicable
processes, standards and procedures.
The role of Project Quality Manager (RSP) has been defined and put in place for each project. The
project's quality objectives are expressed in a Project Quality Plan (PQP) created jointly by the Project
Manager and the Project Quality Manager.
SP1.1
Evaluate objectively the executed and designated processes against the

descriptions of applicable processes, standards and procedures
The objective evaluation is carried out by the Project Quality Manager based on check-lists for the five
processes in QMS-Management by Project. The Quality & Security Centre objectively evaluates the
quality assurance process on the project.
SP1.2
Evaluate objectively the executed and designated products and services against
the descriptions of applicable processes, standards and procedures
The objective evaluation is carried out by the Project Quality Manager based on check-lists of the
important deliverable products.
The following is the second specific objective of the "Product and Process Quality Assurance" activity:
SG2
Non-compliances are objectively monitored and communicated and they are

resolved
Running through the check-lists highlights non-compliances (NCs); they are recorded and monitored
by the Project Quality Manager and the Project Manager.
SP2.1
Communicate quality problems and resolve non-compliances with personnel

and management
The NCs are recorded in the group space; in order to resolve them, actions are allocated to the
project resources involved. If the project operators are unable to resolve an NC, it is "escalated" to
the Quality Manager of Information Systems Management by the Project Quality Manager and
processed at organization level.
SP2.2
COMPANY/DSI
Establish and maintain records of Quality Assurance activities
114
All QA activities are planned as part of the project management and recorded in the project's group
space in the form of check-lists, a quality statement, an NC and actions list, meeting minutes.
10.7 MA- Measurement and Analysis

The following is the primary specific objective of the "Measurement and Analysis" activity:
SG1
Measurement objectives and activities are aligned with the identified

information requirements and objectives.
Measurement objectives have been defined against the strategic objectives of the Information
Systems Management, as expressed in the information systems master plan.
SP1.1
Establish and maintain metrology objectives, which are derived from the
identified information requirements and objectives
The objectives derived from the master plan are defined in a project metrics plan.
SP1.2
Specify the measurements to take account of the metrology objectives
The resulting measurements are defined in the metrics plan and presented in the form of a graph.
SP1.3
Specify how metrology data will be obtained and stored
The metrics plan defines the collection methods, the responsibilities for this collection and the method
of recording the measurements.
SP1.4
Specify how metrology data will be analyses and reported
The presentation and analysis of the measurements is carried out by the Steering Committee by
means of the control sheet, recorded and historized in the project's group space.
The following is the second specific objective of the "Measurement and Analysis" activity:
SG2
The results of measurements which address the identified information

requirements and objectives are provided
SP2.1
Obtain the specified measurement data
Measurements are collected using project data, in particular by automatic macros in the project
management tool MS-Project and the change management tool JIRA. Or they may be transferred
manually from the QA check-lists.
SP2.2
Analyze and interpret the measurement data
The analysis and interpretation of the control measurements is performed by the Project Manager on
the control sheet.
COMPANY/DSI
115
SP2.3
Manage and store the measurement data, the measurement specifications and
the analysis results
The measurements appear on the control sheet which is recorded and historized in the project's group
space.
SP2.4
Report the results of measurement and analysis activities to all interested

stakeholders
The presentation and analysis of the measurements is carried out by the Steering Committee by
means of the control sheet and Steering Committee minutes, recorded in the project's group space.
10.8 SAM - Supplier Agreement Management

The following is the primary specific objective of the "Supplier Agreement Management" activity:
SG1
Supplier agreements are established and maintained
SP1.1
Determine the type of acquisition for each product or product component to be

purchased
SP1.2
Select suppliers on the basis of an assessment of their capacity to meet the

specified requirements and established criteria
SP1.3
Establish and maintain formal agreements with the supplier
The following is the second specific objective of the "Supplier Agreement Management" activity:
SG2
Agreements with the supplier are satisfied by both the project and the
supplier
SP2.1
Conduct a review of "off-the-shelf" products (including software packages) to

ensure that they meet the specified requirements covered by an agreement
SP2.2
Carry out activities with the supplier as specified in the supplier agreement
SP2.3
Ensure that the supplier agreement is satisfied before accepting the purchased
product
SP2.4
Transfer the products purchased from the supplier to the project
10.9 General objective: Institutionalize a managed process

The general objective is not specific to the activity of a single domain, but is common to the
organization and to the global project management method within the context of the improvement of
processes.
COMPANY/DSI
116
This general objective is:
GG 2
Institutionalize a managed process: The process is institutionalized as a

managed process
The associated practices are as follows:
GP 2.1
GP 2.2
GP 2.3
GP 2.4
GP 2.5
GP 2.6
GP 2.7
GP 2.8
GP 2.9
GP 2.10
Establish an organization policy

Plan the process
Provide the resources
Allocate responsibilities
Train the employees
Manage the configurations
Identify and involve appropriate order givers
Monitor and control the process
Objectively evaluate compliance
Conduct an assessment with the hierarchy
This general objective is the responsibility of the whole organization. The complete process is
institutionalized, correctly documented and explained to those company employees who are involved
in the processes.
The reasons for the application of defined methods are understood and accepted by all.
The application of defined methods is insisted on, supported and verified.
Introducing a training plan is vital to its proper implementation
An authoritative body is created to provide support to users on the methods introduced and their
eventual adaptation (Engineering Process Group)
A permanent body is created to verify compliance of day-to-day practices with the defined method.
(QA)
It is the Project Quality Manager's role to maintain and control the application of the quality assurance
policy on projects in which he is involved, and it is therefore his responsibility to ensure that the
above-mentioned points are correctly conducted.
COMPANY/DSI
117
11 REFERENCES
COMPANY
http://www.Company.fr
CMMI
Capability Maturity Model Integration
Software Ingineering Institute

http://www.sei.cmu.edu/cmmi
COMPANY/DSI
118
12 LIFE CYCLE SYNOPSES

Milestones
Phases
Initialization
Deliverables
Project
Sheet
Evaluation
PQP OBS
PBS CMPL
Planning
Opportunity Expression of
need
Specification
CDC
Models
Realisation
Specif.
Conceptions
Preparation
Source
Code
Beta
version
Launch
Accepta
nce
record
Closing
e
Final
version
Project
report
Production
Feasibility
Installation
General
specifications
Acceptance
validation
Detailed
specifications
Work
Package
WP2
Coding
Unit tests
Conception
Integration
Coding
Conception
Test
WP3
Conception
Coding
Integration
test
Test
WP#
Coding
Conception
Test
Manageme
nt
Committee
PM
RQP
Steering
committee
WPM
Report
IT
Project Ownership
COMPANY/DSI
Project Ownership
119
M A NA G E M E NT
I NI T I A L I SA T I O N
I NI T I A L I SA T I O N
EV A L UA TIO N
EV A L UA TIO N
P ro j e t
r pe rt o ri &
c a t go r is
CP & W P M
e n pla c e
CP & W P M
P ro po s s
Au Co D i r
P r - c ad r ag e d u p r o jet
P la n n in g
ch a r g e s
p h a se
E VAL
P la n n in g
ch a r g e s
f in
(d r a f t )
ING E NIERIE
F ich e
P ro j e t
Fi c h es
P i l otag e
&
R c ap .
Ca pa &
P la n s d e
so u r cin g
Etu d e d e
M arc h
et /ou D E O
P la n n in g
ch a r g e s
p h a se
SPE C
Tb l x
de
b ord
PBS
d ra f t
P la n n in g
ch a r g e s
f in
OB S
Dr a f t
Niv 1
F ich e
P ro j e t
P la n n in g
ch a r g e s
p h a se
RE AL
Fi c h es
P i l otag e
&
R c ap .
P QP
PBS
Tb l x
de
b ord
P la n n in g
ch a r g e s
Jo u r n a l
des
f in
r isq u e s
OB S
Exp r. D e
B es oi n s
CdCF
F ich e
P ro j e t
P la n n in g
ch a r g e s
p h a se
P RE P A
Fi c h es
P i l otag e
&
R c ap .
Tb l x
de
b ord
P QP
PBS
Jo u r n a l
des
f in
r isq u e s
CR
ru n i on s
B i l an
P h as e
S P EC
S p ec i fi c at.
Fon c ti on n el l es
C as d
u ti l i s ati on
M aq u ett es
G n ral es
Fi c h es
P i l otag e
&
R c ap .
P QP
PBS
V ers i on s
S p c i f
Fon c ti on n el l es
D t ai l l e s
Tb l x
de
b ord
P la n n in g
ch a r g e s
f in
CR
ru n i on s
OB S
b eta
S i tes p i l ot es
S c en ari i
J eu x d es s ai
D v el op p e m en ts ap p l i c ati on s
PV de
rec et te
Fon c ti on n el l e
D v el op p e m en ts e xp l oi t ati on
& te s ts ( u n i tai re s & i n t g ra ti on )
D os s i er d e
C on c ep ti on
S ys t m es
Log i c i el s
B as es d e
P l an d e
G es ti on
de
C on fi g u ra ti on
C od e
S ou rc e
O p p or tu n i ts
c om m erc i al es i d en ti fi e s
A d q u ati on ro ad m ap
v ri fi e
En g ag em en ts c l i en ts ,
p os s i b l es s i te s p i l ote s et
c l i en ts t es ts i d en ti fi s
Tou tes exi g en c es

fon c ti on n el l es ,
tec h n i q u es e t
op r ati on n el l es
d oc u m en t es
O p p or tu n i ts
c om m erc i al es exp ri m es
O ri en ta ti on s tec h n i q u es
v oq u es
I m p ac ts tec h n i q u es
p oten ti el s i d en ti fi s
C P & W P M s u g g rs
R i s q u es i d en ti fi s
BS R
FC S d u p rojet i d en ti fi s
R i s q u es & p ar ad es
i d en ti fi s
C ap ac i t en r es s ou rc e
val u e & P l an s d e
rec ru t em en t /f o rm ati on /
ac q u i s i ti on s f or m al i s s
COMPANY/DSI
T a r if s
C o n t ra t s
FS R
( p erf or m an c es , en vi r t
exp l oi t ati on ,
m i g ra ti on ) i n tg r s
d an s l e p roj et
OB S
P QP
I m p ac ts tec h n i q u es ( p e rf or m an c es , en vi r t exp l oi t ati on ,

m i g ra ti on ) t rai t s
Log i c i el s i n s tal l e et s e l an c e c o r rec te m en t
P reu v e t an g i b l e d e l exi s ten c e d e d oc u m en ta ti on s
A c ti on s d e l an c e m en t /f o rm ati on s i n te rn e s p l an i fi es
P r o m o t io n
In s t al l at io ns
P r o d uc t io n
Tou t p ers on n el i n t ern e

( ven t e, s u p p or t,
i n tg ra teu rs ) f or m .
A c ti on s d e l oc al i s ati on ,
d e l an c em en t et
fo rm ati on s e xt ern es
p l an i fi es
Ec a rt s p ar r ap p or t au
P Q P & u ti l i s ati on d es
m od l es
Eq u i p es d e
m ai n t en an c e
op r ati on n el l es
I n fras tru c tu r es e t
N i ve au d e s e rvi c e r en d u
en ad q u ati on av ec S LA
c l s
P re m i e rs c l i en ts
i n s tal l s
Tou tes ve rs i on s l oc al es
p rt es
Tou tes d o c u m en ta ti on s
d i s p on i b l es
RLR
C l tu r e
Tous
Do cu m e n t s
d e x p lo it a t io n
e t m a in t e n a n ce
Tou tes val i d ati on s d es

l og i c i el s p os i ti v es ou
ave c r s e rv es c on n u es
A d q u ati on ro ad m ap , O ri en ta ti on s t ec h n i q u es e t
c om m erc i al es c on fi rm es et p u b l i es
D FR
B i l an
CR
Tou tes
ru n i on s
p h as es
L o c al i s ati on s
D at e /b u d g et c i b l es
val i d s & ap p rou vs
En g ag em en ts c l i en ts i d en ti fi s , s i t es p i l ot es e t c l i en ts
tes ts p l an i fi s , p r vi s i on s d e v en te s es ti m es
D i s p on i b i l i t
op r ati on n el l e d es
res s ou rc es d e
d vel op p em en ts
C P & W P M n om m s
i n d i q u s
B r o ch u r e s
A r g u m e n t a ir e s
O p p or tu n i ts c o m m er c i al es i d en ti fi es
Ev ol u ti on s n ot oi r es c l i en ts / m a rc h s /c on c u rr en ts c on n u es
PBS
Tb l x
de
b ord
Fo r m at i o n s
u t i li s at eu r s
En g ag em en ts c l i en ts &
p rvi s i on s d e v en te
c on fi r m s
c om p ri s e t ap p r ou v s
p ar M O A & M O E
( p erf or m an c es , en vi r t
exp l oi t ati on ,
m i g ra ti on ) v al u s
A d q u ati on ro ad m ap
v ri fi e
S u p p o rt s d e
C o u rs e t
S u p p o rt s d e
P r se n t a t io n
Feed b ac k M aq u e tt es
C on ten u s e t n i ve au x d e
p erf. c l ai re m en t d fi n i s ,
P QP
M i s e en P r od u ct i on
A d q u ati on ro ad m ap ,
& c o m m e rc i al es
c on fi r m es
c on fi r m es
M O A , P r od u i t, C at g o ri e,
C ri ti c i t c on n u s
D oc u m en t
de
V al i d ati on
de
V ers i on
Fo r m at i o n s
i n t er n es
R ec et t e
Do cu m e n t a t io n
Ut ilisa t e u r
A d m in ist r a t e u r
E x p lo it a t io n
P a r a m t r ag e
D p lo ie m e n t
PV de
rec et te
u ti l i s ateu r
In d u s t ri al i s ati on
du
Log i c i el
D o cu m en t at i on s
En g ag em en ts c l i en ts
i d en ti fi s
Fi c h es
P i l otag e
&
R c ap .
B i l an
CR
P h as e
ru n i on s
P R EP A
OB S
J ou rn al
d es
ri s q u es
Fi c h e
P roj et
V ers i on
en
p rod u c ti on
D oc u m en t
de
V al i d ati on
R ap p or ts
d e tes ts
In fr as t r u c t u r e
O p p or tu n i ts
c om m erc i al es i d en ti fi e s
PBS
Jo u r n a l
des
r isq u e s
V al i d at i on
D p l oi e m en t
et d e
Loc al i s ati on
Tb l x
de
b ord
P la n n in g
ch a r g e s
f in
C ah i ers
de
R ec e tt e
C o n c ept io n
P l an s d e
Fi c h es
P i l otag e
&
R c ap .
V ers i on s
A lp h a
P la n n in g
ch a r g e s
p h a se
C L OT
F ich e
P ro j e t
B i l an
P h as e
R EA L
C l tu r e
M i s e en s er vi c e
Jo u r n a l
des
r isq u e s
P ro to typ e s
Bi la ns
&
Ac tio ns
R s ul ta ts
P QP
D v el op p e m en ts i n d u s tri al i s ati on
d on n es
P O INTS
-CL ES
P la n n in g
ch a r g e s
p h a se
L A NC T
F ich e
P ro j e t
S p c i fi c ati on s
CL O T U R E
CL O T U R E
P ro du it
V al i d at i on s & Tr an s fer t s
d e c on n ai ss an c es
P la n n in g
ch a r g e s
OB S
L A NCE M E NT
L A NCE M E NT
c o m ple t
& s uppo rt
pr t
D vp t & t es ts
B i l an
CR
P h as e
ru n i on s
EV A L
Et u d e d e fai s ab i l it
I m p l i c ati on
C l i en ts
P REP A RA TIO N
P REP A RA TIO N
L iv ra b le s
&
P e rf o rm a nc e s
S p c i fi c ati on s
Jo u r n a l
des
r isq u e s
B i l an
CR
P h as e
ru n i on s
I NI T
R E A L I SA T I O N
R E A L I SA T I O N
D la is
&
Co nte nus
Be s o i ns
&
Ca pa c it s
C ad r ag e d u p r o jet
F ich e
P ro j e t
(d r a f t )
Et u d e d O pp o r tu n it
SP E CI F I CA T I O N
SP E CI F I CA T I O N
Tou s p b s v oq u s ou
ren c on t rs p en d an t l e
p roj et d oc u m en ts
P rvi s i on s d e v en t es
c on fi r m es
VLR
N i ve au x d e
p erf or m an c es
c on f or m e s au x
ob jec ti fs
Tr a ab i l i t d u rs u l ta t
/s p c i fi c ati on s
120
LN R
Tou s d o c u m en ts rel a ti fs
au p roj et arc h i vs ou
d tru i t s
Tou tes ac ti on s
en tr ep r en d re i d en ti fi es
et s t atu es
FP R

MPP Management Par Projet

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MPP Management Par Projet

Transféré par

Droits d'auteur :

Formats disponibles

QMS

PROJECT MANAGEMENT GUIDELINES

Rfrentiel de gestion de projet - MPP - Management Par Projet

Document created using procedures from the QMS guidelines

Fleury Didier - CIO

CMMI Capability Maturity Model Integration

Rfrentiel de gestion de projet - MPP - Management Par Projet

FIELD OF APPLICATION ......................................................................................................................... 6

GENERAL PRESENTATION OF MANAGEMENT BY PROJECT ..................................................... 7

DEFINITIONS OF FUNCTIONS AND ROLES ..................................................................................... 14

PROJECT AUTHORITIES ....................................................................................................................... 27

Rfrentiel de gestion de projet - MPP - Management Par Projet

Impacts on the hierarchical authority of the Project Managers supervisor ................................ 29

MANAGEMENT BY PROJECT PROCESS ........................................................................................... 31

QUALITY ASSURANCE PROCESS ....................................................................................................... 52

ENGINEERING AND SUPPORT PROCESSES .................................................................................... 61

DELIVERABLE PROJECT DOCUMENTS ........................................................................................... 90

Rfrentiel de gestion de projet - MPP - Management Par Projet

MANAGEMENT BY PROJECT AND CMMI ...................................................................................... 108

THE CMMI REFERENCE FRAMEWORK .................................................................................................. 108

REFERENCES .......................................................................................................................................... 118

LIFE CYCLE SYNOPSES ....................................................................................................................... 119

Rfrentiel de gestion de projet - MPP - Management Par Projet

1.2 Basic points about QMS

Improvement in the quality of developments;

1.3 Basic points about the document

Rfrentiel de gestion de projet - MPP - Management Par Projet

2 GENERAL PRESENTATION OF MANAGEMENT BY PROJECT

Rfrentiel de gestion de projet - MPP - Management Par Projet

A product is regarded as a permanent, generic offering that meets the requirements of a

3.2 Project Ownership

Development: This category includes any development of a new release of an existing

Rfrentiel de gestion de projet - MPP - Management Par Projet

3.4 Concept of criticity

Rfrentiel de gestion de projet - MPP - Management Par Projet

The level of criticity will affect the projects steering parameters.

3.5 Project organization

Product (in the broad product/program sense)

3.5.2 PBS (Product Breakdown Structure)

Rfrentiel de gestion de projet - MPP - Management Par Projet

Internal and external training support materials

"Marketing/commercial" deliverables 3.1

3.5.3 WBS (Work Breakdown Structure)

A software application module produced by developing one or more components: "Preliminary

Rfrentiel de gestion de projet - MPP - Management Par Projet

3.5.4 OBS (Organizational Breakdown Structure)

Rfrentiel de gestion de projet - MPP - Management Par Projet

Rfrentiel de gestion de projet - MPP - Management Par Projet

4 DEFINITIONS OF FUNCTIONS AND ROLES

4.1.2 Positioning and relational modes

4.1.2.1 Hierarchical authority

4.1.2.2 Operating authority

Rfrentiel de gestion de projet - MPP - Management Par Projet

4.1.3 Tasks and responsibilities

4.1.3.2 Establishing a reference

4.1.3.3 Progress tracking

Rfrentiel de gestion de projet - MPP - Management Par Projet

4.1.3.4 Reviews and Reports

Rfrentiel de gestion de projet - MPP - Management Par Projet

In-depth management of the overall project-management process, roles, procedures and

4.1.4.2 Managerial and performance-related capabilities

Exert non-hierarchical authority.

4.2 Work Package Manager

4.2.2 Positioning and relational modes