Purpose
  • To create a documented plan providing a defined procedure for managing and resolving problems experienced during the project
Role:  Project Manager 
Frequency: Once per project (updated with each iteration, if necessary) 
Steps
Input Artifacts:    Resulting Artifacts:   
Tool Mentors:   

Workflow Details:   

In most software projects, problems usually fall into one of three categories:

Product problems  relating to requirements, design, code 
Project problems (or issues)  relating to environment, resources, schedule/budget, tools 
Process problems  relating to life cycle, methodology, quality assurance 

Often, the procedure for managing each category of problem varies, for example using different Change Control Boards, or following different procedures for implementing solutions. When this is the case, the Problem Resolution Plan should describe the process for managing each category of problem separately.

Define Problem Resolution Procedure(s) To top of page

The first step in developing your Problem Resolution Plan is to define the procedure to be followed for handling each category of problem. In the Rational Unified Process, problem management procedures are triggered:

  • in the activity Activity: Handle Exceptions & Problems, based on problems identified in a Status Assessment;
  • by the raising of Change Requests to track defects;
  • through anomalies discovered during reviews, and
  • through non-conformances raised during process audits and reviews.

Status Assessments are created in preparation for scheduled project status reviews. However, the Issues List may be updated on an unscheduled basis during the Activity: Monitor Project Status, if problems are identified that require immediate resolution.

Things to consider are:

  • Method(s) team members will use for raising the problem (e.g. identify defect, raise Change Request)
  • Who is to be involved in assessing the problem and deciding on the best approach for resolution?
  • What will be the mechanism be for implementing the chosen resolution (e.g. submitting a Change Request, raising a Work Order)?
  • How will corrective actions be verified as complete?

Select Tracking Tools and Techniques To top of page

It is important to maintain a current list or log of identified problems and their status. Different tools may be used for each problem category (e.g. a defect tracking system may be used for managing product problems, while a simple spreadsheet may be used for tracking project problems).

In this section, identify the tools, databases and files you will use for tracking problems in your project. Also, identify any particular techniques to be used. These may include techniques for:

  • Problem identification
  • Problem analysis
  • Problem prioritization
  • Verification of corrective actions

Assign Problem Management Team(s) To top of page

In most projects, problems arising in the project are reviewed on a regular basis by a "triage" team consisting of representatives from each of the project sub-teams (i.e. project management, development, testing, QA etc). The team assesses each problem in turn, and puts an action plan in place to correct the problem.

Identify in your plan, the individuals that will participate in the triage activities. If different triage teams will be used to handle the different categories of problem, identify each group separately.

You should also identify the groups or individuals who will be responsible for verifying that the corrective actions identified for each problem have been implemented.

Set Schedule for Problem Management Activities To top of page

Identify in your plan, a schedule for the regular problems management "triage" meetings.

Setting a schedule for problem management activities is important to the smooth flow of a project. This gives the project team a reliable and consistent place to raise and solve problems. An industry best practice is to have a daily "war room" first thing in the morning at which any team member may attend and identify problems for triage.



Rational Unified Process   2003.06.13