An issue is something that has happened and either threatens or enhances the success of the project. Compare this to a risk or opportunity, which are things that might happen.
‘There are no hopeless situations: there are only men who have grown hopeless about them.’
CLARE BOOTH LUCE
Issues management is the process for recording and handling any event or problem which either threatens the success of a project or represents an opportunity to be exploited. Figure 24.1 shows the context: an issue occurs either as a result of an identified risk or opportunity event occurring or as a result of some unexpected event. An issue can either be dealt with within the project, as defined, or will require a change in order to keep the project viable. Examples of issues are:
Problem issues:
Opportunity issues:
An issue is something that has happened and either threatens or enhances the success of the project. Compare this to a risk or opportunity, which are things that might happen.
When talking to people be careful, as ‘issue’ can also mean a ‘topic’ or an ‘important point’: unless you are both tuned to the same definition you may find your conversations confusing!
When an issue is identified, you should:
You should expect a large number of issues to be raised at the start of the project or at the start of a new stage within the project. These will mainly be from people seeking clarification that aspects of the project they are concerned with have been covered. This is a rich source of feedback on stakeholder concerns as well as a check on completeness of the project plan.
Make sure you record issues, even if you have no time to address them or cannot yet find a person to manage the resolution. Just making them visible is sometimes enough to start resolving them (see case study). Many issues cannot be resolved on their own simply because they do not reach the core problem; they are merely symptoms. Once other ‘symptoms’ appear as issues it is possible to start making connections which can help identify the core problem. Once this is solved a number of issues can be struck off in one go.
A project manager was heard to say to another, after running an issues log for some months:
‘This is my magic list. All I do is list the problems on it, share them with my team and … magic! They get resolved!’
‘I don’t believe you; it looks like a load of bureaucratic nonsense to me.’
‘Honestly. I have to work on some of the key ones quite hard myself, but many others are sorted out by the team without me. They see them written there and just act on them if they can. It’s all a matter of creating your own luck.’
The power of the issues log is related to its accessibility. If it is kept secret, no one will know what the problems are and hence will not be able to help. This openness does, however, carry its own risks. If seen by an uninformed stakeholder, an issues log can look like a negative and damning document for the project. You should, therefore, be very careful how you write up the issues and how you circulate or communicate them. Avoid being personal and concentrate on problems: the old saying ‘be tough on the problem, not on the people’ is very pertinent here.
‘I know that’s a secret for it’s whispered everywhere.’
WILLIAM CONGREVE, 1670–1729
A manufacturing organisation was relocating its works. It was intended that the existing plant would be moved and operated in the new location. After the site was acquired and construction was almost completed an issue was raised under European legislation that the old plant would not be allowed to run in the new location. It was deemed to be a new site and hence all plant had to conform to new emission restrictions immediately.
An issue was logged and immediately escalated to the project sponsor as the project manager had no knowledge or power to deal with this. The project sponsor quickly circulated the problem among various contacts within the organisation. Very soon a specialist unit was identified in the head office that was able to review the issue. It found that the issue was a misinterpretation of the legislation and was not valid. The issue was potentially a show stopper for the project. By identifying it and describing it accurately, however, the issue was able to be circulated and resolved (or in this case dissolved). A potentially very expensive change to the project was thus avoided.
Remember, an issue can be raised at any time by anyone and is the means of making a problem visible and having it escalated to the level where it can be resolved.
The following process, if used in full, is a very effective and powerful driver for resolving issues. Followed rigorously it will enable you to ‘breakthrough’ an issue which is blocking your project or programme. The toughest part is to declare that you do in fact have a problem. Doing this puts you in a position of responsibility which will enable you to proceed. Be careful, however; the natural tendency will be for you to dwell on what’s wrong: what’s wrong with you, or with the project, or with ‘them’. Steps 3 to 8 should be done with those who have a stake in the issue in a facilitated, workshop setting, recording the input from the group on flip charts. Do all the steps and do them in the right order. Do not jump ahead.
(Adapted, with kind permission of the London Peret Roche Group, from their ‘Breakdown to Breakthrough’ technology. Copyright © 1992, N J.)
3.12.107.31