Home
About Us
Site Map
Products
Services
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Links
Contact Us
BLOG

 

 

Issue Management

There will be obstacles to overcome and issues to be resolved in every project, even after all the planning has been done and the plan is executed. These are addressed outside of the project plans because every problem or obstacle does not warrant a project change to plan a new activity. These activities are captured and managed in a register which most call an issue log but I prefer to call an action register. I’ll explain the reason for this later on in this article.

These issues are important to the project despite not warranting changes to the project plans. Failure to address these issues will result in dissatisfaction among your project team and stakeholders and may even result in the project failing to deliver on all its goals and objectives. Your ability to manage project issues will affect your project’s health. The elements of good issue management are: identification of issues, capture of issues in an issue log or action register, identification of actions and primes, distinction of issues from changes and risks, closure of the issue, and communication of issue information.

 

Action Register (Issue Log)

The reason for starting with the action register or issue log is this project artifact is central to every element of issue management. The reason (as promised) I use the term action register is to suggest an outcome for the issues captured there. Issues that you manage from the action register will inevitably require someone to do something in order to resolve the issue or solve the problem. Calling the artifact an action register will suggest to everyone who reads it that items described in it must be acted on and hopefully this call for action will have a positive affect on their readiness to act. I can’t tell you at this point that I have an empirical proof this works.

Use a spreadsheet for your action register. Your spreadsheet should support the following fields:

  • Issue Description
  • Issue Date – this is the date the issue was captured in the register
  • Issue Owner – the person who identifies the issue
  • Action Description – a description of the action defined to resolve the issue
  • Action Prime – person who has accepted responsibility for resolving the issue
  • Forecast Date – the date by which the action is to be completed
  • Actual Date – the date the action is actually completed
  • Status (optional) – Could be one of: open, interim, resolved, or closed. Choose the status identifiers that suit your project

The Issue Description, Issue Date, and Issue Owner should be captured as soon as the issue is raised. The Action related information should be identified at the same time, even if it is only to identify the person who can take action on the issue.

The action register is the communication vehicle for informing the project team and stakeholders on the status of project issues. Post this spreadsheet in a central location which is accessible by all, but reserve write permission on the file for yourself or anyone on the team you delegate to administer the file.

 

Identifying Issues

Everyone on the project team and all the stakeholders, including you, are potential issue identifiers. The trick with identifying issues is to identify them while they are still addressable with simple actions; avoid ignoring small issues until they become large and difficult to resolve. The entire team should be aware they are responsible for identifying any project issues they become aware of and their responsibility includes bringing the issue to your attention as soon as they become aware of it. Your project kick-off meeting is the ideal opportunity to educate your team on this point. Team members acquired after the project kick-off should have this information covered in their orientation. Identification of issues and bringing the issue to your attention are just as important as other administrative responsibilities such as time sheets.

Stakeholders can be informed of your expectations around the identification and raising of issues, if you feel they may be an important source of this information. I find that stakeholders are usually not adverse to bringing issues to my attention and seldom need encouragement to do so. The difference between issues identified by stakeholders and team members is that team member issues tend to be obstacles to their progress while stakeholder issues tend to be changes they would like to see to the project, or risks they perceive. If you feel that informing stakeholders of your expectations is warranted for your project, take this step at the first meeting you hold with your stakeholders.

Communication of issues must be a two way street. Team members and stakeholders must bring issues to your attention but you must present them with opportunities for communicating with you. The time and effort you invest in educating your team on their responsibilities and presenting them with opportunities to raise their issues with you will pay off in fewer escalations, missed deadlines, and missed deliverables. Project managers who employ the "walk around” management style will have a much easier job of encouraging the team to raise issues in a timely fashion. Analyze conversations that turn into "gripe sessions” for hidden issues. Team members will frequently complain about trivial matters which aren’t project issues to relieve pressure, on the other hand you may be listening to a team member raising an issue to you that should be addressed by an action and resolved. Asking the right questions can help with the distinction. Open ended questions such as "What affect is this having on your work?” or "Is this likely to prevent you from delivering you widget by next Friday?” may uncover an issue. Get as many specifics as you can from the team member and then capture this information in the Action Register.

For project managers with a geographically distributed team the task is a little more difficult. You can use regularly scheduled one-on-one meetings with team members to replace "walk arounds”, or you can place impromptu calls. Listen for the tell-tale signs of an issue in the same fashion as with a face-to-face meeting.

Team meetings present an ideal environment for flushing out project issues. Set aside a few meetings at each meeting for team members to identify issues that are hindering process. The advantage of raising issues in a team setting is the likelihood that the resolution resides in the room. Capture the issue in your register when it is raised and then look for an action that will resolve the issue and an owner of the action within the room.

Job Huddles are an especially fertile ground for flushing out issues. Due to their more informal setting, issues are more likely to be raised without inhibitions. Since you want to maintain the informal atmosphere and keep these meetings as brief as possible, don’t try to set an agenda with Issue Identification as an item, but do listen for any gripes or complaints that are symptoms of an issue. Don’t bog the meeting down by trying to identify the resolution on the spot, look for someone to provide a resolution after the meeting is over. Don’t be afraid to ask the team to recommend someone who could resolve the issue; they know much more about the issue than you do.

Gate Review/Phase Exit Review/Business Decision Point meetings are another fertile ground for issues, in fact it may be worth your while to create an Action Register for each of these meetings so that "gating” issues can be segregated from regular project issues. Gating issues are those issues that prevent the project from passing the gate or moving to the next phase.

 

Identify an Action and Action Prime

The identification of an action which would resolve the issue and a prime for that action is your responsibility. If the person who raised the issue were capable of resolving the issue themselves, it wouldn’t be an issue. This does not mean that the person who raises the issue does not have some idea of whom or where the resolution should come from, frequently they do. Ask more closed ended questions to get suggestions for resolutions: "What actions do we need to take to resolve this issue?” "Who should act on the resolution?”, "When do you need the resolution?” The "who” may be a single individual, a group, or you. If it is an individual in the room, check for agreement to owning the action and prompt for a forecast due date. Capture the proposed action, action owner’s name, and forecast date in your register.

You are the owner of the action when no resolution can be identified by the issue owner, or the resolution should come from a group, or an individual not in the room. Capture the proposed action in the action field in your register and assign the action to yourself. You will own the action until such time as you can find an owner willing to provide the solution. Action owners must agree to responsibility and a due date for completing the action. Unless the issue arises from a team member not performing their work properly, the action to be taken may be in addition to project work you have already assigned so be careful with assigning actions requiring a great deal of time and effort.

 

Is it an Issue or a Change Request?

Change requests often come to the project manager in the form of an issue. The issue may be raised during a Stakeholder meeting, or Steering Committee meeting, a casual conversation, or in the project’s defect reporting tool. Ask the following questions about the issue: "Is the ask for a new feature?” "Is the ask for a change to an existing feature?” "Is he or she describing an event that may happen in the future which would have a negative impact on the project?” If the answer to any of these questions is yes, you are dealing with a change request or a new risk and need to manage it as such.

Do not capture change requests or risks in the Action Register. Educate the issue owner on the project change process and direct them to the Change Request process and template. Capture any risks in your risk register and manage them there. You may not realize that you’ve actually received a request for a change until you begin to investigate a resolution. Issues that require changes to existing requirements, changes to the tool set team members are given to work with, and changes in roles and responsibilities are all examples of project changes. Keep asking the questions above as you identify the issue resolution. Close the item in the Action Register with the current date as soon as you identify a change or risk. Closure is not dependent on the initiation of a change request. Record the risk information in your risk register if you identify the issue as a risk.

 

Issue Closure

The method for identifying resolved issues is the same as that for identifying the issue. Walk around, team meetings, and job huddles are all appropriate opportunities to review the Action Register. You should update the status of the issue (assuming you capture that information) to indicate the issue has been resolved. Don’t jump the gun and assume the issue owner is happy with the resolution. It is up to the issue owner to test the resolution promptly to determine if the action has resolved their problem. Set the status of the issue to closed as soon as the issue owner has indicated satisfaction with the resolution.

You may need to re-set the forecast resolution date for actions when the action prime misses their resolution date. Don’t let missing one forecast date upset you. Frequently when forecast dates are given for actions that resolve issues, the action prime has not had a chance to analyze the work in depth. One re-set of the date should be all that is required. If you continue to re-visit the issue meeting after meeting without arriving at a resolution, sit down with the action prime to determine the reason for their failure.

Do not be responsible yourself for disappointing the issue owner by repeated failures to deliver on a promise for action. Address the issue with the owner when it turns out that a proposed action is actually a change request, risk, or simply outside of project span of control. Either close the issue without a resolution (the issue owner can "live” with the issue), or identify an action which is within the team’s power to deliver.

 

Communicating Issues

The Action Register is the primary communications vehicle for information on issues. Your first means of communication is to simply make the spreadsheet available to every project stakeholder and project team member by posting it in read only form in a central location. Be certain that no-one else has write access to the register and don’t leave old versions of it in the central location.

Review the Open and Interim items in the Action Register at each of your team meetings, as part of the agenda time set aside for issues. Review the more critical actions with the action primes individually and always update the register as soon as the issue status changes.

Action Registers that are specifically created to handle gating issues identified at a Gate Review meeting should be communicated twice. Once in the mail informing your audience of the outcome of the meeting and again when all the actions have been taken and the issues are closed.

 

The tips and tricks described in this article are intended to help the project manager using the best practices promoted by the PMI. Project managers who are certified have already implemented those best practices. If you haven't been certified as a PMP® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php