I don’t think I’m the only one who has drawn a parallel between project management and Whac-a-Mole, the arcade game where you have a mallet and moles pop out of the board and it’s your job to whack them when they appear.
Something comes up – you whack it. You hope you can whack it hard enough it never comes back, but that’s not actually the way Whac-a-Mole works, I think.
It’s not the way project leadership works, either.
Acting, Not Reacting
I’d like to say that you’d get better results if you took care of the mole, nurturing it and making it a better contributor to society. But in our analogy, if you’re constantly bashing moles, you’re not in charge of the priorities. You’re always reacting to events.
Come on, you may be saying. Sure, you can’t tell where the next mole is going to pop up, but I can’t tell you where the next fire on my project will flame up, either. Complete parallel. Whac-a-Mole analogy confirmed.
The Risk Register
And here is where one of the most under-used project management tools comes in useful: the risk register. Variously called the risk mitigation plan, risk log, and risk mitigation action plan (among other names), the risk register is used to identify things that might happen. Generally the log includes a rating of the likelihood of each risk, and the severity of impact should the risk occur.
In typical usage, the risk log is assembled at the beginning of the project and then it sits, unchanged, for the life of the project. The risk log is brought out occasionally to demonstrate that the project has such an artifact, and then it is wheeled back to its lonely corner of the project document repository until the next audit.
Why does it receive such treatment? On the surface, it seems to be such a useful document. Of course, we should know what risks there are which could rise up and impact our project; we should be watching this like a hawk!
I think there are two reasons why the risk plan is so ignored. First, the risks logged are often not the risks you should be worried about: Things like “Economic downturn hurts the company’s profitability” or “System integrator goes out of business.” They tend to be distant and relatively unlikely.
Second, of all the classic project management documents, it has the least obvious actions related to it. You can have a weekly meeting to ask about issues, but risk lists tend not to change very often, so their weekly meeting gets tedious and soon abandoned. Most people are satisfied to complete the risk log and mitigation plan, secure in the knowledge that they have checked off a deliverable and now have a small insurance policy against risks. Oh, that risk? We’ve got a mitigation plan for that!
So there are two actions to make the risk log meaningful: Document more specific risks, and implement a more active plan to manage the risks.
Let’s talk more about this and how they connect.
Deliverable vs. Outcome
No one ever has a risk that says, “Project team fails to deliver.” In fact, some people would say that that doesn’t fit the definition of a risk, so they don’t put it on the log. “Every other document we have is about ensuring our success,” says the logic. “We don’t need to document our own failure as a risk.”
Here’s why it should be on the list: Your risk register should identify things that could impact the project achieving its business objectives, not just things which could impact the completion of a deliverable.
The distinction here is that a project deliverable, like a process design or a computer system, is not the business outcome; it’s something that enables the business outcome.
Don’t confuse a deliverable with the project outcome.
When you look at it that way, it should become clear that a deliverable not being satisfactorily completed could endanger the project’s success. You won’t want to drown your risk log with risks for every single deliverable, but then, not every deliverable has an equal chance to torpedo your entire project.
Risk Scenarios
Here’s the next reason it should be on the list: While the risk register classically identifies mitigation plans for each risk (usually at the level of three sentences of business jargon), what you really need to be doing is building risk scenarios.
Think of risk scenarios like war games: If events A and B take place, what do we do next? If event C takes place and event D doesn’t, what do we do?
The idea of scenario planning is not that you take actions regarding every scenario, any more than you actually execute a risk mitigation plan in advance of the risk occurring. Instead, you use the planning to assess the project’s state of readiness. If you make an organizational change, maybe it supports scenarios 1 through 4, but not scenario 5, while a different organizational change supports all five scenarios.
In fact, you probably do something like this mentally every time you consider a change.
The nature of scenario planning is that it tends to be a little higher level. You might have thirty items on your risk plan, but you reasonably couldn’t give attention to thirty different scenarios. So, what are the big-ticket items, the scenarios that totally torpedo the project? Maybe you can group them, not basing them on a specific, but on their outcome, i.e., “Module A is not delivered on time.”
Another way scenario planning can help out is in reviewing the scope, schedule, and budget. For example: Management has told you that something needs to be trimmed. Your scenario planning will tell you what part of the project has the least impact.
The last piece of advice in taking the scenario approach and distributing your focus on the different parts of the project is to be consistent. Don’t give your team whiplash by being freaked out by inventory one day and accounts payable the next. The point is to have visibility and monitor the challenges in every area. You might need to stress one area over another to keep it in line, but keep the overall priorities consistent from day to day and week to week.
This sort of steady, controlled approach will continuously build confidence with your team and stakeholders and keep the team heading for success.
And keep the moles sleeping peacefully.
