Risk Register Builder
OPEN SAMPLE Builds a structured risk register from the threats you identify, scoring each by likelihood and impact and noting current controls. Use it at the start of a project or after a major scope change to get all known risks on paper and prioritized.
PROJECT MANAGER NAME ·PROJECT NAME ·ORGANIZATION NAME ·PROJECT DESCRIPTION ·PROJECT PHASE ·TARGET COMPLETION DATE ·KEY STAKEHOLDERS ·RISK INPUTS
## Context
You are a project management assistant helping [PROJECT MANAGER NAME] build a risk register for [PROJECT NAME] at [ORGANIZATION NAME]. The project involves [PROJECT DESCRIPTION]. The project is currently in [PROJECT PHASE] and is scheduled to complete by [TARGET COMPLETION DATE]. Key stakeholders include [KEY STAKEHOLDERS]. The risk identification inputs below come from the project team.
Risk inputs from the team:
[RISK INPUTS]
## Task
Build a risk register table with these columns: Risk ID, Risk Description, Category (schedule / cost / scope / resource / external / safety), Likelihood (1 to 5), Impact (1 to 5), Risk Score (Likelihood x Impact), Priority (High if score 15 or above, Medium if 8 to 14, Low if 7 or below), Current Controls, Risk Owner, and Status (Open).
After the table, provide:
1. A top-3 list of the highest-scoring risks with one sentence on why each deserves immediate attention.
2. Any risk categories that appear underrepresented based on the project description, so the team can decide whether to dig deeper.
## Standards
- Assign Risk IDs sequentially: R-001, R-002, and so on.
- Use only the risks and controls the team provided. Do not invent risks, scores, owners, dates, or controls.
- If a risk input is vague, write the description as clearly as possible and flag it with "(Needs clarification)" in the Description field.
- Do not invent dollar figures, schedule estimates, or percentage probabilities. Use the 1-to-5 scale only.
- Keep each risk description to one sentence: what could go wrong and what it would affect.
- The Risk Owner column lists names or roles only if the team provided them; otherwise leave it blank.
- If any required input is missing or ambiguous, ask before building the register.
BEFORE YOU RUN IT
- Project name, phase, and target completion date from the project plan
- List of identified risks from the team, including any controls already in place
- Names or roles of likely risk owners for each risk category
- Confirm that all dates, scores, and status information come from your project records, not assumed by the AI
- Keep vendor names, contract values, and personnel details general or anonymized unless your AI tool is approved for sensitive project data
- A note on any risk categories the team already discussed so the AI can flag gaps
VERIFY BEFORE IT LEAVES YOUR HANDS
- Confirm every Risk ID is unique and sequential before sharing the register
- Recompute each Risk Score (Likelihood x Impact) yourself to catch arithmetic errors
- Check that no risk, control, owner, or date was invented by the AI that you did not provide
- Verify the Priority thresholds were applied correctly: High is 15 or above, Medium is 8 to 14, Low is 7 or below
- Confirm the top-3 list matches the highest numeric scores in the table
- Review any flagged '(Needs clarification)' descriptions with the team before the register is baselined
Sample output
Sample output. Generated by AI from sample inputs:
Risk register for Project Atlas -- Northwind Logistics Warehouse Migration, Phase 2 (Planning).
| Risk ID | Risk Description | Category | Likelihood | Impact | Score | Priority | Current Controls | Risk Owner | Status |
|---|---|---|---|---|---|---|---|---|---|
| R-001 | Key migration vendor may miss the delivery window, delaying warehouse cutover by two or more weeks. | Schedule | 3 | 5 | 15 | High | Weekly vendor check-in; milestone payment tied to delivery. | Ops Director | Open |
| R-002 | Legacy inventory system may not map cleanly to the new warehouse management system, requiring rework. | Scope | 4 | 4 | 16 | High | Data mapping review scheduled for Week 3. | IT Lead | Open |
| R-003 | Trained staff turnover during migration window could reduce throughput at go-live. | Resource | 2 | 4 | 8 | Medium | Cross-training plan drafted; not yet executed. | HR Lead | Open |
| R-004 | Permit approval for dock expansion may be delayed by the city, pushing Phase 3 start. | External | 2 | 3 | 6 | Low | Permit submitted; city timeline is 30 business days. | Facilities | Open |
| R-005 | Budget variance from fuel and freight cost increases may exceed contingency reserve. | Cost | 3 | 3 | 9 | Medium | Contingency reserve in place; freight costs not yet locked. | (Needs clarification) | Open |
Top 3 risks:
1. R-002 (Score 16) -- A data mapping failure at this scale can halt the go-live entirely; the Week 3 review is the critical gate.
2. R-001 (Score 15) -- Vendor delivery is on the critical path; any slip cascades directly to cutover.
3. R-005 (Score 9) -- Freight cost volatility is active now; the contingency size needs confirmation against current quotes.
Underrepresented category: Safety. A warehouse migration involves physical relocation of equipment and personnel working in a changed environment. The team may want to add at least one safety risk before baselining.
CUSTOMIZATION Adjust the scoring thresholds in the Standards block to match your organization's risk matrix. For larger programs, add columns for Residual Risk Score and Target Mitigation Date. Veterans and logistics professionals can use this same structure for readiness reviews by renaming categories to match their standard risk taxonomy (for example: personnel, equipment, sustainment, external).
Change Request
OPEN SAMPLE Writes a formal change request document including the reason for the change, the scope of the change, and a structured impact analysis covering schedule, cost, and resources. Use it any time a proposed change to scope, schedule, or budget needs to go through a formal approval process.
REQUESTOR NAME ·PROJECT NAME ·ORGANIZATION NAME ·APPROVING AUTHORITY ·CHANGE DESCRIPTION ·CHANGE TYPE ·CHANGE JUSTIFICATION ·ALTERNATIVES CONSIDERED ·SCHEDULE IMPACT ·BUDGET IMPACT ·RESOURCE IMPACT ·CHANGE RISKS ·REQUESTED EFFECTIVE DATE
## Context
You are a project management assistant helping [REQUESTOR NAME] draft a change request for [PROJECT NAME] at [ORGANIZATION NAME]. The change request is being submitted to [APPROVING AUTHORITY].
Change description (what is changing and why):
[CHANGE DESCRIPTION]
Change type: [CHANGE TYPE] (scope / schedule / budget / resource / technical / other)
Reason and justification:
[CHANGE JUSTIFICATION]
Alternatives considered before requesting this change:
[ALTERNATIVES CONSIDERED]
Proposed impacts on schedule:
[SCHEDULE IMPACT]
Proposed impacts on budget:
[BUDGET IMPACT]
Proposed impacts on resources:
[RESOURCE IMPACT]
Risks introduced or reduced by this change:
[CHANGE RISKS]
Requested effective date:
[REQUESTED EFFECTIVE DATE]
## Task
Draft a change request document with these sections:
1. Change Request Summary (one paragraph: what, why, and the requested effective date).
2. Change Description (detailed explanation of what is changing).
3. Justification (why this change is necessary or beneficial).
4. Alternatives Considered (what other options were evaluated and why they were rejected).
5. Impact Analysis (schedule, budget, resource impacts in table form).
6. Risks Introduced or Reduced.
7. Recommendation (one sentence: approve, deny, or defer, written as a blank for the approver to fill in).
8. Signature block with Requestor, Approver, and Date fields.
## Standards
- Use only the information the requestor provided. Do not invent schedule dates, cost figures, resource names, or risk ratings.
- Impact Analysis table: show baseline, proposed change, and net delta for each dimension. Use [BASELINE VALUE] as a placeholder where the requestor did not supply the current baseline.
- Tone: factual and neutral. This is a record, not a sales pitch.
- Note at the bottom: this document does not constitute a contract modification. Formal contract changes require review by the contracting authority.
- Length: 400 to 600 words of narrative, plus tables.
- If any required input is missing, ask before drafting.
BEFORE YOU RUN IT
- Clear description of what is changing, written by the person requesting the change
- The baseline values for schedule, budget, and resources before the change
- Specific impacts on schedule, cost, and resources with numbers from the project plan
- At least one alternative that was considered before the change was requested
- Risks introduced or reduced by the change, from the risk register or team discussion
- Confirm all baseline values, dates, and cost figures come from current project records, not estimated by the AI
VERIFY BEFORE IT LEAVES YOUR HANDS
- Confirm the Impact Analysis table shows your actual baseline values, not placeholders the AI invented
- Check that no cost figures, schedule dates, or resource counts were invented by the AI
- Verify the net delta in each impact row is correct by computing it yourself
- Confirm the alternatives section accurately reflects what the team actually evaluated
- Check the risks section against the project risk register before submitting
- Verify the contractual disclaimer is present and that no language in the document implies a contract modification has occurred
- Do not submit this document until the requestor has reviewed every field and confirmed its accuracy
Sample output
Sample output. Generated by AI from sample inputs:
Change Request CR-007
Project: Atlas -- Northwind Logistics Warehouse Migration
Requestor: Operations Director, Northwind Logistics
Approving Authority: Steering Committee
Date Submitted: [INSERT DATE]
Requested Effective Date: [INSERT DATE]
1. Change Request Summary
This change request proposes to defer the Phase 2 go-live date by three weeks to allow completion of the legacy system data mapping audit, which identified a larger-than-expected number of unmapped fields. Without this extension, the migration would proceed with an incomplete data set, increasing the risk of inventory errors at go-live. The requested effective date is [INSERT DATE].
2. Change Description
The current Phase 2 go-live date will be extended by three weeks. All Phase 2 milestones shift proportionally. Phase 3 planning start date is also affected. No scope changes are proposed.
3. Justification
The Week 3 data mapping review found that 18 percent of legacy product fields do not have a direct equivalent in the new WMS. Mapping these fields manually requires an estimated three additional weeks of IT and operations effort. Proceeding on the original date would require going live with incomplete inventory records.
4. Alternatives Considered
- Proceed on the original date with a partial dataset and remediate post-go-live: rejected because inventory errors during the peak shipping period carry unacceptable operational risk.
- Reduce the scope to exclude the unmapped product categories: rejected because those categories represent core stock the warehouse cannot operate without.
5. Impact Analysis
| Dimension | Baseline | Proposed | Net Delta |
|---|---|---|---|
| Go-live Date | [BASELINE VALUE] | [BASELINE VALUE + 3 weeks] | +3 weeks |
| Phase 3 Start | [BASELINE VALUE] | [BASELINE VALUE + 3 weeks] | +3 weeks |
| Budget | [BASELINE VALUE] | [BASELINE VALUE + extended labor cost] | To be confirmed by PM |
| Resources | IT Lead + Ops SME assigned through go-live | Same, extended 3 weeks | +3 weeks of IT Lead and Ops SME time |
6. Risks Introduced or Reduced
- Reduced: R-002 (Data Mapping Failure) likelihood decreases from 4 to 2 if the extension is used to complete the audit.
- Introduced: Extended timeline increases exposure to R-001 (Vendor Delivery Delay) if the vendor's schedule is fixed.
7. Recommendation
This change request is: [ ] Approved [ ] Denied [ ] Deferred
Comments: _______________
Approver Signature: _______________ Date: _______________
Requestor Signature: _______________ Date: _______________
Note: This document does not constitute a contract modification. Formal contract changes require review and approval by the contracting authority.
CUSTOMIZATION For government contracts and defense logistics programs, add a Contract Line Item Number field and note the requirement for a formal contract modification through the contracting officer. Larger programs should add a Change Control Board tracking number and link the change request to the project schedule baseline version. Adapt the impact table to match your organization's earned value or schedule performance reporting format if those baselines are tracked.