Skip to main content
DoneThat

AI Adoption GuideConsultingKickoff

Risk Register Bootstrapper

LLM generates an initial risk register with likelihood and impact scores drawn from comparable project postmortems.

Consulting processSellScopeStaffKickoffAnalyzeRecommendDeliverClose

By Don, DoneThat’s AI coach · updated

Stop opening the blank house template

The quality problem at kickoff is not missing risk categories. It is a register nobody will own. The usual path is a house spreadsheet with three lines that would fit any engagement: key-person absence, scope change, delayed access. That file is opened once, dropped into the kickoff pack, and ignored.

A useful bootstrap is a short draft pulled from closed work that looked like this one, with likelihood and impact taken from what those files recorded. The draft exists so the team can reject most of it. It is not the register until someone puts a name on a row.

Catalogue lists and ISO-style taxonomies are designed to cover everything. Coverage is how you get forty rows and no owners. For this use case, quality means about ten risks this team will actually watch.

Skip the review and the generated file is worse than the three-line template: it looks like control, and nobody is managing a risk.

Retrieve closed files that actually failed

Seed retrieval from comparable closed engagements, not from a standard risk list. Match on problem shape, sector, delivery model, duration, and the client-side constraints that bind: data access, overlapping programs, a single sponsor. Client name and industry label alone are weak matches. Two operating-model programs can fail for opposite reasons.

Use a comparable past scope retriever if you have one, or search the closed-file store on the same dimensions. Rank the messy closes first. Engagements that overran, slipped a milestone, or needed a painful change order are the instructive set. Smooth closes tell you almost nothing about what to watch on day one.

From each comparable, read the postmortem, not the slide that said "communicate more." A lessons learned synthesizer helps when it names the event, when it showed up, what it cost, and what contained it or failed. Extract candidates as rows: event, trigger, workstream, and the mitigation that was tried.

Drop confidential files that cannot inform other accounts even internally. If a postmortem does not map onto this SOW's workstreams, it is not a comparable.

Do not run the bootstrapper on an empty corpus. Without real postmortems the model fills house columns with generic boilerplate: stakeholder alignment, data quality, resource availability. That prose looks professional and contains no memory. If you only have a handful of thin retrospectives, write the register from those files by hand. Tooling does not create history.

Bring scope-stage flags in as candidates, not as the list. A scope risk classifier can mark ambiguity, client dependencies, and unproven access on the SOW. Those flags still have to survive postmortem evidence and the cut-or-keep pass. A classifier that marked half the scope has not given you ten owned risks.

Open readiness items that will still be true on day one belong here too. Access granted on paper, missing sign-offs, and environments that are not actually usable are delivery risks if a pre-kickoff readiness gap detector still shows them open. They are not a separate polite checklist.

Likelihood is a count in your history

Score likelihood from the comparable set you actually retrieved, not from expert judgment in the prompt. For each candidate, count how often the same event materialized in those files. If working access failed in most of the messy comparables, the risk is frequent in your history. If it never appeared, leave it off the kickoff list even if a partner is uneasy.

Do not blend scores across the whole firm. A pattern that is common in cutover work and rare in diagnostic work should not inherit a firm-wide average.

Impact is historical language mapped onto your house scale, whether that is 1-5 or high/medium/low. Use what the files recorded: slipped milestone, rework loop, idle time, change order, sponsor churn. Ask the model to cite the postmortem line. If a file has no impact language, leave the cell blank and make the team fill it. A guessed score is decoration.

Mitigations come from the same files. Attach only actions that were tried. "Increase communication" is not a mitigation. "Client data owner in the Tuesday working session until the first complete extract landed" is. If nothing worked, write that. An owned risk with no working play is still worth listing.

Every row needs a keep, a merge, or a cut

Cap the draft at about ten risks the team will actually own. The model will emit a catalogue. Forty rows dilute attention until nothing is managed. Completeness is the failure.

Walk the team through every row in a short session. Email is how rows survive without owners. For each row, do one of three things: keep and name an owner, merge into another row, or cut. "Noted" is not allowed. A generated register nobody reviews is worse than a short one the team owns.

Owners are people, not workstreams. If the trigger is client-side, name a client counterpart as well as the consulting owner. A row with "PMO" in the owner cell is not owned.

After kickoff the register is a habit. Review it at every milestone against what actually happened. A register updated once is decoration. Later, a workstream delivery risk predictor may flag velocity or issue-trend problems. Treat those flags as candidates for the live list. Someone still cuts or keeps. Automatic rows recreate the forty-line file.

Illustrative example: Meridian Payments, week minus one

This is a worked example with made-up firms, written to show the cuts, not a case study with results.

Hale & Rowan is kicking off a 16-week payments-operations engagement with Meridian Payments. The SOW has three workstreams: fee-leakage baseline, exception-process redesign, and a 90-day operating cadence. Jordan Hale is the engagement manager; two consultants new to Meridian are staffed.

Jordan does not open the blank house template. She retrieves six closed files that look like this problem: payments or billing operations, mid-market processors, heavy client-data dependency, similar duration. Two were clean. Four were not. She feeds those four postmortems, the signed SOW, and the still-open readiness items, and asks for at most twelve candidate rows cited from the files.

The draft comes back with twenty-two rows. Several are catalogue language: key person risk, scope change, regulatory change. None of those four files mentioned a regulatory event. She deletes the catalogue block.

What remains is specific. In three of the four messy files, "data access granted" was not working access: extracts arrived late, in the wrong grain, or through a person who had left. In this set the event is frequent, and the files describe idle time in the first two weeks. The mitigation that worked once was a named client data owner in the twice-weekly working session until the first complete extract landed. In two files, exception-process workshops ran before the baseline was agreed, and the design had to be redone. In one file, the sponsor changed mid-engagement and the steering pack had never named a deputy.

Jordan takes ten candidates into a thirty-minute team cut. They keep six: working data access, workshop sequencing against the baseline, sponsor-deputy coverage, exception-inventory completeness, overlapping client initiatives that starve workshops, and a fee-logic assumption the SOW treated as known. They merge two access-related rows. They cut "resource availability" because it named no person and no trigger. Each kept row gets an owner on the consulting side, and where the trigger is client-side, a client counterpart.

They do not keep sixteen "just in case" rows. The live copy has six.

Park the owned list where status already lives

Put the owned rows in the same place the team already updates status. Tools in the Smartsheet, monday.com, Jira, and ServiceNow class all hold a risk list. Use whichever one this engagement already lives in. Do not stand up a second register in a chat export or a slide appendix "for the steering pack." Two copies diverge in a week.

Do not expect the tool to enforce ownership. Fill owner and next review date yourself, and set red/amber/green from the last review, not from the model's first score.

Trial this on one kickoff you are already running, in parallel with the blank template. The test is simple. Did the team cut or keep every row. Can each kept row point at a postmortem. Did you stay near ten. If the answer is a twenty-row file nobody opened after the kickoff meeting, stop. Quality is ownership, not coverage.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first