- Title page
- Section 1 Purpose
- Section 2 Strategic Alignment
- Alignment of IT Projects with Business Strategies
- Information Management Principles
- Alignment with the Business Strategy
- Monitoring Agencies: Strategic Alignment - what to look for
- Risk Management Strategy
- Monitoring Agencies: Risk Management Strategy - what to look for
- Business Capability and Continuity
- Monitoring Agencies: Business Capability and Continuity - what to look for
- Section 3 Business Case
- Section 4 Governance and Management
- Section 5 Project Management Processes
- Section 6 Technological Environment
Risk Management Strategy
The Australian and New Zealand Standard (AS/NZS 4360 1999) defines risk, as "the chance of something happening that will have an impact on objectives. It is assessed in terms of consequences and likelihood".
Risk management is the "systematic application of management policies, procedures and practices to the tasks of identifying, analysing, assessing, treating and monitoring risk".
The risk management strategy sets out a process for identifying, documenting and treating potential risks.
A risk management strategy will be prepared for each project. The strategy will include:
Risks are associated with:
Business risks to consider include:
Technology risks to consider include:
Project risks to consider include:
External political risks to consider include:
Quantitative risk analysis provides structure for assessing and treating risks.
Quantitative risk analysis involves:
Unless relevant Ministers agree that the size and nature of the project do not warrant this approach, quantitative risk analysis should be used as the basis for:
Quantitative risk analysis (QRA) enables more accurate project costing.
QRA or risk modelling is an essential part of the approval process.
How it is operationalised will be determined on a case-by-case basis.
- Gaps exist in alignment with the business strategy from a planning and technology perspective.
- The completed system does not meet required business outcomes.
- The business cannot be sustained during the project lifecycle.
- The department does not have the capability to deliver the changes.
- Projects are not scaled from a risk perspective.
- The justification for the project is not based on clearly identified business outcomes.
- Risks are not managed as they arise.
- All risks are not fully assessed and provision for them is inadequate.
Examples of business risk:
- Restructuring the department, with direct impact on the project scope and business benefits.
- Lack of visible senior management sponsorship and leadership.
- Change of Project Sponsor or Chief Executive, and consequent change in commitment to the project.
- Changes in key project staff, with the change of Project Manager the most critical.
- Lack of capability of suppliers (more often the smaller suppliers) to resource projects over a long duration.
- Failure to specify requirements clearly, or to focus on the business needs, exposes the department to major scope change.
Examples of technology risk:
- The supplier withdraws support for a major component.
- The system specification was based on the functionality of a component that did not perform as expected (which can apply to hardware, packaged software or the features of the software language being used).
- Functionality can be developed as specified but the time or expertise needed was underestimated.
- Resource or expertise for particular technical components cannot be obtained easily.
- Obsolescence - the technology is out-of-date before it is fully implemented.
Examples of project risk:
- 'Risk of disclosing risk', the predilection of project team members to understate risks and difficulties in order to protect the status and morale of a project.
- Reporting that seems to suggest that "everything's fine", even when other project indicators do not support this position.
- Inexperienced project manager and poor communication within project team.
- Lack of practical business knowledge skills on the project team.
- Failing to execute a planned programme of regular communication (internally and externally) about the progress of the project.
Examples of political risk:
- Legislation is passed affecting the scope of the project without consideration of its impact on the current project plan, with the expectation that the original business case will be maintained.
- Public exposure of project problems diverts resources from dealing with the problems to reducing the fallout from the publicity.
- Short-term political imperatives may be in conflict with longer-term business and project objectives, and may trigger changes in project scope, with potential unacknowledged impacts on the project.