As a PM the Issue Log along with the Risk Log are two of your most valuable tools when it comes to communication about your project. The Issue Log should probably be your most public-facing document. It should be strictly under your control; even if you work with a Project Office you, as the PM retain ownership and responsibility for content, availability, version control and maintenance of this document.

• The PM is responsible for Issue Log content, version control, availability and publication
• Questions, problems, queries, change requests, change of scope new risks all start life on the Issue Log
• The PM is reponsible for making sure every Issue is followed through to its conclusion
• One of your most important and valuable tools - even without a formal method of project management
• Consider defining the next physical action to take place to progress an Issue

Publicity

The Issue Log is the engine for managing how external forces interact with your project and how you keep them informed of progress regarding their Issue. It is your most publicly visible document. This should be the document which shows people why they should have confidence in your ability to take the project to its conclusion.

It should be self-evident from the Issue Log you are in control of the short, medium and long-term milestones of your project.

But it’s not important to me

Remember, just because an Issue has been raised for which you know the answer or it appears insignificant in proportion to the project, it is evidently important to the person who raised it.

Take the time to manage each Issue through to its conclusion. If you don’t, you can not be considered to be managing the expectations of those effected by the project appropriately. That is rude. Rude communication is not good communication. Rudeness does not endear confidence! And ultimately it can lead to a splintered project team.

External Forces

Anyone associated with a project may raise an Issue at any time. This means anyone (loosely) associated with the project can:

• Ask a general or specific question about any part/the whole of the project
• Raise a “Request for Change”
• Raise an “Off Specification”
• Raise a “Statement of Concern”

It is your responsibility to ensure all of these are logged and actioned against. All of these items should be entered on the Issue Log and you should periodically take time to review all and every item on the Issue Log to make sure it is being progressed. In my opinion you should, at every review determine exactly what the “Next Physical Action” is, so the Issue can be progressed to conclusion.

When assigning actions for Issues, make sure you assign responsibility to an individual rather than a team. It’s a good idea to make this information publicly available.

Good GTD experience counts for a lot here. The ability to look at the next required action versus re-evaluating the issue at each read-through really does make your life as a PM easier.

Too often I’ve heard people say “I don’t have the time to review the Issue Log“. Tough! That’s your job. You are the PM and you have to make the time to manage the Issue Log and Risk Log.

FAQ

Use the Issue Log as an FAQ for the project. Not an FAQ for the project results, but as a working, fluid document, which is kept up to date, to which everyone can have confidence will give them a good heads-up on how the Issues facing the project are being progressed.

This really is the best document to avoid having to answer the same questions time after time. Make it available in the most accessible method possible, be this Wiki, Blog, Spreadsheet, whiteboard, email, etc, but make sure you retain complete (cradle to grave) ownership of the document.

There must be no room for confusion about updates to the Issue Log and version control processes should be transparent, so people can have confidence they are looking at the most up to date version.

Part 2 of Issue Log will be available here on 5, March 2008. What does the Issue Log mean to you? Feedback via the comments is welome.