![](media/image1.png){width="1.20625in" height="1.20625in"}**Issue
Management Procedure**

***OETI-PMP-06***

**Environmental Protection Agency**

**Office of Enterprise Technology and Innovation (OETI)**

February 26, 2007 -- Version 1.0

Document Change History

  --------- ------------------ ---------------- -----------------------------
  Version   Date               Author           Description of Changes

                                                

                                                

                                                

                                                

                                                

                                                

                                                

                                                
  --------- ------------------ ---------------- -----------------------------

Contents

[**1.** **Introduction 1**](#introduction)

[1.1 Purpose 1](#purpose)

[1.2 Background 1](#background)

[2. Approach 2](#approach)

[2.1 Assumptions 2](#assumptions)

[2.2 Scalability 2](#scalability)

[2.3 Best Practices 3](#best-practices)

[3. Roles and Responsibilities 4](#roles-and-responsibilities)

[4. Procedure 5](#procedure)

[4.1 Process Flow Diagram 5](#process-flow-diagram)

[4.2 Steps 5](#steps)

[4.2.1 Plan Issue Management 6](#plan-issue-management)

[4.2.2 Identify Issues 6](#identify-issues)

[4.2.3 Evaluate, Assign and Log Issues
7](#evaluate-assign-and-log-issues)

[4.2.4 Identify Issue Resolution Actions
8](#identify-issue-resolution-actions)

[4.2.5 Escalate Issue 8](#escalate-issue)

[4.2.6 Implement Issue Resolution Actions
9](#implement-issue-resolution-actions)

[4.2.7 Track, Monitor and Close Issues
9](#track-monitor-and-close-issues)

[5. Considerations 10](#considerations)

[Appendix A Acronyms A-1](#acronyms)

[Appendix B Checklist for Issue Management
B-1](#checklist-for-issue-management)

[Appendix C Additional Resources C-1](#additional-resources)

[Appendix D Interface Requirements D-1](#__RefHeading___Toc157914183)

[Appendix E Issue Form E-1](#issue-form)

[Appendix F Issue Log F-1](#issue-log)

# Introduction

This document defines the process by which staff within the
Environmental Protection Agency (EPA)'s Office of Enterprise Technology
and Innovation (OETI) performs issue management activities.

## Purpose

This document defines the approach, process flow, and relevant standards
by which OETI project staff performs issue management activities and
identifies participants and their responsibilities. The purpose of this
procedure is to define steps for identifying, managing, and resolving
issues over the life of the project.

## Background

An issue is a problem that may affect a project's schedule, cost, or
overall quality. The Project Management Body of Knowledge (PMBOK®)
defines an issue as "a point or matter in question or in dispute."^1^
Issues are any active environmental factors that are contributing to the
detriment of product quality, or adversely affecting cost or schedule
milestones.

An issue is different than a risk or an action item. A *risk* is an
incident with consequences for project success that may occur in the
future while an issue is an incident that has already happened and has
immediate potential for adversely impacting the project. Although
different, risks and issues are related. Risks can become issues if the
risk is "realized." This means that the risk is no longer a possibility,
it is an actuality. Both issues and risks should be managed using a
defined process over the entire life cycle of a project. An *action
item* is a matter that requires follow-up execution and usually arises
on an *ad hoc* basis during meetings, or as a by-product of working on
another activity. An action item might be required to resolve or close
an issue but action items themselves are not necessarily issues that
need to be tracked as part of the issue management process.

Issues can be precipitated by any number of factors. Most are project
based and related to cost, scope, schedule, technology, or resources.
External factors such as legislative mandates, agency directives, or
vendor activities can also create issues for the project. Issues can
also result from performing regular project statusing activities or
other project processes such as risk and quality management. For more
information regarding these processes, refer to *PMP-04 Project
Statusing, Reporting and Forecasting Procedure*, *PMP-05 Risk Management
Procedure,* and *PMP-09 Quality Management Procedure*. As these
processes are performed, new issues are often identified since these
processes are designed to manage and control project activities and
determine if process issues exist.

# Approach

This section explains the approach used to develop the issue management
procedure. It details the assumptions, the degree of scalability of the
procedures, and the industry standards, best practices, and EPA current
practices consulted in creating this procedure.

## Assumptions

The issue management procedure assumes the following:

-   An Issue Coordinator will be appointed by the Project Manager.
    Managing the issue management process may or may not be the Issue
    Coordinator's only responsibility, depending on the size, scope, and
    complexity of the project.

-   The Issue Coordinator will maintain documents using the document
    management procedures and tools defined for the project. (See
    *PMP-12 Document Management Procedure.*)

-   A tracking tool or spreadsheet will be used to capture and track
    issues for the project.

    -   All project team members understand and accept their roles in
        the issue management process. See Section 3 for roles and
        responsibilities.

## Scalability

Issue management activities apply to all projects. The actual process
can be scaled to the size of the project. The Project Manager makes the
decision as to what extent to implement issue management as well as the
details of the process during project planning. The timing of project
planning activities is discussed in *PMP-02 Project Initiation and
Planning Procedure*. Table 2-1 below provides basic guidelines for
determining the extent to which this issue management procedure is
implemented for a given project.

Table 2-1. Issue Management Procedure Scalability Guidelines

+-------------+--------------------+-----------------------------------+
| Procedure   | Does the Procedure | Determining Procedure Scalability |
|             | Apply?             |                                   |
+-------------+--------------------+-----------------------------------+
| OETI-PMP-06 | Applies to all     | -   Procedure is scaled based on  |
| Issue       | projects           |     project size, cost, duration, |
| Management  |                    |     control over resources, use   |
| Procedure   |                    |     of new technology, number of  |
|             |                    |     stakeholders, and the         |
|             |                    |     potential business impact of  |
|             |                    |     the project                   |
|             |                    |                                   |
|             |                    | -   Large, complex or unique      |
|             |                    |     projects tend to face a       |
|             |                    |     greater number of issues and  |
|             |                    |     require more rigor in         |
|             |                    |     tracking and managing issues  |
+-------------+--------------------+-----------------------------------+

The issue management process can be informal or formal, depending on the
size, scope, and complexity of the project. Regardless of the degree of
formality adopted by a project, the process itself should be initiated
as soon as possible as issues may be identified during project
initiation. Additionally, the Project Manager should designate an Issue
Coordinator as early as possible for routine maintenance and management
of the process.

Large, complex projects and systems projects require rigorous issue
management due to the large number of issues that are typically
identified and require management and resolution over the life of these
projects. Regardless of the size of the project, the basic process
followed for issue management (described in Section 4) is the same. The
key components include identifying and resolving issues before they
cause more significant problems for the project.

## Best Practices

The OETI vision includes the employment of best practices from both
industry and the EPA. This procedure incorporates the following best
practices and existing regulations and policies:

-   **EPA regulations and standards**

```{=html}
<!-- -->
```
-   The EPA Interim Agency System Life Cycle Management Procedures.
    Available at:
    <http://intranet.epa.gov/otop/policies/Extended_InterimProcedures.pdf>

```{=html}
<!-- -->
```
-   **Federal regulations, industry standards and best practices**

```{=html}
<!-- -->
```
-   Project Management Institute, The Project Management Body of
    Knowledge *(PMBOK®)*, Third Edition. 2004.

```{=html}
<!-- -->
```
-   Software Engineering Institute (SEI) Capability Maturity Model
    Integration (CMMI), CMMI for Systems Engineering, Software
    Engineering, Integrated Product and Process Development, and
    Supplier Sourcing, Version 1.1, CMMI-SE/SW/IPPD/SS, dated March
    2002.

# Roles and Responsibilities

Table 3-1 presents the roles and responsibilities for OETI project staff
involved in issue management activities. This table lists functions or
tasks that each project role performs. While each role will be assigned
to an individual staff member, an individual may perform multiple roles
for a project.

Table 3‑2. Issue Management Roles and Responsibilities

+-------------------+--------------------------------------------------+
| Role              | Responsibilities                                 |
+-------------------+--------------------------------------------------+
| **Project         | -   May be part of the issue escalation process  |
| Sponsor**         |                                                  |
|                   | -   Identifies issues                            |
+-------------------+--------------------------------------------------+
| **Project         | -   Participates in issue planning and           |
| Manager**         |     implementation                               |
|                   |                                                  |
|                   | -   Assigns role of Issue Coordinator            |
|                   |                                                  |
|                   | -   May be part of the issue escalation process  |
|                   |                                                  |
|                   | -   Identifies issues                            |
|                   |                                                  |
|                   | -   Assists with identification of issue         |
|                   |     resolutions                                  |
|                   |                                                  |
|                   | -   Approves issue resolution actions and        |
|                   |     priorities                                   |
|                   |                                                  |
|                   | -   Assigns issue to Project Team Lead or        |
|                   |     project member for resolution, as required   |
|                   |                                                  |
|                   | -   Reviews issues and status of resolution      |
|                   |     actions on a regular basis                   |
+-------------------+--------------------------------------------------+
| **Project Team    | -   Participates in issue planning and           |
| Lead**            |     implementation                               |
|                   |                                                  |
|                   | -   Identifies issues                            |
|                   |                                                  |
|                   | -   Researches and clarifies issues as needed    |
|                   |                                                  |
|                   | -   Evaluates proposed issues and actions and    |
|                   |     identifies alternate resolutions             |
|                   |                                                  |
|                   | -   Makes priority recommendation                |
|                   |                                                  |
|                   | -   Identifies where added tasks fit into        |
|                   |     project plan, if applicable                  |
|                   |                                                  |
|                   | -   Works with Issue Owner to estimate time and  |
|                   |     resources required to resolve the issue      |
|                   |                                                  |
|                   | -   Assigns issue to team member for resolution  |
|                   |     as appropriate                               |
|                   |                                                  |
|                   | -   Reviews team issues and status of resolution |
|                   |     actions on a regular basis                   |
+-------------------+--------------------------------------------------+
| **Issue           | -   Identifies issues                            |
| Originator**      |                                                  |
|                   | -   Documents the issue as clearly and           |
|                   |     completely as possible on the Issue Form     |
|                   |                                                  |
|                   | -   Submits Issue Form to Issue Coordinator      |
+-------------------+--------------------------------------------------+
| **Issue Owner**   | -   Responsible for identifying the issue        |
|                   |     resolution action(s)                         |
|                   |                                                  |
|                   | -   Responsible for determining needed course of |
|                   |     action for issue (escalation, change         |
|                   |     control, implementation)                     |
|                   |                                                  |
|                   | -   Provides feedback and updates to Issue       |
|                   |     Coordinator and other staff as necessary     |
+-------------------+--------------------------------------------------+
| **Issue           | -   Logs issue into issue database and assigns   |
| Coordinator**     |     issue number                                 |
|                   |                                                  |
|                   | -   Tracks status of issue in the Project Issue  |
|                   |     Log and issue database                       |
|                   |                                                  |
|                   | -   Clarifies issue if necessary                 |
|                   |                                                  |
|                   | -   Forwards Issue Log, which includes           |
|                   |     information on the issue, impact analysis,   |
|                   |     and recommendation to assigned team          |
|                   |     member(s) for resolution and to necessary    |
|                   |     management                                   |
|                   |                                                  |
|                   | -   Sends weekly updated Issue List to the       |
|                   |     Project Team Leads and Project Manager       |
+-------------------+--------------------------------------------------+

# Procedure

This section presents the process flow for issue management and
describes each step of the process in detail.

## Process Flow Diagram

Figure 4-1 depicts the process for issue management and the activities
to be performed. This process originates with defining the
implementation of the issue management process as described in *PMP-02
Project Initiation and Planning Procedure*. This process may also be
triggered by risks that are realized and become issues as described in
*PMP-05 Risk Management Procedure*. The identification of issues in the
course of project statusing activities as described in *PMP-04 Project
Statusing, Reporting and Forecasting Procedure* or quality assurance
activities as described in *PMP-09 Quality Management Procedure* can
also trigger the process. The process continues from issue
identification through the implementation of resolution actions and
issue closure.

Figure 4‑1. Issue Management Process

## Steps

The following sections describe the steps of the issue management
process shown in Figure 4-1 and the roles involved with its execution.

### Plan Issue Management

The Project Manager, with the help of Project Team Leads, defines the
issue management process during the planning activities detailed in
*PMP-02 Project Initiation and Planning Procedure* and documented in the
Project Management Plan. For larger, more complex projects, the Project
Manager may consider developing a separate Issue Management Plan (see
examples at links found in Appendix C). However, it is important to
define and communicate the scope and details for regular issue
management early in project planning activities, whether in a separate
plan or as part of the Project Management Plan. The Project Manager
works with Project Team Leads to define issue management activities that
include the following:

-   Define/develop a form for capturing issues

-   Identify the tool used to capture issues for the project

-   Obtain any necessary software needed to manage issues

-   Define the process for identifying issues and submitting the issues
    for review

-   Define the process for identifying and implementing issue
    resolutions

-   Define the scale for prioritizing issues and special considerations
    for high priority items

-   Assign an Issue Coordinator (if required based on the size and
    complexity of the project)

-   Define roles and responsibilities for the issue management process

-   Define the issue escalation process to address issues that the
    project team may not have authority or the resources to resolve

-   Define the frequency for distribution of issue logs, issue updates
    and issue meetings and/or coordination with other procedures such as
    *PMP-04 Project Statusing, Reporting and Forecasting Procedure*

    -   Communicate the issue management process to the team and provide
        training as needed (based on size of project, number of
        resources ad extent of process). Determine the frequency of
        subsequent training sessions if new resources join the project
        on a regular basis.

To manage issues effectively, all members of a project, including the
stakeholders, should be aware of the process for identifying and
submitting issues. Once the process is defined, the Project Manager,
Project Team Leads, and Issue Coordinator communicate to the team the
process for submission and management of issues.

### Identify Issues

The Issue Originator (who can be anyone on the team or involved with the
project) identifies an issue through multiple activities. These include
the following:

-   Daily project activities

-   Project status and reporting activities and analysis (Refer to
    *PMP-04 Project Statusing, Reporting and Forecasting Procedure* for
    more details)

-   External and internal environmental factors (such as budget changes,
    new legislation, etc.)

-   Issue resolution meetings and analysis

-   Realization of known risks

    -   Results or output of other project processes (such as quality
        assurance metrics or results)

The Issue Originator should document the issue as soon as it is known.
This involves completing the project Issue Form (an example form is
found in Appendix E) and submitting it to the Issue Coordinator.
(Smaller projects may simply require identification and documentation of
the issue by the Issue Originator without any routing.) The Issue Form
contains the following items to be completed by the Issue Originator:

-   Project Name

-   Prepared By

-   Date (Prepared)

-   Date Resolution Needed

-   Attachments -- Any supporting documentation needed to evaluate or
    confirm the issue should be attached to the form

-   Issue Description -- Provide a detailed description of the issue and
    the circumstances through which it was identified

-   Priority (if known by Issue Originator at time of form completion)
    -- A priority for the issue based on its impact to the project is
    assigned

    -   Recommendation Status (if known by Issue Originator at time of
        form completion)

The Issue Originator completes these sections of the form but may or may
not have the information needed to complete the Priority and Issue
Resolution Action section of the form. The Issue Resolution Action
section of the Issue Form is finalized in Section 4.2.4, given the
proposed issue is determined to be a valid project issue in section
4.2.3. The Issue Originator submits the Issue Form to the Issue
Coordinator.

### Evaluate, Assign and Log Issues

The Issue Coordinator receives the Issue Form and determines if the
identified issue should be classified as a project issue, a project
risk, or a non-issue. If it is a project risk, the Issue Coordinator
forwards the item to the Risk Coordinator, in accordance with *PMP-05
Risk Management Procedure.* If, after examining the item, it is
determined that no issue needs to be created, then the Issue Coordinator
notes the explanation in the Reviewer Comment section of the Issue Form
and notifies the Issue Originator of the disposition of the submitted
issue. If the proposed issue is determined to be an issue and is not a
duplicate of an existing issue, it should be logged as an issue and
tracked through closure.

Once determined to be a project issue, the Issue Coordinator works with
the appropriate Project Team Lead or Project Manager for review and to
assign the Issue Owner, based on the severity and subject matter of the
issue. The assigned Issue Owner evaluates it for potential impact to the
project, giving it a priority rating or confirming the assigned rating.
The priority rating is dependent on potential impact to the project and
is rated on a scale of 1 to 3, with 3 representing an issue with the
highest severity and negative consequences for the project.

> 3 = High -- a significant event or problem that has occurred; the
> issue has a measurable impact on cost, schedule, or overall project
> quality and is such that the response necessary to resolve the issue
> must be determined as soon as possible. Without an immediate
> resolution, one or more tasks or activities may not be able to proceed
> and there is likely to be an impact to activities on the critical
> path.
>
> 2 = Intermediate -- a moderate event or problem that may have an
> impact on cost, schedule, or overall project quality but not in the
> immediate future. The issue is such that the response necessary to
> resolve the issue must be determined within one month or the impact is
> likely to be more significant and the issue could become a "high"
> priority.
>
> 1 = Low -- a minor event or problem that has minimal or no impact on
> cost, schedule, or overall project quality and is such that the
> response necessary to resolve the issue does not need to be determined
> within one month.

High priority issues require immediate resolution. These issues have a
definite and measurable impact on project scope, schedule, or cost if
not resolved quickly. The resolution for a high priority issue typically
focuses on reducing or minimizing the impact of the issue. Because these
issues generally receive immediate attention, there is sometimes a
tendency to label issues as "high" priority when they are not. The Issue
Owner and Issue Coordinator, as applicable, have responsibility for
ensuring that issues are classified appropriately. Likewise, "medium"
and "low" priority issues should be assigned and managed carefully as
they may become more significant if ignored or if actions are delayed.

The Issue Owner is responsible for the issue until it is resolved or
reassigned to another team member. While responsibility may lie with one
individual for tracking purposes, many Project Team Members may have
responsibilities related to the resolution of the issue. The Issue Owner
has overall responsibility for recommending the corrective action(s)
necessary to address the issue (see section 4.2.4) and implementing and
reporting on status of the action(s).

The Issue Coordinator checks for duplicates, assigns a unique numerical
identifier, and then enters the issue in the Issue Log. The Issue Form
is returned to the Issue Originator if there are any items missing or if
the issue is a duplicate.

### Identify Issue Resolution Actions

The Issue Owner explores action(s) to resolve the issue and follows up
with Project Team members and the Issue Originator, if necessary. When
identifying resolution actions, a special focus is placed on the
resources required to resolve the specific issue and the impact to the
project schedule. See *PMP-03 Schedule and Cost Baseline Procedure* for
information about estimating costs and impacts to the schedule.
Depending on the project schedule and resource availability, it may be
necessary to re-plan activities to address the pending issue or to route
a resolution action through the change control process as described in
*PMP-08 Change Control Procedure*. If the issue requires a decision or
action by senior management, the issue may need to be escalated.

Once the action plan for resolution has been designed and the Issue Form
updated, it is submitted to the Issue Coordinator to incorporate into
the Issue Log.

### Escalate Issue

In the event that the team cannot resolve an issue without assistance
from more senior leader(s), the team should follow the defined
escalation process (see the Project Management Plan). The escalation
process allows for progressive tiers of management to provide input into
the resolution of an issue until a successful resolution and/or action
item is identified. For this process step, the path of escalation should
be implemented as follows:

-   Project Team Lead

-   Project Manager

-   System or Project Sponsor

-   Senior Manager or other agency official of equal or higher authority

    -   External government authority

The Project Manager escalates the issue to the appropriate level needed
to facilitate its resolution or provide the needed approval. This
process differs from the change control process in that the escalation
process is used to make a selection among multiple resolution options,
to approve courses of action, and to negotiate with other senior
managers within the organization or external vendors on behalf of the
project. The project team also uses the escalation process when a
specific action, beyond approval or review, is needed from senior
management in order to resolve the issue or proceed to the next step of
the issue resolution.

Based on the identification of the issue resolution approach, the Issue
Owner works with the Project Manager to determine if any proposed
process improvement(s) should be processed through the Change Control
Process defined in *PMP-08 Change Control Procedure*. For those with
measurable cost, schedule, or resource requirements for implementation,
the Project Manager or designated Project Team Lead completes a change
request (CR) for review and approval.

### Implement Issue Resolution Actions

The Issue Owner and/or other project team members assigned to resolve
the issue implement the resolution action items according to the defined
approach. The Issue Owner will maintain the Issue Resolution Action Plan
and provide the Issue Coordinator with a summary action plan status
according to the process described in the Project Management Plan (see
*PMP-02 Project Initiation and Planning Procedure*). The Issue Owner
will pay special attention the Expected Resolution Date in the log, and
may submit a risk if evidence exists that the milestone will not be met.
If conflicting events derail the successful implementation of a
resolution action, the project may follow the Escalate Issue step.

### Track, Monitor and Close Issues

The Issue Coordinator receives the update on the issue from the Issue
Owner and updates the issue status in the issue tracking system. The
Issue Coordinator distributes the Issue Log (see Appendix F) based on
the frequency and distribution defined during project planning.[^1] This
distribution is usually coordinated with project status meetings.
Alternately, the project team may choose to implement a centralized
issue logging tool to ensure constant availability of project issues to
all stakeholders. The Issue Coordinator works with the Issue Owner(s) to
ensure that the log is kept up-to-date with entries to the Status of
Action Plan To Resolve Issue column on the Issue Log. The Issue Owner
provides status updates on the issue to the Issue Coordinator via email,
phone, or meetings at the intervals defined during the planning process.
For large complex projects, weekly updates are often necessary. Smaller
projects may require less frequent updates. Issues are discussed on a
regular basis, typically during project status meetings.

When the Issue Owner has indicated that the resolution action has been
successfully implemented, the Issue Coordinator will note the date in
the Date Resolved field of the Issue Log (Appendix F) and the issue is
closed. Effort required to implement the resolution action should be
captured as appropriate.

# Considerations

The following list provides general best practices that should be
considered when conducting issue management activities:

-   Start the issue management process as early as possible for the
    project so that issues identified during project initiation are
    tracked and managed in a timely fashion.

-   In many cases items that are classified as issues are really action
    items. Action items are areas that must be followed up on at some
    time. They may or may not involve problems for the project. Maintain
    a separate Action Items listing as part of Project Team, Steering
    Committee, Reference, and Working Group meetings. The important
    thing is to record them somewhere and track their status.

-   If appropriate, establish and use an automated tool to store and
    track issues. An Issue Log that is manually distributed may not be
    as readily available to the entire team whereas an electronic tool
    can facilitate distribution, proactive communications, and
    involvement of key stakeholders. A tool or spreadsheet is useful for
    maintaining the history of all project issues and actions over time.

-   Not all issues are high priority. The project team should avoid the
    tendency to label all issues as high priority. As the implementation
    of resolution actions for high priority issues generally require
    immediate attention, the team should follow the definitions
    carefully.

-   If a large issue looks too difficult to be resolved in a timely
    manner, break it down into logical sub-issues.

-   Resolve issues at the lowest level within the project team as
    possible.

-   Search for a root cause when several issues are reported together in
    a very short time period. These issues may stem from a common
    problem. Addressing this problem may resolve many issues at the same
    time.

-   All project issues identified for a phase should be addressed or
    resolved prior to completing the phase and moving to a new phase of
    the project. The same is true for the end of the project. If the
    issue cannot be successfully resolved, the reason should be
    documented as part of the project records.

    -   The Project Manager or Issue Coordinator may periodically review
        issues to determine if the same type of issues are recurring on
        a regular basis or originating from the same source. This may be
        indicative of a quality issue and the team will want to take
        actions to prevent any continued recurrences.

###### Acronyms

The following acronyms shown below are used in this document.

  -------------- -----------------------------------------------------------
  Abbreviation   Description

  **CMMI**       Capability Maturity Model Integration

  **CR**         Change Request

  **EPA**        Environmental Protection Agency

  **OETI**       Office of Enterprise Technology and Innovation

  **PMBOK®**     Project Management Body of Knowledge

  **SEI**        Software Engineering Institute
  -------------- -----------------------------------------------------------

###### Checklist for Issue Management

The following table provides a checklist for the key activities
associated with each step of this issue management procedure.

+-----------------------------------------------+----------------------+
| Activities                                    | Responsible Parties  |
+===============================================+======================+
| 4.2.1 Plan Issue Management                   |                      |
+-----------------------------------------------+----------------------+
| -   **The scope of the issue management       | **Project            |
|     process is defined and documented in the  | Manager/Project Team |
|     Project Management Plan**                 | Leads**              |
|                                               |                      |
| -   **The issue management process and        |                      |
|     details are defined and documented in the |                      |
|     Project Management Plan**                 |                      |
|                                               |                      |
| -   **An issue escalation process is          |                      |
|     defined**                                 |                      |
|                                               |                      |
| -   **Roles and responsibilities for the      |                      |
|     issue management process are defined**    |                      |
|                                               |                      |
| -   **Issue management process is             |                      |
|     communicated to the project team**        |                      |
+-----------------------------------------------+----------------------+
| -   **The Issue Coordinator is assigned**     | **Project Manager**  |
|                                               |                      |
| -   **The Issue Form and Issue Log are        |                      |
|     designed and locally available to project |                      |
|     team members**                            |                      |
+-----------------------------------------------+----------------------+
| 4.2.2 Identify Issues                         |                      |
+-----------------------------------------------+----------------------+
| -   **Issue is identified**                   | **Issue Originator** |
|                                               |                      |
| -   **Issue is documented using the Issue     |                      |
|     Form**                                    |                      |
|                                               |                      |
| -   **All applicable fields on the Issue Form |                      |
|     are complete and accurate**               |                      |
|                                               |                      |
| -   **A 'Date Resolution Needed' is           |                      |
|     determined, if known**                    |                      |
|                                               |                      |
| -   **Issue is routed to the Issue            |                      |
|     Coordinator**                             |                      |
+-----------------------------------------------+----------------------+
| 4.2.3 Evaluate, Assign and Log Issues         |                      |
+-----------------------------------------------+----------------------+
| -   **Issue is reviewed based on subject      | **Issue              |
|     matter and severity**                     | Coordinator**        |
|                                               |                      |
| -   **Issue is routed to Project Manager or   |                      |
|     Project Team Lead for assignment**        |                      |
+-----------------------------------------------+----------------------+
| -   **Issue is reviewed**                     | **Project            |
|                                               | Manager/Project Team |
| -   **Issue is assigned to appropriate team   | Leads**              |
|     member for resolution**                   |                      |
|                                               |                      |
| -   **Issue Form is forwarded to assigned     |                      |
|     Issue Owner**                             |                      |
+-----------------------------------------------+----------------------+
| -   **Issue is reviewed and assigned a        | **Issue Owner**      |
|     Priority rating**                         |                      |
+-----------------------------------------------+----------------------+
| -   **Issue is reviewed by Issue Coordinator  | **Issue              |
|     and checked for duplication**             | Coordinator**        |
|                                               |                      |
| -   **Issue number is assigned to issue**     |                      |
|                                               |                      |
| -   **Issue is entered into Issue Log**       |                      |
+-----------------------------------------------+----------------------+
| 4.2.4 Identify Issue Resolution Actions       |                      |
+-----------------------------------------------+----------------------+
| -   **Resolution action is identified**       | **Issue Owner**      |
|                                               |                      |
| -   **Next course of action (escalation,      |                      |
|     change control etc.) is determined**      |                      |
|                                               |                      |
| -   **Resolution is analyzed for re-planning  |                      |
|     implications, if any**                    |                      |
|                                               |                      |
| -   **Resolution action is routed through     |                      |
|     change control process, as required**     |                      |
|                                               |                      |
| -   **Resolution action is communicated to    |                      |
|     Issue Coordinator/Project Team**          |                      |
+-----------------------------------------------+----------------------+
| -   **Resolution action is approved to        | **Project Manager,   |
|     implement**                               | Change Control Board |
|                                               | as required**        |
+-----------------------------------------------+----------------------+
| 4.2.5 Escalate Issue                          |                      |
+-----------------------------------------------+----------------------+
| -   **Issue is escalated as needed**          | **Project Team Lead, |
|                                               | Project Manager**    |
+-----------------------------------------------+----------------------+
| -   **Resolution action proceeds once         | **Project Manager,   |
|     escalation action is addressed**          | Project Sponsor,     |
|                                               | Senior Management**  |
+-----------------------------------------------+----------------------+
| 4.2.6 Implement Resolution Actions            |                      |
+-----------------------------------------------+----------------------+
| -   **Resolution action is implemented**      | **Issue Owner,       |
|                                               | Project Team Members |
|                                               | (as needed)**        |
+-----------------------------------------------+----------------------+
| 4.2.7 Track, Monitor and Close Issues         |                      |
+-----------------------------------------------+----------------------+
| -   **Regular opportunities to review and     | **Project Manager**  |
|     discuss Issue Log with Project Team are   |                      |
|     provided**                                |                      |
+-----------------------------------------------+----------------------+
| -   **Status of resolution action is          | **Issue Owner**      |
|     reported**                                |                      |
+-----------------------------------------------+----------------------+
| -   **Resolution action is identified as      | **Issue Owner,       |
|     successful in addressing issue**          | Project Manager**    |
+-----------------------------------------------+----------------------+
| -   **Issue Log is updated regularly**        | **Issue              |
|                                               | Coordinator**        |
| -   **Issue Log is distributed to Project     |                      |
|     Team in advance of statusing activities** |                      |
|                                               |                      |
| -   **Issue closed and status updated**       |                      |
+-----------------------------------------------+----------------------+

######  Additional Resources

The following provides a list of key resources and references associated
with the issue management procedure that can be used to obtain
additional background information, describe concepts and methodologies,
and assist in completion of the activities.

+---+-------------------+----------------------+----------------------+
|   | Form/ Guidance    | Source               | Website              |
+===+===================+======================+======================+
| * | **Issue           | **State of           | [**htt               |
| * | Management Plan   | Washington**         | p://isb.wa.gov/tools |
| 1 | Example and       |                      | /pmframework/plannin |
| . | Template**        | **Department of      | g/issuemgmt.aspx**]( |
| * |                   | Information          | http://isb.wa.gov/to |
| * |                   | Resources**          | ols/pmframework/plan |
|   |                   |                      | ning/issuemgmt.aspx) |
+---+-------------------+----------------------+----------------------+
| * | **Issue           | **Commonwealth of    | [**http://           |
| * | Management        | Virginia**           | www.vita.virginia.go |
| 2 | Document**        |                      | v/projects/cpm/templ |
| . |                   |                      | ates/issue-managemen |
| * |                   |                      | t-document.doc**](ht |
| * |                   |                      | tp://www.vita.virgin |
|   |                   |                      | ia.gov/projects/cpm/ |
|   |                   |                      | templates/issue-mana |
|   |                   |                      | gement-document.doc) |
+---+-------------------+----------------------+----------------------+
| * | **Sample Issue    | **Ohio State         | **ht                 |
| * | Log**             | University**         | tp://oit.osu.edu/pro |
| 3 |                   |                      | jmanage/PDF_files/P_ |
| . |                   | **Office of the      | IssuLog_T_1.00.pdf** |
| * |                   | CIO**                |                      |
| * |                   |                      |                      |
+---+-------------------+----------------------+----------------------+
| * | **General         | **University of      | [**http://ww         |
| * | Guidance on Issue | Manchester, UK**     | w.itservices.manches |
| 4 | Management**      |                      | ter.ac.uk/isprogramm |
| . |                   | **Tasmanian State    | e/specialistareas/is |
| * |                   | Government,          | sues_detailed_page.h |
| * |                   | Australia**          | tml**](http://www.it |
|   |                   |                      | services.manchester. |
|   |                   | **State of           | ac.uk/isprogramme/sp |
|   |                   | Pennsylvania**       | ecialistareas/issues |
|   |                   |                      | _detailed_page.html) |
|   |                   |                      |                      |
|   |                   |                      | [**http://ww         |
|   |                   |                      | w.projectmanagement. |
|   |                   |                      | tas.gov.au/guideline |
|   |                   |                      | s/pm6_7.shtml**](htt |
|   |                   |                      | p://www.projectmanag |
|   |                   |                      | ement.tas.gov.au/gui |
|   |                   |                      | delines/pm6_7.shtml) |
|   |                   |                      |                      |
|   |                   |                      | **http://www.oit.    |
|   |                   |                      | state.pa.us/oaoit/cw |
|   |                   |                      | p/view.asp?a=671&q=1 |
|   |                   |                      | 93322&oaoitNavDLTEST |
|   |                   |                      | =%7C8433%7C8790%7C** |
+---+-------------------+----------------------+----------------------+

###### Interface Requirements

The purpose of this appendix is to provide general guidelines for
collecting the appropriate information from contractors to ensure
seamless integration of project issues and resolutions and promote
efficient monitoring of the overall project. Frequently, data is needed
from support contractors to enable the Project Manager to assess
real-time status accurately against overall performance, schedule, and
cost objectives. In addition, defined interface points ensure that both
the government and contractor understand their specific roles and
responsibilities in issue management and that the information can be
efficiently captured using the project's established management
processes and tools. As a result, the data, reporting, and interface
requirements should be well defined early in the process to ensure that
they are fully described in the awarded contract. For issue management,
these requirements may include the contractor's role in the issue
management process or required inputs to the process.

The following series of questions is provided to help determine the
issue management interface requirements appropriate for a specific
project. Requirements may vary significantly depending on the scope,
complexity, size, and duration of the project and type of contracts
awarded. Overall, the questions are designed to help refine what kind of
information will be needed to ensure effective issue management of the
project and to define the correlating responsibilities of the
contractor.

-   Will the contractor be able or required to identify and submit issue
    forms?

    -   What level of detail is needed on the issue form?

    -   What data elements must be provided?

    -   Will the contractor need training or guidance on how to submit
        an issue?

    -   Will the contractor need access to a specialized tool or site
        for accessing and submitting issues?

    -   Will the contractor be required to obtain approval for the issue
        prior to submission?

    -   Will the contractor be required to submit documentation to
        support (such as cost and schedule impacts) the issue?

-   Will the contractor be required to act as an Issue Coordinator or
    Issue Owner?

-   Does the contractor have specific subject matter expertise that may
    require their participation in issue resolution actions?

-   Will the contractor have a role in the issue escalation process?

-   Will the contractor be evaluated based on ability to identify and
    resolve project issues?

-   How will the contractor be involved in issue communication and
    statusing activities?

-   Will the contractor be required to identify internal issues that may
    impact overall project performance?

###### Issue Form

This appendix provides a project Issue Form that may be used and/or
tailored as appropriate according to project needs.

**Project Issue Form**

Project Name: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Issue
Number: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ (Assigned by Issue Coordinator)

Prepared by: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Date Issue Logged: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Details

+-----------------------------------------------------------------------+
| Date Resolution Needed:                                               |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\                           |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| Proposed Owner:                                                       |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\                   |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| Attachments (if                                                       |
| any):\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\              |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| Reviewer: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_Reviewer    |
| Completion Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_         |
|                                                                       |
| Reviewer Comments:                                                    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\                     |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| \_\_\_\_\_\_\_\_                                                      |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
+-----------------------------------------------------------------------+

Issue Description:

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

***Priority determined by Impact to Project*** (if not resolved):

  -----------------------------------------------------------------------
  Potential Priority: □ High □ Medium □ Low

  -----------------------------------------------------------------------

***Recommended Resolution Action:***

+-----------------------------------------------------------------------+
| Resolution Action Assigned to:                                        |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_Organization:               |
| \_\                                                                   |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| Recommended Resolution                                                |
| Act                                                                   |
| ion:\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_                    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_                    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
|                                                                       |
| Final Planned Completion Date:                                        |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\                             |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
+-----------------------------------------------------------------------+

*Detailed Resolution Action Steps*

  ----------------------------------- -------------------- ---------------
  *Action Step*                       *Responsibility*     *Target
                                                           Completion
                                                           Date*

                                                           

                                                           

                                                           

                                                           
  ----------------------------------- -------------------- ---------------

*Cost/Schedule Impact Analysis Required?* □ Yes □ No

  ----------------------------------- -----------------------------------
  *Resources Required*                *Work Days/Costs*

                                      

                                      

                                      

                                      
  ----------------------------------- -----------------------------------

***Recommendation Status (check one)***

**□** Accept □ Defer □ Need Additional Info. □ Reject

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Project Manager

Comments:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

***Management Action (if required as part of escalation)***

  ----------------------- ------------------------------- ----------------
  **Name/Title**          **Action Requested**            **Date**

                                                          

                                                          
  ----------------------- ------------------------------- ----------------

###### Issue Log

This appendix provides a project Issue Log that may be used and/or
tailored as appropriate according to project needs. The format and
number of fields included in the Issue Log can be modified based on the
size, scope and complexity of the project as well as specific
requirements for tracking certain data items for each issue.

  ------- ------- ---------- ------------ ----------- ----------- ---------- ------------ ---------- ---------
  Issue   Issue   Priority   Originator   Issue       Action Plan Assigned   Resolution   Date       Status of
  No.     Date                                        Summary     To         Date Needed  Resolved   Action
                                                                                                     Plan To
                                                                                                     Resolve
                                                                                                     Issue

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     

                                                                                                     
  ------- ------- ---------- ------------ ----------- ----------- ---------- ------------ ---------- ---------

**Priority Codes**

3 -- Highest impact on cost, schedule, or overall project quality within
one week or impact to critical path work

2 -- Moderate impact on cost, schedule, or overall project quality
within one month

1 -- Lowest impact on cost, schedule, or overall project quality beyond
one month

[^1]: Since issues of the highest priority require an immediate
    corrective action response, the Project Issue Log should be
    distributed with a defined frequency that allows for timely analysis
    and corrective action response.