Issues will arise throughout a project and beyond. There is a temptation to try to avoid trouble by discouraging people from raising their concerns. Of course, the opposite is the best policy. Any potential problem should be surfaced as early as possible and dealt with efficiently.
Anyone concerned with the project may spot potential problems. The participants should be encouraged and rewarded for bringing these to the attention of the project leadership. Once an issue is raised, the Project Manager should ensure that it is proactively pursued and dealt with to the satisfaction of all concerned parties. It should be easy for the participants to submit their concerns. It is a good idea to stimulate the submission of issues, possibly by requesting input as part of the participants' regular progress reporting. One way this might be done is by including an "issues" section on the project timesheet.
A distinction is sometimes made between different types of issue, for example:
In some projects, different processes will be defined. Alternatively, a single mechanism would present a less confusing interface for the participants, but would need to support variations in how the issue is dealt with.
There certainly are some different considerations with issues reported to external suppliers. Very often that supplier will have its own specific procedures, tracking system, reference numbers, liaison points etc. It is good practice to channel external links through a single point of contact - either a member of the Project Office, a specialist within the project team, or a designated person in the wider organisation.
Note that the project team will also need to set up a permanent operational mechanism for the resolution of problems reported by users during the live running of the system. It may be based on the approach used during the project, or it may be that the organisation has a good standard procedure in place.
There are also some specific stages in a project that might warrant their own issue management process and system, for example:
Although these are more part of the project work than part of the project management, it may be appropriate to use some of the same techniques and tools but without the degree of administration and control that should be found in the project's main issue management process.
Relatively little attention to Issue Management is required as part of the Project Definition work. It would be normal to agree the overall approach and its importance with the Project Sponsor and senior leadership.
The main activity at this time would be to establish the mechanism that will be used, particularly if it involves a system that needs to be selected, acquired and implemented. The issue management system would normally be part of the same overall set of procedures and tools that will be used to support the other project management activities. A number of commercial software tools are available. It would also be straightforward to set up your own local system using client server or web technology. In relatively simple projects, the needs could be met by standard tools such as EMail and spreadsheets.
The issue management process will normally involve a combination of procedures, responsibilities and systems. The key to success is to have a well-controlled but easy and efficient process. Define and agree:
Here is a basic process for dealing with issues:
The first priority is to identify and capture the issue. It would then be examined by an appropriate member of the project team to decide how best to deal with it. Specific actions would be proposed, possibly alternative courses of action to be compared and agreed. Where the issue or action has a significant impact upon the project's benefit model it would normally need to be referred to the overall project leadership, probably using the project's scope change mechanism. In any event, the impact would be reported to the steering committee. The agreed actions are then assigned and carried out, subject to monitoring by the Project Office followed by a final review and sign off.
The Issue Management process will run throughout the project, and potentially beyond that into live running. Team members and other participants will be encouraged to submit issues. The Project Office team and the Project Manager will administer and control the process.
It is normal to create standard forms for the submission of issues. Although this could be paper based, it is more common to use EMail, client/server or web-based approaches.
Here is an example of a web-based Issue Submission Form. Take a look at it as a web page.
From a control point of view, it is important to record the participants involved, the dates and the status. The Project Office team will monitor and chase progress. The Project Manager will review the status and take further action as required.
Where necessary, the issue's resolution will be referred to other bodies such as the Steering Committee, external suppliers, other specialist departments etc. It may also be necessary to invoke other management processes such as Scope Change Control and Configuration Management.
To support the process a variety of enquiries, reports and control documents may be generated. The ideal model is a knowledge sharing database accessible by all participants.
The most important control tool is a log summarising the issues, their current status and who is currently responsible for them, again this may take a variety of technical forms from paper to a fully integrated database.
This version is a simple Excel file.
Although the project team will be striving to resolve issues in the most beneficial way, some may remain unresolved at the end of a phase. The Project Manager will need to review the status of the outstanding issues and consider what impact they may have. The phase-end reporting should include any significant outstanding issues and will summarise the overall impact on the benefit model. Any consequences should be agreed with the Project Sponsor and Steering Committee.
Outstanding issues will form an input into the detailed planning process for the following phase of work.
The Project Manager and Project Office staff will be reviewing the outstanding issues on a regular basis and proactively chasing them to conclusion. By the end of the project there should be no outstanding issue left to resolve. This does not mean that every issue can be dealt with during the project. It may be that some concerns cannot be dealt with and appropriate responses should be made to those concerned. Other issues may be deferred to be addressed either as part of the live maintenance of the system or in a future project. Bear in mind that perfection may be expensive if not unachievable. It is normal to accept a reasonable level of imperfection where that represents the best value between cost, benefit, risk and time. With the amazing pace of eSolutions, a rapid workable solution is often better than a high-quality one.
The final status of the issues should normally be reported and reviewed with the Project Sponsor and project leadership as part of the finalisation of the work. Unsatisfactory conclusions will normally have an impact on the final benefit model. Specific actions or requests for future work would be passed into the relevant management processes.
Dealing with the project's issues and their resolution will have generated new wisdom and understanding. The individuals concerned should have benefited from the experience. It is probably worthwhile spending some time recapping the lessons that were learnt. The wisdom should be shared where possible through whatever formal and informal mechanisms are available for knowledge sharing.