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

ShareThis

• 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.

ShareThis

For my opening gambit on Project Management within this blog I shall write a short series of articles focussed solely on the Issue Log and Risk Log. My reference is from two sources: Prince2 and experience. The first article on the Issue Log should be up here by the end of the weekend.

ShareThis