Jump to content

Development Cooperation Handbook/Designing and Executing Projects/Project Execution and Control/Manage Issues

Add links
From Wikibooks, open books for an open world

Isues 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 :

  • the project manager and her/his team can resolve autonomously all issues that do not require modification form the agreed Project Plan Document (and its modification already formally agreed upon by the programme manager and by other project plan decision makers);
  • the project manager will have to document and report all the issues (using the Project Issues Log Template) that have an impact on the project scope or methodology, or lead to an increase of the agreed budget or shedules. These issues will require to undertake the procedures of managing the change process that will lead to formally agreed
    • Changes to Project Scope,
    • Changes to the Project Schedule
    • Changes to the Costs Established in the Project Budget.

Since these decisions will have to made by persons external to the project team, a correct reporting and documentation of the issues is essential.

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:

  • How issues will be captured and tracked
  • How issues will be prioritized
  • How and when issues will be escalated for resolution


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:

  • The project truck will unusable for 3 months because it requires major repairs after an axident
  • Major Project expert is taking another job
  • Project Team member start date may be sooner (or later) than expected
  • There is a delay in approving or rejecting a change request or deliverable
  • Severe weather is predicted in the area
  • A particular group of stakeholders is putting pressure on local Government against implementation of the project.

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 Committee”).

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

[edit | edit source]

Project Issues Log Template Issues Management Plan Interim Project Status Report Template Project Change Request

Retrieved from "https://en.wikibooks.org/w/index.php?title=Development_Cooperation_Handbook/Designing_and_Executing_Projects/Project_Execution_and_Control/Manage_Issues&oldid=3107667"