This document describes the risk management process for risks to the OpenWIS Association. This is a supplement to the Articles of Association and Internal Rules. In the event of any discrepancy between the intentions noted in this document, meaning and governance shall be sought from the Articles of Association then the Internal Rules over this document. Note that individual projects being run or incubated by the Association each determine their own risk management process.
Risk Management Process
Since Risks are just potential Issues, we use the Issue tracking built into GitHub to track Risks. This is done as follows:
- Add a GitHub Issue to the openwis-documentation repository for each Risk: the title should start RISK-NNNNNN-title, where NNNNNN is the next available six digit number in sequence.
- Add a detailed description of the Risk in the initial comment, using structured sentences.
- Add estimated Impact and Probability (very low to very high) for financial, reputation and goals.
- Assign risk RAG label (RED/AMBER/GREEN) accordingly.
- Add the Issue to the GitHub project used to record the risk issues, to the appropriate column based on RAG.
- Assign the risk owner(s) to the Issue.
- If action on this risk is required outside the routine risk review cycle, assign a milestone for the next risk review or risk action.
- Label with the Committee that is tracking eg: PMC/TC/SC/BM. If a risk is escalated, then change the label to the Committee it was escalated to. Label with RISK.
- Add routine or ad-hoc risk reviews to the agenda of PMC/TC/SC meetings as required.
- When necessary, PMC and TC would escalate risks to SC. PMC and TC would also provide a risk summary report to the Annual Meeting for review by both the SC and the Board.
- The SC would escalate risks to the Board whenever they require Board decisions or actions to manage.
- In general, project risks will be managed by the PMC, broader technical risks will be managed by the TC, risks to the Association will be managed by the SC, the Board will only manage risks escalated from the SC, usually because they need Board level actions/decisions according to the articles/rules. However. the Board may assume management of any risk at it’s sole discretion.
chance of occuring description % probability Very Low Unlikely <5% Low Possible 5-30% Medium Likely over time 30-50% High Likely 50-75% Very High Likely and Imminent >75%
Financial €k Very Low <25 Low 25-50 Medium 50-75 High 75-100 Very High >100
Reputation Very Low A few unhappy members/partners/contributors Low Several unhappy members/partners/contributors Medium Loss of potential members/partners/contributors High Loss of existing members/partners/contributors Very High Loss of credibility with WMO
Goals Very Low Minor impact on goals Low Significant impact on one goal Medium Significant impact on more than one goal High Failure to achieve one goal Very High Failure to achieve more than one goal
prob\impact VL L M H VH VL G G G G G L G G A A A M G A A R R H G A R R R VH G A R R R
Where RAG status is: R=RED, A=AMBER, G=GREEN.
- RED = Immediate action required to mitigate, avert or otherwise manage the risk.
- AMBER = Plan of action required for managing the risk in the future.
- GREEN = Level of risk acceptable, no action required apart from monitoring.
Although a project PMC doesn’t have to use the risk register structure above (each project manages its risks as agreed by the project) it might be useful because the Project Management Committee will need to escalate any risks to the Steering Committee that are a threat to the Association. They may also transfer technical risks that have wider implications than just the project, to the Technical Committee.
See the OpenWIS Association risk log.
Individual risks will be reviewed by the Steering Committee on a schedule appropriate for the management of that risk, and by exception (ex-committee) if a risk requires urgent attention. The Steering Committee will review the entire risk log on a twice-yearly basis.