OPP ITS Project Management Office (PMO) Guide

Intent of this Document

Version 1.0

The intent of this document is to serve as a Guide to the workings of the OPP ITS Project Management Office (PMO). The PMO is responsible for OPP ITS Project stewardship from a Projects inception, through development, lessons learned, and enhancements. This document is meant to be a guide and not necessarily written instructions on Project Management. However, all of the concepts outlined herein should be reviewed for applicability throughout the lifecycle of all OPP ITS Projects. Although all Projects might not need all the components listed in this document, any components listed that are used in Projects should be followed in accordance with this guide.

PMO Evolution
The PMO Evolution is depicted in the following diagram. Without having a PMO, the endeavors an organization undertakes can be disjointed, unorganized, and complicated. With the institution of a PMO the intent is to streamline, standardize, and simplify project management. As the PMO becomes involved with Projects, we will begin to understand how our endeavors improve the efficiency, effectiveness and the ability to partner with ITS, OPP and university level entities.

PMO Charter

PMO Charter
Goal To develop a Project Management Office (PMO) within OPP ITS, utilizing business and IT best practices with the intent to set the standard for IT PMOs across the University by implementing basic yet fundamentally sound standards for success. Objectives The PMO seeks to create a new dimension of Project Leadership in OPP ITS ensuring better collaboration and communication within the department as well as with external entities. It endeavors to increase visibility of the ITS Project Management Process, providing the business at large a more transparent view into ITS Projects. The PMO also seeks to provide Project Management guidance to all OPP entities by the inclusion of simple, practical tools and procedures coupled with retrospectives/lessons learned from previous Projects and/or iterations. o o o Simple Practical Applying Lessons Learned

Features and Benefits to the Business By establishing a PMO, the business benefits in many ways: The Project process will become more streamlined and standardized, providing greater consistency across departments in regard to ITS related Projects. Projects will receive more stringent management, enabling the business to prioritize ITS Projects which, in turn, will keep the business informed and Projects on schedule. The PMO will manage and maximize the resources put into Projects, providing the business with an improved output regarding ITS Projects.

Project Definition
A Project in OPP ITS resolves a need that: Is technical and/or Provides benefit to multiple persons/organizations and/or Has an estimated Start and End Date and/or Involves coordination with multiple entities and/or Has an initial investment greater than $100k and/or Has a level of technical effort beyond two weeks and/or Is Not Routine

Project Management Process

Project Management Process

1. Initiation (Initiation) Establishment (Ticket/AtTask) Pull the following Answers from New Project Ticket End result will help the business by: The primary users of the system are: A successful implementation will be when: Department/Area: Goal of the Project: Key Features/Objectives of the Project: Deadlines/milestones for this Project: Project Charter, see example below

2. Discovery (Planning) Further Investigation, use 5 Ws: What/Why - Goal (overarching concept i.e. what problem is solved?), Objectives and their subparts Who - Customer(s), Project Sponsor, Project Manager, Stakeholders, Project Team, Other Groups/Systems Affected When - Desired Completion Date Customer, Estimated Completion Date IT Project Team Where - Department(s), Location(s) Requirements Gathering Business Requirements Document (BRD), see example below

3. Planning (Planning) Organizational Change Management Plan, see example below Communications Management Plan, see example below Post enhancement/upgrade Establish Steering Committee, Core Team, User Groups Work Breakdown Structure, see example below Decision Log, Risk Log/Matrix, see example below

Project Management Process

Critical Path, see example below Task Management Tools - MS Project, AtTask Activity/Task List (see example below) including Red Amber Green (RAG) (see example below) Updates Gantt Charts (milestones, Projected starts/ends and ACTUALS) Reports Functional Specifications Document (FSD), see example below Meeting Notes/Minutes

4. Execution (Execution/Monitoring-Controlling) Development Software Design Diagram (SDD), see example below Environments SANDBOX, DEV, TEST, TRAIN, PROD Cross Functional Flow, e.g. Customers, Development, Approvers SANDBOX and TRAIN are optional Configuration Management Plan, see example below Change Management/Control Plan, see example below Testing, see explanation below Technical Testing Unit, Performance, Systems Integration Testing (SIT) Business Testing Test Cases/Use Cases/Scenarios (Provided by the Business) User Acceptance Testing (UAT) - Test Scripts Issues/Defects Log Training Pre Deployment Hands on/Instructor Led, Manuals, One Pagers/Cheat Sheets, Recordings Go Live/Deployment

Project Management Process

5. Post Deployment(Monitoring-Controlling/Close Out) Steering Committee, Core Team, User Groups Steering Committee makes executive level decisions Core Team could also be called Implementation Team, makes day to day decisions and provides communication. User Group is a larger group, including Core Team, SMEs and primary stakeholders Meetings Discuss general news regarding the application/project Discuss/Approve enhancements (Change Management/Control, see example) Discuss successes/completed items Discuss issues Change Control Board Training Post Deployment New Functionality Training, Refreshers, Onboarding/New Employee Training

6. Lessons Learned (Close Out) Document Lessons Learned during (Agile - Retrospective) and after the Project completion, see explanation below Celebrate and document Projects successes Mandatory read for future Projects Documentation available to PMO (e.g. Box) Five Whys (Explore root cause of Project issues/failure) Something goes wrong on a Project, pick an instance and ask why it occurred Then ask why this occurred (again) Repeat the cycle 5 times and you have arrived at the root cause

Project Checklist

Project Checklist
The intent of this list is to provide a quick reference of the elements which should be considered for the success of a Project. The Responsible Party column can have 3 options: B for business, T for Tech and Both. This is to show which area is responsible for each line item. Status has four options: C for Complete, I for In Progress, N for Not Started, N/A for Not Applicable If a point or step is not applicable or is not completed during the course of the PROJECT, explain why in the provided space. Expected Completion Date Actual Completion Date

Responsible Party

Status

Items

Explanation for not completing

Initiation Idea is vetted ITSG/ESG Approval Discovery Sponsor, PM and Team Identified/Assigned 5 W's Project Charter Business Requirements Document (BRD) & Approvals Planning Organizational Change Management Communications Management Plan Work Breakdown Structure & Critical Path Activity/Task List including Red, Amber, Green (RAG) Rating Decision Log, Risk Log/Matrix Functional Specifications Document (FSD) & Approvals Change Control Process Execution Development Software Design Diagram (SDD) Environments needed DEV, TEST, PROD Diagrams - e.g. Cross Functional Flow Configuration Management Testing Technical Testing - Unit, Performance, SIT Business Testing - UAT, Use Cases Issues/Defects Log Pre Deployment Training (Classroom, Video) Go Live Post Deployment Post Enhancements/Upgrades Post Deployment Training (Refresher, New Hire) Steering Group/Core Team/User Groups User Group Meetings -Scheduled Lessons Learned Retrospectives (Agile) Published to Box

Project Checklist

Project Components
P ROJECT C HARTER The Project Charter is created to establish clear goals, precise objectives, and responsibilities from the initiation of the Project. Upon the charters creation, the Projects Sponsor, Key Stakeholders, and Core Team must be identified. Also, start and end dates must be determined to provide a time estimate for those involved in the Project. Finally, justification for the Project must also be included in the charter. Justification concepts may include: a return on investment, total cost of ownership, and cost benefit analysis. These are posted to the OPP Intranet, under the ITS Projects folder. When building a Project Charter, there are a few pieces of information which must be considered and included. Initiatives Initiatives are made up of many projects, grouped together based on their stakeholder group, goal, or systems they affect. Project Lead The Project Lead is the technical expert who will guide and manage the projects functional progress. The Lead is well versed in the Projects technical requirements and oversees implementation or development required for the Projects success. Requesting Department The Requesting Department is the department that originally submitted the request for the project. Often times, the Key Stakeholders can be found in this department. Project Sponsor The Project Sponsor is the Manager or Director who is funding the project. Key Stakeholders The Key Stakeholders are a group of customers or users whom this project will most heavily affect. B USINESS R EQUIREMENTS D OCUMENT (BRD) The Business Requirements Document is a collaborative effort between the PMO and the Business. The result will be a document that the business agrees defines the way in which the modifications will be applied to the business process/application. The document is created using Business jargon that the Development Team will use to create the FSD. D ECISION L OG The Decision Log is a document which details the decisions made throughout the Projects lifecycle. It is used as a record and is extremely helpful for accuracy and accountability. This document should explain what the decision was, who decided it, why it was decided, and the date it was made.

An example of a Decision Log

Project Checklist

R ISK L OG & M ATRIX The Risk Log is a detailed list which categorizes risks and identifies their probability, impact and other important information. For each risk identified, this log should include a mitigation plan, contingency plan, action by, action when, and a risk score determined by probability and impact. The Risk Matrix illustrates the data from the Risk Log in a graphical format. Risks that fall into the red-shaded cells of the matrix are the highest priority, and should receive the majority of risk management resources during response planning and risk monitoring/control. Risks that fall into the orange-shaded cells of the matrix are the next highest priority, followed by risks that fall into the yellow-shaded cells.

An example of a Risk Log

An example of a Risk Matrix

W ORK B REAKDOWN S TRUCTURE The Work Breakdown Structure (WBS) is a product or deliverable that is a decomposition/breakout of a project into smaller components. WBS is a hierarchical and incremental distribution of the project into phases, deliverables and work packages. This WBS will allow the project leader and members of the team to best organize thoughts and effort for the project.

An example of a Work Breakdown Structure (WBS)

C RITICAL P ATH The Critical Path method is a project modeling technique that provides insight into the duration of the project from several perspectives. From a list of all the activities to complete the project they are laid out in sequence, showing dependencies, applying duration of each task, and including milestones and deliverables. This process allows the project team to determine the longest path (time) it will take to complete the project and best understand project task dependencies. It also helps to identify slack time, if any, between activities. Ergo, this longest time is translated into being the shortest time in which the project can be completed.

Project Checklist

An example of a Critical Path

A CTIVITY /T ASK L IST An Activity/Task List includes a series of goals to be completed by members of a Project team. The completion of these tasks is necessary for successful project implementation. These tasks will be detailed and low level/very specific in nature. They can be broken down into subtasks as needed. The list should include descriptions, planned and actual completion dates, predecessors, roles and responsibilities on each task. By using an Activity/Task list, it is easier to keep a Project on schedule and communicate both in the Project team and out to the business. AtTask will be used by the Project Lead as the authoritative source for managing the projects task list.

R ED , A MBER , G REEN (RAG) R ATING The RAG (Red, Amber, Green) rating can be used as an indication of the level of confidence that an action plan will meet its objectives. The colors are often used as a simple system to categorize and highlight issues (based on clear criteria).

Project Checklist RED AMBER Urgent Action required to get the PROJECT back on track; viability of the PROJECT may need to be reassessed Significant issues and risks exist which requires management mitigation these appear resolvable, and if addressed at this stage, should not threaten delivery GREEN PROJECT delivering on time cost & quality, with no major outstanding issues or risks (i.e. no financial/ reputation problems for the Council) RAG Rating explanation

10

S OFTWARE D ESIGN D IAGRAM (SDD) The Software Design Diagram is created by the technical team to capture the technical system modifications for the Project. A Cross Functional Flow Diagram will be used to create this document. This document will be delivered in a diagrammatic fashion. It will provide insight into how technical processes/systems will be updated in regard to the modifications for the Project. F UNCTIONAL S PECIFICATIONS D OCUMENT (FSD) The Functional Specifications Document is created by the Development Team and is used to define the systematic modifications per the business requirements. This document details the exact functionality of system as is expected by the business at Project completion. This document is a direct response to the Business Requirements Document (BRD). The functional specifications will describe what is needed by the system user for the modifications requested, as well as requested inputs, outputs and their properties. C ONFIGURATION M ANAGEMENT P LAN The Configuration Management Plan examines the configuration of the systems used in the lifecycle of the Project. These systems include servers, databases, applications and the requisite details for each (e.g. server specifications). The plan should also consider areas such as types of configuration data, environment controls, user data management, and system data management. A component of the plan will include a configuration matrix/log which will list/identify the current specifications of the aforementioned systems as well as the prior specifications of the system and the dates and times changes occurred. C HANGE M ANAGEMENT /C ONTROL P LAN The Change Management/Control Plan can be used throughout the lifecycle of a Project, if absolutely necessary, there is a capability within AtTask to introduce new concepts/aspects into the Project. These need to be properly identified, vetted and approved through the change management/control process. Items which come into the Project throughout its lifecycle must be vetted by the Core Team, which consists of the Project sponsor, IT Project lead or Project manager, key stakeholders, subject matter experts and other important stakeholders. If a change in the Project is warranted and affects other Projects, the proposal may need to go to ESG to assist in prioritization of other Projects. O RGANIZATIONAL C HANGE M ANAGEMENT (OCM) P LAN The Organizational Change Management Plan must be fully embraced by the business for the Project to succeed. It needs the full support of the executive team or sponsor. This involves managing and planning the people that touch the Projects output. OCM doesnt necessarily pertain to every Project, but is vital to Projects where multiple business entities are involved. An effective communication plan is intrinsic to the success of organizational change management. Active listening, effective disagreement management and situational leadership should all be encouraged in the communication process. Incumbent upon the processes in OCM is the concept that the customers need to understand why they are being asked to do something new/different

Project Checklist

11

in their daily routine. Training, including early stage demonstrations, UAT, and classroom level training, is also an important piece of OCM. C OMMUNICATIONS M ANAGEMENT P LAN The Communications Management Plan is created at the start of the Project to define the communication requirements and how information will be distributed throughout the Projects lifecycle. It focuses on how the intent, execution, and completion of the Project will be accomplished. The Communications Management Plan defines the following: how frequently information will be communicated, who is responsible for distributing this information, what resources are allocated for communication, and any internal or external constraints on project communication. It may also address any standard templates or documents which must be used, an escalation process for resolving communication-based conflicts and how changes in communication or the communication process are managed. TESTING The intent behind testing, regardless of type is that the expected functionality is present both from a technical as well as from a business perspective. A myriad of testing types exist, some executed solely by the technical team, some solely by the business and a few completed by both entities. This document mentions the specific types needed for successful Project completion. An example Testing Template is used to document test cases for the following test types: System Integration Testing, User Acceptance Testing, and Regression Testing. Unit Testing (Technical Team) - Refers to tests that verify the functionality of a specific section of code. Systems Integration Testing (SIT) (Technical Team) Refers to tests that validate the business requirements have been achieved. This testing is geared toward technologys perspective of/for the system changes User Acceptance Testing (UAT) (Business Team) Refers to tests that validate the business requirements have been achieved. This testing is geared toward the business perspective of/for the system changes. Regression Testing (Technical and Business Teams) Refers to tests that ensure that the existing functionality of a system remains intact and is not adversely impacted by the Projects change(s). Accessibility Testing (Technical and Business Teams) - Refers to tests that assure the compliance with accessibility standards. LESSONS LEARNED Lessons Learned are the items gained from the process of performing the Project. Formally conducted lessons learned sessions are traditionally held during Project close-out, near the completion of the Project. However, lessons learned may be identified and documented at any point during the Projects life cycle. The purpose of documenting lessons learned is for all stakeholders to share and use knowledge derived from experience to promote the recurrence of desirable outcomes and preclude the recurrence of undesirable outcomes. This process is intrinsic to both the success of the current as well as future Projects. Lessons learned should also include successes and positives experienced during the Projects.