In this post we'll 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 shown below provides a comparison summary for your Issue Log options:
Following are some of the techniques that 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 his/her agreement on when the action can be completed and that he/she 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.
There are a couple of special situations that often come up. Let’s see 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 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 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.
Here our discussion regarding project issues come to end, in the next post we shall discuss about project risks.
Following are some of the techniques that 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 his/her agreement on when the action can be completed and that he/she 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.
There are a couple of special situations that often come up. Let’s see 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 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 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.
Here our discussion regarding project issues come to end, in the next post we shall discuss about project risks.
No comments:
Post a Comment