-
Portfolio Management Process - The Process for the Process
February 3, 2012
-
The Role and Significance of an Interior Design Project Manager in Commercial Construction
February 3, 2012
-
Approaches to Leadership
February 3, 2012
-
Point of Total Assumption (PTA)
February 2, 2012
-
Project Management Foundations - Using Progressive Elaboration
February 2, 2012
-
Avoid Communication Breakdowns - Listen to Your Team
February 2, 2012
-
The Ineffective Executive
February 1, 2012
-
How to Deliver More Than Just a Good Project
February 1, 2012
-
Savvy Organizations are Developing Leadership Talent with Special Projects
February 1, 2012
-
Balancing Project Management and Project Administration
January 31, 2012
Project Issue Log
September 8, 2009 | Author: PM Hut | Filed under: Communications Management, Project Management Definitions, Risk Management
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
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
2 people have left comments
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.