Project Delivery Process D190

D190 - Issues - control, escalate, resolve

DEFINITION

Define, agree, instigate and operate procedures for the identification, control and resolution of issues.  Issues that arise during the design work are noted, logged, controlled and resolved.  Escalation and tie-breaking mechanisms are used where necessary.

SUMMARY

Issues are inevitable in any project.  They arise for many reasons.  Often they are due to changing needs or improved understanding.  Occasionally they result from misunderstandings, poor communication or errors made in the work or management of the project.  A particular form of issue occurs when a gap is identified between the client organisation’s requirements and the capabilities of the packages.

With a complex project, issues are particularly likely to occur due to conflicting needs and designs within the different topics of the overall project.  No amount of scheduling of the tasks or review processes could totally avoid such problems.  The answer is to identify such issues and provide an efficient mechanism for their resolution.  The issues resolution process links directly with the Implementation Papers process (see D400).

The issues resolution method is used both for the resolution of issues noted during the development of the various Implementation Papers and also for issues recorded by participants.  Issues forms and a control log may be used.

The issues resolution mechanism must be made known to all participants in the project.  This document may be known as the Issues Control Protocol (ICP).  It will set out the rules and procedures and provide example forms to be used.  All participants and other parties concerned should be encouraged to report issues wherever appropriate.

Any issue leading to potential changes in the project’s deliverables, timescales or costs should be managed in the same way as a change request - note the related activity of Change Control - see process D140.  In general, the best value for money will be achieved where the client organisation’s requirements are adapted to make best use of the package rather than undertaking unnecessary modifications or custom development.  The full effects of any issue may be measured against the project’s “Benefit Model”  where one is in use.

The Software Application Implementation Project  does not stipulate a fixed method for applying issues control.  It may be defined by the project management methodology that is in use.  In this process, the basic needs are identified and some example techniques are illustrated.

PATH PLANNING GUIDANCE

Optional - may be used where there are several people involved in the project such that issues need some form of formal control.  (When no formal mechanism is in use, informal techniques should be used to encourage the identification and resolution of issues.  Issues should always be noted to ensure they are not forgotten about.)

DEPENDENCIES

Prerequisites (Finish-Start):

• none

Prerequisites (Finish-Finish):

• none

Dependent procedures (Finish-Start):

• project termination cannot be completed until all unresolved issues are accounted for

RECEIVABLES

• none

DELIVERABLES

• Issues Control Protocol (ICP)

TOOLS

• Examples: “Issue Log”
• Examples: “Issue resolution form”
• ITPM Core Guide
• Benefit Realisation Core Guide - Benefit Model

DETAILED DESCRIPTION OF TASKS

The issue about issues

In the same way that changes are almost inevitable during the life of a project, issues also arise and have to be resolved.  Issues normally concern either the system being implemented or are organisational.  Areas where technical / design issues arise include:

• the approach being taken
• the techniques being used
• the design itself
• the proposed solutions to the systems requirements and problems
• gaps identified between the client organisation’s requirements and the capabilities of the package.

Organisational issues can involve conflicts within the project or between the project and other parts of the organisation.  They include:

• project team performance problems
• possible misunderstandings of project scope, activities and directions
• problems beyond the project team’s control
• external issues

Issue are often less tangible than changes, especially when they relate to people’s performance, roles or relationships.  It is all too easy to treat them informally, and as a result to et them drift or to forget about them altogether.  This can be disastrous to a project.  To avoid it happening, all issues which cannot be resolved as they arise must be logged and followed up.  The project manager may prefer to keep a separate log for sensitive issues, which is not open to access by the whole team.

The resolution of an issue often results in a change request.  For example, an issue might be a user’s observation during testing that he cannot easily reconcile the input from a feeder system.  As a result of the issue resolution process, the need for program changes in the interface extraction program might be identified - thus the issue is resolved by switching to the change control procedure.

In general, the best value for money will be achieved where the client organisation’s requirements are adapted to make best use of the package rather than undertaking unnecessary modifications or custom development.  The full effects of any issue may be measured against the project’s “Benefit Model”  where one is in use.

Cross-functional / inter-topic issues

A particular type of issue occurs frequently in a complex project.  This is where the design and issues are so complex that conflicting needs or solutions have been defined by different members of the project team whilst addressing different topics.   For example, in the implementation of integrated systems for an airline, the sales and revenue functions required a monthly processing cycle whereas the flight scheduling and operations operated on a two-weekly cycle tied into the timetable and staff rosters.  The packages involved could accommodate either of these requirements but could not meet both at the same time.  Without review and issues resolution processes, such a problem might not be identified until a late stage in the systems integration, yet it could be fundamental to much of the design.

To address this type of issue, the Implementation Paper processes (see D400) include the review of papers by other project team members and specific provision for issues to be identified and resolved even after a topic has been finalised “in principle”.

Implementation papers may include a section detailing any outstanding issues raised regarding the topic in question or raised in other areas which might affect the topic.  Papers remain open for modification as the result of such issues until the time that they need to be “frozen” in the interests of providing a solid basis for finalising the implementation.  After the topic is frozen then subsequent issues can only be resolved by formal change request / change control procedures (see process D140).

Defining the Issues Control Protocol (ICP)

The Issues Control Protocol (ICP) is simply the definition of how issues are handled.  If there is not a technique within the project’s chosen project management methodology, instructions may be drawn directly from this text and the example below.

The purpose of the ICP is to agree and publicise the process of issues control and resolution and, in particular, how to resolve disputes.  It will:

• describe the concepts,
• define individual responsibilities and authority,
• set out the detailed procedures to be used, and
• provide sample forms etc.

The Issues Control Protocol should be agreed with the client organisation including the steering committee and any key management.  It should define in particular which managers “own” which aspects of the requirements or solution.

Defining authorities, and responsibilities

Normally issues can be resolved by discussion and agreement between the parties concerned.  From time to time it will prove impossible or impractical to gain consensus amongst all those involved.  To be prepared for such circumstances, it is useful to agree in advance

• who has the deciding authority over each issue, and
• when and how issues should be escalated to higher levels of management.

A useful technique can be to get the organisation to decide upon “guardians” for each aspect of the data or functionality.  These guardians would always get a casting vote to decide any disputed issue provided it was within their defined scope.  It is often to easier to get such agreements in advance when there is no burning issue to be fought over.

Details of these escalation procedures and individual responsibilities would be agreed and published in the Issues Control Protocol (ICP).

Example procedure

1 - Initiate the request and update the Issue Log

Ideas for changes can arise in many ways, such as:

• from unsolicited Issues Resolution forms from team members
• in the comments received from team members (eg by using a “comments” section on weekly timesheets)
• during meetings with the project team or with users
• by memos notes, etc
• as the result of quality assurance reviews
• as the result of testing or prototyping

It is essential to recognise and record these as they arise.  The best way of doing this is by keeping a central Issues Log, accessible to the whole team, but maintained by (or on behalf of) the project manager.  A commonly heard remark when a critical issue materialises towards the end of a project is “but I warned you about that in a team meeting months ago but nobody listened to me.”  If these procedures and practices are followed this type of problem would be eliminated.

2 - Complete the Issue Resolution form

Once an issue has been recognised it should be properly documented.  A standard Issue Resolution form should be used (see Examples: “Issues Resolution Form”).  Note that it is normal firstly to log the issue and then to complete the full form afterwards.  If issues are only recognised and noted when the official form is filled in then they are likely to be forgotten due to other pressures.  The forms can be completed by anyone concerned with the project, and their use should be encouraged.

3 - Assign staff and establish options

Most issues will require careful consideration to establish the options available.  The project manager will often be able to delegate the work to another member of the project team, or it may be possible to ask a representative of each side in a “dispute” to work together to supply a joint recommendation.  Time spent during investigation should be booked to an unplanned task opened for the purpose within the appropriate phase of the project.

4 - Assess impact

The impact of each option must be analysed in terms of costs, benefits, timescales and other tasks affected.  The team member who established the options will normally do this initially, but the impact should be reviewed by the project manager who has a wider understanding of the overall project.

5 - Decide and agree on action

Normally the project manager plus the initiator of the issue and any team members involved will be able to decide upon a course of action.  If this requires change to project plans or budgets beyond the project manager’s agreed authority, Steering Committee approval will also be required.  Occasionally, when the options are not clear cut, they may be referred to the guardians or to the Steering Committee for fuller discussion of the issues

The Issues Log should be updated to show the result.

If the resolution procedures are to work successfully, it is important that the log should be inspected at least once a week by the project manager, and progress on any unresolved issues should be pursued.  Similarly, log entries not backed up by Issue Resolution forms should be investigated.

If the project team know that all issues they raise will be dealt with promptly and professionally, they will be more likely to take the trouble to raise them early.