13

Managing Project Issues

Projects are dynamic; projects often deal with the new and the leading edge; and projects involve people. As a result, circumstances change, misunderstandings occur, assumptions don’t hold, political agendas collide, problems arise, and risk events happen. These situations are categorized as project issues, and they all have the potential to adversely affect the project’s capability to accomplish its objectives.

To minimize the potential effect of these obstacles on our project objectives, we need to have a proactive plan for effectively managing project issues. In this chapter, we focus on the key elements of that plan. We review the principles, best practices, and project manager skills that are essential to effectively managing project issues. In addition, we touch on the important elements of your issue management system and make sure you are aware of the common challenges faced by project managers in this arena.

The Goals, Objectives, and Principles of Project Issue Management

Managing project issues is an example of proactive project management. Through solid planning, effective stakeholder management, and insightful risk management, you can reduce the number of issues your project will encounter, but you cannot eliminate them. The goal of project issue management is to detect issues as early as possible. The earlier an issue is identified, the greater the chance of resolving the issue before it can affect any of the project’s critical success factors.

The objective of project issue management is to identify, record, track, resolve, and communicate all issues that might adversely impact the project. Translated: write them down (so you don’t lose sight of them) and take care of them (get on it). To accomplish this objective, we need to review the associated principles. The principles of issue management fall into two main categories: an administrative process and a project manager mindset.

  • Administrative process principles—To properly manage project issues, there are a few administrative fundamentals to adhere to:

    • Document the issues—You need somewhere to log the issues as they are identified. We discuss the log details later in this chapter.

    • Track until closure—Use the log to make sure issues remain visible until they are resolved.

    • Align with project needs—Ensure the overall process matches the communication and workflow needs of the project.

    • Cost-effective approach—Keep things in perspective. Don’t buy a BMW when a Chevrolet is all you need.

  • Project manager mindset principles—More than anything, effective issue management is an attitude and an approach. The following terms describe the mindset principles that a project manager needs to have in this arena:

    • Ringmaster—As the project manager, you operate as the focal point for tackling project issues. You are the gatekeeper. You are the one who must get the right people involved at the right time to make sure issues are resolved. In addition, some issues require the input of several different parties to resolve. You need to facilitate this process.

    • Smiling bulldog—Your goal is to resolve issues as quickly as possible and to stay with them until they are resolved. Be persistent. This is the “bulldog” mentality. However, you need to do this with a smile. Leverage your interpersonal strengths to do this, while still building relationships.

    • Swivel-head—Just as with risks, you need to constantly be looking for trouble—that is, trouble for your project. Sometimes issues come disguised as questions or nonverbal communications. When in doubt, ask questions and verify. The effect of most issues can be mitigated if they are detected early and resolved quickly with the right buy-in.

    • Goaltender—Just as good goaltenders do not let anything get by them, good project managers let no issue go unnoticed or unresolved. In addition, the subtle intensity displayed by the project manager here helps to set expectations with the project team and signals to all stakeholders that they will be held accountable for getting issues resolved.

    • Disciplined—To be effective, you need a fair amount of discipline. You need the discipline to log the issues and follow the process. In the whirlwind of most project environments, it is easy to let these slip.

Key Features of Issue Management Systems

The actual details of the issue management system are not complicated, and in most situations they share many similarities with your change control system and risk tracking system. Although issue management systems vary in complexity and sophistication depending on your organization and the needs of your project, all issue management systems should possess the following key features:

  • Clear process—Clearly define and communicate how issues are submitted, how they will be resolved, how and when outstanding issues will be reviewed, and what is needed to officially close an issue. This is not complicated; generally, it’s very commonsense stuff here.

  • Escalation procedures—This is part of the overall issue resolution process, but not always thought about in advance. Define the types of issue that warrant escalation to higher levels of management. Generally, there is a single escalation process for a project, which is leveraged for anything affecting the critical success factors (issues, changes, or risks).

  • Issue log—This is the mechanism used to document and track project issues. The most common mechanism is a spreadsheet, but there are limitations to this method. Other options include database systems and collaboration tools. There are pros and cons to each choice. The important thing is to use a tool that matches the needs of your project.

  • Issue log administrator—Someone needs to serve as the central control point for the issue log. Usually, this will be you, the project manager.

  • Issue data points—Although the specific mechanism used for the issue log and the exact information needs vary across projects, there is a core set of data points that should be considered for any issue logged. The recommended data points are listed in Table 13.1.

TABLE 13.1 Recommended Issue Log Data Points

Element

Definition

Notes

Issue ID

Unique ID that can be used to clearly track this issue.

Best practice.

Issue Type

Category of issue—domain values will vary depending on project.

Example set—Technical, People, Business, Supplier.

Issue Name

The short name for the issue.

Generally fewer than 40 characters.

Issue Status

The current state of the issue. This should be aligned with the process workflow established for issue resolution.

Example set—Open, Assigned, Resolved, Closed. In some settings, Open and Closed values might be sufficient.

Issue Priority

Summarizes the importance and severity of the issue.

Typical domain—Critical, High, Medium, Low.

Issue Details

The full details of the issue.

Potential Impact

Lists the potential impact to the project critical success factors if issue is not resolved.

Date Submitted

Date issue is identified and accepted.

Submitted By

Person who originated the issue.

Date Assigned

Date issue assigned to someone for follow-up.

Assigned To

Person assigned to take action on the issue.

Target Due Date

Target date for issue resolution.

Date Updated

Date that issue log entry was last updated.

Date Resolved

Date that issue is resolved.

This field might not be needed in many cases. Date Closed might suffice.

Date Closed

Date the issue is closed.

Progress Notes

Contains updates and information regarding action items, findings, and steps to resolution.

Related Items

In many cases, one issue is associated with other issues or spawns other issues/action items. It is good to track this association.

Might also be used to link to supporting documents.

Options for an Issue Log

Let’s take a look at the available tool options for your issue log. The most popular options are word processor, spreadsheet, database, and collaboration/workflow tools. There are advantages to each, and each can be appropriate in the right scenario. Table 13.2 provides a comparison summary for your issue log options.

TABLE 13.2 Comparison of Issue Log Options

Options

Pros

Cons

Best Scenario

Word Processor

Low cost.

Simple.

Portable.

“Quick and dirty.”

Limited filtering.

Limited access, visibility.

Cumbersome as log grows.

Manual processes needed.

Cost is key factor.

Team is co-located.

Only one person needs to update log.

Collaboration needs are minimal.

Low complexity level in issues tracked.

Spreadsheet

Low cost.

Simple.

Leverage sorting, filtering, and reporting capabilities of spreadsheet program.

Portable.

Limited access, visibility.

Cumbersome as log grows.

Manual processes needed.

Cost is key factor.

Team is co-located.

Only one person needs to update log.

Collaboration needs are minimal.

Some need for sorting and filtering of data.

Database

Allows for multiuser updates.

Better data relationships.

Better reporting.

Enforces process and business rules.

Increased setup and admin time.

Increased costs.

Not as portable.

Training might be needed.

Many team members need to have access and update capabilities.

Collaboration/Workflow Tools

Web-enabled.

All advantages of database tool.

Maps process flow.

Automatic notifications.

Increased setup and admin time.

Increased costs.

Training might be needed.

Workflow process is more involved.

Team is distributed, virtual.

Communication needs are nontrivial.

Best Practices

The work of project issue management is straightforward. However, several techniques are proven to be effective and help you avoid the common mistakes in this aspect of project control.

  • Assign unique ID—Make sure to assign a unique number to each logged issue. This simplifies the ongoing communication and tracking process.

  • Assign one person responsible—As with other work tasks, assign a specific person responsible for any follow-up action items and for complete resolution to the issue.

  • Facilitate resolution to complex issues—There are times when issues do not have a clear owner or need the collaboration of several parties to resolve. As the project manager, you must either assign someone to facilitate this process or take ownership of the facilitation process yourself.

  • Resolve issues at the lowest level—Always attempt to deal with problems at their lowest level. You can resolve issues faster and at less cost. More importantly, you will earn the confidence of upper management by protecting their time and only engaging them when it is warranted. Again, make sure to establish the escalation triggers with your senior management stakeholders during planning, so you are clear about their expectations.

  • Go after root cause—A common error in dealing with issues is not to deal with the actual source of the problem (root cause). Sometimes, political reasons might hamper your efforts to deal with the root cause, but whenever possible, do the proper analysis to get to the real problem and address it. If you do not, the issue will likely return for another visit.

  • Get buy-in on due date and ownership—Apply the same approach to assigning issues as you do (or should) with assigning scheduled work tasks. For better issue management, make sure to spend the time with the person designated to take action on the issue and get agreement on when the action can be completed and that this is the right person to do it.

  • Adapt process and data points—Even if your organization has a standard approach or methodology for issue management, don’t be afraid to adapt the workflow process or the tracked data points to better fit the needs of the project.

  • Review issues frequently—At a minimum, review any outstanding issues during each status review meeting. (This should be included in your communications plan.) As a good practice, follow up on outstanding issues every day and make sure the necessary steps and actions are occurring to get to a resolution.

  • Train project team on process and tools—This is not as important for projects where the issue log is mostly a management tool just for the project manager (you). However, in any situation where collaboration tools are being utilized or multiple people are involved in the process, make sure the project team is properly prepared to leverage the system.

Some Special Situations

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

  • Visibility of issue log—Usually on projects where there are multiple organizations (especially vendors and 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 might affect your project that 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 engagement—a definite issue for your organization but not a real concern of the customer.

  • Logging issues that cycle in 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 is 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 the “What did we accomplish?” section of your status report.

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

An illustration shows managing project issues.

FIGURE 13.1

Overview of managing project issues.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset