24
Managing what has gone wrong (or right!)

Issues

1. What do we mean by "issues?"
2. When an issue is identified
3. Tips on using the issues log

An issue is something that has happened and either threatens or enhances the success of the project. Compare this to a risk which is something that might happen.

• Be open about issues within your team – declare them.
• Never “sit” on an issue – if you can’t deal with it, escalate it.
• Use the team to resolve the tricky issues.

What do we mean by "issues"?

Issues management is the process for recording and handling any event which either threatens the success of a project or represents an opportunity to be exploited. It could be a problem, query, concern, or risk that has occurred. Figure 24.1 shows the context: an issue occurs, either as a result of an identified risk event, or as a result of something unexpected. An issue can either be dealt with within the project, as defined, or require a change to keep the project viable. Examples of issues are:

Problem issues:

• the late delivery of a critical deliverable;
• a reported lack of confidence by users;
• a lack of resources to carry out the work;
• the late approval of a critical document or deliverable;
• a reported deviation of a deliverable from its specification;
• a request for additional functionality;
• a recognized omission from the project scope;
• an assumption being breached, say an exchange rate or inflation rate, or a lower than expected response to a sales campaign;
• a competitor launches a similar service or product.

Opportunity issues:

• a contract negotiation is concluded early;
• a breakthrough on a new technology cuts months off the development time;
• a new, cheaper source of raw materials is located;
• the enrolment of key stakeholders happens sooner than planned;
• a contract tender comes in significantly less than the pre-tender estimate;
• a competitor announces it has to delay its next major product launch.

An issue is something that has happened and either threatens or enhances the success of the project. Compare this to a risk which is something that might happen.

When talking to the team or any stakeholders, be careful, as “issue” can also mean a “topic” or an “important point”: unless you are all tuned to the same definition, you may find your conversations confusing!

Figure 24.1 Risks, opportunity, issues, and change
An issue occurs either as a result of an identified risk or opportunity event occurring, or as a result of some other 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.

When an issue is identified

When an issue is identified, you should:

1. Record in the issues log any issue which has been drawn to your attention for resolution. (An example issues log is shown in Figure 24.2 on page 392.) You should:
   • describe the issue;
   • record who brought it up and when (date);
   • rate the issue priority (1 (critical) to 4 (minor impact)).
2. Decide and agree who will be accountable for managing the issue’s resolution. If the issue cannot be dealt with by the project team, refer it outside the team to a person with the necessary level of knowledge and/or authority (the project sponsor or project board for example). You should record in the log:
   • the name of the person accountable for managing the resolution of the issue;
   • the date by which resolution of the issue is expected.
3. Regularly update the progress commentary on the log.
4. Once the issue has been resolved, record the method and date of resolution in the log. The line can then be shaded to show the issue no longer requires attention. If the issue resolution requires an amendment to the project scope (deliverables), cost, timescales or benefits, it should be handled through the change control process (Chapter 25).
5. Report new, significant issues in the regular project progress report (see Chapter 19).

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 be mainly 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 and scope.

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. As soon as 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.

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, obviously, not be able to help. This openness does, however, carry its own dangers. If seen by an uninformed stakeholder, an issues log can look like a negative and damning list. 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.

Figure 24.2 Typical issues log
The issues log contains the list of all the "happenings" which either threaten the success of the project or which may lead to an opportunity. It comprises a description of the issue, the date raised, who it was raised by, the name of the person accountable for resolving it, and a target date for resolution. The final column contains notes to help the reader understand the current situation or record how the issue was resolved.

Murphy’s law will strike, so learn how to handle it!
Copyright © 1997 Robert Buttrick

Tips on using the issues log

• Phrase the issue as a question; this is more powerful in helping to focus on a solution.
• Have only one issue per “line”. Grouping a number of issues together (even if related) makes identification of a solution difficult.
• Do not add to existing issues or they will never be resolved; record a new issue if a different facet becomes apparent; they may be symptoms and the more you collect, the more likely you are to find the core problem.
• Make cross-references between issues or refer back to the risk log (by a note in the “comment” column) if this is helpful.
• Keep all issues visible, even those which have been resolved, as this shows achievement in overcoming problems and exploiting opportunities. It also acts as a check in case the same issue resurfaces later. Shading completed issues makes it clear which are live and which are resolved.
• If the resolution of the issue requires a project “change”, put a cross-reference to the change log in the resolution column.
• Be open with your issues log within your core team and share it “with care” with others on whom the project will have an impact.

Workout 24.1 – Resolving issues – from breakdown to breakthrough

The following steps, if used in full, are an effective and powerful was of resolving issues. Followed rigorously, it will enable you to “breakthrough” an issue blocking your project. The toughest part is to declare that you do, in fact, have a problem. Doing this puts you in a position of responsibility and enables you to proceed. Be careful, however; the natural tendency will be 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 in a facilitated workshop, with those who have a stake in the issue, recording the input from the group on flip charts. Follow all the steps and do them in the right order. Do not jump ahead.

1. Declare that you have an issue!

   Tell everyone who could possibly have an impact on resolving the issue, even those you do not want to know about it. Don’t hide the issue. Merely putting it in your issues log is not enough. Actively tell people!

2. Stop the action

   Call everything around the issue to a halt. Don’t react. Don’t try to fix it. Relax.

3. What, precisely is the issue?

   Exactly what did or didn’t happen? When? Distinguish between fact, gossip, and rumour. Then, describe the issue in one sentence. This is the sentence you should write in the issues log.

4. What commitments are being thwarted?

   Which of your commitments is being thwarted, stopped, or hindered by the issue? Remind yourself of the reasons for the project in the first place and the drivers for action.

5. What would a breakthrough make possible?

   What would the resolution of the issue, under these circumstances, look like? What would it make possible? Are you really committed to resolving this and furthering these possibilities? If so, continue. If solving the issue will achieve nothing, then stop now.

6. What’s missing? What’s present and in the way?

   Take stock of the entire project. What’s the situation now (stick to facts!)? What’s missing, that if present, would allow the action to move forward quickly and effectively? What’s present and standing in the way of progress?

7. What possible actions could you take to further your commitments?

   Leave the facts of the current situation and what is missing in the background. Stand in the future, with a breakthrough having been accomplished and create an array of possible actions that brought you to this point. Look outside your paradigm. Think from the future, back to the present. Think laterally.

8. What actions will you take?

   Next, narrow down the possibilities to those with the greatest opportunity and leverage, not necessarily the safest and most predictable! Then, choose a direction and get back into action. Make requests of people and agree the actions needed. Hold them to account on those actions.

(Adapted, with kind permission of the London Peret Roche Group, from their “Breakdown to Breakthrough” technology. Copyright © 1992, N J.)