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