Any experienced project manager will tell you that issues management is an important part of running your project. How important? Failure to document, communicate, and otherwise manage project problems as they occur is associated with a high level of project failure and is considered a common “newbie” PM mistake. The great news about issues is that they are easy to manage if you know how to handle them.
What Qualifies as a Project Issue?
For the uninitiated, a project issue must meet some of the following criteria:
- It must be something that has already happened (things that might happen are called “risks”)
- It is an event, activity, or circumstance that affects your project. This means it impacts the schedule, the budget, or the scope of work. The impact may be a direct impact (e.g., the delivery date was moved forward by 30 days) or indirect (e.g., developers are taking more time to complete work due to ambiguous requirements, leading to potential delays).
Pop quiz about project issues management:
A. T/F The project manager is expected to resolve all issues
B. T/F Issues that are resolved quickly do not need to be documented
C. T/F It’s best to keep the project team out of the issue management process
D. T/F Managing issues is pretty much the same as managing risks
And the answers are:
- The project manager is expected to resolve all issues– False. The project manager is expected to document, track, and look for the best way to solve project issues. However, issues are often assigned to an owner – a member of the project team who is best suited to working on the solution. If a solution cannot be found in a timely manner, escalation to the project sponsor is often the next step.
- Issues that are resolved quickly do not need to be documented- False. You could sort of make a case for this one – what’s the point in documenting something when the solution is almost immediately known? Well, it shows that the issue was recognized, discussed, and solved. This provides continuity for your project’s documentation, and documenting the solution provides potentially valuable information for future projects.
- It’s best to keep the project team out of the issue management process- Absolutely False- really! Do not hide issues from your team! Review the issues and their impact at every status meeting. Engage other project members to find the best solution. Hidden issues can cause big problems when they are inevitably discovered later in the project.
- Managing issues is pretty much the same as managing risks-False. They may look the same in many respects, but issues have already happened and something needs to be done about them. Risks are still just “maybes” – so you need to plan for them and try to avoid them, but really that’s all you can do.
Tracking Project Issues
Most PMs use an issues log or similar device to keep their project issues organized. The log can be a document or a spreadsheet (very popular). Here at Segue, we’ve found that a a SharePoint list works well for us. For each issue, a unique ID should be used (and never reused in the same project). We track the following information for each issue: Description, date identified, owner, status (open, closed, resolved, etc.), date resolved, and notes from each review. You can add other information to suit your project needs.
Project issues from the log should all be resolved in some manner at the end of the project. If an issue’s life extends beyond the project’s end date, it should probably be handled through other organizational practices or otherwise moved to a non-project specific area for tracking. Your PMO documentation practices might help with this.
So, using these basic practices will make it easy to manage your project issues. Solving them – that’s the more difficult part, but make sure to include the expertise of your team when working through anything than might impact your project.