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.
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.
Difference Between and Risk and an Issue
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.
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:
- Issue Strategy is where we document the Issue Management Strategy we are going to use throughout the course of the project or program, including the frequency at which issues will be review and reported.
- Issue Identification is the process by which we identify issues. Issues can come from multiple sources, for example, from a question raised via email, or any of the regular project or program meetings which are held. As soon as an issue has been identified it should be recorded in an Issue Log.
- Identify Owner is where we assign an owner to the Issue who is responsible for resolving and reporting back on the Issue.
- Issue Analysis is where we categorise issues by Urgency and Impact. This categorisation enables us to distinguish between major and minor issues. An Issue with a high impact but low urgency needs to be dealt with but we have some time to plan how to handle it, whereas an Issue with a high urgency and high impact needs to be dealt with immediately or it will very quickly have a large detrimental impact on the project or program. I like to categorise Urgency and Impact use values between 1 and 5, with 1 representing a low impact or urgency and 5 representing a high impact or urgency.
- Issue Evaluation is where we compare the various urgency and impact values for all issues enabling us to prioritise the order in which we will tackle the issues
- Action Steps is where we document the action to resolve the issue that the Issue Owner is responsible for performing.
- Monitor and Review is where we periodically review and update all issues to see if they have been resolved and can be removed from our Issue Log, or if the impact and urgency of the issue has changed.
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.
Issue Management in Practice
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.
Embedding Issue Management
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.
Monitoring Issues Over Time
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.
