Issue Management Methodology for Tracking Project Issues
1. What is an Issue?
An issue is an incident, circumstance, problem or inquiry that
affects or potentially affects the timely delivery of the
project, product or service, it may also impact the quality of
deliverables and the cost of production.
Some projects are ongoing and the definition of an issue is a
little different. A help desk defines an issue as a request for
help that requires a response. A service department keeps track
of service requests as issues. A software maintenance group
tracks reports of software bugs and enhancement requests as
issues.
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. An automated central repository like Issue
Tracker[http://Issue-Tracker.GLM2.com/] is desirable because
it make the issue management and reporting much easier.
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.
The date and who created the issue should be recorded in the
central repository. This is done automatically for you in
systems like Issue Tracker[http://Issue-Tracker.GLM2.com/].
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. Issue
Tracker[http://Issue-Tracker.GLM2.com/] will automatically
notify the person assigned to the issue via email.
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.
- Some issue processes require an approval step before further
action can be taken. This approval should take the form of
signing off on a proposal. While paper based signatures are
acceptable, an automated system is better. Issue events in Issue
Tracker[http://Issue-Tracker.GLM2.com/] can by used to sign off,
since a user is required to log in to identify themselves, this
is as good as a paper signature.
- 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.
Notice that the action taken may involve reassigning the issue,
changing status, refining the issue description, changing the
category of the issue. All of these changes should be recorded
in the central repository. Changing of status, category and
severity are automatically logged for you in an automated system
like Issue Tracker[http://Issue-Tracker.GLM2.com/].
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.