Issue Management
Because of the impact issues have on a project, product
development or ongoing service, issue management is an important aspect in any management
methodology. This issue management methodology promises to make the handling of issues a
seamless part of your larger scoped methodologies rather than a process separate from
them.
It is usually not hard for team members to identify
issues, but it is still worth having a working definition of an issue. Remember that the
more ambitious your project the more issues will arise.
Action item: The project team must be made aware of what
issues are, provide some examples, and ask other team members to provide some examples.
2. Requirements
A central repository of issue information easily
accessible to all team members, because it is good for team morale and productivity to
know that their issues are being addressed.
Action item: Choose a central repository for your
issues.
An issue manager is the person chosen to oversee all
issues. It can be the project manager, team leader or another person in a responsible
leadership position. The issue manager is responsible for making sure that there is
consistent, disciplined and continuous progress made on all issues. The issue manager is
accountable to upper management for the progress made on all issues. The issue manager
communicates issue progress to the team, upper management and all stakeholders.
Action item: Appoint an Issue Manager and notify the
issue manager of their role and responsibilities.
This issue management methodology represents best
practice for managing issues. However, the goal is to have a successful project, product
development or service, the goal is not to follow a methodology fanatically.
Action item: Adapt the methodology so your project's
success is maximized.
3. Steps
3.1 Discovery
Issues can arise at any time. When an issue is discovered
it is recorded in the central repository.
It is important to allow issues to be recorded by a broad
group of people including team members, upper management, users, customers, stakeholders,
vendors and contractors. It is important because if there are barriers to reporting an
issue then there is an increased chance that the issue will go unrecorded. You cannot
address issues that you do not know about. It is not necessary that everyone has access to
central repository, but the more you can allow the better.
Action item: Set up access to the central repository for
those people that need it.
3.2 Recording
Training people to identify issues is often unnecessary,
however getting people to record the issue in the central repository will take some
training and encouragement. For example, a team member may mention an unrecorded issue to
the project manager during a coffee break or other informal occasion, this team member
needs some encouragement to record such issues in the central repository.
For all kinds of issues, prevention is better than
correction. Also, issues tend to be less severe if they are addressed earlier rather than
later. This means that every effort should be made to report issues as soon as they are
discovered, instead of waiting for the issue to become "serious enough" before
recording it. Do not be afraid of duplicating an issue or overlapping with existing
issues, it is better than missing an issue.
A complete description of the cause of the issue should
be recorded in the central repository. Resist the temptation to describe the issue in
terms of a solution. Any implication of the issue should be recorded. Attach any
supporting documentation, screenshots, report output, faxes, error messages and other
media that describes the issue.
The person who is recording the issue can make a
recommendation for a solution, if they have one. This person should also assign the issue
if possible, even if it is only assigned to the issue manager for re-assignment.
When an issue is initially recorded it should be recorded
in the central repository with a status code that reflects the fact that it is new issue
and has not been reviewed. An attempt should also be made to categorize and rank the
severity of the issue.
Many teams describe issues in terms of the desired
solution, leaving others to deduce the actual issue. This is not best practice since it
limits the scope of possible creative solutions. As an example a badly worded issue:
"We need more people." There is no indication in this example of what the issue
actually is, so finding alternative solutions is impossible. If the example issue had been
worded as "The shipping department has swamped us with product, there is a
possibility of spoilage if we cannot get the product delivered." With the issue
worded this way perhaps the shipping department can become aware of how there actions are
causing issues down the line and adapt their actions.
3.3 Initial Review
The initial review is a triage of new issues. It is
usually performed by the issue manager or deputies who are familiar with the scope and
priorities of the project. If the team is small the entire team can meet for the review.
For each new issue the status, category and severity are reviewed and the issue assigned
to someone for action and optionally an owner is identified as follows.
Sometimes the same person who records the issue may be
doing the initial review, so these two steps can be fused into one in this situation.
3.3.1 Issue Status
A decision is made about the next state of the issue.
(The previous state was "new".) The next status of the issue reflects the nature
and timing of the action to address the issue. It is one of the following:
open: immediate action will be taken to address the issue
deferred: action will be deferred until some future time
referred: action will be taken by some other group,
probably because the issue is beyond the current scope
cancelled: no action will be taken now or in the future
3.3.2 Categorize the issue
A first attempt at categorizing the issue was made when
it was first recorded. But, now during the initial review the category can be refined.
The proper issue category is helpful when prioritizing
the resources required to address issues. It is especially useful for reporting purposes.
Action item: Discuss with the team how best to categorize
the issues you expect to get, and document the categories that will be used.
3.3.3 Rank the issue severity
The severity reflects the importance of getting the issue
resolved. Obviously, you want to direct resources at the most important issues before the
lesser ones.
Action item: Choose a small set of severity codes that
have a clear ranking. For example: Trivial, Standard, Important, Critical. Some people
prefer: Low, Medium, High, Very High.
3.3.4 Assignment
From the start, the next person to take
action on the issue must be assigned to the issue and notified.
If the issue description is incomplete, the issue can be
assigned to the appropriate party to gather the information necessary to make the issue
description clear.
Assign a person and not a group. Experience has shown
that assigning issues to individuals leads to greater accountability than assigning issues
to groups. An individual can be confronted about lack of progress, it is much harder to
confront a group of people. A group can be represented by a group leader, so you can
assign an issue to the group leader who will take action to reassign the issue to correct
group member who will actually address the issue.
3.3.5 Ownership
It should be possible to decide which stakeholder is the
owner of the issue. Having an issue owner is a way of recording who is accountable for the
issue's resolution.
Owners must review the issues they own for progress to
resolution. If the progress is not sufficient the issue manager should be told so that the
situation can be remedied.
3.4 Taking Action
The process to address an issue iterates over the
following sub-steps until the issue is resolved.
The person assigned to the issue, takes action to address
the issue.
The person assigned to the issue, documents the action
taken as an issue event in the central repository. An issue event has the person's name,
the date and a description of the action taken.
If there is documentation to support the action taken,
like a cost-benefit analysis of a proposed system change, the supporting files are
attached to the issue.
The process of finding a solution may help refine the
issue description. This refinement should be reflected in updates to the issue description
and title, as well as attaching further supporting files. It may also require that the
issue be re-categorized.
If the next iteration is the responsibility of another
person the issue is reassigned.
If the issue is resolved in this iteration, the status is
updated to reflect the fact that the issue is inactive.
3.5 Ongoing Oversight
Consistent and continuous evaluation of issues by the
issue manager and the team must take place to bring the issues to resolution. This can
take place through a periodic review of all active issues in the central repository with
the team and a separate review with the stakeholders.
Escalate issues as needed by re-assigning or by changing
issue ownership.
Report and communicate progress on all issues to upper
management and to the team, subscriptions can be used by upper management and the team to
follow progress on individual issues. This reporting can be integrated into project status
reporting.
Analyze issue progress and adapt actions. The central
repository should be able to provide feedback on how efficiently the issues are proceeding
from creation to resolution. If it is taking too long to resolve important issues, then
the issue manager must find ways to improve the turn-around time.
4. Finally
The following are a few further action items
Action item: Distribute copies of this issue management
methodology to team members and stakeholders so that everyone knows how and why issues are
managed.
Action item: Adapt and scale this issue management
methodology to suit you project's scale and quirks.
Action item: Create your central repository, and get
started today.
This issue management methodology has evolved over many
years. It evolved from experience on projects with budgets from $500,000 to $50,000,000
which had a total number of issues ranging from a few hundred issues to many thousands. In
half the cases the project team was physically dispersed in several countries.
Project Management Tutorials
Project Management Templates
Here are some Project Management templates you can get
on our partner's site.
 |
The Change
Management Kit provides the documentation required to
control changes to the scope, deliverables and resources within
the project. The Change Request template allows staff to raise a
change request within the project. |
 |
 |
The
Project Planning Kit provides you with all of the
project management templates, documents and forms required to
plan a project by helping you to schedule time, cost and
resources. |
|
 |
The
Quality Management Kit includes a suite of templates
used to assure and control the quality of deliverables within a
project. |
|
 |
Project
Initiation Kit
Start a new project by documenting a business case, undertaking
a feasibility study, defining the project scope, recruiting key
staff and locating them within a project office. |
|
 |
Project
Execution Kit
Manage time, cost, quality, change, risks and issues during the
execution of your project, as well as supplier procurement and
customer acceptance. |
|
 |
Project
Closure Kit
Helps close your project by handing over deliverables and
documentation to the customer, terminating supplier contracts
and releasing resources back to the business. |
|
|
