Who bravely dares must sometimes
risk a fall. – Tobias G. Smollett (1721-1771)
Smollett studied medicine at Glasgow University and
served on a warship as a ship's surgeon. A contemporary of Fielding, Smollet was hardly a great novelist - but his adventure books were (in their time) a 'thumping good read', based as they were on his
own real experience of the hardships and risk faced by the naval adventurer.
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.
In terms of the naval analogy, inherent risk is the height of the sea and the state of the weather.
Project (Specific) Risk
Project Risk is the risk specific to your portal project. Extending the
analogy, this is the seaworthiness of your ship!
Some Project Risk stems from the nature of what you are doing; there are
certain risks common to any portal 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.
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 (see panel right) to first populate the log.
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.
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.
It may well be convenient to use the Risk Log to also track any issues on
the project. Issues will generally fall into a general category - i.e. (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, (I) Other issues. Give issues just an importance score (of between 1 and 9).
If you manage and report regularly on risks and issues, you will have substantially
improved your chances of project success!