Chapter 12

Resolving Issues and Keeping Track of Detail

In This Chapter

Dealing with issues

Controlling changes

Keeping track of your assets with configuration management

Allocating responsibilities

Issue management has a lot in common with risk management, both in general and within programme management, because many issues are risks that have happened. I cover managing risk in Chapter 11 and suggest you read that chapter in combination with this one. Inevitably certain topics overlap between risks and issues: for example, here I cover which programme individuals need to be responsible for which tasks.

In this chapter I look at the specifics of resolving issues. I also consider the associated subject of change control: issues can lead to unexpected changes; therefore you need to control these changes. Doing so is much easier if you understand the configuration (or versions) of the different assets in the programme. If configuration management is a new term to you, for the moment just think about it as version control.

I consider configuration management alongside issue management, rather than as part of quality management (which I cover in Chapter 13), to reflect the way that the MSP manual and exam syllabuses are laid out. But you can consider the subject as sitting here or with quality management: it doesn't really matter. In reality, all these subjects have a strong connection between them.

Resolving Issues

Issues are anything that's happened in your programme that you haven't planned for. Therefore you need to do something about them; you need to resolve the issues.

Think about the types of issues you're going to be dealing with and describe your approach to issue resolution in your Issue Management Strategy document (see the later section ‘Describing your Issue Management Strategy’). You also need to share with your colleagues a standard process or cycle for managing issues and to record issues in an Issue Register (check out the ‘Using the Issue Register’ section later in this chapter.

You can probably guess that the issue strategy and register and the equivalent risk strategy and register that I describe in Chapter 11 have a lot of similarities.

You may like to use the term issue resolution rather than ‘issue management’, because it emphasises that when an issue pops up you need to deal with it – resolve it.

Recognising the sources of issues

Of course issues can come from anywhere, but the following are typical sources:

• Escalated from projects
• From external to the programme
• From within the programme
• Generated by stakeholders
• In operational areas
• Programme constraints
• Related to benefits management

Describing your Issue Management Strategy

Your Issue Management Strategy document describes the mechanisms and procedures for resolving issues as follows:

• How issues are identified, captured and assessed
• How issues are managed
• Responsibilities – at programme level
• Responsibilities – at project and operational levels
• Change control process
• More detailed change control procedures (if you have any)
• How you plan to handle exceptions, particularly those triggered by issues
• Impact assessment
• The difference between project and programme issues
• Severity criteria
• Categorisation
• Monitoring and evaluation
• How you plan to judge effectiveness
• Associated strategies; for example, a cross-reference to the Risk Management Strategy

Setting up an issue-management cycle

Figure 12-1 shows a simple issue-management cycle, and I discuss the various aspects in this section, moving clockwise around the figure (if you start to feel dizzy, you're reading too fast!).

Capture

The first thing to do is to capture the issues.

You have to go further than writing the issues down: you need to analyse them to determine the type of issue. You can have someone in the Programme Office do this task.

You need to categorise issues in some way so that you can assess their severity and the impact. Then, if significant, you allocate the issue to someone. If the impact is sufficiently high, you may need to escalate it.

Examine

Here's a checklist of things to bear in mind when examining an issue:

• Consider enough alternatives. If business as usual says an output isn't fit for purpose, you can put it back into the project to be changed; you can replace it with a manual procedure until you create something better in the next tranche; or you can delay that whole piece of change to the next tranche. A surprising number of alternatives is always available.
• Balance the following:
  • The advantage of dealing with the issue against the impact of dealing with the issue on cost, time and possibly on risk.
  • Secondary risks that may arise as a result of resolving the issue.
• Consider broadening your assessment. Think about the impact on other programmes and other projects inside or outside your programme.

You're sure to encounter mandatory issues, in which case the aim is to minimise the impact but possibly also to exploit opportunities.

Propose a course of action

Having examined each issue, you need to propose a course of action.

Thinking about different courses of action so that you have a good range of options to present can be difficult. To my mind the easiest way to envisage different courses of action is to think back to the analysis you did. Reflect on the impact on, for example:

• Blueprint
• Business Case
• Operational performance
• Programme performance
• Projects Dossier
• Risk Profile
• Stakeholders
• Suppliers

Next, propose a course of action that minimises the impact in each of these areas. I propose one course of action with no or minimal impact on the Business Case, another one with no or minimal impact on the Blueprint and so on.

In each case the impact on other aspects of the programme probably increases. But by taking this approach you get a good range of possible courses of action.

Decide

Having assembled a set of options, you simply make a decision. At this point you need to look at the Issue Management Strategy to understand who has the appropriate authority:

• Is it the Programme Manager?
• Is it even the Senior Responsible Owner (SRO)?
• Do you have some specialist individual or group of people who can make the decision, such as the Business Change Managers?

After the right person makes the decision, you need to plan the change. Consider aspects such as:

• Contingency within the plan.
• Allocating resources to carry out this change.
• Having a fall-back if the changes are more complex than planned.

You can then use the change control procedures that I discuss later in this chapter in the section ‘Taking Control of Changes’.

Implement

Of course, you need to implement the action. The Programme Manager or someone delegated by that person has to communicate what you're going to do:

• So that actionees (see Chapter 11 for a definition; you can have an issue actionee just like a risk actionee) are aware of what to do; they in turn inform those who raised the issue that you are indeed taking action.
• To inform stakeholders so that they're aware that something is going to happen in their area of interest.
• To demonstrate effective management.

You also need to update various documents. I suggest:

• Issue Register
• Any affected plans
• Benefits Profiles
• Configuration management information
• Business Case

Using the Issue Register

The purpose of the Issue Register is to capture and manage actively the programme issues. It's the central log of all reported issues facing the programme, and you use it to assist with managing the issues so that they don't affect the programme adversely. Look at Table 12-1 for the make-up of an Issue Register.

Table 12-1 Issue Register Composition

In the smallest programmes the Issue Register is just a simple spread sheet. In a more reasonably sized programme you may require a series of delegated Issue Registers (managed, for example, by Project Managers) as well as a central Issue Register.

Think about the level of access that central Programme Office staff members have to Issue Registers. You can undermine the Project Managers’ authority if Programme Office staff look regularly at their Issue Registers. On the other hand, Project Managers may not be best placed to consider the wider programme impact of their issues, so Programme Office staff members do need to have some oversight of project Issue Registers.

Taking Control of Changes

Change control is a mechanistic subject linked to keeping track of different versions of anything that's important to the programme. Don't confuse it with change management, which is the softer human side of change that I discuss in Chapter 20.

Your organization may already have sophisticated change control procedures in place, in which case these need to be the starting point for your programme change control procedure. However, if the subject is new to you, this section provides a straightforward change control procedure that gets you started.

Taking steps to control change

Here are the all-important change control steps to follow:

1. Capture and define the change. You need to record the change and why it's needed in order to deal with it in an orderly way.
2. Allocate priority to the change. You do so to help people understand the urgency and the significance of the change.
3. Assess the impact of the change. Make sure that the impact assessment is broad-ranging. You have to assess the impact across the whole of the programme; therefore you may need to look at documents such as the Programme Plan, the Blueprint, the various Benefits documents and the Project Dossier in order to be able to assess the overall impact across the programme. (Chapter 7 describes the programme documents.)
4. Analyse your options. You have to identify and analyse a sufficiently wide range of options and test the potential solutions that emerge from the options analysis.
5. Authorise resolution. At an appropriate level, as described in the governance structures, you have to obtain authorisation to resolve the change.

   Don't forget that one possible resolution for a change request is to do nothing.

6. Implement the change. Only now do you implement the change and subsequently monitor the effects of the change for deviations from what you anticipated. Bear in mind that one change may trigger a series of other changes.
7. Review effectiveness. Step back and review the effectiveness of the individual changes and your overall change control procedure.

Considering change control and issue management

The change control procedure in the preceding section is very similar to the issue management cycle (see the earlier Figure 12-1). Some organizations combine the processes and others prefer to keep them separate. In the latter case, everything goes through issue management, but only those issues identified as changes are passed across to change control. Combining or keeping separate these two processes is just a matter of what the people in the programme are familiar with. My preference is to leave well alone, unless the boldness of the change that the programme's going to bring about means people need to be shaken out of their existing ways of thinking, in which case I deliberately put in place a different way of working.

Getting to Grips with Configuration Management

I'm an aeronautical engineer by training, so I've been managing configuration since I left school; to me it's second nature. But most programme professionals aren't configuration management experts, so in the programme management world I'm considered a little strange (at least I think that's the reason!). When you start to implement changes you need particularly strong configuration management, which is just the way in which different versions of different assets sit together in a configuration (I'm working on a laptop with a second screen attached, remote keyboard and a fancy mouse. Together they are a configuration. If I wanted to give it a fancy name, I could call it my desktop computing environment).

In this section I provide a few definitions around configuration management, in case you're unfamiliar with the concept, and a simple process you can use. If you're already experienced with configuration management, for example, if you're a project manager or an engineer, by all means bring more sophisticated local procedures into your programme.

My goal is to give you just enough information about configuration management so that you can appreciate its significance to your programme. After that you almost certainly need to go out and recruit, part-time or full-time, someone with experience of configuration management.

Configuration management isn't just about managing one class of asset; it's about managing all the assets in the programme. So, for example, if as an IT professional you're used to managing the configuration of software and IT equipment, don't forget that other people in the programme are managing the configuration of everything from offices to people's skills. Instead of imposing your configuration management approach on others, you may need a range of configuration management approaches across the programme.

Configuring assets

Configuration management looks at the configuration of sets of assets. The purpose of asset management is to identify, track and protect the programme's assets including:

• External assets: Exist outside the programme but can affect it.
• Internal assets: Interfaces between projects and the programme, for example, project progress reports.
• Programme assets: For example, the Blueprint and Programme Plan.
• Project outputs: the things that the project bills and delivers into business as usual.

If you go into an organization to set up a programme, you're certain to find people in business as usual who already carry out asset management. Just look at the serial number on your office computer for an example of how someone tracks assets. So asset management is a straightforward way to communicate with business as usual when carrying out configuration management.

An asset that's subject to configuration management is called a configuration item. It may be a component of a product, a product or a set of products in a release.

I cover quality management in detail in Chapter 13, but for now I just want to note the two-way relationship that exists between quality management and configuration management. See Figure 12-2 for an illustration of this relationship.

Moving beyond asset management into configuration management

With configuration management, your aim is to control the development of and changes to items important to the programme:

• Programme management documentation
• Assets, for example, products or services
• Programme dependencies
• External items

Configuration management tracks interrelationships between assets as well as the assets themselves. In your programme you live in a world of change; you don't just need to know the status of the assets, you also need to know how those assets work together in a configuration.

Carrying out configuration management

You undertake five activities when doing configuration management, as I describe in the following sections.

If you find yourself thinking that this process looks too sophisticated and beyond what you need for your programme, bear in mind that most programmes require detailed and rigorous configuration management. Although not a high-profile activity, it can be a vital one.

Planning

The first step, inevitably, is planning. Based on the Blueprint and the organization's approach to configuration management, you need to decide what level of configuration management is appropriate for the programme and plan how to achieve it. Carrying out configuration management at a very precise level of detail can be extremely expensive.

You need only to carry out configuration management of assets where it's essential. I'm always amused when I see a document that's going to be valid for only a few days, but contains one page of information and several pages of configuration management data: in other words, much too much configuration management.

Identifying

Having decided the level at which you're going to exercise configuration management, you set out the requirements for configuration management that all projects should adopt.

Identify all the programme-level configuration items that are to be created during the programme and the dependencies between assets and between configurations. Set up a system for describing configuration items (which I define in the earlier section ‘Configuring assets’).

In fact, you're already familiar with systems for describing configuration items. The part number on anything from your kettle to your jacket is part of just such a system set up by the manufacturer.

Controlling

Having identified configuration items, you need to control them. When the Programme Definition Document is agreed the configuration of the programme itself is baselined. This happens at the end of Defining a Programme stage as I describe in Chapter 7.

Baselined means you take a snapshot of the version at that time which never changes. So if anything does change, you create a new version. Most programmes change over time, and any changes to the configuration must be properly version controlled, following procedures described in the Information Management Strategy.

Version control also includes managing the programme's management information. The programme needs to set out how to manage dependencies on external assets in the event of external assets being revised. Control over an asset passes to business as usual when that asset is agreed to be no longer the responsibility of the programme.

Accounting for status

You need to be able to account for the status of those items that are under configuration control. This task involves maintaining current and historical information for the following:

• Each configuration.
• The configuration items (assets).
• All relevant dependencies (external to the programme as well as inter-project dependencies).

Verifying the status

As the process is getting quite rigorous, you need to verify the status of configuration items. This job includes auditing the programme to ensure conformity between documented configurations and the actual status of products and configuration items before delivery to operations. You also need to verify dependencies as part of an audit, because they may have moved or changed over time.

Confirming Risk and Issue Areas of Focus

Getting clear the areas of responsibility for risk and issue management avoids duplication, and more importantly prevents some tasks falling between the cracks. Here's a checklist for you (to discover more about these roles, flip to Chapter 9):

• Senior Responsible Owner:
  • Authorises the Risk and Issue Management Strategies.
  • Controls risks and issues that affect alignment with Organizational Objectives.
  • Initiates assurance reviews of risk and issue management effectiveness.
  • Owns strategic risks and issues.
• Programme Manager:
  • Develops and implements the Risk and Issue Management Strategies.
  • Designs and manages the risk and issue-management cycles.
  • Manages the aggregate level of risks and issues.
  • Assures adherence to the risk-management principles.
  • Allocates risks and issues as appropriate.
  • Ensures that people with the right authority undertake change control.
  • Ensures that stakeholders understand the impact of risks.
  • Defines clear rules for escalation, cascade and thresholds. (Another word for cascading is delegation – the circumstances when you push something down to, say, a project. You also need to be clear about the threshold for those escalations and delegations. For example, projects have to escalate issues with a budget greater than five per cent of the project budget.)
  • Owns programme-level risks and issues.
  • Rolls out consistent language for risk management.
  • Communicates progress on the resolution of issues.
  • Escalates items that cross programme boundaries to the SRO.
  • Designs and implements the configuration-management system.
• Business Change Manager(s):
  • Manages risks linked to operational performance and benefits.
  • Ensures that operational risks, including opportunities and issues, are managed.
  • Manages risks that impact on business performance and transition.
  • Identifies operational issues to the programme.
  • Identifies opportunities from the business operations to the programme.
  • Contributes to impact assessments and change control.
  • Monitors and reports on business performance issues during transition.
• Programme Office:
  • Manages and co-ordinates information and support systems.
  • Maintains the programme Risk and Issue Registers.
  • Establishes, facilitates and maintains the risk and issue-management cycles.
  • Provides support and advice on risks and issues to projects.
  • Co-ordinates risk and issue-management interfaces with projects.
  • Maintains the configuration management system.
  • Helps with the change control steps.