Recommended resources
The freely available resources this lesson will direct you to.
Hello again. In the previous lesson, you set out how a pilot would be judged: staff review time, crossing recall, false alerts, latency, and agreed conditions for collecting evidence. Those criteria tell you whether the pilot succeeded. A technical risk register addresses a different question: what might prevent you from reaching a trustworthy result, and what will you do before it is too late?
This lesson will help you create a register that a small engineering team can actually maintain. You will describe uncertain events precisely, rate their likelihood and impact, assign one accountable owner, plan mitigation, and define observable triggers for action.
Describe a risk as an uncertain event with a consequence
“Camera reliability” is a topic, not a risk. “The camera disconnected at 10:15” is an issue: it has happened. A useful risk statement connects a possible event, its cause, and its effect:
There is a risk that the ingestion service will not resume counting after a brief camera interruption, because reconnection behavior has not been tested on the site stream. If it occurs, scheduled camera-hours may contain unobserved crossings, putting the recall measurement and pilot result at risk.
This wording tells the team where to investigate and why it matters. It also avoids confusing a symptom—“counts are low”—with a possible cause. Risks can arise from the system, the test plan, or an external dependency. For the doorway pilot, a quiet doorway might prevent you from collecting the agreed minimum of 200 labelled crossings even if the detector works perfectly.
Watch Mike Clayton’s What to Put in Your Risk Register (Risk Log) from Online PM Courses. He describes more fields than a small pilot needs; focus on why each field earns its place in a maintained register.
What to Put in Your Risk Register (Risk Log)
Mike Clayton's overview provides a practical way to build a risk log without turning it into paperwork.
Watch right-size the log for the case for a short, maintained register; identify risks for stable IDs and clear descriptions; and assess risks for likelihood, impact, and timing. Finish with plan ownership and track progress. Notice that identifying a risk is only the beginning: someone must act and return to check it.
Give each risk a stable ID, such as R-01, so meeting notes, test results, and decisions can refer to the same item. Do not silently delete an inconvenient entry. If the event occurs, mark it as an issue being handled; if the exposure genuinely ends, record why it was closed.
Rate risks to direct attention, not to predict the future
A simple scale is enough for a first pilot. Agree on the meaning of the scale before scoring individual risks. For example, rate likelihood over the period from pre-pilot testing through the end of the ten-shift pilot:
| Rating | Likelihood | Impact on the agreed pilot |
|---|---|---|
| 1 | Unlikely on current evidence | Small, readily recoverable disruption |
| 2 | Conceivable | Local rework or a limited interruption |
| 3 | Plausible | A supporting criterion or valid measurement may be threatened |
| 4 | Likely | Primary acceptance or the pilot schedule may fail |
| 5 | Strong evidence it will recur or occur | Pilot must stop, or an unacceptable constraint may be violated |
These are judgment categories, not measured probabilities. Record why you chose a rating: “untested on the site stream” is more useful than an unexplained “4.” Score the risk under controls that already exist. Do not lower its current rating because you intend to implement a mitigation next week.
For sorting, you can multiply likelihood by impact. A risk rated 4 and 4 has a priority score of . But the product is not an expected loss and should not make the decision for you. A privacy or safety constraint with impact 5 may require immediate attention even if its likelihood is rated 2 and its score is only 10. How soon the event could occur, and how long mitigation takes, also matter.
The following template makes the likelihood–impact comparison visible. Its columns for owner, mitigation, trigger event, response action, and status are useful prompts; you need not copy every column into your working document.
Turn warnings into owned actions
Mitigation is work you do before a risk materialises to reduce its likelihood or consequence. A trigger indicator is an observable warning, with a stated condition for acting on it. A response says what the owner does when that condition is met. “Monitor camera stability” leaves all three unspecified. A stronger entry says:
Before the first pilot shift, run a one-hour site-stream test that includes brief interruptions and inspect ingestion logs. If automatic reconnection fails once, or an input gap exceeds two seconds, the device lead investigates and retests before approving the pilot start.
The thresholds here are illustrative; set them from your stream behavior and the agreed pilot rules. The important distinction is timing. A warning during a pre-pilot test leaves room to fix the system. Discovering after ten shifts that counts were missing is a failure of both the system and its monitoring.
In the Department of Energy report The Owner’s Role in Project Risk Management, the “PROJECT RISK REGISTER” section describes a register as a way to track actions and leading indicators, not merely list worries.
[PDF] The Owner's Role in Project Risk Management - Department of Energy
Read the report's compact account of how a risk register connects ownership, indicators, and contingent actions. Its projects are much larger than an edge-AI pilot, but that connection is directly useful.
In “PROJECT RISK REGISTER,” around printed pp. 66–67, start at the paragraph beginning “It may contain the following data elements for every risk.” Read fields and indicators, ending just before the paragraph beginning “The primary purpose of the risk register.” Focus on the distinction between a risk-reduction plan already in effect and an action taken when an indicator triggers.
A good indicator is available early enough to change the outcome and has a source the owner can check. Examples include a failed reconnection in a soak-test log, too few reference crossings in a pre-pilot traffic survey, or an unapproved media-egress path found in configuration review. “The pilot failed recall” is not an early-warning indicator; it is the outcome the register was supposed to help protect.
Assign one accountable owner per risk, even when several people perform the work. The owner ensures that the mitigation happens, checks the indicator, updates the entry, and escalates when needed. An eager but inexperienced engineer can run a test and collect logs; accountability for accepting a serious media-handling risk should remain with someone empowered to pause the pilot and obtain appropriate review.
A working register for the doorway pilot
Below is a starting register for the illustrative pilot from the previous lesson. Ratings and thresholds are examples to replace with evidence from the actual device, site, and agreement. “Open” means mitigation or observation is still required—not that the team has done nothing.
| ID and uncertain event | Current likelihood / impact | Accountable owner | Mitigation before pilot | Indicator, trigger, and response |
|---|---|---|---|---|
| R-01 — Stream recovery: The ingestion service may fail to resume after a brief camera interruption, leaving crossings unobserved. | 4 / 4; reconnection is not yet verified on the site stream | Device lead | Test interruptions on the selected device and stream; add and verify automatic reconnection and gap logging. Complete before pilot start. | Source: ingestion and camera-operation logs. Trigger: one failed automatic reconnect or an input gap over two seconds in the one-hour pre-pilot disturbance test. Response: block pilot start, diagnose, fix, and repeat the test. Record any in-pilot gap as scheduled-time evidence under the agreed interruption rule. |
| R-02 — Insufficient reference events: The agreed ten shifts may contain fewer than 200 independently labelled crossings, making recall acceptance inconclusive. | 3 / 4; site traffic has not been measured | Evaluation lead | Survey representative four-hour periods and reserve annotation capacity before fixing the observation schedule. | Source: pre-pilot counts and annotation plan. Trigger: surveyed shifts average fewer than 20 valid crossings each, leaving no margin for the 200-event minimum. Response: agree additional representative shifts or an inconclusive-result rule with the customer before testing; do not lower the minimum afterward. |
| R-03 — Unapproved media egress: A configuration or component may send raw media beyond the approved device boundary. | 2 / 5; the path is intended to be local but has not been fully checked | CTO | Review data-flow paths, configuration, and destinations; test the approved configuration and retain evidence of the check. Complete before connecting live media. | Source: configuration review, application logs, and network-destination checks. Trigger: an unapproved upload path is enabled or unexplained outbound traffic appears in preflight. Response: block deployment and investigate. If a suspected violation appears during the pilot, pause the affected flow, preserve evidence, and follow the agreed notification process. Traffic alone does not prove that raw video was transmitted. |
| R-04 — Sustained-load latency: Device heat or resource contention may push end-to-end alert latency above the agreed limit during long shifts. | 3 / 4; only short tests have run | Device lead | Run a representative multi-hour load test on the selected device; record alert timestamps, device health, and operating configuration. Verify any correction under the same test conditions. | Source: matched crossing and alert timestamps, plus device telemetry. Trigger: the pre-pilot test’s 95th-percentile matched-alert latency exceeds an illustrative 2.5 seconds, leaving little margin below the 3-second acceptance limit. Response: investigate the bottleneck and retest before starting. Do not quietly reduce streams or change test conditions to claim a pass. |
This is a register, not four independent technical notes. Keep the same fields for each entry and add a short status / next review field in the working version. For example, R-01 might read: “Open; disturbance test scheduled before site installation; review at the pilot-start decision.” R-02 should be reviewed as soon as traffic-survey evidence arrives. R-03 needs review before live media is connected, not at the next convenient weekly meeting.
The register also exposes differing kinds of action. R-01 and R-04 call for engineering tests. R-02 calls for measurement planning and customer agreement. R-03 calls for a deployment block and potentially an immediate pause. A single priority score would obscure those differences.
When a trigger fires, update the record with the observation, decision, owner, and next check. If a risk becomes an actual issue, manage the incident or defect and retain the risk entry’s history. Re-rate a risk after a mitigation is verified, not merely assigned. Closure needs an explanation such as “reconnection passed the agreed disturbance test and the pilot observation period ended,” rather than “fix merged.”
For a small team, a weekly review of the highest risks may suffice during development; review sooner at site tests, configuration changes, and pilot-start decisions. Ask: Has the evidence changed? Is the promised mitigation complete? Has an indicator crossed its trigger? Does anyone need to pause or escalate? That routine makes the register a decision tool rather than a spreadsheet assembled for a meeting.
Key takeaways
A useful technical risk entry names an uncertain event and consequence, gives a justified likelihood and impact, assigns one accountable owner, specifies mitigation before failure, and connects an observable trigger to a response. Scores help you sort work, but severe constraints and approaching deadlines can override the numerical order. Keep the register current as tests produce evidence.
The next lesson uses that evidence to define gates: what must be demonstrated before a prototype becomes a pilot, and what additional proof is needed before a pilot becomes a production service.