Managing Risk in Project Management Assignments
Risk is an unavoidable part of project delivery.
Projects involve uncertainty because they are temporary endeavours operating within changing commercial, technical, regulatory, financial and organisational environments. Even the most carefully developed project plan cannot eliminate that uncertainty.
The objective of effective risk management is therefore not to remove risk altogether.
It is to understand uncertainty, make informed decisions about exposure, and take action early enough to influence outcomes.
For project management assignments—particularly complex capital, infrastructure, construction and transformation projects—this requires a structured approach that goes well beyond maintaining a risk register.
Risk management starts before the project starts
Many project risks are embedded in the project before mobilisation begins.
The business case may contain optimistic assumptions. The scope may not be sufficiently defined. Responsibilities may be unclear. Procurement strategy may be inappropriate. Stakeholder expectations may be misaligned.
By the time these weaknesses become visible during execution, the cost of correcting them can be substantial.
Risk management should therefore begin during project definition and planning.
Early questions should include:
Is the project objective clearly defined?
Are the expected benefits realistic?
Is the scope sufficiently understood?
Are key assumptions documented?
Is the delivery strategy appropriate?
Are responsibilities and decision rights clear?
Is the programme achievable?
Are funding and resources realistic?
What external factors could materially affect delivery?
The earlier uncertainty is identified, the greater the opportunity to manage it.
1. Establish the risk context
A risk process is only useful if it reflects the environment in which the project operates.
The project team should consider risks across multiple categories rather than focusing exclusively on technical or construction risks.
Depending on the assignment, these may include:
Strategic risks.
Commercial and contractual risks.
Financial risks.
Programme and schedule risks.
Technical and design risks.
Procurement and supply-chain risks.
Regulatory and permitting risks.
Stakeholder and reputational risks.
Operational risks.
Resource and capability risks.
Health, safety and environmental risks.
Information and technology risks.
External economic or geopolitical factors.
The objective is to create a sufficiently broad risk universe without producing an unmanageable list of hypothetical threats.
2. Distinguish risks from issues
This distinction is fundamental.
A risk is an uncertain event or condition that may affect the project in the future.
An issue is a problem that has already occurred.
For example:
"The planning approval may be delayed" is a risk.
"Planning approval is now three months late" is an issue.
The management response is different.
Risks require proactive treatment and monitoring. Issues require resolution, escalation and recovery action.
Confusing the two can result in project teams maintaining long risk registers while failing to actively manage problems that are already affecting delivery.
3. Identify risks collaboratively
Risk identification should not be left to the project manager alone.
The best risk discussions bring together people with different perspectives, including:
Project leadership.
Client representatives.
Technical specialists.
Commercial and procurement teams.
Contractors and suppliers.
Operational stakeholders.
Finance representatives.
Regulatory specialists.
End users.
Workshops, interviews, lessons-learned reviews, schedule analysis and structured risk prompts can all be useful.
A simple but powerful question is:
"What could prevent us from achieving the project's objectives?"
Another is:
"What are we assuming will happen that may not happen?"
The second question is particularly valuable because project assumptions are often hidden sources of risk.
4. Assess risk based on exposure
Once risks have been identified, they need to be assessed consistently.
A basic assessment considers:
Probability × Impact = Risk Exposure
Impact should not necessarily be limited to cost.
A risk may affect:
Cost.
Time.
Scope.
Quality.
Safety.
Operations.
Reputation.
Benefits.
Regulatory compliance.
Some risks may have low probability but severe consequences. These should not automatically be dismissed because they score poorly on a conventional probability-impact matrix.
The assessment should also consider the quality of the underlying information.
There is an important difference between:
"The risk is low."
and:
"We have limited information, so we have low confidence in our assessment of the risk."
5. Identify the response—not just the rating
A risk register becomes valuable when it drives action.
Common response strategies include:
Avoid
Change the project approach so the risk no longer exists.
Reduce
Take action to reduce the probability or impact.
Transfer
Allocate appropriate responsibility to another party, often through contractual or insurance arrangements.
Accept
Recognise the exposure and consciously decide that no further treatment is justified.
Exploit or enhance
For opportunities, actively increase the probability or benefit of a favourable outcome.
Every significant risk should have an owner.
The project manager may coordinate the process, but the person best positioned to influence a risk should generally own its treatment.
6. Integrate risk with the project schedule and cost plan
Risk management should not operate as a separate administrative process.
Risks should be connected to the project controls that they can affect.
For example, a risk relating to late design information should be connected to the relevant schedule activities.
A procurement risk should be linked to the procurement programme and cash-flow implications.
A major construction uncertainty may need to be reflected in cost estimates or contingency.
This creates a more realistic picture of project performance.
It also allows the project team to ask better questions:
What happens to the completion date if this risk occurs?
What is the likely financial exposure?
Which activities are on the critical path?
What early action could reduce the potential impact?
7. Manage contingency deliberately
Contingency is often misunderstood.
It should not simply be treated as "extra money in the budget."
Contingency exists to accommodate identified and/or quantified uncertainty within the agreed project scope and risk framework.
Effective management requires clarity around:
What the contingency is intended to cover.
Who has authority to use it.
How its use is approved.
How much remains.
Which risks have materialised.
Whether the remaining contingency is still appropriate.
A project can appear to be within budget while quietly consuming contingency at a rate that makes the final forecast increasingly uncertain.
That is why forecast cost and remaining risk exposure are often more informative than comparing actual expenditure against the original budget alone.
8. Look for early warning indicators
Good risk management is forward-looking.
For every significant risk, the project team should consider whether there are measurable indicators that the risk is becoming more likely.
Examples include:
Procurement milestones slipping.
Increasing design queries.
Growing numbers of change requests.
Contractor productivity declining.
Supplier lead times increasing.
Approval cycles extending.
Increased staff turnover.
Repeated missed decisions.
Deteriorating cash-flow indicators.
Stakeholder engagement declining.
These indicators can provide an early warning before the risk becomes an issue.
The best project managers therefore monitor not only what has happened, but also what the emerging evidence suggests may happen next.
9. Manage risks across contracts and organisational boundaries
Major projects rarely sit within a single organisation.
Clients, designers, contractors, suppliers, authorities, operators and other stakeholders may each control different parts of the delivery environment.
This creates interface risks.
A risk may exist precisely because responsibility sits between two parties.
For example, a contractor may depend on information from the designer, while the designer depends on decisions from the client. Each party may manage its own activities effectively while the overall project remains exposed to the interface.
Risk management should therefore examine:
Who owns the risk?
Who can influence it?
Who is affected if it occurs?
What information needs to move between parties?
Clear allocation of responsibility is particularly important in complex contractual environments.
10. Escalate the right risks at the right time
Not every project risk belongs at executive level.
A mature risk framework establishes thresholds for escalation.
A risk might require escalation when it:
Exceeds the project's delegated authority.
Threatens a critical milestone.
Has significant financial exposure.
Affects regulatory compliance.
Creates material safety concerns.
Threatens strategic benefits.
Requires a decision outside the project team's authority.
Has implications across multiple projects or programmes.
Escalation should not be interpreted as failure.
Early escalation is often evidence of good project management.
The real failure is allowing a known risk to grow because the project team is reluctant to report bad news.
11. Keep the risk process alive
One of the most common weaknesses in project risk management is the "risk workshop and spreadsheet" approach.
A risk register is created at the beginning of the project, reviewed periodically and gradually becomes disconnected from reality.
Effective risk management is continuous.
Risks should be reviewed when:
The project enters a new phase.
Major design decisions are made.
Contracts are awarded.
Significant scope changes occur.
External conditions change.
Key milestones are approaching.
New information becomes available.
A major risk materialises.
The register should change as the project changes.
A practical risk management cycle
A robust project risk process can be summarised as:
Identify → Assess → Respond → Assign → Monitor → Escalate → Review
The cycle should operate continuously throughout the assignment.
The most important part is often not the initial identification of the risk, but the quality and timing of the response.
A risk identified six months before it materialises can often be managed relatively cheaply.
The same risk discovered when it has already become an issue may require significant additional cost, time and management attention.
From risk registers to risk intelligence
The ultimate objective of risk management is not to produce a comprehensive risk register.
It is to improve decision-making.
A strong project management team uses risk information to influence:
Project strategy.
Procurement decisions.
Contract structures.
Programme sequencing.
Resource allocation.
Contingency.
Change decisions.
Executive escalation.
Stakeholder management.
In other words, risk management should be embedded in how the project is managed—not treated as a separate compliance activity.
For organisations entrusting project management assignments to external advisers or delivery partners, this is particularly important. The project manager's role is not simply to report risks to the client. It is to create visibility, challenge assumptions, facilitate decisions and ensure that emerging threats are acted upon before they become expensive problems.
The strongest risk management cultures share three characteristics: they are proactive rather than reactive, evidence-based rather than subjective, and transparent rather than defensive.
Projects will always contain uncertainty.
The measure of effective project management is not whether unexpected events occur. It is whether the organisation is sufficiently prepared to recognise them early, understand their consequences and respond decisively.