Manage Issues

Manage Project Execution

 

Issues are usually questions, suggestions, or problems raised by Project Team members, including the Project Manager and Beneficiaries. They are different from changes in that they do not usually have an immediate impact on the Project Scope or Schedule. If issues remain unresolved, however, they are likely to affect the Project Schedule or Budget, resulting in the need for change control. It is, therefore, very important to have an issue escalation and management process in place, and to execute the process before change control procedures become necessary.

Managing issues involves documenting, reporting, escalating, tracking, and resolving problems that occur as a project progresses.

A fundamental of project management is that :

But even when issue management do not require a change f the project document, to keep track and document them is always a good idea and will give a strong ground to project reporting.  So a general advise is the following:  When managing issues, document EVERYTHING (yes, EVERYTHING) that happens as issues are resolved. Be sure to note what happened, when it happened and who was involved. Don’t skimp on the details. Keep an issues “diary.” When issues are closed, don’t delete them from your issues log – instead maintain the “diary” of closed issues in a separate file or folder or section of the log. This “diary” will ensure that you cover your bases, and the information included in it may become invaluable to you or another Project Manager as lessons learned when resolving similar issues down the road!

In the methodology section of the Project Plan Document there can be a sub-section dealing with the process for managing issues. If not it would be a good idea to agree on this procedure at a early phase of project execution. When then the issues happen there is already an establish and agreed pattern  of how to cope with the issues. The issue management process addresses the following:  

Anyone involved in a project in any way can and should inform the Project Manager of issues. It is the responsibility of the Project Manager and Programme Manager to foster an environment where communicating issues is not only acceptable but strongly encouraged. Individuals should feel a responsibility to the organization to voice their concerns. If individuals are fearful of communicating issues, the resulting effect on the project can be devastating.   (see  communication climate.  A basic assumption of this manual is that only organizations that are projectized and that empower their employees create a communication climate such as to work strategically, collaboratively and cost-effectively, being innovative and accountable.

The people best qualified to determine if the problem has been solved are usually the ones who pointed out the problem in the first place, and then helped come up with the solution for it. 

Advise: The Project Manager should be cautious about reacting to an issue that is communicated by “shooting the messenger.” This sends the wrong message to the Project Team. No matter how devastating the news or the issue, the Project Manager should thank the person who raised the issue and solicit ideas from that individual and other team members for its mitigation.

 

See Implement Quality Assurance and Quality Control Processes

The Project Manager is responsible for capturing and tracking issues as soon as they arise, using the issues log section in the Project Status Report.  (chose on of the templates below) Every issue, whether technical or business related, should be documented in the report.

Below are some examples of project issues:  

Once the description of a new issue has been logged, the Project Manager will estimate the potential impact the issue could have on the project. Based upon potential impact, the Project Manager prioritizes the issue in relation to all other open issues. The goal of issue management is to resolve all concerns completely and promptly, but in reality the issues with the highest priority should be addressed first.

The issues log should also include the date the issue is recorded, its anticipated closure date, and the name of the individual responsible for resolving it or seeing that it is resolved. The due date for closure must be a specific date.

The responsible party must be a specific individual, not a functional group (i.e., an issue should not be assigned to the “Logistic Department” or the “Steering Commitee”).

While the issue remains open, its continuing impact and the status of its action plan should be discussed at every status meeting. If appropriate resources or materials are not available to complete the action items, or if there is disagreement about any  of the elements on the issues log, the Project Manager should invoke previously-defined escalation procedures.

Unresolved issues are one of the leading causes of project failure, and the Project Manager must pursue issue resolution relentlessly. As progress occurs on the resolution of an issue, the Project Manager should update the issues log to reflect what has occurred. As issues are closed, they should be moved to a different section of the issues log. Along with a description of how the issue was resolved, the Project Manager should document who resolved the issue and the closure date.

Managing issues should be properly integrated with reporting of project performance, i.e the most important features of  project communication management

 

Templates:

 

Guidelines:

 

See also: