Search This Blog

31 January 2007

Risk Management 101: Assess a risk

There are three steps to assessing a risk; Likelihood, Impact, Priority/Importance. Priority/Importance is determined by the likelihood and impact.

Risks are often assessed by project team members who have prior experience in a particular area, but bringing in experts can also add value. In fact as most risks have to be assessed by rule of thumb as they are estimates of future behaviour and events the more subject matter expertise you can bring to bear the better.

Be warned that subject matter expertise can also bring a skewed view. People who have been burned by a particular risk can often over-estimate its impact in the future. Similarly people’s assessment of risks can be skewed by their objectives and their horizons. An example from my past work is subject matter experts from operational areas often assess risks as having a huge impact (to their business unit) when in fact, in the context of the whole organisation the impact is insignificant and any inconvenience can be absorbed.

Organised project offices often have defined thresholds for likelihood and impact and they should be contextualised to the environment. For example, my family’s suburban legal practice would consider a $100,000 critical, while Telstra would probably consider this minor.

Examples of Likelihood and Impact thresholds are provided in the sample Risk Management Spreadsheet attached/linked at the end of this article.

Typically risk management systems use Likert scales (score from 1-5) to assess impacts and likelihood, with each score corresponding to a minimum, maximum or both threshold.

I’ll address assessing likelihood and impact in more detail separate posts.

30 January 2007

Risk Management 101: Positive risks

I should also mention that there are positive and negative risks. For example a risk of greater than forecast customer numbers, resulting in higher revenue is still a risk.

Positive risks can be described as opportunities. You can still plan to manage the risk, just in this case to take advantage rather than defend from the risk.

Often positive risks are ignored by project teams but can be worth exploring; Greater than forecast customer take-up can be generally good, but does unveil some potential problems like stock and staff management for order fulfilment, for example.

The Project Management Institute (PMI) generally acknowledges that positive risks are worth considering.

It has a special interest group devoted to discussing and understanding risk in the project context and it uses a definition that includes positive as well as negative uncertainty about the future. They also talk about risk management maturity in a CMMI like framework and suggest that as an organisation becomes more mature in its handling of risk it becomes more able to take advantage of upside or positive risk.

You can also think about positive risks in the context of programmes or portfolios of projects. For example, how can you take advantage of the fact that that new change initiative will finish early? You can grab the people and use their expertise early, you can leverage the changes they have implemented and so forth.

You can read more about these ideas at
RiskSIG or in the whitepapers at PMI.

29 January 2007

Risk Management 101: Describing a risk

In business and especially in projects it is important to be precise with language to avoid confusion and misinterpretation.

Risks should be phrased and framed properly in order to be best managed. Risks should identify three aspects;

  • The circumstances that enable the risk to occur, often the trigger
  • The actual risk, or thing that might happen
  • The impact of the risk event occurring to the project or business

For example these are poorly framed risks;

  • We may set the price too high
  • Technical resources are not available

This is a more effective way of describing the risk;

  • If we raise prices to high customers may find better alternatives and churn away causing loss of market share and revenue.
  • If technical resources are not available by [date] the project’s critical path will be affected resulting in at least a four week delay to launch
The second set of examples provide fuller descriptions that reduce the likelihood of misinterpretation and allow for a better assessment of the likelihood and impact of the risk.

25 January 2007

Risk Management 101: Risk Management Systems

Risk management systems are tools that are used to track, monitor and manage risks. Often they are a combination of lists of things to watch out for and action plans of things to do. The most common risk management systems are minutes and Excel Sheets, however some organisations have quite sophisticated databases.

What a risk management system needs to do is ensure that risks are known and understood by the project team and the people who need to deal with the risk management actions and potential consequences of risk events. Like most project tools it’s all about communication.

The features a risk management system needs to have to do its job well include

  • A brief description
  • A list of impacted stakeholders
  • An impact/likelihood assessment
  • A priority or importance rating
  • An owner who is responsible for the risk management plan
  • A description of the risk management plan
  • A status (is it being managed, has it been closed?)

Another important feature of a risk management system is that it is used. The system (Spreadsheet, word doc, etc) needs to be looked at and the items reviewed and monitored. If you are designing your own make sure it is clear and useable. One weakness of risk management systems is that they can get too complex of the users, so consider their knowledge and awareness of risk management systems and design with them in mind.

A sample Risk Management System in Excel is available from

24 January 2007

Risk Management 101: Raising a risk

Different project managers and business analysts have different approaches to risks. Some only want important risks flagged others only want risks flagged that are specifically related to the project’s scope and others, like me, like to capture all risks identified by the project team and stakeholders. The important thing to remember is what you’re there to do, and how risk identification can help or hinder your efforts.

Regardless of the threshold for entry onto your risk register it is critical to have one and to pro-actively manage risks. Many projects hold risk workshops early in the project and leave it at that. Some hold risk workshops at the beginning of each phase of the project and others hold weekly or fortnightly risk meetings where issues are raised and managed.

The savvy project manager has a team that are always identifying and managing risks, and using meetings as a forum for managing the most complex and important ones.

There are plenty of articles on the internet which suggest that for certain kinds of projects, and at different stages of the project lifecycle, you should be aware of some pretty constant and common risks. Have a look for some in your field.

23 January 2007

Risk Management 101: Project Management is Risk Management

In my mind Project Management is Risk Management. And so are defined business processes.

Much of the ISO9000 quality framework is based upon the belief that standardised processes increase quality through a reduction is defects; which is risk management at the operational level. The favour that the Prince2 methodology has is that it’s a process that guides people through the project; reducing risk through knowing what the expectations and next steps are going to be. Similarly PMI has created processes and checklists of things to tick off in 9 areas of project management – so you can mitigate the risk of ignoring or forgetting certain aspects of the project.

Naturally these are also more than project management, but Risk Management is fundamental to what they are and what they do.

As business evolves into the 21st Century, and as your career as a project worker develops the complexity of the environment escalates and so does the scale of projects you work on and the potential costs of failure. So risk management becomes more and more crucial to managing better projects.

Over the next half dozen projects I am going to post a Risk management 101 series of articles running through the key areas of project risk management:

  • Raising a risk
  • Risk management systems
  • Describing a risk
  • Assess a risk
  • Manage a risk
  • Monitor a risk

No doubt they will be presented in reverse order in blogger, but when I am finished I’ll also publish the whole article in one place and provide a link to it from these pages.

21 January 2007

The one minute risk assessment

I picked this up on my internet browsings; The one minute risk assessment.

This article will probably take twenty minutes to read but once you do you will be the guru in project risk identification meetings.

Or the shortcut:
1. Here are the main drivers of risk.

2. So weight these risks in your risk assessment.

19 January 2007

Meeting Efficiency

There are times when meetings are useful; for example when you want to develop consensus on a decision, where you want to brainstorm ideas and so forth, but is a meeting the right way to get things done or to communicate a message?

It certainly isn’t efficient once you get above half a dozen people.

I’ve put together a table to demonstrate the point.

On the left I have the number of participants. I have then estimated the time it would take to communicate a typical message or address a particular problem in a meeting, based on the number of people in the room.

As you probably know; the more people in the room the longer the meeting takes. People will arrive late, side discussions occur, new agenda items are raised, and the more people in the room the more formal and complex your delivery of the message needs to be.

So calculate the amount of time you spend in the meeting by the number of people in the room and you get the work hours invested into the issue.

Compare this with one-on-one interviews or meetings. Sure when there are just a handful of you in the room you can get more done for less, but as the audience grows the investment into the meeting grows and becomes obviously an inefficient way of dealing with things.

Multiply these estimates by the dozens of meetings across dozens or even hundreds of projects within large organisations and you see the potential for time saving.

Just because it’s more efficient for you as the project manager or business analyst does not make it the best way. Additionally you will get better engagement from the participants in smaller groups and the quality of the discussions will be higher.

Naturally there are exceptions where you need to pull people together but as you can see from this table you are better off working smaller groups.
Next time you call a meeting think about who you want there and why – and how many people you want to deal with at a time

6 January 2007

Is process design integral to capturing workable business requirements?

My friend Patrick Castauro has written an article for the BA handbook on Requirements Management and Process Analysis. I reproduce it here.

You can read more about BA techniques and processes here.


In my experience, there seems to be very little emphasis on process design as a precursor to capturing business requirements. How is possible to know what you need, when you have little or no understanding of its application (what you need it for)?

Many BAs are able to, through prior exposure or experience, guide the requirements gathering process with or without the support of relevant business subject matter experts, and capture requirements relevant to the scope or intended objective of the initiative.

In most cases, it is because the BA understands how the business operates, that this activity, in the absence of process understanding, delivers what is required.

What happens when the BA is new to the organisation, doesn’t have any operational exposure, or business (stakeholders/users) are unable to offer subject matter experts?

In the absence of well managed and facilitated leading process work, it's not possible, in my view, for the BA to produce adequate requirements relevant to the intended scope of the initiative. Furthermore, in the leading stages of a project the focus from the business is somewhat limited - remember very few initiatives proceed to implementation. It's when the initiative receives the green light, and in many cases this is towards the middle of the development lifecycle, that the business decides to take attention.

When this occurs, the business will be seeking validation that the requirements provided thus far will meet their needs, and how is this achieved?

By defining, through process mapping, how the business intend on operating the solution. Better late than never but, ultimately this late validation will see the need to remove or add additional requirements. This may not be too much of an obstacle, assuming the project can absorb any development delays and cost blowouts but should it not be able to manage this change we end up with a solution riddled with gaps. And, how many of those have we seen!

Whether it be capturing high level requirements or detailed requirements, in all cases, these activities should be lead by process design (remember to have your scope confirmed and agreed to before process mapping.)

Many will argue, "But we have no solution to know how to manage the process." Yes, this may be true, but do not discount the value of understanding some of the key process activities for which the solution is required.

You may not have the detail to fill the gaps, but an experienced analyst will (be it a business analyst with process mapping experience, or a pure process analyst working with a business analyst) be able to guide the mapping to identify key lifecycle functions, key process activities to be undertaken across the lifecycle functions (the inputs and expected outputs) and procedures that may be required to manage the processes, across all workgroups and IT applications (be it known or unknown).

The activity itself will assist stakeholders in defining impacts and deriving requirements. Process mapping and requirement gathering are intrinsically linked. Ultimately, the requirement is there to manage a process of some sort – why do we forget this?

Patrick manages a project office at Optus in Australia.