Project Management Office Operations Guide

Printer-friendly version
Project Initiation SDLC Model Change Management
Project Planning Tier Definitions Project Initiation Checklist
Execute/Control Quality Management Production Readiness Checklist
Closeout Risk Management Communications Plan

View full PDF of the PMO Operations Guide

  PMO Project workflow



ABOUT US

MISSION STATEMENT

The Project Management Office (PMO) leads and manages the portfolio of key IT and business process improvement projects. The office is responsible for selecting, managing and optimizing the project resources and ensuring projects are aligned with the University’s mission and strategic goals.

PMO staff works in partnership with IT cross-functional departments to form cohesive teams to achieve project objectives.  PMO supports the successful management of IT projects through application of leading project management practices. We also recognize that all projects are different and may require an adaptable approach to meet the client’s needs.

The PMO is also responsible for monthly posting of the Tactical Plan as well as reporting monthly Key Performance Indicators. Our website address: http://www.pace.edu/information-technology-services/project-management-office

PURPOSE OF THIS DOCUMENT

This document describes in detail the process that the PMO intends to use during the initiating, planning, managing (controlling and executing), and closing stages of technology projects.

In defining this methodology, the PMO hopes to reach the following goals:

  • Provide a common point of reference and a common vocabulary for talking and writing about the practice of project management for technology projects with ITS
  • Provide guidelines as to what is a Project
  • Increase the awareness and professionalism of good Project Management Practice
  • Define the roles of the Project Manager,  Project Review Board, Key Stakeholders, Technical and Business leads

ORGANIZATION

Each section of this document is organized as follows:

  • PROCESS OVERVIEW
  • GUIDELINES

[Top]

PROJECT LIFECYCLE

PROJECT INITIATION

PROCESS OVERVIEW

The Project Management Office is currently engaged in a variety of projects and initiatives and is responsible for ITS resource planning.  The PMO critically analyzes all IT project requests and recommends prioritization to the Chief Information Officer. 

The PMO defines a project as follows:  

  • A group activity designed with a goal to produce a unique product, service or result
  • Considered "temporary" in that it has a definitive beginning and end time
  • Has a defined scope and resources
  • In alignment with University Strategic Goals
  • Not associated with daily business operations
  • Effort requires at least 40 business hours of an individual staff member's time

GUIDELINES

The project is defined, evaluated and approved to be incorporated into the current workload by the Project Review Board (PRB). The PRB is made up of ITS Department Managers and members of the PMO. Upon approval, project priority and complexity is determined.  A scope of work document is required which includes project definition, key stakeholders, justification, significant deliverables and a target timeline.

A scope of work document (aka Statement of Work / SOW) will promote an early collaboration between the client and the project team.  Establishing a good rapport with your sponsors will ensure a cooperative spirit later in the project.

The scope of work should be reviewed by all parties so that everyone involved can understand and come to agreement on exactly what is being proposed. The document will include:

  •   Project Proposal
  •   Benefits that can be expected
  •   Technical approach (IT solution)
  •   Approximate time table for delivery

Formal acceptance of statement of work by the client is critical and required. PMO will also ensure the project is in alignment with the University’s strategic goals.

Sample Statement of work template can be found on our website -> here 

[Top]

PROJECT PLANNING

PROCESS OVERVIEW

Project planning defines the project tasks and describes how the tasks will be accomplished.  The PMO will focus on more clearly defining the project scope and provide a framework for management review and control.

The PMO may schedule internal discussions with team leaders at this stage to gain an understanding of the effort involved and perform a preliminary sizing.  A Project Initiation checklist is used as a guideline.

GUIDELINES

The PMO’s planning process includes the following steps:

  •   Estimating the size of the project
  •   Estimate the technical scope of the project
  •   Estimate the resources required to complete the project
  •   Produce a schedule
  •   Develop a Communications Plan
  •   Identify risk and assess risks
  •   Negotiate commitments

The PMO will assess whether or not the project requires a formal project plan (if so, these steps will aid in developing a plan).  Several iterations of the planning process are performed before a formal plan is actually completed.

An appropriate Tier level will be decided upon after initial assessment; projects would fall into one of three tiers:

Tier #1 Small Projects – Within ITS or non-complex 

Tier #2 Medium Projects - Affect multiple departments or for a client (Pace clients outside of ITS)

Tier #3 Strategic Projects - Organization-wide projects with long term effects   (multi-year, university-wide)

For more details on Tier levels, please see Definition of Tiers section

If procurement is involved (i.e. purchase of equipment or vendor resource), a budget is established and a formal RFP (Request for Proposal) or Quote will be prepared at this time.

Management and finance approvals are required before ordering equipment or contracting vendor resources.

[Top]

PROJECT EXECUTION, MONITORING AND CONTROLLING

PROCESS OVERVIEW

Once a project moves to this phase, the project team is formed and the necessary resources are allocated  to perform project tasks outlined in the project plan.

The Project Plan execution, monitoring & controlling process ensures the planned project tasks are carried out in an effective and efficient way. The PMO is responsible for reporting project progress and keeping management informed of any issues that may arise.

Any updates or changes in project scope will be incorporated through a Change management process. Change in scope can impact resource allocation and/or delivery timeline.

GUIDELINES

The PMO will be responsible for the following:

  •  Regular review of project progress and create status reports
  •  Schedule  checkpoint meetings to update status
  •  Control and track tasks in project plan (deliverables on track)
  •  Adhere to Quality Management and Risk Management Policies
  •  Update project plan (completion dates, new tasks, milestones)
  •  Communicate risks and concerns to client and team
  •  Change management
  •  Obtaining appropriate sign offs for user acceptance testing and deliverables

Periodic status reports are essential to communicate to progress and team accomplishments. Status reports can also provide insight to next steps, as well as bring issues to the attention of the appropriate team for assessment. 

Clients are emailed a list of current ITS projects along with status on a bi-weekly basis.  Checkpoint Team meetings are held with stake-holders as appropriate.

[Top]

PROJECT CLOSEOUT

PROCESS OVERVIEW

The final phase of the project’s life cycle is project closeout. Project closeout is completed once all defined project tasks and milestones have been completed and the customer has accepted the deliverables.  

A Production ready checklist is referenced when a system is being prepared for deployment. Production applications will be maintained via steady-state support teams within ITS. 

GUIDELINES

The PMO will be responsible for the following:

  •   Verification of formal acceptance by stakeholders
  •   Work with Management for the release or redistribution of resources
  •   Contract closure
  •   Identify and document “lessons learned”
  •   Celebrate project success (recognize team members)
  •   Archiving Project records
  •   Send online client satisfaction survey and report results - Qualtrics sample survey can be accessed ->https://paceadmin.qualtrics.com//SE/?SID=SV_6ulbDYcvdlqNCcI


[Top]
 

SDLC - Software Development Life Cycle

Waterfall Model

The PMO works with the client and the Application Development Group using the waterfall model to develop new applications. This is model applies to the majority of our Tier 1 and 2 development projects. For more complex or high-risk projects, phases may overlap to accommodate change in scope and/or extensive testing.

  • Each phase produces deliverables required by the next phase in the life cycle.
  • Requirements are translated into design.
  • Code is produced during implementation that is driven by the design.
  • Testing verifies the deliverable of the implementation phase against requirements.
  • Each phase must be completed in its entirety before the next phase can begin.
  • At the end of each phase, a review takes place to determine if the project is on the right path.


 

[Top]

 

DEFINITION OF TIERS

Tier 1

  •      No Banner integration or other data ETL (Exchange Transfer Load)
  •      Estimated work time greater than 40 hours but less than 2 months
  •      User population less than 20
  •      Approval required by Project Review Board
  •      Project Review Board qualifies project as low complexity
  •      Only a single ITS department completing work
  •      Bi-weekly status report issued by PMO to Business Sponsor and/or Key Stakeholders
  •      Project Management Lifecycle is followed
  •      Quality Management Policy Level 1 is followed

Tier 2

  •      May include Banner integration or other data ETL
  •      Estimated work time greater than 2 months but less than 12 months
  •      May include multiple ITS departments
  •      User population greater than 20 and may have multiple university clients
  •      Approval required by Project Review Board
  •      Bi-weekly status report issued by PMO to Business Sponsor and/or Key Stakeholders
  •      Project Review Board specifies medium complexity
  •      Project Management Lifecycle is followed
  •      Quality Management Policy Level 2 is followed
  •      May require high level Microsoft Project Plan with milestones and dependencies

Tier 3

  •   Includes Banner integration or other data ETL
  •   Estimated work time greater than 12 months
  •   May include multiple ITS departments
  •   User population University wide
  •   High impact to University user community
  •   Approval required by Project Review Board
  •   Bi-weekly status report issued by PMO to Business Sponsor and/or Key Stakeholders
  •   Project Review Board specifies high complexity
  •   Project Management Lifecycle is followed
  •   Quality Management Policy Level 2 is followed
  •   May require detailed Microsoft Project Plan with milestones and dependencies

[Top]

 
QUALITY MANAGEMENT POLICY

The purpose for managing quality is to validate that the project deliverables are completed with an acceptable level of quality. Quality management assures the quality of the project deliverables and the quality of the processes used to manage and create the deliverables.

Level 1

  •  Key Project deliverables and processes are subject to quality review
  •  Completeness and Correctness of deliverables
  •  Ease of transition to support mode by new resource (from development to production)
  •  Business sponsor survey and review - Stakeholder project expectations are met

Level 2

  •   All of Level 1
  •   Complete Project Initiation Checklist Review
  •   Major Deliverables of the project will be tested for satisfactory quality level
  •   Include organizational standards that need to be followed when performing quality review
  •   Quality control activities will occur more frequently throughout the project life cycle
  •   Quality control activity log will be maintained
  •   Complete Production Ready Checklist Review
  •   Business sponsor survey and end user survey and review (ensure expectations are met by both stakeholders and user community)

[Top]

 
RISK MANAGEMENT

Low Risk

Medium Risk

High Risk

  •   Considered non-complex
  •   Minimal impact to user community
  •   No dependencies
  •   Considered moderately complex
  •   Test window required prior to deployment
  •   Some dependencies
  • Considered highly complex
  • Project plan with dependencies
  • Weekend deployment possible
  •  No cost to client
  •  May include vendor costs
  • May include vendor costs
  •   Does not store or transmit banner data
  •   Non-sensitive data
  •   May include one-way pull of banner data
  •   May include confidential data
  •   Includes banner data export/import
  •   May include confidential data
  •  existing technology, standard procedures
  •   May include technology upgrade
  •   New development work on new infrastructure
  •   May require equipment acquisition, setup
  •  Resource from single IT Dept
  •   Internal to IT or single department (client)
  •  Resource required from multiple IT depts
  •   multiple clients impacted
  •   Collaborative effort - ITS, Cross functional teams, University-wide impact.
  •  Project works toward goals and objectives of department
  •  Project in alignment with University strategic direction
  • Project in alignment with University strategic direction

[Top]

CHECKLISTS

Project Initiation Checklist

General Considerations
  • Who is the Project Sponsor(s)?
  • Who are the intended users (ex: students, faculty, and staff)?
  • How and where will the users access the system?
  • Are there specific security requirements / considerations (ex: limits on who should access the data, information that should only be accessed by a certain individual or group)?
  • Are there special usability considerations?
  • Are there specific reporting requirements / considerations?
  • Are there specific performance requirements / considerations (ex: peak processing cycles)?
  • Is a disaster recovery plan required or does one already exist?
Feasibility
  • Is there a life expectancy of the product or service?
  • Which technology is being considered and why?
  • Is technology the best / appropriate solution or would business process reengineering be more appropriate?
Dependencies
  • Do other initiatives need to be completed before this effort can provide value?
  • Is this effort predicated on a yet to be determined product or service offering that may not materialize?
  • Is this a long term or short-term solution?
  • Will data sources be under development?
Constraints
  • Will this effort need additional funding beyond what is available at this time?
  • Will this effort require expertise or knowledge not readily available at the University?
  • Does the proposed solution integrate with the University’s platforms of choice?
  • Will this solution fit into our existing infrastructure?
  • Are there entities within the University that do not support this initiative?
Risks
What are the potential risks of moving forward with this effort?
What are the risks of not moving forward with this effort?
Are there contractual agreements that must be considered with this solution?
Are there methods available to mitigate any identified risks?

[Top]

 

Production Ready Checklist

General Considerations
  • Have we completed the development system testing process?
  • Is the production hardware setup and ready for use?
  • Has the base production software been installed and configured for use?
  • Weekend window needed? (low traffic)
  • Is there a process in place for data or content migration (if applicable)?
  • Process in place to verify the production system?
  • Are user accounts ready?
  • Will users need to be on standby for testing during deploy window?
  • Is there a back-out plan in place?
Dependencies
  • Are there other applications running on the shared server that could be impacted?
  • Does the server require a reboot post-deploy?
  • Does the application or server require any special monitoring post-deploy?
Assumptions
  • Will the application easily transition to steady-state support via the HelpDesk?
  • Incremental upgrades to be handled as separate projects?
  • Does the system require a support team specialist?
Risks
  • Could the system running in production impact server performance?
  • Are there methods available to mitigate any identified risks?

[Top]

 

COMMUNICATIONS PLAN

PROCESS OVERVIEW

A communications plan identifies who needs what information, when they need it and how that information is provided. In developing a communications plan we consider how to report the project status throughout the project life cycle including project health, accomplishments, upcoming challenges, significant changes, budget and schedule.

Establishing a communications plan will ensure interested parties are informed of the project status on a regular basis. During the planning phase we consult with the client and project team to determine a preferred method of communication that works for everyone.

GUIDELINES

  •  Document any project specific procedures.
  •  Describe how decisions are made (who will represent the departments) and how those decisions are communicated to the team.
  •  Document how project information (i.e. schedule, budget, risk, change) is communicated with stakeholders, executives (reporting, email,or checkpoint meetings)
  •  Determine frequency of updates.
  •  Have an internal/external contact list (database or spreadsheet) including roles/responsibilities

[Top]

 

CHANGE MANAGEMENT

PROCESS OVERVIEW

 The project manager will serve as change manager and lead change evaluator.  Responsibilities include:

  •     receive and log change requests
  •     perform the timely and adequate evaluation of changes in terms of their impacts on project deliverables and constraints
  •     outline options and recommend courses of action and priorities for changes
  •     track and facilitate timely decisions on changes
  •     incorporate changes into the appropriate project documents
  •     communicate changes to the project team and others as the communication plan below dictates

The change requestor, who is any key stakeholder, may submit project change requests. The project sponsors will serve as change evaluators and change decision makers.  Responsibilities include:

  •     evaluate options and recommended courses of action for these changes
  •     approve or reject changes

GUIDELINES

  1. Submission and Logging -  Change requests will be submitted formally via written request (email).  A change resulting from a realized risk or issue will be documented and stored in the project record (Briefcase).
  2. Evaluation -   Changes will be evaluated to determine impact to project schedule by project team.
  3. Decision - Approved changes along with impact to schedule, cost, will be communicated to project team by the PMO
  4. Integration -  The change will be incorporated into the original scope of work document and project plan (noted within a change log)

[Top]

Portfolio Management Tool

Team Dynamix

https://pace.teamdynamix.com

[Top]