<Project Name>

Issue and Escalation

Process
<Insert Project Logo here>
<Month, Year>

Health and Human Services Agency, Office of Systems Integration

<Project Name>
Office of Systems Integration

Printed at 02/06/15 1:49 AM

Governance Plan
Date

Issue and Escalation Process

< Date of Document >

< Project Name>

Office of Systems Integration

Revision History
REVISION HISTORY
REVISION/WORKSITE
#
SIDdocs #2478,
3312, 3332, 3333
OSI Admin #4004

DATE OF
RELEASE
07/30/2004
02/20/2008

OWNER
SID PMO
OSI PMO

SUMMARY OF CHANGES
Initial Release

Major revisions made.

Incorporated tailoring guide
information in this template.
Assigned new WorkSite document
number.
Remove template revision history and insert Issue and Escalation Process revision
history.
Approvals
NAME

ROLE

DATE

Insert Project Approvals here.

Template Instructions:
This template offers instructions, sample language, boilerplate language, and
hyperlinks written in 12-point Arial font and distinguished by color, brackets, and
italics as shown below:
Instructions for using this template are written in purple bracketed text and
describe how to complete this document. Delete instructions from the final
version of this plan.
Sample language is written in red italic font and may be used, or modified, for
completing sections of the plan. All red text should be replaced with projectspecific information and the font changed to non-italicized black.
Standard boilerplate language has been developed for this plan. This standard
language is written in black font and may be modified with permission from the
OSI Project Management Office (PMO). Additional information may be added
to the boilerplate language sections at the discretion of the project without
PMO review.
Hyperlinks are written in blue underlined text. To return to the original
document after accessing a hyperlink, click on the back arrow in your browsers
toolbar. The File Download dialog box will open. Click on Open to return to
this document.

<OSIAdmin #259542481.doc

Issue and Escalation Process

< Date of Document >

< Project Name>

Office of Systems Integration

Table of Contents

1. INTRODUCTION.....................................................................................................1
1.1 PURPOSE....................................................................................................... 1
1.2 SCOPE........................................................................................................... 1
1.3 REFERENCES..................................................................................................1
1.3.1 Best Practices Website..............................................................................1
1.3.2 Project Issue Database..............................................................................1
1.3.3 Project Document Repository....................................................................2
1.3.4 Other References.......................................................................................2
1.4
1.5

GLOSSARY AND ACRONYMS.............................................................................2

DOCUMENT MAINTENANCE..............................................................................3

2. PARTICIPANTS ROLES AND RESPONSIBILITIES.............................................3

2.1 PROJECT DIRECTOR........................................................................................4
2.2 PROJECT MANAGER........................................................................................4
2.3 ISSUE MANAGER.............................................................................................4
2.4 PROJECT STAFF MEMBERS..............................................................................4
2.5 EXECUTIVE STEERING COMMITTEE..................................................................4
3. ISSUE AND ESCALATION APPROACH...............................................................4
3.1 IDENTIFICATION...............................................................................................5
3.2 VALIDATION AND PRIORITIZATION.....................................................................5
3.3 ISSUE ANALYSIS..............................................................................................6
3.4 TRACKING AND REPORTING.............................................................................7
3.5 ESCALATION PROCESS....................................................................................7
3.5.1 Internal Escalation Process.......................................................................8
3.5.2 External Escalation Process......................................................................8
3.6 RESOLUTION & CLOSURE................................................................................9
3.6.1 Resolution..................................................................................................9
3.6.2 Closure.....................................................................................................10
APPENDIX A: SAMPLE FORMS............................................................................A-1
APPENDIX B: SAMPLE ISSUE DATABASE INSTRUCTIONS..............................B-2
PROJECT ISSUE DATABASE................................................................................B-2
List of Figures

<OSIAdmin #259542481.doc

ii

< Project Name>

Office of Systems Integration

Issue and Escalation Process

< Date of Document >

FIGURE 1. ISSUE AND ESCALATION PROCESS FLOW CHART (SAMPLE).............................5

<OSIAdmin #259542481.doc

iii

1. INTRODUCTION
In most cases, the Issue and Escalation Process will be created during the Planning
life cycle phase. It is preferable to have this document as a stand-alone process that
is referenced by other documents to ensure a consistent approach that is
documented in only one place. The Issue and Escalation Process should be
referenced in the Communication Plan, Governance Plan, Risk Management Plan
and Master Project Plan, and may be referenced in the Interagency Agreement (IAA)
and Memoranda of Understanding (MOU).
This document does not have to be a stand-alone document; it could be an appendix
to the above referenced plans. The process may be described in a tabular format,
process flow chart or swim-lane chart format.
1.1

Purpose

This document describes the Issue and Escalation Process for the < Project Name>
Project. The purpose of the process is to ensure unanticipated issues and action
items are assigned to a specific person for action and are tracked to resolution.
However, when a resolution cannot be reached, the item should be escalated to
ensure a decision is made before it causes impact to the project. The escalation
process documents how to raise an issue to a higher-level of management for
resolution, particularly when resolution cannot be reached at the project level.
1.2

Scope

The Issue and Escalation Process identifies the procedures used to manage issues,
action items, and escalation throughout the project life cycle. The process
documents the approach to issue identification and analysis, the approach to
escalation and how resolutions are documented.
1.3

References

References should be updated to indicate the location of the projects electronic

document repository, issue tracking tool, as well as the projects hardcopy library. If
the project is using a tool to track information associated with issue and escalation
management, indicate the name and location of the tool, including any available
training materials or instructional guides.
1.3.1

Best Practices Website

For guidance on the Office of Systems Integration (OSI) issue management

methodology refer to the OSI Best Practices Website (BPWeb)
(http://www.bestpractices.osi.ca.gov).
1.3.2

Project Issue Database

The current list and status of project issues are kept in an issues database located at
< path and/or server >. The project uses < MTS II > as their issue and action item
tracking tool. User instruction guides can be found at < path and/or server >. If the

OSIAdmin 4004.doc

project is using a tool other than MTS II to track issues and action items, indicate the
name and location of the tool.
1.3.3

Project Document Repository

The project uses <Worksite> as their document repository for all project-specific
documentation. If the project is not using WorkSite, indicate the location of the
projects electronic document repository as well as the projects hardcopy library.
1.3.4

Other References

<Project Name> Communication Plan

<Project Name> Governance Plan
<Project Name> Master Project Plan
<Project Name> Risk Management Plan
1.4

Glossary and Acronyms

List only acronyms applicable to this document. If the list becomes longer than one
page, move the acronym list to the Appendix.
Action Item

BPWeb
Escalation

IAA
MOU

An assigned task (usually related to project management

concerns) assigned to a person for resolution which can be
completed and has a defined deadline for completion. Action items
may be a subset of an issue or may be a stand-alone item (e.g., an
assignment as a follow-up to a meeting discussion).
Best Practices Website http://www.bestpractices.osi.ca.gov/
An issue that is elevated to a higher level of authority. Escalation
should only occur when all avenues to resolution have been
exhausted at the lowest possible levels within the project.
Inter-Agency Agreement
Memorandum Of Understanding

OSIAdmin 4004.doc

Issue

MTS II
OSI
1.5

A point or matter in question or in dispute, or a point or matter that

is not settled and is under discussion or over which there are
opposing views or disagreements. A issue is a statement of
concern or need:
(1) whose resolution is in question or lacking agreement
among stakeholders
(2) that is highly visible or involves external stakeholders such
as requests from control agencies
(3) which has critical deadlines or timeframes that cannot be
missed
(4) that results in an important decision or resolution whose
rationale and activities must be captured for historical
purposes or
(5) with critical deadlines that may impede project progress.
An issue is a situation which has occurred or will definitely occur,
as opposed to a risk which is a potential event. Items that are
normal day-to-day tasks related to a persons normal job duties
are not considered issues or action items.
Management Tracking System II
Office of Systems Integration

Document Maintenance

This document will be reviewed annually and updated as needed, as the project
proceeds through each phase of the system development life cycle. If the document
is written in an older format, the document should be revised into the latest OSI
template format at the next annual review.
This document contains a revision history log. When changes occur, the version
number will be updated to the next increment and the date, person making the
change, and change description will be recorded in the revision history log of the
document.
2. PARTICIPANTS ROLES AND RESPONSIBILITIES
Section 2 focuses on the roles and responsibilities for the Issue and Escalation
Process, not overall roles for the project. It is quite common for multiple roles to be
assigned to a single person. Discuss the level of authority for the Issue Manager.
Indicate if the Sponsor and Prime Contractor (if applicable) participate in issue/action
item resolution or only in identification.
Discuss who has the authority to identify issues that require escalation and who
validates that the escalation is a valid course of action. Discuss who performs the
analysis of the escalation situation and develops the projects position statement.
Indicate who ultimately has the authority to resolve the item.

OSIAdmin 4004.doc

2.1

Project Director

The Project Director will participate in issue and action item resolutions. If an issue
could not be resolved at the project level, the Project Director will escalate the issue
to the Executive Steering Committee for resolution.
2.2

Project Manager

The Project Manager has overall responsibility for driving, participating, and
managing the overall issue resolution and escalation process at the project level.
The Project Manager will escalate the issue to the Project Director level for
resolution when necessary.
2.3

Issue Manager

The Issue Manager is responsible for overseeing the issue and action item
management process and for periodic reporting on issue status and process
metrics. The Issue Manager generates reports for weekly project team review
meetings. The Issue Manager also monitors due dates and escalates issues and
action items to the Project Manager, as appropriate.
2.4

Project Staff Members

Any staff member or stakeholder may generate an issue or action item. Typically,
issues and actions are only assigned to project staff to ensure proper visibility and
tracking. Other stakeholders may be asked to assist with analysis and review of
proposed issue and/or action item resolutions, when appropriate.
2.5

Executive Steering Committee

The Executive Steering Committee is a governing organization that is comprised of

members of executive level who will discuss status, issues and concerns related to
the <Project Name> project. The Executive Steering Committee will resolve
escalated issues and provide direction to the Project Director. Refer to <Project
Name> Governance Plan for list of Executive Steering Committee members.

3. ISSUE AND ESCALATION APPROACH

The issue and action item management process consists of six steps.
Identification
Validation and Prioritization
Analysis
Tracking and Reporting
Escalation (if needed)
Resolution and Closure

OSIAdmin 4004.doc

Figure 1. Issue and Escalation Process Flow Chart (Sample)

Discuss the relationship of the issue process to the escalation process. If issues and
action items are treated separately, discuss the differences in the process. Inserting
a process flowchart may be helpful to depict the overall flow and interaction with
other processes.
In the sections below, discuss required time frames and tool features as appropriate.
If there are quality checks or measures for each step, discuss these also.
3.1

Identification

Issue and action item identification occurs throughout the projects life cycle. Issues
and actions may arise from meetings, analysis, document reviews, workgroups, and
other project activities. Traditionally, either project staff members or end-users
identify most issues. Identified issues/action items are documented in meeting
minutes and entered directly into the issue tool. For more information on entering a
new issue/action item, refer to the < MTS II > user manual. If the project is using a
tool other than MTS II to track issues and action items, indicate the name and
location of the tool.
Indicate how issues and action items are identified and where or how they are
documented. For example:

3.2

Are they entered on a form before they are entered into the issue database?
If a form is used, indicate where or to whom the form is submitted.
Are issues entered directly into the database or issue tracking tool?
Who has access to the tool? (e.g., all project staff, sponsor staff, management
only, admin staff, etc.)
Validation and Prioritization

The Issue Manager reviews the issue/action item and checks the issue database to
ensure the item does not already exist, determines that the item is an issue/action
item and not a risk or change request, and ensures the desired resolution or
concern is clearly worded. If the item is determined to be invalid, the originator of the
issue/action item is notified and the item is closed in the issue database.

OSIAdmin 4004.doc

The Issue Manager discusses the new issues at the < insert meeting name >. The
manager will discuss the priority of the item, confirm the assignment, and establish a
due date. The Project Manager makes the final decision on priority, assignment, and
due dates. The Issue Manager updates the issue database with the priority and
assignment.
Indicate how issues and action items are validated, prioritized, and assigned.
Indicate who performs the validation and the criteria used for validation.
Indicate what happens if the item fails the validation check. Is the item entered
into the issue database but marked as invalid? If it was already entered in the
database, is the item deleted or marked as rejected?
Indicate who performs the prioritization and what criteria is used in the
prioritization. Describe the criteria for the priority levels. In some cases, the
priority may have been established at the meeting that originated the item.
Indicate how assignments are made and who has the authority to make the
assignment. In some cases, the assignments may have occurred at the
meeting that originated the item. Can items be assigned directly to a staff
member, or are they assigned to a functional manager who will then delegate
to the appropriate staff?
Are the priorities and assignments reviewed at a meeting or otherwise
confirmed? Discuss how staff availability and other work priorities are adjusted
or negotiated, if appropriate.
Discuss how staff is notified of their assignment and due date.
Indicate when and how the tool is updated. Indicate deadlines for process
steps (e.g., assignment must occur within two [2] business days of
identification).
3.3

Issue Analysis

The assigned staff member performs the required analysis to complete the
issue/action item. The assignee updates the issue database with periodic status at
least <weekly, biweekly >. For issues/action items requiring analysis, the assignee
determines the following:
Impacts to Project Scope
Impacts to Cost and Schedule
Impacts to Staff and Infrastructure Resources
Impacts to Sponsor, User and Stakeholder Relationships
Risks and Impacts to Existing Risks
Resolution Alternatives (Pros and Cons)
Suggested Resolution
OSIAdmin 4004.doc

The recommendation is documented in the issue database and reviewed at the

< meeting >. The <insert role> must approve the suggested resolution. If the
resolution is approved, the Issue Manager updates the issue database to reflect the
approval and the assignee is notified to begin performing the resolution.
Document how issues and action items are analyzed.
Indicate where the resulting analysis and recommendations are stored
Discuss the activities and approvals required for the analysis step. In some
cases, sponsor/stakeholder staff may need to be involved in the analysis
(indicate who makes this determination). Indicate the criteria or types of
situations that may require sponsor or stakeholder involvement.
Indicate if the issue resolution must be approved before it is performed.
Indicate who has the authority to approve the resolution and what happens if
the resolution is and is not approved.
3.4

Tracking and Reporting

The Issue Manager monitors the issue database < daily, weekly > to ensure new
issues/action items and resolved items are clearly documented. Assignees are
required to update the status of the item in the issue database at least < weekly,
biweekly >.
Indicate how issues and action items are tracked, monitored, and reported.
Discuss staffs responsibility for updating status on their assigned
issues/action items.
Discuss the Issue Managers responsibility for updating and monitoring
overall issue status.
Discuss how the Issue Manager monitors the projects overall commitment
to timely issue resolution.
Indicate what meetings are used to discuss issue status and issue process
effectiveness.
Indicate when and how the tool is updated. Indicate required status updates
(in the tool) and any automatic notifications. Indicate deadlines for process
steps (e.g., analysis must complete within 10 business days of assignment).
Indicate what triggers the resolution process.
Describe the reports and metrics used to monitor the effectiveness of the
process and the projects adherence to the process.

OSIAdmin 4004.doc

3.5

Escalation Process

The Escalation Process will be used to ensure critical issues are raised soon
enough to prevent undesirable impacts to the <Project Name> Project and to ensure
the appropriate parties are informed and involved in critical decision-making. The
Project Director, Sponsor and stakeholders shall always strive to make decisions
and address issues at the lowest possible level.
3.5.1

Internal Escalation Process

Define your <Project Name> internal escalation process.

The escalation process is invoked when a manager in one of the governance
structures determines that an issue requires escalation for resolution. The disputed
issue must be reported to the <Project Name> Director.
3.5.2

External Escalation Process

Define your <Project Name> external escalation process.

The Project Director will notify and meet with the <Project Sponsor> in order to
resolve the issue. In the event that the <Project Name> Project Director and Project
Sponsor are unable to resolve the issue, they determine the urgency of the issue
and escalate to the <Project Name> <Executive Steering Committee>.
If the issue resolution can be delayed until the next scheduled <Project Name> <
Executive Steering Committee> meeting without negative impact to the Project, or to
State and County programs, its schedule or its budget, the <Project Name> <
Executive Steering Committee> will be asked to address the issue. If timing is
critical or resolution cannot be delayed the <Project Name> < Executive Steering
Committee> members will be contacted to resolve the issue on an emergency basis.
When an item is escalated, the appropriate participants are notified by <e-mail,
meeting request, formal letter> which includes the date of the scheduled meeting.
The meeting must be scheduled within <five days> of the notification of escalation.
The notice of escalation includes a summary of the issue and the analysis of each
partys position. The participants must review the analysis prior to the scheduled
meeting. All correspondence is stored in <WorkSite> and cross-referenced to the
action item in < MTS II >.
Additional items to take under consideration:
Indicate how potential escalations are identified, documented and
communicated.
Indicate what processes or situations may trigger an escalation.
Discuss who creates the official notification letter and indicate who receives
the notice of escalation.
Discuss any required time frames and deadlines involving notifying the other
party of the escalated item. Usually the escalation meeting must be
OSIAdmin 4004.doc

scheduled within a certain number of days (not more than ten business
days) of the notification.
Indicate the impacts and considerations used to develop the projects
position based on the analysis of the situation.
Discuss how the escalation history is documented.
The following are examples of types of issues that might be escalated to the
<Project Name> < Executive Steering Committee>.

Policy Issues

Schedule

Adverse Program Impacts

Go/No-Go recommendations

Vendor Disputes

Stakeholder disagreements

Funding

Examples of Types of Escalation

3.6

Escalation will occur if at any time the necessary activities either are not
being completed or appear that they will not be completed timely, resulting
in a risk to agreed upon target dates.

Escalation will occur if at any time it appears either requirements are not
being met or cannot be met or those requirements may be contrary to
state or county expectations with regard to quality of the system and its
subsequent impact on state programs.

Escalation will occur if at any time an issue is raised for which a decision
is needed in order to continue progress on the completion of the activities.

Escalation will occur if the escalation governance structures are not able
to reach concurrence on an issue where concurrence is needed to
proceed.

Resolution & Closure

3.6.1 Resolution
The <Project Name> < Executive Steering Committee> will:

Review escalated issues and solution alternatives.

Approve or deny recommended resolutions.

Commit appropriate resources to support the resolution.

OSIAdmin 4004.doc

Provide expedited response and direction on issues which may impact the
scope or schedule of <Project Name> activities.

Additional items to consider when resolving the issue:

Discuss who facilitates or leads the escalation meeting.
Discuss how the meeting is structured (e.g., open discussion, facilitated
discussion of key points, or position-rebuttal format).
Indicate if all participants are mandatory or if a general majority or quorum
is
sufficient.
Discuss who documents the meeting minutes and when they are
distributed.
If the item is resolved at the meeting, discuss how the resolution is
documented.
3.6.2 Closure
The <Assignee, Issue Manager, PM> coordinates the implementation of the issue
resolution or completion of the assigned action item. Upon completion of the
resolution, the <Assignee, Issue Manager, PM> updates the issue database with the
final results of the resolution and closes the item in the database. Any materials
related to the resolution are stored in <WorkSite> and referenced in the issuetracking database.
Discuss the activities required to resolve and close the issue/action item. Indicate if
the assignee must report back to the managers before closing the issue, or if the
manager(s) must approve the closure. Indicate if the originator(s) of the item are
notified of the resolution and closure (either by the system or by the assignee).
Indicate when and how the tool is updated. Indicate where any associated materials
are stored. Indicate required status updates (in the tool) and any automatic
notifications. Indicate deadlines for process steps (e.g., manager must complete
review and approval of the resolution within 10 business days of completion).
Indicate if an item can be re-opened once it has been closed. Indicate if the project
allows for deferred items and how often the deferred items are reviewed or
monitored.
Discuss how the other party and appropriate project participants and stakeholders
are notified of the resolution. Discuss how the resolution is implemented and
documented. Discuss required documentation and how the issue/action item is
updated and closed.

OSIAdmin 4004.doc

10

APPENDICES

APPENDIX A: SAMPLE FORMS

< If appropriate, include sample forms which are used to document issues and
action items before they are entered into the issue database. >

<OSIAdmin 4004>

APPENDIX B: SAMPLE ISSUE DATABASE INSTRUCTIONS

< If appropriate, include sample Issue Database Instructions or screen prints here or
reference the User Guide instructions. >
PROJECT ISSUE DATABASE
The project uses < MTS II > (version x.xx), to track project issues and action items.
< MTS II > is an issue/action item tracking database designed to describe, organize,
prioritize, track and display project issues and action items. The application provides
standard database functions to add and delete issues/action items, specialized
functions for prioritizing and closing project issues/action items, as well as
maintaining a log of historical events related to a particular issue/action item.
No confidential or sensitive items are recorded in the database since the reports are
shared with control agencies and other stakeholders. Potentially confidential or
sensitive issues are reviewed with Legal, prior to them being documented.
The < OSI IT Support Staff > are responsible for administration and maintenance of
the issue tool and its associated database.
The < MTS II > User Manual is located <list location here>.
Discuss what tool is used for the projects issue database. Indicate the version used,
where the tool resides, and who is responsible for content maintenance and
technical maintenance. Do not include detailed instructions on the use of the tool,
unless they are not available in any other document.
If there are any special reports or workarounds, indicate what these are and why
they are needed.

<OSIAdmin 4004>