|
|
|
|
|
3.1.1T Manage Issues / Techniques
Problem Solving Techniques (3.1.1T.P1)
People have been creating and solving problems for thousands of years. In the last few decades, formal techniques have been developed to help in the problem resolution process. These techniques can be very useful resolving issues on your project. There are dozens of different problem solving techniques available, including the following three:
Resolve Issues as Soon As Possible (3.1.1T.P2)
The definition of an issue is that it is a problem that will impede the progress of the project and cannot be totally resolved by the project team. That definition leads you to understand that issues must be addressed quickly. If a problem is indeed being classified as an issue, the project manager must take responsibility for getting it resolved. The project manager should have an activity in the schedule every week to follow-up on open issues to ensure they are being diligently resolved.
By the same reasoning, if there is no urgency to resolve the issue or if the issue has been active for some time, you should look again to see if it really is an issue. It may be a potential problem (risk) or it may be an action item that needs to be resolved at some later point. Issues by their nature must be resolved with a sense of urgency.
Try to Solve the Root Cause, Not Just Symptoms (3.1.1T.P3)
When issues arise, they should be solved as quickly as possible. However, try to resolve the root cause of the issue, not just the symptom. Solving the root cause will ensure that the problem does not resurface later in the project. The root cause can usually be found by asking a series of ‘why’ questions. Why did the issue arise? When the question is answered, ask yourself ‘why’ again, and again. When you cannot answer the ‘why’ question again, you are probably close to the root cause. See 3.1.3T Manage Issues / Root Cause Analysis for more information.
Sometimes you have to Make Decisions Among Imperfect Alternatives (3.1.1T.P4)
After reviewing the process and the techniques for managing issues, you may think that you should be able to successfully resolve every one if you only knew the right technique. In fact, you may find some issues that do not have good, clean solutions. It may be difficult in some cases to determine any good options for resolution. Other times, issues arise that are hard to resolve not because of a lack of options, but because of the difficulty gaining approval and resolution among a number of alternatives. In other cases, you may have a number of options that are less than optimal, and the ultimate resolution may be one that is the least offensive.
An example of this dilemma is an issue that involves internal politics. Usually when a problem starts to get mixed up with internal politics, you will find that the resolution is difficult because there is more to the decision-making process than a cool examination of the facts. When a problem becomes political, in fact, a resolution may be approved that is actually far less than optimum for the project team. However, a less-than-perfect solution may be preferable to deadlock or the prospect of an even worse alternative approved.
In these situations, try to get the approvers to understand that a delay in the resolution decision usually does not make the result any more palatable. The project manager should strive to gain a resolution as quickly as possible so that the project can move forward. If the issue is political, the project manager will usually need to rely heavily on the sponsor and other management stakeholders to help in the resolution.
Create Guidelines for When Can Team Members Can Make Decisions? (3.1.1T.P5)
After stressing the importance of raising issues and potential scope changes to the project manager, it may seem to some team members that they do not have the ability to make any decisions at all. You definitely do not want to give that impression. As a project manager, you need to encourage people to accept responsibility and make decisions when appropriate. This helps the team run more efficiently and allows individuals to grow professionally.
As a project manager, you need your team members to handle all the day-to-day problems and only bring items to you on an exception basis. In general, team members need to ask themselves some key questions before deciding if they need help or if they can make a decision themselves.
-
Is there an impact to effort, duration or cost? If there is, the project manager must be involved.
-
Will the decision require you to go out of scope or deviate from previously agreed upon specifications? If so, the project manager must be involved.
-
Is the decision politically sensitive? If so, the project manager must be involved.
-
Will the decision require you to miss a previously agreed upon commitment? If so, the project manager must be involved.
-
Will the decision open the project to future risk? If so, the project manager must be involved.
If none of these conditions are true then the team member can make the decision. It may sound like there is nothing left, but in fact, most of the decisions that are required on a day-to-day basis do not meet these criteria and can be made by the team or individual team members.
Understand the Difference Between Issues Vs. Action Items (3.1.1T.P6)
In many cases, project managers are not using the Issues Log to identify and track true issues. Many items that are classified as issues are really risks (potential problems) or just action items. Action items are activities that must be followed-up on at some time. They may not be problems at all. If you find that your Issues Log has dozens of items on it, you are probably tracking many action items. Because issues are large problems, there should not be many items open at any one time. For more information on action items, see 4.1.1.2T Action Items.
Ask Team Members to Identify Problems and Solutions (3.1.1T.P7)
Issues can come from team members, clients or any project stakeholder. It is a good practice to encourage people to help identify solutions along with the issues. When a team member identifies a potential issue, ask him to bring one or more possible solutions. This process will help build accountability among the team members, but it will also help determine possible courses of action. In fact, if a team member proposes one or more viable solutions, the problem may be able to be resolved with the help of the project manager and never reach the level of an issue at all.
Engage the Client Early in Issues Management (3.1.1T.P8)
Issues management tends to go more smoothly when the entire project team is comfortable working through the issues management process from the very start. If issues arise early in a project, be sure to follow your issues management process and get the client engaged in the solution. Issues become more urgent as you get closer to your end-date. Don’t let these be the first issues the client gets involved with. Earlier issues management experience will cause the client to see issues as just temporary hurdles that need to be overcome. If you haven’t engaged the client earlier in the issues management process, the client may cause more harm than good when you absolutely need him at the end, since he is not familiar with the issues management process.
Break Very Large Issues into Smaller Problems (3.1.1T.P9)
If a large issue looks too difficult to be resolved in a timely manner, break it down into logical sub-issues. In many cases, the resolution of an initial sub-issue will drive the solution for the remainder of the issue. If it does not, it at least lets people understand the components of the issue, so that they can be attacked and resolved individually.
Look for Common Causes if You Find Multiple Issues in a Short Timeframe (3.1.1T.P10)
Sometimes you may encounter a number of issues in a short timeframe. If this happens on your project, look to see if some are related. If so, try to resolve the issue that looks like more of a root cause. The resolution of this issue may substantially resolve others.
If the issues look independent, try to resolve those with the most negative impact on the project first.



