Project Issue Log
Project Issue Log
By The Office of Government Commerce – OGC, UK
Purpose of the Project Issue Log
The purpose of the Project Issue Log is to:
- Allocate a unique number to each Project Issue
- Record the type of Project Issue
- Be a summary of all the Project Issues, their analysis and status.
Fitness for Purpose Checklist
- Does the status indicate whether action has been taken?
- Are the Project Issues uniquely identified, including to which product they refer?
- Is access to the Issue Log controlled?
- Is the Issue Log kept in a safe place?
Suggested Content in the Project Issue Log
- Project Issue number
- Project Issue type (Request for Change, Off-Specification or a general issue such as a question or a statement of concern)
- Author
- Date identified
- Date of last update
- Description
- Status
Source Information of the Project Issue Log
Project Issues may be raised by anyone associated with the project at any time.
The Office of Government Commerce – © Crown Copyright 2009
I find the following additional fields to be invaluable within an issue log:
Owner – someone needs to be accountable for each issue; it probably is not the author
Target Date – Without a goal, the issue can not be managed appropriately
Priority – Not all issues are created equal
Peer Reviewer – builds consensus and increases communication when dysfunction exists (Be careful with this one. There is a lot of overhead in its use. Good during project recovery though)
Peer Review Target Date – see target date above
Thanks for bringing up the question about the issue log structure. In addition I would agree with Shawn’s remark – to make each issue a potential action item. The OGC’s log seems static and I guess it is a result of issue identification activities. In order to minimize project’s issues there have to be some action and responsibility.