1. DRAFT
Client X OSS Program Management Office (PMO)
February 2010
Play Book

2. - 2 -
DRAFT
Background and Context 3
PMO Framework – Overview 4
Program Governance 5
Action Item Management 9
Issue Management 10
Decision Management 12
Status Reporting 13
Next Steps 14
PMO Templates 15
Contents

3. - 3 -
DRAFT
Background and Context
The purpose of this document is to serve as a guideline to the key activities and processes that will be executed and
followed by the B/OSS program team. The contents of this document will help with the following:
 Describe the overall Program Management Framework
 Describe the proposed governance organization with roles and responsibilities
 Depict key responsibilities of the PMO, including process flows, tools, and templates (defined for
processes needed in the near term)
 The process flows for the remaining activities will be defined shortly. We wanted to get agreement on
the processes needed immediately

4. - 4 -
DRAFT
PMO Framework – Overview
The PMO Framework provides a structured approach to the effective set-up of the Program Management Office and delivery
of PMO activities for the B/OSS Platform.
The objective of the PMO Framework is to support the effective establishment and efficient operation of PMO
processes to assist Client X with on time and on budget delivery of its B/OSS platform.
Objective of the PMO FrameworkObjective of the PMO Framework
Issue and Risk ManagementIssue and Risk Management
Program Governance & OrgProgram Governance & Org
Communication ManagementCommunication ManagementScope Management & Change ControlScope Management & Change Control
Financial ManagementFinancial ManagementIntegrated Work Plan ManagementIntegrated Work Plan Management
PMO FrameworkPMO Framework
Vendor ManagementVendor Management
Quality ManagementQuality Management
Status ReportingStatus Reporting
TraceabilityTraceability
Resource ManagementResource Management
ActivitiesActivities
PMO
B/OSS Program
Integration
Dependency
Awareness
Program
Reporting
Standards
Adherence
PMO
Ensure smooth integration of milestones
and dependencies between B/OSS, third
party vendors, and other dependencies
Develop and disseminate standards for
project management, business analysis
and monitor compliance with PMO
standards
Enhance visibility across the different projects
by giving appropriate stakeholders information
they need to make effective and timely
decisions
Highlight linkages and dependencies to ensure
understanding across the portfolio of IT
projects
Decision ManagementDecision Management
Action Item ManagementAction Item Management

5. - 5 -
DRAFT
B/OSS Program Governance - Organization
The B/OSS Program will engage stakeholders through a structured governance process throughout the implementation
lifecycle.
Executive Sponsor:
<Client person name
cleansed>
Client X:
<Client person name
cleansed>
Deloitte:
Mark Litwin
Convergys:
Client person name
cleansed>
Day to Day Governance
Working Committee
Customer Care:
<Client person name
cleansed>
POS:
<Client person name
cleansed>
Finance:
<Client person name
cleansed>
Product:
<Client person name
cleansed>
Proc & Logistics :
<Client person name
cleansed>
Network:
<Client person name
cleansed>
Steering Committee
Client X CEO:
<Client person name
cleansed>
Client X CIO:
<Client person name
cleansed>
Client X CMO:
<Client person name
cleansed>
VP Network Eng:
Client person name
cleansed>
Client X CAO:
<Client person name
cleansed>
Client X CFO:
TBD
Core Day-to-Day Management Council
− Business Process Design & Overall Solution
Deloitte
Functional:
Chris Anderson
Convergys
Functional:
HJ
Client X
Functional:
Working
Committee
− Solution Architecture and Infrastructure
Deloitte
Integration:
Ajit Kumar
Convergys
Integration:
Client person
name
cleansed>
Client X
Integration:
TBD
− Data Migration
Deloitte
Migration:
TBD
Convergys
Migration:
Client person
name
cleansed>
Client X
Migration:
TBD
Client X:
<Client person
name cleansed>
Deloitte:
Minu Puranik
Convergys:
Client person
name cleansed>
PMO
CVG Executive:
<Client person name
cleansed>
Deloitte Executive:
Mark LitwinRate Plan/Pricing:
<Client person name
cleansed>

6. - 6 -
DRAFT
Program Governance – Roles and Responsibilities
The roles and responsibilities of the program team are described below.
 Establish and manage strategic direction and objectives of the B/OSS program
 Provide visible sponsorship of the program to all stakeholders
 Provide oversight and executive coordination of program management
 Communicate critical decisions, issue resolutions and program changes to project team
and corporate leadership
 Resolve cross-functional issues and escalated project decisions
 Approve change requests to project scope, budget, and timing
 Assist with identification and prioritization of project risks and mitigation strategies
Steering
Committee
 Serve as SMEs to provide information into the day-to-day management council
 Approve deliverables produced by the management council such as Business/Functional
Requirements
 Participate in requirements discussions and workshops
 Drive resolution of issues and action items in respective functional or technical domains
Working
Committee
 Provide leadership and overall management of day-to-day program activities
 Communicate strategic objectives and organizational strategy
 Assign project leaders and SME support to support required inputs and business decisions
required to support implementation
 Provide input / guidance to resolve program issues
 Review, provide feedback and approve project strategy and work / activity plans
Day to Day
Governance

7. - 7 -
DRAFT
Program Governance – Roles and Responsibilities Contd.
 Develop the overall program management framework, including a common set of project
management tools and templates
 Lead development of integrated program roadmap, including definition of sequencing and
prioritization criteria
 Define status reporting framework and process
 Structure and lead development of integrated work plans
 Collect work plan updates from project teams and incorporate into integrated plan
 Coordinate access to other individuals and information located across the organization
 Coordinate and communicate cross-functional activities and dependencies
 Manage and facilitate escalated and cross-functional issue resolution
 Execute risk assessment processes, risk prioritization and development of mitigation
strategies
 Define mechanisms for measuring project progress and success (time, budget, quality,
etc.)
 Intervene (where needed) to resolve key issues and drive scope changes
PMO
 Coordinate development and ongoing updates to the project (functional, technical and
migration and other components) work plan
 Establish accountability for achieving objectives at the working team level
 Provide ongoing leadership and overall management of functional, technical and migration
projects
 Resolve issues and action items in a timely manner
 Facilitate and prioritize interdependencies with other teams
 Provide visibility on key issues to day-to-day governance on risks and decisions that may
require Working Committee and Steering Committee guidance
 Support the identification and confirmation of potential costs, risks, and barriers to
achieving program milestones
Core Day to
Day
Management
Council

8. - 8 -
DRAFT
Program Governance – Meeting Cadence
The recurring meeting cadence for the various groups is shown below.
In addition to the meetings shown below, the working committee, management team, and PMO will meet on an ad-hoc basis
to discuss other items as they arise.
Meetings
# Group Cadence Schedule
1 Steering Committee Once every two weeks Monday 4.00 PM – 5:00 PM
2 Working Committee Every week Thursday 10:30 AM – 11:00 AM
3 Core Team Every week Wednesday 3:00 PM – 4:00 PM
4 PMO: Plan/Risks Discussion Every week Friday 12:00 PM – 1:00 PM

9. - 9 -
DRAFT
Action Item Management
Client X’s B/OSS implementation program has four threads that operate in parallel with simultaneous meetings occurring
across or within each thread. Therefore, for the most effective management of action items, the PMO recommends the
action items be tracked by each thread on a decentralized basis. The PMO will provide templates for capturing action
items, but the onus of capturing and following through with action items resides within each thread.
 The two artifacts for capturing action items are as follows:
Meeting Minutes Template Work Thread Specific Action Item Log
 Will be used to capture meeting minutes including
decisions and action items for all meetings
 Will be specific to each work thread
 Ownership of action items will be managed on a
decentralized basis by the work thread lead
 All action items from meeting minutes will be captured in
a centralized location
 This central inventory of action items per work thread
will give each work thread a holistic view of all open and
closed action items
 Ownership of the action item inventory is the
responsibility of each work thread

10. - 10 -
DRAFT
Action Item Log: Process Flow
Gather & Dispatch Resolve/Follow-Up Reconcile/Escalate
Jeff Boes updates action item log and sends
respective organizational action item log to POCs
every Friday at 9:00 AM CDT
PMO team, functional team, and
organizational POCs meet weekly on
Wednesday at 5:00 PM CDT to discuss
action items status with a focus on the
following:
Status of open items
Prioritization of open items
Decisions on open items
Escalation
Next Steps
Jeff updates action item logs and sends
respective organizational action item log to
POCs
Action items collected from meetings, touchpoint,
and conversations and prioritized by Deloitte
Jeff Boes updates FIMP* action item logs daily
with the following:
Action Item Details
Action Item Owner
– Respective Org. POC if none specified
Due date
– 1 week for high priority and 2 for medium
Jeff Boes filters logs and sends respective action
items to action item owners and POCs
Action item owners
verify assignment
and due date
POCs determine
owners for action
items
Organizational POCs meet with action item
owners/functional area delegates** from
their organization every Tuesday at 3:00
PM CDT focus on the following:
Status of open items
Decisions on open items
Issues and Risks associated with action
items
Determine target action items for next
week
POCs notify Jeff Boes of updates based
on weekly meeting with their respective
teams by Tuesday 6.00 PM CDT
Points of Contact (POCs)
Client X
CVG
Deloitte
<Client person name cleansed>
<Client person name cleansed>
Pallavi Pradhan, Anil Vaitla
Action Item Log Owner
Deloitte Jeff Boes
Timely resolution and escalation of functional action items is contingent on following the iterative comprehensive
process outlined below.
Iterative process
Jeff consolidates inputs from POCS and
updates action item logs
** Delegates will be assigned by business unit leaders as and
when team members are hired. In the meantime, identified
owners from IT will be the BU action item owners
POCs send out the action item log to their
respective organizational action item owners every
Friday at 12.00 PM CDT
Action item owners work on assigned
action items and send their action item list
to POCs by Tuesday 12: 30 PM CDT
POCs consolidate action item list from
owners and send to their action item team
by Tuesday 2: 00 PM CDT
*FIMP= Functional, Integration, Migration, PMO

11. - 11 -
DRAFT
Issue Management
Issue management includes registering, coordinating, solving and escalating issues across the teams within the program.
Unlike the action item management which is a decentralized process, issues and risks will be managed on a centralized
basis by the PMO.
 An issue is defined as an item that requires a resolution or a decision
 It is expected that the Team Leads will identify the majority of project issues, however, any team member can identify
an issue. The issue will be entered into the issue log by a PMO team member only. Team members will submit an
issue in a template provided by the PMO
 Once an issue has been identified, an Issue Owner will be assigned. The Issue Owner is responsible for driving
resolution of the issue, but updating information on the Issue Log is the PMO’s responsibility
 Should resolution of an issue result in a key decision being made, a decision should be entered into the Issue and
Decision Log. The log entry will allow the user to reference the decision related to each issue

12. - 12 -
DRAFT
Issue Management (Cont’d)
The artifacts used to captures issues/risks are shown below.
PMO
Deloitte Leads
CVG Lead
Team leads submit issues/risks
identified to the PMO using a template
provided by the PMO. One template
will be provided for each team lead
PMO manages the Master Issue/Risk
register and synthesizes issues/risk
from the individual work thread
templates
Synthesized Master Issue/Risk Register
Issue/Risk Register/Work Thread

13. - 13 -
Options can be provided for each risk criteria to determine the overall Delivery Risk Level for a function
Example Risk Criteria
Options
1 (Low Impact) 3 (Medium Impact) 5 (High Impact)
Scope and Complexity Impacts only one process or function;
few technical systems are impacted and
project planning, coordination and
execution are straightforward
Impacts multiple processes OR
multiple functions; moderate technical
systems are impacted OR project
planning, coordination and execution
are moderately difficult
Impacts multiple processes AND
multiple functions; multiple technical
systems are impacted AND/OR project
planning, coordination and execution
are complicated
Impact to the Business Little change which will be easily
implemented and accepted by the
business
Moderate change that will be
challenging to implement and
components of the change will be
accepted by the business
High degree of change that will be
difficult to implement and not easily
accepted by the business
Resources Client X has qualified personnel with the
required skill sets AND the personnel is
available for the initiative
This initiative requires skill sets that
are not present in Client X but are
easily available in the marketplace OR
personnel with required skill set is
unavailable
This initiative requires skill sets that
are difficult to obtain both in Client X
and in the marketplace
Interdependencies There is no dependency with other
internal or external initiatives or
resources
Weak dependencies or other internal
or external initiatives are dependent on
the successful implementation of this
initiative
Highly dependent on the successful
implementation of other internal or
external initiatives or resources
Duration Initiative duration is less than 3 months Initiative duration is between 3 months
and 6 months
Initiative duration is more than 6
months
External Stakeholders No impact to stakeholders Impacts stakeholders but NO
interaction required (i.e. no external
dependency on the success of this
program )
Impacts stakeholders AND interaction
required (i.e. there is an external
dependency impacting the success of
this program)
Internal Certification,
Regulatory Compliance,
Legal and Political Risk
Has no internal, regulatory, legal or
political risk
Has an internal and/or regulatory
and/or legal and/or political risk, but
extensive analysis has been
performed and a mitigation plan has
been developed
Has significant internal / regulatory /
legal / political risks that are difficult to
mitigate
Issue, Risk, and Decision Management Rating Guide:
Overall Delivery Risk Level Low (1-2), Medium (2-4), High (4-5)

14. - 14 -
DRAFT
Decision Management
Client X’s B/OSS implementation program has four threads that operate in parallel with simultaneous meetings occurring
across or within each thread. Therefore, for the most effective management of decisions taken, the PMO recommends that
decisions be tracked by each thread on a decentralized basis. The PMO will provide templates for capturing decision
items, but the onus of capturing the decision items resides with each work thread.
 The two artifacts for capturing decisions are as follows:
Meeting Minutes Template Work Thread Specific Decision Log
 Will be used to capture meeting minutes including
decisions for all meeting
 Will be specific to each work thread
 Ownership of decisions will be managed on a
decentralized basis by the work thread lead
 All decisions from meeting minutes if any will be
captured in a centralized location per work thread
 This central inventory of decisions per work thread will
give each work thread a holistic view of all decisions
taken

15. - 15 -
DRAFT
Status Reporting
Program status will be reported on a weekly basis.
 The PMO is responsible for publishing two status reports
1. Executive Status Report – Provides a dashboard view to Client X’s executives on B/OSS program status
2. Detailed Status Report – Provides a detailed view of the project status to the “core team”
 The process for publishing of the status reports is shown below
Synthesize status
reports and create
one integrated
executive status
report
Submit detailed
status reports by
6:00 PM CST
Monday Tuesday Wednesday Thursday Friday
Executive Steering
Committee
Core Team
PMO
Deloitte Leads
Approve status
report
Publish executive
status report
CVG Lead
Review integrated
status report with
team leads
Conduct core
team status
meeting
Update status
report if needed

16. - 16 -
DRAFT
Ground Rules
Effective and efficient execution of the program is contingent on the team following some basic ground rules.
 All team members should use a central repository for posting information. In this case, the E-Room is
the tool we will be using
 All meeting minutes should be published within a 24 hour timeframe, unless Chris Anderson has
approved an exception
 Action items and decision items captured in meeting minutes should be communicated to the thread
leads
 If thread leads require PMO assistance, they will communicate that to the PMO
 Issues/ Risks that arise in a meeting should be communicated to the PMO
 Thread leads own and drive the action items and decision logs for individual threads
 Prior to sending information to Client X leadership, the information must be shared internally with the
“core team”
 All corridor conversations that become action items/decisions should be communicated to the team
leads and officially tracked in the action item/decision log
 The E-Room is meant for the whole team, so don’t be afraid to post relevant information to the E-
Room
 Any questions following processes? Please ask your local PMO police – Minu Puranik and Jason
Sandler

17. - 17 -
DRAFT
Next Steps
We recommend executing the following next steps.
 Agree on overall approach and aforementioned processes
 Update processes or templates if needed

18. - 18 -
DRAFT
PMO Templates
Template Name Description Template
Meeting Minutes
Template
 Template used by each work thread to
capture meeting notes, decisions , and
action items
Work Thread Specific
Action Item Log
 Centralized location to track work thread
specific action items, one per work thread
Issue/Risk Register/Work
Thread
 Template to capture identified issues/risks
that are sent to the PMO
Work Thread Specific
Decision Log
 Centralized location to track work thread
specific decisions, one per work thread
Status Report
 Centralized location to track work thread
specific decisions, one per work thread
WIP
<deleted the embedded ppt
file and attached it
seperately to the record as
06_status report_c.pptx>
<deleted the embedded excel
sheet and attached it
seperately to the record as
05_work thread specific
decision log_c.xls>
<deleted the embedded excel
sheet and attached it seperately
to the record as 04_issue risk
register work thread_c.xls>
<deleted the embedded excel
sheet and attached it seperately to
the record as 03_work thread
specific action item log_c.xlsx>
<deleted the embedded word
document and attached it
seperately to the record as
02_meeting minutes
template_c.doc>

19. Appendix

20. - 20 -
DRAFT
PMO Activities
Activity Description Sample Artifacts
Program Governance &
Planning
 Determine and communicate standards
for creating project plans
 Define process for workplan updates and
tracking
 Define reporting metrics for workplan
items
Scope Management
 Scope Management defines and
manages what is and is not included in
the project work content (Project charter)
 Change controlling is the process by
which changes to project scope can be
implemented
Integrated Work Plan
Management
 Consolidated Program-level view of all
activities across projects to
‒ Track milestones, deliverables and
resources across projects
‒ Sync up activities, milestones, and
deliverables of individual projects
‒ Establish priorities and identify
dependencies
Resource Management
 A centralised process of requesting,
booking and allocating resources to the
projects activities
WIP

21. - 21 -
DRAFT
PMO Activities Contd.
Activity Description Sample Artifacts
Financial Management
Quality Management
Issue & Risk Management
 Issue management includes registering,
coordinating, solving and escalating
issues across the teams within the project
 Risk management involves identification
of risks, assessment and evaluation and
implementation of mitigation strategies for
the same
WIP

22. - 22 -
DRAFT
PMO Activities Contd.
Activity Description Sample Artifacts
Traceability
 Documents the dependencies and logical
links between individual requirements and
other system elements
Decision Tracking
 Outlines standards, policies and
procedures for tracking Project decisions
 Provides a repository for documenting the
impact of major decisions on the Project
timeline, budget, scope, quality and
resources
 Enables organization of major Project
decisions by decision-making body
Status Reporting
 The process of identifying and reporting
the progress of each sub-team and thus
the progress of the overall project
Communication
Management
 Involves the following activities
‒ Establish Program level communication
plan
‒ Provide communications to key
stakeholders
‒ Allow projects to control local
communications
WIP

23. - 23 -
DRAFT
Scope Management & Change Control
Scope management defines and manages what is and what is not included in the project work content. Change control is
the process and rules by which changes to project scope will be managed.
c The objective of the change control process is to establish a common process for defining, communicating and
managing scope changes with full traceability and accountability
 When will the change request processes kick in?
– Scope:  or 
– Cost:  or 
– Timeline increases
– Business requirements change
 To that effect, change control encompassess the following:
– Define change standards, policies, and procedures
– Manage and coordinate all changes to the projects
– Communicating change requests and its impact to appropriate constituents
– Assess and monitor the impact of proposed changes to the project timeline and deliverables
– Coordinate work activities associated with a change request

24. - 24 -
DRAFT
1 Day
DTDAGFilter#1–ValidationofChangeRequest
CCBFilter#2–Review
Reques
tor
Identif
y
Chan
ge
Complete
Draft
Change
Request
Form and
submit to
PMO
Enter into
CR Tool
Raise
to
DTDAG
Call a
special
meeting
with
DTDAG
Request
detailed
assessme
nt
Immediat
ely
Approve
(minor
changes)
Update
in DR
Tool
Communica
te decision
and update
plans
Reject EN
D
Raise to
Steering
Committe
e
Approve
Reject
Immediately
Approve
Update in
CR Tool
Communic
ate
decision
and
update
plans
Reject
Update
in CR
Tool
Communic
ate
decision &
update
plans
Execu
te
Chan
ge
Urgent
Update in
CR Tool
EN
D
PMO identifies and
coordinates appropriate
people and communicates to
all stakeholders.
EN
D
Update in
CR Tool
EN
D
EN
D
Update in
CR Tool
Guideline Principles
1) Is change required for Day 1 launch?
2) Is change critical to delivering legacy Company A (managed by client X) functionality versus a
‘nice-to-have’ (e.g. Can it wait for Phase II?)
One Week 1 Day One Week
EN
D
LEGEND
Requestor
PMO
Day to Day Client X Governance
SME & Management Council
Steering Committee
Not Urgent
One Week
Communic
ate
decision
and update
plans
Communica
te decision
and update
plans
Communic
ate
decision
and update
plans
Functional & Technical
Experts:
•Perform Impact/Risk
Assessment
•Cost Benefit Analysis
•Assessment of need for Day
1 operations
Execut
e
Change
Execute
Change
For external partners,
PMO will enter change
request into CR Tool.
Defer
EN
DUpdate in
CR Tool
Communica
te decision
and update
plans
Defer
EN
D
Update in
CR Tool
Communic
ate
decision
and update
plans
A list of deferred change requests will be generated for future release
planning. These items may be considered for allotment into a future
release.
Scope Management & Change Control (Cont’d)

25. - 25 -
DRAFT
Resource Management
Text
Use the descriptions from the
Appendix slides (the table you
had created)