Action Trackers, Risk and Issue Registers, Schedule

Question

There is a lot of discussion around maintaining different types of trackers or registers to monitor and control project activities, risks, issues, sub-projects, various tasks, and whatever else of interest to various stakeholders.

However, I am finding this creates a lot of wasted redundancy in documenting, reporting, and tracking efforts involving a ton of resources, human and otherwise.

There are arguments ad nauseam around trying to differentiate a risk from an issue from an action when these things are related in correlation or cause and effect. Risks are driven from existing issues which can turn into issues causing further issues and other risks turning into more risks and evolving into issues and so on....

Then, we mitigate and recover, which means we create actions to go do.

Where this gets documented seems to depend on how it gets discovered. Were we risk planning, were we just impacted by an issue, did someone suggest an action?

Here's an example: the project team uncovered an issue with storage capacity on their servers, running above 90%. The team dutifully captured this issue on its issue register and laid out a recovery plan and proceeded to implement. Since it was nicely captured already, the idea of conducting a risk assessment, trying to predict what could go wrong because of the current storage condition, was conveniently nixed, with a key argument being there is no need to identify the risks and capture on the risk log since we already have documented this on the issue log. Needlesstosay, some of the actions were duplicated in the recovery plan as well as the action log. Several redundant reporting channels were created, discovery of out of sync registers occurred, everything crapped out. (I won't discuss the severe outage that occurred for which we had done nothing to mitigate and had no contingency in place to recover quickly.)

If you to the books, the answer is usually several logs, so this is not helping me. I am looking for opinions and other people's experiences in this area and how it was resolved.

I know opinions are not necessarily right for this site but I will hope this question remains open and perhaps some answers can be developed.

Answer 1

I'm not entirely sure that I understand the situation, but what concerns me is the comment,

Since it was nicely captured already, the idea of conducting a risk assessment trying to predict what could go wrong because of the current storage condition, was conveniently nixed, with a key argument being there is no need to identify the risks and capture on the risk log since we already have documented this on the issue log.

That sets off alarms for me. I don't think that any changes you make to tools will make a difference until there is an integrated, strategic committment to change management. Risks, issues, actions, work packages, etc, all result in changes. Every change should be assessed. Optimize your change control process so that the involved stakeholders have the skill & knowledge to quickly spot implications, and to know when they can be silent.

Answer 2

Risk-Related Artifacts are Secondary Objectives

There is a lot of discussion around maintaining different types of trackers or registers to monitor and control project activities, risks, issues, sub-projects, various tasks, and whatever else of interest to various stakeholders.

The way to avoid useless and duplicative tracking work is to realize that risk logs and other similar artifacts ought to be transient means to a more productive end. By itself, a risk or issues log is essentially useless as an output artifact; the purpose of such logs ought to be as inputs into a risk management process where the output is a control, modification to the deliverables, or a documented decision in your project report at close-out.

Issues and Risks as Inputs

A risk can be avoided, mitigated, transferred, or accepted. It has no intrinsic value; it's an anti-value that should be addressed by the project and incorporated by the project in some way rather than being given independent life.

Having an issue or risk log is fine, but it should be an ephemeral artifact. The goal isn't to write a document, after all; the goal is to manage the risk. In an agile project, an identified risk should be assessed more or less immediately, and then disposed of properly.

Disposition may include:

1. Adding an appropriate control-development or risk-mitigation story to the Product Backlog.
2. Agreeing on a new control or process to manage the risk during the next Sprint Retrospective.
3. Terminating the current sprint with an immediate return to Sprint Planning to address the risk.
4. Noting the transfer or acceptance of residual risks in the project close-out report.

Solved problems aren't really problems anymore, so the utility of tracking risks outside of a defined deliverable is zero. In other words, a risk codified in a corrective policy document is a useful risk-related project artifact, while an Excel spreadsheet enumerating risks is suitable for making origami animals.

Assessing and Managing Risks

Of course, to properly dispose of a risk, it must first be assessed. Examining the threat model, quantifying the risk, and determining how to manage it (if that's even required) is a process in itself, and how this fits within your project management framework often varies a lot. However, once you've identified the risk and determined how you wish to manage it, one can generally:

• Avoid the risk.
• Develop controls to correct or limit the risk.
• Transfer the risk.
• Accept the risk.

In all cases, the goal is to do something about the risk, not just note it for posterity. Risks that are designed around or otherwise mitigated are (functionally speaking) documented in the changes to the project plan, and in my opinion no longer need to be tracked explicitly. Residual risk, on the other hand, is part of what's delivered by the project, and therefore risk-transfer or risk-acceptance artifacts become deliverables for the project.

Personally, I prefer to place all risk mitigation as action items on the Product Backlog, and to document any residual risk in an appendix in my project close-out reports. Related artifacts such as:

• risk-assessment meeting minutes,
• formal risk-acceptance sign-off documents, or
• relevant insurance riders showing that the risk was transferred

may be useful attachments to the close-out report, too. Your mileage in that regard may vary rather widely.

Answer 3

At my current place we integrate documentation of risks, decisions, action items and assumptions in a single Excel file. Each category has it's own worksheet to make it easier to track them. I've found this helpful to avoid redundancy.

One caveat is that what I track is at a project rather than at a deliverable level... tracking to this level for X projects each with Y deliverables would become unmanageable if I were to go too deep into the weeds. Unfortunately I've found that some team members expect that the PM will hold their hands too much, so use of any tool requires management of expectations.

Answer 4

In some organizations I observed sharepoint tool customized to project needs used to manage all the issues,risks and other documents. I see this as effective than excel etc. every one can access easily and PM discuss these and make real time updates as we speak in the meetings and every one has latest information.