Project Governance Plan V0.2a

Project Governance Plan

(engagement name)/ Project Governance PlanPage 39

DELIVERProject Governance Plan

(Engagement Name and Id)

(Client)

DOCUMENT ORIGIN

AUTHOROPERATION UNIT

CHANGE HISTORY

VERSIONDATECHANGES

REVIEW AND APPROVAL

COMPANYNAMEDATESIGNATURE

DISTRIBUTION

COMPANYNAMELOCATIONACTIONINFO

Template reference: DT-0004

Template version: 5.0

Copyright 2004 by Capgemini

TABLE OF CONTENTS

91.PROJECT GOVERNANCE PLAN OVERVIEW

91.1.Purpose Of The Project Governance Plan

91.2.Scope Of The Project Governance Plan

101.3.Control Of The Project Governance Plan

111.4.Deviations From Standard Structure

122.PROJECT OVERVIEW

122.1.Project Description

122.2.Project Objectives

122.3.Project Critical Success Factors

132.4.Project Scope

132.5.Contractual Deliverables

132.6.Contractual Milestones

132.7.Client Obligations

142.8.Assumptions And Constraints

142.9.Dependencies/Related Projects

153.Delivery Approach

153.1.Phases, Stages, Activities

153.2.Deliverables

15Appendix D contains a Deliverable Description for all deliverables from the project, both contractual and non-contractual. The method of delivery to is defined in that description

153.3.Development Standards

153.4.Verification and Validation

163.5.Notification of Deliveries

163.6.Replication

163.7.Installation

163.8.Servicing

174.PROJECT GOVERNANCE

174.1.Project Management Method

17In this section a reference should be made to the Project Management quoting the version number. Any tailoring or tuning applied to the method, to meet the specific needs of this project, should be detailed here.

174.2.Organisation

174.3.Roles and Responsibilities Matrices

174.4.Internal Steering Committee Description

184.5.Project Reporting

18Key Performance Indicators

18Productivity Metrics

18Delivery Dashboard

18Project Progress Reporting

18Project Status Reporting

184.6.Meetings

184.7.Acceptance

18Client Acceptance

18Capgemini Acceptance

194.8.Client Billing

194.9.Monitoring Of Actions

194.10.Handover

20Handover Procedures

20Handover Roles and Responsibilities

204.11.Warranty

215.TIME AND COST MANAGEMENT

215.1.Estimating

215.2.Project Schedule

215.3.Cost Management

21Budgeted Costs

21Actual Costs

215.4.Budget Management

226.RISK MANAGEMENT

226.1.Business Risk Management

226.2.Technical Risk Management

227.RESOURCE MANAGEMENT

227.1.Team Organisation

227.2.Team Roles and Responsibilities

227.3.On-Boarding

237.4.Training and Coaching

237.5.Team Member Evaluations

237.6.Team Member Release

238.CLIENT RELATIONSHIP MANAGEMENT

238.1.Client Profile

238.2.Client Steering Committee Description

238.3.Client Kick-Off Meeting

238.4.Client Satisfaction And OTACE

249.COMMUNICATION MANAGEMENT

249.1.Progress Meetings

249.2.Correspondence Handling

2410.INFRASTRUCTURE MANAGEMENT

2410.1.Project Management Office Infrastructure

24Office Infrastructure

24Hardware/Software Environment

24Tools Infrastructure and Integration

2410.2.Project Team Infrastructure

24Office Infrastructure

24Hardware/Software Environment

24Tools Infrastructure and Integration

2410.3.Infrastucture Reviews

2410.4.Security Management

24On-site Working Practices

2510.5.Access Control

25Handling, Storage and Archiving

26Backup Procedures

26Confidentiality

2711.ISSUE MANAGEMENT

2812.SCOPE AND REQUIREMENTS MANAGEMENT

2812.1.Scope Baseline

2812.2.Requirements Traceability

2812.3.Change Management

2913.QUALITY ASSURANCE

2913.1.Project Reviews

2913.2.Deliverable Reviews

2913.3.Project Audits

2913.4.Quality Audits

3013.5.Defect Tracking

3013.6.Continuous Improvement

3013.7.Final Evaluations

3014.CONFIGURATION MANAGEMENT

3014.1.Configuration Identification

3014.2.Configuration Control

3114.3.Configuration Status Reporting

3114.4.Configuration Reviews and Audits

3215.KNOWLEDGE MANAGEMENT

3215.1.Engagement Profile

3215.2.Knowledge Object Reuse

3215.3.Knowledge Object Sharing

3216.PROCUREMENT MANAGEMENT

3316.1.Supplier Selection

3316.2.Supplier Agreements

3316.3.Supplier Tracking

3316.4.Supplier Audits

3316.5.Supplier Billing

3316.6.Supplier Performance

3417.APPENDICES

3417.1.Appendix A: Document Control

34Completion and Amendment Schedule

34Version History

34Document Distribution

34Document Reviewed By

35Source File Location

3517.2.Appendix B: - Reference and Applicable Documents

35B.1Reference Documents

35B.2Applicable Documents

3617.3.Appendix C: Glossary

36C.1Terms

36C.2Acronyms and Abbreviations

3617.4.APPENDIX D - Deliverable Descriptions

3917.5.APPENDIX E Governance Procedures

3917.6.APPENDIX F Time and Cost Management Procedures

3917.7.APPENDIX G Risk Management Procedures

3917.8.APPENDIX H Resource Management Procedures

3917.9.APPENDIX I Client Relationship Management Procedures

3917.10.APPENDIX J Communication Management Procedures

3917.11.APPENDIX K Infrastructure Management Procedures

3917.12.APPENDIX L Issue Management Procedures

3917.13.APPENDIX M Requirements Management Procedures

3917.14.APPENDIX N Quality Assurance Procedures

3917.15.APPENDIX O Configuration Management Procedures

3917.16.APPENDIX P Knowledge Management Procedures

3917.17.APPENDIX Q Procurement Management Procedures

1. PROJECT GOVERNANCE PLAN OVERVIEW

1.1. Purpose Of The Project Governance Plan

A Project Governance Plan is a document that describes the specific procedures and resources necessary for the fulfilment of the project according to the Clients stated requirements. These procedures should be established when the project is set up and reviewed and modified if necessary during the life of the project.

The purpose of the Project Governance Plan should be clearly stated at the beginning of the document and will generally conform the recommended text below, with additions as necessary.

The objectives of the Project Governance Plan are as follows:

To give (the Client( confidence in the quality of the work that Capgemini will perform on the project.

To define (the Client's( rights and obligations in relation to quality.

To make visible all the means to be applied in meeting ( the Client's( technical and quality requirements.

To provide the quality authority with information necessary to organise quality assurance and quality control activities, including transfer of information, verification actions, etc.

To identify all the components to be used in the project; procedures, rules and applicable methods, etc.

This Project Governance Plan provides a high-level view of the project. It details the scope, objectives and overall approach for planning, designing, developing and implementing the solution for .

The Project Governance Plan provides for a common understanding between all project participants, helps manage expectations, and becomes the standard against which changes and deviations to process or product are identified and managed.

1.2. Scope Of The Project Governance Plan

{ This section should describe the scope of the Project Governance Plan, making clear both what is covered by the document and what is not.

The Project Governance Plan covers the processes, means and personnel for the following domains:

the planning activities;

the production activities (writing of a document, producing software, modelling, etc.);

the management activities (project management, preparation of reviews, training, installing tools, configuration management, etc.);

the verification activities (walk-through, review, audit, test by sampling, etc.).

When the Project Governance Plan is first created, a full understanding of all phases of the project will not usually be available. A completion schedule should therefore be incorporated in this section, which identifies the dates planned for further additions.

Provide a crisp definition of the scope. This is the opportunity to clarify scope issues early in the project. Ensure this covers Capgemini responsibilities only or that Capgeminis responsibilities within the scope are crystal clear. Consider:

- the system to be developed

- the services to be provided e.g. programme office

- a DFD level 0 might be useful

- reference Appendix D for deliverables rather than repeat list of deliverables here }

The following are within scope of Capgeminis responsibilities on this project:

1. { list items within scope of Capgeminis responsibilities on the project. Ensure they are explicit }

1.3. Control Of The Project Governance Plan

Preparation

It is normally the Project Manager who prepares the Project Governance Plan. The Project Manager may choose to delegate this task to another resource, such as the quality authority. However, the ultimate responsibility for its completion and maintenance remains with the Project Manager. Also, as the Client must approve the Project Governance Plan, the Client should therefore be involved in its formulation, albeit through discussion, to agree the approach, and to partake in the composition.

The Project Governance Plan should always be a co-ordinated effort with a broad range of inputs and contributions, even if the Project Manager or one other delegated person is responsible for combining, moulding and presenting these inputs. The use of a table will simplify the summary of the activities and the roles responsible for the development and production of the Project Governance Plan, for example:

PGP Development ActivityResponsible

DEFINE THE MODELProject Manager

Define contents of section 3Team Leader 1

Define contents of sections 4.1 to 4.10Team Leader 2

Define contents of remaining sectionsProject Manager

Produce initial versionDocumentation Specialist

Update the Project Governance PlanProject Manager

Approval

This section should describe the procedure for internal approval and external approval. The complexity of the approval process will be dependent upon the nature of the local Operation Unit procedures, the Client procedures and the project.

A Project Governance Plan is approved initially by Capgemini ("internal approval") and subsequently by the Client, or their representative ("external approval").

When a Project Governance Plan is a contractual requirement, an authority stipulated in the contract (usually the Client) must perform the external approval. When this is not the case, the Client must clearly indicate to whom this authority is given.

Updating

As the Project Governance Plan contains elements which should not vary with time, only exceptional events (modification of the contract, deviations to the Project Governance Plan due to impossible application of its requirements, new production conditions, etc.) are grounds for modification of the Project Governance Plan. The Client needs to be informed of any modifications made to the Project Governance Plan during the life of the project.

The updating procedure should be described in detail. Depending on the Client requirement for a Project Governance Plan, the following type of information should be given:

authority responsible for the updating process,

version control definition,

request for updating coming from the Client,

request for updating coming from Capgemini (usually the Project Manager),

decision-making process,

the Capgemini responsibilities,

the Client responsibilities,

organisation of meetings for decision-making,

recording of decisions,

responsibilities for performing the update,

information for the Client,

re-issuing of the document,

responsibilities associated with the follow-up of decisions,

actual details of the update to be performed,

approval of the update.

Lack Of Adherence To Project Governance Plan

This section should describe a procedure to permit the quality authority to:

identify the lack of adherence to the Project Governance Plan,

evaluate the impact and consequences of this,

initiate corrective actions, which may fall into one of the three following categories:

those that require the application of the Project Governance Plan,

those that require a modification the Project Governance Plan because it is not well suited to the project,

those that override a specific requirement. This requires the Client's authorisation and is recorded with the other reporting of quality activities.

The procedure to be followed in each circumstance should be described in detail.

1.4. Deviations From Standard Structure

In the case of a deviation from the DELIVER Project Governance Plan model (for example, when requested by a Client), the following information should be provided in this section:

An introductory text explaining the new structure of the Project Governance Plan.

The precise reference of the standard to which the Project Governance Plan adheres.

A reference to the Reference Documents appendix containing a cross-reference table between the new structure and the DELIVER model.

If it proves necessary to split up the Project Governance Plan into several documents (for example Development Plan, Configuration Management Plan, Change Control Plan), the reason for such a split should be provided together with an explanation of where and how each document fits in the Project Governance Plan. In this case, each such document becomes an applicable document and should therefore be referenced as such, in the Applicable Documents appendix.

2. PROJECT OVERVIEW

2.1. Project Description

This section should comprise the definition and background of the project, including:

the identity of the project,

the name of the Client,

a brief description of the Clients activities in relation to the project,

the agreed contract value,

an explanation of the overall environment of the project.

A diagrammatic illustration should also be produced, giving the structure of the project as viewed by the Client, and indicating the system, subsystems and main elements. These elements, as well as their interfaces, should be clearly defined.

The diagram should also show the following, with a brief explanation in each case:

the part developed by Capgemini,

the part bought by Capgemini,

the part under Capgemini subcontractors' responsibility (already existing, to be developed or bought),

the part under Capgemini co-contractors' responsibility (already existing, to be developed or bought),

the part under the Client's responsibility (already existing, to be developed or bought),

the links that exist between each of the aforesaid parts.

This section may be taken from the Project Charter

[To give the reader of the PGP any necessary background information or information necessary to understand the PGP in the context of the business issues, or other ongoing projects.

2.2. Project Objectives

This is a key section in which the fundamental objectives of the project should be specified. Both the high-level and project-level objectives should be outlined. The high-level objectives, in the context of the business case, which will have identified the need for the project in the first place, should first be stated (with the Client's agreement). If, for example, the project forms an element of a complete programme then its context in the programme and the related programme objectives should be stated.

The project-level objectives should then be specified and can be categorised as follows:

the Client's specific business objectives, to be achieved on the project,

the system objectives and the Client's system expectations,

the Client's organisational and functional objectives.

2.3. Project Critical Success Factors

[An internal, business-related item that is measurable and will have, on an ongoing basis, a major influence on whether or not an enterprise or process meets its objectives. Each critical success factor should be defined as follows:

Definition

Begin time

End time

Unit of measure

Means of measure]

2.4. Project Scope

Specify the subject matter boundary of the project, the subset of the organization that will be involved in the project, the time frame from project start to completion, the estimated cost for the project's completion, and the deliverables to be produced during the project.

Changes to scope will be documented as separate change requests and will be managed as per the standard change management process described within section 12.3.

2.5. Contractual Deliverables

The following table defines what the deliverables are and who is responsible, Capgemini or the Client.

WorkflowDeliverableResponsible Party

As part of the project, many other deliverables will be produced in support of the above key outputs of the project. These are identified in the project approach section of this document.

2.6. Contractual Milestones

The contractual milestones, which the project will deliver, should be described in this section. Subsequent plans should be based upon these milestones, but should not be included in the Project Governance Plan. This will allow for update of the plans without the need for a full Project Governance Plan re-issue.

The following project milestones should be shown in the project plan:

Start date.

Contractual deadline.

Intermediate dates linked to validation, reviews, visible stages, etc.

Events linked to Client's obligations, such as providing equipment, approving deliverables, etc.

Delivery dates.

Go/no-go decision points.

2.7. Client Obligations

The corporate obligations of to undertake activities as part of, or provide resources for, the project, are listed below:

1. { List the general obligations of the client. Cross reference to the Contract if appropriate. Consider:

- provision of working environment

- provision/maintenance of development environment

- provision/purchase of licences and software

- making available key personnel

- training, if not already covered by the project

- maintenance of the live system, if not already covered by the project

- operation of the live system, if not already covered by the project }

2.8. Assumptions And Constraints

In this section all key assumptions made about the project should be listed. The initial list may be taken from the proposal and supporting documentation. It is particularly important to include all assumptions relating to deliverables, resources, and other factors to be supplied by the Client, upon which the project will be dependent. These dependencies should be clearly documented and carefully monitored.

This section should also include constraints. Constraints may be external, that is to say, those imposed by Client, for example, limitations on the hardware to be used, or restricted access for Capgemini personnel to areas or information.. There may also be internal constraints, that is to say, those originating from Capgemini, for example, limited availability of personnel.

2.9. Dependencies/Related Projects

This section defines the known external dependencies associated with this project i.e. dependencies this project has with other projects, areas of work, people or events outside of this project.

a)Projects/Events that this Project is Dependent On

{ Delete this section if not required }PROVIDER (Details of who/what this project is dependent on)

Provider IdName of ProviderDescription of DependencyDate Required

b)Projects/Events that are Dependent on this Project

{Delete this section if not required}

RECEIVER (Details of who/what is dependent on this project)

Receiver IdName of ReceiverDescription of DependencyDate Required

3. Delivery Approach

3.1. Phases, Stages, Activities

{ Provide a brief overview of the approach. Consider:

describe the main phases of development

procedures used for advancing from one phase to another

use of traditional waterfall approach, or an iterative approach and the implications

how requirements will be gathered e.g. by workshops with users or interviews with individual users

- how a functional specification or use cases will be produced e.g. by workshops with users or reviews in small sections with users

what technical activities will take place e.g. design, build, test

hold up of a following phase until a particular sign off is obtained

big bang implementation or phased roll-out

specific user activities e.g. attendance at requirements workshops, acceptance testing, training

user training/knowledge transfer

- any special communication within the project and with the client e.g. newsletters, bulletins}3.2. Deliverables

Appendix D contains a Deliverable Description for all deliverables from the project, both contractual and non-contractual. The method of delivery to is defined in that description

3.3. Development Standards

Standards, rules and conventions that are used in the project and applied to development work should be listed. The list should contain the precise identification of each document, or a reference to an appendix of this Project Governance Plan where the document can be found. A table may usefully summarise this information.

3.4. Verification and Validation

This section should list the verification activities that have to be set up for assuring that the results of the phases meet their quality requirements. These requirements should be consistent with, but not restricted to, the Client's quality requirements and acceptance criteria.

The following information is given for each verification activity:

Type of verification (walk-through, end of phase review or review of document, audit, code/document inspection, etc.).

Object (item being verified).

Responsible authority for the verification (it may be the Project Manager, the quality authority, any specific authority in the project team, or even the Client).

Participants (usually members of the project team and sometimes the Client).

Objectives (criteria related to Client's or Capgemini quality requirements).

Notes (annotations on the document, minutes of meetings, request for corrective action, etc.).

Schedule for sending out documents to be reviewed.

Schedule for the review.

List of all documents required for the review.

Approval criteria.

Writer of the minutes.

Outcome of the review including the approval criteria and the specific action(s) to occur upon approval.

When the verification activities are met the next phase can start. Some reviews, such as proposal or contract reviews, may have taken place already, in which case they should be mentioned in this section.

Appendix D contains a Deliverable Description for all deliverables from the project, both contractual and non-contractual. The method of verification and validation by Capgemini is defined in that description.

3.5. Notification of Deliveries

The delivery procedure for products (documents, software or hardware) should be described. This includes, for each delivery, the application of an approval process and the use of a delivery note. When the project includes delivery of equipment, this section should also give details concerning the arrangements made in order to identify the different products and to assure quality during handling and transportation.

3.6. Replication

Appendix D contains a Deliverable Description for all deliverables from the project, both contractual and non-contractual. Any method of replication (or reproduction) to ensure that a replicated object is identical to the master and of the same quality is defined in the Deliverable Description.3.7. Installation

{ If installation is to be performed within the project, provide details of the installation process stating:

- the item to be installed (reference the Identification Code in the Deliverable Description in Appendix C

- the exact location of the installation - site, machine, environment

- who will carry out the installation and what client involvement is required

- plans to install/check that installation is complete

If all details are not known at this stage, state that the details will be defined in which will contain the above information, and when it will be produced.

If no installation is to be performed, state Not applicable }3.8. Servicing

If there is to be any subsequent service management provided by Capgemini, the relevant service management method to be implemented should be specified here. The procedures for knowledge transfer and for formal hand-over should also be stated in such case.

4. PROJECT GOVERNANCE

4.1. Project Management Method

In this section a reference should be made to the Project Management quoting the version number. Any tailoring or tuning applied to the method, to meet the specific needs of this project, should be detailed here.

4.2. Organisation

The following diagram summarises the links that connect the parties involved in the project, and indicates the specific functions associated with the project:

This section should display of all personnel and project teams involved in the project together with the links (hierarchical and functional) that connect them. An Organisation Chart or diagram should be created so that the overall organisational structure of the project can be perceived at one glance. The project should be represented in terms of the inter-related groups involved, including the following:

the Client organisation to which the project belongs,

the Client-supplier relationship,

the subcontracting organisation,

the Quality organisation,

the Capgemini organisation relating to the project (role of the Operation Unit Manager, the Operation Unit Quality Manager, the sales representative, the technical support, etc.).

A graphic representation of the project is recommended (a chart or overview diagram, for example) showing the hierarchical dependencies between the Project Manager and the different team leaders (where this level of organisation exists) and the members of the project. Such a diagram should, at this level, also show the organisational environment of the project with entities external to the development (for example business experts, a technical department, product support).

If needed, complementary descriptions of the different organisation units may be undertaken. There may also be a need to show the project in the context of a larger programme, in which case the project organisation chart would then be an expansion of the relevant section of the programme organisation chart.4.3. Roles and Responsibilities Matrices

This section should list, for each project stage and activity identified, the personnel (indicated by job title, not by name) responsible, in terms of those accountable, those responsible and those consulted. Other levels of responsibility, such as those who verify, inform or sign-off can be indicated as appropriate. This may be done in the form of roles and responsibilities matrices, as shown (and can be downloaded) in the DELIVER Project Management method.

4.4. Internal Steering Committee Description

This section should state the purpose of the internal steering committee and identify each of its members. The composition of the Internal Steering Committee may be represented in a table format or graphically, in a chart or overview diagram and it is advisable to include role and contact details of each member.

The purpose of the internal steering committee meeting is typically to ensure that the appropriate start-up tasks have been completed and to direct the management of potential risks, problems, issues or concerns that may impede the successful completion of the project.4.5. Project Reporting

Key Performance Indicators

Productivity Metrics

Delivery Dashboard

Project Progress Reporting

Project Status Reporting

4.6. Meetings

4.7. Acceptance

Client Acceptance

{ Amend the following section if appropriate. Reflect/cross reference the Contract if appropriate. More than one turn round of the document may be required, but, the number of turn rounds need to be appropriate for the overall project timescale, especially if fixed price }When a deliverable is delivered to < CSN > for acceptance, the following procedure and timings will apply:

Capgemini will give 3 working days notice of a deliverable to < CSN >

< CSN > will provide comments on the deliverable within 5 working day of issue by Capgemini. These comments will be coordinated by < CSN > so that a single set of comments, with duplicates removed and conflicting comments resolved, prior to issue to Capgemini

Capgemini will review the comments and update the deliverable as appropriate and reissue within 5 working days of the receipt of all comments by < CSN >

< CSN > will have 5 working days from reissue to check that comments are included and to sign off the deliverable. (In order to meet overall timescales. This will not be an opportunity for comment in addition to those from the initial delivery)

if any < CSN > does not provided a co-ordinated response by the end of either of the two 5 working day loops, following chase up by the Capgemini Project Manager, this will be escalated to the < CSN > Project Manager for action. In order to meet the overall timescales, Capgemini may choose to continue work on the basis that the contents of the deliverable are correct and any subsequent changes to the deliverable will be managed through formal change control. The Capgemini will inform the Project Manager of such a decision.

The acceptance criteria against which < CSN > will verify the deliverable are given in Appendix D, along with the people responsible for verification and sign off.

Once all deliverables to < CSN > have met their acceptance criteria (as defined in Appendix D) and Capgemini has completed its activities as defined in this PQP and the Contract, < CSN > will provide final and full acceptance that Capgemini has fulfilled its contractual obligations and its responsibilities on the project by completion of a Capgemini Acceptance Certificate by the < CSN representative >.

Capgemini Acceptance

{The Capgemini acceptance procedure for a purchased product, or a developed product, coming from the Customer, another unit or a supplier, that is to be used in the project or added to the project results, is described. This includes the acceptance protocol in which acceptance criteria are clearly indicated. Record of the acceptance is indicated.

When a product is purchased for or supplied by the Customer, special care must be taken on licensing, maintenance, obtaining updates, new releases or versions. Arrangements made and the ways these products are managed are described.

If no such products are to be accepted state Not applicable

Details may be added to appendix D}

4.8. Client Billing

{Amend details as appropriate}

Amend this section to Invoices will be sent as defined in the Contract if invoicing arrangements are clearly specified in the Contract (or perhaps the overall Programme Plan if this project is part of a programme)

Amend this section if the project is Fixed Price and a payment schedule needs to be defined here (and cannot be referenced from the Contract)

Ensure you are aware of the invoice authorisation levels for your delivery unit/region}

Invoices will be sent to the < CSN > by the < nth > day of each month for the work completed in the previous period.

4.9. Monitoring Of Actions

Actions arising from meetings, reviews, audits, risk management, problem management are reviewed on at least a monthly basis by the Project Manager.

4.10. Handover

{ Provide a brief description of how and to whom the project will be handed once the teams responsibilities have been completed. This may be to a Capgemini team or to the client. It may be, for example, to a testing team or a support team.

It is important that members of the team to which the project will be handed over are planned into the project at the earliest possible stage. Consider how they may be included - this may be:

during a specific handover period during which time members of the team are trained by the development team in the application and associate documentation. Sufficient time and budget will need to be allowed for this approach or by including one or more members of the team as development team members, enabling them to become familiar with the application by being hands on during the development. This is likely to be the more economical route but resources and timescales may be prohibitive or by one or more members of the team shadowing the development team and self training. Define how much time will be allowed, if any, by the development to help the support teamIf there is no agreement in place for on-going support, document this fact and that arrangements need to be agreed by the client as soon as possible. Point out the possible arrangements and relative impact on costs and budget. Also, if arrangements are not in place early enough for adequate training of the support team to take place, this is a risk to the successful live operation of the project - enter this in the risks section

Document the approach, the skills required (or agreed) of the support team members and the deliverables from the handover. If the support team does not have the appropriate technical skills for the project and they are to be included in the development, ensure allowance is made for this in the timescales and budget. The support team should agree the approach and be required to sign off the completion of the knowledge transfer in accordance with the agreed approach }Handover Procedures

Handover Roles and Responsibilities

4.11. Warranty

{ This would normally be explicit in the Contract i.e. that there is no warranty or what the warranty arrangements are. If so, reference the contract. If there is no information in the Contract regarding warranty, state here that there is no warranty on the project deliverables. If the information in the Contract is not explicit, clarify the arrangements here. Consider:

- what do the warranty arrangements mean in terms of number of staff and their availability/location

- what is the process for the client notifying Capgemini of issues arising under the warranty arrangements

5. TIME AND COST MANAGEMENT

5.1. Estimating

5.2. Project Schedule

{Amend details as appropriate. Describe the procedure used for managing the project plan and the tasks contained therein. It may be necessary to be explicit about how the plan is to be incorporated into an overall programme }

Tasks are assigned to each team member on a < weekly > basis on a < weekly > timesheet. At the end of the week, the team member submits the completed < weekly > timesheet showing for each activity the time spent and an estimate to complete. The < weekly > timesheets are used to update the < PMW > project plan on a weekly basis.

5.3. Cost Management

{ Amend details as appropriate. Define processes for controlling the budget as cost, revenue and margin. Revenue to complete will not be from the current project plan if the project is fixed price, it will the remainder of the agreed budget }

At the outset of the project, the budget in terms of < man days and > revenue is agreed with the client (this is normally part of the Contract). The budget for internal costs to Capgemini are agreed between the Capgemini Project Manager and Delivery Manager and details recorded on a Project Assignment Sheet (PAS)

On a monthly basis, the Capgemini Project Manager provides a Project Revenue Report showing the Original Budget, the Current Agreed Budget, Actual Costs to Date, Forecast Remaining Budget and Total Forecast Budget, in each of < man days, revenue and cost to Capgemini >. Actual Costs to Date is updated from monthly timecards and expenses forms (which are completed by the project team members) and from the updated project plan and purchase invoices raised.

Budgeted Costs

Actual Costs

5.4. Budget Management

6. RISK MANAGEMENT

This section should specify the procedure and responsibilities with regard to each of the three principal elements of Risk management: risk assessment, risk containment and risk monitoring. The procedure should be consistent with the unit/region Risk Management Procedures. In particular the following aspects of the procedure should be highlighted:

when the initial risk assessment is performed,

who is to be responsible for the assessment,

the frequency of further risk assessment thereafter,

the forms and templates to be used,

the frequency and responsibilities for reporting,

the process and responsibilities for risk containment management,

definition, review and update of the risk containment plan,

the process and responsibilities for escalation to the client,

the process and responsibilities for escalation with Capgemini.

6.1. Business Risk Management

6.2. Technical Risk Management

7. RESOURCE MANAGEMENT

{ Amend details as appropriate. If the team is joint Capgemini/client, the Capgemini project manager may be asked to provide appraisals for the client staff. If this is the case, the details of the appraisal process for the client staff must be included. The activity must be included in the project plan.. If the project is Fixed Price and this is not a contractual deliverable or is not included in the budget, then Change Request must be raised by the Capgemini Project Manager to cover the cost of this activity}7.1. Team Organisation

7.2. Team Roles and Responsibilities

The Capgemini Project Manager will ensure that Assignment Details are produced for each Capgemini team member. An Assignment Appraisal will be held either every six months/year according to their grade and/or at the end of the assignment for each Capgemini team member.

7.3. On-Boarding

New Capgemini team members are given a brief overview of the project by the Capgemini Project Manager .

7.4. Training and Coaching

7.5. Team Member Evaluations

7.6. Team Member Release

8. CLIENT RELATIONSHIP MANAGEMENT

8.1. Client Profile

8.2. Client Steering Committee Description

8.3. Client Kick-Off Meeting

8.4. Client Satisfaction And OTACE

{ If it is agreed with the Capgemini Account Manager and Delivery Manager that no OTACE will be carried out for this project, state that there will be no OTACE for this project. This may be appropriate for a small/short project. }It is Capgemini policy to measure client satisfaction throughout the life of each project so that the clients aims and objectives are understood. This process also provides feedback on areas that are going well and those areas where improvements are needed. The Capgemini programme is entitled OTACE (On Time and Above Client Expectations) and procedures are described in an OTACE questionnaire and brochure.

{If OTACE for this project is encompassed by OTACE for the Programme/Service within which this project fits, delete the following and refer to the Programme/Service level OTACE }

The responsibilities / timescales for effecting these procedures are:

TaskTimescaleResponsibility

Initial criteria definedDuring Start Up phaseCapgemini Account Manager / Capgemini Delivery Manager & Client Project Sponsor

Assessment{ at major milestones or max every 6 months }Client Project Sponsor

{Describe any other client satisfaction methods employed on the project e.g. end of project survey}

9. COMMUNICATION MANAGEMENT

9.1. Progress Meetings

9.2. Correspondence Handling

10. INFRASTRUCTURE MANAGEMENT

10.1. Project Management Office Infrastructure

Office Infrastructure

Hardware/Software Environment

Tools Infrastructure and Integration

10.2. Project Team Infrastructure

{An overview of the development environment of the project would be useful with an architecture type of diagram. List all hardware used in the delivery environment. Note where hardware items are remote from the team location

Consider means of going from development to target environment

This section could refer to a separate document}.

Office Infrastructure

Hardware/Software Environment

Tools Infrastructure and Integration

10.3. Infrastucture Reviews

10.4. Security Management

On-site Working Practices

{ If the project is not on a clients site, state in this section the work is on a Capgemini site and Capgemini normal working practices apply. Otherwise enter specific details for the Capgemini project team working on the clients site. Consider:

- normal working hours

restricted working hours

-access to client premises/car parks (by badge, pass, signing in)

- security procedures

- rules for arrival/removal of Capgemini equipment

- health and safety rules

- use of telephones, if the client has specific rules

need for Capgemini staff to log onto the Capgemini Intranet to keep abreast of corporate news and access their email account

on-site virus protection procedures before down loading software onto the client or third party network }}

10.5. Access Control

{ Enter specific means of restricting access. Consider:

- who access to the Project Repository, documentation or software will be restricted to if on Capgemini site e.g. to the Capgemini project team

- method of accessing the Project Repository, documentation or software will be restricted to if on Capgemini site e.g. by user name and password }Handling, Storage and Archiving

a)Handling{ This section is for handling of hardware only. If there is no hardware to be delivered, delete the next sentence and state No special handling arrangements are applicable}

< Appendix D contains details of hardware deliverables. >

{In Appendix D for the appropriate deliverable describe the goods receiving, inspection, acceptance/rejection processes. Consider special arrangements on client sites}

b)Storage

{Describe where documents or software are stored, saying who is responsible for the original or master copy and how long they are kept. For hardware the special conditions for storage are indicated (humidity, temperature, etc.).

Consider

- for distributed projects, the location of intermediate storage for equipment (hardware, software)

- for projects that include delivery of hardware, the measures for assuring identification}

All documentation and information regarding the management of the project is filed in the Project Repository. All signed off paper originals of document deliverables will be filed in a hard copy repository.

Software will be stored < >

Hardware will be stored < >

c)Archiving

{Enter details of the items that must be archived, related to development and management activities. This should including the following:

- project repository

- deliverables, including signed paper copies

- quality activity documentation (for example minutes of reviews and audits, trace of the configuration status, validation results, acceptance report)

- acceptance certificates.

Define media and format of archival and the location and duration of archiving.

Legal requirements for archiving vary from one country to another - note any special requirements

Backup Procedures

{ Enter details of what is to be backed up. Consider:

- the frequency of back-up

- location of back-ups (storage premises including off-site copies)

- scope of backup (part or total)

- verification of back-ups (for example by periodical restoration tests

- back-ups of information not held on the normal development media such as information held on Capgemini laptops.}

Confidentiality

{ Enter any special confidentiality aspects of the project and the measures to be taken to ensure they are complied with. This may be in the contract, in which case reference the Contract. Consider:

- if the client has a Confidentiality Statement, reference it here

- any particular documents that have restricted distribution/classification

- data encryption

- special clearance for new personnel joining the team

If there are no special confidentiality requirements, state There are no special confidentiality requirements }11. ISSUE MANAGEMENT

Procedures for problem management are described within DELIVER Project Management method.



Raise Issue ReportAs they occurAny person working on or related to the project

Assessment/ management of issuesWeekly/periodicallyCapgemini Project Manager

ReportingperiodicallyCapgemini Project Manager

Escalation of Problems will be as follows:

Escalation within

PM to

Sponsor to

Escalation within Capgemini

Capgemini PM to

Capgemini Delivery Manager to

Capgemini Delivery Director


Capgemini Delivery Director12. SCOPE AND REQUIREMENTS MANAGEMENT

12.1. Scope Baseline

12.2. Requirements Traceability

12.3. Change Management

The procedure for Change Management is described in DELIVER Project Management Method.



Raise Change Request/Reason for raisingAs they occurProject Manager

Impact AssessmentAs they occurCapgemini Project Manager

Approval of Budget ChangesWithin working days from issue of CR< CSN Project Manager > to level of < xk or x man days >

< CSN Sponsor > to level of < xk or x man days >

Capgemini Delivery Manager to level of < xk or x man days >

Escalation of non sign off of Change Requests will be as follows:

Escalation within

PM to

Sponsor to

Escalation within Capgemini

Capgemini PM to


Capgemini Delivery Director

{ Amend as appropriate }

13. QUALITY ASSURANCE

Details of Terms of Reference, participants and expected duration of the above events will be found in the Capgemini standard Audit and Review Procedures.

13.1. Project Reviews

13.2. Deliverable Reviews

13.3. Project Audits

Audits are carried out by appropriate Capgemini staff who are not involved in the project. The approach taken normally involves interviewing selected members of the Project Team (arranged with the Capgemini Project Manager) and, where relevant, it is preferred that key < CSN > staff involved with the project are included. A report is produced from the audit, which is internal to Capgemini, although key findings will be discussed with the < CSN > Project Manager.

13.4. Quality Audits

{Agree types and dates of audits and reviews with the Divisional Quality Manager and enter details and/or delete items from the table below. Consider also whether the client will audit the project and ensure the objectives/process/duration/follow up are defined.

If Contract Review and/or Delivery Solution Review have been undertaken this section must state when they occurred and who was involved

The following reviews and audits are planned to take place during the course of the project according to the Quality Assurance procedures: }

Type of Review or AuditResponsibility for Organising Review/AuditTarget Date of Review/AuditClient Involvement

(Y/N)Output from the Review/Audit

13.5. Defect Tracking

13.6. Continuous Improvement

13.7. Final Evaluations

14. CONFIGURATION MANAGEMENT

14.1. Configuration Identification

{ Amend the following as appropriate }

Configuration identification provides the mechanism to obtain visibility and to establish traceability of the configuration items. Identification does not mean the assignment of a single identifier to some monolithic component. Rather, it means the determination of the constituent parts of a system or product, the recording of the characteristics of those parts, the identification of their relationships, the assignment of a unique name to each part, and the graphical or tabular depiction of the whole system/product.

A list of items under configuration management will be maintained.

Capgemini version control standards will be used.

The following configuration management tools will be used:

{If no configuration management tool is used then this section contains precise details of how configuration management will be achieved that are required as explanation in addition to the DELIVER Configuration Management Guide }

14.2. Configuration Control


The Configuration Manager is responsible for giving access to the configuration items only to authorised people. The overall objective is to prevent any uncontrolled change to occur, while maximising the efficiency of normal operations. This will preserve the integrity of the whole configuration, therefore allowing for secure archives to be generated.

In order to protect the integrity of the configuration and to provide the basis for the control of change, it is essential that configuration items are held in an environment which:

protects them from unauthorised change or corruption

provides means for disaster recovery

permits the controlled check-in and check-out of items (especially for software and documentation)

supports the achievement of consistency between related configuration items

Once a safe environment is in place, configuration control will involve the following activities:

document and justify changes

evaluate consequences of changes

approve or disapprove changes

implement and verify changes

issue copies of configuration items

record that configuration item has been issued for update

notify copy holders

store modified versions of configuration items

update configuration item records

create new baselines

produce new releases

Further details on configuration control can be found in the DELIVER Configuration Management Guide

14.3. Configuration Status Reporting


Configuration status reporting is a line of communication between the people working on the engagement and the Engagement Manager. It may be used also to communicate with upper management. Depending on the situation, some more quantitative information may be required to produce statistical reports as deemed necessary.

The following information is required as input for configuration management reporting:

the status of each configuration item and baselines

the status of each change request, fault report or known error (with a list of the affected items)

the date at which each baseline was established

the date at which each item and change was included in a baseline

the description of all the changes made during a certain period of time

the documentation status of each item and baseline

the list of the changes planned for each identified future baseline.


14.4. Configuration Reviews and Audits


Configuration reviews and audits guarantee the correct functioning of the whole configuration management function. Reviews focus on checking the integrity of all the items under configuration management, whilst audits focus on checking the actual application of the configuration management procedures and rules.

A configuration status review is a formal examination of the characteristics of configuration items, baselines and releases, in order to check the overall consistency and integrity of the configuration database.

A configuration status review will be conducted:

immediately after the introduction of the configuration management system and procedures (to check the base configuration, which will then be changed only through formal control procedures)

at planned milestones (for example at the end of a development phase)

at specific points (for example, following major changes to the IT infrastructure)

at random intervals (to discourage the introduction of spurious items)

in the event of a disaster (to establish which items have been damaged or destroyed, to investigate recovery actions, and to verify that recovery actions have been successful).

A configuration management audit is aimed at assessing the effectiveness and efficiency of the configuration management function as a whole. The configuration management audit will include checks to ensure that the traceability requirements are being satisfied.

They will be conducted:

shortly after the introduction of the configuration management system (approximately 3 months)

periodically thereafter (6-12 month intervals).


15. KNOWLEDGE MANAGEMENT

15.1. Engagement Profile

15.2. Knowledge Object Reuse

15.3. Knowledge Object Sharing

16. PROCUREMENT MANAGEMENT

{ If there are no Third Party Suppliers involved in the project, state that there are none. If it aids clarity, include the section if the client is responsible for Third Parties but restate that their management is the clients responsibility. Other Capgemini Units may be regarded as any other external supplier or subcontractor. However, in general, the client should perceive Capgemini as a whole unit and care should be taken to avoid showing Capgemini as fragmented.}

Include this section if Capgemini is responsible for managing Third Parties. Consider:

-

how items will be purchased from the supplier (e.g. via client or by Capgemini)- ensure that it is clear who pays for such items. It may be that Capgemini is responsible for purchasing the item in the first instance but that the cost is then passed onto the client reference to Capgemini Procurement if appropriate

- any special arrangements for sub-contractors

reference Capgemini Sub Contractor Management if appropriate, for major sub-contractors

maintenance and reporting of problem (issue) management

maintenance and reporting of change management

reference back-to-back contracts }

16.1. Supplier Selection

16.2. Supplier Agreements

16.3. Supplier Tracking

16.4. Supplier Audits

16.5. Supplier Billing

Supplier bills received by the project are checked by the Project Manager. Valid invoices are passed for payment authorisation and payment within Capgemini.

16.6. Supplier Performance

17. APPENDICES

17.1. Appendix A: Document Control

Completion and Amendment Schedule

Date/Dependency/ActionSectionTitle

Version History

VersionDateComments

1.2June 1999Version of template for PM3 version 1.2 - delete this line

1.3August 2000Version of template for PM3 version 1.3 - delete this line

1.4August 2001Version of template for Rational Unified Process delete this line

2.0May 2002First draft based on PQP template v 1.2

2.0April 2003First version of PGP

Document Distribution

NameLocationResponsibilityAction/Information

Project Sponsor

Project Manager

CapgeminiCapgemini Delivery Manager

CapgeminiCapgemini Divisional Quality Manager

CapgeminiCapgemini Project ManagerProject Repository

Document Reviewed By

NameLocationResponsibility

Source File Location

Specify location of your PGP

17.2. Appendix B: - Reference and Applicable Documents

{Be as specific as possible about each document to ensure the correct document is identified i.e. title, version number, reference, date}B.1Reference Documents

The following table lists all documents, which are referenced within this Project Governance Plan. The extent of the applicability of each document to the project is described in the appropriate section of this document.

Document ReferenceTitleVersion

DELIVER Project Management < 5.0 >

Delivery Method(s) e.g. Rational Unified Process

< Contract >

< Proposal >

< Training manual >

< Standards >

B.2Applicable Documents

{This section is optional}The following table lists all documents, which may not be explicitly referenced within this Project Governance Plan, but provides background or supplementary information to the project.

{Consider:

- Programme Quality Plan

- Client documents that provide background or supporting information

- Technical documents that provide background or supporting information

If any of these documents is to be binding to Capgemini and/or the client, state this}Document Reference TitleVersion

17.3. Appendix C: Glossary

C.1Terms

This appendix defines key abbreviations and acronyms contained in this document.

{Delete any you dont refer to}

Term Meaning

Review (of a deliverable prior to delivery to < CSN >)A formal documented review by one or more people, either from within or outside the project team

Walkthrough (of a deliverable prior to delivery to < CSN >)A peer group review of any deliverable conducted by the project team members. This should normally include the originator of the deliverable

Inspection (of a deliverable prior to delivery to < CSN >)A semi-formal check that the deliverable meets the specifications and conforms to standards. This may not include the originator of the deliverable

Formal Inspection (of a deliverable prior to delivery to < CSN >)A formal methodical inspection (e.g. Gilb Inspection)

Testing (of a deliverable prior to delivery to < CSN >)A series of formal tests against a set of documented expected results. The types and level of testing will depend on the stage of the project < and documented within a Test Strategy, drawn up in conjunction with < CSN > >

C.2Acronyms and Abbreviations

This appendix contains definitions of acronyms and abbreviations contained in this document, which may otherwise lead to incomprehension, misunderstandings or ambiguities.

Acronym or Abbreviation Meaning

CRChange Request

PMProject Manager

PGPProject Governance Plan

TPS(n)Third Party Supplier (n)

17.4. APPENDIX D - Deliverable Descriptions

{Complete one Deliverable Description for every deliverable, whether or not contractual and whether delivered from Capgemini, the client or a third party

If there are many deliverables, consider inserting an index at the start to help find the individual Deliverable Description

If a category of information of the Deliverable Description is not applicable state Not applicable, or if the information is to be provided during a later update of the PGP state when this will take place.Do not leave a category of information blank}Deliverable ID{Enter the identifying code by which the deliverable will be known in here e.g. D0002. The identifier is referenced elsewhere in the document, so it must be unique}

Deliverable Name{Enter the name by which the deliverable will be known in here e.g.

Project Governance Plan, Functional Specification}

Abbreviation{Enter the abbreviation by which the deliverable is normally known e.g. PGP, FS}

Contractual DeliverableContractual / Not Contractual {delete one of these as appropriate}

Type {Enter type of deliverable e.g. Document, Software, Hardware}

Source/Destination{Enter e.g. Delivered from Capgemini to < CSN >

Or Delivered from < TPS1 > to Capgemini, then to < CSN >

Or Delivered from < TPSI > to < CSN >

Or Delivered from < CSN > to Capgemini}

Purpose{Enter the purpose of the deliverable, why has it been produced, what information it is it intending to convey}

Composition

{Enter e.g. the contents of the deliverable (i.e. the Table of Contents for a document, with a brief description of the contents of each section.

If the deliverable is software, list the main functional elements of the software and a brief description of each

If the deliverable is a software product from third party supplier state the name and version of the product and a brief description}

If the deliverable is a Release of software list the components of the Release, version numbers and brief description of each}

Form{Enter the form that the deliverable will be prepared in (e.g. Word 6.0}

Deliverable StandardEnter the e.g. the documentation standard (e.g. Q004 Capgemini Document standard}

Development standards e.g. which coding standard, which tools or hardware, include version numbers as appropriate}

Derivation

{Enter the derivation of the deliverable e.g. the documents which are referred to when preparing the deliverable e.g. the derivation for a PGP may be the Contract, the Proposal}

Acceptance Criteria

{Provide the criteria against which the deliverable will be measured, The criteria should be as measurable as possible, not subjective

If this is software to be delivered for testing, this must state the acceptable levels of each fault classification}

Capgemini Verifiers{Name the roles of the people on the team (or outside of team if appropriate) who will check/verify the deliverable (before it is delivered to the client or on receipt from the client or third party}

Capgemini Verification Method{Document the ways in which quality of the deliverable will be ensured e.g. Review, Walkthrough, Inspection, Formal Inspection, Testing (state levels of testing e.g. unit testing, system testing, performance testing - should equate to tasks/activities on the global plan}

Capgemini Sign Off{State the role of the person who is authorised to formally signing off the deliverable as meeting all specified acceptance criteria for the deliverable on behalf of Capgemini

It is possible that several people will sign the document following verification, but make it clear who have overall responsibility for its sign off}

Capgemini Sign Off MethodSignature on front page of deliverable / Signature on Acceptance Certificate / Not applicable {delete appropriate}

< CSN > Verifiers

{List the people that will review the deliverable against the quality criteria. The role of the person may be specified rather than the actual name e.g. Project Sponsor

Not applicable if not a contractual deliverable}

< CSN > Sign Off

{State the name of the person who is authorised to formally signing off the deliverable as meeting all specified Acceptance Criteria {see above} for the deliverable on behalf of < CSN >

It is possible that several people will sign the document following verification, but make it clear who have overall responsibility for its sign off}

Not applicable if not a contractual deliverable}

< CSN > Sign Off MethodSignature on front page of deliverable / Signature on Acceptance Certificate / Not applicable {delete as appropriate}

Not applicable if not a contractual deliverable

Delivery Medium {E.g. paper, electronic (diskette or a specific file/directory location}

Number of Copies{State number of copies of each media to be provided to the Destination}

Replication Methods{If multiple copies are to be delivered state what process will occur to ensure all copies accurately reflect the master}

Delivery Arrangements {State specific delivery arrangements e.g. issue by email to person, visit to client site, transit by road and how receipt will be checked}

17.5. APPENDIX E Governance Procedures17.6. APPENDIX F Time and Cost Management Procedures17.7. APPENDIX G Risk Management Procedures17.8. APPENDIX H Resource Management Procedures17.9. APPENDIX I Client Relationship Management Procedures17.10. APPENDIX J Communication Management Procedures17.11. APPENDIX K Infrastructure Management Procedures17.12. APPENDIX L Issue Management Procedures17.13. APPENDIX M Requirements Management Procedures17.14. APPENDIX N Quality Assurance Procedures17.15. APPENDIX O Configuration Management Procedures17.16. APPENDIX P Knowledge Management Procedures17.17. APPENDIX Q Procurement Management ProceduresReference: (document reference)

Version: (document version)

Date: (document date)

Reference: (document reference)Version: (document version)Date: (document date)