Issue Logs I want to implement a project by identifying, tracking and resolving issues Issue Logs

What is it and why should I use it? Issue Owner Date Opened Status Date Closed Resolution It rained for two days resulting in a significant work delay RS – Work Site Manager 11 July 11 July – Rain started in the morning . Workers went home 12 July noon– Rain stopped but workers did not report today 12 July afternoon – Inspected site and determined work could resume on 13th 13 July –Workers arrived & agree to work extra hours 13 July Workers agree to stay 3 extra hours for the next 2 days to make up for the rain delay What is it and why should I use it? This tool can help you track, manage and document issues. Once again this is an example the format, or number of columns, can vary according to a specific projects needs. The first column provides a description, in detail, of the issue at the point that it enters the log. The goal of the project management team is to manage this issue so that it can exit from the issue log without causing the project to get out of control. (this is normally a time cost scope issue) The second column specifies who will own and take the lead in resolving each issue. The date that the issue has been opened the date of resolution, along with a description of the status between those dates, are contained in the next three columns. Finally, the last column is a description of the resolution or solution that allowed this issue to be closed. That's really all that there is to and issues log – it is a relatively simple but powerful management tool. The actual log itself can be kept in a notebook, on a flipchart or recorded on a computer. It is important that the issues log be transparent – that the team members and other stakeholders can see how their complaints are being heard and responded to in a timely and responsible manner.

Reminder: Assumption = A statement (identified in order to complete cause-effect logic – mostly in logframes) Risk = A possibility (identified in order to be managed – using a risk register) Issue = A real problem (identified in order to be controlled –using an issues log) Remind the participants of the list they created earlier outlining What goes wrong in projects? How do you deal with them (think especially about how you deal with delays)? Although crashing and fast tracking can solve scheduling problems, we still need to look at the differences between Assumptions, risks and Issues and how we track and record them throughout the life of a project >>click Remember that there is often a relationship between an issue, a risk and an assumption. from the identification and design module that an assumption is: a statement identified in order to complete the cause – effect logic (or horizontal logic of the logframe). An assumptions is a positive statement that, when made negative, becomes a risk. Almost all of the assumptions in the logframe will become risks in the risk register but not all risks would have been assumptions – this is because some of the risks were not known during the identification and design phase. Reminder: Since risks will change over time, the Risk Register must be updated during implementation An issue, then, is: a happening identified in order to solve real problems. Not every risk will become an issue and issues will arise that were not on the risk register. The tool for managing issues is called an issues log.

Discussion: In your projects, how do you manage problems and changes?

Activity: Prepare an issue log for one of your projects. Issue Owner Date Opened Status Date Closed Resolution Prepare an issue log for one of your projects.