Risk Management - Risk Management in Practice

This article chapter started with an overview of the steps required for effective risk management and then covered the different types of risks that we are likely to face. Next, we need to put this understanding into practice. That is, raise awareness and get action. There are a few techniques that can be used. Talking about it is the key but it helps to have a framework or structure to give substance to any discussions and create documentation that can be reviewed and referred to down the track.

Depending on the nature of your projects, you may be able to sit down directly with whoever is in charge and spell out the major risks. That's not always the case, in larger organizations with a formal organizational structure, it's not so easy. Or, the management don't want to listen, there's no buy in. Even you know it's a major problem, management doesn't want to hear it. If this is the case, doing a short risk assessment with the key people involved is a great way of getting buy in and getting the attention of the decision makers.

Risk Assessment Overview

The basic premise is you get the key people in the project together and get them to fill out the following form. Each person MUST fill it out on their own so they are not biased or prejudiced by other people's view or influence. Then get everyone to share their results. Note: this is just an overview so doesn’t cover every risk that has been outlined. It’s a summary to get an idea of the overall risk of the project.

System Risks

Overall System

Simple

Average

Complex

Volume of existing content

Small

Medium

Large

Volume of new content

Small

Medium

Large

Integration with other systems

Simple

Average

Complex

Functions / process

Simple

Average

Complex

New business processes

None

Some

Extensive

Stability of requirements

Stable

Average

Unstable

Performance targets

Low

Medium

High

Level of innovation

None

Some

Extensive

Environment Risks

Client experience with CMS

High

Medium

Low

Stakeholder support

High

Medium

Low

Impact on client eg. new business process?

Low

Medium

High

Availability of domain expert

Full time

Part Time

Casual

Number of stakeholders

1 - 3

4 - 10

10 +

Team Risks

Team skills with ez publish

Extensive

Some

None

User skills with ez publish

Extensive

Some

None

Project Manager experience

Extensive

Some

None

Size of team

Small

Medium

Large

Use of contractors

None

Some

Extensive

Project Length

Short

Medium

Long

Deadline

Open

Flexible

Fixed

Physical environement

Good

Average

Bad

Once you get each person to fill this out, you count up the number of ticks in each column to get the total. The column with the highest number gives you a high level indication of the risk profile of the project. The more ticks there are in the left column the lower the risk. The more ticks in the right column, the higher the risk.

So, in the space of about 15 minutes, you can get a pretty good idea of the risk profile of your project. The benefit of getting the stakeholders involved is that you're creating instant awareness. You haven't had to say anything, they can see it in front of them! Hopefully that means you can get straight down to focusing on what to do about the major risks. If there are too many risks, then now's the time to stop the project.

In particular, there are two things that you are looking for

  • What people agree on

  • What people strongly disagree on

For the elements that people agree on, whether it's the project has little risk or there is an aspect that is high risk, at least the key people are of the same mindset and any arguments will only be over what to do about the situation. You've achieved what you wanted, raised awareness and hopefully got agreement that action is to be taken (what action, depends on the project and the risk itself).

For the elements that people strongly disagree on, eg. person A says it's not a risk and person B thinks is a big risk, then you've identified yet another risk, the ability to get consensus. For a project manager, this is powerful insight into the potential issues you may face down the track when decisions need to be made. Projects rarely run smoothly and changes are inevitable. If you have stakeholders or decision makers that can't agree, it's going to be hard to get direction on what to do and you don't want to be stuck in the middle. This is a perfect example of a personal risk factor. Of course, this approach doesn't resolve the issue but it makes you as the project manager aware of it and you can then decide how you're going to manage it, eg. take the risk or walk away (assuming that's an option!). Of all the risks identified, the most important ones are the team risks. If you have an experienced team that has worked together, you can counter many of the risks. But if your team is inexperienced, even medium level risks can become problems. At the end of the day, the success of a project is going to depend on the team.

Risk Memos

An alternative approach is for you as an individual or each of your team to identify, analyze and evaluate all the potential risks. Then it's just a matter of, working out what can be done to prevent them from happening or contain and control the impact they will have on the project.

Now, all projects will have risks, there's always something that can go wrong and identifying every risk is counter productive, it's only the high risk factors that need to be brought to the attention to management to get action or create awareness. Trying to cover off every risk is not possible or productive. That's why this chapter is titled "Risk Management" because at the end of the day that's all you're doing, managing the risk. The small or remote risks are going to be there regardless, what you need to do is make sure the major risks are dealt with.

A simple way to do this is using a risk memo which states the risk, the impact on the project, the potential cost, reduction strategies and a contingency plan. It may seem like a lot of work but it's pretty straight forward using the following template.

Risk Factor

Legacy database structure is not optimised for website needs.

Impact (if not resolved)

Site will perform slowly

Development will be complex

Cost of non containment

Estimate additional 1 month development & testing work required.

Cost: $25 – 30k

Minimisation Strategy

Design database structure for website and migrate external data into the web database.

Contingency Plan

Purchase more hardware to manage increased load.

The above example is from a real project. It took approximately 10 months to complete from the start of the specification to go live. After the specification was completed, I identified the major risks. There were 7 in total. All 7 risks had the potential to put the project over time by anywhere from 1 to 4 months. Anything that was going to cause a delay of less than a week, I didn't bother to document since those sorts of problems could be dealt with during production. The key was to make sure to identify any problems that would cause a serious overrun in terms of budget or timeline.

Shooting the Messenger

If you take the risk memo approach and then present them to management or the stakeholder, beware of the "Shoot the Messenger" syndrome. In the project where the above risk memo example comes from, I was considered a messenger with bad news and it wasn’t taken well. Rather than focusing on the risk at hand, management looked at me as the problem for highlighting the risk. In hindsight, I would have been much better off taking the short assessment approach because then I wouldn't have ended up at a meeting table with a barrage of angry faces and shouts of "why didn't you tell me this earlier!". Trust me, it's not much fun!

The reality is no-one likes bad news. Knowing this, I started the meeting with a quote from the most recent Standish Report on Project Success, it said that over 70% of software projects fail – not something management likes to hear. My rationale for saying this was to prepare the stakeholders for bad news, that chances were, their project would fail. Of course, I felt safe in the knowledge that I had the answer and if they followed the minimization strategies outlined in the risk memo's everything would be fine.

To some degree this approach worked, but mostly it just got a lot of people worried and upset, including me. From my experience, you can't just tell people bad news and expect them to accept it and act immediately. In my case, I got some action and then the rest of the risks were ignored and dealt with later. A better approach is to get people to come to there own conclusions, this is why starting off with the short assessment form is an easier way to deal with risk management.

Risk management itself is a risky activity, but an important one. It's a bit like insurance, you can get away without it until something goes wrong at which point you wished you had done something earlier.

Who is Responsible?

If you've gotten to this point in one piece, you're doing well! Hopefully you've got awareness of the risks and agreed on action. Now, it's a matter of making sure the action is taken by the right people and that depends on the nature of the risk. For business risk, it's the project sponsor and stakeholders that are ultimately responsible.

For project risk, the project manager is in charge, hopefully with support from stakeholders

For production / system risk it's usually the IT team.

For benefits realistion risks, it's back to the stakeholders as they are the ones who gain to loose if this is not addressed.

Finally, personal risk, that's up to you!

Risk Reporting

Once the project is underway, it doesn't end there. As mentioned at the start of the chapter, risk management is an on-going activity.

The following risk report is an example of what needs to be updated on a weekly basis to

  • Monitor progress on minimizing known risk and,

  • Identify any new risks.

All that is required is a list of all high risk factors, in order of priority with the number of weeks the risk has been on the list. For each risk there should also be a risk memo that has more details that can be referred to if needed. This is a summary that can be used to maintain awareness and make sure action is taken.

This Week

Weeks in Total

Risk Factor

Minimisation Strategy

1

4

External schema not optimized for web

Create define new data structure and script transformation for data feed

2

4

Interactive Planner integration needs uncertain

Get technical documentation for interactive planner

3

1

Sample data not available

Create sample data set for initial testing

4

5

Performance requirements not confirmed

Define performance requirements for normal & peak load times – concurrent requests per second

5

5

Unclear roles & responsibilities

Draft roles & responsibilities and assign to team members

There are a few points to note in the above example.

The third row shows a new risk. In this project , there was a milestone for the client to provide sample data for the developers to use in constructing a particular feature. The deadline passed and even though emails had been sent noting this – it wasn't acted upon. Being able to add this to the risk report raised the profile and helped to make the stakeholder aware that something needed to be done and pressure was placed on the department that was supposed to supply the data. The fourth row shows a risk to do with performance. It's placed lower in the list as it won't impact on the project until the later stages but it was important to have it on the list so that it could be dealt with in due course. The fifth row shows a risk that was noted upfront but not dealt with. The project was moving forward without too much issue but there was still some confusion as to who was responsible for some parts of the project. However, it wasn't having too significant an impact on the project. In time, some risks prove to be less serious that initially expected so can come off the list.