NextGen Michigan Project Management Guidebook

University of Michigan
NextGen Michigan Program

Project Management Guidebook
Confidential and Preliminary. For use within University of Michigan only.
Table of Contents
Introduction ................................................................................................................................................ 2
Program and Project Governance ............................................................................................................ 4
Summary of Phase Gates .......................................................................................................................... 5
Program Office Phase Gate Review Process ................................................................................... 5
Project Management Capabilities ............................................................................................................ 7
Work Planning ........................................................................................................................................ 7
The Project Work Plan........................................................................................................................ 7
Standards in project plan ................................................................................................................... 8
Example of a Project Plan Hierarchy ............................................................................................... 8
Definitions............................................................................................................................................ 8
Multi-Workstream Projects ............................................................................................................... 9
Time Tracking Management ................................................................................................................. 9
Program Deliverable Management .................................................................................................... 11
Performance and Status Reporting .................................................................................................... 14
Issue Management................................................................................................................................ 17
Risk Management ................................................................................................................................. 22
Scope Change Control Management ................................................................................................. 28
Project Resource Requests ................................................................................................................... 32
Planning Phase ......................................................................................................................................... 33
Planning Deliverables .......................................................................................................................... 33
Analyze/Design ....................................................................................................................................... 35
Analyze/Design Deliverables ............................................................................................................ 35
Build/Test ................................................................................................................................................. 37
Build Deliverables ................................................................................................................................ 37
Test Deliverables .................................................................................................................................. 38
Service Pilot............................................................................................................................................... 40
Service Pilot Deliverables .................................................................................................................... 40
Deploy/Run .............................................................................................................................................. 42
Deploy/Run Deliverables ................................................................................................................... 42
Introduction
The purpose of Project Management is to drive a project to a successful completion by planning,

coordinating, and monitoring day-to-day operational and tactical activities. The purpose of the
Project Management Guidebook is to provide Project Managers with guidance and expectations
to mobilize a project as well as execute it to completion; more specifically, the guidebook walks
project managers through the phase-gating process. The deliverables listed serve as a guide to
successfully executing a project; projects may need to work on additional deliverables
depending on scope.
This guidebook is a living document that should be continually edited and updated by the
NextGen Michigan Program Management Operations (PMO) Office.
All NextGen Michigan projects will be managed under the PMO office. The PMO office is
responsible for establishing the management processes for all projects within the NextGen
Michigan program. For more information, refer to the Program Management Operations
Guidebook. It is expected that all NextGen Michigan projects will incorporate program policies,
procedures (as well as management processes), tools, and services defined by the PMO office in
the PMO Guidebook.
About the Project Management Guidebook
The Project Management Guidebook seeks to answer the following key questions:
How to get a project started?
How to obtain Sponsor sign-off?
How to identify and resolve risks and issues, as well as how to escalate to the program
as necessary?
How to manage and control project scope?
What is the interplay between project-level and program-level processes?
The Project Management Guidebook is divided into the following sections:
Program and Project Governance
Summary of Phase Gates
The Planning Phase
The Analyze/Design Phase
The Build/Test Phase
The Service Pilot Phase
The Deploy/Run Phase
Project Management Capabilities
Program and Project Governance

The NextGen Michigan PMO office has established Program Governance that includes
stakeholder groups, governance organization, escalation process, as well as management
processes (i.e. risk and issue management, etc). Projects managed under the PMO office will
follow the Programs Governance unless otherwise stipulated in the Project Charter 1. NextGen
Michigan projects should refer to the PMO Guidebook for more information on management
processes.
The PMO Guidebook has developed capabilities that:
Identify the stakeholder groups to represent in the governance organization.
Define program structure and roles.
Define the relationship between stakeholders and program/projects.
Define decision making authority, and determine who makes what decisions.
Define the process for making these decisions.
Defines deliverables to be used by the Program Governance to manage the strategic

direction.
Project Governance is a hierarchical breakdown of a project team, showing primary reporting

responsibilities and lines of authority. It should also include the individuals and groups with
whom the project team will regularly interface, including program management, sponsors, and
stakeholders. It is developed and updated for changes in connection with organizing the project
resources.
The team organization must reflect the proper consideration and balancing of the following
factors:
Type of Work Aggregate tasks with similar skill requirements.

Team Size Aggregate closely related work within teams and recognize the span of
control limits. Consider using work cells to reduce the number of deliverable hand-offs
and to provide clear ownership of the deliverables created.
Person/Job Match Match capabilities with requirements.
Risks Assign the best resources to high-risk areas.
Experience Mix experienced and inexperienced persons to facilitate mentoring.
Team Leaders Select them primarily based on competence and experience.
This deliverable is developed as part of Organize Project Resources and updated as needed.
A project may have unique governance requirements, which will need to be captured in the Project
Definition document during project chartering.
Summary of Phase Gates

Phase-Gates are reflection points in the projects lifecycle where program management and/or
project sponsors will ask questions to help ensure that sufficient value will be delivered within
a reasonable timeframe at a reasonable cost. The phase-gates also align to the incremental
investment approach of the program. Upon approval of a project, the program leadership will
also approve incremental funding required to get to the next phase-gate.
The following figure illustrates the standard phases of a NextGen Michigan project and the
types of questions that program and project leadership will address as a project moves through
its lifecycle.
Figure 1: Questions answered at each Gate.

The Phase-Gate reviews help determine whether the project has achieved the exit criteria. Exit
criteria provide control of the project milestone completion. Exit criteria are statements to
confirm if the required tasks and steps were satisfactorily completed; the required deliverables
completed, reviewed, and received sign-off before the stage is considered complete; and are
ready for transition to the next phase.
Program Office Phase Gate Review Process
The steps below describe the Phase Gate review process. Projects should perform a gate review
when they are nearing completion (90-95%) of a current phase.
1. Project Manager guided by Project Owner completes the NextGen_Gate Review
Executive Summary Outline v5.pptx Template and email to Program Owner and
Prgram Manager for review.
2. Upon review, Program Owner and Manager will provide feedback and request
clarifications or updates (if needed)
3. If the project experienced any variance in business case or a significant scope change or
project/timeline is at risk, please schedule a meeting with the Project Owner, Project
Manager, Program Manager and Program Owner to discuss further.
4.
Depending on the project status, Program Manager and Program Owner will share the
Phase Gate document with Program Sponsors or schedule a meeting with the Project
Owner and Project Manager if warranted.
The following chapters detail the exit criteria and final deliverables, as well as provide guidance
to complete these deliverables at each phase.
Project Management Capabilities

Project Management deals with the day-to-day operational and tactical aspects of executing and
monitoring project work. The Program Management Operations (PMO) office has established
management processes, tools, and services to assist Project Managers (PMs). These tools can be
used to monitor and control actual progress against the project work plan, communicate with
sponsors and stakeholders, plan and manage iterations, and coordinate the effort within the
existing program management structure. For more information on the management structure at
the program level, refer to the PMO Guidebook.
The project management capabilities that will be used on regular basis are:
Work Plan and Time Tracking management
Performance and Status Reporting
Issue Management
Risk Management
Scope Change Control Management
Work Planning
Work planning is an iterative effort that is typically performed at the end of each phase and/or
at scope changes. Re-planning includes re-estimating of work effort, resource needs, completion
schedule, and other cost figures. Throughout the lifecycle of the project, the Project Manager
continues to monitor the projects progress toward the Business Cases benefits, to analyze any
changes, to understand the potential effect on project metrics and Business Case, to work with
the PMO to correct any inconsistencies in the way benefits have been assigned to the project
and to communicate any additional opportunities identified for maximizing value. To learn
more about PMO responsibilities, refer to the PMO Guidebook.
The Project Managers monitor project progress against the work plan to ensure progress
remains within acceptable limits. The Project Managers should focus on high risk, high impact
aspects of the project and be appropriate to the project scale. To do this:
Review the start and finish dates for each task.
Determine the specific changes to be made to the start or finish dates.
Review the predecessor and successor tasks and understand the impact to other tasks
based on changes to dates.
Review the resources assigned to the task and the effort for each resources. Understand
the impact to resources and leveling based on changes.
For impacts across projects, ensure that changes are understood by the Project Managers
and issues discussed/resolved.
The Project Work Plan
The Project Work Plan includes the tasks, milestones, schedule, dependencies, resources,
start/end dates, and other information needed to manage the projects delivery. The Project
Manager is the plan owner, and the PMO office will interact with this person to understand and
discuss the project plan.
Standards in project plan

There should be a 1-1 relationship between projects and work plans (each project has 1
plan, each plan represents 1 project).
The work plan should encompass all work for the project, including functional, technical
and change work (if applicable).
A well constructed work plan should have project phases and milestones. Every phase
should have milestones.
The work plan must be constructed in MS Project and submitted for PMO review. Upon
approval, the work plan will be loaded into Planview for progress tracking during the
phase execution.
Identify resource requirements in the subsequent phase (e.g. if you are in the planning
phase, please name the resources in the Analyze/Design phase).
Example of a Project Plan Hierarchy
WS: Workstream
Phase: [Planning, Analyze/Design, Build/Test, ]
DEL: Deliverable 1
MS: Milestone 1
DEL: Deliverable 2
Task 1
Task 2
MS: Milestone 2
DEL: Deliverable 3
Task 1
Task 2
MMS: Major Milestone 1
Definitions
Workstreams - are a focused collection of work (think of mini-projects); an example
would be a large project that may incorporate delivering a tool along with a process and
metric capability. In PlanView, workstreams require a WS prefix.
Deliverables - list the actual work products, located at the end of a hierarchy of
activities. In PlanView, deliverables require a DEL prefix.
Milestones - lists the key dates as determined by the project manager. A dependency is
created for each milestone to the appropriate activity in the deliverables section. This
predecessor can be any line item in the deliverables section that drives the milestone. No
work is assigned to any of these milestones and their duration is zero. In PlanView,
milestones require a MS or MMS prefix. MS for Milestone and MMS for Major Milestone.
Only Major Milestones will appear on the program status report.
Tasks large units of work with a single major outcome. Tasks are composed of
activities.
Activity smaller units of work that are performed by on individual or team to create a
single primary outcome.
Multi-Workstream Projects
Large complex projects will likely be organized into workstreams. As defined above,
workstreams are large collections of work within a project focused on a significant project
deliverable. In some cases it may not be practical to require all individual workstreams to
maintain the same gate review cadence throughout the projects life-cycle.
In order to deliver a multi-workstream project on-time, where the workstreams will exist in
multiple phases, project managers must set clear expectations with sponsors prior to gate
reviews. Sponsors will need to understand the process for the gate review, the expectation for
phase sign-off and what is being asked of them to approve. Clear and easily discernable
information regarding the status of workstreams at the gate review is critical and expected for
sponsorship sign-off.
For phase-gate review, projects with workstreams in multiple phases will need to account for
out of sequence workstreams in their phase-gate reviews. This means that projects will be
asking sponsors to approve funding and advancement of workstreams at the phase-gates
instead of the entire project. However, projects will need to get tentative acceptance of all
workstreams and full funding for the next phase of entire project. Funding for workstreams that
have not reached phase completion will be held for distribution by the PMO until the
worksteam has successfully completed.
Time Tracking Management
Project Team Members are expected to record their time on a weekly basis. Project Managers
should review project time and collect status. This involves the following:
Review time reports and collect deliverable status on a weekly basis.
Track actual work, schedule, resource, and effort, against the Work Plan.
o Track actual work and identify variance between planned vs. actual hours spent
on tasks.
o Identify tasks that are past due. Highlight tasks that are past due in the Status
Reports (refer to Performance and Status Reporting) and/or raise an issue or
risk.
The following figure depicts the Work Plan and Time Management process. Notice the
interaction between the Project (PM and Team Member) and the PMO office.
Team Member
Work Plan and Time Management
2. Complete actual
hours and submit
timesheets in
PlanView
4a. Complete
time adjustment
Yes
Project Manager
Yes
3. Review Actual
Hours
4. Timesheet
adjustment
needed?
NO
5. Monitor
project progress
6a. Scope
Change
Control
6. Work plan
adjustment
needed?
1. Load PMOapproved work

plan to PlanView
No
PMO
7. Review work
plans
Yes
8. Follow-up
needed?
No
9. Report on
project metrics
Figure 2: Work Plan and Time Management Workflow

The following table provides further detail on the Work Plan and Time Management process.
Table 1: Work Plan and Time Management Process Steps
Step
1. Load PMOapproved work plan
to Planview
Responsible
Project
Managers
2. Complete actual
hours and submit
timesheet in
Planview.
3. Review Actual
Hours
Team Member
Project Manager
Review team members time in relation to tasks,

deliverables or milestones.
4. Timesheet
adjustment needed?
Project Manager
4a. Complete time

adjustment
Team Member
Determine if timesheet adjustment is needed. If

changes to the time allocation are needed, inform the
team member to correct his or her timesheet in
Planview.
Update timesheet in Planview. Reach out to Resource
Manager for approval, if needed.
5. Monitor project
progress
Project Manager
10
Description of Activity
Work plans are submitted to the PMO for approval
at each phase gate (refer to section Project Approval
Phase-Gate Process). Upon approval, load MS work
plan to Planview.
Submit timesheet on a weekly basis in Planview.
Monitor project progress against baseline to ensure

progress remains on schedule and on budget.
6. Work plan
adjustment needed?
Project Manager
Determine if rework/adjustment is needed based on

project progress against work plan.
6a. Scope Change

Control
Project Manager
7. Review work
plans
PMO
8. Follow-up
needed?
PMO
9. Report project
metrics
PMO
If work plan rework is need, complete a change

request form, determine mitigation plan, and follow
the Scope Change Control Management process.
PMO has the following tasks/responsibilities:
Validate the overall work and actual work efforts
to ensure that they fall within the appropriate
control limits.
Review the start and finish dates, as well as
resources assigned to the tasks and the effort for
each resource.
Understand the impact to resource and leveling
based on changes.
If Scope Change is needed and change was
approved, the PMO confirms that changes
schedule, budget, deliverables, or milestones
have been approved.
Note: Updates should be made in both MS Projects
and Planview.
Are there any discrepancies or pending
questions/concerns regarding schedule, budget,
milestones, or deliverables?
The PMO will pull project status reports from
Planview on a weekly basis. Set project health based
on actual vs. baseline, issues and risk identified, as
well as accomplishments made.
Planview Time Tracking Job Aid:

https://collaborate.adsroot.itcs.umich.edu/mais/products/pvhelp102/PlanView%20at%20ITS/Tracking%20Time%20and%20Adding%20Work%20to%20Timesheet.
docx
Program Deliverable Management
As a part of the NextGen Program, certain deliverables are required for each phase to ensure the
success of the Program. The following diagram outlines the required program deliverables by
phase:
11
To see the most current version of this document, please refer to the Program Deliverable Flow.
Many of these deliverables are to provide integration with the various capabilities in NextGen.
To understand proposed responsibility for each deliverable, please refer to the NextGen
Deliverable RACI, also shown below.
12
Build/Test
Service
Bundle
Delivera
A
A
A
R
R
R
R
I
A
A
A
A
I
C
I
I
I
I
I
I
I
I
I
I
I
C
I
C
R
R
I
R
C
C
R
C
I
C
Security Manager
IT Cost Manager
C
I
I
I
R
C
C
C
C
C
C
C
R
C
C
C
C
I
Service Portfolio Owner
A
A
A
A
A
R
A
A
A
A
A
A
A
I
I
I
I
A
Service Center Manager
Operations and Availability
Service Transition Manager
R
R
R
C
C
I
I
I
C
I
C
I
I
C
C
C
Enterpise Architect (Coach)
I
I
A
A
A
R
A
A
A
A
R
A
A
A
A
C
C
C
Capability Integration
Customer Relationship Manager
Technical Lead(s)
I
I
I
I
I
C
A
Communications Lead (SH)
Deployment Manager (Bundle) (RM)
Workforce Strategy Lead (KS)
I
I
I
I
I
I
Communication Plan
Test Approach
Test Scenarios, Conditions & Expected Results
Build Documents
Service Pilot & Deployment Plan
Build/Test Executive Summary
Production Support Plan
Early Life Support Plan
Service Restoration Plan
Service Availability Plan
Service Capacity Plan
Org Readiness Assessment
Service Level Expectations (SLE)
Training Plan
Unit Readiness Plan
Workforce Plan
Change Management Summary
Service Bundle Test Approach*
Service Bundle Test Scenarios, Conditions & Expected
Results*
Service Bundle Deployment Plan*
I
I
I
C
C
I
I
Project Owner
Project Manager
Change Management Lead ( AP)
Program Integration Lead ( AB)
Program Operations Lead
Program Owner (LP)
Program Manager ( DT)
Program Steering Group
Program Sponsors
Project Definition
Project Plan
Business Case and Benefits Realization
Planning Executive Summary
Service Definition
Requirements Traceability Matrix
Solution Architecture
Detailed Design Documents
Analyze/Design Executive Summary
Service Flow
Support Model
EA Questionaire
Information Assurance Questionnaire
Change Impact Analysis
Stakeholder Analysis
Risk Assessment
Project Team
Program Director(JG)
Planning
Deliverable
Analyze/Design
Program Team
Functional Lead/BSA
NextGen- Program Deliverable RACI Matrix
SME/Team that Provides Assistance
I
C
R
R
I
C
C
C
C
R
R
C
C
C
C
I
I
C
I
I
I
C
C
C
I
I
I
NextGen Program Office
C
C
I
I
C
C
I
I
Manoj Krishnan
Service Management
C NextGen Program Office
Chris Eagle
C
I
C
C
I
I
R
R
I
I
C
I
I
C
R
C
I
C
C
R
C
I
C
C
C
C
I
R
R
I
I
I
C
C
C
C
C
C
I
I
I
I
I
I
I
C
C
I
R
R
R
Communication Team
I
I
C
C
C
C
R
R
R
I
I
I
I
C
C
R
C

Service Management
Service Management
Chris Eagle
R Information Assurance Team
Change Management Team

Service Management
Service Management
Service Management + O&A
Customer Relationship Manager
Workforce Management Team
The RACI should be used as an initial guideline, project circumstance and scope may require
variance from this model. The RACI defines who is responsible, accountable, and should be
consulted and informed throughout the lifecycle of the deliverable. The RACI definitions are
outlined below:
Responsible
Those who do the work to achieve the task. There is typically one role with a participation type
of Responsible, although others can be delegated to assist in the work required.
Accountable
The one ultimately answerable for the correct and thorough completion of the deliverable or
task. Typically the Accountable role delegates the completion of the deliverable to the
Responsible role. There must be only one Accountable specified for each task or deliverable.
Consulted
Those who possess subject matter expertise or knowledge that is critical to the creation of a
deliverable or are highly dependent upon the deliverable.
Informed
Those who are kept up-to-date on status throughout the lifecycle of the deliverable, and with
whom there is just one-way communication. These are the "key consumers" of the information.
13
Each of the required Program deliverables are described in further detail below in the
corresponding phase section. For information on how to report the status of a deliverable,
please refer to the Performance and Status Reporting Section of this document below.
Performance and Status reporting involves evaluating and documenting the projects
performance against the work plan. Performance reporting addresses the NextGen Michigan
Program Management Office, and the Program Steering Committee. Performance assessment
must be objective to be reliable.
Project Managers are expected to complete Project Status reports on a weekly basis. The Project
Status report highlights project status based on deliverable/milestone status, summarizes recent
progress and upcoming plans, as well as quantitative metrics, such as baseline and actual dates.
Project Managers should analyze variances from project baselines to identify actual and
potential problems, i.e. issues and risks, as well as forecast future performance.
Project Managers are also expected to complete a monthly Project Status report for publishing
on the NextGen Michigan website. The monthly Project Status report provides campus with
insight on the progress made by each project.
The figure below displays a sample of the NextGen Michigan Program Office Scorecard that
consists of various project status reports.
Figure 3: NextGen Program Office Scorecard
14
The figure below depicts the Performance and Status Reporting process and the table provides
further detail on process steps and responsible parties.
PMO
Yes
4. Examine Project
Data Against
Baseline
2. Data
Complete?
5. Highlight Areas
of Concern
6. Publish Report
9. Communicate
Corrective Actions
Project
Manager
Report
No
3. Follow-up on
missing or invalid
data
Advisory/
Steering
Committee
1. Update Project
Progress in
Planview
10. Implement
Corrective Actions
7. Review Project
Performance
Report
8. Determine
Corrective Actions
Figure 4: Performance and Status Reporting Workflow
Table 2: Performance and Status Reporting Process Steps

Process
1. Update Project
Progress in
Planview
Responsible
Project
Manager
On a weekly basis, Project Managers are responsible for
submitting project progress updates in Planview. Each
submission should include updates on:
1. Health of project deliverables (Green, Yellow, Red).
2. Accomplishments for the week.
Refer to the table for Deliverable Health criteria.
PMO will review the data and request any
clarification/updates from the appropriate Project Manager.
This data will consist of issues, risks, scope changes,
progress status, schedule, benefits realization, etc.
Refer to Issue Management and Risk Management for a
description of the processes and data required.
2. Data
Complete?
PMO
3. Follow-Up on
Invalid or
Missing Data
4. Examine
Project Data
Project
Manager
Project Manager will provide additional data requested by

the PMO.
PMO
PMO will analyze data for quality, adherence to processes,

and impact to project against the baseline.
15
Against Baseline
5. Highlight
PMO
Areas of Concern
PMO will highlight areas of concern needed to be brought to

the attention of the Program Manager(s), Program
Advisory/Steering Committee, and Program Sponsor(s).
PMO will create a Performance Report based on the
reporting cadence.
The Committee reviews the issues with a status of Critical
or High and ensures the critical risks are being mitigated.
The Committee monitors milestones progress and the
overall Program/Project health.
6. Publish
Report
7. Review Report
PMO
8. Determine
Corrective
Actions
Advisory/
Steering
Committee
Program Advisory/Steering Committee will address issues,

risks, scope changes that are potential threats to the
Program/Project. Determine corrective actions to ensure the
Program/Project remains on budget and on schedule.
9. Communicate
Corrective
Actions
PMO
PMO will communicate corrective actions to be

implemented by Project Manager.
10. Implement
Corrective
Actions
Project
Manager
Project manager will implement corrective actions based

direction from leadership to ensure the Program and Project
remains on schedule and on budget.
Advisory/
Steering
Committee
On a weekly basis, Project Managers are expected to provide the health status on major project
deliverables and/or milestones. The overall health of the project depends on the health of each
major deliverable and/or milestone. Use the table below to determine the health of each major
deliverable/milestone. The PMO office will determine the overall health of your project based
on your weekly input. The PMO will use the following criteria to determine the overall health
of a project:
Green The health status of all major deliverables/milestones is green.
Yellow The health status of one or more deliverables/milestones is yellow.
Red The health status of one or more deliverables/milestones is red.
The table below provides guidance on how to choose the health status of each deliverable.
Table 3: Deliverable Health Status Criteria
Category
Scope
16
Green
Scope is clearly
defined and stable.
Yellow
Scope is unstable with
expected impacts.
Red
Scope is not well
defined, is
unachievable or
differs substantially
Schedule
On schedule.
Risk & Issues
Risks and/or issues

identified and actively
managed with
reasonable
expectation that they
will not impact project
success.
The properly number
of resources are
working to meet
current expectations.
Only if ALL of the
above are green.
Resources
Overall
Deliverable
Status
Task/activity contributing to
the completion of the
deliverable likely to be
missed.
Risks and/or issues have not
been identified, or known
risk/issues pose a reasonable
threat to deliverable success.
from the project

charter. Requires
remediation.
Major or several
tasks/activities are
likely to be missed,
requires remediation.
Risks have been
realized (become
issues) and have put
deliverable success in
jeopardy.
Potential issue in securing

needed resources.
Needed resources not

secured.
If ANY of the above are

Yellow.
If ANY of the above

are red. Project status
report must include a
plan to mitigate in the
comments field.
Communication regarding project performance and overall project status, staffing, scope
changes, issues, risks, and related corrective actions should be an ongoing process which
includes both formal and informal interaction between the project manager, the project team,
program management, and external teams (third parties, sponsor, etc.).
It is important that the program manager always be aware of any issues affecting performance
of a project since there could be dependencies which could create a program-wide impact.
Besides providing regularly scheduled communications and reporting, the project manager
should understand when and how to escalate issues and/or risks to the program level to
prevent causing an unforeseen impact to schedule, budget, or quality.
Issue Management
An issue is a problem that is currently happening. An issue might adversely affect a projects
ability to deliver based on the agreed scope, schedule, budget, and quality, as well as ability to
meet key stakeholders expectations. An issue describes a situation where something has gone
wrong and/or a decision needs to be made. Since an issue has already been realized, it can no
longer be mitigated, and must instead be resolved. Issues may have started from risks that have
been realized; if this is the case, then the issue should be linked to the original risk.
17
Project issues occur at all phases of the project. Issue identification is an ongoing process. Any
team member can raise issues. The Issues Management process, established by the PMO office,
defines how the project should raise, document, and, if appropriate, escalate an issue, as well as
track it through closure. In addition, the PMO office has developed an Issue Log as tracking
mechanism; however, the issue log should not be used as sole means of communication. Both
formal (issues log) and informal (verbal communication with team members) should take place.
Project Managers and team members are expected to log issues on a continuous basis. Project
Managers are expected to review and validate that new issues have the correct level of
information needed. All project issues should be documented in Planview. If an issue started as
a risk that was realized, then link the issue with the associated risk.
Review the Issue Management Approach depicted on the figure below to understand the
process for identifying, analyzing, escalating, resolving, and reporting issues.
PMO
Issue Management
Start
Issue Creator
10. Monitor, Control, and Report
1. Identify Issue
2. Document Issue
Issue Log
Project Manager
3. Validate Issue
4. Issue or
Risk?
Issue
5. Reject
Issue?
Risk
Yes
9. Close Issue
9. Close Issue
Yes
7. Monitor Issue
9. Close Issue
8. Issue
Resolved?
End
No
Issue Owner
Risk
Management
End
6. Analyze and
Resolve Issue
Escalation
Management
Figure 5: Issue Management Workflow
The table below provides more details on the Issue Management process and responsible
parties.
18
Table 4: Issue Management Process Steps

Steps
1. Identify
Issue
Responsible
Issue Creator
2. Document
Issue
Issue Creator
3. Validate
Issue
Project
Manager
4. Issue or
Risk?
Project
Manager
5. Reject
Issue?
6. Analyze
and Resolve
Issue
Project
Manager
Issue Owner
7. Monitor
Issue
Project
Manager
8. Issue
Resolved?
Project
Manager
9. Close Issue
Project
Manager
19
Issue identification is an ongoing process, which is monitored
and updated regularly. The Issue Creator will inform the
Project Manager that there is a new project issue.
Identified issues will be documented on the Issue Log (in
Planview). Projects will document issues through the lifecycle
of the project.
All Open issues are validated by the Project Manager to
ensure issue validity, priority assignment, and correct due date.
If the issue requires additional information or clarification, then
the Project Manager will request clarification from the Issue
Creator. Valid issues will be assigned to an Issue Owner and a
Target Resolution date.
Project Manager reviews Open submissions and assesses
their validity. Submissions assessed as risks rather than issues
are set to Closed status and deferred to the Risk Management
process. The Project Manager documents the rationale.
If the issue is not valid, then the Project Manager will set its
status to Rejected and document the rationale.
The Issue Owner analyzes the issue, determines level of impact,
researches resolution alternatives, and modifies the Due Date as
needed. During this stage, the issue status remains Open.
After the issue has been analyzed, the Issue Owner will
determine a feasible solution and update the issue log. The
Issue Owner communicates the issue progress to the Project
Manager. The implementation of the solution is planned
accordingly.
Project Manager regularly assesses the status of the issue
resolution progress and manages communication, notification,
and, if necessary, escalation. The Project Manager reviews and
agrees on an Action Plan, as well as monitors the resolution
progress and determines the necessary escalation with all
affected parties. The status will remain in Open until the
issue is resolved.
Once a solution has been implemented, the Project Manager
monitors progress to determine the success of the
implementation. If the issue cannot be resolved or
implementation was not successful, the issue is escalated up the
program governance and deferred to the Escalation
Management process.
Once the issue has been addressed and the resolution has been
implemented, then the Project Manager will document the
10. Monitor,
Control, and
Report
PMO
resolution and set the status to Closed.

PMO oversees the Issue Management process and supports the
timely identification, validation, and resolution of issues. PMO
monitors process compliance, manages the compilation of issue
reports, and prepares analyses for the leadership team. PMO
will report issues with a status equal to Critical or High, as well
as escalate them as deemed appropriate or based on the
escalation criteria.
For each new issue, the following fields should contain information:
Table 5: Issue Log Fields in Planview

Planview
Field Name
CRI #
Description
CRI Status
The status of the issue.
Number generated automatically in Planview to keep track of all issues.
Dropdown field with the following choices:

Open: The potential issue has been entered into the Issue Log, assigned to the
appropriate resource for analysis, and is being actively investigated.
Rejected: The potential issue has been rejected either because it is a duplicate or
another valid reason.
Closed: The potential issue has been reviewed, a resolution has been proposed,
accepted, and acted upon.
If a Closed issue becomes active, it should to be re-opened as a new issue.
Within the new issues Description, the Issue Creator should reference the
Closed issue ID number to provide history. Also note that risks mistakenly
submitted as issues will be set to Closed status using this process.
Initiated By
The user who created the issue. Automatically generated in Planview.
Issue Owner
The person responsible for following up on the issue. Responsible person can be
selected from a list of Planview users.
The project name associated with the issue. Automatically generated in
Planview based on the project work plan.
Project
Name
Naming convention: L8: DEL: Project PLAN: [Name of Project]

CRI Priority
20
The priority of the issue. Dropdown field with the following choices:
1 Critical: I cant move forward until this issue is resolved.
2 High: Im fine for right now, but unless this issue is resolved by the due
date, I wont be able to move forward.
3 Medium: Im fine for the right now, but this may impact my ability to
move forward in the near future.
4 Low: This issue is not impacting my ability to move forward.
Description
& Detail
Initiated On
Target
Resolution
Date
CRI Type
Refer to the Escalation Table below to determine the appropriate level of

priority.
Description field to be used as Issue Title.
Detail field to be used as Issue Description (2-3 sentences)
The date the issue was identified. Automatically generated in Planview.
The date by which the issue should be resolved. Select a specific (future) date.
The type of issue being raised. Dropdown field with the following options:
Cost - Financial benefits, additional costs in changing/solving design,
application program, or operational problems.
Scope The work that needs to be accomplished to deliver a product, service,
or result with the specified features and functions.
Schedule Deliverables and/or Milestones deadlines.
Quality Deliverables or work products comply with project standards,
expectations, and goals.
Resources Lack of resources with the appropriate skills to complete
deliverables.
Action Plan
& Issue
Resolution
Resolution
Date
Clear and concise description of the proposed solution or final solution. May
reference other documents as needed. If other documents are referenced,
provide file name and location.
There are two fields in Planview that capture this information. Action Plan is a
text field where the user records the proposed solution to the issue. The Issue
Resolution is a text field that captures the final resolution once the issue is
closed.
Date on which the issue was closed or deferred. User must select the date.
The table below provides information on the issue escalation process.
21
Table 6: Issue Escalation

Escalation
Level
Project
Manager
PMO
Steering
Committee
Description
All issues should begin with a priority level equal to Low or Medium in order
to properly follow the escalation process. The PM is responsible for reevaluating the priority of each new issue. The PM determines the level of
impact, action plan, resolution alternatives, and Issue Owner. Along with the
Issues Owner, the PM will monitor the resolution progress. If the issue cannot
be resolved at the project level, the PM will change the priority to High. At this
point, the PMO will assess the issue.
The PMO is responsible for re-evaluating the priority of each new issue with a
status of High. Along with the Project Manager, the PMO will monitor the
progress of the issue. If the issue cannot be resolved at the PMO level, the
PMO will change the priority to Critical. At this point, the PMO will escalate
the issue to the Program Advisory/Steering Committee.
The Program Management team will escalate all issues with a status of Critical
to the Steering Committee is to guide and provide issue resolutions or
approving a contingency plan.
Planview Issue Management Job Aid:

https://collaborate.adsroot.itcs.umich.edu/mais/products/pvhelp102/PlanView%20at%20ITS/Issue%20Details.pdf
Risk Management
Risk management and issue management are closely related, but distinctly different. A risk is
an uncertain circumstance or event that could hinder a project from achieving its objectives.
Issues are problems that currently affect the projects planned execution.
Any risk that the project fails to adequately respond to results in failure to obtain benefits.
Conversely, approaches that successfully avoid risks and/or mitigate their impact clear the way
for achieving benefits. Remember these relationships when assessing project performance, and
highlight them in the project performance reporting.
Risk management is a systematic approach to identifying, evaluating, and mitigating risks. It is
not about being risk averse. Rather, it is based on taking action to either minimize the impact of
a risk and/or decreasing the likelihood of it occurring. It involves planning and being proactive.
Review the Risk Management Approach depicted and explained on the figure and table below.
This process will be used to identify and evaluate risks. Work with the PMO to address any
questions on the documented process. Reuse this process to evaluate all project-specific risks.
Document your project-specific needs in the Risk Log.
22
PMO
Risk Management
Start
Risk Creator
14. Monitor, Control, and Report
1. Identify Risk
2. Document Risk
Risk Log
No
End
4. Risk or
Issue?
Program Manager
3. Validate Risk
Risk
5. Determine
Approach and
Create Risk
Mitigation Plan
9. Monitor Risk
10. Risk
Condition
Triggered?
Risk Log
13. Close Risk
Issue
13. Close Risk
Yes
6. Create Risk
Contingency Plan
11. Issue
Generated?
Yes
Risk Log
No
End
Issue
Management
Escalation
Management
Issue
Management
Risk Owner
No
7. Risk
Mitigation
Required?
8. Implement Risk
Mitigation Plan
12. Implement
Risk Contingency
Plan
Yes
Figure 6: Risk Management

Table 7: Risk Management Process Steps
Process
1. Identify Risk
Responsible
Risk Creator
Risk identification is an ongoing process, which is
monitored and updated regularly, of uncovering
circumstances, hazards, threats, and vulnerabilities that
could affect the work efforts or the projects ability to meet
its objectives. Risk sources are both internal and external.
To be effective, do not focus on identifying every possible
risk, but rather focus on identifying events that could
negatively impact any of the following project areas, cost,
scope, schedule, quality, or resources. In addition, please
note that risk identification is not a focus on placement of
blame.
A risk will be discussed with the Project Manager prior to
entering risk in Risk Log.
23
2. Document Risk
Risk Creator
3. Validate Risk
Project
Manager
4. Risk or Issue?
Project
Manager
5. Determine
Approach and
Create Risk
Mitigation Plan
Project
Manager
6. Create Risk
Contingency Plan
Project
Manager
Identified risks will be documented on the Risk Log. See

the Table below for a description of the required fields of a
Risk.
All Open risks are analyzed by the Project Manager on
at least a weekly basis to determine the appropriate
probability and priority for all new risks. If the risk
requires additional information or clarification, then the
Project Managers will request clarification from the Item
Creator.
The Project Manager reviews Open submissions and
assesses their validity. Valid risks are set to Open status.
If the risk is in fact an issue, then the Project Manager will
set its status to Rejected and document the rationale in
the Detailed Description.
The Project Manager will define a mitigation strategy for
each risk. Identified Program members will work with the
Project Manager in assessing and developing the
mitigation and contingency plan, and updates the risk log.
Risk mitigation alternatives are the set of options that may
mitigate/subdue risk if implemented. A programs risk
mitigation strategy is preventative in nature and designed
to reduce impact or probability of risk occurrence. A risk
mitigation strategy uses acceptance, avoidance, protection,
reduction, research, and transfer to develop alternatives
for risk resolution. Each strategy contains objectives,
constraints, and alternatives. The contingency plan is
executed if a risk is realized despite the implementation of
the risk mitigation strategy.
A Risk Contingency Plan describes the possible scenarios
of risk problems that could occur from a solution and what
to do to revert back to normal operation. Risk contingency
planning involves creating one or more fallback plans that
can be activated in case efforts to prevent the risk event
fail. Contingency plans are necessary for all risks,
including those that have mitigation plans. They address
what to do if the risk occurs and how to minimize its
impact.
Risk triggers are established for the contingency plan
based on the probability of risk, the severity of impact, and
the level of control that may be encountered. Triggers are
indicators that tell the engagement a certain condition is
about to occur, or has occurred, and, therefore, it is time to
24
put the contingency plan into effect.

Contingency plans are created to:
Identify the solutions or workarounds to resume
normal business operations
Prepare people who are responsible so they can
respond quickly when problems occur
Identify the right people to notify and/or implement
actions
The Risk Owner evaluates and determines whether to
implement the mitigation plan.
7. Risk Mitigation
Required?
Risk Owner
8. Implement Risk
Mitigation Plan
Risk Owner
Progress on the mitigation activities will be monitored and

reported to the Project Manager on a periodic basis.
9. Monitor Risk
Project
Manager
The Project Manager will have oversight on risk

management activities. The Project Manager will act as the
point of escalation if the risk is not manageable. If the risk
is realized, the Project Manager could request a different
risk handling approach or assign the risk to a different
Risk Owner to assess and plan the mitigation strategy.
If risk triggers are realized, the Risk Owner implements
the planned risk contingency approach. Progress on the
mitigation activities will be monitored and reported to the
Project Manager on a periodic basis.
If an issue is generated when the risk condition is
triggered, defer the issue to the Issue Management
process.
The Risk Owner will carry out the contingency plan if the
risk triggers are realized. After the contingency plan has
been implemented or risk has become an issue, the Project
Manager will document risk status in the appropriate
fields; detailed description, contingency plan, actions to
date, etc.
When a risk turns into an issue, expires, is diffused, or is
removed through the implementation of the mitigation or
contingency plan, the risk is then set to Closed.
The PMO oversees the Risk Management process and
supports the timely identification, validation, and
resolution of risks. The PMO monitors process
compliance, manages the compilation of risk reports, and
prepares analyses for the leadership team.
10. Risk Condition Project

Triggered?
Manager
11. Issue
Generated?
Project
Manager
12. Implement
Risk Contingency
Plan
Risk Owner
13. Close Risk
Project
Manager
14. Monitor,
Control, and
Report
PMO
For each new risk, the following fields in Planview should contain information:
Table 8: Risk Log fields in Planview
Planview
25
Description
Field Name
CRI#
CRI Status
Unique number to track risks. Planview automatically generates a unique

number for each new risk.
The status of the risk. Dropdown field with the following options:
Initiated By
Open: The potential risk has been entered into Risk Log, assigned to the
appropriate resource for analysis, and is being actively investigated.
Rejected: The potential risk has been rejected either because it is duplicate
or another valid reason.
Closed: The potential risk has been reviewed, a resolution has been
proposed, accepted, and acted upon.
The user who logs the risk is the risk creator.
Risk Owner
Project Name
Risk Horizon
and Risk
Priority
The user to whom the risk is assigned. Planview allows the risk creator to
assign a risk owner. Planview also records a risk owner's contact
information.
The project name associated with the risk. Automatically generated in
Planview based on the project work plan.
Naming convention: L8: DEL: Project PLAN: [Name of Project]
Planview does not track severity of impact; however, it does track the Risk
(Impact) Horizon and Risk Priority. The PMO will use these two fields to
determine if escalation is necessary.
Estimate the Risk Impact Horizon. This dropdown field has the following
options:
Short Term: within the next 3 months
Mid Term: 3-6 months
Long Term: greater than 6 months
The Risk Priority dropdown field has the following options:
1 Critical: Threatens the success of the project.
2 High: Significant disruption to project schedule, cost, and
products/services over the medium and long term.
3 Medium: Progress disrupted with large extensions to schedule and cost,
across short and medium terms.
4 Low: Exposure is marginal.
Probability
Description
26
The probability of the risk occurring. Text field. PMs should enter a
percentage in intervals of 25% as listed below:
100%: Expected occurrence
75% : Probable occurrence
50% : Possible occurrence
25% : Unlikely occurrence
This field serves as Risk Title. The Detail field should be used to provide
2-3 sentences describing the risk.
Initiated On
Resolution Date
CRI Type
Risk Triggers
Risk Response
Plan
(Mitigation/
Contingency)
The date the risk was identified. Automatically recorded when the risk is
created.
The date the risk will be realized or closed.
The type of risk being raised. The dropdown field has the following options:
Cost - Financial benefits, additional costs in changing/solving design,
application program, or operational problems.
Scope The work that needs to be accomplished to deliver a product,
service, or result with the specified features and functions.
Schedule Deliverables and/or Milestones deadlines.
Quality Deliverables or work products comply with project standards,
expectations, and goals. project leaves; the project may be significantly
impacted if it cannot replace the
Resources Lack of resources with the appropriate skills to complete
deliverables.
The risk trigger is the event that would need to happen in order for the
potential risk to become an issue. Risk triggers are usually expressed with
some sort of dependency, or qualifier. For example, a risk trigger might be
that a resource with critical skills or knowledge leaves project leaving a gap.
When the risk trigger occurs, the risk is no longer a risk, but has
materialized into an issue that needs resolution.
This is a text field that captures situations that would allow for risk
realization, or make it an issue.
The user will record both the Mitigation plan and Contingency plan in this
text field. The Mitigation plan is the proposed solution to lessen the
probability and/or impact of the risk. The contingency plan is the action to
take if the risk is triggered.
As part of the Mitigation plan, the Project Manager should document which
strategy will be employed to mitigate the risk. See below for definitions of
strategies.
Accept - These describe the factors that may directly affect the success of
the Project ABC, but are outside of the sphere of influence of the Project
ABC Manager, and can therefore only be accepted. In addition,
acceptance of risks as a response may be based on the costineffectiveness of any available response or solution. An example:
acceptance response could be created from a legislative or legal risk,
over which no control could be leveraged.
Avoid - Avoidance-based responses are employed at any point in the
development lifecycle where future planning work is performed.
Typically, most risk avoidance occurs during the project definition and
planning phases of a project, where objectives, scope, key success
factors, work breakdown, and project outputs or deliverables are
defined. An example of risk avoidance is the use of a stable, established
27
technical solution in preference to an untried or complex new

technology. However, risk avoidance solutions may limit the ability to
achieve high-level Project objectives, by unnecessarily constraining a
desirable solution.
Mitigate - Occurs at all points throughout the development lifecycle,
and is typically the most common response. The Project Manager
identifies an action or product that becomes part of the team or work
plan, and is monitored and reported as part of the regular performance
analysis and progress reporting of the Project.
Transfer - Transfer-based responses target the party who is best placed
to analyze and implement the response to the risk, based on their
expertise, experience, and suitability. Typical transfer responses include
the sub-contracting to specialist suppliers who are able to reduce the
overall risk exposure.
The table below provides information on the risk escalation process.

Table 9: Risk Escalation
Escalation
Level
Project
Manager
PMO
Steering
Committee
Description
All risks should begin with a priority level equal to Low or Medium in order to
properly follow the escalation process. The PM is responsible for re-evaluating
the priority of each new risk. The PM determines the level of impact, action
plan, resolution alternatives, and Risk Owner. Along with the Risk Owner, the
PM will monitor the resolution progress. If the issue cannot be resolved at the
project level, the PM will change the priority to High. At this point, the PMO
will assess the risk.
The PMO is responsible for re-evaluating the priority of each new risk with a
status of High. Along with the Project Manager, the PMO will monitor the
progress of the risk. If the risk cannot be addressed at the PMO level, the PMO
will change the priority to Critical. At this point, the PMO will escalate the
risk to the Advisory/Steering Committee.
The Program Steering Committee is responsible for assessing all new risks
with a status of Critical, re-prioritizing critical risks, approving/providing
mitigation/contingency plan.
Planview Risk Management Job Aid:

https://collaborate.adsroot.itcs.umich.edu/mais/products/pvhelp102/PlanView%20at%20ITS/Risk%20Details.pdf
Scope Change Control Management

This deliverable is a written request, from the project to the program, for a material change to
the project. Program management must approve a Change Request before it can be
28
implemented by the project. Program management can also issue Change Requests to reflect
approved changes requested by other stakeholders (e.g., sponsoring organization management,
program management itself, other projects that may impact the current project, etc.) A project
Change Request is an authorized (written and approved) material change to an active project
typically affecting the baseline requirements such as scope, cost, schedule, resources, acceptance
criteria, method of delivery, documentation, quality, risk, and/or performance characteristics.
Prepare this deliverable whenever a requested change affects the project baselines. If the change
does not affect the project baselines, preparation of this deliverable is unnecessary. This
deliverable is applicable to all projects.
Start
Project Manager
Scope Change Management
2. Document
Change Request
1. Identify Change
Request
9. Analyze and
Implement Change
Request
6. Revise Change
Request
Scope
Change Log
Scope
Change Log
Yes
3. Validate
Change Request
PMO
Risk
Management
5. Additional
Info Required?
Yes
Risk
10. Close Change

Request
No
Issue
Steering
Committee
Issue
Management
4. Associated
Risk/Issue
Identified?
7. Approve
Change
Request
8. Reject Change
Request
No
Figure 7: Scope Change Management Workflow

Table 10: Scope Change Process Flow
Process
1. Identify
Change Request
29
Responsible
Project
Manager
Based on the project (work plan) progress and budget, the
Project Manager will determine if a change request is
needed in order to maintain the success of the project. The
Project Manager identifies, documents, and is responsible
for scope change follow through.
2. Document
Change Request
Project
Manager
The Project Manager will document identified scope

changes in Scope Change Log.
3. Validate
Change Request
PMO
All Open change requests are validated by the PMO to

ensure change validity, and correct due date.
4. Associated
Issue or Risk
Identified?
5. Additional
Info Required?
PMO
The PMO reviews Open submissions and assesses if

they create new risks or issues.
PMO
The PMO may request additional information about the

scope change request. Determine if additional information
is required to process this scope change request.
6. Revise Change
Request
Project
Manager
The Project Manager revises the request, if needed, when

requested by the PMO.
7. Approve
Change Request
Steering
Committee
PMO will escalate the change request to the Steering

Committee. If the request is approved, the PMO will set
the status of the request to Approved.
8. Reject Change
Request
Steering
Committee
9. Analyze and
Implement
Change Request
Project
Manager
10. Close Change

Request
PMO
If the scope change is not approved, then the PMO will set
its status to Rejected and document the rationale in the
Detailed Description.
The impacted project(s) is then responsible for assigning
responsibility for implementing the approved Scope
Change request. This includes updating the schedule(s),
milestone(s), budget(s), requirement(s), and any other
affected project deliverables in a synchronized manner.
The Project Managers are responsible for coordinating the
implementation of the changes across all impacted
deliverables, such as work plans, test cases, etc., in their
respective areas of responsibility.
The change request is closed once the request has been
resolved.
The Change Request template has the following required fields. Refer to the table below for
further description of each field.
Table 11: Change Request Fields on form
Field Name
Change Status
30
Description
The status of the scope change:
Open: The scope change has been entered into Scope Change Log,
assigned to the appropriate approver, and is awaiting approval.
Approved: The scope change has been reviewed, accepted, and
approved.
Rejected: The scope change has been rejected.
Closed: The scope change has been approved and work product has
Date of Request
Created By
Implementation
Date
Project Name
Type of Change
Description
Priority
Impact Severity
Benefits of
Proposed Change
Alternatives
List of Impacted
Deliverables
Financial Impact ($)
Schedule Impact (in
days)
Impact Summary
Authorized
Approver
31
been updated to include the additional/subtracted scope.

Deferred: Decision
Date change request was created.
The user who created the scope change.
The date by which the change should be implemented.
The project name associated with the change.
Business Change or Need: Changes in what the organization needs
to be able to do, as a result changes to what the project delivers.
Funding Source Plan Change: Changes in funding sources.
Scope Change or Need: Changes in the magnitude or composition of
the project.
Schedule Change: Changes to the original work plan and/or due
date for scheduled milestones/deliverables.
Error Correction: Changes made to project scope or schedule in
order to correct a new or overlooked error.
Regulatory Requirement: Changes due to new external regulatory
requirements.
Other: Changes not listed above.
A description of the change with rationale.
The priority of the scope change:
1 Critical: I cant move forward until this change is resolved
2 High: Im fine for right now, but unless this change is resolved by
the due date, I wont be able to move forward
3 Medium:Im fine for the right now, but this may impact my ability
to move forward in the near future
4 Low: This change is not impacting my ability to move forward
The severity of the scope changes impact on the business.
1 - Critical Impact: Threatens the success of the program
2 - High Impact: Significant disruption to program schedule, cost, or
quality
3 - Medium Impact: Progress disrupted with manageable extensions to
short-term schedule and cost
4 - Low Impact: Exposure is slight
The additional benefits the proposed change.
Any alternatives to the scope change that exist.
A list of deliverables impacted by the scope change.
The dollar amount of the scope changes impact.
The number of days by which the scope change affects the schedule.
A summary of the impact of the scope change.
Program Steering Committee
Sponsor
Organization/Title
Date Approved
Program Management Office (PMO)

Customer/Stakeholder
Other
Title of the approver.
Date the Change Request Form was approved.
Planview Scope Change Control Management Job Aid:

https://collaborate.adsroot.itcs.umich.edu/mais/products/pvhelp102/PlanView%20at%20ITS/Forms/AllItems.aspx
Project Resource Requests
To request a project resource, please fill out the following forms and send them to the Program
Operations Lead.
ITS Resource Request
Campus Resource Request
32
Planning Phase
Planning is the first phase of the project lifecycle. During this phase the Project Manager
assembles and organizes all the necessary information to achieve the following objectives:
Understand project stakeholder goals and expectations.
Establish project governance to provide leadership and decision making support for the
project.
Confirm project scope, estimations, and roles.
Develop project work plan.
Estimate operating cost, savings, and benefits.
In order for a project to exit the Planning phase and receive approval to move to the next phase,
the project must have:
Identified the Project Sponsor, Owner and Manager who will be held accountable to the
outcomes of the project.
Identified stakeholders and developed a plan to manage their expectations.
Defined high level objectives, scope, and assumptions.
Identified risks and issues, and provided mitigation and contingency plans for the key
business risks.
Defined a high-level business case, which includes benefit realization tracking that is
supported by the project sponsor.
Developed high-level work and resource plan with clear effort estimation for the next
phase of work.
Planning Deliverables
The following tables outlines the required program deliverables for the Planning phase.
Deliverable
Name & Link
to Template
Project
Definition
33
Description
The project manager creates the Project Definition to define the overall scope of
the project that is to be undertaken, as well as to maintain and operate the
project. The Project Definition includes:
Project Objectives
Project Scope
Assumptions, Risks, and Dependencies
Stakeholder Identification and Plan to Align
Communication Approvers
Governance Requirements
Project Plan
Business Case
Service Level
Expectations
(SLE) Draft
Planning
Executive
Summary
The Project Plan includes the tasks, milestones, schedule, dependencies,

resources, start/end dates, and other information needed to manage the
projects delivery. The Project Manager is the plan owner, and the PMO office
will interact with this person to understand and discuss the project plan.
For project plan standards and recommendations, please refer to the Project
Management Guidebook.
the business case is a quantitative and qualitative model of benefits and costs
used to approve an investment and guide the work conducted during the
project life-cycle.
The business case articulates the financial and non-financial rationale for
proceeding or not proceeding with a project. It does the following:
Quantifies the financial and non-financial implications of the
investment.
Supports business decisions/select value creation opportunities by
weighing choices or options.
Creates a way to track performance and measures success after making
a decision.
Gains alignment and management consensus for a project.
The Service Level Expectations deliverable is intended to provide the definitive
description and expectations for a given service in its run state. SLEs provide
clarity to ITS staff, as well as customers and users by clearly articulating the
nature of the service and also the commitments which ITS makes in delivering
the service. This includes commitments for key service attributes such as
service availability, performance, and response times for provisioning and
support.
During the Planning Phase of a project, an initial draft of the SLE is created
andwill serve as a living document throughout the course of the project.
During the Planning Phase, focus primarily on the Service Definition section
of the template in order to describe the nature of the service, intended
consumers, value to customers, and governance roles (if known). If other
aspects of the service are known at this time (such as service details,
expectations), additional sections may be drafted as well. Changes to existing
services (if known) should be applied to the current version of the SLE during
this stage as well.
The Executive Summary is a PowerPoint presentation summarizing key
information from the Project Definition, Project Plan, and Business Case. The
Project Manager will use the Executive Summary presentation to obtain
Sponsor buy-in. All four deliverables, Project Definition, Project Plan, Business
Case, and Executive Summary, construct the Project Charter. The Sponsor signs
off on the Project Charter. Upon achieving this milestone, the project may move
forward to the Analyze/Design phase.
34
Analyze/Design
The Analyze/Design phase has the following objectives:
Understand current business processes.
Understand current technical architecture
Design future business processes.
Understand and document technical requirements
Use the business process requirements to drive out application and integration
requirements and metrics.
Create the technical architecture design to meet quality requirements, technical

constraints, and performance requirements.
Create the test approach and leverage the business requirements to start developing test
conditions and expected results.
In order for a project to exit the Analyze/Design phase, it must have:
Identified business requirements and received sign-off by the sponsor and appropriate
stakeholders.
Identified technical requirements and received sign-off by the technical domain owners.
An approved blueprint of the solution that describes how the services, components, and
support capability come together to meet objectives of the project.
An agreed-upon functional and technical design that describes how the requirements
will be satisfied.
A Project Sponsor committed and accountable to manage the cost and deliver of the
controllable benefits described in the refined business case.
Analyze/Design Deliverables
The following tables outlines the required program deliverables for the Analyze/Design phase.
Deliverable
Name & Link
to Template
Solution
Architecture
Blueprint
35
Description
The Solution Architecture Blueprint outlines the target-state of the solution,
specifically the application or service, the technology or process, and training
required to support it. The Solution Architecture Blueprint contains the design
decisions for application, process, technology, as well as training and
performance support. The solution blueprint typically does not contain detail
specification of how each piece-part works; rather it defines what technology
parts are used and how they interact.
Requirements
Traceability
Matrix
Analyze/Desi
gn Executive
Summary
Service Flow
Support Model
Updated
Service Level
Expectations
(SLE)
The Requirements Traceability Matrix captures high-level customer

requirements, stated by business representatives, customers, and other
stakeholders, which include functional, quality, interface/data, security and
control, content, technical, training, performance support, and deployment
requirements.
The Requirements Traceability Matrix is updated throughout the project lifecycle to maintain cross-references as analysis, design, build, and test
components.
information from the Analyze/Design Phase. The Project Manager will use the
Executive Summary presentation to obtain Sponsor buy-in. The Sponsor signs
off on the Executive Summary and the required phase deliverables. Upon
achieving this milestone, the project may move forward to the Build/Test
Phase.
The Service Flow deliverable presents a high-level overview of the key service
inputs, activities, and outputs in a visual diagram. The Transition Team creates
this with input from the project team members that intimately know the
Service. When complete, the diagram depicts the request fulfillment of the
service from initial order through provisioning and identifies specific steps and
roles. .
The Support Model identifies key elements that impact the overall support
strategy during both a transition and run state. Using these key elements,
various tools are leveraged that help scope the support strategy, staffing needs,
and logistics.
During Analyze/Design, the initial draft of the SLE is updated by focusing
primarily on updating the Service Definition section as needed and providing
the service details. If other aspects of the service are known at this time (such as
service expectations), additional sections may be drafted as well.
EA
Questionnaire
The EA Questionaire is a brief questionnaire to gauge the architecture

significance of the project. This deliverable will be expanded during the review
process and will be a key input into the Solution Architecture.
Information
Assurance
Questionnaire
The Information Assurance Questionnaire is used to gauge the potential

information assurance risk associated with a service project and will be used to
determine IIAs level of engagement with the project. This questionnaire should
be completed early in the lifecycle of a project, typically during the projects early
in the projects analyze/design phase, before any significant design or
architecture decisions have been made.
36
Build/Test
The objectives of the Build/Test phase are to:
Plan the testing of the product or application.
Build and test the components of the product/application.
Refine the customization, integration, and conversion of the product/service until they
are concrete and detailed enough to implement.
Prepare and execute the assembly test to ensure classes and components work correctly
when integrated into a complete application/solution.
Prepare and execute the test to ensure the solution meets the functional requirements
and that all components work together.
In order for a project to exit the Build/Test phase, it must have:
Verification and agreement by Project Sponsor that the service, component, or support
capability meets the defined requirements.
Commitment from pilot stakeholder group to participate in Service Pilot.
Actual and ETC costs within an acceptable range of tolerance from baseline.
Build Deliverables
The following tables outlines the required program deliverables for the Build portion of the
Build/Test phase.
Deliverable
Name & Link
to Template
Build
Documents
Test Approach
Production
Support Plan
Description
The program is intentionally not specific regarding this deliverable, as it varies
based on the type of service project being completed. This deliverable should
include the key the outputs of the project, and in many cases there may be more
than one. For an End User Computing deliverable, an example might be the
Windows Build Image it should be essentially whatever the project is
building during the Build/Test phase. This deliverable is called out specifically
in the methodology because it is important to track these items in the Work
Plan as they are critical path items for moving into the subsequent phases.
The first step in preparing for any test stage is to develop a test approach. This
deliverable outlines the specific test types to be performed, the scope and
objectives of each test type, a high-level schedule, the pass strategy, test
environments and any testing tools to be utilized as a part of the testing effort.
The production support plan is the authoritative document that defines how
ITS supports a service in its run state. It reinforces our commitment to adhere to
processes and procedures defined at an organizational level. It is followed by
all ITS staff.
ITS provides a pre-determined, base level of production support for all
operational services in a run state. This support is set forth in the Standard
Production Support Plan and establishes the roles and expectations critical to
37
providing all ITS users the same minimum amount of consistent, timely, and
effective service support across the organization.
Service
Capacity Plan
The Service Capacity Plan is to document assumptions and expected capacity

usage for each Service.
Service
Availability
Plan
The Service Availability Plan is to document assumptions and plans for service
availability.
Test Deliverables
The following tables outlines the required program deliverables for the Test portion of the
Build/Test phase.
Deliverable
Name & Link
to Template
Test Scenarios,
Conditions &
Expected
Results
Service Pilot &

Deployment
Plan
Build/Test
Executive
Summary
Service
Restoration
Plan
Early Life
Support Plan
38
Description
Test Scenarios are high level descriptions of functional and technical areas to be
tested. Scenarios are broken down into detailed, testable conditions and
expected results based on the requirements defined in the Requirements
Traceability Matrix. This document should be used to define all test scenarios
and conditions, and to document testing activity during the testing process. The
Scenarios, Conditions & Expected Results assists with understanding test phase
status as well as tracking the work to ensure all conditions and scripts are
completed.
The Service Pilot & Deployment Plan outlines the projects approach to the
Service Pilot and Deployment. It includes key success factors,
relationships/dependencies with other projects, the scope of the Service Pilot
and Deployment, Key Stakeholders, Implementation Risks, Key Activities and
Timelines.This deliverable should be used to help prepare for the Service Pilot
and Deployment and should be highly integrated with the Program Service
Pilot & Deployment Plan.
information from the Built/Test Phase. The Project Manager will use the
achieving this milestone, the project may move forward to the Service Pilot
Phase.
The Service Restoration Plan is a document to help establish Service Level
Expectation (SLE) compliance, Data Recovery, and Custom Significant Incident
guidelines for each service.
Early Life Support (ELS) is a time-limited, enhanced level of assistance to
ensure appropriate levels of support are provided during stabilization, issues
are addressed quickly, and knowledge transfer is occurring to the run
organization. All support staff participating in Early Life Support follow the
plan.
The objective of the Early Life Support plan is to establish specific activities to
occur that are above and beyond the standard production support plan. The
plan further establishes stabilization criteria that, once met, trigger the move to
standard production support. The plan is often considered the support plan
that is active during the pilot phase of a project.
Organizational
Readiness
Assessment
The Organizational Readiness Assessment is comprehensive analysis of the

organizations readiness to deliver and support the Service as defined in the
Service Level Expectation (SLE). It considers many factors such as security,
knowledge transfer, technology, application, monitoring as well as roles and
responsibilities. The information gathered during the assessment is
instrumental in guiding a go/delay decision.
A determination of organizational readiness is based on comprehensive factors,
including:
39
Organizational readiness to support the service

The customers ability to consume the service
Technical completeness, accuracy, and availability to deliver the service
Service Pilot
The objectives of the Service Pilot phase are:
Prepare and execute the performance test to ensure the application or service meets all
the performance-related metrics, such as response time, availability, load/throughput,
and reliability.
Test all the components of the service including the enabling shared services such as
Integrated Service Desk, Service Management Processes and Metrics, Operations and
Availability, etc.
Prepare and execute the user acceptance test to ensure the application or service meets
user expectations.
Assess whether service will scale.
In order for a project to exit the Service Pilot phase, it must have:
Verification and agreement by pilot owner that the service, component, or support
capability met the defined requirements.
Identified and dispositioned enhancement and requirements gaps, as well as have
Project Stakeholder agreement.
Updated the work plan.
Updated the cost and benefit estimates and received sign-off by the project sponsor.
Service Pilot Deliverables
The following tables outlines the required program deliverables for the Service Pilot Phase.
Deliverable
Name & Link
to Template
Service Run
Book
Service Pilot
Lessons
Learned
Final Service
Level
Expectations
(SLE)
Description
The Service Run Book is created to support the transition of a service into a
run state by providing a detailed explanation of how the service should
operate and includes step-by-step procedures, general tips, and a list of SMEs.
The Service Pilot Lessons Learned Document is meant to document key
takeways and areas of improvement in relation to the Service Pilot phase.
The final version of the Service Level Expectations deliverable is intended to
provide the definitive description and expectations for a given service in its run
state. SLEs provide clarity to ITS staff, as well as customers and users by clearly
articulating the nature of the service and also the commitments which ITS
makes in delivering the service. This includes commitments for key service
attributes such as service availability, performance, and response times for
provisioning and support.
During the Service Pilot Phase (prior to Deployment), the final version of the
SLE should be completed. All sections of the document should be completed
unless there are sections that do not apply to that service. If there is not a
40
Service Pilot, the SLE should be finalized at the end of Build before moving to
deployment.
Service Pilot
Executive
Summary
41

information from the Service Pilot Phase. The Project Manager will use the
achieving this milestone, the project may move forward to the Deploy/Run
Phase.
Deploy/Run
The objectives of the Deploy/Run phase are:
Prepare the production and operating environments for application/service roll-out to
the users and other application stakeholders.
Enable users and other stakeholders to use or support the new application/service.
Roll-out the new application/service to the deployment groups.
If applicable, identify the requirements for transferring responsibility for operating and
maintaining the application to the operating group and developing the transfer plan.
In order for a project to exit the Deploy/Run phase, it must have:
Key stakeholders, service portfolio manager, and project sponsor sign-off on the User
Acceptance Test Plan and how it is executed.
The Deployment Plan sign-off, as well as verification of service management
requirements from Service Operations leadership.
Deploy/Run Deliverables
The following tables outlines the required program deliverables for the Deploy/Run Phase.
Deliverable
Name & Link
to Template
Project
Closeout
Checklist
Description
Project Lessons
Learned
Summary
The Project Closeout Checklist is meant to verify that all documentation has
been archived appropriately and all of the appropriate tasks complete prior to
closing the project. The Key Service Document Repositoryis the where all
service information documents should be stored at the completion of a project.
Each ITS service has a section for documents providing information about that
service. The Service Owner will be the ongoing person responsible for
maintaining this repository of information about their service for reference by
all ITS staff. This is an inward facing Sharepoint site and should provide onestop stop to obtain all information about an ITS service.
TheProject Lessons Learned Document is meant to document key takeways and
areas of improvement in relation to project execution throughout the entire
project lifecycle.
Customer
Lessons
Learned
Summary
The Customer Lessons Learned Summary is intended to capture customer

feedback regarding the rollout of NextGen services. Feedback may be solicited
via survey and/or focus groups related to the rollout processes, interactions
with ITS employees, and overall satisfaction with the outcome of the rollout.
Deploy/Run
Executive
Summary

information from the Deploy/Run Phase. The Project Manager will use the
achieving this milestone, the project may close the project.
42
43

NextGen Michigan Project Management Guidebook

Uploaded by

Copyright:

Available Formats

NextGen Michigan Project Management Guidebook

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NextGen Michigan Project Management Guidebook

Uploaded by

Copyright:

Available Formats

What are the different phases of a project?

What are the different phases of a project?

What deliverables are required in the Deploy/Run phase?

What deliverables are required in the Deploy/Run phase?

University of Michigan

NextGen Michigan Program

Confidential and Preliminary. For use within University of Michigan only.

Confidential and Preliminary. For use within University of Michigan only.

The purpose of Project Management is to drive a project to a successful completion by planning,

How to get a project started?

How to obtain Sponsor sign-off?

How to manage and control project scope?

What is the interplay between project-level and program-level processes?

The Project Management Guidebook is divided into the following sections:

Program and Project Governance

Summary of Phase Gates

The Planning Phase

The Analyze/Design Phase

The Build/Test Phase

The Service Pilot Phase

The Deploy/Run Phase

Project Management Capabilities

Confidential and Preliminary. For use within University of Michigan only.

Program and Project Governance

Identify the stakeholder groups to represent in the governance organization.

Define program structure and roles.

Define the relationship between stakeholders and program/projects.

Define the process for making these decisions.

Defines deliverables to be used by the Program Governance to manage the strategic

Project Governance is a hierarchical breakdown of a project team, showing primary reporting

Type of Work Aggregate tasks with similar skill requirements.

Confidential and Preliminary. For use within University of Michigan only.

Summary of Phase Gates

Figure 1: Questions answered at each Gate.

Confidential and Preliminary. For use within University of Michigan only.

Confidential and Preliminary. For use within University of Michigan only.

Project Management Capabilities

Confidential and Preliminary. For use within University of Michigan only.

Standards in project plan

Confidential and Preliminary. For use within University of Michigan only.

Time Tracking Management

Confidential and Preliminary. For use within University of Michigan only.

Work Plan and Time Management

1. Load PMOapproved work

Figure 2: Work Plan and Time Management Workflow

Review team members time in relation to tasks,

4a. Complete time

Determine if timesheet adjustment is needed. If

Monitor project progress against baseline to ensure

Confidential and Preliminary. For use within University of Michigan only.

Determine if rework/adjustment is needed based on

6a. Scope Change

If work plan rework is need, complete a change

Planview Time Tracking Job Aid:

Program Deliverable Management

Confidential and Preliminary. For use within University of Michigan only.

Confidential and Preliminary. For use within University of Michigan only.

Service Portfolio Owner

Service Center Manager