Program Management Playbook
Download as PPT, PDF20 likes20,537 views
The document provides an overview of the program management framework for Client X's B/OSS program. It describes the program governance structure including roles and responsibilities. It also outlines key PMO processes like action item management, issue management, decision management, and status reporting. The processes are described along with templates and artifacts that will be used to track items and reporting.
Program Management Playbook
- 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)