All projects suffer from the odd thing that goes wrong: these are project issues and they are so common that the project management literature has dedicated reams of space about writing about how to deal with them.
But it’s not all straightforward. In this article we’ll look at 5 ways that issue management can go wrong. It doesn’t take much for your carefully prepared issue management processes to be thrown off course!
1. Issues Are Not Recorded
The first way that issue management goes wrong is right at the beginning, when issues aren’t recorded.
You should be documenting issues as they happen. Your issue log should make it easy to see what has happened and you’ll note down:
· The issue owner
· What has happened
· What you are doing about it
· An assessment of severity
· The date, and the expected date of resolution
· Issue status: open, closed, on hold, etc.
Having everything in one log makes it simple to follow up with the issue owner.
Anyone should be able to raise an issue, but keep it the job of one person to update the log, whether that is you or a project support person. You are less likely to hit problems this way and you’ll always have one person accountable for making sure that the log reflects reality.
2. Issues Recorded Are Really Risks
What exactly is on your issue log? You should only be recording things that have actually happened.
Problems that you are worried about but that have not yet happened are not issues. These are risks (and you can read more about how to identify them here).
In A Guide To the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, issues are defined as:
“A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.”
These are the things that you want to include in your log.
3. Issues Are Too Low Level
You know that time when you double-booked a meeting room and had to cancel a workshop? Or the time when a key person didn’t turn up to work because they were sick?
They aren’t issues. They are day-to-day problems that you manage as a project manager.
It’s easy to fill up your list with tiny problems and then pat yourself on the back for doing a great job resolving them all. But resolving problems like that is your job. That’s part of the role of the project manager, so you won’t get extra credit for it.
The issues you should be focusing on documenting and resolving are the ones that are significant and that could affect the success of the project.
4. Issues Are Not Escalated
On the other hand, it’s important that issues are escalated when they need to be. If you can’t resolve it yourself and you need input about what is the right course of action, then you absolutely need to be escalating the issue to your project sponsor.
Issues should be resolved by the most appropriate person, so if your sponsor isn’t the most appropriate person (for example, it’s an issue with a contractor and you want to talk to them first) then by all means go to someone else to get it resolved. Use your professional judgement about making sure that your sponsor is kept informed about what is going on and that they make all the major decisions (as that is their job).
Unresolved issues can be the cause of project failure, so if you have any doubts about how to handle it, talk to your sponsor. It’s too risky to leave a project issue to languish because if it isn’t dealt with now it could turn into an even bigger problem later on.
5. Issues Are Not Followed Up
Finally, you have to follow through on the tasks required to get your issues resolved.
This will mean altering your schedule so that everyone can use a tool like ScheduleReader to see the latest plan, and that plan has tasks related to issue management in it.
Managing issues properly might upset your existing schedule. If the schedule changes, the team needs to know, so the best way to do that is to keep your Gantt chart and plan up-to-date.
The other advantage of transferring your issue management activities on to your schedule is that it gives real visibility about what needs to be done. If it means moving resources from other, lower level tasks to dealing with this issue, then you’ll be able to see that. You can also acknowledge that issue management takes time, and takes the team away from other activities, which you can’t do if you manage issues outside of your main scheduling tool.
Plus, if they are on your schedule, you are more likely to follow through and do the work because it’s right there.
These are 5 common ways that issue management can go wrong. Don’t let them happen on your project!