In Part 1 of this two part series on keeping track of your ongoing issues that arise on the projects you manage, we first had to acknowledge that every project experiences issues. It is the nature of project management and our imperfect environments that we can’t completely control. We then discussed a simple and usable format for creating and maintaining the ongoing issues list. Remember, making it too detailed and complicated will turn off the customer and confuse the very individuals that you are tasking to resolve the issues. Keep it simple and it will be easy for everyone to understand and for you to maintain, keep up to date, and distribute weekly.
Let’s continue this review by discussing how best to use and monitor the issues list on an ongoing basis…
Using the issues list
The issues list is maintained by the project manager and is updated at each project team meeting. It is not a replacement for a project schedule. It is used during the planning phase, before a schedule is created, to track any planning tasks that must be completed. It is also used during execution to track issues or action items that are not significant enough to put on the schedule. It should not be used to track the deliverables or tasks that must be completed during the execution phase – the real work of creating the final deliverable. That is what the schedule is for.
Monitoring the list with the team
In preparation for the formal weekly status discussion that includes the customer and where the issues list will be formally discussed each week, it should also be reviewed weekly with the team and updated at every weekly team meeting. Review the current issues with the team, asking for a status update on the issues due for resolution. Were they resolved? If so, how? When? If they were not resolved, what will be required to get them resolved and when will that happen? Ideally, the project manager should be notified as soon as the person assigned to the issue knows that he will not be able to resolve the issue or when he needs help getting the issue resolved on time. This allows the project manager to be proactive before the issue is overdue. If necessary, enlist the help of the sponsor, if the project team can’t get an issue resolved on its own. Before the project team meeting is adjourned, review any items that should be resolved before the next team meeting, so that everyone is clear about which pending issues are scheduled for resolution.
Summary
Again – and I can’t stress this enough – keep it simple. Too many things in the PM world are detailed and difficult for the customer and others to follow. I have had project clients who hated looking at the project schedule and wished everything could be handled in the issues list format. While that really isn’t feasible for a complex, long term project and not something that the average project manager wants to try to do, I did at least understand where they were coming from so I made the issues list a prominent part of our PM strategy for those particular clients. People want information in front of them that they can easily see and understand without a roadmap to get them there. And if they understand it better and can own it more easily, that makes our jobs as project managers easier and it means that the issues list will be more easily managed.
