Eleanor Whitfield manages a seven-person operations team inside a regional logistics company. Two summers ago she watched a warehouse-software rollout slip eleven weeks past its deadline, and the post-mortem stung. The root cause was not bad work. It was a dependency nobody had written down: the new system needed an integration with the finance team's billing platform, and the finance team had a hard freeze on changes during their fiscal close. Eleanor had known about the freeze. She had simply never connected it to her timeline. "We did not get surprised by something unknowable," she told her director afterward. "We got surprised by something we already knew and never said out loud." Since then she starts every project by writing down what could go wrong, and she uses an AI assistant to make sure she is not missing the obvious.

What This Lesson Covers

Risk identification is the practice of naming what could go wrong on a project before it does, so you can decide what to do about it in advance. This lesson shows you how to use AI to brainstorm a thorough first-cut risk list, organize those risks into a risk register, score them so you know which ones deserve your attention, and plan mitigations and owners. Throughout, the AI is your fast brainstorming partner. The judgment about which risks are real, which to actively manage, and which to simply accept stays with you.

You will learn the categories risks fall into, the standard risk register format, how to score likelihood and impact, how to decide which risks to mitigate versus monitor versus accept, and how to keep the register alive instead of letting it die in a folder. We will build one concrete register end to end with real numbers so the method is not abstract.

The goal of risk work is not to eliminate every risk. It is to make sure no risk that mattered went unnamed, and that the ones that mattered had a plan.

Why Risk Work Gets Skipped

Most managers do not skip risk planning because they think it is useless. They skip it because it feels like extra paperwork when they are eager to start the real work. The cost is invisible right up until the moment it is not. A dependency you never wrote down blocks your timeline. A key person leaves and there is no backup. A vendor misses a date you assumed was firm. None of these are exotic. They are ordinary, and ordinary risks are exactly the ones a structured pass would have caught.

AI helps here for a specific reason: the hardest part of risk work is the blank page. Staring at a project and asking "what could go wrong?" with no prompt, most people list three or four obvious risks and stop. An AI assistant, given a clear description of your project, will reliably produce fifteen to twenty candidate risks across categories you might not have considered. Your job shifts from generating the list to editing it, which is far easier and far more thorough.

The Categories Risks Fall Into

Before you brainstorm, it helps to have a mental checklist of categories. When you ask the AI for risks, naming the categories forces broader coverage. Eight cover most team-level projects, and the first six carry the weight on a typical internal project:

• Dependency risks. Something your project needs from another team, system, or external party. The billing-platform integration that sank Eleanor's first rollout was a dependency risk. These are the most commonly missed because they live outside your own team's control.
• Timeline risks. Estimation errors, scope creep, hard deadlines with no buffer, and known absences like holidays or planned leave that compress the working calendar.
• Resourcing risks. A single person being the only one who knows something, a teammate at full capacity with no slack, a planned hire that has not landed, or a contractor whose start date keeps slipping.
• Stakeholder risks. Misaligned expectations, a sponsor who changes their mind, sign-offs that take longer than assumed, or a decision-maker who is hard to reach when you need them.
• Technical risks. Integration complexity, an unproven tool, a skill gap on the team, or performance and scale requirements that have not been tested.
• Political and institutional risks. Budget cuts mid-project, a reorganization that moves your priorities, a competing initiative that outranks yours, or a history at your company of similar projects being quietly shelved. This is the category AI knows the least about, and we will return to it.
• Market risks. Shifts outside your organization entirely: customer demand moving away from what you are building, a competitor changing the landscape mid-project, or a regulatory change that alters what you are allowed to ship. These feel remote on a three-month internal project and become decisive on anything customer-facing or regulated.
• Vendor and external risks. A partner missing a date, a third-party service failing, support that does not respond when you need it. Related to dependency risks but worth naming separately, because the lever you have over a vendor is contractual rather than personal, and that changes the mitigation entirely.

Not every category applies to every project, and forcing risks into all eight produces filler. But running the list is cheap, and the value of a checklist is precisely that it makes you consider the category you would otherwise have skipped.

The Risk Register Format

A risk register is simply a structured list of your risks with enough detail to act on. The standard columns are:

• Risk. A specific, concrete description of what could go wrong. "Designer gets pulled to another project in May" is useful. "Resource problems" is not.
• Likelihood. How probable the risk is. You can use High, Medium, Low, or a number. We will use a 1 to 5 scale below because numbers let you rank.
• Impact. How bad it would be if the risk happened, on the same 1 to 5 scale.
• Risk score. Likelihood times impact. This single number is what lets you sort the register so the risks that matter most rise to the top. A risk scored 4 by 5 lands at 20; a risk scored 2 by 2 lands at 4. The first demands a plan. The second probably does not.
• Mitigation. What you will do to lower the likelihood, lower the impact, or both.
• Owner. The one named person responsible for watching this risk. Not "the team." A person.
• Status. Whether you are actively mitigating it, just monitoring it, or have consciously accepted it.

The format is the easy part. The two things that make a register actually work are honest scoring and a real owner for every risk you choose to manage.

Using AI to Generate the First Cut

Eleanor's team is starting a three-month project to migrate the warehouse inventory system to a new vendor platform. She has one engineer, one analyst, and herself part-time. The go-live is fixed at September 30 because the old vendor contract ends that day. Before opening any AI tool, she spends five minutes writing down what she already knows is shaky: the engineer has never used the new platform, and the data export from the old system has always been flaky.

Then she brings in the AI with a prompt that includes real context and names the categories she wants covered:

We are migrating our warehouse inventory system to a new vendor platform over three months. Team: one engineer (new to this platform), one data analyst, and me part-time as manager. Hard go-live of September 30 because the old vendor contract ends that day. Known concerns: the engineer is learning the platform, and the legacy data export has been unreliable. Identify the significant risks across these categories: dependency, timeline, resourcing, stakeholder, technical, and political or institutional. For each risk, estimate likelihood and impact on a 1 to 5 scale, compute a risk score, and suggest a mitigation. Return it as a table sorted by risk score.

The AI returns roughly eighteen risks. Most are useful. A few are generic filler she will cut. And two important ones are missing, which is exactly what she expected.

What AI Reliably Misses

AI is excellent at the risks that are common to projects of a given shape. It is blind to the risks that live in your company's specific history and politics, because that information was never in its training data and is not in your prompt unless you put it there. For Eleanor's migration, the AI did not surface two risks she knew mattered:

• A company-history risk. The last vendor migration at her company, two years earlier, was paused for a quarter when leadership got nervous about cost overruns. That precedent makes a mid-project pause a real possibility here. No AI could know this.
• A political risk. The finance director has publicly favored a different vendor and may lobby to revisit the decision. That is a stakeholder and political risk rolled together, rooted in personalities the AI has never met.

This is the core division of labor. The AI gives you breadth across the predictable categories in seconds. You supply the institutional memory and the read on the people. A register built only by AI looks complete but quietly omits the risks most specific to your situation. A register built only by you is thorough on politics but tends to miss the ordinary dependency and technical risks because you were not staring at a checklist. Together they cover far more than either alone.

Scoring Likelihood and Impact

Scoring is where your judgment does the most work. The AI's first-cut scores are a reasonable starting point, but they are generic guesses. You adjust them using what you actually know.

Use a consistent 1 to 5 scale for both dimensions. For likelihood, anchor the numbers so you are not just guessing differently each time: 1 is rare, 2 is unlikely, 3 is even odds, 4 is likely, and 5 is nearly certain. For impact, anchor to consequences: 1 is a minor annoyance, 3 is a real setback you would recover from, and 5 is a project-threatening event. A common mistake is to score everything a 3 or 4 because every risk feels somewhat likely and somewhat bad. Force yourself to use the full range. If nothing is a 1 and nothing is a 5, your scores are not discriminating between risks, which defeats the purpose.

One discipline matters more than precision: score likelihood from evidence, not dread. "We have hit data-export problems on the last three projects" justifies a high likelihood. "It would be terrible if the data export broke" justifies a high impact, but says nothing about likelihood. Keep the two separate or you will inflate likelihood for any risk that scares you.

If you prefer to think in percentages rather than a 1 to 5 scale, the same discipline works with three bands. High likelihood, roughly 70 to 100 percent, is where the thing has happened before on projects like this and is likely to happen again. Medium, roughly 30 to 70 percent, is genuinely possible without being expected. Low, under 30 percent, is unlikely but would still be bad. Whichever notation you use, the pattern across managers is consistent: we underestimate likelihood. The correction is historical data. Look at what actually went wrong on your last three projects, and score the next one against that record rather than against your hopes for it. Eleanor's data-export risk earned a 4 because the export had misbehaved every time anyone touched it, not because it worried her.

A Worked Example: The Migration Risk Register

Here is Eleanor's register after she edited the AI's first cut, adjusted the scores using her knowledge, and added the two risks the AI missed. Likelihood and impact are each 1 to 5; the score is their product.

Risk	Category	Likelihood	Impact	Score	Mitigation	Owner
Legacy data export fails or corrupts records	Technical	4	5	20	Run a full test export in Week 1; build a validation script that flags mismatches before cutover.	Analyst
Engineer's learning curve slows delivery	Resourcing	4	4	16	Budget two weeks of ramp-up; buy vendor support hours; pair on the first integration.	Eleanor
Leadership pauses project over cost (company history)	Political	3	5	15	Pre-brief the sponsor with a cost ceiling and a clear contract-deadline rationale before kickoff.	Eleanor
Hard September 30 deadline with no buffer	Timeline	3	4	12	Protect a two-week buffer by descoping non-essential reports to a later phase.	Eleanor
Finance director reopens the vendor decision	Stakeholder	2	5	10	Get the decision confirmed in writing now; give finance a voice in acceptance criteria.	Eleanor
New platform integration more complex than scoped	Technical	3	3	9	Two-day integration spike in Week 1 to surface unknowns early.	Engineer
Analyst pulled to support quarter-end reporting	Resourcing	3	3	9	Confirm analyst availability with their manager; map quarter-end dates against the plan.	Eleanor
Vendor onboarding support slow to respond	Dependency	2	3	6	Name a dedicated vendor contact in the contract; set response-time expectations.	Analyst
User training delayed, slow adoption at go-live	Stakeholder	2	2	4	Schedule training in Week 10; record sessions for later reference.	Eleanor

Sorted by score, the picture is immediately clear. The data-export risk at 20 and the engineer ramp-up at 16 are the two that could genuinely sink the project, and both have concrete, early mitigations. The company-history pause risk at 15 is unusual because its likelihood is only moderate but its impact is maximal, which is exactly the kind of risk a register surfaces and gut feel ignores.

Mitigate, Monitor, or Accept

You cannot actively work every risk, and you should not try. For each risk, decide on one of three responses, generally guided by the score:

• Mitigate the high-score risks. Take real action now to lower likelihood or impact. For Eleanor, the top three (scores 20, 16, and 15) all get active mitigation with owners and deadlines.
• Monitor the middle-score risks. You will not invest heavily yet, but you watch for early warning signs and have a trigger that tells you when to act. The deadline-buffer and integration-complexity risks sit here.
• Accept the low-score risks. Acknowledge them, write them down, and consciously choose not to spend resources. The training-delay risk at 4 is accepted: if it happens, it is a manageable nuisance, not a crisis.

A fourth option, avoid, means changing the plan so the risk disappears entirely. If the finance-director risk felt severe enough, Eleanor could avoid it by bringing finance into the vendor selection from the start so there is no decision left to reopen. Avoidance is powerful but usually costs you something in scope or schedule, so it is reserved for the rare risk you genuinely cannot live with.

Beware two opposite failures. One is treating the register as wishful thinking, where naming a risk feels like handling it but nobody actually does anything. The other is over-catastrophizing, where the AI's long list paralyzes you into mitigating everything and shipping nothing. The score column is the cure for both: it tells you the short list that earns real effort and gives you permission to accept the rest.

Contingency Plans: What If It Happens Anyway

Mitigation lowers the odds or the damage. A contingency plan answers a different question: if this happens despite everything, what do we actually do? For your top few risks it is worth writing that answer down in advance, because the moment a risk materializes is the worst possible moment to invent a response. Eleanor wrote three. If the legacy export keeps failing, the fallback is to go live with a manually validated subset of data and complete the automated import in a follow-up phase. If the engineer's ramp-up runs long, the fallback is to buy more vendor support hours and cut the non-essential reports. If leadership pauses the project, the fallback is a documented restart plan that preserves the work already done rather than losing a quarter of context.

Contingency planning also gives you a cost comparison that clarifies the mitigate-or-accept decision. For each of your top risks, ask what the worst case actually looks like, what your workaround would be, and how the cost of mitigating now compares with the cost of falling back later. Sometimes the fallback is cheap enough that heavy mitigation is not worth it, and knowing that is what stops you from over-preparing.

It helps to sequence the mitigations across the project rather than treating them as a list. Some belong before kickoff, like Eleanor's pre-brief to the sponsor and the written confirmation of the vendor decision. Some belong in week one, where the cheap information lives: the test export, the integration spike, the confirmation of the analyst's availability. Others sit later, like scheduling user training in week ten. Mapping mitigations onto the calendar turns the register into a plan, and it front-loads the checks that could change the shape of the whole project while there is still time to change it.

One recurring risk deserves its own mechanism. Scope creep is best handled not by vigilance but by a change process: lock the scope at a defined point, then route new requests to a later phase rather than absorbing them. Eleanor locked hers at the end of the design work and allowed only minor adjustments afterwards, which is the honest version of a scope freeze; a hard freeze while the design is still iterating tends to be ignored, and a rule that gets ignored is worse than no rule.

Assigning Owners and Setting Triggers

Every risk you decide to mitigate or monitor needs one named owner. The owner is not necessarily the person who fixes the problem; they are the person who watches the risk and raises a hand when it starts to materialize. Diffuse ownership ("the team will keep an eye on it") means nobody is watching.

For monitored risks especially, define a trigger: the specific, observable signal that turns a monitored risk into an active one. A vague "watch the data export" is weak. "If the Week 1 test export has more than a 2 percent mismatch rate, we escalate and add a second engineer to the validation work" is a trigger. It tells the owner exactly when to act and removes the judgment call from the heat of the moment, when judgment is worst.

Eleanor keeps the register alive with a fifteen-minute risk review every Friday. The team walks the top five risks, updates any scores that have moved, and checks whether any trigger has fired. A register that is built once and never revisited is just a document. A register reviewed weekly is a management tool, because risks change: likelihoods rise and fall as the project moves, new risks appear, and mitigated ones drop off.

Give that review a simple escalation rule as well. When a risk moves from monitored to active, it does not just change colour on your spreadsheet; it goes up. Eleanor's rule is that any risk crossing that line gets raised with her sponsor in the same week, with the trigger that fired and the fallback she intends to use. Escalation framed that way is not an admission of failure. It is the sponsor finding out early enough to help.

The Same Method on a Decision

Risk work is not only for projects. It is at least as useful when you are deciding whether to do something at all, and Eleanor used it before the migration was ever approved. The trick with a decision is to ask for both sides: the risks of making the change and the risks of not making it. Most people only list the first, which is why the safe-looking option so often wins by default.

She described the choice to the AI in plain terms. The team knew the old platform well. The new one had a learning curve, the migration would take about four weeks, the new platform was better supported and more actively developed, and it carried a subscription cost where the old one had been effectively free. Then she asked for the risks of switching, the risks of staying, and help thinking the decision through.

The risks of switching came back in three groups. Technically, there was the learning curve costing roughly two weeks of productivity, the chance of migration bugs and data loss during the transition, a degree of lock-in because the new platform is proprietary and switching again would be harder, and the need to rebuild monitoring on unfamiliar tooling. On resourcing, four weeks of effort comes directly out of other work, the expertise concentrates in whoever learns it first and walks out of the door with them if they leave, and both systems have to run in parallel until the cutover is complete. Operationally, the pipeline is critical, so any cutover downtime affects everything downstream, and future updates from the vendor could break existing workflows.

The risks of staying were less obvious and, laid out side by side, no smaller. Competitively, iteration stays slower and teams using more modern tooling may ship faster. Technically, the older architecture accumulates debt, scales less comfortably as the work grows more complex, and sits on a community that is shrinking relative to the alternative. On resourcing, hiring becomes harder because engineers expect modern tools, and existing engineers may want to work with newer technology. On cost, the apparently free option carries a real operational burden of manual management, self-hosting, and updates, which is paid in on-call pain rather than in invoices.

The decision matrix that followed was blunt about both paths. Switching buys faster iteration, modern tooling, and a better hiring story at the cost of four weeks of opportunity, migration risk, and a learning curve, and it makes sense if you expect to live with the tool for at least a couple of years, since the return takes something like six months to arrive. Staying avoids disruption and keeps the team shipping features through the period the migration would have consumed, at the cost of compounding technical debt, harder hiring, and slower iteration. The analysis was explicit that staying only made sense if the whole pipeline was going to be replaced soon anyway; the source Eleanor was working from was cut off before it named a timeframe, so she treated it as a question to answer herself rather than a number to accept.

Her review found one gap: the analysis never mentioned customer impact, and if the pipeline goes down the dashboards her operations team relies on go with it. She added that, then made the call. Migrate, but do it in the quieter month, run both systems in parallel for a week to validate before cutting over, and get experienced help with the process. The subscription cost was real and worth paying for the velocity and hiring benefits. What the AI gave her was a fast, balanced, thorough map of both options. What she gave it was the customer consequence and the decision itself.

Operational Risk: The Service That Must Not Fall Over

The third shape of risk work is ongoing rather than project-bound. If you manage a service that other people depend on, the register looks slightly different: you are hunting for single points of failure, skill gaps where only one person can fix something, scaling limits you have not tested, and vendor risks in the components you do not control.

Describe the service to the AI, its architecture, its dependencies, who supports it, and the load it carries, then ask for operational risks in those categories with two mitigations for each: one that reduces the likelihood of the failure and one that reduces the impact when it happens anyway. The impact-reducing half is where the real resilience lives, and it usually looks like a failover path, better documentation, or a runbook that lets a second person handle an incident at two in the morning.

Then decide what is worth investing in, because operational mitigation is rarely free. And finish with the step people skip: test it. A failover that has never been exercised and a runbook nobody has followed are both hypotheses, not mitigations.

Using AI Well in Risk Work

Write your own list first. Spend five minutes naming the risks you already sense before opening an AI tool. This keeps the AI from anchoring your thinking and ensures the company-history and political risks, which only you know, make it onto the page.

Name the categories in your prompt. Asking simply for "risks" yields a shallow list. Asking for risks across dependency, timeline, resourcing, stakeholder, technical, and political categories forces breadth and surfaces the ones you would have skipped.

Treat AI scores as a starting draft. The AI's likelihood and impact numbers are generic. Re-score using what you actually know about your team, your vendors, and your history. The adjusted scores are the ones you act on.

Use AI for contingencies too. Once your top risks are set, ask the AI to draft a fallback plan for each: "If the data export keeps failing, what are our options?" It is good at generating alternatives you can then weigh.

Interrogate the risks it hands you. The opposite of AI blindness is AI credulity. A generic list will contain risks that are simply not real in your context, and if you take the register as truth you will spend real effort preparing for things that cannot happen to you. Read each one and ask whether it is a genuine risk here, then adjust the likelihood down or strike it out entirely.

Checkpoints Before You Call the Register Done

Five questions are worth asking before you circulate a register, and they take about ten minutes between them.

• Completeness. What major risk might still be missing? Walk the categories once more, thinking about dependencies, people, technology, and the world outside, and ask the question that surfaces the rest: what would we most regret not having planned for?
• Likelihood realism. Are these estimates grounded in history, or are they theoretical? If you cannot point to why a number is what it is, treat it as a guess and label it as one.
• Mitigation realism. Are the mitigations actually doable? Do they justify their cost, and can they be done inside the project window rather than in an imaginary quieter month?
• Ownership. Is it clear who watches each risk, is that a specific named person, and do they know it is theirs? An owner who has not been told is not an owner.
• Priority. Is your effort concentrated on the risks with the highest scores, or spread thinly across many small ones?

What a Register Cannot Do

Three honest caveats keep this practice useful rather than performative. A register is not a guarantee: risks still happen, and the document only means you are prepared, not protected. Some risk is inherent in doing anything worth doing, and a plan that claims to have eliminated it is telling you something about its author rather than about the project.

Be honest about uncertainty too. Calling something high likelihood is a guess unless you have evidence behind it, and it is entirely acceptable to write down that you do not know the likelihood and will monitor it. That is more useful to the people reading your register than false precision.

And keep the exercise from tipping into catastrophizing. Naming risks changes how a team feels about a project, and a long list of theoretical worst cases can drain confidence without improving preparation. Stay with actionable risks, the ones where naming them leads to a decision, and let the score give you permission to leave the rest alone.

Practice

Four exercises will make this a habit rather than a technique you have read about.

First, run a full risk assessment on a real project. Use AI to brainstorm across the categories, estimate likelihood and impact yourself, pull out the high-priority risks, define a mitigation for each, and assign owners. Doing it once end to end is what makes the second time fast.

Second, do a historical calibration. Look back at your last few projects and list the risks that actually hit. Did you see them coming? Which ones did you overblow, and which did you underestimate? That review is the single best way to make your next set of likelihood estimates honest.

Third, practise contingency planning. Take your top three risks and, for each, write down the worst case, the fallback or workaround, and how the cost of mitigating compares with the cost of falling back. Some of your mitigations will not survive that comparison, which is the point.

Fourth, make risk ownership real. Name one person to own risk monitoring for a project, agree a weekly check on the top five, agree that they escalate when likelihood or impact shifts, and let them run the mitigations as planned.

Then take two minutes for a reflection. Think about the past week and find one decision where a five-minute risk pass would have changed your approach. What would you have done differently, and what would the outcome have been? Eleanor's whole practice started from exactly that question, asked after an eleven-week slip.

Related Lessons

Creating Project Plans With AI is where your risks should land. A plan that does not name its risks is a schedule with optimism baked in, and the register is the section that makes the plan honest about what could move it.

Prioritization Frameworks With AI connects because risk frequently drives priority. A high-score risk with an early, cheap mitigation often deserves to jump the queue, and the reason it belongs there is legible to everyone once the score is written down.

Resource and Capacity Planning supplies several of your most common risks directly. Single-specialist dependencies, people running at unsustainable utilization, and unplanned leave in a critical week are resourcing risks that a capacity model surfaces before the register does.

Verification Workflows is the discipline that keeps the register current, because tracking status against what you planned is what turns a weekly risk review into a real check rather than a recital.

Summarizing Documents and Reports follows this lesson in the programme, moving from planning work into information synthesis, where the same pattern applies: AI supplies breadth and speed, and your judgment supplies what matters.

Key Takeaways

• The hardest part of risk work is the blank page, and that is exactly what AI solves. Given a clear project description and named categories, an AI assistant reliably produces a broad first-cut risk list in seconds, turning your job from generating risks into the easier task of editing them.
• A risk register is risk, likelihood, impact, score, mitigation, owner, and status. The format is simple; the value comes from honest scoring and a real named owner for every risk you choose to manage.
• Score likelihood and impact separately on a 1 to 5 scale, and multiply. The score sorts your register so the risks that could actually sink the project rise to the top. Use the full range; if nothing is a 1 or a 5, your scores are not discriminating.
• AI is blind to your company's history and politics. It nails the predictable categories and misses the risks rooted in past projects and specific personalities. You supply the institutional memory; the AI supplies the breadth.
• Decide mitigate, monitor, or accept for each risk. Actively work the high scores, watch the middle ones with a defined trigger, and consciously accept the low ones. You cannot manage every risk, and the score tells you which ones earn the effort.
• Every managed risk needs one named owner and, when monitored, a trigger. A trigger is the observable signal that turns a watched risk into an active one, so the decision to act is made in advance rather than in the panic of the moment.
• Write a contingency plan for your top risks. Mitigation lowers the odds; a contingency plan says what you do if it happens anyway. Deciding the fallback in advance beats inventing one in the middle of the crisis, and comparing mitigation cost against fallback cost tells you which risks are worth real effort.
• Calibrate likelihood against your own history. Managers systematically underestimate how likely things are. Score against what actually went wrong on your last few projects rather than against how you feel about this one.
• Ask for the risks of not acting, too. Applied to a decision, the method only works if you list the risks of staying put alongside the risks of changing, otherwise the status quo wins by never being examined.
• A register reviewed weekly is a tool; a register built once is a document. Risks change as the project moves, so a short standing review keeps scores current and catches triggers before they become crises.