Inherent (or Business) Risk
Inherent Risk is the risk that exists in the environment
around your portal project. It will tend to be unique to your organisation; it's culture
and politics. For example, if you have a fragmented business (either geographical or
functional), then this will create a higher inherent risk of poor communication.
Project (Specific) Risk
Project Risk is the risk specific to your project. Some
Project Risk stems from the nature of what you are doing; there are certain risks common
to any project (e.g. the unfamiliarity to users of the technology you are deploying).
However, most project risk is under your direct influence; for example the skills of the
project team, the level of governance effectiveness and so on.
Stage Risk
Finally, there is 'stage risk' which is the risk
associated with the particular activity of any given phase of the project plan.
The Risk Log & Risk Plan
In order to stay in control of the risks to your portal
project, it makes sense to have a formal log of all risks, to which anyone involved with
the project is entitled to add. You might use a formal workshop to first populate the log.
Assessing Risks
Each risk (however derived) can be assessed using a
simple methodology, whereby the probability of the risk being realised ('likelihood') and
the size of the impact on the project objectives ('severity') can be measured.
The simplest system (based on the PRINCE project
management method) is to give a score of 1-3 for likelihood and severity (where 1 is low
and 3 is high). From these scores, the importance of each risk can be measured as the
product of likelihood and severity.
Clearly, any risk of importance 9 demands immediate
attention, followed by risks rated 6 and so on.
Risk Counter-measures
The importance of each risk should be regularly
maintained, based on the extent to which the likelihood and severity of impact change over
time.For each risk, one should enter a counter-measure in the risk plan. Where a risk can
be eliminated, then this will be the counter-measure. Where it cannot be fully eliminated,
then risk mitigation actions will be the most appropriate.
Issues Log
A Risk is something that is yet to happen, whilst an
Issue is something that has already happened.
It may well be convenient to use the Risk Log to also
track any issues on the project. Issues will generally fall into one of the following
categories:
(R) - Request for a change (in the scope of the project)
(O) - An item has been identified that is
Off-Specification
(Q) - A Question has been raised that needs to be
resolved
(S) - A Statement of Concern has been raised by someone -
and
(I) - Other issues.To score issues, just ascribe an
importance score (of between 1 and 9).
Managing Risks and Issues
Once you have put a Plan in place, then it is important
to regularly monitor and report on the counter-measures that have been deployed and
whether or not they have been successful in reducing the overall risk profile of the
project.
For templates and examples of risks and issues pertinent
to intranet portal deployment projects, please check out my chapter on Risks and Issues
(see http://www.viney.com) in the (free to access) Intranet Portal Guide.
If you act, manage and report regularly on risks and
issues, you will have substantially improved your chances of project success!
David Viney (david@viney.com) is the
author of the Intranet Portal Guide; 31 pages of advice, tools and downloads covering the
period before, during and after an Intranet Portal implementation. Read the guide at http://www.viney.com
or the Intranet Watch Blog at http://www.viney.com/intranet_watch.
Learn How To Write A Case Study
Case studies involve a particular method of research. Rather than using large samples and
following a rigid protocol to examine a limited number of variables, case study methods
involve an in-depth, longitudinal examination of a single instance or event. [Read More]
Your Thoughts?
What are your thoughts on this? Drop me a line at ivan at klariti dot com |
