SWOT has served its strategic purpose for decades: a snapshot of the project’s context at kick-off. The risks-and-opportunities matrix is the operational layer that complements it, connecting that view to the PM’s day-to-day tracking. The two coexist; neither replaces the other.
A recurring observation in industrial projects: many of the problems that appear in later phases — detail design, manufacturing, approvals, purchasing — share one origin, an insufficient risk analysis at the start. When a project enters industrialisation (TRL 7-8) and serious incidents emerge, tracing them back rarely leads to a single technical error. It usually leads to a chain of unquestioned assumptions, risks never identified, or risks identified but never monitored.
The PMI’s Project Management Body of Knowledge (PMBOK) devotes a whole chapter to risk management for one simple reason: the cost of acting late on a risk grows exponentially as the project advances. What costs a week of the technical office’s time at kick-off costs months, and an order of magnitude more budget, once the moulds have been cut.
Anticipating risks at the start of a project does not remove uncertainty. What it does is give the team the time to design mitigations while degrees of freedom still remain. The later a risk is identified, the fewer options are left to respond with.
This INNsight proposes a concrete way of doing that analysis at kick-off and keeping it alive through the whole project cycle. The proposal combines two tools that already exist: the classic SWOT for the strategic snapshot, and a simplified risks-and-opportunities matrix for operational tracking. Each serves a different purpose. Together they cover the full cycle.
SWOT analysis — Strengths, Weaknesses, Opportunities, Threats — is a well-established tool with decades of validation behind it. Its origin goes back to research led by Albert Humphrey at the Stanford Research Institute in the 1960s. Its original purpose still holds today: to offer a snapshot of the project’s context at a given moment, crossing two axes of analysis.
The visual convention of SWOT organises the four quadrants along two axes:
“What conditions does this project have right now?” That is a strategic question, not an operational one. This is why SWOT fits perfectly at kick-off, in annual planning or in portfolio reviews. What it does not solve on its own is continuous risk tracking during execution. That is where the next layer comes in.
The strategic snapshot of a SWOT is valuable at the moment it is taken. The project, however, is a living system: weaknesses get mitigated or get worse; threats materialise or get defused; opportunities are captured or lost over time. The snapshot remains true as initial context, but it stops reflecting the current state as the weeks pass.
What the project team needs day to day is a different tool: an operational layer that keeps the conversation about risks and opportunities alive at every milestone, in every weekly review, in every technical decision. This layer does not replace SWOT; it extends it into the operational plane.
SWOT answers “where are we?”. The risk register answers “how is what we have to watch evolving?”.
The transition from one tool to the other is the interesting part. Once the SWOT is done, the entries in the negative quadrants (weaknesses and threats) move into the risk register as risks to mitigate. The entries in the positive quadrants (strengths and opportunities) move across as opportunities to capitalise on. The internal/external distinction stops being structural in day-to-day work and becomes just another attribute of each entry.
With that simplification, project management can hold an operational conversation with the team without having to remember in every meeting which quadrant each entry belongs to. The daily question stops being “is this a weakness or a threat?” and becomes “is this risk still open or already mitigated?”.
The risk register proposed here is a deliberately simple table. Complexity adds no value when what you are after is continued use by the team. The minimum necessary columns are seven:
“Our usual moulder has no experience with material X, which the new project requires.” From day one this statement belongs in the risk register as a supply chain risk · high probability (4) · high impact (4) · severity 16. A possible mitigation: identify three alternative suppliers with experience in X, validate samples, keep the usual supplier as a second option. Owner: head of purchasing. Status: being mitigated. This entry gets reviewed every week until it is closed.
A working version of the risk register, pre-loaded with four typical industrial project entries. You can edit, add and delete rows and export the result.
| ID | Category | Description | P (1-5) | I (1-5) | Severity | Mitigation | Owner | Status |
|---|
This table, living in a shared spreadsheet, in Notion, ClickUp, Asana or any project tool, becomes the living document the team consults. The most important improvement over SWOT is that every entry has an owner and a status. The conversation stops being theoretical and becomes operational.
One of the commonest traps when building a risk register for the first time is producing a flat, unstructured list. The consequence: certain families of risk are over-represented — typically the technical ones, because they are the most visible to the engineering team — and others stay invisible. To avoid blind spots, it is worth categorising risks into six clearly distinct dimensions.
Everything to do with the technical viability of the product: meeting specifications, validating prototypes, reaching the target TRL within budget.
Validating the value proposition, expected customer behaviour, competitive positioning, time to market.
Material availability and lead times, supplier capabilities, logistics, critical dependencies in the value chain.
CE marking, sector regulation (medical, rail, machinery, REACH, RoHS), approval requirements that come before you can sell.
Budget overruns, dependence on grants, currency swings, payment terms, working capital.
Team capacity, dependence on key people, concentrated knowledge, overlap with other projects, quality of documentation.
Not every dimension carries the same weight in every project. A medical device project weights the regulatory dimension very heavily. A furniture project weights supply chain more. An early-stage project weights the commercial one. The categorisation does not set the weight; what it does is make sure no family stays invisible at the start.
These three questions reflect where your team stands on risk management. The result is not a verdict: it is a starting point for identifying which layer to add next.
—
The approach in this INNsight combines operational experience with established frameworks. For anybody wanting to go deeper into the theory or into specific applications, these are the main references.
International guidance on principles and guidelines for risk management, applicable to any organisation. It defines a common vocabulary and sets out the cycle identify → analyse → evaluate → treat → monitor.
The Project Management Institute’s body of knowledge devotes its “Project Risk Management” area to concrete processes for identification, qualitative and quantitative analysis, response planning and control.
Failure Mode and Effects Analysis. A tool that complements the risk register, aimed at the product and the manufacturing process. Especially relevant in automotive, aerospace and medical devices.
Corporate planning research in the 1960s that gave rise to the SOFT model (Satisfactory, Opportunities, Faults, Threats), later reformulated as SWOT. The visual convention of four quadrants settled in the 1980s.
The concept of “leap-of-faith assumptions” as a special category of risk: the critical hypotheses that, if they fail, invalidate the whole project. Validating those hypotheses early is the heart of the lean approach.
A rigorous treatment of uncertainty in industrial new product development. It argues that reducing the variance of risks is worth more than minimising average risk. Essential reading for anybody running a project portfolio.