Continued from page 1
3.3.1 Issue Status
A decision is made about next state of issue. (The previous state was "new".) The next status of issue reflects nature and timing of action to address issue. It is one of following:
- open: immediate action will be taken to address issue
- deferred: action will be deferred until some future time
- referred: action will be taken by some other group, probably because issue is beyond current scope
- cancelled: no action will be taken now or in future
3.3.2 Categorize issue
A first attempt at categorizing issue was made when it was first recorded. But, now during initial review category can be refined.
The proper issue category is helpful when prioritizing resources required to address issues. It is especially useful for reporting purposes.
Action item: Discuss with team how best to categorize issues you expect to get, and document categories that will be used.
3.3.3 Rank issue severity
The severity reflects importance of getting issue resolved. Obviously, you want to direct resources at most important issues before 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.
From start, next person to take action on issue must be assigned to issue and notified. Issue Tracker[http://Issue-Tracker.GLM2.com/] will automatically notify person assigned to issue via email.
If issue description is incomplete, issue can be assigned to appropriate party to gather information necessary to make 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 group leader who will take action to reassign issue to correct group member who will actually address issue.
It should be possible to decide which stakeholder is owner of issue. Having an issue owner is a way of recording who is accountable for issue's resolution.
Owners must review issues they own for progress to resolution. If progress is not sufficient issue manager should be told so that situation can be remedied.
3.4 Taking Action
The process to address an issue iterates over following sub-steps until issue is resolved.
- The person assigned to issue, takes action to address issue.
- The person assigned to issue, documents action taken as an issue event in central repository. An issue event has person's name, date and a description of action taken.
- Some issue processes require an approval step before further action can be taken. This approval should take 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 action taken, like a cost-benefit analysis of a proposed system change, supporting files are attached to issue.
- The process of finding a solution may help refine issue description. This refinement should be reflected in updates to issue description and title, as well as attaching further supporting files. It may also require that issue be re-categorized.
- If next iteration is responsibility of another person issue is reassigned.
- If issue is resolved in this iteration, status is updated to reflect fact that issue is inactive.
Notice that action taken may involve reassigning issue, changing status, refining issue description, changing category of issue. All of these changes should be recorded in 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 issue manager and team must take place to bring issues to resolution. This can take place through a periodic review of all active issues in central repository with team and a separate review with 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 team, subscriptions can be used by upper management and 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 issues are proceeding from creation to resolution. If it is taking too long to resolve important issues, then issue manager must find ways to improve turn-around time.
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 cases project team was physically dispersed in several countries.
Grant Murray is project manager and enterprise application architect specializing in technical project leadership strategy. Email [firstname.lastname@example.org] for questions or comments regarding this article, or if you require project management consulting. Issue Tracker