Following on from part 1, posted over the weekend here is part 2 of this 3 part series on the Issue Log

Formal Method

I am not advertising here, but one of the benefits of Prince2 as a method for managing projects is the ability to adapt the method to meet the needs of the project. However, I have yet to come across any project where the decision to dispense with the Issue Log or Risk Log has proven to be successful. So, even if you don’t follow a proven method for managing your project you should not dispense with either the Issue Log or the Risk Log.

Of course, if you’re a Prince2 advocate none of this should be news to you. The Issue Log is the base-tool for Capturing Project Issues (CS3). It is the tool which leads into managing Change Control and forms an integral part of Examining Project Issues. If you are not following a formal method of project management you should still - as a minimum - make use of the Issue Log and Risk Log.

What does an Issue Log look like

• The Issue Log IS
• A tool to demonstrate why people should have confidence in you
• Controlled
• Complete and accurate
• Holistic, but detailed
• Specific
• An open communication tool
• The Issue Log is NOT
• Kept in your head
• Only dealing with what’s happening now
• For Your Eyes Only
• A jumbled list of project-related problems
• Incomplete

The Look and Feel of an Issue Log may well change from project to project, but I always start out with my base template, modifying it where appropriate. A good understanding of the desired project outcomes should lead you to make the right changes to the template.

How do I manage the Issue Log?

I can pretty much guarantee whilst I am managing a project/s I will always have a copy of the latest version of the Issue Log (and Risk Log) with me. I take personal responsibility for Version Control and update it regularly - usually daily.

Where possible I make the Issue Log available as a link on a web site and raise awareness of its location and update schedule at the earliest opportunity with anyone/everyone who interacts with the project. I also make it clear how people make Add/Change/Delete (ACD) to it; I do all that I can to reiterate its importance and the route people should take to ACD it.

At Project Board meetings/briefings I lead with the Risk Log. However, I - again - make sure the Project Board have access to the Issue Log, so they can see the PM’s view of the project.

At least once a day (more on larger projects) I will guarantee to make sure I set aside time to review every item on the Issue Log, making sure the next action is identified, reponsibility is assigned and reasonable targets are set to conclude them.

Part 3 will follow in a week’s time