Posts Tagged With: Risk management

It’s time for RAID logs to evolve!

When documents are used to track project information, a common approach is to create a consolidated workbook in MS Excel for tracking risks, actions, issues and decisions. This is usually referred to as a RAID log.

The benefit of this approach beyond having the information in a convenient, centralized location is that there are logical relationships between these disparate elements which can be easily reflected if they are consolidated. For example, negative risks which have not been successfully avoided could be realized as issues. In turn, issue resolution might be done via actions. And finally, actions may require formal decisions to be taken.

But is there an opportunity to consolidate additional list-based project data elements for greater benefit, and if so, what are some good candidates?

We frequently hear about the need to capture assumptions made by stakeholders when planning our projects so that they can be validated over time. A benefit of having the assumptions consolidated in the same workbook is that part of a regular risk register refresh could include a quick walkthrough of those assumptions which have not been validated yet to see whether any new risks can be identified or whether information regarding existing risks should be updated.

It’s rarely ideal to wait till the very end of a project to harvest knowledge. But if you choose to identify lessons regularly over the life of your project, they’ll have to be captured somewhere. As issues are often a good input into lessons identification, having the ability to link issues to a lesson will simplify the process of understanding the context behind the lesson. Another benefit of this approach is that since it’s common practice to review issues and actions in regular team meetings, having lessons also available in the same document might encourage team members to review them and identify new ones.

Finally, let’s consider stakeholders. We know that it’s a good practice to identify stakeholders early in your project, analyze them according to their impact, interest and influence, and use that information to form your engagement and change strategies. Stakeholders will be closely associated with all of the other data elements we’ve looked at so it’s likely worth including your stakeholder register too.

So if your organization doesn’t have a central project management information system, why not use a RADIALS log in place of a traditional RAID log!

Categories: Project Management | Tags: , , , | 1 Comment

Shuffle up and deal with qualitative risk analysis!

While it is frequently used by agile teams to size work items (e.g. user stories), Planning Poker® can also be used to facilitate other types of decision making so why not use it for qualitative risk analysis?

A common approach to this process is to utilize a scale from very low to very high or even just low, medium and high to assess the probability and impact of identified risks. One concern with this is that at the end of the risk analysis workshop the team likely ends up with a significant volume of high probability or impact risks. This forces them to do a second pass to prioritize the risks so that risk owner capacity can be focused on the valuable few.

In many cases, determination of probability or impact is done through a group discussion. This means that the same biases which affect sizing when techniques like Delphi aren’t used will be realized. Whoever speaks first or speaks loudest anchors the remaining team members to their perception of probability or impact.

Finally, I’ve seen some teams analyze risks as part of the identification process. Not doing the analysis in a batch manner might seem to be better, but it also means that the team won’t benefit from the perspective which comes after they have had the chance to review all risks. Again, this might force a second normalization pass to ensure evaluations are consistent across the risk register.

So how can Planning Poker® address these challenges?

  • By using a numerical basis for qualitative risk analysis (yes, I know that sounds like an oxymoron!) we provide greater levels of granularity which should simplify the risk prioritization process.
  • Planning Poker® uses a non-linear (usually Fibonacci-like) sequence. This is important because risk impacts and probability do not scale linearly. When we use low, medium or high to analyze risks, we don’t account for non-linearity.
  • It removes bias from the initial individual assessment and provides a structured approach to surface and discuss differences in perception.
  • It requires us to normalize our sizing at the very beginning based on the complete list of risks to be assessed. Once the team has identified all risks, they will review each and determine which risk they believe has the smallest probability and which one has the smallest impact and use those as their basis for relative assessment against all others.
  • Finally, Planning Poker® can be a lot of fun – it gets people actively engaged in what can sometimes be a very dry discussion.

Scaling this technique with larger teams might be challenging, but for risk analysis sessions with up to a dozen participants it can work well.

The beautiful thing about poker (and risk analysis!) is that everybody thinks they can play – Chris Moneymaker



Categories: Agile, Project Management | Tags: , , | 1 Comment

A risk management ode to project managers!

Father’s Day might be a holiday which is much newer than the project management profession itself, but let’s not miss the opportunity to celebrate the many ways in which project managers help their projects succeed through effective risk management.

F is for Failure Mode and Effect Analysis, which can be a mouthful to say,

A is for avoidance to hold critical risks at bay,

T is for risk transfer for which we’ll have to pay,

H is for human bias, which can stand in risk management’s way,

E is for expected monetary value analysis, which calculates outcomes come what may,

R is for reserves, which prevents realized risks from ruining our day,

S is for simulations like Monte Carlo for us to play,

D is for Delphi where estimators go to pray,

A is for assumptions which come in many shades of grey, and

Y is for yellow which our project dashboards should never display.

Happy Father’s Day to all!


Categories: Project Management | Tags: , | 1 Comment

Create a free website or blog at

%d bloggers like this: