|
Have you had a project that didn't meet its objectives? There is a seemingly endless list of reasons why projects fail,
and each of these reasons is a potential risk that you must
mitigate. In the next two articles, I'll provide you with a
framework to identify more of the risks your project faces, before
they happen. Once you have a more complete idea of the risks you face, you
improve the likelihood of completing your project successfully.
Known Unknowns
To start, let me quote former US Defense
Secretary Donald Rumsfeld, from February 12, 2002:
"There are known knowns. There are things we know
that we know. There are known unknowns. That is to say, there are
things that we now know we don’t know. But there are also unknown
unknowns. There are things we do not know we don’t know."
Rumsfeld was the subject of a lot of jokes for this statement.
But it's a very accurate summation of what you face, as someone who
must manage risk.
The "known knowns" are the problems, issues, and tasks that you
are aware of right now. These aren't risks. These are
known issues that you must deal with. In risk management
parlance, they have either already happened or they have 100%
probability of occurrence.
At the other end of the spectrum, the "unknown unknowns" are the
things that could happen, but you don't know what they are, so it
becomes very difficult to plan for them. This includes
catastrophic "black swan" events, such as the recent global
financial crisis.
The focus of this article will be the "known unknowns".
These are known events that may or may not occur, such as a key team
member quitting. Since we can
reasonably predict that they may occur, we can identify them and plan for them.
How do You Identify Risks?
OK, so we know that risks are important. So, how do you
identify them? Here are some considerations to help spot risks
that may be lurking in your projects.
Be honest: Perhaps this goes without saying.
But in a world where the contract goes to the vendor with the lowest
price, its easy to be optimistic and overpromise what you can
achieve. This is especially common in fixed price contracts,
where less aggressive proposals will often cause a potential
customer to walk away. The business reality is that companies
will often need to be aggressive with their quotes. But this
means that you need to be even more diligent about recognizing and
mitigating the associated risks.
In fact, when it comes to identifying risks, its usually more
productive to be pessimistic. Pessimists are
excellent in identifying things that could go wrong. Then,
once you've identified your risks, become a realist again and focus on solutions to mitigate those risks and plan for contingencies.
Learn from the past: Why have your company's
past projects failed? And for past projects that succeeded,
what problems did they encounter? Very few companies reliably do
good failure case studies.
However, a small amount of research into past projects can reveal a
wealth of information on risks in your organization and your
technologies that
need to be mitigated in your project. Over time, you can even
develop a checklist of risks that are typical of your projects.
Look inside and outside your team: Many project
managers simply focus on risks inside their project team. For
example, the risk that an algorithm may not provide the necessary
throughput. However, many risks lurk outside your team as
well. For example, a lack of executive or stakeholder support
could derail your project, or quality issues in a supplier's
component could make the system unusable.
It's easy to simply identify such issues to senior management,
say that they are outside your control, and leave it at that.
But external risks can and should be mitigated by your team.
Effective communication and stakeholder involvement can often turn
external critics into project supporters. And development
methodologies like Agile use frequent integration, testing, and
communication to mitigate external quality problems. Identify
your external risks and act on them, just as you do for risks that
are fully within your control.
Identify your assumptions: Every project plan
contains assumptions. You assume that the final version of a
dependency will be available by a certain date. You assume
that a particular component will meet the end users' needs.
These assumptions are risks, and must be tracked. If
you already identify your assumptions when you provide estimates,
take these assumptions and copy them into your risk register.
If you don't identify your assumptions when you provide estimates,
then start. Every estimate makes assumptions, and if you
identify those assumptions up front, then you've identified some key
risks that could invalidate your schedule, if they materialize.
Search for risk statements: In the
Final
Report of the Universal Risk Project, the INCOSE Risk Working
Group and the PMI Risk Specific Interest Group identified two risk
statements, which can indicate possible risks:
- An IF - THEN type of risk statement.
- Example 1: If this technology is not
available, then we will not meet the requirement.
- Example 2: If we cannot hire sufficient
qualified software engineers, then we cannot meet the
planned development schedule.
- A CONDITION - CONSEQUENCE risk statement.
- Given the “condition”, there is a likelihood that
“the consequence” will occur.
- Example: Given that this specific test
fails, the consequence is that the planned schedule will
slip.
Search your documentation, plans, and discussions for these forms
of statements. Then include them and plan for them.
Target the root causes: Risks are more easily
managed when you target the root cause of the risk, rather than a
symptom of the risk. For example, you may be tempted to
include the risk, "Developers introduce regression defects into the
code", when the real root cause of the risk is that the developers
may not have sufficient experience working in that part of the
application. The root cause of a risk is more specific and
will have a more specific mitigation. As well, remember that a
symptom may have multiple root causes, and a root cause may show
multiple symptoms. A useful tool to manage this is the
Ishikawa diagram, also known as a fishbone diagram or a
cause-and-effect diagram. Here is a template Ishikawa diagram,
courtesy of
Wikipedia:
Work as a team: Risk analysis is best performed
as a group activity, rather than on your own. One problem with
assumptions is that you often don't know that you're making them,
until you're challenged by someone else. Two tools you can use
to identify risks as a team are brainstorming and the
Delphi method.
Note that the rule to look inside and outside your team applies
here as well. Involve external stakeholders in the discussion,
either by including them in the risk analysis team or by simply
interviewing them for their input. They will often have unique
perspectives that you've overlooked.
What Next?
So far, we've talked about how to identify
risks. In my next article, I'll discuss where risks
hide in your project. (Sorry! It was originally going to
be one article, but I decided it was getting too long, so you're
going to have to wait for part 2...)
Lastly
Thank you to everyone for providing me with excellent feedback. There
seems to be a lot of interest in risk management topics, along with innovation
and human / cultural topics. As always, if there is an area that you'd
like more information on, please let me know! Also, if you have some
information that you'd like to share, please send it and I'd be happy to include
it.
I have a request for you! If you are
finding these articles to be helpful, please forward them on to
someone else who may benefit from them, and invite them to join the
list. More people on this list means that more people will
contribute their ideas, which benefits everyone (including me, of
course...).
Of course, if you have any questions, or if you would like more information on how to implement these or other
software development processes in your organization, please feel free to contact
me at Charles@CharlesConway.com.
Good luck!
Charles
| 
