This article is part 4 of a four-part series on project management lessons from the tsunami
that damaged the TEPCO Fukushima Dai-ichi nuclear complex.
Tuesday, I noted three big
project-management errors in their risk analysis. Wednesday, I
described how they missed
a big risk. Yesterday, I detailed single-point-of-failure
issues. Today's final installment examines risk review.
Litigators are fond of saying,
"Never ask a question to which you don't know the answer."1 Granted,
they're talking about a specific circumstance, a witness on the stand, but the
expression has hold of attorney imagination.
For one thing, you don't risk
looking dumb if you don't ask questions. Also, some people - not only attorneys
- think that control of a situation or a team means not only never showing
ignorance but proactively demonstrating you know more than the other players.
Neither rationale is a good idea in
dealing with risk.2
Not only does a project manager need
to ask questions to which she doesn't know the answer... she needs to do so
repeatedly, and often with the same questions. Eek!
Reviewing Risks
One of the big lessons from TEPCO -
short for Tokyo Electric Power Company - is that the risk plan for tsunamis was
never updated... but new facts emerged during the years after it was written, as
I noted in Part 2
of this series. For example, clear evidence was discovered of historical
tsunamis far larger than the supposedly maximum 19-foot wave and magnitude-8.6
quake they'd planned for.3 As we all now know, they got it wrong,
which became clear when the water level rose 46 feet after the 9.0 megaquake.
Risk review is an ongoing process,
not a one-time event.
On any project, the project manager
and team need to review the risk sheet regularly. I recommend weekly or
fortnightly on most legal projects. It's a brief process, not a long meeting.
Expedite it by circulating a current version of the risk sheet ahead of the
meeting, highlighting whatever's changed since the previous meeting. Even
better, sort the sheet so that the changes are at the top.
The risk review for most projects
should not be a separate meeting; rather, it becomes a brief part of your
overall team meeting (the shorter, the better... within reason). If you do this
well, it will take five minutes, maybe less.
Ask the team some questions you
don't know the answer to:
- Are the changes correct/sensible/agreeable?
- What new risks are we facing?
- Is there something else on the list that you think
should be changed - probability of occurring, mitigation plan, etc.?
And then, listen. Listen to their
answers, even if you don't agree with them.
As with any meeting, manage it both
to encourage the less vocal folks to speak out and to rein in any discussions
that get off track or go on for too long.
Tell the attendees also to email you
(or see you in person) if they see or hear of something new before the next
meeting. This gives the less vocal and/or lower-power team members the
opportunity to raise risks without fear of being subtly ridiculed or undermined
in the group meeting. Ideally, of course, you want to lead the team so that
everyone is empowered to participate without recrimination in meetings, but the
world as it is rarely meets our ideals.
Likewise, if there's argument over a
risk - serious debate, not nitpicking - quickly defer it to a separate
discussion rather than sidetrack everyone in the meeting (when the core purpose
of the meeting is something other than looking at risk). Don't pooh-pooh it,
don't minimize it, but saying "Let's talk about it later" isn't minimizing it,
as long as you do get to it at some point before the next meeting.
This sounds like a lot of work.
First, project management is, of
course, work. Second, risk review really isn't that much work once you get the
hang of keeping it moving... and the payoff can be enormous. So can the cost of
failure. Third, don't just review the risks but make sure your mitigation and
contingency plans4 are appropriate. Knowing that you're subject to
tsunamis that can overrun your seawall and that your backup generator system is
a single point of failure isn't terribly valuable in itself; the value is in
doing something to mitigate the problem before it occurs. (We know they didn't
mitigate it, but it sounds like they had no contingency plan in place either.)
I hope the failure won't be anything
as dramatic as what happened in Japan. But on a far smaller scale, these
failures can seriously damage your projects, hurt your clients, and affect your
profitability or budget discipline.
Spend a little time on risk review,
or spend a lot of time cleaning up the mess.
==============
1I was raised during an era where folks were strict about not
ending sentences with prepositions. It's not a grammatical necessity, as pretty
much any modern style guide will note. Or as Churchill allegedly (and unprovably)
said, it's nonsense "up with which I will not put." Still, some habits die
hard.
2Trying to demonstrate you're the smartest person in the room
is not a good leadership strategy, either.
3There, I ended a sentence with a preposition. Y'know, that
doesn't feel so bad after all.
4In project manager parlance, mitigation is what you do to
minimize the likelihood and/or the impact of a risk coming to pass. The
contingency plan covers what you do should the risk actually occur.
Read more on the Lexician Blog
For more information about LexisNexis products and solutions connect with
us through our corporate site.