Issue Resolution in Software Project Management

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 as a Problem or Concern? During 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, such as the following scenarios:

1. During requirements specification, the end-user or the customer kept 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, or partially. They need a concession 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/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.

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 – 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 waiting for another vendor to come up with specs. So the issue would be kept pending – and sometimes, forgotten. And it will grow in size in proportion to the time it was tardy and result in a huge problem, in some cases. 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 / customer.
2. Communication for resolving the issues - in addition to Issue Register, emails, tele-conferences, video conferences, face-to-face meetings to 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 /satisfactory.

These aspects are discussed in detail in the paragraphs below.

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.

click to enlarge

An Issue Resolution Template is available is both Excel 2003 and Excel 2007 format in our Project Management Media Gallery.

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.

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 needs a mechanism referred to as 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 / persons 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 in conflict, 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 of escalating including the media for communication (phone call, email, template / format etc.).
6. Approvals for escalations, if any required, before escalating the issue.

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.