What is an Issue Log?
No matter how well you plan, issues can always appear and quickly halt a project’s progress. When such issues come, it is critical to have an effective process for documenting, tracking, assigning, and resolving the problem. An effective process will minimise any negative impacts on the project or the organisation. A common process which project management professionals often use are issue logs. So what is an issue log, and how can you use it to address your risks and issues?
What is an Issue?
Before going into depth about issue logs, let’s define a project issue. While we often talk about issues with risks, they are distinctly different. While a risk is anything that can potentially impact the future of a project, both positively and negatively, an issue is a project risk that has escalated into a current problem that can negatively impact the successful delivery of the project. An issue is current and present and thus requires immediate attention and action.
What is an Issue Log?
An issue log also referred to as an issue register, is a comprehensive document that outlines all issues that arise throughout the project lifecycle. It typically comes in the form of a list or spreadsheet that allows teams to easily track, record, report and communicate ongoing issue management progress. It acts much like support desk tickets that allow teams to easily log, identify, track and resolve an issue with clarity and efficiency.
The issue log is a vital part of both the risk management and issue management process. It not only helps with a real-time resolution of issues but also acts as a vital repository for historic data on team issue management performance. It provides the data needed to find issue themes throughout the organisation’s projects that may have gone unseen and helps identify new opportunities for improvement.
Benefits of an Issue Log
One of the most apparent benefits of an issue log is the level of transparency it provides teams with its clear documentation, definition and classification of issues within the project. However, issue logs bring many more benefits beyond that, including their ability to:
- Improve communication and collaboration amongst team members with clearer accountability and documentation.
- Simplify task delegation and prioritisation activities by clarifying the status and severity of each issue.
- Nurture proactive problem-solving practices within teams
- Upgrade organisational record keeping and documentation
- Create cost and time savings during issue responses that increase overall productivity
- Ease issue management burden on team members by making it easier to track and meet crucial deadlines
- Facilitate better organisational learning by giving teams valuable historic data on issue management actions and performance
- Enable greater stakeholder engagement and management
Components of an Issue Log
The specific components of an issue log may vary depending on the type of project, industry or software in use. Regardless, there are some common issue log components that project managers can use no matter the project type. These incclude:
Issue Name and/or Number
This is a unique identification name or number that you should assign to a single issue. This number can be particularly useful for integrating data across platforms and software.
Issue Type
Issues may fall into different categories that project teams may want to filter out. Teams can introduce different issue types by categorising them by department, vendor, product, or team.
Issue Description
This section describes the issues of the project in detail. The issue description should be comprehensive, concise, and easy-to-understand. The quality test of an issue description is if anyone can read the issue description, understand what they’re reading, and have a solid overview of the issue. We recommend the formal structure of an issue statement, mentioned in this blog post on issue management.
Resources
This identifies the different resources needed to resolve the issue such as human resources, equipment, or materials.
Reported By
It’s good practice to assign each issue to a person. If you follow this practice, it makes sense for you to include the name of the person who reports the problem on the issue log. This streamlines communication in your team if you need more details, and simplifies management activities.
Reported Date
Also referred to as the open date, the reported date gives the team a predicted time frame for expected issue response and resolution. With a clear reported date, teams can prioritise their tasks, and ensure they are resolving issues in a timely manner.
Priority
This determines the level of severity or immediacy of an individual issue. Teams can tap into the power of an issue matrix to help identify the specific ‘issue-level at’ any given time. The typical priority levels include ‘low’, ‘medium’ and ‘high’, which may PPM solutions visually represent through the ‘traffic light’ system.
Assigned Owner
As mentioned before, project managers often assign a team member responsibility for the issue and the ensuing tasks. Though it best practice for a project manager to allocate one owner per issue, the issue owner may further delegate different tasks and actions. Therefore, it’s critical for us to maintain clarity over who has contributed to resolving this issue, which you can outline in this section.
Target Resolution Date
This is the set deadline of the team needs to resolve the issue by. Typically, the issue-owner will choose this date based on the issue-level and reported date. This helps maintain accountability within teams, while also ensuring teams are meeting expectations and assisting projects to run smoothly.
Status
The status describes the progress of the issue resolutions. Oftentimes, project managers will indicate the status by labels such as ‘open’, ‘implementing’, ‘in-progress’, or ‘resolved’.
Solution
A project manager can use this section to write in the agreed solution, and how the team can or has implemented it. Then the team can reference the resolution later for future projects.
Comments
This section allows team members to add any additional relevant notes regarding the issue that can help simplify communication needs or support future historic learning activities.
Integrating issue logs with RAID logs to elevate risk and issue management activities
While issue logs are a valuable tool, there are other types of logs that can help elevate your overall risk and issue management activities. Instead of having the individual risk and issue logs, RAID logs consolidate key aspects related to project risks so your team can have more holistic visibility and control.
RAID is an acronym for Risk, Issues, Assumptions, and Dependencies, and through a RAID log teams can easily track risks, their ensuing escalations and impacts on project progress. To learn more about how you can start using RAID Logs, make sure to check out our guide to RAID Logs or book a free trial to see it all in action!
IIR: Introduce, Integrate, Replace
Step 01
Introduce
You cannot run a portfolio on Excel and PowerPoint alone.
Project portfolio management is the discipline of seeing every project in one place, prioritising the work that matters, allocating people against demand, and governing delivery with real numbers. It is not optional at any serious scale. The moment you have more projects than one person can hold in their head, you need a single, current view of status, schedule, cost, resource and risk.
Excel and PowerPoint feel free because there is no licence conversation. The real cost is elsewhere. It is the hours spent maintaining workbooks, the version confusion, and the numbers that go stale the moment they are pasted.
A spreadsheet cannot tell you, on demand, which projects are at risk, where your people are over-committed next quarter, or how much of the portfolio budget is actually spent.
Introducing a proper PPM platform is the first step. Not to add another tool for its own sake, but to give the portfolio one place where the data lives together and stays live.
Step 02
Integrate
The instinct after buying a PPM platform is to make everyone move into it. That is the fastest way to fail. Project managers already have tools they trust, and finance already has systems of record. Force a migration on day one and you get resistance, shadow spreadsheets, and a dataset nobody believes.
Integrate first. Meet the data where it already is. Two directions matter.
Direction 01
Enterprise systems
Connect to the finance or ERP layer so actuals, commitments and budgets flow in automatically. Reporting stops being a monthly reconciliation and becomes a live view. Nobody rekeys a spend figure again.
Direction 02
The tools PMs already use
The direction most platforms neglect, and arguably the more important. The portfolio should read from the PM's own tools, not force people to abandon them.
The reason this matters is simple. That data is already there, and it is kept current by the person closest to it. When the portfolio reads directly from these sources, the status report updates itself. No chasing, no copy and paste, no reporting lag. The PM keeps working the way they always have, and the board gets a live picture as a side effect.
Step 03
Replace
Integration buys you two things: trust, and live data. Once both are in place, you look at what can go.
Every organisation carries tools and spreadsheets that either do not do the job well or carry a heavy maintenance overhead. The classic example is the resource spreadsheet. It is a workbook someone maintains by hand to track who is on what. It is always slightly out of date, owned by one person, and impossible to reconcile against real demand.
Replace it with the equivalent function in your PPM.
A proper demand management capability does what the spreadsheet was reaching for, with none of the overhead. It models demand against capacity across the whole portfolio, updates as projects shift, and needs no manual upkeep.
Replace deliberately, one function at a time, and only after the platform has earned it. The test is simple: if a spreadsheet is high overhead or low quality, and the platform does the same job natively, retire the spreadsheet.
The payoff
You stop producing reports and start reading them
Follow IIR and the nature of reporting changes. The status view is current because it is fed by the tools people already use and the systems that already hold the money. The overhead that used to consume the last week of every month disappears, because there is nothing to assemble.
That is the whole point of real-time reporting. Not a prettier deck, but a portfolio you can look at any day of the month and trust, at a fraction of the effort it takes today.
Built on Microsoft 365. Native ground for IIR.
pmo365 integrates with the tools your teams already run in, so the path from Introduce to Integrate to Replace is a natural progression rather than a rip and replace.