program management playbook

DRAFT

Client X OSS Program Management Office (PMO)

February 2010

Play Book

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

DRAFT

Background and ContextThe 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 -

DRAFT

PMO Framework – OverviewThe 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 Framework

Issue and Risk Management

Program Governance & Org

Communication ManagementScope Management & Change Control

Financial ManagementIntegrated Work Plan Management

PMO Framework

Vendor Management

Quality Management

Status Reporting

Traceability

Resource Management

Act

iviti

es

PMO

B/OSS ProgramIntegration

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 Management

Action Item Management

- 5 -

DRAFT

B/OSS Program Governance - OrganizationThe 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 CommitteeCustomer 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 CommitteeClient X CEO:


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:


- 6 -

DRAFT

Program Governance – Roles and ResponsibilitiesThe 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 -

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 -

DRAFT

Program Governance – Meeting CadenceThe 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 -

DRAFT

Action Item ManagementClient 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 -

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 DetailsAction 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 itemsDecisions on open itemsIssues and Risks associated with action itemsDetermine 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 XCVGDeloitte

<Client person name cleansed><Client person name cleansed>Pallavi Pradhan, Anil Vaitla

Action Item Log OwnerDeloitte 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 -

DRAFT

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

Team member identifies an issue and logs in Issue

and Risk Log No

Team Lead assigns issue

owner

Issue Owner develops

resolution options and reviews with impacted parties

Team Lead determines if issue can be resolved at Work thread/Team

Level

Immediate escalation?

Resolve within team?

PMO review issue and proposed

resolution

Yes

PMO Resolved Issue

Steering Committee

Reviews Issue/Decision

Escalate to PMO No

PMO

No

Did resolution result in Decision

Set Issue status to “Closed”

Set Issue status to “Closed” and log

Decision

Yes

PMO and Team Lead prepare materials for

Steering Committee

No

Steering Committee

Steering Committee Resolved

Issue

Yes

Yes

Escalate to Decision

AcceleratorNo

Yes

Embarq Corporate Leadership Resolved

No

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

Options can be provided for each risk criteria to determine the overall Delivery Risk Level for a function

Example Risk CriteriaOptions

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 -

DRAFT

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

DRAFT

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

DRAFT

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

DRAFT

Next StepsWe recommend executing the following next steps.

Agree on overall approach and aforementioned processes

Update processes or templates if needed

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

Appendix

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

DRAFT

PMO Activities Contd.


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 -

DRAFT

PMO Activities Contd.


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 -

DRAFT

Scope Management & Change ControlScope 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 -

DRAFT

1 Day

DTDA

G Fi

lter #

1 – V

alid

atio

n of

Cha

nge

Requ

est

CCB

Filte

r #2

– Rev

iew

Impa

ct A

sses

smen

t

Requestor

Identify Change

Complete Draft Change Request Form and submit to PMO

Enter into CR Tool

Raise to DTDAG

Call a special meeting with DTDAG

Request detailed assessment

Immediately Approve (minor changes)

Update in DR Tool

Communicate decision and update plans

Reject END

Raise to Steering Committee

Approve

Reject

Immediately Approve

Update in CR Tool


Reject

Update in CR Tool

Communicate decision & update plans

Execute Change

Urgent

Update in CR Tool

END

PMO identifies and coordinates appropriate people and communicates to all stakeholders.

END

Update in CR Tool

END

END

Update in CR Tool

Guideline Principles1) 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

END

LEGEND Requestor PMO Day to Day Client X Governance

SME & Management Council Steering Committee

Not Urgent

One Week




Functional & Technical Experts:•Perform Impact/Risk Assessment•Cost Benefit Analysis•Assessment of need for Day 1 operations

Execute Change

Execute Change

For external partners, PMO will enter change request into CR Tool.

DeferEND

Update in CR Tool


Defer END

Update in CR Tool


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 -

DRAFT

Resource ManagementText

Use the descriptions from the Appendix slides (the table you had created)