Riata - Project Governance Plan

PROJECT GOVERNANCE
PLAN V.1
Reference: (Riata Corporate Group Project Governance Plan)

Version: (1)
Date: (Feb 6, 2013)
Copyright 2012. Capgemini
DOCUMENT ORIGIN
AUTHOR
OPERATION UNIT
TOOL
LOCATION (PATH/FILE NAME)
DATE
CHANGES
Mickey McBroom
DOCUMENT LOCATION
CHANGE HISTORY
VERSION
1
March 1, 2013
Initial Draft
REVIEW AND APPROVAL

COMPANY
NAME
Riata
Joe K
Capgemini
John Clark
DATE

This document is the confidential and proprietary property of Capgemini U.S. LLC/ Riata Corporate Group
SIGNATURE
Page 1
TABLE OF CONTENTS
1.
Project Governance Plan Overview
1.1 Purpose Of The Project Governance Plan......................................................................................3

1.2 Scope Of The Project Governance Plan......................................................................................... 3
1.3 Control Of The Project Governance Plan........................................................................................ 3
2.
Project Overview
2.1 Project Description.......................................................................................................................... 5

2.2 Project Objectives........................................................................................................................... 5
2.3 Project Critical Success Factors..................................................................................................... 5
2.4 Parameters for Decision Making..................................................................................................... 6
2.5 Project Scope................................................................................................................................. 6
2.5.1
Organization Scope................................................................................................................. 7
2.5.2
Application Module Scope........................................................................................................ 7
2.5.3
Software Version Scope........................................................................................................... 7
2.5.4
Business Process Scope......................................................................................................... 8
2.5.5
Development Scope............................................................................................................... 10
Definition of Complexity for RICEFW Scope......................................................................................11
2.5.6
Legacy Remediation and De-Commissioning Scope.............................................................11
2.5.7
Data Scope............................................................................................................................ 12
2.5.8
Archiving Scope..................................................................................................................... 12
2.5.9
Scope of Support For Data Management...............................................................................13
2.5.10 Controls and Compliance Scope............................................................................................ 13
2.5.11 Security Scope....................................................................................................................... 14
2.5.12 Language Scope.................................................................................................................... 14
2.5.13 Currency Scope..................................................................................................................... 14
2.5.14 Geographic Delivery Scope................................................................................................... 14
2.5.15 Organizational Change Management Scope.........................................................................15
2.5.16 End-User Training Scope....................................................................................................... 15
2.5.17 Knowledge Transfer Scope.................................................................................................... 15
2.6 Scope Assumptions Concerning EnergyPath Software................................................................15
2.7 General Responsibilities............................................................................................................... 15
2.8 Estimated Project Timeline and Approach....................................................................................16
2.9 Project Activities and Deliverables................................................................................................17
Project Preparation............................................................................................................................ 17
Business Blueprint Phase.................................................................................................................. 18
2.10 Project Team Organization and Staffing.....................................................................................18
2.11 Roles and Responsibilities......................................................................................................... 19
2.12 Assumptions and Constraints.................................................................................................... 23
2.13 Dependencies/Related Projects.................................................................................................28
3.
Delivery Approach
29
3.1 Phases, Stages, Activities............................................................................................................. 29

Page 1
3.2 Deliverables.................................................................................................................................. 33
3.3 Notification of Deliveries and Acceptance.....................................................................................33
3.4 Installation..................................................................................................................................... 34
4.
4.1
4.2
4.3
4.4
4.5
5.
Project Governance 36
Organization................................................................................................................................. 36
Steering Committee Description................................................................................................... 36
Project Reporting.......................................................................................................................... 36
Meetings....................................................................................................................................... 38
Monitoring Of Actions.................................................................................................................... 39
Risk and Issue Management Process
40
5.1 Risk Management......................................................................................................................... 41

5.1.1
Risk Definition........................................................................................................................ 41
5.1.2
Risk Classification.................................................................................................................. 41
5.1.3
Risk Escalation...................................................................................................................... 41
5.1.4
Risk Process flow................................................................................................................... 41
5.2 Issue Management....................................................................................................................... 42
5.2.1
Issue Definition...................................................................................................................... 42
5.2.2
Issue Priority.......................................................................................................................... 42
5.2.3
Issue Escalation..................................................................................................................... 43
5.2.4
Issue Process Flow................................................................................................................ 43
6.
6.1
6.2
6.3
6.4
7.
Change control
44
Change Request Definition........................................................................................................... 44

Change Request Escalation......................................................................................................... 44
Change Control Process............................................................................................................... 44
Change Request Form.................................................................................................................. 46
Resource Management
47
7.1 On-Boarding................................................................................................................................. 47
7.2 Team Member Evaluations........................................................................................................... 47
7.3 Team Member Release................................................................................................................. 47
8.
Quality Assurance
48
8.1 Program Reviews......................................................................................................................... 48

8.2 Deliverable Reviews..................................................................................................................... 49
8.3 Quality Audits (Capgemini Projects).............................................................................................49
9.
Infrastructure Management 51
9.1 Project Infrastructure..................................................................................................................... 51

9.2 Security Management................................................................................................................... 51
10.
10.1
APPENDICES53
APPENDIX A: - Reference Documents......................................................................................53

Page 2
1. PROJECT GOVERNANCE PLAN OVERVIEW

1.1 Purpose Of The Project Governance Plan
This Project Governance Plan provides a high-level view of the SAP Project. It details the
scope, objectives and overall approach for planning and designing the SAP solution for
<client> .
The Project Governance Plan provides for a common understanding between all project
participants, helps manage expectations, and provides the guidelines and structure for
managing the SAP project.
The objectives of the Project Governance Plan are to:
Define the scope and assumptions of the project
Identify the approach required to meet <client>s requirements
Provide the quality authority with information necessary to organize quality control
activities, including transfer of information, verification actions, etc
Identify all the components to be used in the project (e.g., procedures, rules and
applicable methods) and govern both the project and the SAP solution design
1.2 Scope Of The Project Governance Plan

The Project Governance Plan covers the processes, means, and personnel for the following
domains:
Planning activities
Design activities (e.g. documentation standards, document management)
Management activities (e.g., project management, project governance, preparation of

reviews, training)
Verification activities (e.g., walk-through, review, audit)
The initial Project Governance Plan will cover the Blueprinting phase of the project. It will be
updated upon completion of the Blueprinting Phase. Estimated to be completed at end of June,
2013.
1.3 Control Of The Project Governance Plan

Preparation
The Capgemini and <client> Program Management Office (PMO) managers are responsible for
preparing the Project Governance Plan. Representatives from <client> will participate in the
production and approval of the Project Governance Plan. The following chart outlines the
Project Governance Plan responsibilities.

Page 3
Program Governance Plan

Development Activity
Responsible
Define the Model
Mickey McBroom (Capgemini)
Review and update content

based on an understanding of
<client> model
Produce draft version
Review draft
XYZ (<client>)
Project Governance Plan

finalization
XYZ (<client>)
Update the Project Governance

Plan
Approval
The Project Governance Plan approval is achieved by the signatures (electronic approval is
acceptable) of each member of the approval list presented in the review and approval section
(page 1) of this document.
After approval, a current copy of the Project Governance Plan will be stored in the document
location previously identified in the document location section (page 1).
Updating
The Project Governance Plan is a living document, and will be modified during the life of the
project as circumstances change. The PMO will maintain a change control sheet as part of the
Project Governance Plan (before the table of contents) documenting the date of modifications,
the section modified, and a brief description of the modifications.
After approval of the Project Governance Plan revisions, the most recent version will be
maintained in the <client> Project Management document location defined and earlier versions
will be archived. The PMO will notify the impacted functional teams of approved Project
Governance Plan changes.
Any team member or SAP project stakeholder may request modifications to the Project
Governance Plan. Modifications can also occur because of a corrective action. Modification
requests must be made in writing and approved by the SAP Project Management team and
<client> Steering Committee.

Page 4
2. PROJECT OVERVIEW
2.1 Project Description
The <client> seeks to implement SAP as the core ERP system for Finance, Procurement, HR,
and Reporting. The intent is to use SAP as the common ERP system across most of the
operating companies within the . Capgemini and <client> will perform work jointly to complete
a global design blueprint for <client>s operations.
The project will be primarily conducted out of <client> s Addison, Texas offices.
Capgeminis services for this phase are limited to the activities/deliverables needed to complete
a global design blueprint.
2.2 Project Objectives

<client> s goals for this initiative are to provide a system foundation to support their growth
strategy to:
Standardize business processes
Improve access to financial information
Provide tighter informational integration between various functions
Enable the <client> to more efficiently conduct business with its customers, vendors and
service providers
Limit customizations to the software to hold down implementation costs, to support

standardization of business practices
2.3 Project Critical Success Factors

Progress towards program objectives should be tracked by critical success factors. These
critical success factors are internal, business-related items that can be monitored and will have
on an ongoing basis, a major influence on whether or not an enterprise or process meets its
objectives. The critical success factors for this project are:
Involvement from key stakeholders
Dedicated project team (<client> and Capgemini) with the appropriate skill set
Executive governance and support
On time execution of project plan and key milestones to be achieved on a timely basis
Closely linked and well integrated <client> andCapgemini teams
Active involvement and quick decision making by <client>
Well documented future state business processes, KPIs, and reporting formats

Page 5
Functional leads acting as subject matter experts within <client> and adoption of their
design decisions by their Riara colleagues
Close management of stakeholder expectations
Timely review and sign off of deliverables
Monitoring competing organizational priorities (e.g. New builds)
Resolution of inadequate project management and execution
Prevention of scope expansion
Management of integration with other systems
Adequate training and rollout
Dedicated training resources identified and allocated
A robust, post implementation support model
Global design phase deliverables completed in time with sufficient details for next phase
2.4 Parameters for Decision Making

Decisions throughout the project should be considered in accordance with the following
parameters:
Limit customizations The redesign of existing transaction processes will conform to the
EnergyPath solutions best practices
Keep it simple Solutions should be simple and effective
Monitor budget and timeline The project and timeline will be closely managed with
frequent variance reporting
Control scope Project scope will be closely monitored with impacts clearly defined
before any scope change is approved
Deliver value The implementation of SAP will support the business goals that
<client>s current systems cannot
Design for tomorrow System design should accommodate future state business
requirements
2.5 Project Scope

<client> is planning to implement SAP as the ERP system across the group. The
implementation of SAP will be managed as a Program and achieved in phases. The first phase
of the SAP implementation program is to realize a common process design across Energy and
Retail companies for Finance, HR, and procurement processes. Capgemini will be engaged for
the following project phases:
Project Startup and Preparation

Blueprint

Page 6
The scope of this project is only to address the first phase of the SAP implementation program
that is to deliver a common process design within the defined project scope as set forth below.
Any Build, Testing, Training and Go-live activities are not in scope for this project.
2.5.1 Organization
Scope
2.5.1.1 In-Scope Business Entities

The following business entities will be in scope for this project:
2.5.2 Application
Module Scope
The following SAP Modules are in scope for this project:

Module
SAP FI/CO
SAP FI/CO
SAP FI/CO
SAP FI/CO
SAP FI/CO
SAP FI/CO
SAP FI/CO
SAP PS
SAP MM
SAP MM
SAP HR
Process
General Ledger Accounting (New GL)
Accounts Payable
Accounts Receivable
Asset Accounting
Treasury limited to bank integration
Cost Center Accounting
Profit Center Accounting
Project Accounting
Purchasing
Inventory Management
Organization Management
Any additional functionality will be reviewed with the Project Steering Committee for
approval and will then follow the established change order process if warranted.
2.5.3 Software
Version Scope
The scope of this project is limited to the SAP ECC versions 6.0 with EP6.
2.5.4 Business
Process Scope
The list of in-scope business processes is set forth below. The scope for these business
processes will be refined (but not changed or expanded) during the Blueprint Phase of the
Project and will be documented in the Functional Design Documents.
Finance and
Controlling
SAP ERP Module
functionality,
Design only
In Scope
The following functionality is in scope for this
SOW:
GL - General Ledger Accounting (FI-GL)
Accounts Payable (FI-AP)
Invoice entry / debit memo processing
Vendor down payments
Automatic payment program (integration
with bank)
Out of Scope
Logistics part of Project Systems
which enables project planning,
monitoring and work scheduling.
Online Credit Status and Credit
Management
Income tax calculation
Investment Management

Page 7
Finance and
Controlling
In Scope
Manual payments
Recurring entry documents such as
monthly rentals
Check printing (extract file to send)
Invoice approval workflow
SAP standard 1099 reporting
Accounts Receivable (FI-AR)
Invoice entry / credit memo processing
Cash application
Asset Accounting (FI-AA)
Asset acquisitions
Capitalization of assets under
construction
Asset transfers
Asset retirements
Standard SAP depreciation calculation
(planned and unplanned)
Integration with GL and project systems
Treasury (FI-TR) Banking and Cash
Management interface only
Standard SAP Tax Calculation
New GL Profit center accounting
Cost Center Accounting (CO-CCA)
Planning and budgeting
Manual and automatic allocation of cost
Standard roll up hierarchy and alternative
hierarchies
Project Systems (PS) Management of financial
aspect of projects- project accounting (AFE)
Capital projects
Expense projects
Integration with Asset Accounting
Accumulation and settlement of costs
Development of a high level project plan for the
implementation of SAP Business Planning and
Consolidations (BPC) Legal and Managerial
Consolidations.
Review of functional design documents to
validate finance and controlling design may not
hinder future implementation of SAP BPCConsolidation application
Out of Scope
EC-CS (SAP Consolidation module)
Financial planning, forecasting and
budgeting.
SAP Banking functionality in regards
to:
o Bank Customer accounts,
o Loans management,
o Collateral management and
o Reserve for bad debt.
Special Purpose Ledger
Lease Accounting
Travel Management

Page 8
Materials
Management
SAP ERP Module
functionality,
Design only
In Scope
Out of Scope
Standard SAP procurement functionality

Purchase requisitions and purchase orders
Request for quotation and quotation
functionality
Purchasing Contracts
Purchase Order approval process
Invoice verification to support three and two way
matching
Inventory Management to cover goods receipts,
issues and transfers
Human Resource
Management
SAP ERP Module
functionality,
Design only
Web enabling (similar to supplier

portal) of materials management
transactions
SAP's Foreign Trade (FT)
component of that supports export
and import processing
Procurement card functionality
In Scope
Out of Scope
Organization Management to support workflows
2.5.5 Development
Personnel Administration
ESS
MSS
Time management
Payroll and Benefits
Any other HR functionality
Scope
The scope of this project does not cover for any development or coding or testing of Reports
(R), Interfaces (I), Conversion (C), Enhancements (E), Forms (F) and Workflow (W). The
RICEFW requirements will be identified by the design team and documented in the functional
design documents. Any modification to the RICEFW counts as set forth below will require a
change order.
SIMPLE
MEDIUM
COMPLEX
VERY COMPLEX
TOTAL
Reports
Interfaces
Conversions
Enhancements
Forms (Printouts)
Workflow
BI Cubes
BI Reports
Portal Objects
18
22
Totals:
Definition of Complexity for RICEFW Scope

The definition of complexity of RICEFW will be based on the number of hours required for
development (coding and unit testing). The final complexity of development objects will be
agreed in writing between Capgemini and <client> during the Common Design phase.
Page 9
Very
Simple Medium Complex Complex
Conversions
58
68
87
144
Middleware
72
87
144
216
Interfaces
54
141
203
256
ABAP Reports
29
75
105
144
Enhancements (ABAP)
30
69
141
209
Forms
29
138
144
183
Portals (Webdynpro)
48
115
142
480
Workflow
48
115
142
480
Other Batch Processes
40
71
104
160
BW Cube
40
71
104
160
BW Report
19
26
36
58
For purposes of illustration, a Conversion Routing that required up to 58 hours of coding and
unit testing would be considered to be simple complexity, a Conversion Routine that required
between 59 hours and 68 hours of coding and unit testing would be considered to be medium
complexity, a Conversion Routine that required between 69 and 87 hours of coding and unit
testing would be considered to be complex, and all other Conversion Routines would be
considered to be very complex.
2.5.6 Legacy
Remediation and De-Commissioning Scope
<client> will be responsible for all activities associated with the remediation of any legacy
applications required for the Project.
2.5.7 Data
Scope
The following major data objects are in-scope for this project. The objective of the Common
Design in the area of the data is to identify and agree upon the guidelines to load the below
master data in the subsequent phases of the project.
Data Object
Master or Transactional
Vendor Master
Master Data
Customer Master
Master Data

Page 10
Data Object
Master or Transactional
GL Master
Master Data
Cost Center
Master Data
Profit center
Master Data
Cost center groups
Master Data
Profit center groups
Master Data
Chart of Accounts
Master Data
House bank
Master Data
Open AR balances
Transactional Data
Open AP balances
Transactional Data
WBS Balances
Transactional Data
GL monthly balances
Transactional Data
Fixed Asset Master and asset

balances
Material Master
Transactional Data
Open Purchase Orders
Transactional Data
Open stock
Transactional Data
Employee Master
Master Data
2.5.8 Archiving
Master Data
Scope
Any Capgemini support for archiving data is outside of the scope of this project.
2.5.9 Scope
of Support For Data Management
The responsibilities for Data Management are as set forth in the table below:
Task
Define data
conversion
requirements
and Strategy
Description
Analyze and document the
conversion scope, objectives,
approach, requirements, and the
strategy for how the conversion will
be performed.
In Scope
Yes
Work Product
Data conversion
requirements and
strategy

Responsible Party
Capgemini
Page 11
Task
Description
In Scope
Work Product
Responsible Party
Perform
conversion data
Mapping
Map legacy data files and

elements to the table(s) and
columns. This map includes an
explanation of business,
translation, foreign key rules, and
default settings where applicable
Yes
Conversion Data
Mapping
This is a joint
responsibility with
Capgemini providing
SAP experience and
the Client providing
legacy system
capability
Define Manual
conversion
Procedures
Define procedures for manually

converting applicable business
objects through SAP forms.
Yes
Manual Conversion
Procedures
Client (supported by
Capgemini)
Design
conversion
Programs
Design how the conversion

programs should be coded using
conventional programming
techniques including any
translation modules
Yes
Conversion
Functional
Specifications
Capgemini for SAP

programs
and the Client for
Legacy system
The following data activities are not in scope for the Project:
Perform conversion Business Object Tests

Perform conversion Validation Tests
Create Data Test Plan
Conduct Data Testing
Perform Data Profiling
Cleanse Data
Install conversion Programs
Convert and Verify data
2.5.10
Controls and Compliance Scope
<client> is responsible for the design and implementation of the financial controls and
compliance related activities required for this release, including, without limitation, security and
IFRS, GAAP and other internal controls.
<client> retains sole responsibility for the identification, monitoring and interpretation of, and
ensuring compliance with, any laws, rules and regulations and accounting standards applicable
to the business and operations of the Client and its affiliates (including, without limitation, their
business processes and systems). Capgemini is not providing legal or regulatory advice as
part of the Project and is not responsible for the <client>s compliance requirements.
2.5.11
Security Scope
Capgemini will be responsible for identifying security roles as a part of Common Design.
Development and Testing of the Security Role is not in scope for this project. Capgemini
anticipates providing the following resource to support the activities of the Client security team
as set forth in the RACI Table for the following periods of time:

Page 12
Roles
Start Date
SAP Security Lead (Offshore)
March 11, 2013
Ending Date
May 24, 2013
Standard SAP Role-based Security will be used for the Project. The security mechanisms for
legacy applications will not be changed and will remain as they are established as of the
Effective Date. While individual access rules within these applications may change, the security
mechanisms for legacy applications will not be changed as part of the scope of this project.
<client> is responsible for enabling all security associated with the Project including all security
activities associated with all aspects of SAP and the legacy systems. <client> will be
responsible for providing Segregation of Duties rules and design.
2.5.12
Language Scope
All Project activities and Deliverables will be created in English. There will not be a requirement
to support any language other than English. To the extent that any translation activities are
required, those translation activities will be the responsibility of <client>.
2.5.13
Currency Scope
The following currencies will be supported within the scope of the Project:
US Dollars (USD)
Brazilian Real
Turkey Lira
Note: Transactions are supported in all SAP delivered currencies as per ISO standards.
2.5.14
Geographic Delivery Scope
All Services under this project will be provided from the following locations:
<client> office in Addison, TX;
Capgemini offices or consultant home work location;
Capgemini India offices; and
The homes, hotels, and / or home offices of the Capgemini consultants assigned to
perform the Services.
2.5.15
Organizational Change Management Scope
<client> is responsible for all OCM related tasks associated with the Project.
2.5.16
End-User Training Scope
End-User training is not in scope for this project.
2.5.17
Knowledge Transfer Scope
Knowledge Transfer or <client> training is not in scope for this project.

Page 13
2.6 Scope Assumptions Concerning EnergyPath Software

The proposed approach calls for an accelerated template-based approach for the scope of
Services as set forth for the Energy and Oilfield Services part of <client>s business. Capgemini
will base the initial design and configuration of the system on Finance and minimal Procurement
standard leading practices from Capgeminis EnergyPath approach and allow <client> to review
the approach for fit. Capgemini will then proceed with developing the approach based on the
<client>s approval/acceptance of the design.
Under the accelerated approach, it is assumed that the template will be sufficient for <client>s
functional requirements. This will be validated towards the end of the Blueprint phase before
initiating the Realization phase. It is also assumed that <client> has reviewed the EnergyPath
pre-configured software and has determined is a good match for its requirements. The
schedule and budget for this project assume that EnergyPath will be installed for <client> largely
as is with very minimal changes to the pre-configured software.
There will be a formal checkpoint at the end of the first month of the project to confirm that
EnergyPath is a good match for <client>s business needs. To the extent that <client>
determines that the preconfigured software associated with EnergyPath is not a good match for
its needs, the parties will work together to determine the go-forward approach for the project.
There will also be a second formal checkpoint once the Blueprint and the Functional
Specifications are approved / accepted to evaluate the overall schedule and budget for the
project based on the then-current definition of the scope for this project.
2.7 General Responsibilities

<client> shall perform the tasks and responsibilities stated below and as otherwise set forth in
this project as a condition to the provision of Services by Capgemini.
<client> will provide the following levels of office space for the on-site Capgemini Project team:
Sufficient facilities for Capgemini resources including workspace, network access,

printer, and phone;
Conference rooms sufficient for the meeting needs of the project;
Access to all office facilities used for the Project.
Capgemini and the Client resources assigned to the same track of work will be colocated in a shared facility and have direct and reasonable access to each other to
facilitate knowledge transfer and collaboration.
2.8 Estimated Project Timeline and Approach

The estimated term of this project is twelve (12) weeks. Targeted phase start dates are
3/13/2013 for the Blueprint Phase.
The estimated project timeline is depicted in the following figure:
<timeline>
This schedule is estimated and is subject to the scope of work, Project Approach, Services,
Deliverables, approach, roles and responsibilities and assumptions/requirements set forth in the

Page 14
SOW. The proposed list of gate (entry/exit) criteria for the following project phases is provided
in Appendix A.
The plan may be adjusted based on the availability of <client> staff and/or changes in the
assumptions. Any such changes would be subject to discussion between <client> and
Capgemini Project management team and will be mutually agreed through the project change
order process as defined in the Program Governance Plan.

Page 15
2.9 Project Activities and Deliverables

This section summarizes the objectives, assumptions, activities and Deliverables which
Capgemini will assist <client> to deliver during the Project Preparation and Blueprint stages of
the Project.
Project Preparation
During the Project Preparation phase the high-level project scope will be confirmed. The
combined Capgemini and <client> project team will kick-off the project and conduct project team
training on templates, methods, and tools. Capgemini will assist in reviewing and finalizing the
Instance strategy.
Description of Project Preparation Deliverables:
Project Governance Plan (PGP) - The Project Governance Plan will detail project-specific
governance processes that may be unique from the overall Program Governance Plan. The
PGP, together with the Capgemini SOW defines the baseline for the project against which both
Capgemini and <client> will operate for the duration of the project. The PGP also provides for a
common understanding of roles and responsibilities between project participants, helps manage
expectations, and becomes the baseline against which changes and deviations to process or
product are identified and managed.
Level 1 and 2 Project Plan A level 1 project plan in ppt (GANTT) and a level 2 MS project
plan that defines the activities and tasks to be carried out by Capgemini and <client> during the
project.
Issue/Change Control Process - Formal process for managing change requests. The project
scope definition along with the structured change control process will assist program/project
management in assessing the impacts of potential scope changes with respect to the overall
project cost, schedule, and risk. The change control process will detail the escalation and
approval procedures to be used in evaluating and processing all change requests. The
objectives of change control are to preserve the integrity of the project charter, to provide a
mechanism for handling change requests, and to provide a means for retaining historical
change information.
Steering Committee Meeting Schedule Schedule of Project Steering Committee meetings
at regular intervals to review project progress, mediate any unresolved issues extending beyond
the scope of the project teams control, and approve project Deliverables.
Status Reporting Process Defines schedule and governance process for tracking and
communication of project progress to appropriate groups through regular reports and
assessments. This refers not only to vertical (up the ranks) communication, but also across
process teams and functional areas due to the need for integration between the project teams.
This will be defined in the Project Governance Plan.
Team On-boarding material - Provides key information and instructions to help transition new
project team members onto the project. It includes an overview of the project, any background
information, project vision, scope, logistics, and key contacts.

Page 16
Business Blueprint Phase

The Blueprinting Phase will define and document the solution design for the Global Design.
Description of Blueprint Deliverables:
Functional Design Documents - Developed jointly by Capgemini and <client> .The Functional
desing documents (also called Business Blueprint documents) specify the design of the new
system, including business processes and other objectives identified during the requirements
workshops. These documents are be used to define the Baseline Scope and refine the original
goals, objectives, and the project schedule and budget.
The key work products for this deliverable will consist of:
Functional Design Documents narration of requirements, scope, and key design

decisions in Word document template
Swim Lane Process Diagram Visio diagram of the sub-process transactions and roles.
High Level Functional Specification for RICEF Developed jointly by Capgemini and
<client> and consists of documentation of development requirements to mitigate a functionality
gap.
Security Strategy - Covers the business, functional and technical strategy related to the future
state design and ongoing support of security for the Manufacturing project. It also consists of
documentation outlining the security requirements of user access to SAP in the environments of
Development, Testing, Pre-Production, and Production (including post implementation support).
Data Migration Strategy Developed jointly by Capgemini and <client>. The strategy outlines
the methods and tools by data object. The strategy outlines the data validation and loading
procedures.
2.10
Project Team Organization and Staffing
This Charter is based on the assumption that Capgemini will be responsible for staffing the
following roles and hours (with target start and end dates) on the Project team:
Role
Project Manager
Project QA
Project Account
Executive
PMO Consultant
Finance to Manage
Lead
Finance to Manage
Consultant
Estimated
Start Date
Estimated End
Date
Estimated
Hours
03/04/2013
05/24/2013
540
03/04/2013
05/24/2013
54
03/04/2013
05/24/2013
27
03/04/2013
05/24/2013
540
03/04/2013
05/24/2013
540
03/04/2013
05/24/2013
540

Page 17
Hire to Retire
Consultant
Procure to Pay
Consultant Consultant
Procure to Pay
Consultant
Business Planning &
Consolidations
Consultant
Development lead
-Offshore
Finance to Manage
Consultant -Offshore
Finance to Manage
Consultant Brazil
Procure to Pay
Consultant - Brazil
03/04/2013
05/24/2013
480
03/04/2013
05/24/2013
540
03/04/2013
05/24/2013
135
03/04/2013
05/24/2013
216
03/04/2013
05/24/2013
480
03/04/2013
05/24/2013
480
03/11/2013
05/24/2013
440
03/11/2013
05/24/2013
440
Total Hours
5,542
The Project Governance Plan (PGP) is based on the assumption that <client> will be
responsible for staffing the following full time roles (with target start and end dates) on the
Project team:
Estimated
Start Date
03/04/2013
Estimated
End Date
05/24/2013
Finance to Manage Lead
03/04/2013
05/24/2013
Procure to Pay Lead
03/04/2013
05/24/2013
Role
Project Manager

Page 18
2.11
Roles and Responsibilities
The Project will require the collaborative team work of <client> and Capgemini.The prime
responsibilities of these organizations are:
<client>
Organization
Primary Role
Client and process/system owner
Capgemini
Systems integrator
The table on the next page illustrates the allocation of responsibilities between <client> and
Capgemini during the Project:
Role
<client> Project
Lead
Capgemini Responsibilities
Achieving project milestones Oversees the

quality of the project Deliverables
Capgemini project liaison with the <client>
Steering Committee members and Project
Sponsor
Coordinates and oversees the development
and management of the consolidated work
plan
Assists with the day-to-day management
and execution of the <client> Solution
Implementation work plan
Provides leadership and guidance to the
<client> Program
Reviews project Deliverables for quality and
completeness
Oversees communication and issues related
to the <client> project; anticipates
roadblocks and works to reduce and/or
avoid them
Oversees Capgemini resources and staffing
Helps maintain the integrity of the <client>
Core Solution Design
Tracks and controls project scope
Finance to
Manage Lead
Oversees Financials domain project

Deliverables and day-to-day management of
the functional area.
Provides SAP functional and management
leadership and guidance to the <client>
FI/CO lead
Organizes functional team workload, e.g.,
Business Process Documentation, Issue
Resolution, and Development Support.
Organizes Capgemini involvement in
functional team meetings, and related
workshops or testing sessions
Facilitates the communication and resolution
of domain related issues to Capgemini &
<client> Project Management
<client> Responsibilities
Achieving project milestones

Oversees the quality of the project
Deliverables
<client> project liaison with the
<client> Steering Committee
members and Project Sponsor
Coordinates and is responsible for the
management of the <client> aspects
of the Solution Implementation
consolidated work plan
Reviews project work products for
quality and completeness
Manages communication and issues
related to the <client> project;
anticipates roadblocks and works to
minimize and/or avoid them
Oversees Riara resources and staffing
Helps Maintain the integrity of the
<client> Core Solution Design
Tracks and controls project scope and
budget
Oversees Finance domain project

Deliverables and day-to-day
management of the functional area.
Organizes functional team workload,
e.g., Business Process
Documentation, Issue Resolution,
and Development Support.
Organizes <client> involvement in
Facilitate the communication and
resolution of domain related issues to
Capgemini & <client> Project
Management
Confirm that business expertise is

Page 19
Role
Validates integration design with other

domains
Produces documentation during all phases
Actively participates in change management
available to the project team

Signs off on Finance design
Validates integration design with other
domains
Produces documentation during all
phases
Actively participates in change
management
Purchase to Pay
(MM-IM, PUR) Lead
Oversees the PTP domain project

Deliverables and day-to-day management of
the functional area.
Develops team project plan and monitor and
adjust the plan as needed
Provides SAP functional and management
leadership and guidance to the<client> PTP
lead
Organizes functional team workload, e.g.,
Business Process Documentation, Issue
Resolution, and Development Support.
Organizes Capgemini involvement in
Facilitates the communication and resolution
of domain related issues to Capgemini &
<client> Project Management
Assists <client> by providing SAP/process
experience to the project team
Assists <client> by reviewing that knowledge
transfer is happening within the team.
Reviews team Deliverables to confirm that
they are complete in accordance with SOW
requirements.
Oversees the PTP domain project

Deliverables and day-to-day
management of the functional area.
Develops team project plan and
monitor and adjust the plan as needed
Provides <client> leadership and
guidance to the Capgemini PTP lead
Organizes functional team workload,
e.g., Business Process
Documentation, Issue Resolution,
Development Support
Organizes <client> involvement in
workshops
Facilitates the communication and
resolution of domain related issues to
Capgemini & <client> Project
Management
Ensures that business expertise is
available to the project team
Ensures that knowledge transfer is
happening within the team.
Reviews team Deliverables to confirm
that they are complete in accordance
with SOW requirements.
Process Team
Members (FTM,
PTP, HCM)
Works with <client> counterpart to document

the design documents and other project
deliverables
Works closely with the technical
development team and legacy development
team in the design and development of the
Master Data development objects (reports,
interfaces, conversions, forms and
enhancements)
Provides SAP Master Data leadership and
guidance to their <client> counterpart.
Works with the master data team on data
migration and mapping activities
Works with <client> to confirm that
knowledge transfer is happening with their
counterpart
Performs the development of the

Master Data design
Works with Capgemini counterpart to
document the design document and
other project deliverables
Works closely with the technical team
and Legacy team in the design and
development of Master Data reports,
interfaces, conversions and
enhancements
Assist with the development of the
training materials and documentation
Confirms that knowledge transfer is
happening with their counterpart

Page 20
Role
Development Lead
Achieving development milestones

Oversees development Deliverables
Provides leadership and guidance
throughout the implementation
Oversees Capgemini development
resources with respect to the timeliness of
Deliverables Acts as a focal point for
offshore development activities
Implements the Capgemini distributed
delivery framework
Defines with <client> the standard
templates for development
Achieving development milestones

Oversees development Deliverables
Provides development leadership and
guidance throughout the
implementations
Basis/Security
Manages and executes SAP installations,

upgrades and system patches
Configures, monitors, tunes, and
troubleshoots the SAP technical
environment on an ongoing basis
Maintains documentation of system set-up
Manages and executes SAP

installations, upgrades and system
patches
Configures, monitors, tunes, and
troubleshoots the SAP technical
environment on an ongoing basis
Maintains documentation of system
set-up
Develops and manages transports
from one environment to the next
Performs checks, tasks, and backups
within the technical environment
Works with the domain and
development teams to support
<client> planning and execution of
volume and stress tests
Configures network devices, such as
printers, within the SAP environment
Develops and manages transports from one

environment to the next
Performs checks, tasks, and backups within
the technical environment
Works with the domain and development
teams to support <client> planning and
execution of volume and stress tests
Works with <client> counterpart to transfer
knowledge
Configures network devices, such as
printers, within the SAP environment
Data Management
Lead
Achieves data migration project milestones

Oversees data migration project
Deliverables
Provides leadership and guidance
throughout the Final Preparation and GoLive of the platform implementation
Oversees Capgemini data migration
resources with respect to the timeliness of
Deliverables
Acts as a focal point for offshore data
migration activities
Defines with <client> the standard
templates for data migration
Achieves data migration project

milestones Oversees data migration
project Deliverables
Provides data migration leadership
and guidance throughout the Final
Preparation and Go-Live of the
platform implementations

Page 21
2.12
Assumptions and Constraints
The following assumptions support the timelines, deliverables, and roles and responsibilities set
forth in this project charter. Any adjustments or changes to these assumptions may require a
Change Order.
No.
Category
Assumption / Constraint
1.
Project
Management
The <client> Project managers will be available for a daily checkpoint meeting if
required by Capgemini. Due to time frame and the complex nature of the work,
<client> and Capgemini will work to control scope in order to keep this Project within
the agreed upon timeframe.
2.
Project
Management
<client> will be responsible for procuring and coordinating the necessary resources
from 3rd party vendors.
3.
Schedule
Capgemini is not responsible for missed dependent Deliverables from other program
tracks or parties. Delays to the Project caused by SAP product defects or other
legacy system dependencies will be subjected to the formal Change Order process
to secure additional funding for time extensions.
4.
Schedule
Any changes to the terms of the SOW, including but not limited to the assumptions,
approach, or Deliverables given throughout this document may require a change
order.
5.
Schedule
Any changes to the project schedule as a result of a change in non-availability or

poor quality of environments, master data or transactional data Deliverables,
business documentation Deliverables, regression testing or validation Deliverables
may result in a change order.
6.
Schedule
Any changes or delays to the project schedule resulting from business user adoption,
training, communication, or other organizational change management issues outside
of the control of the Capgemini project team may result in a change order.
7.
Scope
Acquisitions, mergers, and expansions are out of scope of this project.
8.
Scope
The Blueprint will define the shape and size of the future state design. Detailed
Functional Design and Technical Design will be done early in the Realization Phase.
The full configuration of the system will take place in the Realization phase of this
Project. The end of the Blueprint phase will include a reappraisal of the original
Project estimates, approach and timeline. Any changes in scope will be evaluated
and subject to the Change Order process.
9.
Scope
Our estimates and fees assume that the Project team will leverage the existing
<client> Business Case, Current State documentation and SAP fit analysis, and that
these documents are comprehensive and up to date. Any additional current state
documentation developed by the Project team will be at a high level and focused on
only those areas where <client>s processes are unique.
10. Scope
Our estimates for Current State Process Modeling assume that all documentation
(BPP, business maps, process flows, functional, technical specification, test scripts
etc.) of the as-is processes will be made available to Capgemini at Project start. The
assumption is made that the information in this documentation is accurate and any
changes over the life of the Project (other than to add additional information as the
details of the Project are understood) will be communicated as they are known. If the
change is significant, or impacts completed Deliverables or work in progress, this
may result in a change order. It is also expected that this current state processes
and requirements will need to be revised to correspond with the SAP software
package and that changes will be made in the requirements set-forth in the current
state documentation to correspond with the base functionality provided in SAP.
Current business process maps are out of scope.

Page 22
No.
Category
11. Scope
The complete list of Deliverables that Capgemini will coordinate is specified in the
SOW. Any Deliverables not specified in this SOW are out-of-scope.
12. Scope
The complete list of roles and responsibilities for Capgemini is given in the SOW.
Any other roles and responsibilities not specified in the SOW are out-of-scope.
13. Scope
Our software implementation strategy is to implement an ERP package in an as

delivered state and configure the package parameters using standard SAP
functionality to meet business requirements. It is assumed that <client> will
aggressively seek a vanilla (no customization) implementation. Where the
application does not meet the requirements of the current business practices,
Capgemini will identify modifications to the SAP business practices to take
advantage of the softwares features and functions. Any changes to the software,
extensions to the software, or any other non-standard software will require approval
by the Project Steering Committee and will go through the Change Order process.
14. Scope
American English will be supported as the primary language for the system. Support
for any other language is not included in the estimate and will result in additional
development and testing hours not currently included in the estimate. The only
exception to this is where outputs are required to be in local language to meet
statutory and regulatory requirements. In such cases, <client> will be responsible for
identifying these requirements and the translation and validation activities.
15. Scope
ECC 6.0 EP6 will be used as part of this Project. Should a different release be
required after the start of the Project, a Change Order and potential change in
schedule will be required to implement that revised version of the application.
16. Scope
Our approach and price assumes that the software package version selected by
<client> works as described by SAP and is a stable product that does not include
either functional or performance defects. The assumption is made that <client> will
contract with SAP for the resolution of functional or performance defects that are not
caused by Capgeminis configuration activities. Any delays associated with
functional or performance defects in the SAP system are outside of the scope of the
estimates provided.
17. Scope
The Project scope does not include modifications to <client>s legacy systems
resulting from changes associated with the SAP Implementation. All design,
development and testing of changes to <client>s legacy systems will be <client>s
responsibility and will be completed as indicated by the Project timeline.
18. Scope
Standard SAP reports and ad-hoc queries will be used when available instead of
creating custom reports.
19. Scope
<client> is responsible for the functionality and performance of legacy systems that
require interfaces to the new system.
20. Scope
Specifications for RICEF (Reports, Interfaces, Conversions, Enhancements, Forms)

objects developed during Blueprinting will be high level functional specifications only,
sufficient to drive work development effort estimates. More detailed functional and
technical specifications that contain the specific rules for each of the RICEF objects
will be developed as part of the Realization Phase of this Project.
21.
Scope
<client> is responsible for any changes to business processes outside of SAP.
Scope
Decommissioning of legacy applications is the responsibility of <client> and is

outside the scope of this project.
22.
23. Scope
The <client> Basis SMS will lead the sizing activities. <client> will make the final
decision with regards to hardware sizing.

Page 23
No.
Category
24. Technical
Environments
<client> will be responsible for the cost of the hardware, software, networking costs,
and support of all required development, testing, Performance Testing (including
production sized environments), training, production, and post-implementation
support environments. <client> will size these environments sufficiently to provide
reasonable network and online response times and batch compile and run
times/throughput. <client> will institute regular "back-up" procedures to prevent the
loss of data throughout the life of the Project.
25. Technical
Environments
A Virtual Private Network (VPN) environment will be available for remote access to
<client> facilities, and to support remote Project working as required. The cost of this
network connection is included in the separate Capgemini Operations Management
SOW and as such is not included in this SOW. If the Operations Management SOW
is not in effect at the time this project starts, then the VPN costs would be added to
this project SOW via the change order process defined in the Master Services
Agreement.
26.
<client> is responsible for scheduling of batch processes and for the setup and
testing of all automated batch scheduling tools.
Technical
27. Technical
<client> will be responsible for the procurement, cost and installation of software
adapters required based on the business design from Blueprint.
28. Technical
Capgemini will use its standard development process for both onshore and offshore
development. <client> developers assigned to the project will use this process.
29. Technical
<client> will assign necessary legacy resources in order to complete detailed legacy
interface analysis early in Realization.
30. Technical
The RICEF estimates developed in Blueprint are based on high-level functional

specs and the teams assessment of complexity. During Realization, a detailed
functional specification will be developed and approved by <client> for each
development object. A technical specification will then be developed by the technical
team, and based on that technical specification, the object will be re-estimated.
31. Technical
<client> will be responsible for establishing and tuning the technical environments.
<client> will also be responsible to contract with SAP for the resolution of any
performance or functional defects in the SAP systems that are not the result of the
Capgemini configuration activities.
32. Technical
<client>is responsible for disaster recovery.
33. Application
Security
Security will be configured using delivered functionality (e.g. role-based/position

based design). Any customizations will be determined in Blueprint and be subject to
the project design and scope approval process
34. Data Conversion
<client> will be responsible for data quality and cleansing. <client> will be
responsible to extract all data from the legacy systems, cleanse this data, test the
data, and put it into the structures and format required for the new system.
35. Data Conversion
Capgemini assumes that the quality of converted data is good. Any time or effort to
verify the quality of existing data or to resolve testing defects associated with
converted data may be subject to a change order.
36. Training
<client> will provide classrooms for end user training and will take responsibility for
ensuring that networked computers in the classrooms function properly.
37. Training
The project will use a Train-the-Trainer approach for training delivery. This includes a
representative from each impacted constituency group (<client> Resource) that
provides input and validation to training development.

Page 24
No.
Category
38. Staffing
Key executives and process owners will be available for interviews to enable
Capgemini to gain an understanding of the overall future vision, current business
processes and applications. Process owners will take an active role in shaping and
signing off the future state design, as well as promoting the future state design to the
rest of the organization.
39. Staffing
At the commencement of the Project and throughout the entire Project, <client> will
provide Capgemini access to appropriate and sufficient subject matter experts for
each functional area. Identified <client> individuals that will participate in the Project
will have the depth of knowledge to understand the required inputs and outputs of the
process and understand the information available at the company level.
40. Staffing
<client> core team members will need to meet a full time Project commitment during
the time that they are assigned to the Project.
41. Staffing
Core Project resources identified within the plan must have the required skills and
training and be available according to the resource deployment dates defined in the
plan.
42. Staffing
Capgemini will utilize the 3-4-5 schedule for out-of-town resources assigned to the
Project. This plan includes: five (5) days assigned to the Project; a minimum of four
(4) workdays on site; and if the schedule allows in Capgeminis discretion, a virtual
day on Monday or Friday in which the out-of-town team members are devoted to
completing <client> Project work from their home office location(s). From time to
time and as necessary, Capgemini will work 5 days a week at <client>s office.
Capgeminis adherence to this schedule shall not relieve Capgemini of its obligations
to meet deadlines or Deliverables.
43. Staffing
<client> core team members will be available to review and approve project
communications and training materials, as needed
44. Staffing
<client> will identify super-users as applicable, these super-users will be identified

and receive training before go-live. Super users are deployed on-site to train, triage
and assist end users during project roll out
45. Pricing
Training-related expenses for <client> Super Users and End-Users, including but not
limited to production of training materials, job aids, webcasts, and training facilities, is
not contained in Capgemini pricing and will be billed at cost
46. Decision Making

and Design
Acceptance
Many of the Deliverables will be delivered in sections. Once a given section is

approved by <client>, that section will be frozen and material changes can only be
changed via a Change Order. The only exceptions to this will be (a) instances in
which the document must be changed because the overall Deliverable will not work
technically, and (b) instances in which an earlier approved section of the Deliverable
must change to correspond with a later not-yet-approved section of the Deliverable
which technically cannot function correctly due to the design set-forth in the earlier
(approved) section of the Deliverable.
47. Decision Making

and Design
Acceptance
In the event that issues are not acted upon by <client> within the specified time
frames, this Project may be delayed. In the event of the delay, overall fees may
increase and timeframe/ delivery dates may change.
48. Decision Making

and Design
Acceptance
Capgemini shall be entitled to rely upon the accuracy and completeness of any data
or information provided by <client>, its representatives or advisory without
independent verification by Capgemini.
49. Decision Making

and Design
Acceptance
<client> is ultimately the expert in its business, processes and systems. While
Capgemini has professional experience in <client>s industry and the technology
used on this Project, Capgemini is ultimately relying upon <client>s expertise in its
business, processes and legacy systems to define the requirements for this Project.
<client> will be ultimately responsible to review and approve all Deliverables. Once
these Deliverables are approved, Capgemini will have the right to rely upon <client>s
acceptance of these Deliverables as the basis for subsequent work on this Project.

Page 25
No.
Category
50. Facilities
<client> will provide 24/7 access to all office facilities used for the Project. Sufficient
facilities, workspace, network access, printer, phones and Capgemini network access
will be available for Capgemini resources in <client>s facilities.
51. Legal
Capgemini will not provide <client> with legal, financial, tax, or regulatory advice. To
the extent applicable to the any of the services, <client> will consult with and rely
exclusively on its own legal counsel and financial representatives (or other
appropriate representatives) for advice.
<client> is solely responsible for determining its requirements and specifications to
address its Sarbanes-Oxley compliance. Capgemini is not providing any legal advice
and therefore does not warrant that any services it provides will assist <client> in
being compliant with Sarbanes-Oxley requirements.
52. Legal
<client> will enter into contracts or licensing agreements directly with all third party
vendors. Capgemini will not enter into any contracts or licensing agreements on
behalf of <client>.

Page 26
2.13
Dependencies/Related Projects
The current list of defined projects and identified inter project dependencies is summarized on
the Portfolio Milestone Plan in the PMO T-Room and maintained in Clarity:
Ref.
Project Name/Description
Dependency
Actions Required by
<client> Project

Page 27
3. DELIVERY APPROACH
3.1 Phases, Stages, Activities
The <client> Project will be implemented using the Project Phases, Stages, and Activities as
defined within the iSAP methodology.
DELIVER is Capgeminis Global Methods Environment. We will use DELIVER for the SAP
projects including the <client> Project. This methodology is supplemented by approaches,
techniques, and hints drawn from experienced Capgemini SAP practitioners.
iSAP defines the SAP project in 6 distinct phases:

Project Preparation
The Project Preparation phase provides initial planning and preparation for the Pegasus project. iSAP defines activities
for this phase to provide the infrastructure, processes, and procedures needed to allow the teams to move forward in
an integrated manner. Key Objectives:
Implement the UPM infrastructure
Define project governance
Set up Solution Manger and Solution standards
Have initial meetings and site visits to orient the teams
Plan and conduct the End to End Value Stream sessions
Plan and conduct the project kick-off to train the joint project team
Blueprint
The objective of Blueprint is to design and document the Solution to the detailed level required to Configure the system
and define the technical infrastructure. iSAP templates and techniques are designed for more accurate,
comprehensive definition of the Solution Blueprint. The team must also prepare for the Realization Build (next) phase.
Realization Build
This phase is dedicated to building and testing the individual components of the Solution. iSAP defines configuration
as proceeding logically (one work package) in the order of the End to End business processes: Organization
Structures, Master Data, and Business Processes. The team also prepares for the next phase (Realization Test),
including preparing the detailed plans and schedules and preparing the Testing infrastructure and prerequisites. Data
Migration is launched during this phase, including a first test load.
Realization Test
Realization Test centers on testing the end to end business processes as business scenarios and variations of those
scenarios. Data Migration work must complete by the end of this phase. Cut-over plans must be completed in
preparation for the next phase. iSAP stresses the re-use of standard Integration Testing strategies and Test Case

Page 28
templates. The work is accelerated by the SAP Value Stream sessions (Project Preparation phase) where the End to
End processes are reviewed and different scenarios and variations are initially catalogued.
Final Preparation
and Go-Live
All of the work of the iSAP Solution and enabling streams come together to plan, practice and execute the production
cut-over. The project team works closely with the business to prepare users, systems, processes and sites and proves
out the approach in one or more Dry Run rehearsals of the production cut-over. iSAP templates allow the team to
focus on preparing the business rather than creating templates.
Support
This support phase is a pre-determined (usually by contract) period of time after the production go-live, when the
system is intensely supported by the project team. Usually this period extends through the first monthly financial
close after the go-live. iSAP provides Hypercare strategy and schedule templates as well as process monitoring
templates and batch job.
The iSAP project is delivered by 6 work streams:

Business Process
Business Process is the focal point of the iSAP method. This stream focuses on identifying how people and systems work
together to:
drive value from lean end-to-end processes,
identify measurable opportunities to improve process through SAP-enabled changes,
work with the OCM stream to communicate business process changes,
deliver the training and education of business process changes,
facilitate the communication of the Solution strategy throughout the multiple layers of the
organization.
Development
The Development stream includes all the development, testing and documentation of the software required for the SAP
implementation project. This includes ABAP, portal, Java, Middleware, etc areas. iSAP requires a critical path approach to
sequencing Development work. The Development team must understand the critical path work, typically prioritizing go-live critical
development (e.g. Interfaces).
Data Management
This stream supports activities related to the management of data in the new SAP systems from the definition to the migration process
into the SAP system. The primary objective is to ensure the data needed by the users is included in the new system in an accurate
and usable manner. Like the Development stream, iSAP stresses a critical path approach to defining and managing the Data work.
Technical
Infrastructure
Within the Technical Infrastructure stream, the team focuses on designing, implementing and maintaining the technical infrastructure
of the SAP based solution. This scope includes Development, Quality Assurance, and Production instanced of the SAP platforms.
This also includes set up of the systems, networks, administration and other infrastructure-related activities. iSAP does not provide
specifc templates other than stressing the simple approach of managing the Technical Infrastructure milestones and not the detailed
activities.
Organization Change
Management
The primary objective of the Organizational Change Management stream is to adequately prepare people, process and technology for
the business transformation. It requires early identification of process and organizational improvement opportunities within the context
of the ERP system, continuous communication across the organization, and readily available training materials. iSAP stresses the
early identification and mobilization of the Change Leader Network to enable the OCM activities.
Project Management
This stream focuses on delivery governance up activities which are specific to the SAP implementation project; and occur during
Project Preparation phase. The primary objective is to prepare the team to execute the project using established standards and
procedures. iSAP provides Project Management with a standardized Project Plan approach supported by Lean Visual Management
tools.
Project Preparation Phase

The Project Preparation Phase is brief but it sets the stage for the Blueprint Phase, so it is
important that the project management team and project team leads:

Page 29
Are each aware of the repository of existing information and the purpose of each of
those Deliverables
Understand the project plan and their specific responsibilities to deliver to the schedule
Understand the roles and responsibilities of the other team leads and members, so that
they are aware of who to involve as questions arise
The Project Preparation Phase comprises the following main activities:
Team lead on-boarding
Development of a detailed project plan, with clear milestones along with processes for
measuring performance versus plan and resolving deviations from the plan. This will
include identification of project team resources.
Identifying <client> business participation required for workshops and informing the
business leadership of key dates
Establish the project governance program
Implement the project tools and infrastructure. Create project directories. Establish
project templates/standards for minutes, agendas, team communications, etc.
Communicate with related initiatives. Establish communication with all related initiatives
and work streams (e.g. Other projects within <client>, SAP Infrastructure set up)
The project team will participate in the 1-2 day Project RapidStart session. This
session will get the combined <client>/Capgemini team grounded in the project
processes and procedures such as status reporting, time collection, issue management,
risk management, and scope control.
Draft questionnaires for information gathering for Blueprint Sessions
Identification of <client> stakeholders and creation of a targeted change management
communications plan
Set up of sandbox and development SAP environment for teams use during blueprinting
and beyond to build the <client> system and allow the system to be shown during
blueprinting, as needed. The sandbox will be pre-loaded with the EnergyPath Solution.
These tasks will be the responsibility of <client>s hosting provider.
Prepare for Blueprint Phase kick-off. This involves both preparing for the blueprint kickoff meeting, scheduling attendees and doing a first pass at the timing of design
workshops
Blueprint Phase
The Blueprint Phase will commence with a one day team kick-off meeting where the full team,
including all significant part-time team members, will be introduced to the scope, timeline,
responsibilities, team organization, tools, methods, standards and expectations as they come
on board.
It is recommended that the <client> team leads take a very active part in this session, to
establish themselves in their positions and to take ownership of their area from the start
The draft design workshop schedule will also be reviewed and the schedule and
attendees adjusted to take into account other commitments.
The team leads will commence preliminary design, covering major scope items and
establishing the global settings/decisions within SAP which set the constraints around
which the business and the team will operate.
Functional/Process Design Stream
Rapid Design Workshop Breakdown
Page 30
o
o
The majority of Blueprint Phase will be spent in Rapid Design workshops, working
initially as a full team to absorb the major decision parameters which will affect each
team (<client> organizational structure, Chart of Accounts etc.).
Generally, the next set of workshops are team specific, with a focus on scope by
functional area.
As progress is made on functional design, the teams will organize multi-functional
team discussions to discuss integration points. These discussions will culminate to
structured walk through of each end to end process.
Sub-activities, within the Rapid Design Workshops
Within the design workshops, the teams will confirm <client>s detailed requirement
are addressed by SAP configuration options, revising business process workflows
and documentation (Business Requirement Documentation-BRDs) (for team design
use and later use during training); agreeing data mapping from existing systems and
also for data to be gathered for project go-live.
Towards the end of the Blueprint Phase, the design workshops may be expanded to
involve the full team and also the future trainers and other key individuals identified
as part of the change management stakeholder analysis. These review workshops
would be decided on a case by case basis, with the team leads working with the
project management and change management teams
Each of the design workshops will comprise a mixture of process flow reviews,
process discussion and demonstrations of the configured EnergyPath, where
appropriate. To facilitate communication across the organizations stakeholders, it is
proposed that design documentation is updated at each session or within one day, so
its ready for review by a wider audience within two days, in general. This is assuming
that the design schedule has suitable gaps built in to allow time to document between
other activities.
The objective for each of these workshops is the development of best practices
across <client>, leading to standardization based on SAP.
During the initial workshops Capgemini recommends that an early assessment of team
member abilities and role-effectiveness is carried out, along with a review of the alignment
within the organization.
Data and Technical Stream

The functional teams will also start drafting the requirements for data migration and
establish the formats required for the key data, this will be expanded upon as the more
detailed design decision are made on items such as catalogue standards, naming
conventions etc. during blueprint
Identify and design the R.I.C.E.F.W. (Reports, Interfaces, Conversions, Enhancements,
Forms and Workflow) elements, allowing the functional specifications to be developed and
approved for key elements.

Page 31
3.2 Deliverables
During each phase of the Project there are a number of key deliverables that are expected to be
created. Capgemini will monitor the preparation and presentation of these deliverables to
<client> . Capgemini will provide <client> with status reports (weekly) articulating the progress
towards the completion of the deliverables and activities.
3.3 Notification of Deliveries and Acceptance

The Notification and Acceptance process will occur at the major deliverable level using the
approach defined below. Acceptance processes and criteria will follow the guiding principles set
forth below:
Acceptance and sign-off of all major deliverables will be performed by the <client> Project
Manager in conjunction with a gate review process. The <client> Project Manager has sole
authority to accept or reject on <client>s behalf.
In the event acceptance is not granted, the Riara Project Manager will clearly define in
writing the deficiency(ies) as it relates to not materially meeting the mutually agreed upon
criteria applicable to that deliverable along with any associated specifications. Acceptance
is expected upon the identified deficiencies being re-reviewed and addressed and limited to
the initial markups only.
The operational approach and decision-making used in the gate review acceptance process
and by the Project Manager will be consistently applied to deliverable acceptance regardless
of the party accountable or responsible for the deliverable i.e. completion of deliverables
for which <client> is responsible will follow the same processes and standards applied to
Capgemini deliverables.
All deliverables submitted to the <client> Project Manager will generally be reviewed for
approval within an appropriate amount of time, generally to be less than 3-5 days.
For most deliverables, with exception of the high volume process / configuration/
development deliverables, the deliverable will be submitted for gate review on the date it is
scheduled for completion (usually a Friday), and reviewed for acceptance the following
Wednesday..
The standard process for deliverable acceptance will be as follows:
A standing weekly gate review meeting will be scheduled (used as needed) on

Wednesdays.
Deliverable completion dates will generally be scheduled on Fridays, and the

applicable gate review document will be submitted the Friday prior to when the Gate
Review is scheduled to approve completion of the applicable deliverable(s) per the
mutually defined acceptance criteria defined during Project Startup.
The Gate Review Team will review the submitted Gate Review Executive Summary
document, as well as the underlying deliverable materials as needed, in preparation
for the Gate Review meeting.

Page 32
The Gate Review meeting will focus on exceptions or questions related to the
deliverables, and the <client> Project Manager will determine if the deliverable is
accepted, is accepted with conditions or is rejected.
If a Work Product is accepted with conditions, then the conditions will be reviewed
in the next gate review, or the next mutually agreed gate review
The Capgemini PMO Analyst will publish minutes from the Gate Review,
summarizing the Gate Review outcomes, including any specific conditions to be
addressed before finalizing a deliverable, or actions required to be taken in order to
resubmit for approval after the deliverable was rejected.
Deliverables approved with conditions are considered completed on time.
Standards and expectations for deliverables will be defined either before the work
begins or at project initiation and may be refined before the applicable phase of work
begins.
The general acceptance approach and criteria applied to other deliverables will follow common
SAP ASAP standards for completeness and detail, and as outlined in templates or examples
reviewed and mutually approved by <client> and Capgemini before the work is performed.
Deliverables will be stored in one of two locations:
Solution Design and Build Deliverables: stored the project T-Room
Project Management and Implementation Deliverables: stored the project T-Room
3.4 Installation
SAP Project Landscape
Installation of the systems landscape to support a multi SAP project environment is the
responsibility of <client>. The Technology and Architecture function of the PMO will assist in
providing advice on the landscape strategy.
The current version of the Landscape Strategy is housed on the PMO T-Room:
Key to the landscape strategy is the use of parallel project environments structured around
planned releases of functionality into production. The determination of which environment a
project will be developed in (Production support (N), Project Landscape (N+1), Project
Landscape (N+2) etc) is the joint responsibility of the <client> Infrastructure Team, PMO
Architecture & Technology function and the Project Management team. This decision will be
based on factors including the:
Planned go live date

Degree of integration with other projects occurring at the same time
Current project landscapes available
Overall <client> Landscape Strategy

Page 33
PMO Tools:
The PMO toolset is defined in the <client> Program Governance Plan.
Clarity and T-Room capabilities will be provided via Capgemini. MS Project will be provided by
<client> for <client> IT partners and Capgemini for Capgemini personnel. Solution Manager will
be provided by <client>. Overall maintenance of this toolset will be coordinated by the PMO
and the <client> IT Infrastructure group.

Page 34
4. PROJECT GOVERNANCE
4.1 Organization
The project follows the following heirarchy:
Capgemini
<client>
Project Governance
Project Management
Team Leads
Team Members
4.2 Steering Committee Description

As the final decision makers on any critical issues, the ERP Steering Committee will play a key
part in ensuring that the system design is in line with the <client> management teams vision of
the future. The Steering Committee will make Go/No Go decisions, offer direction for the project
as needed, and resolve any major issues. The Steering Committee is also, collectively and
individually, one of the critical success factors in facilitating change throughout the <client>. The
Steering Committee will consist of the management team from <client> as noted in the Project
Structure. The Steering Committee meetings will be led by the <client> and Capgemini PMO.
Selected advisors from the leadership team of services providers will attend Steering Committee
meetings. During the course of the SAP project the Steering Committee will be tasked with the
following:
Providing guidance and oversight
Upholding the interest of <client> holistically
Resolving escalated issues in a timely manner
Approving changes to the system design and implementation strategy
Monitoring the progress and organizational impact of the project and supports adoption
of the production system
The Steering Committee will consist of the following executives:
Organization
Name
Role

Page 35
4.3 Project Reporting

This section provides templates for each of the reporting levels highlighted above, as well as the
report submission process and meeting calendar.
The project will follow a 3 level project reporting framework:
Level 1 Overview charts will be maintained in MS Powerpoint. Level 1 is used for

communications purposes and for high level modeling of plan options.
Level 2 is the Step project plan, initially created in MS project, loaded to Clarity. The Level 2
plan will be structured by phase: Startup, Blueprint, Realization, Final Prep and Rollout, plus,
the plans will be structured around the 7 project stream teams (4-Process, Data, Development,
Basis/Infrastructure). Object-based work statuses will be rolled up from the Level 3 task plans.
Time will be entered by team members at the Phase/Team level (as dictated by the Program
Governance Plan).
Level 3 is the detailed task and object plans for the 3 teams. The Object based work will be
tracked in MS Excel templates based on object/activity listings.
Project Managers will be responsible for updating their project status in their Excel Level 3
Plans on a weekly basis.

Page 36
The dashboard includes a summary analysis from each teams detailed Excel item task lists,
including:
Overall Status in terms of Schedule, Resource, Cost/Scope

Progress by work product/deliverable based on detailed object lists in the workbook
tabs
High Priority issues
The above items will form the Weekly Project Status Report pack and will be submitted to the
PMO T-Room shared folder structure by 1pm on Monday:
4.4 Meetings
All meetings for the project will be planned in a manner that supports facilitating effective
decision making. Action items and decisions discussed during the meetings will be collected
and distributed as appropriate. Action items will clearly identify target due dates and owners
and any information on key decisions will be captured as a reference for attendees, nonattendees, and for project management. The meeting hierarchy and schedule for the project is
outlined below:

Page 37
Meeting
Type
Meeting
Leader
Meeting Participants
Frequency
Duration
Steering
Committee
Meeting
<client>
Project
Manager
<client> Sponsors:
Capgemini Account
Executive: John Clark
Monthly
1 hr
Project
Status
Meeting
Capgemini
Project
Manager
Mickey
McBroom
PMO
<client> Team Leads
Capgemini Team Leads
Weekly,
Monday 1pm
1 hr
Issues and
Integration
Meeting
Capgemini
Project
Manager
Mickey
McBroom
<client> Team Leads

Bi-weekly
1 hr
Tuesday 8am
Thursday 8am
Interim Gate
Review
Meeting
Capgemini
Project
Manager
Mickey
McBroom
PMO
<client> Team Leads
Weekly,
1 hr
Wednesday 1
pm
4.5 Monitoring Of Actions

Program level actions arising from meetings, reviews, audits, risk management, problem
management will be evaluated by Project Managers and logged as risks or issues as
appropriate.

Page 38
5. RISK AND ISSUE MANAGEMENT PROCESS

The risk and issue management process to be followed by on this project is outlined below and further
described in individual flow charts. Risks and issues will be raised to Team Leads on a weekly basis and
logged in SharePoint. Risks and Issues will be reviewed at the weekly Team Status Meetings. Important
risks and issues will be covered in detail at the Steering Committee meetings. It is the responsibility of
each team member to raise issues as soon as they happen.
Step
Details
Owner
Identify issues & risks
Anyone may identify and issue or risk and inform a

team lead. Team members identify and inform
respective team leads or PMO of the risk/issue.
All
Log issue or risk
Team leads are responsible for logging risks and issues

in the Risk register or Action and Issue list. Item is
added to the respective list in the Sharepoint project
site. The respective information, including initial
assessment needs to be added by the Team Lead.
Team lead
Qualify the issue/risk
The PMO is responsible for reviewing and making

certain issues and risks raised by their team members
or assigned to their team members are valid and
relevant. PMO will periodically (at least weekly) review
the risk and issue log for validity and potential impact to
scope, project plan, and budget
PMO
Assess severity of
impact & probability of
occurrence
Team Leads and Project Leadership are jointly

responsible for assessing the impact of risks and the
likelihood of occurrence Team Leads will proactively
communicate identified risks/issues and work with the
PMO to validate the risk and determine if immediate
escalation to the project Steering Committee is
required
PMO, Team
Leads
Assign actions
The PMO will assign actions to specific team members.

Owner investigates the risk/issue and formulates plan
for risk mitigation and contingency management.If the
risk or issues is the Project Manager(s) and/or Team
Leads will confirm the assigned-to individual and work
together on a resolution/mitigation plan.
PMO
Open discussion
Open actions, issues, and risks will be discussed at the

Weekly Team Lead Status Meetings. PMO, Team
Leads, and Project Team Members will discuss the
status of open and assigned risks/issues and
determine possible escalation. Risks and issues that
are determined to be high impact, high probability, high
priority must be reviewed with the Steering Committee
for recommendations and guidance
All
Update log
The owner updates and closes the risk/issue upon

successful mitigation or implementation of contingent
Project Team

Page 39
Step
Details
Owner
actions. The risk or issue should only be closed after

PMO is informed and agrees. The team lead should
also inform the person who identified the risk or issue
of the status.
Lead
5.1 Risk Management

5.1.1 Risk
Definition
A risk is a potential issue that can have a materially adverse impact on the project, one of its
work streams or the company as a whole. Typically, risks are factors that potentially may occur
at some date in the future, the occurrence of which may result in an issue.
The goal of risk management is to identify risks, assess the severity of their impact, determine
the probability of occurrence, formulate mitigation plans prevent occurrence, and prepare
contingency plans to deal with the impact if the risk eventually occurs.
5.1.2 Risk
Classification
In order to efficiently utilize available resources, the project will classify risks and issues along
the following dimensions:
Resolution Deadlines
Risks will be assigned a priority (and potentially re-assigned a new priority) as follows:
High Could prevent a team from meeting deadlines/completion
Medium Could delay a team
Low - Needs to be resolved (by requested date)
Rick resolution will start within the following period:
High - Same day
Medium - 3 days
Low - No set timing
5.1.3 Risk
Escalation
All Risks will follow the below escalation path:

Team Member Team Lead Project Manager Steering Committee
5.1.4 Risk
Process flow

Page 40
5.2 Issue Management

The goal of issue management is to quickly resolve outstanding issues and to communicate the
identification and resolution of issues to the appropriate stakeholders. An issue is any formally
defined matter that may threaten the success of or impede the progress of the project or one of
its work streams (e.g., causes a delay, changes the direction, impairs the solution, hinders the
quality, alters the deliverable content, or potentially increases implementation costs).
5.2.1 Issue
Definition
An issue is an existing matter that if not resolved may threaten the success of, or impede the
progress of the Project, Project or one of its work streams i.e., causes a delay, changes the
direction, impairs the solution, hinders the quality, alters the model or deliverable content, or
potentially increases implementation costs.
5.2.2 Issue
Priority
Issues will be assigned a priority (and potentially re-assigned a new priority) as follows:
High Impacts overall Project Timeline
Normal (Medium) Impacts Project Teams timeline but does not have an impact
on the Key Milestones of the Project
Low Does not impact timeline of a deliverable (Project Team)
5.2.3 Issue
Escalation
All issues will follow the below escalation path:

(The PMO should be notified immediately of all high priority issues)
Page 41
Notes: Actions and Issues within this Project are tracked within the same management tool
5.2.4 Issue
Process Flow

Page 42
6. CHANGE CONTROL
Change Control outlines the formal process used to keep project on track and ensure that
changes to scope are recognized and assessed for impact on the project budget and schedule.
6.1 Change Request Definition

A Change Request is a formal request to implement a new system functionality that was not
anticipated, defined and/or budgeted in the original scope of work/project.
6.2 Change Request Escalation

All Change Requests will follow the below escalation path:
6.3 Change Control Process

The <client> Change Control process will be utilized to manage change requests for the SAP
project.
The approach and timeline appropriate for completing each step to implement change as
defined by the project team is defined in the next section (SAP Project Changes). The defined
criteria for change requests and an understanding of the impact to the project will be used to
implement controls and govern change. Each role of the approval workflow should evaluate the
change against criteria below.

Page 43
SAP Project Changes

Changes are requests for work outside the original scope of the project, as documented within
the Project Governance Plan (and related Work Orders). <client> seeks to limit all such
changes. All changes which require a change in the project go-live date or an increase in
project costs will be carefully challenged before being signed and accepted by Project and
Program Management. If an approved project change results in a change to a Statement of
Work, the change order will form an addendum to the Work Order. Each such change request
will specify the change, the impact, and the acceptance by both Service provider and <client>
that the change will be incorporated.
The costs of any approved change requests will be mutually agreed in writing between <client>
and the Service provider prior to commencing any work.
Task
Timescale
Responsibility
Raise Change Request/ Reason

for raising
As they occur
Team Lead
Impact Assessment
As they occur
PMO
Approval of Budget or Schedule

Changes
As they occur
Project Steering Committee

Page 44
6.4 Change Request Form

A project change request form is required for any activity that proposes a change to the original
project scope. The project will be required to maintain a change log. The project change log
will track the status of all change requests.
The change request form is designed to answer the following questions:
How important is this change to the success of the project?
Does the change significantly impact the project?
How does this change introduce, modify or mitigate risks to the project?
Can the change be accommodated with the existing project resources and timelines?
Will the change require an extension of the deliverable schedule?
Can the change be accommodated within the current deliverable schedule if additional
resources are added? How will this affect the budget?
Will the change require additional resources and an extension of the deliverable
schedule? How will this affect the budget?
Maintaining the required documentation and obtaining the appropriate approvals for the change
control process is just as critical as implementing the change. A new change request must be
logged in the Change Request Log on Sharepoint and the Change Request Form attached to
the log entry.

Page 45
7. RESOURCE MANAGEMENT
7.1 On-Boarding
An on-boarding package is provided by the PMO at the link:
All new resources will be contacted and forwarded the On-boarding package.
7.2 Team Member Evaluations

Team member evaluations will be performed on an informal basis or as-needed basis by the
<client> and Capgemini project managers.
7.3 Team Member Release

Capgemini will be notified of planned or impending <client> Team Member releases from the
project. <client> will maintain its resource levels and responsibilities within the terms of the
<client> Project Statement of Work.
Capgemini may request release of <client> team members after consultation with the <client>
project manager and agreement with <client> IT sponsor and Capgemini Account executive.
<client> will be consulted prior to planned or impending Capgemini Team Member releases from
the project. Capgemini will maintain its resource levels and responsibilities within the terms of
the <client> Project Statement of Work.
<client> may request release of Capgemini team members after consultation with the
Capgemini project manager and agreement with <client> IT sponsor and Capgemini Account
executive.

Page 46
8. QUALITY ASSURANCE
8.1 Program Reviews
To be defined at the Project/Service Level and documented in the corresponding Project
Governance Plan/Service Quality Plan.
The Framework will include 4 components:

Vision replace legacy process with standardized SAP best practices.
Guiding Principles more specific guidance on levels of customization

permitted.
Design Standards naming and numbering for SAP objects, number ranges,
data elements.
Solution Scope and Key Decisions During the Blueprint phase, the project
scope will be finalized as the structures and objects defined in SAP Solution
Manager. Key Design Decisions will be documented in Functional Design
Documents posted in Solution Manager.

Page 47
4 key Gate Reviews are scheduled at key milestones: Kick-Off, Blueprint Completion,
Realization Completion, and Go/No-Go points for each go-live event. Additional
Work-in-Process Gate Reviews will be held as needed to address potential
requirements gaps and proposed solutions that may be potential exceptions to one or
more levels of the Design Control framework.
8.2 Deliverable Reviews

Type of Review:
Document Review (reading or workshop)
Objectives:
To verify that the deliverable is fit for purpose.

This involves verifying internal consistency, understandability and that the document
is in agreement with a predecessor document(s). It includes verification that any
solutions described are within scope and support the overall project objectives.
Method:
Document reading and/or presentation of the deliverable.

Challenge of the content from workshop or team reviewers.
Objects to be
available:
Applicable document
Outcome and
records:
Completed deliverable or updates to that deliverable.

Updates to progress reports and work plan to reflect the completion (or not) of the
deliverable.
Change history (in the case of controlled documents)
The responsible and accountable team member will review typical deliverables. These team
members will also be responsible to have the right stakeholders included in the review.
8.3 Quality Audits (Capgemini Projects)

Audits are carried out by a Capgemini executive who is not involved in the project (i.e. the
Project QA advisor). The approach taken normally involves interviewing selected members of
the <client> and Capgemini Project Team (arranged with the Capgemini Project Manager). A
report is produced from the audit, which is internal to Capgemini, although key findings will be
discussed with the <client> Project Directors/Sponsors.
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 Audit
Project Quality Audit (internal

Capgemini)
Responsibility for
Organizing
Review/Audit
Capgemini Project
Manager
Target Date of
Review/Audit
Quarterly
Client
Involvement
(Y/N)
Y

Output from the

Review/Audit
Audit report
presented to
Capgemini PM,
and the <client>
Page 48
PM/BSM

Page 49
9. INFRASTRUCTURE MANAGEMENT
9.1 Project Infrastructure
The project will use the following core tools:
Clarity Project standard for work planning including issues, risks, change requests and
action items.
Open Work Bench Project Scheduling. MS Project can be used on an exception basis
as agreed by the Project Manager, <client> Project Management Leader and the PMO.
Solution Manager - Solution Manager will be used for system design and build
documentation and decisions
SharePoint T-Rooms Project folders and documents to serve as the primary document
repository for all project documentation that is not housed within Solution Manager.
MS Office suite MS Word, PowerPoint and Excel are the project standard productivity
tools.
Visio - will be used for all process flows.
Outlook Primary vehicle for internal team communications and meeting planning.
Testing MS Excel templates, stored in Solution Manager
9.2 Security Management

SAP Solution Manager all core team members will be permitted to be contributors, Project
Administration will be restricted.
SAP Development Environments configuration access will be restricted to have configurators
access using Solution Manager. Direct access to project IMG will be limited.
MS Sharepoint All team members will be permitted as contributors, site administration will be
restricted.
Clarity All team members will be permitted to log risks and issues and to view plans and
reports. Project administration access will be restricted to trained Project Managers.
Project/Service Level
The following guidelines will apply:
Storage
The storage guidelines for Blueprint Deliverables are summarized below:
Document Category
Project Management
Repository
Specific Examples
Clarity
Planning, Scheduling, Monitoring
Change Request Tracking
Status Tracking
SolMan
T-Room
+
+

Page 50
Solution Design
Issue Tracking
Risk Tracking
Time Reporting
Process Master List
Blueprint Design Document
Process Flow
Functional Specs
Key Decision Document
Gap Analysis Log
Preference Documentation
Intermediate Documentation
X
X denotes Primary/Final Repository
+ denotes Secondary/Transitional Repository
For documents stored on T-Rooms, each team will utilize a standardized directory structure:
Electronic signature (E-mail approvals or Scanned Signatures) will be utilized for documents
which require a sign-off.
Each document may have a different author or owner, but in general, the documents on the TRoom are owned by the Team Leads.
Backup Procedures
<client> is responsible for backup procedures for all files stored on <client> Infrastructure.
Capgemini is responsible for backup procedures for files stored on Capgemini infrastructure.
Confidentiality
Confidentiality agreements are in place between Capgemini and <client> which require all team
members to guard the proprietary and confidential information of the other party. In addition the
team must keep in mind that certain information, such as personnel data, may be used as part
of project implementations and should not be shared even within the respective companies.

Page 51
10.
10.1
APPENDICES
APPENDIX A: - Reference Documents
Reference Documents
The following table lists all documents referenced within this Program Governance Plan. The
extent of the applicability of each document to the Program is described in the appropriate
section of this document.
Document Reference
Title
Current List of Defined Projects
Milestone Plan
SAP Development Standards
Landscape Strategy
Methods

Page 52
Document Reference
Title
Clarity Reporting Procedures
Steering Committee Reporting

Template
Project Management Reporting
Project Team Level Status Reporting

Page 53
Document Reference
Title
Risk Management
Issue Management
Scope Change
Communications

Page 54
Document Reference
Title
Solution Manager

Page 55

Riata - Project Governance Plan

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Riata - Project Governance Plan

Enviado por

Direitos autorais:

Formatos disponíveis

PROJECT GOVERNANCE

Reference: (Riata Corporate Group Project Governance Plan)

LOCATION (PATH/FILE NAME)

REVIEW AND APPROVAL

Copyright 2012. Capgemini

Project Governance Plan Overview

1.1 Purpose Of The Project Governance Plan......................................................................................3

2.1 Project Description.......................................................................................................................... 5

3.1 Phases, Stages, Activities............................................................................................................. 29

Copyright 2012. Capgemini

Risk and Issue Management Process

5.1 Risk Management......................................................................................................................... 41

Change Request Definition........................................................................................................... 44

8.1 Program Reviews......................................................................................................................... 48

9.1 Project Infrastructure..................................................................................................................... 51

Copyright 2012. Capgemini

1. PROJECT GOVERNANCE PLAN OVERVIEW

Define the scope and assumptions of the project

Identify the approach required to meet <client>s requirements

1.2 Scope Of The Project Governance Plan

Design activities (e.g. documentation standards, document management)

Management activities (e.g., project management, project governance, preparation of

Verification activities (e.g., walk-through, review, audit)

1.3 Control Of The Project Governance Plan

Copyright 2012. Capgemini

Program Governance Plan

Define the Model

Mickey McBroom (Capgemini)

Review and update content

Mickey McBroom (Capgemini)

Produce draft version

Mickey McBroom (Capgemini)

Project Governance Plan

Update the Project Governance

Mickey McBroom (Capgemini)

Copyright 2012. Capgemini

2.2 Project Objectives

Standardize business processes

Improve access to financial information

Provide tighter informational integration between various functions

Limit customizations to the software to hold down implementation costs, to support

2.3 Project Critical Success Factors

Involvement from key stakeholders

Executive governance and support

Closely linked and well integrated <client> andCapgemini teams

Active involvement and quick decision making by <client>

Copyright 2012. Capgemini

Close management of stakeholder expectations

Timely review and sign off of deliverables

Monitoring competing organizational priorities (e.g. New builds)

Resolution of inadequate project management and execution

Prevention of scope expansion

Management of integration with other systems

Adequate training and rollout

Dedicated training resources identified and allocated

A robust, post implementation support model

2.4 Parameters for Decision Making

2.5 Project Scope

Project Startup and Preparation

Copyright 2012. Capgemini

2.5.1.1 In-Scope Business Entities

The following SAP Modules are in scope for this project:

Copyright 2012. Capgemini

Copyright 2012. Capgemini