Explain the use of an Issue Log/Register

Home Forums APM PMQ Study Group Explain the use of an Issue Log/Register

This topic contains 0 replies, has 1 voice, and was last updated by  Paul Naybour 8 months, 3 weeks ago.

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #16990

    Paul Naybour
    Moderator

    A typical APM PMQ exam question might be

    Part A Explain the use of an Issue Log/Register
    Part B List and describe four essential items of information that should be included in an issue
    log/register

    A typical answer might be:

     

    A) An issue log is a record of the issues that have occurred on the project. Typically is it maintained by the project manager and includes those things that are having a significant impact on the likely project outcome. So, for example, the on-going poor performance by a contractor or the inability of the users to clarify their requirements could all be issues. It’s important to record and highlight these sorts of issues because they are often beyond the ability of the PM to resolve. For this reason, we escalate issues to the next level of management. Typically this will be the sponsor, but in a contracting organisation, this could be senior management. The aim is the get the support of senior management in resolving the issue.

    B) Five typical items in an issue log include:

    1. ID number for the issue.
    2. Description of the issue.
    3. Who raised the issue.
    4. The impact of the issue.
    5. Status of the issue.
    1. It’s important to identify each issue with a unique ID number. This prevents duplication and means that the issue can be tracked effectively as it matures. It may be that as more information emerges, we discover more about the issue and want to refine the description. By maintaining a unique ID we can track the history of the issue through various issue logs.
    2. The description of the issue need to be comprehensive. It should summarise the cause of the issue and the impact on the project. So for “example lack of resources” would be a poor description. A better description would be “a lack of testing resources will introduce a 6-week delay on the project”. This more detailed description is much more likely to stimulate action from senior managers.
    3. It’s beneficial to know who initiated the issue. The issue raiser most probably can provide the best information of the cause of the issue and possible ways in which the issue could be resolved. By recording their name we can also see trends in the issues as they emerge. Maybe part of the project has more issues then another.
    4. It’s essential to evaluate the impact of the issue on the achievement of the project success criteria. As a minimum, this would include an impacts on time, cost or scope. This assessment will guide the project manager and senior management in evaluating how critical the issue is to the delivery of the project. Is some project there may be many issues, that need to be prioritised. Impact is one way to do this.
    5. The status of the issue summarises the action take so for. It would map to the stages in the issue management process. So would include raised: identified but no further action. Assessed: the impact of the issue has been evaluated. Escalated: the issue has been raised with senior management. Closed for the issues that have been impacted or resolved. tracking the issues in this way means we know where each issue is in the overall process.

     

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.