Class of 2019: Risk Management For Rookies

 “The real troubles in your life are apt to be things that never crossed your worried mind, the kind that blindsides you at 4pm some idle Tuesday” Baz Luhrman, Everybody’s Free (to wear Sunscreen)

Most PMs are undiagnosed control freaks. We like everything in its place, everything in order, everything happening when it should. Methodologies such as Prince2 even give us frameworks to apply, to allow us to order our work further and compartmentalise activities. We use gates to continually check progress and scope, and we keep a tight grip on change.  So, what could possibly go wrong?

Well I’m sorry to break this to you, but life just doesn’t work according to rules and documents. It has no respect for planning or prayers. Sometimes, things just happen.

In my time as a PM, I’ve personally seen the following:

• Resources stuck on the wrong side of the world due to volcanoes erupting
• Resources late for critical meetings due to escaped chickens on a motorway
• Whole teams wiped out by Swine Flu
• Servers undelivered due to Tsunamis in the Far East
• Critical servers crashing because a cleaner has unplugged them in the Data Centre
• Global HQs evacuated due to flooding (Vodafone, take a bow)

Some of these, arguably, could have been foreseen, but others (escaped chickens, really?) could not, at least, not in the short term. Possibly, Vodafone should have rethought building their HQ around a lake, but there you go, we live and learn.

All these examples are ‘Issues’ in PM lingo, because they’ve happened. I’m not imagining them, they really did occur, and I had to deal with them there and then. Its pretty obvious when you have an issue, you’ll know when it hits you. Risks however, are problems that might happen. I might win the lottery and not finish this article, but let’s be honest, it’s unlikely, especially as I’ve not bought a ticket. And so, as you see, we’ve begun assessing the level of the risk already.

So, before we jump the gun, Risk Management generally consists of:

1. Identifying risks
2. Assessment
3. Responding

The first step is tricky. How do we know what’s going to happen? Spoiler: We don’t. We have to take a good look at the context of the project, ie what we DO know, and, make some sensible judgements about what could go wrong.

Let me give you some examples:

-Are there lots of dependencies between different teams?

-Is it new technology?

-Is the timeline challenging?

-Do you need quick approval from that guy in Finance you had the argument with last week?

-Are all the teams remote?

-Is the HQ built in a lake?

Clearly, you have to stop somewhere, but by assessing the project the PM can identify likely problems. Past history and experience is another key indicator, read previous Lessons Learned if they exist. Talk to peers and stakeholders.  Here’s some common ones from my experience:

• No one lines up Training, Infrastructure or Environments early enough. Whatever stage you’re at, start now.
• The guys who says he’s 90% complete, isn’t. The last 10% takes 90% of the time. Don’t believe him.
• The offshore supplier that’s been reporting Green for the last 10 weeks will turn Red the week before it’s due.

Once you’ve got all your risks written down, what then?

Firstly, what is the probability of a risk happening? High, Medium, Low? We’ve stablished that the risk of me winning the lottery before finishing this article is Very Low, but the risk that my laptop battery will die is pretty High.  Once we have defined this, we look at the impact.

The impact of me winning the lottery would be High (because I’d be on a plane to the Bahamas), the impact of my battery dying is Medium, because I could re-write it, if I still have the will to live.

Next, we look at what responses are appropriate for the risk.

Whilst winning the lottery would have a high impact, the probability is VERY low, so we can discount this in a real-world assessment. My battery dying has a fair potential to occur, so I’m going to take action.

What are my options?:

• Prevention – Plug in my charger
• Reduction – Save the file so it can be recovered
• Transference – Get someone else to write the article
• Acceptance – Hope for the best
• Contingency – Send an old article instead

Now we select the most appropriate action and implement it. We’ve established I’m a control freak, so I’ve decided to save it in two places and plug my charger in. Just in case….

Crystal balls don’t work too well, and, in the absence of divine intervention, this process should help you to identify and address the key problems your project is likely to face, but as I said, sometimes things just happen, so don’t take it personally.

Watch out for those chickens, though.