The Issue Resolution Process in Software Project Management

The Issue Resolution Process in Software Project Management
Page content

Issue By Definition

The word “Issue” has multiple dictionary meanings ranging from Topic, Subject, Problem, Concern and so on. For this specific topic, an “issue” is meant to indicate some sort of Concern or a Problem. Why can’t we call it a Concern or a Problem? During the stages of software project execution, we come across situations which may neither be problems nor concerns but still need focus from various agencies other than the project management team. Consider the following scenarios:

  1. During requirements specification, the end-user or the customer keeps one or more requirements as TBD (To be decided – that is, it will be decided later on).
  2. During the course of project execution, the project team may find that one or more requirements are not clear, or they are ambiguous or open to multiple ways of interpretation. So, the team needs to obtain clarification from the end-user about the right interpretation.
  3. During the course of project execution, the project team may find that it may not be able to implement one or more requirements fully. They need an agreement from the end-user or customer on alternatives for implementing the requirements in question.
  4. Some approvals, or reviews, that needed to happen from the end-user or customer did not take place, or the results of such action are yet to be received by the project team.

There can be some more such situations like the above. These are referred to as “issues” in the software project parlance.

Issue Resolution Process

When taken in isolation, we hear simplistic statements like:

“If you have an issue, lift the phone and place a call. Don’t make it bureaucratic.”

If a single phone call can solve all the issues – that’s excellent. Usually, a phone call can solve only some issues – not all. The customer/end-user may need to consult their team or seniors or wait for another vendor to come up with specs. So the issue would remain pending – and sometimes, forgotten. And it may grow in size in proportion to the time it was tardy and result in a huge problem. That is the reason why a procedure or process is needed for issue resolution.

The issue resolution has three components –

  1. An Issue Register - wherein all issues raised are recorded and exchanged between the project team and the end-user or customer.
  2. Communication For Resolving the Issues - in addition to the Issue Register, emails, teleconferences, video conferences, and face-to-face meetings will assist in issue resolution.
  3. Escalation Mechanism - to raise the level when either the resolution is not forthcoming or if the resolution offered is not practical or satisfactory.

Issue Register

This is normally maintained in a spreadsheet like Excel or a software tool. An Issue Register will contain information such as:

  • Issue ID
  • Issue Description
  • Date of Raising the Issue
  • Name of the Person Raising the Issue
  • Category, if any defined of the issue
  • Description of the Resolution Offered
  • Date on which the Resolution is Provided
  • Status of the Issue (either Open or Closed)
  • Date on which it is Closed

Whenever an issue arises, it would be recorded in this register. This register is sent to the customer for resolution whenever a new issue arises or periodically (i.e., every day/week). The customer records his/her resolution against the issues raised and sends it back to the project team, normally within one business day.

The end-user or customer may also record issues, if any, from their side in the Issue Register against which the project team needs to offer resolution. Only one copy (in addition to backups) of the register is maintained and it is either with the project team or the end-user/customer at any given time. As execution progresses, the issues in the register would move to “Closed” status.

You can use this Excel 2003 version of an Issue Resolution Template or this Excel 2007 format by downloading one of them right now.

Communication for Resolving the Issues

Normally, the resolution is described in the Issue Register itself. Sometimes, the description may be large enough to warrant a separate document and in such cases, the reference to the document is recorded in the Issue Register and the document is sent to the project team. Sometimes, though, a discussion would be needed to:

  1. Explain the resolution in greater detail.
  2. Elicit details about ambiguous definition of the issue.
  3. Think aloud between both parties on the possible alternatives/approaches to resolve the issue.

In such cases, a teleconference or a videoconference may be held.

Escalation Mechanism

When the project team and the customer representative cannot agree on a resolution, either may wish to escalate the issue to a higher authority. This involves a mechanism referred to as an Escalation Mechanism. The escalation mechanism defines:

  1. The name of the person with contact details for first level of escalation – this person is concerned about the project and is one level above the interacting parties.
  2. The name of the person(s) with contact details for second and further levels of escalation, if desired. This person is normally a senior management level person but is also concerned about the project.
  3. When conflict remains, include the details of the person making the final decision.
  4. Description of circumstances when escalation can be resorted to. Such circumstances can result when one of the parties is causing unreasonable delays or unreasonably sticking to their stated positions without consideration for the other party’s limitations.
  5. The process for escalating if it must be communicated to the media (phone call, email, template / format etc.).
  6. Approvals for escalations, if any required, before escalating the issue.

Status Reporting of Issue Resolution

Normally, a summary of issues would form part of the Project Progress Report (weekly or monthly). The total number of issues raised, number of issues resolved, and total number of open issues would be reported in the Project Progress Report. Issue Status also would be reviewed and monitored, along with other aspects of the project, during the Project Progress Monitoring sessions. Issues are part and parcel of software project execution. It pays well to have a defined process for issue resolution so that all issues raised are recorded and tracked to closure.