Chapter 21. Issue management

Issues should be managed at an appropriate level (portfolio, programme, project or work package) based on the source and extent of the impact. The more complex the issue, the more detailed the assessment of impact and cause needs to be. This supports proportional responses to issues.

Where possible it is helpful to align risk and issue management frameworks, for example, using common techniques and tools for identification and assessment, and consistent metrics to monitor and report. This supports efficiency and helps track the relationship between risks that are causes of issues, and residual risks which result when responding to an issue.

The risk appetite, described within the risk management framework, supports the design of the issue management framework. The risk appetite influences the threshold levels of issue exposure, called issue tolerances. These tolerances can be set at a portfolio, programme, project, work package level, for individual issues, or across issues of a common type in aggregate. These, when exceeded, should trigger some form of response, such as escalation to a higher-level decision maker to decide a response or raise a change request. The triggers for escalation should be described in the issue management framework.

When first identified, the issue might only represent a symptom. A single cause could result in many symptoms which might be identified in different areas of the work and have already been identified as seemingly unrelated issues. There might also be unidentified issues relating to the same cause. By identifying the root cause all these issues can be addressed together. The issues manager should identify related issues, reallocate ownership or redefine the issues, or all, to ensure a single-issue owner to oversee the response, even if multiple teams are working on resolving different aspects of it.

Openness and collaboration on open and closed issues help promote wider understanding of issues across the work and their typical sources. It also helps build confidence that problems can be overcome and opportunities exploited, as well as being a check when a similar issue resurfaces later. The record of issues should be open to the core team, but care should be taken in sharing issues more widely, both to protect safety and security, and to ensure that information is presented in context and communicated appropriately (see Chapter 26: Stakeholder engagement).

Take a strategic view of likely requirements for issue management. This can be by developing an understanding of the context and nature of the work, including its scale, complexity and risk profile, as well as its objectives and desired outcomes.

Understand the wider governance and management framework for the sponsoring organisation, portfolio, programme or project, as appropriate. Particularly, consider how it connects to risk management and change control, and how issues will be escalated and reported between different levels of the project delivery hierarchy.

The data and detail needed in the issues register to manage issues effectively varies depending on the needs of the individual portfolio, programme, or project. Simple portfolios, programmes and projects need less information and data. Different aspects of the work might require different information to other aspects. It is also important to consider the context as often information from one piece of work can be collated for reporting with other work within the same portfolio,  programme or project, for example where there are common issues.

Unless the choice of data, level of detail and categorisation are compatible, aggregated reporting can become meaningless. On the other hand, sufficient information should be recorded to enable decisions and action to be taken. The choice of tools and the experience of the team can also influence the information to be gathered and held.

There are often legal, regulatory or policy requirements which require the formal reporting of certain types of issues. Such reporting needs to be built into the issue management framework. Examples of legislation covering reportable incidents are the Reporting of Injuries, Diseases and Dangerous Occurrences Regulations 2013, and the UK’s General Data Protection Regulations (GDPR) which sets requirements on personal data breaches (see Chapter 24: Information and data management).

Part B: Tailoring and adopting can also help with this as it sets the context for project delivery in different sectors.

Issue management requires a systemic approach to identifying, assessing, responding, monitoring, reporting, and closing individual issues through the life cycle. It also requires a framework to govern and manage these activities.

These related activities are shown in Figure 21.2. These may be sequential or iterative, depending on the nature of the portfolio, programme or project.

The approach to issue management should be defined including any processes, methods, tools and techniques to be used (see 21.6.2 on preparing to manage issues). This forms part of the overall governance and management framework for the work (see Chapter 4: Governance and management). The issue management framework should be developed at the start of the life cycle and maintained to address relevant feedback from its use.

This activity looks at issues in aggregate to gain an overall view of the issues being faced and their impact on the objectives. This could result in consolidating or splitting issues if necessary, or the reassignment of owners (see 21.6.1.3 on understanding the root cause of an issue). The activity can also include the provision of support to issue owners, if needed.

Looking at the issues in aggregate supports:

• making sure each issue has a named owner
• understanding whether the overall level of issues threatens the viability of the work 
• assessing by categories, such as the type of issue, source, cause or impact and being able to provide corrective actions that can resolve multiple related issues at once
• identifying patterns that point to a common cause, so preventative action can be taken

Throughout the life cycle of a portfolio, programme or project, issues need to be reported on regularly so that the portfolio director, senior responsible owner and their respective boards have an up-to-date understanding of issues such as problems or concerns being faced and significant individual issues which need their attention.

The context and nature of the work may change throughout the life cycle. Therefore, the issue management framework should be under continuous review to ensure it remains effective. For example, early in the project life cycle the issue thresholds for escalation might be lower than during the delivery stage.

An issue is identified when it is first recognised and formally registered. The raising of an issue could be formal or informal, such as a risk occurring, a submission of a query or concern from a member of the team or stakeholder. Once recognised, the issue should be verified and recorded in the issue register.

The issue should be assessed by the issue owner to understand its cause and the impact it has on the objectives if not resolved. If the cause is not fully understood there is a risk that the impact could be incorrectly determined and the wrong actions might be taken.

The issue should be classified in accordance with the pre-defined categories in the management framework. When assessing an individual issue, the issue owner and relevant stakeholders should seek to understand aspects such as:

• cause, the specific factors that led to the event, query, concern or change to be identified
• event, query, concern, change request, what has happened, or been raised
• impact, describing the effect of the issue on the objectives

Various techniques can be used to determine the root cause to the likely impact. Guidance to support analysis can be found in the Government Functional Standard for Analysis and in The Aqua Book (requires sign in).

This information should be recorded and updated in the issue register.

Once an issue has been assessed, the response should be determined and noted in the issues register. The response can range from doing nothing, by accepting the impact, to taking corrective action such as making changes to the work within current tolerances or seeking agreement to a change outside existing tolerances.  In the case of a major issue which cannot be resolved, the issue should be escalated to the appropriate level for a decision on possible termination of the work. 

The response actions should be proportionate to the impact and be value for money. The impact of a risk response on the definition of the plan, solution design and management documentation needs to be considered. If any changes are required to these, this could require a formal change request to be initiated (see Chapter 22: Change control).

The issue owner should assign actions to one or more named individuals, known as the action owner(s) to undertake this work.

The actions taken in response to the issue should be monitored to check they are effective.  Those who need to know about the issue should be kept informed. As a result of monitoring, the responses can be changed. This could be because the initial response had insufficient effect or because more information on the issue itself is available.

The issues register is a primary source of management information used in reporting (see Chapter 18: Reporting) and should be updated on an ongoing basis to reflect the current understanding of the issue, its impact and the response actions.

An issue should be closed once it no longer needs monitoring and the response actions have been completed. There should be an agreed procedure for closing issues, for example seeking approval from the appropriate decision-making body in the team, as determined in the governance and management framework.

Closed issues should be kept on the register, stating when and why they were closed and by whom as this information is important for managing aggregated issues, identifying likely sources of risks (see Chapter 20: Risk management), for maintaining traceability (see Chapter 23: Traceability management), and when conducting lessons learned reviews (see Chapter 38: Learning from experience).

Once the work has been completed and issue management is no longer needed, the management framework should be merged into the management framework for the solution or closed, retaining information and data in accordance with the delivery and sponsoring body’s information retention policy.