Transport Department’s Framework: Software Before Mandate?
A state transport department with 4,000 staff and 14 regional offices has been told by the minister to “implement enterprise risk management” after two failures: a $120 million bridge project overran its budget by 40%, and a licensing IT system went live with incorrect fee calculations. Internal audit rated risk management a “significant deficiency.” The risk function is 1.5 full-time staff sitting under the chief financial officer. Three risk registers exist-corporate, project, and work health and safety-each with different scales and owners. There is no risk policy, no executive risk committee, and no common risk criteria. The executive team has never received a consolidated risk report. E-learning completion is 62%, and the only risk workshop held last year was a two-hour session for directors. The proposed remedy is to buy a $350,000 governance, risk and compliance system and adopt the risk framework used by a sister agency, which has a different legislative mandate and a centralized operating model. The minister wants visible progress within six months.
1. Advise the department on the sequencing of framework establishment in the first six months. What must precede software procurement and why?
Read the worked answer
ISO 31000 treats the framework as the arrangements that support risk management, not a software installation. In the first six months, sequence should be:
- Leadership and commitment (5.1): secure a written mandate from the minister/secretary and a public statement from the executive board. Without this, the risk function cannot enforce common criteria or challenge projects.
- Policy and accountabilities: issue a risk policy, define risk appetite/tolerance at least for project delivery, licensing, WHS, and financial exposure, and appoint executive risk owners. Establish an executive risk committee with a charter and decision rights.
- Integration (5.2): connect risk to existing decision points-project gate reviews, procurement, budget bids, WHS, IT change-rather than running a parallel process.
- Common design elements (5.3): agree one risk taxonomy and scales, map the three registers, define reporting lines, and pilot on a live project (e.g., the next bridge business case).
- Communication and training: target executives and project managers with role-based training; completion rates are not evidence of competence.
- Software later: a GRC tool should automate an agreed process. Buying it first would lock in inconsistent data and create false assurance.
Visible six-month progress could be a policy, committee, common register, executive dashboard, and one pilot decision that used risk information. Evaluation and improvement (5.5–5.6) should follow, not be deferred indefinitely.
2. Critique the plan to adopt the sister agency’s framework. What does “customized” require in ISO 31000 terms?
Read the worked answer
Adopting a sister agency’s framework may be efficient, but ISO 31000 requires the framework to be customized to the organization’s external and internal context: legislative mandate, governance, size, culture, maturity, objectives, and operating model. The sister agency’s centralized model may not fit a department with 14 regional offices and delegated project delivery. Copying can import incompatible risk criteria, committee structures, and reporting lines.
A customization process should:
- Compare the sister framework with the department’s mandate and decision rights; identify gaps and conflicts.
- Consult executives, regional directors, project managers, and WHS specialists on what decisions the framework must support.
- Tailor the risk policy, appetite statements, scales, taxonomy, and reporting templates.
- Define interfaces between corporate, project, and WHS registers without forcing a single register where legal or operational differences matter.
- Pilot in one region and one major project; revise based on use.
- Document why elements were adopted, changed, or rejected.
The test is not “does it look like ISO 31000?” but “does it change decisions and improve outcomes?” A copied framework that is not used is a compliance artifact. Customization also supports the inclusive principle: people who must apply the framework should help shape it.
3. How should the department evaluate whether the framework is working, and what improvement mechanisms should be built in?
Read the worked answer
Framework evaluation (5.5) should ask whether risk management is integrated and effective, not whether registers exist. Useful measures:
- Decision use: percentage of major project gate reviews, business cases, and procurement decisions that document risk analysis and treatment options.
- Accountability: executive risk owners actively reviewing their risks; treatment actions completed on time and within budget.
- Control effectiveness: incident and near-miss trends, audit findings, test results, and repeat failures-not training completion.
- Reporting quality: board/executive reports show risks at or above tolerance, treatment progress, and decisions requested; minutes show challenge.
- Culture and consultation: staff can describe how risks are escalated; regional staff were involved in design; no fear of reporting.
- Outcomes: project overruns, licensing errors, WHS incidents, and regulatory findings.
Build improvement mechanisms: an annual independent review or maturity assessment, a standing executive agenda item, post-incident reviews, and a process for updating the framework when mandates or structures change. Avoid measuring only the number of risks or e-learning completion. The department should also evaluate the framework after the first pilot and publish lessons, so improvement is continual rather than a one-off audit response.