Actions
Actions is a lightweight governance-layer tracker for discrete tasks arising from meetings, RAID Log items, risk mitigations, and runbook reviews. With built-in email reminders, priority levels, and due date tracking, Actions ensures every follow-up item has a clear owner and deadline. Unlike Runbook tasks — which are sequential and execution-focused — Actions are standalone items that require follow-up and can come from any source at any point in the project.
Overview
The Actions module is a governance-layer action tracker, not a substitute for Runbook tasks. Where Runbook tasks are sequential, execution-focused steps tied to a specific migration event and T-Minus schedule, Actions are standalone items — follow-ups, confirmations, investigations, stakeholder requests — that arise from governance activity and need to be tracked to completion regardless of where they originated.
Actions can come from any source: a governance meeting, a RAID Log item, a risk mitigation requirement, a stakeholder request, or an issue raised during a runbook review. They are linked to a migration event where relevant, but they exist independently of the runbook execution pipeline. This makes Actions the right place to capture anything that doesn't neatly fit into a T-Minus schedule but still needs an owner, a due date, and follow-through.
Actions have a simple lifecycle: Open → In Progress → Completed / Deferred / Cancelled. Each action supports configurable email reminders, so owners receive advance notice before their due date. Actions appear on each team member's personal action dashboard, giving individuals a clear view of what they owe the project — without having to dig through meeting minutes or RAID registers.
When to use this
- Governance meetings: Capture follow-up items in real time during steering committees, wave planning sessions, or daily stand-ups — so nothing is lost in meeting notes.
- Risk mitigations: When a risk in the RAID Log requires a specific action to reduce its likelihood or impact, log that mitigation step here with an owner and due date.
- Ad hoc follow-ups: When someone raises a point in a meeting that needs a response by a specific date but doesn't belong in a runbook — for example, "Confirm firewall rules with the security team before T-5."
- External dependencies: Chase external teams (network, security, procurement, vendors) for confirmations, deliverables, or approvals that the migration is waiting on.
- Items that don't fit a runbook: Any follow-up task that is governance-layer or pre-planning in nature — not part of a specific migration event's execution sequence.
Key features
Step-by-step instructions
Creating an action
Complete the following required fields before saving:
- Title — a concise, unambiguous description of the action
- Description — additional context or acceptance criteria
- Owner — the person responsible for completing the action
- Due Date — a firm date by which the action must be resolved
- Priority — High, Medium, or Low
Updating action status
Filtering by owner or due date
Configuring email reminders
Exporting actions for meeting reports
Important fields
| Field | Required / Optional | Description |
|---|---|---|
| Title | Required | A concise, unambiguous description of the action. Should be specific enough that the owner knows exactly what is expected without reading the description. |
| Description | Required | Additional context, background, or acceptance criteria for the action. Explain what "done" looks like so there is no ambiguity at completion. |
| Owner | Required | The person responsible for completing this action. Only one owner per action — if multiple people are involved, assign to the person accountable for the outcome. |
| Due Date | Required | The date by which this action must be completed or escalated. Used for overdue highlighting and email reminder scheduling. Always set a firm date. |
| Priority | Required | The urgency level of the action: High (blocks migration or poses significant risk), Medium (important but not blocking), or Low (good to have, minimal impact if delayed). |
| Status | Required | Lifecycle state of the action: Open (not yet started), In Progress (owner is actively working on it), Completed (done), Deferred (postponed with new due date), or Cancelled (no longer required). |
| Migration Event | Optional | Links the action to a specific migration event (wave) for context and filtering. Useful when reviewing all outstanding actions for an upcoming wave in governance meetings. |
| Source | Optional | A free-text or linked reference to what triggered this action — for example, a meeting name and date, a RAID item ID, or a risk reference. Provides full traceability. |
Example workflow
During the Wave 2 governance meeting, three follow-up items are raised by attendees. Rather than recording them in meeting minutes and hoping someone follows up, the meeting facilitator opens Governance → Actions and creates all three immediately.
The first action is assigned to John on the network team: "Confirm firewall rules are open between source and target subnets before migration window." Priority: High. Due: Friday. The second action goes to Sarah, the project manager: "Send migration communication email to all impacted application owners." Priority: Medium. Due: T-7. The third action is assigned to Tom, the lead engineer: "Verify that automated backup jobs have been suspended for all Wave 2 devices." Priority: High. Due: T-3.
All three actions are saved before the meeting ends. John receives a reminder email on Thursday (one day before his due date, per the configured 1-day lead time). On Friday, John updates his action to Completed and adds a note confirming the firewall change request number. Sarah's action is later set to Deferred by one week when the communication template is revised, and the due date is updated accordingly. Tom completes his action at T-4 — one day early — and marks it Completed.
At the next governance meeting, the facilitator filters the Actions list to Status = Open and exports the result to Excel for the meeting pack. The register shows only two remaining open actions, giving stakeholders a clear picture of outstanding governance obligations before the migration window opens.
Tips & best practices
The most effective time to log an action is the moment it is raised — in the meeting itself. Actions recorded immediately are more accurate, more specific, and more likely to be acted on than those reconstructed from notes an hour later. Keep the Actions page open during governance meetings and log items as they arise.
Vague deadlines like "ASAP" or "soon" are not enforceable and rarely result in timely completion. Every action should have a specific calendar date. If the due date genuinely isn't known at creation time, agree on a date to re-review it (use that as the due date) rather than leaving it blank or open-ended.
If every action is marked High priority, none of them are. Reserve the High designation for actions that are truly blocking — items where delay would directly impact a migration window or create a significant risk. Using Medium and Low consistently means that when a High-priority action appears, the team treats it with appropriate urgency.
Common mistakes
An action without an owner is a wish, not a commitment. If nobody is accountable, nobody acts. Every action must have a named individual assigned as owner before the meeting ends. If ownership is unclear or contested, escalate to the project manager to assign it — do not leave the Owner field blank as a placeholder.
Actions without due dates languish indefinitely. They sit in the register looking like open work, obscuring the real picture of what's outstanding. The overdue highlighting and email reminder features both depend on a due date being set. Always set a specific date — it focuses the owner and makes the action trackable.
If a task is part of the execution sequence for a migration event — a pre-cutover check, a database backup step, a DNS cutover — it belongs in a Runbook, not the Actions register. Actions are for governance-layer follow-ups, not operational execution steps. Mixing the two makes runbooks incomplete and the action register noisy.
If actions are completed in reality but remain Open in the system, the register looks full even when things are done. Governance reports show inflated outstanding counts, and team members receive unnecessary reminder emails. Make it a habit to update action status promptly — ideally the same day the work is completed.