MPP Management Par Projet

7/25/2019 MPP Management Par Projet

1/120

QMS

PROJECT MANAGEMENT GUIDELINES


2/120

Rfrentiel de gestion de projet - MPP - Management Par Projet

Revisions

Date Revision Subject

Drafted by Approved by

April 01,2007

1.0 Document created using procedures from the QMS guidelines

Soudy EricQuality Director Fleury Didier - CIO

Reference documents

Title Origin Project

CMMI Capability Maturity Model Integration SEI CMMIMPPManagement By Project guidelines poster Company QMSMPPManagement By Project guidelines Company QMS
http://www.sei.cmu.edu/cmmi/general/general.htmlhttp://www.sei.cmu.edu/cmmi/general/general.htmlhttp://www.sei.cmu.edu/cmmi/general/general.html


3/120


TABLE OF CONTENTS

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

1.1 IDENTIFICATION....................................................................................................................................... 61.2 BASIC POINTS ABOUT QMS ............................................................... ....................................................... 6

1.3 BASIC POINTS ABOUT THE DOCUMENT..................................................................................................... 6

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

3

TERMINOLOGY ......................................................................................................................................... 8

3.1 PRODUCT/PROGRAM................................................................................................................................ 8

3.2 PROJECT OWNERSHIP............................................................. ................................................................. . 83.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) ............................................................ ..................... 123.6 GLOSSARY............................................................................................................................................. 13

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

4.1 PROJECT MANAGER............................................................................................................................... 14

4.1.1 Job description .............................................................. ................................................................ 144.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/120


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

5.3.3 Impact on the hierarchical authority of the Work Package Managers supervisor...................... 29

5.3.4

Positioning of Project Coordination and Project Quality ............................................................. 30

6 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 1Definition of the projects target.............................................................. ..................... 356.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

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

7.1 DESCRIPTION OF THE PROCESS............................................................................................................... 52

7.2 ROLES AND RESPONSIBILITIES........................................................... ..................................................... 527.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.......................................................................... 577.7.1 Date / Date Diagram (45 curve) ....................................................... ........................................... 57

7.7.2 S-curve .......................................................................................................................................... 58

7.7.3

Diagram of fault management 59


5/120


9.2 PROJECT QUALITY PLAN........................................................ .............................................................. .. 92

9.2.1 Document purpose ............................................................................. ........................................... 92

9.2.2

Document evolution....................................................................................... ................................ 929.2.3 Model ........................................................................... ............................................................... .. 93

9.3 RISK MANAGEMENT SHEET.................................................................................................................... 94


9.3.2 Document evolution....................................................................................... ................................ 94

9.3.3 Model ........................................................................... ............................................................... .. 949.4 STEERING SHEET.................................................................................................................................... 95


9.4.2 Document evolution....................................................................................... ................................ 95

9.4.3

Model ........................................................................... ............................................................... .. 96

9.5

OBS(ORGANIZATIONAL BREAKDOWN STRUCTURE) ........................................................ ..................... 97

9.5.1 Document purpose ............................................................................. ........................................... 979.5.2 Document evolution....................................................................................... ................................ 97

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 THE CMMIREFERENCE FRAMEWORK......................................................... ......................................... 108

10 2 REQM R M 110


6/120


1 FIELD OF APPLICATION

1.1 Identification

Project: QMSSubject: 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 Improvement in the quality of developments;o Respect of commitments;o Process for releasing new projects;o Better visibility of the departments activity;o Optimization of resource allocation as a function of priorities;o Better addressing of market expectations;o

Increased formalism between the teams that make up the group;o 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 aproject within the COMPANY group. This methodology was defined under the designation MPP for

M t b P j t


7/120


2 GENERAL PRESENTATION OF MANAGEMENT BY PROJECTThe goal of the projects for which the DSI is the general contractor is to permanently improveCOMPANYs competitiveness, either by:

o Enhancing its commercial offer in terms of products or of new capabilities, whether forgeneric or specific use, with the goal of acquiring new market shares and/or maintaining itscurrent positions, or by

o Transforming its internal organization or giving it methodological or software tools designed tostrengthen its productivity.

As part of this goal, Management By Project is a process designed to ensure that projects areundertaken which have the best possible fit with the companys strategic objectives, and that the risksincurred are identified and managed.

Activities that involve insignificant expenses or present a low degree of risk can be considered to beprojects 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 numerousdepartments 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, iscommonly designated by the term project portfoliomanagement, shortened to "management byproject".

Management by project is intended to identify, evaluate, prioritize and manage projects in progresswithin the corporation, using a set of methods consisting of verifying that the projects that thecorporation decides to undertake are in agreement with its strategic objectives and lead progressively


8/120


3 TERMINOLOGY

3.1 Product/Program

"Product" shall be taken to mean:

o All parts of COMPANYs market offerings, as well as those of its subsidiaries, that have or willhave a permanent presence over time, and whose development is governed by an outlinedocument or a multi-yearroadmap.

o Any service provided.o 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 genericand 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 inresponse to a customers specificneeds.

The "roadmap" shall include all improvements expected for the product, in successive releases. Theseare major developments that involve the companys strategy as well as Companys position as asolution provider in the pharmaceutical and medical fields.

Sometimes a group of projects that combine to bring about a given strategic objective, in the samelocation or in geographically distinct locations, and/or which do not necessarily lead to the emergenceof a new product offering, can be designated by the term program (of investments).

A d t i di ti i h d f elease i th th t


9/120


Companys clients and prospects can request that additional work be done beyond thestandard context of a software product. This may involve improvements or adding new

features. This may also involve the DSI s participation in the startup of the applicationsoftware 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, theSteering 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 shortdevelopments with an impact on resource scheduling. These minor corrections andimprovements are deliverable in the form of patches, service packs or complete applications.

Since these activities concern impromptu developments in response to operatingrequirements; they cannot be planned or managed according to the same formalism asdevelopments or creations, and shall be subject to specific procedures that are less stringentas related to size and associated risk level. Certain regular or basic tasks fall into the scope ofan 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.

o R&D: This category includes all activities of research, technological experimentation or tooltesting, including all initiatives for documentation, awareness or internal training. Theseactivities are associated with a design or development project, are of a prospective naturethat is independent of a given project, or are executed to produce a result applicable tomultiple projects.

3.4 Concept ofcriticity

Beyond the "product," "project ownership" and "category criteria is the concept of project criticity.

M f t d t l t th l l f iti it b th lit ti d tit ti d i l i


10/120


The level of criticity will affect the projects steering parameters.

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

3.5 Project organization

3.5.1 Project referencingThe term "project" shall be used to designate any development in the products/services offered byCOMPANY 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 ofexisting 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 givenclient, 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 objectivethat are clearly identified. A Project Manager is assigned to it, who is responsible for productioncoordination for all deliverables and for the organization and proper execution of all tasks andparticipants involved in the execution of the project, from inception to completion. Implicitly, thismeans that a project includes not only tasks related to software development, but also allcommunication, documentation and industrialization activities upstream or downstream from theproduction of the software.

N t Th l f th P j t M i di ti t f th t (th ) f t( ) t h i l l d ( )


11/120


PBS typeLevel 1 Description Level 3 Description

1 Project file 1.1 Economic documentation

1.2 Project Documentation

1.3 Development Cycle

1.4 Launch

2 "Product" deliverables 2.1 Software

2.2 Packaging (PC/PDA/HOST)

2.3 Packaging Documentation2.4 Documentation

2.5 Internal and external training support materials

3 "Marketing/commercial" deliverables3.1 Pamphlets

3.2 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 deliverablesthat a project is likely to produce. The Project Manager is responsible for identifying, at the start ofthe project, the PBS type elementsthat he will select for his project.

3 5 3 WBS (W k B kd St t )


12/120


WP Title Managing entity Project OBS

WP00 Project management PRO "Project" cell

WP01 "Upstream" Marketing MOA/PSP Product SpecificationWP02 Engineering studies DSI/BET DSIEngineering Design Department

WP03 Developments DSI/DEV/DATA DSI - Data Development

WP04 Developments DSI/DEV/TM DSI - TM Development Teams

WP05 Developments DSI/DEV/PDA DSI - PDA Development Teams

WP06 Developments DSI/DEV/OTC DSI - OTC Development

WP07 Developments DSI/DEV/ATL DSIATLAS Development

WP08 Developments DSI/DEV/ONE DSI - ONE UP

WP09 Validation DSI/DDO/REC DSIAcceptanceWP10 Industrialization DSI/DDO/IND DSI - Industrialization

WP11 Support materials MOA/PRD Product Release Department

WP12 Documentation MOA/STC-ITS STC/ITS

WP13 "Upstream" Marketing MOA/MKT 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 willcustomize his OBS by indicating:

o The choice of players for the project starting with a generic proposalo 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 projectprogresses. It constitutes an appendix to the Project Quality Plan (in particular, the Project Manager

t h t t li k f th PQP t th OBS)


13/120


3.6 GlossaryAbbreviation DefinitionAQ Quality AssuranceBU Business UnitCdCF Functional SpecificationsCheck-list Verification tool for a process or product, used by QACML Configuration management leaderCMPL Configuration management plan

CODIR Management CommitteeCOPIL Steering CommitteeCOTS Commercial Off-The-Shelfor product from the catalogCP Project ManagerCRML Change request management leaderDDO Operations DepartmentDRH Human Resources DepartmentDSI Information Systems DepartmentEBF Emergency Bug Fix

MOA Project ownershipMOE Project managementMPP Management By ProjectMTF Functional tracking matrixNC Non-complianceOBS Organizational Breakdown StructurePBS "Product Breakdown Structure"PQP Project Quality PlanPV Minutes


14/120


4 DEFINITIONS OF FUNCTIONS AND ROLES

4.1 Project Manager

4.1.1 Job description

The goal of the Project Managers positionis leadership of the project in its entirety (from definition ofits objectives to release of the solution and closure), according to the process and tools defined forthis 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, andin 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 inthe Terminology. It appears at the start of the project after the designation of the Project Managerand disappears at the end of the project.

4.1.2.1 Hierarchical authorityDepending 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 theproject owner; or

o an employee of the project owner, assigned by the projects initiator in accordance with hishierarchy and with the DSI development manager.

o

In all cases, the Project Coordinator must be informed of this assignment.


15/120


an end-phase milestone has been reached, and have this decision confirmed a priorior a posterioribythe authority involved.

4.1.3 Tasks and responsibilities

4.1.3.1 Definition of project target

o Define the projects scope in compliance with project ownership and the hierarchicalsupervisors of the mobilized participants.

o Identify the deliverable elements of the project (PBS) in association with project ownershipand the Work Package Managers.

o Coordinate and check the definition, planning (without constraint on resources for the firstpass) 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).

o Consolidate these elements over the entire project to the end (milestones) after confirmingtheir validation in compliance with the defined cycles.

o 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 allprocedures in force.o Obtain the cooperation of the project owner, project authorities and various hierarchical

supervisors regarding the elements listed above, in compliance with the defined validationcycles.

4.1.3.2 Establishing a reference

o Ensure that the various work packages are correctly supplied with resources (human andmaterial resources, capabilities):

di t th ll ti f il bl f ti iti i i ti ith


16/120


o Process exception reports (major alteration or crisis) submitted by the Work PackageManagers, working with the projects authorities, Project Coordinator and hierarchical

supervisors, depending on the case.o Validate the results produced by the work packages and monitor their validation in compliance

with the defined cycles.o Ensure that the procedures in force are respected by the various players, in compliance with

the quality plan.o Identify and qualify the sources of submitted or potential modifications and ensure that they

are monitored.

4.1.3.4 Reviews and Reports

o Organize and conduct phase-end reviews (reaching a milestone) as part of a meeting (regularor special) of the authority indicated by the authority chart:

o Collection and monitoring, in cooperation with the Project Quality Manager, of thecompletion and full validation of the documents required for reaching themilestone (deliverables for the phase being completed and project managementelements for the following phase);

o Report on the reservations and actions to be taken that were decided at the timethe previous milestone was reached;

o Transmission of decision-making elements to the members of the authorityinvolved;

o Leading the review.o Upon request from Work Package Managers, participate in progress reviews conducted per

work package.o Organize and lead Steering Committee reviews (project progress tracking, deliverables to be

validated, difficulties encountered and conflicts to be resolved).o 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

C i d h h ll i d


17/120


4.1.4 Capabilities

4.1.4.1 Methodology capabilities

o In-depth management of the overall project-management process, roles, procedures andtools.

o Superficial knowledge (on an overview level) of the procedures and conditions foraccomplishing all the tasks included in the project.

o Overall vision of the organization, potential resources and their technical capabilities.

4.1.4.2 Managerial and performance-related capabilities

o Exert non-hierarchical authority.o Mobilize resources and launch a project or tasks.o Provide training as needed in methods, procedures and tools.o Perform intermediate tracking.o Prepare reports (diagnostic and plans of action).o Chair meetings in different positions (subordinate, equal-to-equal, authority)o Manage conflicts and negotiate in these same positions.o 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.

H h ll b ibl f h i i ki d fi i f h i f ll


18/120


4.2.2.2 Operating authority

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 ProductManagement 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 projectsdeliverables;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 exercisedby the Steering Committee, of which he is a member.


4.2.3.1 Definition of the target

o Assimilate the scope and content of the project, its objectives and its organization.

o Identify the deliverable elements in his work package, working with the Project Manager andproject owner.

o Provide the definition, planning (without constraint on resources for the first pass) andbudgeting (man-days and other expenses) of his work packages tasks by phase , incoordination 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).S b h l h f l d d l d


19/120


o Produce tracking elements (management chart, steering sheet) and submit them to theProject 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 orparticipate directly in the performance of certain tasks/deliverables and/or provide regulartechnical expertise.

4.2.3.4 Reviews and Reports

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.o Submit to the Project Manager all information that may be useful to the preparation and

performance of Phase-end reviews (reaching a milestone).o Formalize and present an update on progress, difficulties encountered and requests for

conflict resolution during Steering Committee reviews.o Participate, during these Steering Committee reviews, in decision-making and in defining any

future plans of action.o Inform his team of all decisions made during Phase-end, Steering Committee and Product

Management Committee reviews, and ensure that they are carried out.


20/120


o Manage conflicts and negotiate (in a position of authority or between equals).o 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 thechapter).

4.2.5.1 "Upstream Marketing" work package

o Definition of the projects scope and objectives, from an "economic" point of view (marketstudy, opportunity study, request for intervention) as they relate to a generic or customer-specific need.

o Preparation of the launch strategy and project constraints associated with it (for exampledeployment plans, translation needs).

o Definition and formalization of functional specifications (improvements/corrections to bemade, configuration requirements, operating environments required, etc.).

o Definition of any possible modeling/prototyping needs.o Validation of models/prototypes presented.

4.2.5.2 "Development" work package

o Preparation and formalization of operating specifications based on the specifications validatedby the MOA.

f


21/120


Project Quality Manager is designated per project, although the same employee can assume thisfunction for several projects simulatenously.

4.3.2.1 Hierarchical authorityThe function of Project Quality Manager is entrusted to either;

o A Quality-Safety division employee upon proposal by the Project Manager and after validationby the Quality-Safety division manager; or

o An employee in another DSI division upon proposal by the Project Manager and aftervalidation 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 whichhe is participating, retain his permanent hierarchical position.Nevertheless, the authority of the hierarchical supervisor of the Project Quality Manager co-exists, fortasks that are part of the PQMs function, with the operating authority of the Project Manager and theoperating authority exercised collectively by the projects decision-making authorities.

Likewise, barring a decision to the contrary from his hierarchical supervisor, the employee acting asProject Quality Manager retains his hierarchical authority and his other functions in full throughout theduration of the project.

4.3.2.2 Operating authorityAs indicated earlier, the Project Quality Manager is subject to the collective operating authority of theprojects decision-making authorities, i.e., the Steering Committee and the Product ManagementCommittee.He is likewise subject to the operating authority of the Project Manager with regard to tracking theprogress 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


22/120


o Periodically formalize and submit to the Quality-Safety division manager, reports regardingdifficulties encountered during the project and non-compliances that cannot be resolved

within the scope of the project.

4.3.4 Capabilities

4.3.4.1 Methodology capabilities

o In-depth understanding of the overall project management process and its related roles,procedures and tools.

o Superficial knowledge of the procedures for all tasks included in the project.o In-depth knowledge of the pre-requisites and conditions for completing these same tasks.o Mastery of quality assurance principles to be implemented during software development

projects for internal and external use.o Overall vision of the organization, resources and capabilities available within the various

entities that can be mobilized for projects.

4.3.4.2 Managerial and performance-related capabilitieso Communicate, in writing and orally, including to people with limited capabilities in his own

areas of expertise (ability to communicatein laymans terms).o Provide training as needed in methods, procedures and tools.o Prepare and file reports (diagnostic and plans of action) in various positions (equal-to-equal,

operating authority relationship).

4.4 Project Coordinator



23/120


The Project Coordinator may act alone, as needed, on behalf of a group by delegation of the ProductManagement Committee.


o Maintain the Management By Project process and the reference materials associated with it(documentation, available tools, communication and training support materials involved in theprocess), specifically based on phase-end and project-end reports.

o 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.

o Participate in selecting sub-contractors, providing an overall vision of their quality of service

and their capabilities.o Contribute to decisions and conflict resolution during Product Management Committee

meetings.o Collect the various project tracking elements (steering committee presentations and meeting

minutes) and prepare overall multi-project tracking (shown with charts).o 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 QualityManager. As part of this, the Project Coordinator must, insofar as is possible, work with theProject 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 ManagementCommittee or initiate an escalation procedure for conflict resolution by the directingauthorities.

o Inform and communicate regarding the Management By Project process in general as well asthe projects themselves.

4.4.4 Capabilities


24/120


4.5 Configuration Management Leader

4.5.1 Description of the role

The Configuration Management Leader (CML) is the administrator in charge of project configurationmanagement.

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 heorganizes the implementation of the CMS (Configuration Management System) by performing thefollowing actions:


25/120


The CML analyzes the content of the CMS to check the correlation between what is actually in it andwhat 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 integrityThe CML organize updates for tools from other systems:

The change request management system must make reference to the new "baselines" so thatrequests 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 SteeringCommittee (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 requestof the Project Manager and with the employees acceptance.

4.6 Change Request Management Leader

4.6.1 Description of the role


26/120


4.6.2.4 Perform change request management audits

Implement change request management audits to guarantee proper process managementand 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 externalvisibility requests are made regarding the project.

Analyze the contents of the CRMS to ensure the correlation between what is actually in it andwhat 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.5Act according to planned tasks

Announce releases and distribute requests among the various processing managers (RESP-

TRT). 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.


27/120


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 consistsof 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 projectsubmitted by the Project Manager: objectives/orientations, scope, contents and projectcriticity (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 aspreparation of corresponding plans of action.


28/120


o 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 primarytasks, 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. Inthis regard, it can be led to define priorities between the various projects, with correspondingresolution of resource conflicts.

o Validation or return for adjustment of plans of action developed by the Steering Committeesfor handling major difficulties encountered (sticking points, crisis situation, etc.).

o Authorization to reach a project milestone (according to the defined authority chart) withregard to the elements submitted to it by the Project Manager (simple or conditionalauthorization) with possibility of a priorior a posterioriauthorization.

o Validation of end-of-phase and end-of-project reports tracking of the corresponding plans ofaction.

o As manager of the product life cycle (encompassing the project life cycles), determination ofthe end of the product, allowing the project elements to be archived.

The Product Management Committee may routinely decide to delegate one of its responsibilities toany individual (for example to a Project Manager or to the Project Coordinator) or committee (for


29/120


5.3 Impacts on standard hierarchical relationships

5.3.1 Diagram of established relationships (not including Project Coordination andProject Quality)

Productmanagement

Inter-projects

Full valid

O eratin

SteeringCommittee

Pro

Work PackageManager

Deliverable validation

ro ress trackin

ProjectManager

Steering for collective progressdecisions and arbitration includingvalidating deliverables and passingmilestones

Steering for progressdecisions and

arbitration includingassin milestones

HirarchiqueWPM

PMs

supervisor

Hierarchical

Designatio

DesignationAllocation of project resourcesValidation of key deliverables(projects, development cycle,products)

DsignationValidation of key projectmanagement deliverables(project sheet, schedule,resource acquisition plan,steerin sheet, ro ect reviews

The PMs supervisor is usually a

member of the CODIR


30/120


o 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.o On the other hand, authority over "work package control" is primarily assured

operationally by the Project Manager and the project authorities, to whom the WPMreports and from whom he receives conflict resolutions and other decisions associatedwith 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 andCODIR project reviews) as well as decision statements.

o ON the other hand, he participates in the Steering Committee only when he is himselfa Project Manager and does not fully participate in the Product ManagementCommittee.

o Since he has no hierarchical or operating association with the Project Manager andthe authorities, he must express any disagreements with their decisions and conflictresolutions using his own hierarchical line which is itself represented to the ProductManagement Committee.

5.3.4 Positioning of Project Coordination and Project Quality

The Project and Project Quality Coordinator (Project Quality Manager or manager of the Quality-Safetydivision) both have a duty to alert and to escalate if they detect any difficulties or malfunctions whichare 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, andthat is included in his job description. Because of its "neutrality", this role can also, to a certain extent,be played by Project Quality.


31/120


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. Eachphase is concluded by a review meeting to evaluate the projects performance with regard to itsobjectives, and decide upon its continuation. This review takes place when a milestone is reached thatindicates the projects maturity status.

Reaching every milestone is conditional upon:

o The production of certain deliverables or management documents,o 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 theproject.It is concluded by the BSR (Business Review) milestone, which marks agreement on theeconomic relevance of the project.

EVALUATION, abbreviated EVAL


32/120


LAUNCH, abbreviated LAUNCH

This phase covers all the marketing, commercial and customer relations operationssurrounding the market introduction of a new product or new release: press activities,conferences, user training. Note: the processes of installation, configuration, updating clientconfigurations 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 beencompleted and that the release is now in full operation.

CLOSING, abbreviated CLOSING

The purpose of this phase is to produce a technical and organizational reporton the project,in order, primarily, to take stock of difficulties encountered and suggest directions fordevelopment 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:

DEFINITIONREVIEW

INITialization

Definition of theopportunity

EVALuation

Initial decision aboutinterest and feasibility

SPECification

Precise Identificationof content & finaldecision

EXECution PREParation

BUSINESSREVIEW

FEASIBILITYREVIEW


33/120


6.2 Authority ChartsThe validation of each of the milestones presented above is subject to the approval of a specificauthority, who thus assumes the responsibility for authorizing a project to reach an end-of-phasemilestone.

This authority is predefined for each milestone as a function of the product/program associated withthe project, its project owner, its category and its level of criticity.

Four responsibility levels have been identified at the COMPANY in project management:

MOAIndividual representative of the Project owner: PSP Director, Product Manager,Marketing Manager, DSI Manager

PMProject Manager, in general an authorized representative of the MOA or of the DSI:BET, DDO, Developments

CoPilSteering Committeeof the project consisting of the Project Manager, work packagemanagers, and a quality manager, including, if applicable, representatives of clients orof project ownership

CoDir Management Committeefor "products" consisting of DSI and project ownershipexecutives

Note: a responsibility can be transferred routinely to any committee or individual acting by delegationfor one of the authorities named above.

The chart below defines the levels of responsibility required to validate the achievement of amilestone, depending on the category and criticity of the project being considered.


34/120


MOA Creation Update Maintenance/R&D

INIT MOA MOA MOA/PM

BSRSubsidiary/Product MOA / PM MOA / PM

PMSubsidiary/Client MOA MOA

Internal MOA/PM MOA/CP

FSRSubsidiary/Product

CoDir

CoDirCoPil

Subsidiary/Client CoDir

Internal CoPil (*) PM

DFRSubsidiary/Product CoDir CoPil (*)

PMSubsidiary/Client CoPil (*)

Internal CoPil (*) PM (*)

EXRSubsidiary/Product CP PM

PMSubsidiary/Client CoPil CoPil

Internal CP CP

VLRSubsidiary/Product

CoDirCoPil (*)

CoPilSubsidiary/Client CoPil (*)

Internal CoPil (*) CoPil (*)

LNRSubsidiary/Product

CoPil (*)

CP (*)

PMSubsidiary/Client CoPil (*)

Internal PM (*)

FPRSubsidiary/Product

PMSubsidiary/Client

Internal


35/120


Step 3 Track progress: This step evaluates the performance of the project from twodifferent 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 & intermediatemilestones).

3.2 Tracking project progress (deliverables & end-of-phase milestones)3.3 Tracking and summary of time elapsed3.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 ofthe project itself. During these steps, reports and reviews are prepared. They consist of thefollowing procedures.

4.1 End-of-phase review (milestone reached)4.2 Steering Committee review4.3 Product Management Committee review4.4 End-of-phase report4.5 End-of-project report

These steps will be detailed in the following paragraphs.

6.3.1 STEP 1Definition of the projects target

6.3.1.1 Step 1.1: Definition of the projects scopeThis procedure consists of the following steps:


36/120


37/120


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 thePBS. 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. Thedetailed WBS is established progressively, phase-by-phase, as the components to be produced areindicated and specified.

The lowest level describes the nature of the activity to be performed and the component to which thework is applied.

At this level, it is appropriate to indicate the capabilities required and estimate the work load and thetime required to accomplish the task. This information allows a budgetary envelope to be calculatedfor each phase of the project.

1.3.1 Break down the work to be performed into a primary level (level 1) of work-packages coveringthe entire project, for example:

WP Title

WP00 Project management

WP01 "Upstream" MarketingWP02 Engineering studies

WP03 Database development

WP04 Development, Front office module

WP05 Validation

WP06 Industrialization

WP07 Development of training support materials

WP08 Documentation


38/120


1.3.7 Finally, assign a unit rate to each type of capability allocated to the task (optional). Addingthem at the project level will provide part of the components that constitute the projectsbudget, 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 fromthe lowest level of the WBS, in order to obtain detailed schedules and estimate a target duration foreach phase. At this stage we shall not yet preoccupy ourselves with availability of resources. Theexecution of this procedure is the responsibility of the Work Package Managers in close collaborationwith the Project Manager.

1.4.1 Introduce logical scheduling between the lowest-level tasks of the WBS. This logic is appliedby defining constraints associating the activities with each other. Four types of constraints canbe considered:

o End to Starto End to Endo Start to Endo Start to Start

These constraints may be instantaneous or cause positive shifts (lead time) or negative shifts(lag time) to appear.Example: End of designassociated 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


39/120


M17 Pre-production environment

M18 Production Environment

M19 User Documentations (copy)M20 External Training Plans and Support Materials

1.5.2 Identify the interdependency milestones that involve a constraint imposed by a factor that isexternal to the project.

Examples:

o Availability of a specific piece of equipment or environment (development, production)o Development Task conditional upon Acceptance of a New Server Tasko Integration of external software components

1.5.3 Position these milestones in the plans (tasks with no duration), ensure that they areacceptable 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 beforedistribution 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 theallocation and potential valorization of project resources. The execution of this procedure is theresponsibility 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 theWBS results in a task plan that is broken down into phases over time.


40/120


7. Identify palliative actions and these actions managers to be proposed in a summary, inresponse to weights of risks greater than 8 that correspond visually to the colors red andblack.

6.3.1.7.2Diagram of the risk management process

Identify context

Identify risksusing the checklist

Trackandm

cateandconsult

28/06/2007

Risk Management Process

Analyze risks

Determine probability

PDetermine impact

I

Estimate risk level (weight)

N = Px IRisk summary


41/120


weight of risk = probability x impact

Example:Analysis of risks in the sector: Management, organization andpartnership

Risk AnalysisManagement, organization andpartnership

Weight of risk=probability x impact

1-4low

5-8medium

9-12high

13-16critical

Action

+ + + - - -

Ref. Risk - probability from 1through 4

Note Impact from 1 through 4 Note Weight N

RSK01 Time required for results ofexperiments with prototype

2 Revision of specifications andbudgetary evaluations

4 8 1,3

RSK02 Non-synchronization of interfaceprojects (4)

4 Integration blocked, the teamis on hold, cost overruns andplan deviation (3)

3 12 2

Summary of risk analysis(= maximum of weights) 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 actionsnumbered 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 inthis way shall be grouped in the tracking chart.


42/120


6.3.1.7.5.3 Categorizing of actions

Every action proposed must correspond to one of the following types:

Communication actionThese actions allow opinions to be expressed, misunderstandings to be resolved, specific points in theproject to be clarified (roles, responsibilities, etc.). This can take place during meetings (briefstatement) or scheduled for later presentation.

Client requirements actionThese actions are an opportunity to explain to project management about the importance of a clientrequirement. The purpose of these explanations is to improve project quality by re-centering it aroundthe 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 riskcan be done in two ways. As with safety, we can speak here about "Active quality" and Passivequality.

Actions associated with "Active quality" allow the risk to be addressed before it even happens, bydecreasing the likelihood that it will occur (example: Action of training the project team to decreasethe 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 offailure to respect deadlines).

Risk-taking actionCertain risks cannot be decreased. They are in fact a characteristic of the project (example: risk of"lack of technological maturityfor a project based on XML technology if the standard does not lead toa stable revision). In this case, these risks must be explained to the project owner so that he maybetter understand them and, if they cannot be minimized, accept them.


43/120


o Development or consulting projects performed on a one-time basis by a third-partyorganization as part of a contract specifying the nature of the work to be performed.Here we are referring to sub-contracting.

o Third-party products selected for integration into an existing application or one that isunder development. Here we are referring to "OEM" or "ISV".

o 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 temporarystaffing is not part of the scope of application of this process.

Roles Responsibilities

ProjectManager /Manager of

VendorRelations.

Handles all the defined functions and responsibilities of the ProjectManager. As such, he plans and delegates the internal activities associated with themanagement of sub-contractors (drafting of the business case, drafting of thespecification 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 itscommitments with regard to the sub-contractor. Above all, he promotes the successful achievement of the sub-contractors objective in the interest of maintaining balance between the contractingparties. He manages change orders and any conflicts that may arise, with the


44/120


Start of process

Initiation

Preparation

Selection&

Contract preparation

Project Manager,Steering Commitee,Management Committee

and BET

Project Manager,Purchasing Manager,Steering Committee,Management Committeeand sub-contractor-

Transfer ofcapabilities& coaching

Project Managerand sub-contractor-t

Tracking & monitoring

Project Manager,Conference Manager,Steering Committee,and sub-contractor-

Make the decision to sub-contract;

Business case.

Draft specifications;

Prepare call for bids.

Make sub-contractor selection-

Sign the contract.

Provide sub-contractor with- sinformation and equipmentnecessary to participatein the project.

Track and monitor progress.Set up indicators.

Project Managerand Steering Committee

ManagementProject Managerand Steering Committee

Issue call for bids andmonitor responseto call for bids


45/120


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 timebeing considered for the activities in which they are to participate. If there is no precisecorrelation 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 thetarget 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 whichthese tasks must be performed. No scheduling margin should be announced. However, it isimportant that all the resources participating in critical-path tasks be notified of it, so as topromote good awareness of the impact of any possible delay. Project organization can thenbe 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 "baselinebudget" 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. Aproject always experiences unanticipated unknowns of various causes: inaccuracies in estimates,delays in availability of resources, risk occurrence, etc.


46/120


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 theProject 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 theproduction of new or alternative deliverables.

2.3.3 Update the WBS, schedules and especially milestones, after provisional tasks have beenincorporated.

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 theSteering 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 progressaccomplished in the completion of deliverables to be provided, and on the other hand, evaluating thework put into it.

6.3.3.1 Step 3.1: Tracking the progress of a work packageThe purpose of this procedure is to clarify how to evaluate the physical progress of the work


47/120


Example: in this case, the physical progress to be declared is 57%

contribution % progress % completedtask 1 2 100% 2%

task 2 5 100% 5%

task 3 5 100% 5%

task 4 5 100% 5%

task 5 10 100% 10%

task 6 10 50% 5%

task 7 10 50% 5%

task 8 20 50% 10%task 9 10 50% 5%

task 10 10 50% 5%

task 11 8 0% 0%

task 12 5 0% 0%

100 57%

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 thephysical 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 andthe Steering Committee decide arbitrarily, before the FSR milestone, what will be the total valueproduced by the project at the end of each phase.

Example:


48/120


6.3.3.4 Step 3.4: Re-estimation

Execution of this procedure is the responsibility of the Work Package Managers in cooperation withthe 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 theremainder of the project, it shall be the responsibility of the Work Package Manager to issuean 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 eveneliminate some deliverables and consequently update the PBS, in order for example to adhereto 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 ManagementCommittees or the Steering Committee to pass judgment on the achievement of an end-of-phasemilestone.

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 ManagementCommittee, 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


49/120


50/120


4.3.4 Each Project Manager shall prepare for the Management Committee meeting using the modelprovided for this purpose (Steering Sheet and Summary Sheet).

4.3.5 The Management Committee shall validate all proposed documents, deliverables or plans ofaction, pronounce reservations or postponements, and render any requested arbitrations.

4.3.6 The Management Committee meeting shall also allow the Project Manager to obtain formalvalidation from the Management Committee on the achievement of a milestone, either inadvance or a posteriori, when the date for reaching a milestone and a meeting of theManagement 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 foreach of the major management phases of a project. The purpose of this report is to improve both theproduction 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 theSteering 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 deliverablesto be supplied during the phase, deliverables actually provided, and difficulties encountered ifany.

4.4.3 During the meeting, he shall go around the table and ask each attendee to present the list ofdeliverables provided with regard to the objectives, explain any discrepancies observed andthen express what he feels to be positive or negative in the previous phase completed.


51/120


4.5.2 When preparing for this meeting, he shall take all the end-of-phase reports and consolidatethem into a project report:

o Any difficulties encounteredo Difficulties resolved during the projecto Unresolved difficultieso Actions agreed to in a phase report and completed during the projecto Actions agreed to in a phase report and not accomplished during the projecto 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 todocument the performance of the project with regard to contents, deadlines and baselinecosts. To this end, he shall assemble the following components:

o Project objectives, and the level to which these objectives were attained.o Deliverables produced vs. deliverables expected.o A document issued by the Project Quality Manager evaluating the quality of the

deliverables provided.o Schedules achieved vs. expected, indicating all milestones.o Costs incurred vs. planned.o Values of other key success indicators vs. objectives.o Any explanation related to analyzing and understanding any discrepancy.o 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 themeeting.


52/120


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 toimplement the Quality Assurance functionthroughout the lifetime of a project.

The primary objective of Quality Assurance (QA) is to accompany the project team, throughout thelifetime of the project, as project procedures and standards are implemented, and provide objectivevisibility 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 thatshall serve as a guide to the process and product evaluations.

7.2 Roles and responsibilities

Roles / Authorities ResponsibilitiesProject Manager (PM) Responsible for the achievement of project

objectives (external and internal quality) andfor measurement of these objectives.Defines or reviews and approves the qualityobjectives of the project.Reviews and approves the documentsprovided by quality assurance.Decides on and plans corrective actions.


53/120


7.3 Process Activities

SQA1Establish QA for

the project

Projectinitiation

SQA2Specific QA

activities

SQA3Process

evaluation

SQA4Product

evaluation

SQA5QA Reporting


54/120


Output Mgr. and approval

Project Quality Plan (PQP) Mgr: PM or PQMApprov.: CoPil

Project Schedule or Tracking Chart updated with QAactivities

Mgr: PQMApprov.: PM

7.4.2 Specific QA activities

SQA2 01: the PQM implements the activities defined during initialization and whosepurpose is the achievement of quality objectives. In particular, he assists the project team in

properly understanding the expected processes and deliverables, he assists in thedevelopment of certain documents, participates in project tracking meetings and, especially,contributes to quality updates. He participates in organizing the client audit and internal auditsas a function of requests made.

Inputs Status

Project Quality Plan (PQP) ValidatedStandards and procedures applicable to the project

Outputs Mgr. and approvalCommunication or training support materials Mgr: PQM

Approv.: PMAudit reports Mgr: PQM

Approv.: PM

7.4.3 Evaluation of processes


55/120


Outputs Mgr. and approval

Updated Project Schedule or Tracking Chart Mgr: PQMApprov.: PM

Review report: checklists completed Mgr: PQMApprov.: PM

Updated list of non-compliances Mgr: PQMApprov.: PM

Updated list of corrective actions (Project TrackingChart)

Mgr: PQMApprov.: PM

7.4.4 Evaluation of productsSQA401: The PQM regularly verifies the compliance of the projects products compared toapplicable standards; verification is conducted using checklists adapted to each product beingevaluatedSQA402: The PQM drafts a report of the review, has it validated by the participants anddistributes it to the stakeholders; non-compliances are listed, corrective actions are taken bythe PMSQA403: The PQM checks that corrective actions have been taken, and may decide on a

new review to formally ensure project compliance.

Inputs Status

Project Quality Plan (PQP) ValidatedProducts to be evaluatedProject Schedule or Tracking Chart Version from past reviewsList of non-compliances Version from past reviewsList of corrective actions in progress (Tracking chart)


56/120


Inputs Status

Report on process and product evaluations ValidatedProject Schedule or Tracking Chart ValidatedList of non-compliances ValidatedList of corrective actions in progress Validated


Project quality indicators Mgr: PQMApprov.: PM

Reporting support materials Mgr: PQMApprov.: PM

Quality Tracking Chart OQM

7.4.6 QA report

SQA601: the PM shall coordinate a project quality report with the teams and the PQM, ifapplicable as part of the project report; the quality report is focused on lessons learned,strengths and weaknesses associated with quality activities and processes.

Inputs StatusProject quality tracking documents Validated


Project quality report Mgr: PQMApprov.: PM

7.5 Reporting


57/120


Project objectives Project Measurements

Deadline management Date / Date DiagramCost management S-curveQuality management Diagram of fault management

Adherence to processes Results of process checklists

7.7 Definitions of standard project measurements

7.7.1 Date / Date Diagram (45 curve)

Graphic illustration:

Indicateur de jalons

01-mai-04

05-juin-04

10-juil-04

14-aot-04

18-sept-04

23-oct-04

27-nov-04

01-janv-05

05-fvr-05

12-mars-05

004

004

004

004

004

004

004

004

005

005

005

Lancement projet Jalon 1Jalon 2 Jalon 3Jalon 4 Jalon 5Fin de projet bissectrice


58/120


7.7.2 S-curve


Indicateur d'effort

0

300

600

900

1200

1500

1800

2100

Date1

Date2

Date3

Date4

Date5

Date6

Date7

Date8

Date9

Date10

Date11

Date12

Date13

Date14

Date15

Initial (nb

jours)

Ralis (nb

jours)

Re-estim

(nb jours)

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 Who: the Project Manager.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.

Measurement analysis:o


59/120


7.7.3 Diagram of fault management


Number of serious and critical faults

0

2

4

6

8

10

12

Mar-

05

Apr-

05

M

ay-

05

Jun-

05

Jul-

05

A

ug-

05

S

ep-

05

Oct-

05

N

ov-

05

D

ec-

05

Jan-

06

Feb-

06

Nbre total d'anomalies

Nbre d'anomalies rsolues

Number of major faults

100

120


60/120


7.7.4Adherence to processes


0

0.2

0.40.6

0.8

1

CHANGE - Gestion duChangement

CONF-Gestion deConfiguration

MPP-Management ParProjetsQUAL-Management de laQualit

REQM-Gestion desExigences

Description: for each process, percentage of adherence by the project.


61/120


8 ENGINEERING AND SUPPORT PROCESSES

8.1 Requirement Management Process

8.1.1 Presentation of the process

Top level

CdCF author (RCC)

RFS author (RSP)

Acceptance designer(CREC)

All

CdCFCdCF

DSL DSL DSL

MTF MTF MTF

Expr. of needDivers

MKT

CdCF

MTF

Development designer(CDEV)


62/120


Role Definition

Author ofRequestors

Specifications (ARS)

Project Owners employee, writes the requestors functional specifications

Author of FunctionalSpecification (AFS)

Writes the specification document using the requestors functional specifications

Acceptance Designer(ACCD)

Writes the test plan and scenarios using the specification document

DevelopmentDesigner(DEVD)

Writes the software design document using the specification document

Ergonomics In

Documents

MPP Management Par Projet