Subsidiary Project Management Plans: Internal

Subsidiary Project Management Plans
INTERNAL
TABLE OF CONTENTS
INTEGRATED CHANGE CONTROL PROCEDURE.......................................................................................5
Introduction..................................................................................................................................................... 5
Purpose........................................................................................................................................................... 5
Procedure........................................................................................................................................................ 5
ISSUE MANAGEMENT PLAN......................................................................................................................... 9
Introduction..................................................................................................................................................... 9
Purpose........................................................................................................................................................... 9
Procedure........................................................................................................................................................ 9
SCOPE MANAGEMENT PLAN..................................................................................................................... 15
Introduction................................................................................................................................................... 15
Purpose......................................................................................................................................................... 15
Procedure...................................................................................................................................................... 15
TIME MANAGEMENT PLAN......................................................................................................................... 18
Introduction................................................................................................................................................... 18
Purpose......................................................................................................................................................... 18
Procedure...................................................................................................................................................... 18
COST MANAGEMENT PLAN........................................................................................................................ 23
Introduction................................................................................................................................................... 23
Purpose......................................................................................................................................................... 23
Procedure...................................................................................................................................................... 23
QUALITY MANAGEMENT PLAN.................................................................................................................. 27
Introduction................................................................................................................................................... 27
Purpose......................................................................................................................................................... 27
Procedure...................................................................................................................................................... 27
HUMAN RESOURCE MANAGEMENT PLAN...............................................................................................33
Introduction................................................................................................................................................... 33
Purpose......................................................................................................................................................... 33
Procedure...................................................................................................................................................... 33
COMMUNICATION MANAGEMENT PLAN................................................................................................... 38
Introduction................................................................................................................................................... 38
Purpose......................................................................................................................................................... 38
Procedure...................................................................................................................................................... 38
RISK MANAGEMENT PLAN......................................................................................................................... 42
Introduction................................................................................................................................................... 42
Risk Management Process Detail................................................................................................................ 42
Glossary........................................................................................................................................................ 50
PROCUREMENT MANAGEMENT / CONTRACT INVENTORY....................................................................52
Purpose......................................................................................................................................................... 52
2
INTEGRATED CHANGE CONTROL PROCEDURE
Introduction
Integration Management is focused on aggregating all the sub functions across Scope, Time, Cost,
Quality, HR, Communications, Risk and Procurement management to ensure the holist view of the
project is considered and that are stakeholder needs are incorporated. Integrated change control
management is a key process within integration management focused at ensuring requested
changes, whether approved or denied are properly documented, processed and controlled.
Purpose
Integrated Change Control provides a method of controlling and monitoring project changes.
Change is defined as any activity that alters the scope, schedule, deliverables, or costs of the
project. The key objectives of Integrated Change Control are to:
 Identify changes in scope, or other unplanned activity, in advance and control them
 Protect the integrity of deliverables that have been approved (signed off)
 Ensure that new tasks and other requested changes are justified and cost justifiable, and that
affected deliverables are identified and modified accordingly (re-baseline)
 Obtain authorization to proceed with the new tasks/changes and assign them to appropriate
individuals to be completed
 Monitor the progress, cost and value of the change scope
Integrated Change Control Procedures will apply to the following types of changes:
 Any change of project scope, unplanned activity or the production of an unplanned deliverable
(i.e., any task not explicitly within the scope of the current baseline work plan)
 Modifications to approved (signed-off) project deliverables except where:
 The modification has been planned - in this case authorization is not required
 The deliverable has a suspected defect (e.g., where factual errors are subsequently
discovered in an approved document, or where approved configuration or development
apparently does not function to specification). These situations should first be handled
through the project’s defect process used for testing or validating any deliverable. If,
however, on investigation, it is determined that the deliverable does function to specification,
but requires enhancement, then a Change Request (CR) should be raised.
No project team member should begin work on a task for which there is not an explicit task on the
work plan without first raising, and obtaining approval for a Change Request.
Procedure
Integrated Change Control defines the mechanisms for requesting, evaluating, deciding, and
tracking possible changes to the project scope and all related activities and deliverables.
3
Establish Implement
Change Control Change Reques
Board Procedure
Procedure by which project team members update p

Committee that approves or rejects proposed changes
Procedure
based
by which
on theproject
analysis
team
of the
members
change and
and stakeholders
the implication
canofrequest
the proposed
chang
Establish the Change Control Board (CCB) and delegate authority

To oversee the change process and to make decisions on changes, as defined in the process, a
CCB will be established to evaluate and disposition all change requests. Members of the CCB will
be as follows:
<List the CCB members. There should be 3-6 members including the SAP Project Management
and CEM (if possible or another member of the Account Management team), and key customer
stakeholders. A customer stakeholder should chair the board and have final decision authority)>
 <<Name>>, <<Customer Name>> Program Manager
 <<Name>>, <<Customer Name>> Project Manager
 <<Name>>, SAP Program Manager
 <<Name>>, SAP Project Manager
 <<Name>>, SAP Consulting Engagement Manager
The CCB will meet weekly in order to review pending change requests. In addition, emergency
meetings may be held at the discretion of the CCB.
Change requests that exceed a threshold of <enter time, cost, expected value, scope or quality
parameters> will require Steering Committee approval. All change requests less than this threshold
will be managed by the CCB.
Implement Change Request Procedure

Step 1: Team member identifies need for potential change
A project team member or external source identifies a need for a potential change to the project
scope, schedule, resources, expected value or budget. Team member discusses potential change
with Team Lead and/or Business Process Owner.
Step 2: Team lead and process owner identify need for change request
Team Lead and Business Process Owner will assess validity of whether requested change
requires a change to scope, schedule, resources, expected value or budget.
Step 3: Team lead and process owner create, approve for further consideration, and submit a
Change Request Form to the Change Control Board (CCB)
 If necessary, Team Lead and/or Business Process Owner will complete first section of the
Change Request Form.
4
 Team Lead and/or Business Process Owner provide a detailed description of the requested
change, benefits, and implications to project, and authorize change request to be reviewed by
the CCB.
- Any change request not authorized by the Team Lead and the Business Process
Owner with the above detailed information will not be reviewed by CCB.
- Disputes between the Team Lead and the Business Process Owner will be
addressed in accordance with the Issue Management Process. Once the issue is
resolved, the updated change request will be resubmitted to the CCB for review.
 Change request is entered into the Change Control Log with an initial status of “New”.
Step 4: Change Control Board (CCB) reviews change requests

 CCB will review “New” change requests entered in Change Control Log.
 CCB will review detailed description of the requested change, benefits, and implications to
project and determine whether to proceed with further analysis or reject the change request
based on the merit of the original request.
 CCB will reject all change requests that have not completed step 3.
 CCB will send change request back to the Team Lead and the Business Process Owner to
complete the required initial analysis.
 Once the initial analysis is completed, the updated change request may be resubmitted to the
CCB for review.
 If change request is approved for further analysis, change request status in Change Control
Log is changed to “Analysis” status.
Step 5: Technical team and PMO submit results of change request analysis for Change Control
Board (CCB) approval
 The business process, functional, and or technical teams estimate total effort, cost, and
required resources necessary to complete the proposed change.
 The PMO estimates impact to project schedule, resources, expected value and budget.
 Note: All change requests need to have a comprehensive view of project lifecycle impacts
(e.g., functional specification, technical specification, development, unit testing, integration
testing, user acceptance testing, training, deployment, etc.).
 Upon completion of estimation by business process, functional, and or technical teams and
PMO, change request status in the Change Control Log is changed to “Ready for Approval”.
Step 6: Change Control Board (CCB) approves, rejects, or defers change request based on
detailed analysis
 CCB will review “Ready For Approval” change requests in the Change Control Log.
 The PMO and the business process, functional, and/or technical team lead present the detailed
analysis of the change request to the CCB. They must explain the change request, impact, and
alternatives in enough detail for the CCB to evaluate the request and validate the need for the
change. After the CCB has completed their review, they have the authority to approve, defer,
reject, or close the change request.
 If a change request is rejected by the CCB, the reason must be documented in the Change
Request Form. The status of the change request must then be updated in the Change Control
Log to “Rejected”. The result should also be communicated to the change request originator. If
the change is rejected, it must be reopened as a separate item.
 A change request may also be deferred by the CCB. A deferral would normally occur when
more information is needed, viable alternatives exist that need further review, or a work around
has been discovered. The status of the change request should be updated in the Change
Control Log to “Deferred”.
 During the change process a change request may no longer be needed or not be relevant due
to other changes. When this occurs the change request can be closed. The status should be
updated in the Change Control Log to “Closed”.
5
Step 7: Communicate changes in the scope to the project stakeholders.
 All approved change requests must be communicated to the appropriate teams to commence
work.
 The status of the change request should be updated in the Change Control Log to ‘Approved’.
 All documentation/change authorizations should reference the approved change request
number and title.
 The resolution of the change should also be fully documented. This will allow for transport
tracking as well as change request tracking.
Update the Project governance and control documents

Updates may include but not limited to:
 Scope Statement
 Project Schedule – WBS
 Management Plans
 Impacted deliverables
6
ISSUE MANAGEMENT PLAN
Introduction
Issue Management is key to project success. Issues are the barriers in place that restrict
completion of the objectives of the project. On many project, people are reluctant to raise issues,
they are concerned about how to raise them and what the consequences are, therefore they do not
raise the issues they see. As a good project manager, you should forester just the opposite.
Issues recognized early can be managed most efficiently, issues discovered much later in the
process, become much larger and require more effort to resolve. Issues should be manage early
and often, this prevents issues from restricting the success of any project deliverables.
Purpose
Issues management within Project <<Project>> serves the purpose of highlighting problems that, if
not addressed, will jeopardize the success of the project and resolving them or defining actions
must to be taken urgently.
The issues management concept applied in project <<Project>> is that the entity recognizing the
issue is as a first level responsible for its resolution. Only if the recognized and consequently
registered issue cannot be resolved in such a manner (e.g. time, effort, nature, etc.) that it does not
jeopardize the success of the project, it is escalated to the next level of the project structure.
It is the responsibility of the <<Project>> project managers, <<Customer>> and SAP Consulting,
that this concept is applied throughout the project.
Procedure
Issue Management is a continuous process composed of 4 steps including regular reporting:
Issue Issue Issue

Issue Resolution
Planning Identification Monitoring
Identify, Regularly
categorize review
and the issues
document Issuesand make sure the issues are actively monitored and con
Define Issue management approach in the project
Define processes to resolve issues in a timely manner
Issue Planning
Issue management planning is the process of deciding how to approach and conduct issue
management activities for the project. Planning will ensure that the identification, type, priority, and
visibility of issue management are commensurate with both the issue and importance of the project
to the organization, to provide sufficient resources and time for issue management activities, and to
establish an agreed-upon basis for evaluating issues. Managing issues is an essential
7
responsibility of the project management team and is fundamental to the success of an
implementation.
Each project, its scope, project manager, and project team, have unique characteristics and
qualities, and consequently, the procedures many vary from project to project. Because of this
variance, the project manager, team leaders, and team members take on different responsibilities,
depending on the situation.
<<Assess whether the customer has an existing issue and defect management database
containing issue and defect status, control information, issues and defect resolution, and action
item results. If so, review customer issue management process and procedure to assess whether
customer issue management plan needs to be updated or is consistent with the below issue
management plan. Update documentation to reflect final issue management process, procedure,
and communicate to the project team>>
An issue is a certain event (no uncertainty) with a negative effect on at least one project objective,
such as scope, time, cost, or quality. Issues are items that are identified during a project and may
influence the success of the project. Typically, they fall into one of three areas:
 They were not anticipated.
 They are normal tasks that cannot be completed.
 They are external factors that need to be overcome.
Issues will be documented and maintained in the issue register, a single central register utilized by
the project team. NOTE: No other issue register, log, or issue listing will be maintained outside of
the issue management register by project team members during the project implementation.
Monitoring of the issue will occur in the weekly project and team status meetings, along with
reporting high issues in the weekly team status reports.
The <<Project>> will utilize this issue management plan to manage project issues throughout the
life of the project implementation.
Issue Identification
Issue identification determines which issues might affect the project and documents their
characteristics. Participants in issue identification activities can include the project manager,
project team members, issue management team, subject matter experts from outside the project,
end users, stakeholders, etc. An issue should only be reported into the log if it affects or requires:
 Scope
 Design and integration of the solution
 Decisions outside of the project scope and charter
 Dependencies with other projects or business units
 Cost (budget & resources)
 Time
 Quality
Normal day-to-day project problems that can be resolved within a timely period should not be
considered an issue for follow-up. Team members should review with consultants before recording
the issue. The following procedure describes the issue identification process:
 The team member identifies, opens, and documents issue in <<Project >> issue register
 The team member or team lead will assign issue to a team member, consultant, subject matter
expert or business owner with agreed upon resolution date based on priority. NOTE: No issue
will be opened without an issue owner being assigned and that there is acknowledge by issue
owner that he or she is responsible for closing and/or resolving issue.
 Individual responsible for resolution will document the solution and change the status of the
issue to “Closed” in the issue log.
 Whenever an issue or conflict arises that cannot be resolved within normal channels, the
project team will strive to work out the problem internally through the escalation management
process.
8
The following conditions are essential to record an issue in the <<Project>> issue management
register:
Issue Name: Title of Issue (short name or description)

Date Issue Opened: Enter the date Issue Created By: Enter the person's name who
(XX/XX/XXXX) the issue is entered into initially entered the issue into the log
the log
Issue Status: Definition of Impact Levels:
 Open - Issue recorded and assigned  Critical - Major impact on the implementation
to a team member target date with several teams unable to
 In progress – Issue is actively being proceed, immediate attention required and
worked on resolution within 24-48 hours
 Completed – Team member updates  High – Definite impact on the implementation
issue with a description of the target date, which requires quick attention and
resolution and is reviewed by the resolution within 2-3 business days.
project manager.  Medium – Medium impact on the
 Change Control – The issue was implementation, not impacting timeline at this
closed and a change request was time, should be resolved within 2 weeks.
created to deal with the issue.  Low – No critical impact on the implementation
but should be resolved prior to the go-live date
or possibly defer issue until after Go-live
Team: Team impacted (e.g., Finance, Definition of Phase: Project Preparation, Explore,
Order to Cash, Change Management, Realization, Final Preparation, Cutover, Go-live &
Basis, etc) Support
Issue Owner: Person Assigned Date To-Be Resolved: Enter the date
Responsibility for Resolving Issue (XX/XX/XXXX) the issue is to be resolved. The
date selected should minimize any negative
impacts to schedule and/or cost.
 Type of Issue: Identifies the type of issue (e.g., business process or procedure, functional
area, technical area, training, etc.)
 Definition of Issue: An issue or significant matter of importance that will impact the project,
which should be brought to the attention of the customer.
 Definition of Impact: How will the issue impact the project – scope, cost, time, and quality.
 Definition of Recommendation: Potential solution or corrective action of issue, including
identifiable benefits and/or enhancements to the existing business process
 Resolution: Describe the resolution when the issue is closed. This field should contain a
complete history and how the issue was resolved. If applicable, include references to
supporting documents.
 Issue Status Notes: Input and document update issue status as part of the weekly review
process. Include any comments related to this change. Reference any supporting
documentation, if applicable.
Issue Resolution
The focus of this issue management plan is to identify, prioritize, resolve, and/or prevent issues.
Issues that must be resolved for completion of a successful implementation are identified
throughout the course of the project. Typically, issues must be resolved before phase completion
and before beginning the next phase. Issues should be closed on a timely basis, based on the
issue owner resolution date that was assigned to the issue when it was recorded. Escalation
Management comprises the following aspects:
9
Expediting
If an issue is not resolved by the forecasted date, and the lack of resolution will affect other project
steps, then the issue must be expedited. The project manager evaluates the reason the issue is
not resolved and defines what must be done for the issue to be resolved. Also, the project
manager identifies who is responsible for resolution, attempts to put more people on the issue
team (if this would help resolve the issue), and ascertains whether or not the issue will be resolved
in a timely manner. If need be, the project manager raises the priority and rearranges the project
schedule to accommodate issue resolution, keeping in mind the business and project goals.
Escalating
If the issue is not resolved according to the project plan and this will significantly affect the project
timeline, then the manager may opt to escalate it to initiate the following escalation management
process:
 Level 0: The project team lead will create an issue in the << Name>> issue management
register, which will include minimum documentation requirements noted in the issue
identification section of the issue management plan. Only issues defined as High and Critical
may be escalated.
 Level 1: If the Project team lead cannot resolve the conflict within two to three (2-3) working
days, <<Customer >> Project Manager and SAP Program Manager will meet in an attempt to
resolve the issue.
 Level 2: If the conflict is not resolved within three (3) working days after being escalated to
Level 1, a representative of <<Customer, Program Sponsor>> will meet with a representative
of SAP’s VP of Consulting to resolve the issue.
 Level 3: If the conflict is not resolved within two (2) working days after being escalated to Level
2, <<Customer, CIO or CTO>> will meet with SAP’s Executive Vice President of Services to
resolve the issue.
High or Critical issues may warrant immediate escalation to obtain timely resolution related to
production support.
10
Reporting and Escalation Channels
Steering Committee
Escalation in line with the Project Sponsor

defined Issue Management
Procedures
Bus iness Design Quality Assurance

Project Management
Board
Project Management SAP Project Management <Client> Ris k Management

Board of Architects
Project Team
Project Team Members SAP Project Team Members <Client>
Reporting to/ Escalating to: Information:
© SAP 2008 / Page 4 confidential
Crisis mode
If there is a crisis, for example, the system is down, or a significant member leaves the team, the
project manager should immediately review the project, its status, and the impact of the crisis.
Additionally, the project manager should devise a workaround to accommodate the change to the
project plan. In all cases, the project manager involves the lowest-level personnel in the decision-
making process. The project manager will report any revisions of the timeline in an emergency
steering committee meeting.
Issue Monitoring
Monitoring of the issue will occur in the weekly project and team status meetings, along with
reporting high issues in the weekly team status reports. In addition to reviewing the log, the project
management team should be talking to the team leader and team members to understand their
perspectives. By asking open-ended questions and delving into the issues at hand, the
management team is able to identify obstacles in advance and prevent any need for expediting the
issues. Further, the team members may identify related issues or additional details that have been
overlooked.
In general, the project management team’s primary function regarding issues management is
maintaining the project timeline and confirming that issues remain on track and are resolved on
time. The project managers and team leads must make it part of the regular (weekly) duties to
11
review the status of issues and to evaluate their progress. As the project progresses and deadlines
approach, the review frequency may increase.
In every project, there are issues that remain open past the Go-live date. Because these issues
may eventually affect the post implementation, they need to be monitored. The team must identify
the point at which the issue will have an impact and accordingly identify a tactical plan for issue
resolution.
 Issue Review meetings will be scheduled as follows:
 Weekly
 Required attendees include:
o <<Name>>, SAP Project Manager
o <<Name>>, <<Customer Name >> Project Manager
o PMO Members
o Issue “owners” as defined in the project Issue register
Issues with High impact/probability will be reviewed with the Steering Committee as part of the
steering committee meeting.
Issues Register
The usage of the SAP Solution Manager is recommended in terms of an SAP implementation
project. In case that is not applicable an excel-based list can be used to register issues. With the
help of that list it is also possible to monitor all defined issues during the project.
12
SCOPE MANAGEMENT PLAN
Introduction
Scope Management, as stated in the PMBOK, is focused at ensuring that the project contains all
the work required and only the work required to complete the project. Therefore, Scope
Management contains the processes focused at gathering and documenting project requirements,
breaking those requirements down to work activities, verification and controlling processes to meet
stakeholder expectations.
Purpose
The Scope Management Plan defines the processes required to ensure that the project includes all
of the work required, and only the work required, to complete the project successfully. Project
scope management is primarily concerned with defining and controlling what is and is not included
in the deliverables of the project.
Procedure
Scope Management is a continuous process composed of 5 steps including regular reporting:
Scope ScopeDefini ScopeVerifica ScopeContro

CreateWBS
Planning tion tion l
Developdet Controlchang
Create Decomposema Formalizeacc
ailed es toproject
scopemanage jordeliverables eptanceof
scopestate scope
mentapproach into projectdeliver
forproject ment manageablewo ables
rk packages
Scope Management Planning

Defining and managing the project scope influences the project’s overall success. The project
management team will document the scope management decisions in the subsequent steps of this
plan. It will describe how the team will define the project scope, develop the detailed scope
statement, define and develop the work breakdown structure, verify the project scope, and control
the project scope.
 This plan will be developed by <enter name of> SAP Project Manager, <enter name of>
Customer Project Manager, and <enter names of any others who will participate>.
 The Scope Management Plan will be completed before the start of Solution Validation
workshops.
13
Scope Definition
The preparation of a detailed project scope statement is critical to project success and builds upon
the major deliverables, assumptions, and constraints that are documented in the Statement of
Work (SOW). During this step/process, the scope is defined and described with greater specificity
because more information about the project is known. Stakeholder’s needs, wants, and
expectations are analyzed and converted into requirements.
Note: The Solution Validation serves as the process for further elaboration of project
requirements. Therefore, the Scope Statement cannot be completed until the end of Solution
Validation.
 The Preliminary Scope Statement will be developed in the Project Preparation Phase by <enter
name of> SAP Project Manager, <enter name of> Customer Project Manager, and <enter
names of any others who will participate>.
 Solution Validation activities will be will be performed by project teams, further elaborating
project requirements, to include approved change requests that were identified in the Solution
Validation phase.
 The Project Scope Statement will be finalized at the end of Explore by <enter name of> SAP
Project Manager, <enter name of> Customer Project Manager, and <enter names of any
others who will participate>.
 The Project Scope Statement must be approved by the following stakeholders:
- <Enter name of> Customer Project Manager
- <Enter name of> Customer Project Sponsor
- Steering Committee
- <Enter name of> SAP Project Manager
- <Enter names of any others whose approval is required>
Note: Creation of the Project Scope Statement is a significant milestone in the project. The
Realization Phase should not begin until approval is granted and final scope is communicated to all
team members and key project stakeholders.
Create WBS
The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the
project team, to accomplish the project objectives and create the required deliverables. The WBS
organizes and defines the total scope of the project. The WBS subdivides the project work into
smaller, more manageable pieces of work, with each descending level representing an increasingly
detailed definition of the project work. The planned work contained within the lowest-level of the
WBS components, which are called work packages, can be scheduled, cost estimated, monitored,
and controlled.
 The Preliminary WBS and WBS Dictionary will be created by <enter name of> SAP Project
Manager, <enter name of> Customer Project Manager, and <enter names of team leads>
during the Project Preparation phase and before the start of Solution Validation workshops.
 The Project team will utilize the WBS Template for SAP implementation projects. This structure
will serve as the foundation for the Project WBS. Evaluation and further decomposition of
deliverables, as well as elaboration of business scenarios and processes is required to
complete a preliminary WBS and represent key input to the Explore phase.
 The final Project WBS and WBS Dictionary will be created at the end of Solution Validation and
incorporate progressively elaborated requirements defined in the final scope statement.
14
Scope Verification
Scope verification process will be assessed at the end of each project milestone to obtain
stakeholder formal acceptance of the completed project scope and associated deliverables.
Verifying the project scope includes reviewing deliverables for the individual project phases to
ensure that each is completed satisfactorily and/or reasonable expectations that the deliverables
can be met in subsequent project phases per the project implementation lifecycle.
Scope verification is the process of obtaining the stakeholders’ formal acceptance of the completed
project scope and associated deliverables. Verifying the project scope includes reviewing
deliverables to ensure that each is completed satisfactorily.
In SAP implementation projects, hundreds of work packages (deliverables) are defined and are
subject to the scope verification process. It is highly recommended that a delegation-of-
responsibility be created to accomplish scope verification.
The Project WBS must serve as the foundation for the delegation-of-responsibility. It is
recommended that a simple matrix be created (example below) to manage this process.
 The Scope Verification matrix will be created by <enter name of> SAP Project Manager, <enter
name of> Customer Project Manager, and <enter names of team leads> during the Project
Preparation phase and updated after completion of the Solution Validation workshops.
 The Scope Verification matrix and Scope Management Plan must be approved by the
following stakeholders:
- <Enter name of> Customer Project Manager
- <Enter name of> Customer Project Sponsor
- Steering Committee
- <Enter name of> SAP Project Manager
- <Enter name of any others whose approval is required>
Scope Control
Scope Control is focused on influencing the factors that create project scope changes and
controlling the impact of those changes. As scope control assures that all requested changes and
recommended actions are processed through and Integrated Change Control process, the project
will execute scope control in accordance with the Integrated Change Control process. Please see
the Integrated Change Control Procedure for detailed information.
15
TIME MANAGEMENT PLAN
Introduction
Time Management as stated in traditional terms was related to the application of resources to
achieve a specific goal within a given time period. That has not evolved much, but today is
managed through many tools and techniques with specific inputs and outputs to ensure that the
goals / deliverables of a project or project phase are accomplished within the given time period.
Purpose
The Time Management Plan includes the processes required to accomplish timely completion of
the project. Project Time Management Plan is part of the planning process, monitoring and
controlling process of each project.
Procedure
Time Management is a continuous process composed of 6 steps including regular reporting:
Activity Activity
Activity Schedule
Activity Definition Resource Estimating
Duration Estimating
Schedule Development
Sequencing Control
Analyzing activity
y schedule activities toEstimating
Identify
be performed
dependencies
the type
to produce
and quantities
among
Estimating
project
schedule
of
deliverables
number
resources
deliverables
of work
required
periods
to perform
neededeach
to complete
schedule
Controlling
schedule
activity
changes
activities
to the project schedule
Sequences, duration, resource requirements & constraints in creating a project schedule
Activity Definition
Defining the schedule activities involves identifying and documenting the work that is planned to be
performed in the SOW. The activity definition process will identify the deliverables at the lowest
level in the WBS, which also referred to the work package. Project work packages are planned
into smaller components called schedule activities to provide a basis for estimating, scheduling,
executing, and monitoring and controlling the project work. Implicit in the process is defining and
planning the schedule activities such that the project objectives will be met.
 Inputs for activity definition
 Project scope statement
 NA work breakdown structure
 Scope management plan
 Approved change requests
Activity definition methods and tools

 Decomposition
 Templates
 Rolling Wave Planning
 Planning Component
 Control account
 Planning package
16
Outputs for activity definition
 Activity list
 Activity attributes
 Milestone list
 Change requests
Activity Sequencing
Activity sequencing involves identifying and documenting the logical relationships among schedule
activities. Schedule activities can be logically sequenced with proper precedence relationships, as
well as leads and lags to support later development of a realistic and achievable project schedule.
Sequencing can be performed by using MS Project or by using manual techniques. Manual and
automated techniques can also be used in combination.
 Inputs for activity sequencing
 Project Scope Statement
 Activity list
 Milestone list
 Approve change requests
Activity sequencing methods and tools

 Precedence Diagramming Method (PDM) – “finish-to-start”
 Arrow Diagramming Method
 Dependency Determination
 Mandatory Dependencies
 Discretionary Dependencies
 External Dependencies
 Apply Leads and Lags
Outputs for activity sequencing

 Project schedule network diagrams
 Activity list updates
 Activity attributes updates
 Requested changes
Activity Resource Estimating

Estimating schedule activity resources involves determining what resources (persons, equipment,
or material) and what quantities of each resource will be used, and when each resource will be
available to perform project activities. The activity resource estimating process is closely
coordinated with the cost estimating process.
Inputs for activity resource estimating
 Customer Resources
 Activity list
 Resource availability
Activity resource estimating methods and tools

 Expert judgment
 Bottom-up estimating
17
Outputs for activity resource estimating
 Activity resource requirements
 Resource breakdown structure
 Resource calendar updates
Activity Duration Estimating

The process of estimating schedule activity durations uses information on schedule activity scope
of work, required resource types, estimated resource quantities, and resource calendars with
resource availabilities. The inputs for the estimates of schedule activity duration originate form the
person or group on the project team who is most familiar with the nature of the work content in the
specific schedule activity. The duration estimation is progressively elaborated, and the process
considers the quality and availability of the input data.
The activity duration estimating process requires that the amount of work effort required to
complete the schedule activity is estimated, the assumed amount of resource to be applied to
complete the schedule activity is estimated, and the number of work periods needed to complete
the schedule activity is determined. All data and assumptions that support duration estimating are
documented for each activity duration estimate.
Inputs for activity duration estimating

 Activity list
 Resource Calendar
 Project Management Plan
 Risk register
 Activity cost estimate
Activity duration estimating methods and tools
 Expert judgment
 Analogous estimating
 Parametric estimating
 Three-points estimates – most likely, optimistic, pessimistic
 Reserve analysis
Outputs for activity duration estimating

 Activity duration estimates
Schedule Development
Project schedule development, an iterative process, determines planned start and finish dates for
project activities. Schedule development can require that duration estimates and resource
estimates are reviewed and revised to create an approved project schedule that can serve as a
baseline against which progress can be tracked. Schedule development continues throughout the
project as work progresses, the project management plan changes, and anticipated risk events
occur or disappear as new risks are identified.
Inputs for schedule development
 Activity list
18
 Project schedule network diagrams
 Resource Calendars
 Activity duration estimates
 Project Management Plan
 Risk register
 Schedule development methods and tools
 Schedule network analysis
 Critical path method
 Schedule compression
 Crashing
 Fast tracking
 What if scenario analysis
 Resource leveling
 Critical chain method
 MS Project
 Applying calendars
 Adjusting leads and lags
 Schedule model
Outputs for schedule development

 Project schedule
 Project schedule networks diagrams
 Bar charts
 Milestone charts
 Schedule baseline
 Resource requirements updates
 Project calendar updates
 Project management plan – schedule management plan
Schedule Control
Schedule control is a portion of the integrated change control process, which involves:
 Determining the current status of the project schedule
 Influencing the factors that create schedule change
 Determining that the project schedule has changed
 Managing the actual changes as they occur
Inputs for schedule control

 Schedule management plan
 Schedule baseline
 Performance reports
Schedule control methods and tools

 Progress reporting
 Schedule change control system
 Performance measurement
 MS Project
19
 Variance analysis
 Schedule comparison bar charts
Outputs for schedule control

 Schedule model data updates
 Schedule baseline updates
 Performance measurements
 Recommended corrective actions
 Activity list updates
 Project management plan updates
20
COST MANAGEMENT PLAN
Introduction
Cost Management is focused at defining and understanding the cost of the project, in whole and in
part, to ensure that the project is properly funded and controlled.
Purpose
Project cost management includes the processes involved in planning, estimating budgeting and
controlling costs so that the project can be completed within the approved budget. Project cost
estimating and cost budgeting are part of the planning process, while cost control is part of the
monitoring and controlling process of the project.
Procedure
Cost Management Plan is a continuous process composed of 3 steps including regular reporting:
Cost Cost Cost

Estimating Budgeting Control
Estimating costs of
Aggregating
resources needed
the estimated
Influencing
to complete
coststhe
of
project
factors
individual
activities
thatactivities
create cost
to establish
variancesa and
costcontrolling
baseline changes to the project bu
Cost Estimating
Developing an approximation of the costs of the resources needed to complete project activities.
Estimating schedule activity costs involves developing an approximation of the costs of resources
needed to complete each schedule activity. The cost for scheduled activities is estimated for all
resources that will be charged to the project. This includes, but not limited to, labor, materials,
equipment, services, and facilities, as well as special categories such as an inflation allowance or a
contingency costs. A schedule activity cost estimate is a quantitative assessment of the likely cost
of the resources required to complete the schedule.
The Cost Management Plan will be developed in the Project Preparation Phase by <enter name
of> SAP Project Manager, <enter name of> Customer Project Manager, and <enter names of any
others who will participate>.
Inputs to cost estimation:
SOW
Consulting resource costs
 Staffing list
 Rate per hour
 Expenses
 Others
21
High-Level Timeline
Project scope statement
WBS
<<Customer>> resource costs (e.g., blended rate)
Software & hardware costs
Other contract/SOW costs
Contingency costs or reserves
NOTE: <<Customer>> normally monitors and tracks total project costs; however actual monthly
costs incurred and accruals for SAP consulting costs incurred on a monthly basis may need to be
reported to <<customer finance organization>>. As a result, agreement with <<Customer>> and
the SAP Project Manager on how SAP consultants costs will be captured, monitored and reported
on a monthly basis must be determined during the project preparation phase. SAP project
management must also track and report project finance management on a monthly basis.
Costing estimation techniques:

Analogous estimation from actual costs of previous, similar projects with a cost of inflation increase
Bottom-up estimation from the cost of individual work packages or individual schedule activities at
the lower level of detail and rolled up to higher level or summarization for reporting and tracking
purposes
Output of cost estimation:

Activity cost estimates with supporting detail
Description of the schedule activity’s project scope of work
Documentation of the basis for the estimate
Documentation of any assumption made
Documentation of any constraints
Indication of the range of possible estimates (e.g., order of magnitude)
22
Cost Budgeting
Cost budgeting involves aggregating the estimated costs of individual schedule activities or work
packages to establish a cost baseline for measuring project performance. The scope statement
provides the summary budget. However, schedule activity or work package cost estimates are
prepared prior to the detailed budget requests and work authorization.
Inputs for cost budgeting include:

Project scope statement
Work breakdown structure
Activity cost estimates
Activity cost estimate support detail
Project schedule
Resource calendars
Contracts & SOW
Cost budgeting methods and tools:

Cost aggregation
Reserve analysis
Parametric estimation
Funding limit reconciliation
Outputs for cost budgeting:

Cost baseline
Project funding requirements
Cost management plan updates
Requested changes
Cost Control
Project cost control searches out the causes of positive and negative variances and is part of
integrated change control. Influencing the factors that create cost variances and controlling
changes to the project budget.
Inputs for cost control:
Cost baseline
Project funding requirements
Performance reports
Work performance information
Approved change requests
Cost control methods and tools:

Cost change control system
Performance measurement analysis – Earn Value Analysis (EVA)
Forecasting
Project performance reviews
MS Project
Variance Management
Outputs for cost control:

Cost estimate updates
Cost baseline updates
23
Performance measurements
Forecasted completion
Requested changes
Recommended corrective actions
24
QUALITY MANAGEMENT PLAN
Introduction
Quality: the degree to which a set of inherent characteristics satisfies the stated or implied needs of
the customer. To measure quality successfully, it is necessary to turn implied needs into stated
needs via project scope management.
The Quality management plan focuses on defining the objectives for quality, how they will be
applied and how they will be measured. Quality is planned in to each process and controlled along
the way, and can be verified and validated in the end. The implementation of quality within the
project will cost time and money. Quality is the fourth component the triple constraint of Cost, Time
and Scope, as any one of these change, so do the others, all of which impact quality.
Quality management and the creation of the quality management plan are a key success factor to
the project. The quality plan must be defined, well communicated, executed and controlled as the
project moves through the phases from requirements gathering to project sign-off. The quality of
the deliverables must be approved to meet the stakeholder expectations and to produce project
success.
Purpose
The Quality Management Plan includes the processes and activities of the performing organization
that determine quality policies, objectives, and responsibilities so that the project will satisfy the
needs for which is was undertaken. It implements the quality management system through policy
and procedures, with continuous process improvement activities conducted throughout, as
appropriate. Project quality management plan is part of the planning process, executing process,
and monitoring and controlling process of each project.
Procedure
Quality Management Plan is a continuous process composed of 3 steps including regular
reporting:
Quality
Quality Planning Quality Control
Assurance
Monitoring project
Application of planned
Identifying relevant results to determine
systematic quality
quality standards and compliance with
activities to ensure
determining quality standards to
project requirements
acceptance criteria eliminate
are met
unsatisfactory results
The fundamental tenet of modern quality management is: quality is planned, designed, and built in
– not inspected in.
Quality Planning
The Quality Management Plan describes how the project management team will implement the
performing organization’s or project’s quality policy. Quality planning involves identifying which
25
quality standards are relevant to the project and determining how to satisfy them. The quality
management plan should include efforts at the front end of the project to ensure that the earlier
decisions, for example on concepts, designs and tests, are correct. These efforts should be
performed through an independent peer review and not include individuals that worked on the
material being reviewed. The benefits of this review can include reduction of costs and schedule
overruns caused by rework.
■ Preparation: The Quality Management Plan will be developed in the Project
Preparation Phase by <enter name of> SAP Project Manager, <enter name of> Customer
Project Manager, and <enter names of any others who will participate>
■ Approval: The Quality Management Plan approval is achieved by the signatures
(electronic approval is acceptable) of each member of the approval list presented on page 2
of this document. As soon as this document is validated and approved, it should be
communicated to all the project team members. After approval, a current copy of the plan
will be stored in the project files on the project shared directory space.
■ Updating: The Quality Management Plan is a living document, and will be modified
during the life of the project as circumstances change. The Project Management Office will
maintain a change control sheet as part of this document (before the table of contents)
documenting the date of modifications, the section modified, and a brief description of the
modifications. After approval of revisions, the most recent version will be maintained on the
project shared directory site; earlier versions will be archived. The Project Management
Office will notify the project team of approved document changes.
■ The Quality Management Plan is based on the successful completion of key project
deliverables at the end of each major milestone as defined in the Work Breakdown
Structure of the Project. Internal and external quality policy and standards that project
deliverables must adhere to include the following:
- Note specific organizational policies and procedures, standard product and project life cycles, and
quality policies that will need to be incorporated within the project quality management plan to ensure
quality assurance and quality control activities are met.
- Note specific enterprise factors that will need to be incorporated within the project quality management
plan to ensure quality assurance and quality control activities meet local, state and federal
governmental or industry standards (e.g. regulatory agency, product standards, quality standards)
■ Customer satisfaction is an integral part of quality management and is monitored at key

project milestones. The target overall customer satisfaction rating measured at each
defined Project Quality Gate is [list the agreed upon customer overall customer satisfaction
quantitative rating].
■ [List any additional customer success measures and their weighted targets to be defined in the Project
Quality Management Plan, such as:]
- Quality of project management (scope, schedule, cost)
- Quality of implementation tools (methodology, content)
- Technical knowledge/experience of consultants
- Relationship Management skills of consultants
- Availability and responsiveness of consultants
- Ability of consultants to understand business/industry need
■ Acceptance criteria:
- Project Quality Gates will assess project deliverables at the end of each project
milestone to obtain stakeholder formal acceptance of the completed project scope and
associated deliverables. Verifying the project scope includes reviewing deliverables for
the individual project phases to ensure that each is completed satisfactorily and/or
26
reasonable expectations that the deliverables can be met in subsequent project phases
per the project implementation lifecycle.
- A phase approval/closure acceptance document will be prepared by the <enter
name of> SAP Project Manager, <enter name of> Customer Project Manager, and
<enter names of any others who will participate> at the end of each project milestone
for formal and/or conditional acceptance to proceed to the next phase of the project
implementation lifecycle. The phase approval/closure acceptance document will
include a list of project deliverables by functional and technical teams, along with a
summary of change requests, issues, and risks for key stakeholder and steering
committee member approval. Phase approval/closure acceptance of deliverables are
met by the following approval conditions:
 Signatory authorization of project deliverables
 Email authorization providing formal and/or conditional acceptance of project
deliverables
- Formal approval of project deliverables noted in the steering committee meeting
minutes.
Perform Quality Assurance

Quality assurance (QA) is the application of planned, systematic quality activities to ensure that the
project employs all processes needed to meet requirements. QA is typically performed by an
individual or group (e.g., quality assurance team, internal auditor, fellow team member) not actively
involved in the work of the project being validated. QA also provides an umbrella for another
important quality activity, continuous process improvement. Continuous process improvement
reduces waste and non-value-added activities, which allows processes to operate at increased
levels of efficiency and effectiveness. Process improvement is distinguished by its identification
and review of organizational business process.
▪ Project Management Review, Project Quality Gates and Quality Assurance Services
and Safeguarding activities will be included as part of the project quality plan,
quality assurance and quality control process <if applicable>:
▪ Organizational quality policies, procedures and guidelines will be adhered to by the

project team. Quality assurance and control activities will be performed by the
<<customer name>> quality group or internal audit group <if applicable>:
Project Quality Gates will assess project deliverables at the end of each project milestone as
defined in the Work Breakdown Structure of the Project. Key project milestones and applicable
dates:
[Four of the project quality gates are mandatory (Project Preparation Phase, Explore Phase, Realization Phase,
Final Preparation) and the other three gates are optional as agreed with the customer.]
▪ Prepare Phase<<enter milestone date>>

▪ Explore Phase <<enter milestone date>>
▪ Baseline Configuration<<enter milestone date>>
▪ Final Configuration<<enter milestone date>>
▪ Realize Phase <<enter milestone date>>
▪ Deploy Preparation<<enter milestone date>>
▪ Completed Project <<enter milestone date>>
27
Work performance information and/or results, including technical performance measures, project
deliverable status, required corrective actions, and performance reports are inputs to QA and can
be used in areas such as audits, quality reviews, and process analysis.
The QA results must be accepted and/or approved by <PMO and Steering Committee>
The project management plan will be updated from changes to the quality management plan that
result from changes to the quality assurance process. These updates can include incorporation of
processes that have been through continuous process improvement and are ready to repeat the
cycle, and improvements to processes that have been identified and measured and are ready to be
implemented. Requested changes (additions, modifications, deletions) to the project management
plan and its subsidiary plans (e.g. quality management plan) are processed by review and
disposition through the Integrated Change Control Process.
Perform Quality Control

Performing quality control (QC) involves monitoring specific project results to determine whether
they comply with relevant quality standards and identifying ways to eliminate causes of
unsatisfactory results. QC standards include project processes and product goals. Project results
include deliverables and project management results, such as cost and schedule performance.
Identify quality control resources for QA activities:
▪ Project Plan <<resource name>>
▪ Project Schedule << resource name>>
▪ Project Management Review <<resource name>>
▪ Organizational Policy & Procedure Compliance/Validation <<resource name>>
▪ Safeguarding Program <<resource name>>
Delegate team members to review quality control procedures and complete questionnaire or
documentation related to QA activities:
▪ Project Plan <<resource name>>
▪ Project Schedule << resource name>>
▪ SAP Review Program <<resource name>>
▪ SAP Project Review Services <<resource name>>
▪ SAP Modification Review <<resource name>>
▪ SAP Solution Review <<resource name>>
▪ SAP Technical Review Services <<resource name>>
▪ SAP Safeguarding <<resource name>>
▪ Organizational Policy & Procedure Compliance/Validation <<resource name>>
Review and validate acceptance criteria:
▪ Project Management Review
▪ Solution Validation Document or Requirements Specification
▪ Project Issue Log
▪ Project Risk Log
▪ Project Control Log
▪ Approved Requests for Change
▪ Test Plans
▪ Test Scripts
28
▪ Defect Tracking Log
▪ Test Results
▪ User Acceptance Sign-off
Quality control measurements represent the results of QC activities that are fed back to QA to re-
evaluate and analyze the quality standards and processes of the performing organizations.
Quality Management Plan Reviews

The Project will incorporate the following reviews:
Technical Quality Assurance Reviews (SAP Safeguarding) are scheduled to ensure that the
solution and system can handle the anticipated volumes and that Interface design and
performance are acceptable. Below is a list of the SAP Safeguarding Scope to be coordinated with
the SAP Technical Quality Manager. All technical QA services, activities and project deliverables
will be scheduled, tracked, and monitored in the Project Schedule.
QA Service Dates Description Service days Client Environment

required Resource
Demands
Project Quality Gates are conducted by Project Management and the Team Leads to ensure that
all relevant project deliverables have been completed at key project milestones. Each Quality-Gate
has pre-defined entry and exit criteria.
Project Review Type Target Date Client Resource Output from the
of Review Demands Review
Project Preparation Completed
(Mandatory)
Business Solution Validation Completed
(Mandatory)
Baseline Configuration Completed
(Optional)
Final Configuration Completed – Project
Readiness for Integration & Customer
Acceptance Test (Optional)
Realization Completed (Mandatory)
Deploy Phase Completed (Mandatory)
Project Closure (Optional)
SAP Project Reviews provide a proactive quality assurance review, with an impartial analysis of
all aspects of the project – across all project management disciplines, enabling early detection of
project issues with actionable recommendations. The approach taken normally involves
interviewing selected members of the Client and SAP or Partner Project Teams. A report is
29
produced from the Review, which is presented back to Client and Partner. Key findings will be
reviewed and discussed with the Project Leadership.
The following reviews are planned to take place during the course of the project according to the
Quality Assurance procedures:
Project Review Type Target Service Client Output from Project
Date of days Resource the Review Comments
Review required Demands
 Prepare Phase end
 Explore - Phase end
 Realize - during the configuration

cycle, before integration testing
 Deploy - two to four weeks before
going live
 Post-Go Live Support, approximately

four weeks after going live
[Provide the listing of any additional QA Services in scope of contract.]
30
HUMAN RESOURCE MANAGEMENT PLAN
Introduction
Human Resource Management is concerned with the aspect of managing resources on the
project, as they roll on and off the project. In the best case scenario the earlier you engage
resources / team members in the project activities, the higher the likelihood of success. The main
focus of the Resource Management Plan is to develop the basis for managing the processes of
this area and producing a productive, highly efficient and effective team.
Purpose
Project Human Resource Management includes the processes that organize and manage the
project team. The project team is comprised of the people who have assigned roles and
responsibilities for completing the project. While it is common to speak of roles and responsibilities
being assigned, team members should be involved in much of the project’s planning and decision-
making. Early involvement of team members adds expertise during the planning process and
strengthens commitment to the project. The type and number of project team members can often
change as the project progresses. Project team members can be referred to as the project’s
staffing. Project human resources are essential part of the planning process, executing process,
monitoring and controlling process, and closing process of each project.
Procedure
Human Resource Management is a continuous process composed of 4 steps including regular
reporting:
31
Acquire Develop Manage
HR
Project Project Project
Planning
Team Team Team
Identify and document project roles and

Interviewing
responsibilities
Improving
and competencies,
obtaining
and Tracking
reporting
project
team
interactions
relationships
team
performance,
resources
of teamproviding
membersfeedback,
to enhance
resolving
performance
issues,
Human Resource Planning

Human Resource Planning involves identifying and documenting project roles, responsibilities, and
reporting relationships, as well as creating the staffing management plan.
This plan will be developed by <enter name of> SAP Project Manager, <enter name of> Customer
Project Manager, and <enter names of any others who will participate>.
The definition of project roles and responsibilities are developed with an understanding of the
existing business and technical organizations that will be involved in the project and how they
interact in the current operating environment. Organizational environment factors include the
following:
 The following business organizations, departments or groups impacted by project
implementation: (i.e., Finance Group, Production, Engineering, Procurement, Purchasing,
Worldwide Sales Operations, Warehouse Management & Distribution, Retail Sales)
 The following technical organizations, departments or groups impacted by project
implementation: (i.e., basis, security & administration, programming and development, portal,
support desk, business warehouse)
 Type of organizational structure – functional organization, matrix organization (weak matrix,
balanced matrix, and strong matrix), projectized organization.
 Reporting structure and organization management style: autocratic, consultative, democratic,
or entrepreneurial
 Logistical implications: name operational units, countries, locations, languages, time zones
involved and/or impacted with delivery of project
<<Customer Project Name>> Organization Chart is arranged according to a breakdown of project

deliverables and the organization’s existing departments, units, or team structure.
 Steering Committee
 Project Sponsor
 Project Management Office
 Functional Teams (Finance Plan to Actual, Procure to Pay, Order to Cash)
 Organizational Change Management (Change Management, Training, Communication)
 Integration/Cutover Lead
 Programming & Development (Reports, Interfaces, Conversions, Enhancements, Forms &
Workflow)
 Global Delivery Center – Offshore
 Technical (Basis, Security & Administration, Portal, Support Desk)
32
 Business Warehouse
The <enter name of> SAP Project Manager, <enter name of> Customer Project Manager, and
<enter names of any others who will participate> will determine the project roles, authority,
responsibilities, experience level, and competency level required to deliver key deliverables and
meet project milestones as defined in the WBS of the project. Project roles and responsibilities are
utilized to document internal and external job requisitions to fulfill temporary project positions.
 Initiate assignment of GD Project Manager for offshore development > 100 person days <<if
applicable>>
 Initiate process for on-shore GD personnel <<if applicable>>
<enter names of any others who will participate> will develop a Responsibility Assignment Matrix
or RACI (Responsible, Accountable, Consulted, and Informed) Chart by project implementation
phase that will be used to align project team member roles and work to be done to complete
deliverables, noted in the WBS of the project.
The type and number of project team resources can often change as the project progresses. As a
result, a staffing management plan will be continually reviewed and updated at the beginning and
end of each major milestone as defined in the Work Breakdown Structure of the Project to address
ongoing staff acquisition, availability by resource, on-boarding, and development actions.
<enter names of any others who will participate> will define recognition and rewards process for
recognizing and rewarding desirable behavior of project team members. Utilize organization’s
policies, procedures, and systems to reward project team members during the course of the
project, which may include recognition dinners, certificates of appreciation, newsletters, bonus
structures, corporate apparel, and/or gifts in accordance with corporate guidelines (e.g., $25 gift
certificate).
Release criteria of internal project team resources will be in accordance with <<Customer Name>>
human resource policy and procedures or statement of work for external consultants, contractors,
and temporary staffing. Prior to release of project resources, the <enter name of> SAP Project
Manager, <enter name of> Customer Project Manager, and <enter names of any others who will
participate> will need to determine project impact, issues and/or risks of not delivering project
deliverables and/or meeting project phase milestones associated with releasing project team
members during the project implementation.
Acquire Project Team

Acquiring Project Team resources involves obtaining available resources both internally and
externally to complete the project. Recruit, interview, and hire open project roles, based on
resource availability, ability, competency level, interests and cost, and experience level required to
deliver key deliverables and meet project milestones as defined in the WBS of the project.
<enter names of any others who will participate> will abide by <<customer name>> HR policies
and procedures governing staff or the recruitment, hiring and on-boarding of project team
members. In addition, the <enter name of> SAP Project Manager, <enter name of> Customer
Project Manager, and <enter names of any others who will participate> will:
 Review and update project organization chart to determine number of resources need for the
project
 Update project roles and responsibilities to reflect current positions, skills, job requirements,
and competencies needed for the project
 Negotiate internal project team staffing with functional managers for staff assignment
availability and experience level to deliver project.
33
 Assist HR with documenting job requisition requirements for open project team positions
 Interview internal and external project team candidates
 Update staffing management plan, along with project schedule to identify when resources will
be needed and other pertinent inform required to recruit, interview, and hire new project team
members.
<enter names of any others who will participate> will maintain project team directory and project
team on-boarding email or document.
Develop Project Team

<enter names of any others who will participate> will develop project team members by improving
the competencies and interaction of team members to enhance project performance. The following
development activities will be initiate to enhance team effectiveness:
 Co-locate active project team members in the same physical location to enhance their ability to
perform as a team. Set-up and establish electronic communication (i.e., email,
teleconferencing, and video conferencing) and applicable system access for virtual team
members.
 Establish ground roles and clear expectations regarding acceptable behavior by project team
members
 Conducting on-site and off-site training to enhance competencies of project team members to
complete project activities.
 Level 1 Training
 Methods & Tools Training
 Project Risk & Issue Management Process Presentation
 Global Delivery – Offshore Development Overview
 Diversity Training
 Incorporate team building exercises during project team meetings to promote trust and
cohesiveness among team members in order to raise productivity through teamwork.
 Phase Kick-off Meetings
 Team Meetings
 Individual Team Building Sessions (if required)
 Phase Closure & Lessons Learned Meetings
 Recognize and reward team members for desirable project team behavior as part of the
recognition and reward process defined in Human Resource Planning.
Continually monitor and assess team performance to determine whether development efforts need
to be adjusted in order to improve project team’s effectiveness.
34
Manage Project Team
Management of the project team is complicated when team members are accountable to both a
functional manager and the project manager with a matrix organization. Effective management of
this dual reporting relationship is often a critical success factor for the project, and is generally the
responsibility of the project manager(s).
The <enter name of> SAP Project Manager, <enter name of> Customer Project Manager, <enter
name of> SAP Team Lead, <enter name of> Customer Team Lead, and <enter names of any
others who will participate> will track team member performance, by providing timely feedback,
resolving issues as they arise, and initiating corrective actions or changes to enhance project
performance.
Performance appraisal process, procedures, and timing for project team member feedback will
adhere to individual company processes and procedures for both internal and external resources.
The need for formal or informal project performance appraisals depends on the length of the
project, complexity of the project, organizational policy, labor contract requirements, and the
amount and quality of regular communication. At minimum, performance appraisal for individual
team members should occur at the end of project or end of their assignment. The following inputs
should be utilized for project team member performance appraisal:
 Project organization chart to determine reporting relationship within project team and among
project team members. Project team members should receive appraisal from individual who
supervise project work and individuals he or she worked with to complete project deliverables.
 Team member role and responsibility
 Time period project team member work on the project
 Team performance assessments of project team member performance
 Work performance information
 Performance reports provide documentation about performance against plan.
Prior to release of project resources, the <enter name of> SAP Project Manager, <enter name of>
Customer Project Manager, and <enter names of any others who will participate> will need to
determine project impact, issues and/or risks associated with releasing project team members
throughout the project implementation. As a result, project resource changes, whether by choice
or by uncontrollable events, can affect the rest of the project plan. When project resource issues
are going to disrupt the project plan, such as causing schedule to be extended or the budget to be
exceeded, a change request can be processed through the integrated change control process.
As part of the project’s lessons learned document, Prior to release of project resources, the <enter
name of> SAP Project Manager, <enter name of> Customer Project Manager, and <enter names
of any others who will participate> should collect or document the following human resources
lessons learned:
 Project organization chart, project team roles and responsibilities, and any staffing
management plans.
 Ground rules, conflict management techniques, and recognition events
 Procedures for virtual teams, co-location, training, and team building techniques proven to be
successful
 Special skills or competencies by project team members that were observed or discovered
during the project
 Issues and solutions documented in issue log.
35
COMMUNICATION MANAGEMENT PLAN
Introduction
Communication Management is focused at planning for and ensuring that the information needs of
the project are planned. Communications Management includes the processes of communications
planning, information distribution, status reporting and stakeholder management. Each of these
processes contain underlying activities, inputs, outputs, tools and techniques based on the
methodology and the needs of the project. As with the other management areas, it is essential that
a communications management plan is developed, communicated and employed during project
execution. It is only through the use of these communication tools and techniques that the project
stakeholders, both internal and external to the project become aware of the project objectives,
issues, milestones and deliverables.
Purpose
Project communications management includes the processes required to ensure timely and
appropriate generation, collection, distribution, storage retrieval and ultimate disposition of project
information. The project communication management processes provide the critical links among
people and information that are necessary for successful communications. Project managers can
spend an inordinate amount of time communicating with the project team, stakeholders, customer,
and sponsor. Everyone involved in the project should understand how communications affect the
project as a whole.
Procedure
Communication Management Plan is a continuous process composed of 4 steps including regular
reporting:
Communication Performance Manage

Information Distribution
Planning Reporting Stakeholders
Determining information
Providing
andCollecting
communication
project and
information
distributing
needsavailable
of project
performance
toManaging
stakeholders
project
information,
stakeholders
including
in a timely
communications tostatus
manner
reporting,
satisfy progress measure
the requirements of and re
Communication Planning
Determining the information and communication needs of the project stakeholders and determining
a suitable means of meeting those needs is an important factor for project success. Project
Stakeholders are identified in the project scope statement.
Communication has many dimensions:
36
 Written and oral, listening, and speaking
 Internal (within the project) and external (customer, the media, the public)
 Formal (reports, briefings) and informal (memos, ad hoc conversations)
 Vertical (up and down the organization) and horizontal (with peers)
NOTE: <<Customer Public or Investor Relations Group>> is responsible for all external (customer,
the media, the public) communication regarding company business.
Audience of project communication:
 Project Sponsor
 Project Steering Committee Member
 PMO Team Member
 Project Team Member
 A project stakeholder is a person or organization that are actively involved in the project, or
whose interests may be positively or negatively affected by execution or completion of the
project. A stakeholder may also exert influence over the project and its deliverables.
This plan will be developed by <enter name of> SAP Project Manager, <enter name of> Customer
Project Manager, and <enter names of any others who will participate> before the end of project
preparation.
In order to promote better communication within the project, the following procedures will be
implemented:
 Weekly project team meetings with PMO and Team Leads. Each team will produce a project
status report on a weekly basis which will highlight their key accomplishments for the current
week and key objectives for the following week, risks and issues with individual mitigating
activities, resources constraints, as well as scorecard.
 Weekly project status reports and scorecards from team leads to PMO
 Weekly project reports from PMO to <<customer>> sponsor and CIO and SAP management
team
 Weekly communication of project status and expectations from PMO to all project team
members and <<customer>> stakeholders
 Monthly steering committee presentation from PMO to <<customer>> sponsor and CIO and
SAP management team
 Quarterly executive committee presentation from <<customer>> sponsor to <<customer>>
board members.
 Weekly project time reporting from <<customer>> project team members to <<customer time
system>>
 Monthly project financial reporting from project analyst to <<customer>> budget analyst /
project controller
 Ad hoc reporting needs or requirements will be assessed on as is basis
 <<Add additionally reporting requirements>>
<enter names of any others who will participate> will review the project issue log, risk log, and
change log on a weekly basis and report updated issue, risk, and change log metrics in the weekly
project status reports and monthly steering committee presentation.
Communication planning often entails creation of additional deliverables that require additional
time and effort. The <enter name of> SAP Project Manager, <enter name of> Customer Project
Manager, and <enter names of any others who will participate> will review communications plan on
a regular basis throughout the project and revise plan as needed. Thus, the project’s work
breakdown structure, project schedule, and project budget are updated accordingly.
Information Distribution
Making needed information available to project stakeholders in a timely manner. As part of the
communications process, the sender is responsible for making the information clear and complete
37
so that the receiver can receive it correctly, and for confirming that it is properly understood. The
receiver is responsible for making sure that the information is received in its entirety and
understood correctly.
The following information distribution methods will be utilized by the project team:
 Project meetings, soft-copy and hard-copy document distribution, manual filing systems and
shared access electronic databases (i.e., ORM applications)
 Electronic communication and conferencing tools, such as email, fax, voicemail, telephone,
video and web conferencing, and web publishing.
 Solution Manager will be the central repository for working project documentation and project
records throughout the life of the project. Access to Solution Manager will be restricted to
project personnel only with varying levels of authorization.
<<identify other methods and tools for project management, such as web interfaces to scheduling
– project server, meeting and virtual office support software, portals, instant messaging, and other
collaborative work management tools that will be utilized by project>>
Types of project information distributed throughout the project:
 Project Reports
 Project Presentations
 Project Records
 Lessons Learned
 Stakeholder feedback and notifications
 Change Requests
Reporting
Collection of baseline data and distribution of performance information to stakeholders on a timely
basis. Performance reporting should include information on scope, schedule, cost, quality, project
risks, along with how resources are being used to achieve project objectives.
Performance reporting will provide:
 Work performance information on the completion status of deliverables and accomplishments
 Performance measurements
 Forecasted completion
 Quality control measurements
 Performance measurement baseline
 Corrective Actions
 Deliverables
Manage Stakeholder
Managing communications to satisfy the requirements of and resolve issues with project
stakeholders.
<enter names of any others who will participate> are responsible for stakeholder management.
Communication methods that will be utilized to manage stakeholders include:
 Face to face meetings
 Web or video conference meetings (international stakeholder meetings)
 Issues log – As stakeholder requirements are identified and resolved, the issues log will
document concerns that have been addressed and closed.
 Action item log
 Approved corrective actions
38
39
RISK MANAGEMENT PLAN
Introduction
Project success depends, in part, on having a clear understanding of the risks that we face as an
organization. The project risk management plan describes how risk management will be structured
and performed in the project
Risk Management Process Detail

Project Risk Management includes the processes involved in planning, identifying, quantifying,
qualifying and monitoring and controlling risks and opportunities in an effort to complete the project
in a controlled and monitored environment reducing the possibilities of negative events and taking
advantage of the opportunities for positive activities
The key elements of SAP’s Project Risk Management process are as follows:
■ Risk Planning is concerned with determining how to approach the Risk Management
activities for your business area or project.
■ Risk Identification involves identifying the threats to your business or project objectives.
■ Risk Analysis involves determining which risks are the most important by way of a
quantitative and qualitative assessment of the identified risks.
■ Risk Response involves deciding what actions to take concerning specific risks or
opportunities.
■ Risk Monitoring is the process of keeping track of the risks and the corresponding actions,
and looking for new threats to your objectives.
Each of these process areas is discussed in detail below.
Risk Assessment
Risk Risk Risk Risk Risk

Planning Identification Analysis Response Monitoring
Roles and Responsibilities

There are different roles involved in the risk management process with the following
responsibilities.
Role Responsibilities
Project Sponsor Sign-off of initial Risk Management Plan and of changes to it
Escalation level for risk management process
Project Manager Participate in the project planning activities and manage the execution of
projects according to plan.
Manage project stakeholder relationships.
Manage and communicate a clear vision of the project’s objectives,
Proactively identify changes in work scope and ensure appropriate planning
measures are taken with internal and external stakeholders to reassess and
amend the scope of work requirements, budget and timeline.
40
Role Responsibilities
Manage the financial aspects of the project: budgeting and estimate to
actual variance.
Analyze risk, establish contingency plans and identify trigger events and
responsibilities for initiating mitigating action.
Escalate issues early about the project to account management.
Risk Manager Setting standards for the risk management process
Managing and controlling of the risk management process
Responsible for the methodology and the realization of the risk management
in the project
Moderation of risk workshops
Participation in the development of risk response strategies
Monitoring of the realization and the success of the risk responses
Responsible for the risk reporting towards the steering board
Note: The risk manager is responsible for running the process and not
for the content of the project risk register.
Sub-Project Responsible for the identification of risks within the sub-project effecting the
Manager whole project and reporting of those risks to the project management
(IT and
Business)
Team member Reporting of identified project-internal and project-external risks
The roles described above do have a different involvement level during the entire risk management
process.
Steps Roles and responsibilities

Project Risk Manager Sub-Project All project
Manager Manager members
Risk planning A !R - -
Risk identification R !R R R
Risk evaluation R !C R I
Definition of risk A/R !R R -
responses
Risk monitoring and I !R I I
reporting
Legend
Rol Responsible for content execution R
e
Rol Accountable for the process step A includes involvement
e (C)
Rol To be consulted / Involved C includes information (I)
e
Rol To be informed I
e
Rol Responsible for the execution of the !
e process step“
Project Stakeholder Mapping

Role Name
Risk Sponsor Risk Sponsor Name
Project Manager Project Manager Name
41
Risk Manager Risk Manager
Sub-Project Manager 1 Risk Manager
42
Risk Planning
Risk Planning is concerned with establishing the context for the Risk Management process. It
includes defining the objectives of the business unit or activity to which the Risk Management
process is being applied, identifying and surrounding the activity, and setting the boundaries for the
process.
(For information purposes only. Delete this section prior to finalizing the risk management plan.
Among the questions that should be addressed during this phase and document in the PRR are):
■ Do we have a clear understanding of the business objectives?
■ Who should be involved in the Risk Management process for this activity?
■ Who must approve the results of the risk assessment?
■ How often do we review these results?
■ How often and to whom do we report the results?
■ What is the escalation path and procedure in case risks cannot be managed successfully?
■ What is the time horizon for this activity?
Risk Identification
Risk Identification is about uncovering potential sources of strategic, operational, technical or
environmental risks that might negatively impact the achievement of the project’s objectives.
Conversely, identification may also result in discovering an opportunity that may have a positive
impact on the objectives. Once identified, all risks should be documented and tracked in the PRR.
Unless a risk is written down, there is a good chance that it won’t be managed. Therefore all
identified risks should be recorded.
Participants in the risk identification process should include subject-matter experts, business unit
managers, project / account team members, and other stakeholders as required.
Among the questions that should be addressed during this phase are):
■ What assumptions have we made about the activity?
■ What constraints are limiting our ability to achieve the objectives?
■ Are there any other internal or external factors that we need to be aware of?
■ Is there any experience from comparable projects?
■ Which uncertainties exist?
■ What kind of consequences do we expect?
Risk Indicator
A risk is usually identified when factors exist leading to the belief a particular problem could occur,
or that the risk situation is worsening. The risk indicator provides information (or clues)
substantiating the original risk, or confirming a worsening / improving situation. The indicator can
be used to determine whether or not the risk warrants the allocation of (scarce) management
resource. If the indicator is weak (e.g. based on speculation as opposed to factual evidence), then
the risk would not likely warrant active management. Well-substantiated, fact-based indicators help
prioritize Risk Management efforts.
Assessment Horizon
When identifying risks, the time horizon (referred to as the assessment horizon) should be
consistent with the time horizon of the related objectives defined in the Risk Planning phase. By
focusing only on short to mid-term objectives, we tend to focus on risks within those time frames.
However, some aspects of the project activities could extend to a longer term. Hence, it is
important that we be aware of the longer timeframes, and not ignore risks that might be further out.
43
Risk Analysis
Key Analysis Attributes
Risk Analysis involves the developing of an understanding of the risk severity in order to determine
which risks need to be managed. We understand risk as an event of a certain impact (I) that is
likely to happen with a certain probability (P). Therefore, the severity of a risk can be determined
as:
Risk (severity) = P x I
The phrase “a risk occurs” is hence conveniently used synonymously with “an event occurs”
throughout this text.
Probability
The degree of uncertainty associated with a risk is described using the term probability to indicate
how likely you expect the risk to occur. Probability will be described numerically with a value
between 1 and 99% as shown in the table below.
Level Probability Range Description
1 1 – 19% Risk will occur only under exceptional circumstances
(within the assessment horizon)
2 20 – 39% It is unlikely that the risk will occur (within the
assessment horizon)
3 40 – 59% Risk is likely to occur (within the assessment horizon)
4 60 – 79% Risk is highly likely to occur (within the assessment
horizon)
5 80 – 99% Risk is nearly certain to occur (within the assessment
horizon)
The low end of scale is used when there is a remote (very low) chance that the risk will occur,
whereas the high end of the scale is used if you think a risk is nearly certain to occur (very high
chance). Since the determination of probability is usually subjective, don’t try to be precise.
Instead, find the range that you think best represents the likelihood of the risk occurring, and select
a probability within that range. If in doubt, go with the mid-point.
Impact
The second attribute of a risk is the effect it would have on business objectives if the risk were to
occur. There are two methods for analyzing the risk impact: qualitative analysis and quantitative
analysis.
Qualitative Impact Analysis: This method is used when data is not available for a quantitative
analysis, or when you want to perform an initial analysis while you are researching numerical data.
When using this analysis method, the impact definitions will reflect the objectives of the project
activity that is being assessed. See appendix section for sample qualitative levels and definitions.
Quantitative Impact Analysis: Quantitative analysis uses numerical values to express the impact
if the risk were to occur. The impact is usually expressed in financial terms (e.g. unplanned costs,
revenue loss, etc…) often referred to as Total Loss, or Un-weighted Exposure. When quantifying
the impact, it is important that the unit of measure be clearly understood. See appendix section for
sample qualitative levels and definitions.
With impact levels and definitions agreed to, fill in the following table to illustrate project specific
impacts as they relate to time, cost, quality and functionality related risks. Data in blue is sample.
Impact rating and definitions
1 2 3 4 5
Time Effects on results in a results in a results in a results in a
time have time delay of time delay of time delay of time delay of
to be up to 5% of up to 15% of up to 25% of more than 25%
44
neglected. the total the total the total of the total
project project project project
duration duration duration duration
Costs Effects on results in a results in a results in a results in a
costs have cost increase cost increase cost increase cost increase
to be up to 5% up to 15% up to 25% higher than
neglected. 25%
Value Effects on results in a results in a results in a results in a
value have value value value value decrease
to be decrease up decrease up to decrease up higher than
neglected. to 5% 15% to 25% 25%
Quality Effects on results in a results in a results in a The product is
quality have deterioration deterioration considerable useless.
to be of the quality of the quality deterioration
neglected. in uncritical in critical of the quality;
areas of the areas of the the customer
project/produc project/product must approve
t this
Functionality Effects on results in a results in a results in a The product is
/ Scope function or deterioration deterioration considerable useless.
scope have of functionality of functionality deterioration
to be in uncritical in critical of
neglected. areas of the areas of the functionality;
project/produc project/product the customer
t must approve
this
Timeframe
The timeframe for risk occurrence is the third factor to consider when prioritizing risks. The
following guidelines will be used for this project.
■ Short term: 0 – 3 months
■ Medium term: 3 – 12 months
■ Long term: More than 12 months
Risk Analysis Results
Risk Level
The risk level is derived from the intersection of the probability and impact as described in the heat
map table that follows.
Impact
5 medium medium high high high
4 low medium medium high high
3 low medium medium medium high
2 low low medium medium medium
45
1 low low low low medium
10% 30% 50% 70% 90%

Probability
For example, a risk with a probability of occurrence of 80% and an impact of 2 would be
considered a medium level risk.
Expected Loss
The term Expected Loss, or Weighted Exposure, is used to express the anticipated loss associated
with a risk, taking into account the probability and financial impact of the risk event. It is calculated
by multiplying the probability of the risk occurring by the Total Loss, where probability is a value
between 1% and 99% (see sample table below). Note that values may be changed to reflect
individual project requirements.
Probability Impact Expected Loss

(Total Loss)
Office Fire 10% $2,500,000 $250,000
System Failure 90% €1,000,000 €900,000
Free Consulting 50% ₤5,000,000 ₤2,500,000
Risk Priority
Prioritizing risks involves separating out which risks should be dealt with first when allocating
resources. One way to determine the relative priority of the risks is to map the risk level against the
time frame for the risk. The following table shows the time criteria used for risk prioritization.
Risk Level and Priority
Timeframe
Low Medium High
Short term 5 2 1
Medium term 7 4 3
Long term 9 8 6
With this method risks will be prioritized relative to each other based on their overall risk level.
Risks with the highest risk level and the shortest time frame would be considered first before
allocating resources. Of course there are numerous other techniques for prioritizing risks such as
Total Impact, Expected Loss, Risk Category, etc. Professional judgment will be used when
deciding which risks should be dealt with first.
Risk Interdependency
Risk analysis should also consider the interdependency of one risk on other risks.
46
Risk Response
General
In order to develop effective risk responses, we must be able to pinpoint the risk’s origin or cause
as well as the impact which may be stated in terms of costs, time or quality as shown in the figure
below.
Risk response involves deciding what, if anything should be done with a risk. This phase answers
two key questions which should be documented in the PRR:
1. What response actions can/should be implemented?
2. Who should be responsible for implementing those response actions?
Among the questions that should be addressed during this phase are):
■ Do we know enough about the risk?
■ Can we live with the risk?
■ Is it possible to avoid or eliminate the risk?
■ Is the effort needed for mitigation action adequate in relation to the risk?
■ Who is responsible to take the action?
Risk Response Options
Decisions on risk response options will involve subject-matter experts. Depending on the risk, the
response options will have to be reviewed and / or approved by project steering committee.
Responses to identified risks should be documented in the PRR and may follow the following
strategies:
Risk Response Description
Strategy
Delegate Transfer the risk to someone within the project organization who is in a
better position to control it.
Transfer Pass the risk on to someone outside the project organization who is able
to deal with it.
Research Learn more about the risk, in case information is missing
Mitigate Set up an action plan to mitigate or minimize risks. The action plan can
challenge the impact or the probability of the risk.
Accept Accept a risk, if it is not possible to mitigate it.
Watch Monitor if the impact or the probability of a risk increases, and decide on
an action plan at a later stage.
47
Risk Monitoring
Risk Monitoring is the process of keeping track of the risks and evaluating the effectiveness of the
response actions. Monitoring may also provide a basis for developing additional response actions
and identifying new risks.
Risk monitoring is an ongoing activity aimed at ensuring response plans are working and new risks
are being captured. Appropriate timelines and follow-up assessments must be agreed upon and
performed as part of the ongoing monitoring activities as described below:
Among the tasks that should be addressed during this phase are):
■ Collecting information about the attributes (probability, impact and timeframe) of the Top n
risks being managed
■ Observing risk triggers for information regarding potential risk occurrence and / or when to
execute on a recovery (contingency) plan
■ Risk reporting
■ Monitoring business unit compliance with the Risk Management policy
Activity Description
Who Risk manager/project manager
What All risks included in the project risk register
How often High risk impact: Monitor risk development and risk response results on
a weekly basis
Medium risk impact: Monitor risk development on a weekly basis
Low risk impact: Monitor risk development on a monthly basis
How Re-evaluate probability level
Re-evaluate impact level
Define required action if risk score changes
Glossary
Assumption
A supposition or something that is taken for granted surrounding a business activity. Assumptions
should be documented during Risk Planning. Incorrect assumptions can lead to risks. It is
important that you test your assumptions in terms of their instability (likelihood that the assumption
will turn out to be false), and sensitivity (impact if the assumption turns out to be false).
Business Owner
Generally any individual who is authorized to transact business on behalf of SAP. For much of the
GFO organization the Business Owner is also the Risk Owner.
Condition
A short description of the key circumstances, situations etc., causing concern, doubt, anxiety, or
uncertainty. In the risk statement, the condition phrase is the phrase at the beginning of the
statement. The condition component of the risk statement focuses on what is currently causing
concern. The condition provides information that is useful when determining how to respond to the
risk. An example condition is: “We do not have the required experience for the interface.”
Consequence
A short description of the possible negative outcomes of the current conditions that are creating
uncertainty. In the risk statement, the consequence phrase is the phrase at the end of the
statement. The consequence component focuses on the impact of the risk. The consequence
contains useful information to help you determine how much time, resource and effort should be
48
allocated to the response effort. An example consequence (related to the above condition) is: “The
interface code may not be completed on time and may be inefficient.”
Constraint
A limitation or restriction surrounding a business activity. Constraints should be documented during
Risk Planning. Constraints that are removed (or relaxed) could result in a more favorable situation.
It is important that you test your constraints in terms of their instability (likelihood that the constraint
will be relaxed) and sensitivity (impact if the constraint is removed).
Issue
A risk that has occurred. Key customer issues are managed through the escalation process, or are
managed via contingency plans and / or reactive problem solving.
Maintenance
Operational risks
The risk of loss resulting from inadequate or failed internal processes, people, systems, or other
external events.
Reassessment
The process of reviewing prior risk assessments in an effort to identify, quantify, analyze and
monitor new and existing risks.
Risk Assessment
The process of identifying, analyzing, responding, and monitoring risks for an activity. Examples of
activities include: Software and Service Opportunities, Implementations, Internal or Development
Projects and Subsidiary Risks.
Risk Interdependency
The multiplying impact of a risk on other risk, whether within or outside your business area.
Risk Management
The process by which SAP methodically addresses risks.
Risk Triggers
Values that define when an action, such as implementing a contingency plan, may need to be
taken. Risk triggers are generally used to provide warning of an impending critical event, or to
indicate the need to implement a contingency plan to preempt a problem.
Strategic risks
Events and trends that could damage SAP’s shareholder value.
Top - N
A list of the most significant risks to a business unit or project.
Validation
The process of reviewing and approving the results of a risk assessment.
49
PROCUREMENT MANAGEMENT / CONTRACT INVENTORY
Purpose
The project Contract Inventory contains all contractual agreements with product and service
providers. This may include contractual arrangements with hardware providers, organizational
change management, training, hosting, off-shore delivery and application management service
providers, just to mention a few.
50
www.sap.com/contactsap
© 2018 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.
The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark
information and notices.

Subsidiary Project Management Plans: Internal

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Subsidiary Project Management Plans: Internal

Uploaded by

Copyright:

Available Formats

Subsidiary Project Management Plans

Procedure by which project team members update p

Establish the Change Control Board (CCB) and delegate authority

Implement Change Request Procedure

Step 4: Change Control Board (CCB) reviews change requests

Update the Project governance and control documents

Issue Issue Issue

Issue Name: Title of Issue (short name or description)

Escalation in line with the Project Sponsor

Bus iness Design Quality Assurance

Project Management SAP Project Management <Client> Ris k Management

Project Team Members SAP Project Team Members <Client>

Reporting to/ Escalating to: Information:

© SAP 2008 / Page 4 confidential

Scope ScopeDefini ScopeVerifica ScopeContro

Scope Management Planning

Activity definition methods and tools

Activity sequencing methods and tools

Outputs for activity sequencing

Activity Resource Estimating

Activity resource estimating methods and tools

Activity Duration Estimating

Inputs for activity duration estimating

Outputs for activity duration estimating

Outputs for schedule development

Inputs for schedule control

Schedule control methods and tools

Outputs for schedule control

Cost Cost Cost

Costing estimation techniques:

Output of cost estimation:

Inputs for cost budgeting include:

Cost budgeting methods and tools:

Outputs for cost budgeting:

Cost control methods and tools:

Outputs for cost control:

■ Customer satisfaction is an integral part of quality management and is monitored at key

Perform Quality Assurance

▪ Organizational quality policies, procedures and guidelines will be adhered to by the

▪ Prepare Phase<<enter milestone date>>

Perform Quality Control

Quality Management Plan Reviews

QA Service Dates Description Service days Client Environment

Deploy Phase Completed (Mandatory)

Project Closure (Optional)

 Explore - Phase end

 Realize - during the configuration

 Post-Go Live Support, approximately

[Provide the listing of any additional QA Services in scope of contract.]

Identify and document project roles and

Human Resource Planning

<<Customer Project Name>> Organization Chart is arranged according to a breakdown of project

Acquire Project Team

Develop Project Team

Communication Performance Manage

Risk Management Process Detail

Each of these process areas is discussed in detail below.

Risk Risk Risk Risk Risk

Roles and Responsibilities

Steps Roles and responsibilities

Project Stakeholder Mapping

5 medium medium high high high

4 low medium medium high high