Issues abound on every project ever managed since the beginning of time. No project is executed so perfectly that no issues arise. And even if everything is running smoothly on all cylinders, there will still be issues that come up that are beyond the control of the project manager, team and other stakeholders…. there are just too many variables that come in to play on each engagement for issues not to arise. So basically, no matter what you do, no matter how well you plan, no matter how experienced you are and no matter how hard you try, you will never ever run a project that does not experience some issues along the way that must be documented and managed.
The nature of issues
Issues can be big or small, but if they are left unmanaged they will almost always become problematic and threaten to bring the project down. The experienced and prepared project manager will proactively document and manage project issues and assign them just like tasks in a project schedule. And they will also review them and track them just like anything else on the ongoing project status report and discuss them – at least the big ones – at every project status meeting with the key stakeholders and assigned resources.
Documenting and managing the issues
The first thing you’ll want to do as part of the issues management process is to create an issues list. The issues list does not need to be complex… in my opinion the simpler the better because then it will be something easy to use, easy to comprehend and easy to keep up to date.
The list will capture any issues that need resolution or any actions that need to be completed that cannot be captured in the project schedule, which you’ll develop later during the planning phase. The issues list is set up and managed by the project manager and can generally simply in spreadsheet form though you should tailor what tool you use to however it works best for you to manage it and disseminate the information to your team and customer.
The layout
Again, a simple layout is best, in my opinion. In all it should just need to be a few columns…likely in a simple spreadsheet format. The first column would be a unique identifier – a sequential number. However, depending on the complexity of the project, it may make sense to use a combination of alpha and numeric characters to differentiate between areas of the project or end solution.
In the next column write a brief description of the issue or action item required. What exactly must be resolved? Next, who is it that needs the issue resolved? Whose problem is it? Then record the name of the person on the team who is accountable to resolve the issue. He or she may or may not resolve the issue alone, but he or she needs to get the issue resolved. (Because we need someone from the team – delivery or customer team – to be responsible, the person whose job it is to get the issue resolved must be on the team.) Next, when is the resolution needed? Set a date. The last two columns are filled in after the issue has been resolved.
In Part 2 of this two part series on making issue tracking simple…but actually doing it…we will discuss the ongoing usage and monitoring of the list with your customer, project team and key stakeholders.
