This post aims to walk you through all the information you’ll need to successfully manage and track any issues which occur during the execution of your project or program. Successful issue management will enable you to manage your project or program execution as smoothly as possible. Let’s begin with the definition of an Issue.
In Program and Project Management, issues occur every day. My definition of an Issue would be anything that might impact the schedule, cost, or quality of a project or program. Another way you might define an Issue is as anything which will adversely affect the project or program.
Let me be very clear about what I mean by the word “impact”, by considering as an example, schedule impact. I do not mean just those things which impact the overall program schedule causing the whole project or program to delay, but also smaller events which slow down execution within the project or program, even if they don’t necessarily delay the overall schedule.
A risk is a future event which has not yet materialized, whereas an Issue is present concern which if not dealt with will adversely impact the project or program. Once a risk has materialized it becomes an Issue, but an Issue can never become a risk.
Let’s look at an example. Suppose we have a system which can only calculate tax as 15%, corresponding to the current national tax rate. During the early phase of program or project execution rumours abound in the national press that the government is considering raising the tax rate to 20%. We would at this point track this as a risk to the project or program. Sometime later the government announces that they are indeed to raise the tax rate to 20% from 15%. At this point the risk has materialized and is now an Issue and should be dealt with through the Issue Management Process.
The Issue Management Process is very similar to the Risk Management Process, and is shown below:
The steps of the Issue Management Process are as follows:
The Issue Management Process should be repeated at regular intervals throughout the duration of the project or program. In a program context, you may find that it makes sense to increase the frequency at which you run the Issue Management Process as your program nears completion, even running the process twice daily to ensure issues are being closed off quickly and effectively as time runs out.
In practice I like to track issues using a spreadsheet, an example of which is shown below:
This spreadsheet allows you to filter issues according to a number of criteria, including Issue Owner and Urgency, amongst others. It also allows you to assign a Due Date, enabling you to monitor/track when you expect an update on the issue.
In addition to the spreadsheet shown, there is a range of Issue tracking software available commercially, but I find the above spreadsheet serves me well.
I don’t think it makes sense to have a specific meeting whereby issues are discussed as this always seems cumbersome and time consuming in my experience. I think it is easier to simply have the Issue Register to hand in every meeting you attend related to you project or program.
How frequently you run the Issue Management Process will depend on whether you are using it for project or program management and the stage you are in within the project or program.
As an example, let’s consider an R&D team using agile and how they might embed the Issue Management Process in to the Agile process.
The easy way to embed the Issue Management Process into the Sprint process is to complete the Issue Management Process every day as part of the daily stand-up meeting. In this way if a Sprint was 5 days in duration you would complete the Issue Management Process 5 times per sprint. You do not need to have a specific agenda item to go through the Issue Management Process each day, but simply assign one member of the team to log issues raised and request updates which are due or nearing their due date.
A useful thing to do is to monitor issues over time to see how many open issues the project or program is running with at any one time. The diagram below categories issues as Major, Medium, and Minor, and displays how open issues grow or shrink in number month by month.
This technique can be useful for highlighting to your management how effectively issues are being dealt with within the project or program. It also enables you to perform trend analysis and estimate when all issues should be closed off.
I hope you find this post useful. If there are other techniques you are using to manage Issues, please write to me and let me know. I’m always interested to discover new ways of doing things.
How to Close a Project Successfully
Communication in Project Management
Change Request Template
Project Management Soft Skills
Project Status Report Template
How to Start a Project
Project Plan Example – How to Plan a Project
The Project Scope Statement