Business Analysts Handbook
Register
Advertisement

This article is reproduced from a series of posts at BetterProjects

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 of 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. etc

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. This is a Risk management 101 article running through the key areas of project risk management.

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.

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.

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.

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.

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, a suburban legal practice would consider a $100,000 critical, while a multinational 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.

Risk Likelihood[]

Risktable1

An example of Likelihood ratings for project risks may be; Highly unlikely, Unlikely, May happen, Likely and Almost certain.

Depending on where you are working you can put likelihood percentages next to these classifications to increase people’s certainty about what they mean. The insurance company Benfield has published this table in presentations as an example. Your bands can be whatever you want, but they help people allocate things into classes and they help people understand what likelihood means.

As an alternative classification system I present this second table from Southern Cross University’s website:

These definitions can also be enhanced by putting timeframes on them; such as within the project lifecycle, within the benefits extraction period, within a year, ten years etc. Again; it’s all in aide of effective communication.

The Insurance industry uses historical information and sophisticated models to work out how likely you are to be robbed or die of a heart attack. IT and Business projects are not yet at this stage of sophistication and I am not qualified to speak for the building industry. However, there are many reports and studies published on the internet and elsewhere that show common risks and how frequently they occur. And the number of reports increases each month.

You can also look at corporate archives to see what common risks occur where you work. For example is there a risk the deadline is too close and you don’t have time to deliver good quality? Are you the hundredth project in that circumstance where you work?

At the end of the day most people today rely upon their personal experience to assess likelihood of a risk eventuating. You should use yours too, but be aware of its limitations. When you get the chance you can search the internet, your companies documents, your colleagues memories and other places for common risk factors and their likelihood of occurring. The wisdom of many can do a great deal to help you avoid risk.

Risktable2

Risk Impacts[]

The Impact of a risk may be to the project and its success criteria (eg budget and timeframes or the quality of the project output) or it could be to the business as a result of the way the project is carried out, or even by bringing in a new product.

If you launch a new product there are always risks. These include risks that you won’t achieve sales targets, risks that customer complaints will go up, and risks that regulatory and compliance requirements may be introduced that increase forecast operational expenses. (Risks can also be positive.)

The easiest risk impacts on project performance to measure are impact to project time and schedule, and to some degree quality, through compliance with requirements, but how do you measure customer satisfaction or company brand or some of the other more long term and strategic impacts?

Impact assessments, like likelihood estimates, are often classified into tiers. As a demonstration of the types of impacts I have created a sample table below with more than just financial impacts. It includes impacts such as shareholder value, reputation and regulatory compliance.

Risktable3

There are many more types of impacts as well and you can look to your industry to come up with typical examples. Health and Safety and environmental impact are two popular categories.

However you categorise risks your team doesn’t have to restrict themselves to the list. Just because my table doesn’t address environmental risks doesn’t mean we shouldn’t consider the risk unexpected disposal costs as a result of the type of batteries e install into our computers we manufacture.

Like most things I have been describing here, these assessment tables are primarily guidelines and communications tools. The aim is to inform people what the impact of risks are so that they can be properly prioritised and managed.

Assessments are best done in groups or in an iterative process to normalise estimates. Regular project risk meetings can provide an opportunity for a consensus assessment of risks. An alternative (and possibly better) approach is to have an expert on (or near) the project team who liaises with the appropriate subject matter experts on the risk metrics.

All sorts of rules and processes can be developed to reduce the impact of personal interpretation but in my opinion the best guideline for risk assessment is breadth of experience and deep local subject matter expertise. An adjunct, but an important one, to this is reading up on the risk areas in your industry so you can be informed beyond your personal experience.

Once the likelihood and impact are understood the risk can be prioritised according to its importance. Prioritisation is a necessity as it’s unlikely that the project will have the resources to deal with all potential risks, nor would it want to if the gates are open for SMEs to suggest all risks that occur to them.

Closing out this topic; categories and thresholds help people rate risks, which in turn can assist people in prioritising them. Appropriate threshold guidelines complement expertise and research. Them more experience you bring to bear the better your assessment and rating.

Risk Assessment and Prioritisation[]

Prioritisation is a tool to communicate and agree on what risks are to be actioned most urgently. It sets expectations and allows for people to understand where a particular risk falls in the project’s workload.

If there is disagreements about priorities the likelihood and impacts can be revisited, and maybe a risk can be re-prioritised. This is likely in many projects as the uncertainty of the future diminishes and the likelihood of risk events occurring is better understood.

The diagram below is a typical tool for representing a project’s risks at a strategic level. You may identify several dozen risks and the number of risks (or the risk reference numbers) can be listed in the boxes representing each likelihood/impact assessment. This then gives an overview of the risk profile of the project. It also highlights which things are priorties to be dealt with.

Riskgrid

Manage a risk[]

Once risks are understood and prioritised for action the team needs to determine what sort of action is appropriate? Typical responses to risks are avoidance, transference, mitigation, and acceptance. Each of these responses has certain characteristics and is appropriate to certain types of risks.

Avoid[]

Avoid the risk by removing the potential risk through taking precautionary measures, which at extremes can mean cancelling the project.

Transfer[]

Usually this means insuring against a risk occurring, but can also include getting the business owner/sponsor to take accountability for the risk outside the scope of the project.

Mitigate[]

This means minimise the damage a risk can cause or reduce its likelihood of occurring (or both) through taking precautionary actions.

Accept[]

In cases where the risk is considered unworthy of effort to manage it can be accepted. This may occur in instances where the risk is so unlikely to occur as to not warrant attention, or where the impact is insignificant in the content of the business and project’s environment.

Whichever option you pick for your risks you should have a detailed action plan against the risk which includes

  • Who is responsible for managing the risk
  • What is going to be done to manage the risk
  • When are the major work activities to manage the risk going to start and end
  • How the risk will be managed as a result of this management plan – that is the planned outcomes of the risk management plan

For risks that require major bodies of work to be managed appropriately you should consider raising a change request and revising the project management plan to include new or modified work packages including this new work.

Monitor your risks[]

Risk monitoring should be ongoing and continual. As you travel through the project lifecycle you should be monitoring for changes in the environment and regularly recheck your assumptions. The likelihood and impact of risks changes over time.

Early on in the project the likelihood of risks occurring is much greater due to the relative uncertainty compared to the end of a project. Also the impact of risks changes over time; for example if you cancel s project at the beginning you have expended less labour costs that at the end.

A project’s success factors change over time also. For example a building development may acquire a success factor of dealing successfully with local anti-development protestors. The risks associated with dealing with these stakeholders will change as their importance and influence changes.

Riskovertime2

As well as monitoring existing risks you will have the opportunity to monitor for new risks. Have new opportunities for risk come up as a result of changing environment or scope? Has the project’s business case or relationship with the rest of the world changed? Specific things you can do to help monitor risks include:

  • Risk Owners: Ensure all risks have an owner, even if there is no active management plan for them. It is best if these risk owners will have to deal with the results of the risk occurring to give them motivation to pay attention.
  • Risk Meetings: Have formal risk review meetings where people have time to stop and think about risks. Time may cost money but often risks can be much more expensive that they first appear. You can also schedule low likelihood and impact risks to future dates.
  • Triggers: Identify triggers for reviewing risks. If a risk is minor today but will become important if something occurs, look out for the something.

Closing project risks[]

You will close project risks at two places;

  • When the risk can no longer happen (maybe it already has occurred, or maybe it can no longer occur.)
  • When the project has closed and there are still open risks.

Typically this second class of risks will be to do with the business operating the new product, system or process. For example, if you release a new CRM there is always a risk of critical system failure which was not there before.

But that is not always the case. Many projects launch their product with some planned or unplanned cleanup work to follow; for example some product documentation will need to be done, or a support process for a particular exception will need to be developed.

Regardless of the type of risk, at the end of the project risks need to be handed over to the responsible operations managers, and it should not come as a surprise to them. If you have managed your risks well through the project process you have informed them of the risks and management plans as you have gone along, and all the better of they have been involved in the identification and management of your project risks.

I am an advocate of a risk handover meeting where you produce all the risks from your projects risk management system and talk your stakeholders through them so that they get a complete and appropriate understanding of the risks they are taking on. You may also be able to hand over some of your project's subject matter expertise in the form of advice on how to handle certain operational risks.

Organisations with high process maturity or an interest in continual improvement often migrate project risk registers into larger databases so that future projects can learn from previous experience. For example, if you have had a resource risk on your project (because the labour market is tight or because the company runs to many projects for the number of people) the organisation can learn if you were a one off circumstance or if there is a systematic problem that needs addressing.

Craig Brown 07:23, 11 February 2007 (UTC)

Advertisement