Risk Management

Risk Management is a flat-list risk register that lives inside each project. Use it to track engineering, manufacturing, and operational risks against a deliverable in one structured place, instead of scattering them across Slack threads and meeting notes.

---

Concepts

The deliberate choice: flat list, no hierarchy. No parent-child risks, no risk categories. Hardware projects accumulate twenty to fifty risks at most; a flat register is faster than a tree and easier to keep current.

---

Before you start

• Decide who owns the register. Usually the engineering lead, sometimes a dedicated NPI manager. The owner reviews the list weekly.
• Define your severity and likelihood scale up front. S3Suite uses fixed labels (Low / Medium / High / Critical for severity, and Rare → Almost Certain for likelihood), but your team should agree on what each one means for your product. Write the definitions in the project's Knowledge Base.

---

Quick start (5 minutes)

1. Open the register

1. Open your project
2. In the sidebar, go to Engineering → Risk Management
3. You land on the flat list of risks. New project = empty list.

2. Add your first risk

1. Click New Risk
2. Fill in:

- Title - short and specific - Description - what could go wrong, what is the impact - Severity - pick one - Likelihood - pick one - Owner - pick from the project's team - Mitigation - what you are doing about it (or "TBD" if not yet planned)

1. Click Create

The risk appears at the top of the list with a coloured severity badge and the owner's name.

3. Update status directly from the row

1. Find a risk in the list
2. Click the Status dropdown directly in the row (no need to open the full detail)
3. Pick the new status (Open / Mitigating / Closed)

The status change is saved immediately and the row's status badge updates.

---

Workflow: weekly risk review

Most teams find a weekly 15-minute risk review pays for itself in avoided fire drills.

1. Open Engineering → Risk Management
2. Set the Status filter to Open + Mitigating (hide closed)
3. Sort by Severity (descending)
4. For each top-of-list risk:

- Has the likelihood changed? Update. - Is the mitigation on track? If not, change owner or note new action. - Has the risk been eliminated? Move to Closed with a note in mitigation.

1. Add any new risks surfaced during the meeting

---

Workflow: linking a risk to a design change

When a design change introduces a risk (or addresses one), link the two so the audit trail is intact.

1. Open the risk detail page (click the row in the list)
2. In the Linked items panel, click Add link
3. Pick:

- Commit - a Revision Control commit (see Hardware Revision Control) - Device - a specific device serial - Ticket - a customer support ticket - RMA - a return record

1. Save

The linked item appears on the risk detail. From the linked side (the commit, for example), the risk also surfaces as a back-reference.

---

Workflow: closing a risk

1. Open the risk detail page
2. Move status to Closed
3. Add a closing note in mitigation. What eliminated the risk? E.g. "Switched to multi-sourced MCU XYZ. EOL no longer applies."
4. Save

Closed risks are filtered out of the default view but remain in the database forever. They show up in audit reports and search.

Tip: Do not delete closed risks. The history of "we tracked this risk, we closed it on date X for reason Y" is what makes the register defensible in an audit.

---

Reference

Severity definitions (default starting point)

These are the labels S3Suite ships with. Your team is free to redefine them, but document the definition in the project knowledge base.

• Low - inconvenience only, no production impact.
• Medium - manageable production delay or rework.
• High - significant production delay, customer impact, or compliance issue.
• Critical - product cannot ship, customer safety concern, or regulatory blocker.

Likelihood definitions (default starting point)

• Rare - has not happened, no known path.
• Unlikely - theoretically possible but no evidence.
• Possible - has happened in similar projects.
• Likely - has happened in this project before, or in a recent project.
• Almost Certain - happening now or imminent.

Filters available in the list

• Status - Open / Mitigating / Closed / All
• Severity - any combination
• Owner - filter to your own risks
• Search - free text against title and description

Common pitfalls

• "We tracked the same risk in three different places." Use linked items to consolidate. One risk, multiple links to commits / tickets / devices.
• "The register is full of stale Open risks." Schedule a weekly review. Stale Open risks are noise that hides real risks.
• "Severity and likelihood disagree with the mitigation plan." A Critical + Almost Certain risk needs an active mitigation plan, not "TBD". If you cannot mitigate it, escalate.

---

Related docs

• Hardware Revision Control -link risks to specific commits that introduced or addressed them
• RMA and Troubleshooting -field failures often surface new risks
• Knowledge Base and Diary -where to write the team's risk-scale definitions