MPP Management Par Projet

QMS PROJECT MANAGEMENT GUIDELINES MPP - MANAGEMENT PER PROJECT

Référence: DOC-MPP-ManagementParProjet-EN.doc

V 1.0

1

Référentiel 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

2

Référentiel de gestion de projet - MPP - Management Par Projet

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

2

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

3

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

4

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 Positioning and relational modes.................................................................................................. 17 4.2.3 Tasks and responsibilities ............................................................................................................. 18 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 Positioning and relational modes.................................................................................................. 20 4.3.3 Tasks and responsibilities ............................................................................................................. 21 4.3.4 Capabilities ................................................................................................................................... 22 4.4 PROJECT COORDINATOR ........................................................................................................................ 22 4.4.1 Job description .............................................................................................................................. 22 4.4.2 Positioning and relational modes.................................................................................................. 22 4.4.3 Tasks and responsibilities ............................................................................................................. 23 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

5

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

3

Référentiel de gestion de projet - MPP - Management Par Projet

5.3.2 5.3.3 5.3.4 6

Impacts on the hierarchical authority of the Project Manager’s supervisor ................................ 29 Impact on the hierarchical authority of the Work Package Manager’s 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 project’s target ................................................................................... 35 6.3.2 STEP 2: Definition of the project reference .................................................................................. 44 6.3.3 STEP 3: Tracking the project’s 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 ................................................................................................................ 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

8

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

9

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

4

Référentiel de gestion de projet - MPP - Management Par Projet

9.2 PROJECT QUALITY PLAN ........................................................................................................................ 92 9.2.1 Document purpose ........................................................................................................................ 92 9.2.2 Document evolution....................................................................................................................... 92 9.2.3 Model ............................................................................................................................................ 93 9.3 RISK MANAGEMENT SHEET .................................................................................................................... 94 9.3.1 Document purpose ........................................................................................................................ 94 9.3.2 Document evolution....................................................................................................................... 94 9.3.3 Model ............................................................................................................................................ 94 9.4 STEERING SHEET .................................................................................................................................... 95 9.4.1 Document purpose ........................................................................................................................ 95 9.4.2 Document evolution....................................................................................................................... 95 9.4.3 Model ............................................................................................................................................ 96 9.5 OBS (ORGANIZATIONAL BREAKDOWN STRUCTURE) ............................................................................. 97 9.5.1 Document purpose ........................................................................................................................ 97 9.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 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

5

Référentiel de gestion de projet - MPP - Management Par Projet

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 department’s 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 SEI’s 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

6

Référentiel de gestion de projet - MPP - Management Par Projet

2 GENERAL PRESENTATION OF MANAGEMENT BY PROJECT The goal of the projects for which the DSI is the general contractor is to permanently improve COMPANY’s competitiveness, either by: o

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 company’s 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

7

Référentiel de gestion de projet - MPP - Management Par Projet

3 TERMINOLOGY 3.1 Product/Program "Product" shall be taken to mean: o

o o

All parts of COMPANY’s 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 customer’s specific needs. The "roadmap" shall include all improvements expected for the product, in successive releases. These are major developments that involve the company’s strategy as well as Company’s 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

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.

o

Development: This category includes any development of a new release of an existing product, or any extension of an existing product made to a client’s specific requirements.

COMPANY/DSI

8

Référentiel de gestion de projet - MPP - Management Par Projet

Company’s 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 DSI’s 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.

o

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

9

Référentiel de gestion de projet - MPP - Management Par Projet

The level of criticity will affect the project’s steering parameters. The level of criticity is subject to modification depending on the project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

PBS type Level 1 Description 1 Project file

2

"Product" deliverables

3

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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 "Upstream" Marketing

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

4 DEFINITIONS OF FUNCTIONS AND ROLES 4.1 Project Manager 4.1.1 Job description The goal of the Project Manager’s 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 Manager’s 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 project’s 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 Manager’s hierarchical supervisor co-exists, for tasks that are part of the Project Manager’s 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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

o

Define the project’s 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 project’s 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

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

Référentiel de gestion de projet - MPP - Management Par Projet

o

o o o

Process exception reports (major alteration or crisis) submitted by the Work Package Managers, working with the project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 4.2.1 Job description 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.

4.2.2 Positioning and relational modes 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.

4.2.2.1 Hierarchical authority 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 employee’s 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 WPM’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

4.2.2.2 Operating authority The Work Package Manager shall be subject to the collective operating authority of the project’s 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 project’s 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 Tasks and responsibilities 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 package’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 4.2.4.1 Methodology 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).

4.2.4.2 Managerial and performance-related capabilities o o o o o

COMPANY/DSI

Mobilize resources and initiate tasks. Provide training as needed in methods, procedures and tools. Perform intermediate tracking. Prepare reports (diagnostic and plans of action). Chair meetings (in a position of authority).

19

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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 4.3.1 Job description 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.

4.3.2 Positioning and relational modes 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 project’s closure phase has been completed. Just one

COMPANY/DSI

20

Référentiel de gestion de projet - MPP - Management Par Projet

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

4.3.2.1 Hierarchical authority 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 PQM’s function, with the operating authority of the Project Manager and the operating authority exercised collectively by the project’s 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.

4.3.2.2 Operating authority As indicated earlier, the Project Quality Manager is subject to the collective operating authority of the project’s 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.

4.3.3 Tasks and responsibilities 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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

o

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 4.3.4.1 Methodology 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.

4.3.4.2 Managerial and performance-related capabilities o o o

Communicate, in writing and orally, including to people with limited capabilities in his own areas of expertise (ability to communicate “in layman’s terms”). Provide training as needed in methods, procedures and tools. Prepare and file reports (diagnostic and plans of action) in various positions (equal-to-equal, operating authority relationship).

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

4.4.2 Positioning and relational modes 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.

4.4.2.1 Hierarchical authority 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.

4.4.2.2 Operating authority 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

4.4.3 Tasks and responsibilities o

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 4.4.4.1 Methodology 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.

4.4.4.2 Managerial and performance-related 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 layman’s 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. Prepare reports (diagnostic and plans of action). Chair meetings in various positions (subordinate, between equals, authority). Manage conflicts and negotiate in these same positions.

23

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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 project’s 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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 employee’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 employee’s agreement.

COMPANY/DSI

26

Référentiel de gestion de projet - MPP - Management Par Projet

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 owner’s 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 owner’s directors; o The Project Coordinator;

COMPANY/DSI

27

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 PM’s supervisor member of the CODIR

is

usually

a

Inter-projects

Steering for progress decisions and arbitration including passing milestones

Steering Committee

PM’s supervisor Désignation 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

Hiérarchique 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 Manager’s supervisor o

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 Manager’s 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 project’s 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 Manager’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

o

o

The Work Package Manager’s 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 WPM’s 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 Management 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-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

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s performance with regard to its objectives, and decide upon its continuation. This review takes place when a milestone is reached that indicates the project’s 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 COMPANY’s strategic orientations, its capabilities and the foreseeable return on investment. It is concluded by the FSR (Feasibility Review) milestone, which indicates agreement about the project’s feasibility. SPECIFICATION, abbreviated SPEC The purpose of this phase is to define the project’s precise content and decide on its technical choices. It is concluded by the DFR (Definition Review) milestone, which indicates agreement about the project’s 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 project’s 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 project’s validation and the fact that the entire organization is ready to market and support the release.

COMPANY/DSI

31

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s target 6.3.1.1 Step 1.1: Definition of the project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 "Upstream" Marketing 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 user’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

P

I

Estimate risk level (weight)

N=P

x

I

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

Référentiel de gestion de projet - MPP - Management Par Projet

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)

4

Integration blocked, the team is on hold, cost overruns and plan deviation (3)

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

3

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 reader’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 client’s 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 company’s 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 project’s requirements in its development plan. The vendors referred to here belong to specific categories. These are:

COMPANY/DSI

42

Référentiel de gestion de projet - MPP - Management Par Projet

o

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-contractor’s 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 subcontractor’s 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-contractor’s performance in the organization’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

Start of process

Project Manager and Steering Committee Project Manager, Steering , Commitee Management Committee and BET Project Manager and Steering Committee Project Manager, Purchasing Manager, Steering Committee, Management 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 client’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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: 0–100%: the task remains at 0% progress as long as the corresponding deliverable is not validated by the work package manager. 0–X–100% 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 Committee’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 Management Committee.

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

Output Project Quality Plan (PQP) 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 Project Quality Plan (PQP) 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 Quality Plan (PQP) Project documents from the processes evaluated Project Schedule or Tracking Chart 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 Version from past reviews

54

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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 Project Quality Plan (PQP) Products to be evaluated Project Schedule or Tracking Chart 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

Version from past reviews Version from past reviews

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 organization’s Quality Tracking Chart.

COMPANY/DSI

55

Référentiel de gestion de projet - MPP - Management Par Projet

Inputs Report on process and product evaluations Project Schedule or Tracking Chart 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

Référentiel de gestion de projet - MPP - Management Par Projet

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-févr-05 01-janv-05 27-nov-04 23-oct-04 18-sept-04 14-août-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 project’s 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 Who: the Project Manager. o When: at COPIL and CODIR meetings. o How: formalized in the COPIL and CODIR meeting minutes.

COMPANY/DSI

57

Référentiel de gestion de projet - MPP - Management Par Projet

7.7.2 S-curve 

Graphic illustration:

Indicateur d'effort 2100

Initial (nb jours)

1800 1500

Réalisé (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

7

D

at e D

6

at e D

5

at e D

4

at e D

3

at e D

2

at e D

at e D

D

at e

1

0

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 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 Who: the Project Manager. o When: COPIL and CODIR meetings. o How: formalized in the COPIL and CODIR meeting minutes.

COMPANY/DSI

58

Référentiel de gestion de projet - MPP - Management Par Projet

7.7.3 Diagram of fault management 

Graphic illustration:

Number of serious and critical faults 12 10 8 Nbre total d'anomalies

6

Nbre d'anomalies résolues

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 résolues

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. Measurement analysis: 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 Who: the Project Manager. o When: in COPIL and CODIR meetings. o How: formalized in the COPIL and CODIR meeting minutes.

COMPANY/DSI

59

Référentiel de gestion de projet - MPP - Management Par Projet

7.7.4 Adherence to processes 

Graphic illustration:

CHANGE - Gestion du Changement 1 0.8 0.6 REQM-Gestion des Exigences

0.4 0.2

CONF-Gestion de Configuration

0

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. Measurement analysis: 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 requestor’s 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 Requestor’s 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 project’s general glossary.

8.1.2 Roles The following roles have been created for the requirements of this process:

COMPANY/DSI

61

Référentiel de gestion de projet - MPP - Management Par Projet

Role

Definition

Author of Requestor’s Specifications (ARS) Author of Functional Specification (AFS) Acceptance Designer (ACCD) Development Designer(DEVD) Ergonomics

Project Owner’s employee, writes the requestor’s functional specifications Writes the specification document using the requestor’s 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 application’s 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 requestor’s 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 COMPANY’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

8.1.4 "Evaluation" Phase The "Evaluation" phase starts as soon as the BSR milestone has been reached.

8.1.4.1 Requestor’s functional specifications During the “Evaluation” phase, one or more Requestor’s 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 Requestor’s 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 document’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 owner’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 requestor’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 document’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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)

1

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

 

Since the product tested is not the one delivered, bugs are discovered when the product is installed at the client’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 référence 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 requestor’s 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 component’s content Modification of a component’s identifier (name change)

COMPANY/DSI

73

Référentiel de gestion de projet - MPP - Management Par Projet

Modification of a component’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 requestor’s specifications: validation is very important because it is contractual. o The product’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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 component’s 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 product’s "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

Référentiel de gestion de projet - MPP - Management Par Projet

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 bug’s 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 release’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

o

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 product’s 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 product’s environment cannot always be controlled. Incompatibility is therefore understood to designate only interface incompatibility. Examples:

COMPANY/DSI

78

Référentiel de gestion de projet - MPP - Management Par Projet

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

o

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

o

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 request’s 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 A Project Manager [PM] A work package manager [WPM]

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

who could handle this role: A Project Manager [PM] A work package manager [WPM] 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 A Project Manager [PM] A work package manager [WPM]

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 request’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

o o

Ensures the confidentiality of the requests from an organization Works in close collaboration with the various CRML’s 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 who could handle this role: 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

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 further—it 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 The [REQ] has entered his request, which will be evaluated by an [EVAL-MGR] The [REQ] has entered his 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 request’s 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)  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 A non-reproduced fault  the request is rejected 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

Référentiel de gestion de projet - MPP - Management Par Projet

[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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

8.3.5.3 Evaluation steps

COMPANY/DSI

88

Référentiel de gestion de projet - MPP - Management Par Projet

8.3.5.4 Processing steps

COMPANY/DSI

89

Référentiel de gestion de projet - MPP - Management Par Projet

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 client’s 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 Owner’s 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 project’s objectives or scope will trigger an update to the project sheet.

COMPANY/DSI

90

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

9.2 Project Quality Plan 9.2.1 Document purpose 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.

9.2.2 Document evolution Any event with an impact on the project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

2

GLOSSARY

3

INTRODUCTION

4

5

6

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

7

RESOURCES 7.1 7.2 7.3

8

HUMAN RESOURCES EQUIPMENT AND SOFTWARE RESOURCES TRAINING PLAN

PROJECT STEERING 8.1 8.2 8.3 8.4

9

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

Référentiel de gestion de projet - MPP - Management Par Projet

9.3 Risk management sheet 9.3.1 Document purpose 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.

9.3.2 Document evolution The risk summary table is initialized and sent during the project’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

9.4 Steering sheet 9.4.1 Document purpose The steering sheet is where the project’s steering and tracking measurements are recorded for presentation at the Steering Committee (COPIL) meeting.

9.4.2 Document evolution 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

9.5 OBS (Organizational Breakdown Structure) 9.5.1 Document purpose The purpose of the OBS is to present all of the project’s 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

9.5.2 Document evolution 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

o

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 Organization 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

o

Manages the principal Work Package Operational member on the project Manages the Information Systems Management’s project portfolio Nominated Quality Manager for the project Organization Quality Manager 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 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

Référentiel de gestion de projet - MPP - Management Par Projet DEM

PM PO

x

COMPANY/DSI

CM: Requester PO-specific participant

Initiates the change request

99

Référentiel de gestion de projet - MPP - Management Par Projet

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

1

Project file

1.1

Economic documentation

EMA

EMA-Market Research

x

DEO

DEO-Opportunity Study Document

x

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

x

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

x x x x Closure (FPR)

[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)

x x x x Execution (RLR)

[DEV]

DCO

DCO - Other design documents

x x x x Execution (RLR)

[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

2

"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

x x x x Execution (RLR)

[DEV]

Source Code --> SVN link: Example: onekey-srv-1.0 component source code

x x x x Execution (RLR)

[DLOG]

Executables --> SVN link: Example: onekey-srv-1.0.0 component executable code

x x x x Execution (RLR)

[DLOG]

Example: onekey-srv-rpm-1.0.0.0 packaging

x x x x Execution (RLR)

[DLOG]

Acceptance/pre-production architecture product

x x x

[DEV]

Source Code

x x x x Execution (RLR)

[DLOG]

Executables

x x x x Execution (RLR)

[DLOG]

Deliverable product on beta test site, pilot or for controlled deployment

x x x

[DEV]

Source Code

x x x x Execution (RLR)

Execution (RLR)

Execution (RLR)

101

[DLOG]

Référentiel de gestion de projet - MPP - Management Par Projet

Code

Title

CEMR

Author

Executables

x x x x Execution (RLR)

[DLOG]

Production architecture product

x x x

[DDO/IND]

Source Code

x x x x Execution (RLR)

[DLOG]

Executables

x x x x Execution (RLR)

[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)

Preparation (VLR) [STC]

[DLOG]

Preparation (VLR) [PO]

Packaging

2.3

Blank CD(s)

x x

Preparation (VLR) [PO]

CD labels

x x

Preparation (VLR) [PO]

CD sleeve

x x

Preparation (VLR) [PO]

Guarantee/registration card

x x

Preparation (VLR) [PO] Preparation (VLR) [PO]

Box/File

x x

Packaging Documentation

x x

Manuals

x x

Preparation (VLR) [PO]

Files

x x

Preparation (VLR) [PO]

Inserts

x x

Preparation (VLR) [PO]

Cover

x x

Preparation (VLR) [PO]

Packaging

x x

Preparation (VLR) [PO]

Update pack

x x x

Preparation (VLR) [PO]

OF & production quantities

x x x

Preparation (VLR) [PO]

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

Preparation (VLR) [STC]

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

Preparation (VLR) [MKT]

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

Preparation (VLR) [OPS]

FOR

FOR - Test decks/demo companies

x x

Execution (RLR)

COMPANY/DSI

102

[PRD]

Référentiel de gestion de projet - MPP - Management Par Projet

Code

Title

CEMR

Author

FOR

FOR - Trainer's Guide

FOR

FOR - Training on the new version

x

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]

3

"Marketing/commercial" deliverables

3.1

Brochures Sales brochures

x x

Preparation (VLR) [MKT]

Technical brochures

x x

Preparation (VLR) [MKT]

Other documentation (examples of reports, screenshots, blank books etc.)

x x

Preparation (VLR) [MKT]

Mailing/Newsletter

x x

Preparation (VLR) [MKT]

Computer graphics

x x

Preparation (VLR) [MKT]

Content-data & demo companies

x x

Preparation (VLR) [MKT]

Media

x x

Preparation (VLR) [MKT]

Installation Guide

x x

Preparation (VLR) [MKT]

Scenario/demonstration script

x x

Preparation (VLR) [MKT]

Packaging

x x

Preparation (VLR) [MKT]

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

Preparation (VLR) [OPS]

JUR

JUR - License contracts (definitive)

x x

Preparation (VLR) [OPS]

JUR

JUR - Service contracts (training, parameterising)

x x

Preparation (VLR) [OPS]

JUR

JUR - Maintenance and assistance contracts

x x

Preparation (VLR) [OPS]

JUR

JUR - Partner contracts and royalty agreements

x x

Preparation (VLR) [OPS]

JUR

JUR - Copyright declarations

x x

Preparation (VLR) [OPS]

JUR

JUR - Certificate of registration with the APP, the French Program Protection Agency

x x

Preparation (VLR) [OPS]

3.6

Launch kit

COM

COM - Commercial launch pack

x x

Preparation (VLR) [MKT]

COM

COM - Website update

x x x

Preparation (VLR) [MKT]

COM

COM - Press file

x x

Preparation (VLR) [MKT]

COM

COM - Technical launch file

x x x

Preparation (VLR) [MKT]

3.2

x x

Phase

Preparation (VLR) [PRD]

Demonstration and evaluation kits

3.3

Sales aids

All gadgets

x x

Preparation (VLR) [MKT]

COM

COM - PPT presentation for conferences/customer presentations

x x

Preparation (VLR) [MKT]

CUS

CUS - Subsidiary feedback report

x x x x Closure (FPR)

COMPANY/DSI

[PO]

103

Référentiel de gestion de projet - MPP - Management Par Projet

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

Intégration 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

Vérification 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

Référentiel de gestion de projet - MPP - Management Par Projet

COMPANY/DSI

105

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

9.8.3 Model The following is a standard summary of a Configuration Management Plan: 1 CONTEXT 1.1 GENERAL POINTS ON 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

2

Project Planning

PP

Project Management

2

Project Monitoring and Control

PMC

Project Management

2

Supplier Agreement Management

SAM

Project Management

2

Measurement and Analysis

MA

Support

2

Process and Product Quality Assurance

PPQA

Support

2

Configuration Management

CM

Support

2

Requirements Development

RD

Engineering

3

Technical Solution

TS

Engineering

3

Product Integration

PI

Engineering

3

Verification

VER

Engineering

3

Validation

VAL

Engineering

3

Organizational Process Focus

OPF

Process Management

3

Organizational Process Definition +IPPD

OPD +IPPD

Process Management

3

Organizational Training

OT

Process Management

3

Integrated Project Management +IPPD

IPM +IPPD

Project Management

3

Risk Management

RSKM

Project Management

3

Decision Analysis and Resolution

DAR

Support

3

Organizational Process Performance

OPP

Process Management

4

Quantitative Project Management

QPM

Project Management

4

Organizational Innovation and Deployment

OID

Process Management

5

Causal Analysis and Resolution

CAR

Support

5

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 organization’s 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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

The practices associated with this objective are:

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

The practices associated with this objective are:

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

The practices associated with this objective are:

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.

The practices associated with this objective are:

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

Référentiel de gestion de projet - MPP - Management Par Projet

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.

The practices associated with this objective are:

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.

The practices associated with this objective are:

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

The practices associated with this objective are:

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

The practices associated with this objective are:

COMPANY/DSI

113

Référentiel de gestion de projet - MPP - Management Par Projet

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. The practices associated with this objective are:

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. The practices associated with this objective are:

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

Référentiel de gestion de projet - MPP - Management Par Projet

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. The practices associated with this objective are:

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

The practices associated with this objective are:

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

The practices associated with this objective are:

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

The practices associated with this objective are:

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

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

11 REFERENCES COMPANY

http://www.Company.fr

CMMI

Capability Maturity Model Integration ® Software Ingineering Institute http://www.sei.cmu.edu/cmmi

COMPANY/DSI

118

Référentiel de gestion de projet - MPP - Management Par Projet

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

Référentiel de gestion de projet - MPP - Management Par Projet

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 réu 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 réu 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 tés 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 tés 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 érés  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

 I m p ac ts tec h n i q u es ( 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 tég 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 tég 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 rêt 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 réu 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 vés

 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

 D at e /b u d g et c i b l es 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 tés 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

 D at e /b u d g et c i b l es val i d és & ap p rou vés

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 révi 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

 I m p ac ts tec h n i q u es ( 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 ,

 D at e /b u d g et c i b l es val i d és & ap p rou vé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 , O ri en ta ti on s tec h n i q u es & c o m m e rc i al es c on fi r m ées

 O ri en ta ti on s tec h n i q u 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 réu 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 tés 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

& te s ts ( u n i tai re s & i n t ég ra ti on )

& te s ts ( u n i tai re s & i n t ég ra ti 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 réu 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 réu 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 rés p en d an t l e p roj et d oc u m en tés

 P révi 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 rés 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 vés 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