Issues Management | Managing Risks and Issues

An issue is something that has happened and threatens the success of the programme. Examples of issues are:

• 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 sign-off of a critical document or deliverable;
• a reported deviation of a deliverable from its specification;
• a request for additional functionality;
• a recognised omission from the programme scope.

When an issue is identified you should:

• record it in an issues log;
• agree and take action to resolve the issue;
• regularly update the progress commentary on the log;
• once the issue has been resolved, record the method and date of resolution in the log;
• report new, significant issues in a regular programme progress report.

You should expect a large number of issues to be raised at the start of the programme or at the start of a new stage within the programme. These will mainly be queries from people seeking clarification that aspects of the programme 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 programme 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. Also, 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 that can help to identify the core problem. Once this is solved, a number of issues can be struck off in one go.

'Scope creep' is a phenomenon where a programme over-runs its agreed time-scale and budget due to many extra (often minor) 'features' being added in an uncontrolled manner. For this reason, it is often easier to bundle a number of small changes together and assess them as a whole, choosing to implement only those that will further the objectives of the programme. At the other end of the scale, it is wise to consider delaying the addition of a major change until after the programme is completed and introduce it as a second phase programme. Remember, the primary aim of a programme is to fulfil a stated business need. As long as this need is satisfied, fine tuning, enhancing or embellishing the outputs are potential wastes of resources.

At some point, a time may come on a programme when an issue arises that cannot be resolved whilst keeping the programme viable. Either a time window will be missed or costs will be so high that even a marginal cost analysis leads to the conclusion that it is not worth continuing. In these cases, a decision to terminate a programme might be treated as a success, as there is little point in continuing with a programme that is not viable in business terms. However, such a situation would demand serious questions being raised about the risk and issue management regime in place at the time.

Figure 1 shows how a well-managed programme retains a decent shape all the way through, meaning that key activities in the programme are being well managed and aligned and harnessed. Benefit delivery is good and on track and the governance structure is able to contain the complexity to within manageable proportions. On the other hand, if the complexity becomes unmanaged, what then happens is that a significant shortfall of benefit takes place: either benefit streams themselves are delayed, or costs rise significantly as efforts are made to contain the event or sequence of events that have created the unmanaged complexity situation.

 
Figure 1: Risk and issues management.

This point illustrates something mentioned earlier about the need to retain a highly diligent focus on costs and benefits, and also to make sure that key milestones are achieved and to be in a position to have the processes in place to take swift remedial action if it is recognised or identified that things are moving out of kilter.

An unmanaged complexity situation can be very draining and very wearing on members of the programme team and indeed the higher steering boards. Therefore, it is highly beneficial and desirable to prevent those situations happening in the first place than to have to deal with them, although it is almost inevitable that there will be occasions during a complex programme extending over many years when unmanaged complexity will strike. The ability to be able to deal with that situation is absolutely fundamental to the overarching programme governance framework.

Returning to the theme of keeping major items in alignment, Figure 2 shows how the three core pillars of the HR transformation programme — technology, process and people — are kept in alignment around a particular milestone.

 
Figure 2: Making it happen — illustration.

The point of this is really to show how a number of inter-related activities need to be carefully managed in the build-up to a critical go-live situation, and how the state of each of those major activities would need to be regularly tested and assessed as the days tick by in order to minimise or eliminate risk.Makes reference to organising these bundles of activities into 90-day periods, to give more visibility and focus around deliverables.

Finally, it would be highly recommended for practitioners to constantly review and assess a number of questions listed below. Having reliable answers to these questions provides an insightful perspective on the programme overall.

Business Management

• Is the programme still a good business proposition; are the risks acceptable?
• Is the business ready to take on the operation of the solution?
• Are the benefits/results monitoring systems in place?
• Are current estimates of the costs and benefits in the business forecasts?
• Are all internal and marketing communications designed and ready?

Programme Control

• Has a programme health check been done and found to be acceptable?
• Are you sure beyond reasonable doubt that the solution will work?
• Have all stakeholders reviewed and approved those deliverables requiring their input?
• Have all purchases that affect service delivery been properly completed?
• Are all support agreements in place?

Ongoing Evaluation

• Are resources in place to monitor adequately the costs and benefits against the business case?

---

Case Study 1: Scottish Executive (SE) e-HR and HR Transformation

This case study is used to illustrate how deficiencies in governance and related protocols,  led to a serious and disruptive delay in the deliverables of a major government HR Transformation programme. The lessons learned underpin the critical importance of a robust governance framework.

The SE, known as the Scottish Government since August 2007, is responsible for most of the issues of day-to-day concern to the people of Scotland, including health, education, justice, rural affairs and transport. It managed an annual budget of more than £30 billion in 2007–2008. It embarked on an ambitious HR transformation programme in 2005, consisting of e-HR and HR Transformation projects, which soon ran into major difficulties, prompting an official review conducted by Bill McQueen in 2006. The review was tasked with

Establishing the current state of the Scottish Executive's (SE) e-HR and HR Transformation projects, the circumstances and causes which threatened deliverability, whether the conduct and management of the projects was compliant with relevant protocols and best practice, whether the projects remained deliverable and to make recommendations.

Managing Risks and Issues

Risk Management

Risk is any uncertainty, potential threat or occurrence that may prevent you from achieving your objectives. It may affect timescale, costs, quality or benefits. All programmes are exposed to risk in some form, but the extent of this will vary considerably.

The purpose of risk management is to ensure that:

• Risks on programmes are identified and evaluated in a consistent way.
• Recognised risks to programme success are addressed.

You cannot use risk management to eliminate risk altogether, but it will enable you to avoid it in some instances or minimise the disruption in the event of its happening in others. When a programme sponsor approves a programme, he or she does so in full knowledge of the stated risks, and accepting the consequences should things go wrong.

The steps are:

• Identify: Log all the risks that may potentially jeopardise the success of the programme.
• Estimate: Review each risk in turn:
  • assess the likelihood of the risk occurring;
  • assess the severity of the impact on the programme if it occurs.
• Evaluate: Use a risk matrix to determine the 'risk category' (high, medium or low) to help you assess how acceptable the risk is.

Depending on the risk category, take action as follows:

• High risk: Take definitive action to prevent or reduce risk. Reconsider the viability of the programme before proceeding further.
• Medium risk: Take action to prevent or reduce risk where appropriate. Prepare a contingency plan if risk cannot be reduced. Manage risk and implement contingency plan where necessary.
• Low risk: Take action to reduce risks if cost effective. Monitor risk — it may become more significant later.

Taking positive steps to reduce the possible effects of risk is not indicative of pessimism, but is a positive indication of good programme management. Many possible options exist for reducing risk, including:

• Prevention, where countermeasures are put in place either to stop the threat or problem from occurring or to prevent it having any impact.
• Reduction, where the actions either reduce the likelihood of the risk developing or limit the impact on the programme to acceptable levels.
• Transference, which is a specialised form of risk reduction where the impact of the risk is passed to a third party via, for instance, insurance.
• Contingency, where actions are planned or organised to come into force as and when the risk occurs.
• Acceptance, where the organisation decides to go ahead and accept the possibility that the risk might occur and is willing to take the consequences.

Consider also:

• bringing risky activities forward in the schedule to reduce the impact on the programme outcome if they are delayed;
• modifying the programme requirement to reduce aspects with inherently high risk, for example, new, leading-edge technologies;
• allowing appropriate time and cost contingencies;
• using prototypes and pilots to test the viability of new approaches.