Some Special Situations

On this subject of managing project issues, there are a couple of special situations that often come up. Let's discuss them briefly.

• Visibility of Issue Log Usually on projects where there are multiple organizations (especially vendors, suppliers), you will want to manage multiple Issue Logs (same for risk logs too). Why? Quite simply, there are things you are concerned about that may impact your project, which you need to bring to the attention of your organization's management, but that you are not ready to share with all project stakeholders. This is simply a matter of expectations management and not sharing your dirty laundry prematurely. A common example is with resource productivity on a fixed price engagementa definite issue for your organization, but not a real concern of the customer.
• Logging issues that cycle less than a reporting period Depending on how often the Issue Log is updated, there are often cases where an issue is identified, evaluated, and resolved before it can actually be logged. Of course, on many projects, this a standard operating procedure. However, it is often difficult to exercise the discipline to log these issues after the fact. It is strongly recommended that you find the willpower (or assign someone) to get this accomplished. From a lessons learned and audit perspective, you will be glad you did. Plus, it boosts your "what did we accomplish" section of your status report.

The Absolute Minimum

At this point, you should have a solid understanding of the following:

• Managing project issues has two key componentsan administrative process and a project management mindsetthe mindset is far more important.
• The terms that best describe the desired project manager mindset are "ringmaster," "smiling bulldog," "swivel-head," and "goaltender."
• Project issues need to be identified, recorded, tracked, resolved, and communicated.
• Key issue management best practices include resolving issues at the lowest possible level, going after the root cause of any issue, assigning a specific person responsible for each issue, getting buy-in on ownership and due date from the person assigned the issue, and frequently reviewing the issue log with the project team.
• Whenever an issue needs the input of more than one person to resolve, the project manager should facilitate the resolution process.
• The issue management system needs to match the specific communication and workflow needs of the project team and the project stakeholders.

The map in Figure 13.1 summarizes the main points we reviewed in this chapter.

Figure 13.1. Overview of managing project issues.