Why Context Is Everything in Risk Management
Here is a question that separates competent project managers from exceptional ones: Do you understand the battlefield before you start fighting?
Every project exists within a web of organisational politics, industry regulations, stakeholder expectations, and environmental forces. A risk that is perfectly tolerable in one context — say, a 10% schedule overrun on a low-priority internal upgrade — can be catastrophic in another, such as a defence procurement milestone tied to parliamentary funding cycles. The same event, two radically different consequences. That difference is context.
ISO 31000:2018, the international standard for risk management, makes this explicit: establishing context is not an optional preliminary step — it is the first formal activity in the risk management process. Without it, risk identification becomes guesswork, risk analysis becomes meaningless arithmetic, and risk response becomes reactive firefighting.
For engineering and defence projects, where technical complexity intersects with regulatory environments, multi-layered contracting structures, and public accountability, establishing context is not just good practice — it is survival.
What Does "Establishing Context" Actually Mean?
Establishing context means systematically building a 360-degree understanding of your project's operating environment before you attempt to identify individual risks. It operates across two dimensions: the external environment and the internal environment.
The External Environment: PESTEL Analysis
PESTEL analysis is a structured framework for scanning the macro-environment in which your project operates. Each letter represents a category of external force that can generate risks or opportunities.
| Factor | Description | Example Risk for a Defence Manufacturing Project |
|---|---|---|
| Political | Government stability, policy shifts, cross-cutting decisions | Change of government cancels procurement programme |
| Economic | Inflation, exchange rates, labour market conditions | Steel price volatility blows out material costs by 18% |
| Socio-cultural | Demographics, public attitudes, workforce expectations | Community opposition to factory expansion delays approvals |
| Technological | Obsolescence, innovation pace, digital transformation | Legacy CNC systems cannot interface with new CAD/CAM |
| Environmental | Climate impacts, sustainability mandates, disposal regulations | New emissions standards require production line retrofit |
| Legal/Regulatory | Compliance requirements, contract law, international trade rules | ITAR export restrictions block component supply from US vendor |
PESTEL analysis follows three steps: first, identify the relevance of each factor to your project context; second, categorise the specific information gathered under each factor; and third, analyse the data to draw actionable conclusions about risk exposures and opportunities.
The Internal Environment: Understanding the Rules of the Game
The PMBOK® Guide calls them Organisational Process Assets, but what they really represent is the accumulated DNA of how your organisation does business. These assets fall into two categories: Formal assets (policies and standards) include risk registers, risk policies and standards, WBS templates, project schedules, standardised forms, health and safety policies, accounting controls, naming conventions, data retention requirements, and communication protocols. Informal assets (cultural norms) include team members' willingness to take ownership of risks, the level of prescriptive control management expects, how openly bad news is communicated upward, and the organisation's genuine (as opposed to stated) appetite for risk.
Risk Appetite and Tolerance
Understanding context also requires mapping the risk appetite of your organisation and your client. Risk appetite is not a single number — it varies by risk type. A council's infrastructure division may be highly comfortable with construction risks but have near-zero tolerance for public safety risks. A defence contractor may accept significant technical risk on a prototype but refuse to tolerate schedule risk on a production contract.
| Dimension | Risk-Seeking | Risk-Neutral | Risk-Averse |
|---|---|---|---|
| Technical/Innovation | New unproven alloys in prototype | Proven materials, novel assembly | Only certified, field-tested systems |
| Schedule | Aggressive fast-track delivery | Standard phased schedule | Conservative buffer on every milestone |
| Financial | Accept cost overrun for market share | Strict budget with contingency | Fixed-price, liquidated damages |
| Reputation/Brand | Willing to accept public scrutiny | Managed media strategy | Zero public controversy tolerance |
How to Establish Context in Practice
Step 1: Clarify Organisational Objectives and Mission
Before any risk identification begins, confirm alignment between the project and the organisation's strategic direction. What are the strategic objectives? What is the mission or vision that this project serves? A misaligned project carries a fundamental existential risk that no amount of schedule buffering can fix.
Step 2: Research the Project History
Where did this project come from? What were the assumptions in the business case? Were similar projects attempted before, and what happened? Organisational process assets from past projects — including lessons learned reports and project closure documents — are goldmines of risk intelligence. Some organisations maintain Risk Knowledge Banks or Risk Libraries cataloguing past risks that materialised or were successfully avoided.
Step 3: Identify Key Stakeholders and Their Risk Appetites
Map not just who the stakeholders are, but what risks they will and will not tolerate. Clients may openly state they want innovation (implying risk-seeking behaviour on technology) while simultaneously demanding fixed-price contracts (revealing risk-averse financial behaviour). The gap between stated and implied risk appetite is itself a significant risk.
Step 4: Conduct PESTEL and SWOT Analyses
Use PESTEL for external scanning and SWOT for summarising the complete picture:
Step 5: Define Risk Criteria and Categorisation
Establish the criteria against which risks will be evaluated — probability scales, impact scales, and the probability-and-impact matrix that will govern prioritisation. These must be agreed upon during context setting, not invented mid-project when emotions are running high.
The Pitfalls: Where Context Setting Goes Wrong
Skipping it entirely. Under schedule pressure, teams jump straight to brainstorming risks without understanding the organisational rules, stakeholder tolerances, or external environment. The result is a risk register full of technical risks but blind to political, legal, or cultural risks. Treating it as a tick-box exercise. Filling in a PESTEL template with generic one-liners does not constitute environmental scanning. Each factor must be analysed for its specific implications on this specific project. Ignoring organisational culture. In some cultures, team members will not volunteer information they believe management does not want to hear. If your organisation punishes the messenger, your risk register will be dangerously incomplete. The de-identified multi-hazard case case is a stark reminder. Assuming your client's risk appetite matches yours. Misalignment between the project team's risk tolerance and the client's expectations is one of the most common — and most damaging — sources of project conflict. Failing to update context as the project evolves. The external environment changes. Governments change. Exchange rates move. Regulations are introduced. Context is not a one-time activity — it must be revisited at key milestones throughout the project lifecycle.
Key Takeaways
- Establishing context is the first formal step in the ISO 31000 risk management process and a prerequisite for meaningful risk identification.
- The external environment is analysed through PESTEL (Political, Economic, Socio-cultural, Technological, Environmental, Legal) to identify macro-level forces that generate project risks and opportunities.
- The internal environment is understood through Organisational Process Assets — both formal policies and informal cultural norms — which define the "rules of the game" for risk management.
- Risk appetite varies by type within the same organisation and between project stakeholders. Mapping these tolerances early prevents costly misalignment later.
- SWOT analysis synthesises internal and external findings into an actionable summary that feeds directly into risk identification.
- Lessons learned from previous projects and Risk Knowledge Banks are among the most underutilised — yet most valuable — inputs to context setting.
- Organisational culture can either enable or suppress honest risk assessment. A culture that punishes bad news guarantees an incomplete risk picture.