Managing project scope
21 Manage issues
D E F I N I T I O N
An issue is a problem that is affecting your ability to deliver the project successfully. It might be big or small, something that can be fixed in a day or approached with a long-term vision, but all issues will be handled in the same way.
M I S S I O N C R I T I C A L ( P A R T 2 )
Dr Ady James’ spectrometer project did not have an issue-management sys
tem in place at the outset in 1998. He adopted an informal approach to documenting issues, combined with a close knowledge of his team’s activit
ies and concerns to ensure they were managed effectively.
‘The issues register was informal and anything could go in it,’ he says. ‘I would cut and paste sentences from emails from concerned engineers and give it an issue number so it could be tracked.’ James led his international team from the Mullard Space Science Laboratory at University College, Lon
don, and engineers from the UK, the USA, Norway and Japan contributed to the issue list. James noticed that the issues raised fell into two categories:
everyday concerns and insecurities, and new items that had not been con
ceived in the project planning. ‘The issues list was a way of allowing anybody to input new tasks into the project plan,’ he says. ‘Unplanned work issues or points relating to practical build or assembly were raised as issues in the issues register, where they were turned into new work packages and therefore planned tasks or actions.’
With a budget of around £13 million, partly funded by the Particle Physics and Astrophysics Research Council, it was essential that every concern was addressed. The issues register was one of the ways James could demonstrate to his team and stakeholders that things were being managed. Like the way the project managed its risks, the system was very simple and based on the circulation of documents rather than any complex IT package. James is clear that expensive issue-management applications are not necessary: ‘I like the paper-based systems in that I only have to worry about the update and maintenance of the information and not the update and maintenance of the system that contains the information as well,’ he explains. ‘Your project tools should support your project and no more. There is a fashion for believing that the quality of the project is reflected in the quality or complexity or newness of the tools used or in how the information is displayed. I don’t believe this.
Some tools will be necessary when the size of the project is such that a paper system is unworkable, but if it is not needed, don’t use it. The management
Project Management in the Real World
of the project should be challenging enough as it is. When there are major problems, teams like to see that the right decisions are being made, actions allocated, resources freed up. The use of these tools, whether paper-based or an IT system, then becomes a good way to show how we would get over the issue,’ he says.
Issue management requires the same approach as risk management: log the issue, devise an action plan, carry it out and monitor the situation. The issue log should include any problems that occur that will have an impact on your ability to deliver the project successfully. An example log is included in the appendix.
Issues may be the result of a risk that has materialized but could just as easily be something that has never been on your risk register. The log can include issues over which you have no direct control as well as those you can fix using the resources within your project organization. However, this is not the place to log approved changes. They should be kept separate, so if the result of an issue is to raise a change to address something, the change should always go through the change-management process.
By their nature, issues are more immediate than risks, and as such you may choose a more informal approach to documenting them. As the situation has already happened, it is less useful or necessary to craft a descriptive paragraph explaining the issue: a cut-and-paste from an email may well be sufficient to provide enough of a memory jog so that your team knows exactly what is being referred to.
The appropriate resolution for an issue may be immediately obvious, so that you see quickly what you need to do in order to create an action plan to rectify the situation. That’s rare though. It is more likely that the full extent of the problem will not be known. Then it is down to you to investigate the issue thoroughly, drawing on the relevant team members, in order to be able to find an appropriate solution.
A good way to analyse a problem’s root causes is to brainstorm with the right people in a room. This will help you:
• understand the issue;
• be able to explain its impact to the relevant stakeholders;
• devise an action plan with which you can monitor the situation.
Due to the immediacy of issues, there are two key things to bear in mind:
• the efficacy of the action plan to handle the problem;
• the speed with which you allocate someone as the owner of that issue to take responsibility for seeing that the action plan is carried out.
Even issues outside of the project’s control can have a team member alloc
ated a watching brief, someone tasked to provide updates on a regular basis as an issue unfolds. It may take a significant time for some issues either to be resolved or to disappear. On the other hand, some issues may be a short sharp shock to your project, over and done with very quickly.
Manage issues
H I N T
Issues can be controlled in various ways depending on the type of problem, but a common way to resolve simple issues is to propose a change to the project schedule, budget or require
ments in order to incorporate the tasks needed to resolve the problem. If the project sponsor agrees, then the change is approved and you can replan your project accordingly, pro
ceeding with the new status quo.
The issue status in the log can be changed to ‘closed’ once an issue is con
trolled. As with risks, do not delete issues from the log. The complete list of issues with the action plans and final resolution provides a useful audit trail and input into the post-project review. It will also help you remember what you did if you come across a similar problem later.
G O L D E N R U L E S
Issues have already happened, so log them, draw up an action plan to manage them and move quickly to execute that plan.