0% found this document useful (0 votes)
24 views

2015-04-16 PMO Operations Guide

This document provides an operations guide for a university's Project Management Office (PMO). It outlines the PMO's mission to lead and manage the portfolio of key IT projects through applying project management best practices. The guide describes the project lifecycle used, including initiation, planning, execution, monitoring, and closeout. It also defines project classifications, types, and tiers of complexity. Sections cover topics like the software development lifecycle, quality management, risk management, roles and responsibilities, checklists, communications plans, change management, reporting, and the portfolio management tool used.

Uploaded by

Hammad Masood
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views

2015-04-16 PMO Operations Guide

This document provides an operations guide for a university's Project Management Office (PMO). It outlines the PMO's mission to lead and manage the portfolio of key IT projects through applying project management best practices. The guide describes the project lifecycle used, including initiation, planning, execution, monitoring, and closeout. It also defines project classifications, types, and tiers of complexity. Sections cover topics like the software development lifecycle, quality management, risk management, roles and responsibilities, checklists, communications plans, change management, reporting, and the portfolio management tool used.

Uploaded by

Hammad Masood
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

Information Technology Services

Project Management Office


Operations Guide

Revised 3/31/2015
Table of Contents

ABOUT US........................................................................................................................................................... 4
WORKFLOW ....................................................................................................................................................... 5
PROJECT LIFECYCLE ............................................................................................................................................ 6
PROJECT INITIATION....................................................................................................................................... 6
PROJECT PLANNING ....................................................................................................................................... 7
PROJECT EXECUTION, MONITORING AND CONTROLLING ............................................................................. 8
PROJECT CLOSEOUT ....................................................................................................................................... 9
PROJECT SCORING MODEL............................................................................................................................... 10
SCORECARD CRITERIA – WHY ARE WE DOING THIS AND HOW WILL IT BE COMPLETED? ..................................................... 10
GOALS ................................................................................................................................................................ 13
RISKS .................................................................................................................................................................. 13
SDLC – SOFTWARE DEVELOPMENT LIFE CYCLE ................................................................................................ 14
WATERFALL MODEL ..................................................................................................................................... 14
REQUIREMENTS ....................................................................................................................................... 15
DESIGN ..................................................................................................................................................... 15
IMPLEMENTATION ................................................................................................................................... 15
VERIFICATION ........................................................................................................................................... 16
MAINTENANCE ......................................................................................................................................... 16
DEFINITION OF PROJECT CLASSIFICATIONS ..................................................................................................... 17
ACADEMIC TECHNOLOGIES ...................................................................................................................... 17
ADMINISTRATIVE SYSTEM IMPROVEMENTS............................................................................................ 17
INFRASTRUCTURE IMPROVEMENTS ........................................................................................................ 17
IT GOVERNANCE & STRATEGIC PLANNING .............................................................................................. 17
IT SECURITY .............................................................................................................................................. 17
IT SERVICE IMPROVEMENTS & OUTREACH .............................................................................................. 17
RESEARCH TECHNOLOGY SERVICES ......................................................................................................... 17
STUDENT EXPERIENCE .............................................................................................................................. 17
DEFINITION OF PROJECT TYPES........................................................................................................................ 18
APPLICATION DEVELOPMENT / BANNER ................................................................................................. 18

Page | 2
BUSINESS INTELLIGENCE .......................................................................................................................... 18
CONSTRUCTION ....................................................................................................................................... 18
PACE WEB SITE ......................................................................................................................................... 18
SYSTEMS & INFRASTRUCTURE ADMINISTRATION ................................................................................... 18
TRAINING / PROGRAM MANAGEMENT ................................................................................................... 18
DEFINITION OF TIERS ....................................................................................................................................... 19
TIER 1 – Minimal Complexity ....................................................................................................................... 19
TIER 2 – Moderate Complexity..................................................................................................................... 19
TIER 3 – Highly Complex ............................................................................................................................... 19
QUALITY MANAGEMENT POLICY ..................................................................................................................... 20
LEVEL 1 ......................................................................................................................................................... 20
LEVEL 2 ......................................................................................................................................................... 20
RISK MANAGEMENT......................................................................................................................................... 21
ROLES AND RESPONSIBILITIES.......................................................................................................................... 22
REQUESTOR .................................................................................................................................................. 22
PROJECT SPONSOR ....................................................................................................................................... 22
PROJECT MANAGER ..................................................................................................................................... 22
FUNCTIONAL LEAD ....................................................................................................................................... 22
STAKEHOLDER .............................................................................................................................................. 22
CHECKLISTS....................................................................................................................................................... 23
PROJECT INITIATION CHECKLIST .................................................................................................................. 23
PRODUCTION READY CHECKLIST.................................................................................................................. 24
COMMUNICATIONS PLAN ................................................................................................................................ 25
CHANGE MANAGEMENT .................................................................................................................................. 26
REPORTING....................................................................................................................................................... 27
PORTFOLIO MANAGEMENT TOOL ................................................................................................................... 27
Team Dynamix.............................................................................................................................................. 27

Page | 3
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 Strategic and Tactical Plan reports. Our department
homepage resides within Information Technology Services org site at –> PMO homepage

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, Key Stakeholders, Technical and Business leads

ORGANIZATION

Each section of this document is organized as follows:

 PROCESS OVERVIEW

 GUIDELINES

Page | 4
WORKFLOW
The PMO receives and processes projects as follows:

Request Initiated via ITS Internal


IT Project Request Form Work

Project is reviewed by PMO for approval

NO
Re-evaluation needed to
Meets Criteria
for Project ?
ensure alignment with
University goals and/or
priority justification
YES
R
Evaluator (PMO) Scores project
after consultation with client
and assigns Functional Manager

Application NO
Development ?

YES

Document Scope of Work


Determine Timeline
Obtain approvals

Follow Project Management Process


D
outlined in PMO Operations Guide

Page | 5
PROJECT LIFECYCLE

PROJECT INITIATION

PROCESS OVERVIEW
The Project Management Office is currently engaged in a variety of projects and initiatives and assists with
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
 It is considered “temporary” in that is has a definitive beginning and end time
 Has a defined scope and resources
 In alignment with the University’s Strategic Goals
 Not associated with daily business operations
 The effort requires at least 40 business hours of an individual staff member’s time

GUIDELINES
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 during project lifecycle.

The scope of work should be reviewed by all invested parties so that everyone involved can understand and
agree on the proposed specs. The document includes:

1. Project Proposal
2. Benefits that can be expected
3. Technical approach (IT solution)
4. 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 -> Sample SOW

Page | 6
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 1 is used as a guideline.

GUIDELINES
The PMO’s planning process includes the following steps:

1. Estimating the size of the project

2. Estimate the technical scope of the project

3. Estimate the resources required to complete the project

4. Produce a schedule

5. Develop a Communications Plan2

6. Identify and assess risks

7. Negotiate commitments

The PMO will assess whether or not the project requires a formal project plan or if a high-level list of
milestones is more appropriate. Several iterations of the planning process are performed before a formal
plan is actually completed.

1
See CHECKLISTS section of the document

2
See COMMUNICATIONS section

Page | 7
An appropriate Tier level will be decided upon after initial assessment. For more details on Tier levels,
please see Definition of Tiers section3

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.

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:

1. Regular review of project progress and creation of status reports


2. Schedule checkpoint meetings to update status
3. Control and track tasks in project plan (deliverables on track)
4. Adhere to Quality Management and Risk Management Policies4
5. Update project plan (completion dates, new tasks, milestones)
6. Communicate risks and concerns to client and team
7. Change management5
8. Obtaining appropriate sign offs for user acceptance testing and deliverables

Periodic status reports are essential to communicate 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 scheduled basis.
Checkpoint Team meetings are held with stake-holders as appropriate.

3
See DEFINITION OF TIERS section of the document

4
See QUALITY MANAGEMENT and RISK MANAGEMENT sections

5
See CHANGE MANAGEMENT section

Page | 8
PROJECT CLOSEOUT

PROCESS OVERVIEW
The final phase of the project’s lifecycle 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 6 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:

1. Verification of formal acceptance by stakeholders

2. Work with Management for the release or redistribution of resources

3. Contract closure

4. Identify and document “lessons learned”

5. Celebrate project success (recognize team members)

6. Archiving Project records

7. Distribution of client satisfaction surveys upon project closure

6
See CHECKLISTS section of this document

Page | 9
PROJECT SCORING MODEL

Our project ranking model is based on weighted responses to project initiation checklist questions which
are typical for IT projects. This model is currently implemented in TeamDynamix which will aid the PMO
and Project Review Board in assessing priority.

In order to rank incoming projects, we evaluate its importance by assessing the value it will bring as well as
ensuring it is aligned with the University’s strategic goals. We also take into account the risk, urgency, and
target audience.

The Scorecard criteria questions along with Goals and Risk are calculated to create a composite score
percentage. A summary report of scored projects is reviewed by the governance committee in order to
determine priorities.

SCORECARD CRITERIA – WHY ARE WE DOING THIS AND HOW WILL IT BE COMPLETED?

1. Value Add / Impact: Projects that have a positive impact on the largest customer base are ranked
highest on this criterion. Projected business benefits can include financial, organizational, student
enrollment or retention.

Strategy Weight Criteria Value

No Impact .0

Single Administrative Division / College .33

Value Add 20% Multiple Administrative Divisions / Colleges .66

Significant Return on Investment 1

University-wide 1

Page | 10
2. Urgency: In an effort to make sure the project benefits the university as a whole or a specific
component of the institution, this criteria ranks both the urgency and the group(s) who will benefit
from it.

Strategy Weight Criteria Value

Not Urgent or important .0

Urgent 20% Important to 1 or more departments .25

Urgent – time sensitive 1

3. Required: Measure the extent to which the project is required for compliance (minimizing any risk to
the University) or cost reduction. A patch or upgrade to major university systems based on federal
regulations is associated with remaining in compliance (highest value).

Strategy Weight Criteria Value

Not Required .0

Required? 20% Associated with planned initiatives .33

Required to sustain operations .66

Required to remain in compliance 1

4. Mission Supported: Identify how this project supports our organization’s mission.

Strategy Weight Criteria Value

Administration 0

Mission 10% Academic 1


Supported
Research 1

Page | 11
Student Experience 1

5. Increase Effectiveness: The project will contribute to ongoing efforts that drive continuous process
improvement. Does this improve an existing process or enhance user experience? For example, does
this project produce a new service that will reduce administrative cost and create an easy-to-use
interface for the student or user?

Strategy Weight Criteria Value

No Impact on Efficiency .0

Increase 10% Improved User Experience .5


Effectiveness
Increased Administrative Efficiency .5

Increased User Experience & Admin Efficiency 1

6. Funding: Costs include both human resource and physical (hardware/licensing) costs. If funding is
available and allocated to support the project life-cycle, the score is higher. If funds are not available,
we cannot proceed with taking on this project.

Strategy Weight Criteria Value

Funds are not available .0

Funds 10% Funds are available .5


Allocated
Funds are available and allocated 1

7. Goals clearly articulated: A complete set of requirements are required to develop a scope document. A
scope document includes description of solution, deliverables, exclusions, constraints and assumptions.
Stakeholders and IT must agree to scope before committing to execution.

Strategy Weight Criteria Value

Solution is unclear; problems expected .0

Goals clearly 10% Solution is known: some problems expected .33


articulated
More than 1 approach is available .66

Solution is well defined: no problems expected 1

Page | 12
GOALS
Note: the List of Goals will be updated to reflect 2016-2020 University Strategic Plan as soon as they are
released.

I - Advance Pace's Academic Programs

II - Build a Culture of Community

III - Create Vibrant and Distinct Campus Identities

IV - Build a Strong Financial Foundation and Efficient Infrastructure

V - Enhance Pace's Visibility

RISKS
• Not Applicable = 1
• Low = 0.67
• Medium = 0.33
• High = 0

Risk Score = (Sum of all risk scores) / (Total number of risks). A lower risk score means the project is more
risky. Risk scores will fall between 0 and 1.

1. Campus Risk non-compliance Would the university potentially be at risk if this project was not
completed (regulatory or security related)

2. Risk mitigation Risk mitigation involves development of mitigation plans designed to manage,
eliminate, or reduce risk to an acceptable level. Once a plan is implemented, it is continually
monitored to assess its efficacy with the intent of revising the course-of-action if needed.

Page | 13
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.

Page | 14
SDLC Description of Phases

REQUIREMENTS
 Recognition of need
o Can be environmentally or organizationally based.
o Ideas are generated to advance technology
o User-originated ideas prompt initial investigation

 Feasibility Study
o Economic: Cost benefit analysis
o Technical: Determine whether existing systems can support what is requested.
o Behavioral: An estimate is made of how strong a reaction the user staff is likely to have
toward the development of a new system.
o Steps:
 Form a project team and appoint a leader.
 Prepare system flowcharts.
 Enumerate potential systems.
 Describe and identify characteristics of candidate system.
 Evaluate performance.
 Select best candidate system.

 Analysis
o In-depth analysis is performed to obtain a detailed understanding of the business needs.
o Tools used: interviews, on-site observation, etc.
o Training, experience, and common sense are required for collecting information to do
analysis.

DESIGN
 Defines the final system and refers to technical specifications.
 Logical Design: Specifies user needs.
 Physical Design: Tells ITS what the candidate system must do.

IMPLEMENTATION
 3 Types:
o Implementation of a computer system to replace manual system.
o Implementation of a new computer system to replace an existing one.
o Implementation of a modified application to replace existing one.

Page | 15
VERIFICATION
 Determine if system does what it was designed to do.
 Ensure it supports the user effectively, efficiently, and as required.
 Determine success in terms of functionality, performance, and cost versus benefits.

MAINTENANCE
 Ensure that needs continue to be met and system continues to perform according to specifications.
 Routine hardware and software maintenance and upgrades are performed to ensure effective
system operations.
 User training continues during this phase, as needed, to introduce new users to the system or to
introduce new features to current users.

Page | 16
DEFINITION OF PROJECT CLASSIFICATIONS
Project classifications are used to sort projects by type of service provided to help determine value added
by each project.

ACADEMIC TECHNOLOGIES
Projects related to academic technologies in classrooms, online, or related to faculty research.

ADMINISTRATIVE SYSTEM IMPROVEMENTS


Upgrades to departmental or division-wide workflows or systems.

INFRASTRUCTURE IMPROVEMENTS
Upgrades to networking, telecommunication, or server infrastructure that affects specific physical locations
or the entire University.

IT GOVERNANCE & STRATEGIC PLANNING


Projects to create a reinvigorated IT governance structure that promote transparency and include
representation from faculty and staff.

IT SECURITY
ITS security initiatives to reduce/mitigate risk, or maintain compliance with industry standards and best
practices.

IT SERVICE IMPROVEMENTS & OUTREACH


Projects to improve IT services to the University community as well as IT staff development.

RESEARCH TECHNOLOGY SERVICES


Projects related to faculty and/or student research.

STUDENT EXPERIENCE
Service improvements that directly affect student experience. This includes upgrades such as: digital
signage systems, improvement to computer classrooms and computer labs, academic support, and
retention initiatives.

Page | 17
DEFINITION OF PROJECT TYPES
The Project Type attribute allows the PMO to break down ITS projects by technology, e.g. measuring
percentages of development projects versus construction projects.

APPLICATION DEVELOPMENT / BANNER


Projects involve web applications developed for client departments, typically to streamline workflows
and/or eliminate paper forms. These projects can be submitted by a variety of University departments
including Human Resources and the Office of Student Assistance and typically require work from ITS’
Application Development Group or Administrative Programming Group.

BUSINESS INTELLIGENCE
Projects to develop dashboards, reports, analyses, and decision-support information prepared by
Enterprise Reporting, sometimes in collaboration with the Application Development Group or
Administrative Programming Group.

CONSTRUCTION
Typically affect one or more departments or entire campuses depending on project size. The PMO is
responsible for coordinating between construction managers and relevant ITS departments like
Networking, Telecommunications, and Educational Media to ensure adequate voice/data service in new or
renovated spaces and to provide academic technology in student-facing areas.

PACE WEB SITE


Involve updating the University-wide website as well as making changes to, or updating, departmental
websites for the various departments and colleges in the University and involve ITS’ Web Services
department.

SYSTEMS & INFRASTRUCTURE ADMINISTRATION


Projects that affect backend systems and infrastructure. These are typically initiated internally by ITS to
upgrade or maintain network or server infrastructure.

TRAINING / PROGRAM MANAGEMENT


Projects typically involve training faculty on new or updated academic technologies, developing a suite of IT
services to support faculty research, tracking progress on the yearly University PC Replacement program,
etc. These projects involve a variety of University departments and typically require input from ITS’
Academic Technology or User Services departments.

Page | 18
DEFINITION OF TIERS
Based on the project scorecard and criteria listed below, ITS projects are sorted into project tiers which
provide guidance related to variations in approval requirements, execution methods, and documentation
requirements.

TIER 1 – Minimal Complexity


 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
 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 followed7
 High level milestones/tasks identified

TIER 2 – Moderate Complexity


 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
 Technical Lead identified to ensure appropriate strategy
 User population greater than 20 and may have multiple university clients
 Bi-weekly status report issued by PMO to Business Sponsor and/or Key Stakeholders
 Project Management Lifecycle is followed
 Quality Management Policy Level 2 is followed
 Requires a high level Project Plan with milestones and dependencies

TIER 3 – Highly Complex


 Includes Banner integration or other data ETL
 Estimated work time greater than 12 months
 May include multiple ITS departments
 Technical Lead identified to ensure appropriate strategy
 User population is University wide
 Executive Business Sponsor identified (provide leadership support)
 Bi-weekly status report issued by PMO to Business Sponsor and/or Key Stakeholders
 Project Management Lifecycle is followed
 Quality Management Policy Level 2 is followed
 Requires detailed Project Plan with milestones and dependencies

7
See QUALITY MANAGEMENT POLICY section

Page | 19
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)

Page | 20
RISK MANAGEMENT

Low Risk Medium Risk High Risk

 Considered non-complex  Considered moderately  Considered highly complex


 Minimal impact to user complex  Project plan with
community  Test window required prior dependencies
 No dependencies to deployment  Weekend deployment
 Some dependencies possible
 No cost to client  May include vendor costs  May include vendor costs

 Does not store or transmit  May include one-way pull  Includes banner data
banner data of banner data export/import
 Non-sensitive data  May include confidential  May include confidential
data data
 existing technology,  May include technology  New development work on
standard procedures upgrade new infrastructure
 May require equipment
acquisition, setup
 Resource from single IT  Resource required from  Collaborative effort - ITS,
Dept multiple IT depts Cross functional teams,
 Internal to IT or single  multiple clients impacted University-wide impact.
department (client)
 Project works toward goals  Project in alignment with  Project in alignment with
and objectives of University strategic University strategic
department direction direction

Page | 21
ROLES AND RESPONSIBILITIES
Each project has a team of people who fill various roles that works together to ensure each project is a
success. Below are the typical roles individuals affiliated with ITS projects fulfil with an outline of their
responsibilities.

REQUESTOR
 Initiates the request for identified project.
 Generally, end-user of the product or service.

PROJECT SPONSOR
 AVP or higher with vested interest in successful outcome of the project.
 Champions the project at the executive level to secure buy-in.
 Authorizes and promotes the project’s business case.

PROJECT MANAGER
 Assigned by PMO.
 Responsible for managing and completing projects on behalf of requestor and/or sponsor.
 Coordinates communication across multiple functional departments.
 Reports on project status and progress.

FUNCTIONAL LEAD
 Provides and manages resources for project.
 Accurately and effectively represents the business needs of their department and the inter-
relationships between departments.
 Provides guidance and insight for the project’s roll-out within their areas of responsibility.
 Provides and shares feedback on deliverables.

STAKEHOLDER
 Has vested interest in the completion of the project and how the project will impact their specific
area.
 Provides information, as needed, to insure that the project stays on track and meets the intended
goals and deliverables.
 May be affected either positively or negatively by the project.
 Categorized as Responsible, Accountable, Consulted, or Informed.

Page | 22
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?
 Have commercially available products been evaluated?

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?

Page | 23
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?

Page | 24
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 lifecycle 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
1. Document any project specific procedures.

2. Describe how decisions are made (who will represent the departments) and how those
decisions are communicated to the team.

3. Document how project information (i.e. schedule, budget, risk, change) is communicated
with stakeholders, executives (reporting, email, or checkpoint meetings)

4. Determine frequency of updates.

5. Create and maintain user profiles in TeamDynamix

Page | 25
CHANGE MANAGEMENT

PROCESS OVERVIEW

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

• Receive and log change requests via a Project Change Request Form
• 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 and plans
• Communicate changes to the project team and others as the communication plan dictates

The change requestor, who is any key stakeholder, may submit projects changes through the change
request form. The project sponsors will evaluate and approve any change requests. 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 Project Change Request
Form and entered as an issue in our project portfolio management system along with supporting
documentation.

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 - If approved, the change will be incorporated into the original scope of work
document and project plan.

Page | 26
REPORTING

The PMO is responsible for creating and publishing monthly reports on the ITS website. Tactical and
Strategic Plan reports are published here -> Tactical and Strategic Plan Reports

The user must be within the Pace Network to view the PDFs.

PORTFOLIO MANAGEMENT TOOL


Team Dynamix

https://pace.teamdynamix.com

Page | 27

You might also like