There are plenty of resources available on project risk management. It’s an important topic. After all, if you mismanage risks, your project could run late, go over budget, fail to deliver its benefits, or fail to be completed at all. The topic of project risk management is often treated academically. Try reading most books, articles, or blogs on the subject and you are quickly submerged in frameworks, assessments, protocols, Black Swan theory, and Monte Carlo simulation. There is also some practical advice about holding an initial risk assessment meeting at the outset and again during the project, so risks can be logged and monitored. Unfortunately, there are also things that happen that team members don’t really recognize as project risks, as they are situations that happen all the time and assumed to be ‘just the way it is’.
Identify risks by listening
Often, additional risks can be identified outside of formal risk meetings. Once identified, risks can be managed, so identification is critical. Project managers need to practice their listening skills throughout the project to identify additional risks. In any kind of project meeting or casual discussion, risks can be identified. Here are several examples I’ve heard at different times, and how I heard about them:
· When we change the active directory security groups we need to make sure it isn’t month-end because there are always so many errors that users can’t work for a while. (In a meeting on scheduling)
· At go-live, it’s always crazy trying to get the inventory to reconcile, the accountants end up doing lots of ‘plugs’ and estimates, then they figure it out correctly and fix it the next month. (In a status meeting, when the discussion got side-tracked to an unrelated topic)
· When we launch new forms, the end users make a mess of them because they can’t figure out how to fill them in. Then we have to re-work the form and launch the revision. (At a kickoff meeting for a project to design and implement a new form)
· We hope that Jenny never catches the flu, as no one else knows how to do that critical step we need at go-live. (At a status meeting, while explaining that a component is late due to Jenny’s lack of availability)
· It seems like there’s an awful lot of work to be done on the go-live weekend, I wonder if it’s too tight. (In the kitchen, when the project manager was getting coffee)
· We have a new vendor working on an internal web site for our HR department. (In a discussion about roles and responsibilities)
· The vendor’s project manager is a sub-contractor; do you think she will keep the vendor’s senior management informed and engaged? (Informal chat, after the vendor’s project manager had been introduced)
The risks noted above did not come up in official risk identification meetings, but instead came up in other unrelated discussions.
Managing the risks
Because these came up outside of the formal risk meeting, and many were assumed as ‘just the way it is’, there was sometimes resistance when the question was asked “what can we do to manage this?” However, when pressed further, it was frequently possible to identify steps that could be taken to manage the risk. Let’s look at risk mitigation ideas for the first few risk examples:
· If changes to AD security groups usually have a lot of errors, can they be subject to a rigorous review step before implementation, or can the testing approach be examined to see if there are gaps, or can part/all of the process be automated?
· If it’s crazy trying to get the inventory to reconcile, how about a rehearsal, or customized reconciliation reports, or review the approach with the accounting department to see what additional controls are warranted?
· If new forms are not well received, can they be vetted and changed as part of the project instead of after launch? Is it possible to create a user advisory panel, or run a pilot with a subset of users?
As you can see, once the risk is identified, it’s possible to come up with ideas on how to mitigate that risk.
Although the risk identification meetings can generate some ideas about risk, additional risks can be identified if the project manager is listening for them. Ask yourself every day: Did I hear something today that might suggest there’s a risk we aren’t managing?