Project Plan

Project Plan

The Project Plan converts migration scope into accountable work. Each row should describe an outcome that can be owned, approved, evidenced, and closed, rather than a vague reminder to “work on migration.”

Use stable Task IDs so risks, validation checks, redirects, and decisions can reference the work without copying the same explanation into several sheets.

Build each task around an outcome

A strong row answers five questions: what must be true, who is accountable, what does it depend on, when is it due, and what evidence proves completion.

Field group	Fields	How to use them
Classification	Workstream, Task ID	Group the work and assign a stable identifier such as SCOPE-01, DEMO-01, or LAUNCH-01.
Outcome	Task / Outcome, Acceptance Criteria / Expected Output	State the result to achieve and the evidence-based condition that closes the task.
Accountability	Owner, Approver, Consulted / Support	Separate the person doing or coordinating the work from the person who approves its completion.
Control	Milestone / Decision Gate, Dependencies / Related IDs	Show which gate the task supports and which tasks, risks, validation items, or decisions affect it.
Timing	Start Date, Due Date, Duration (days)	Plan the work window. Duration is calculated from the entered dates and includes both the start and due date.
State	Status, Blocking?	Record progress and whether unfinished work blocks the next project decision.
Traceability	Evidence Link, Notes	Link to controlled evidence and record context that changes how the task should be interpreted.

Use workstreams consistently

The workbook provides workstreams for Preparation, Access, Scope, Configuration, Demo Migration, Validation, Decision, Full Migration, Launch readiness, Launch, Post-launch monitoring, and Custom Service.

Choose the workstream that reflects the task’s project role. Do not use workstreams to reproduce the Documentation sidebar or to split one outcome into unnecessary micro-tasks.

Write acceptance criteria before assigning Completed

A task is easier to close when the expected output is written before work starts.

Instead of:

Validate the migration.

Use a result that can be evaluated, for example:

Representative and high-risk records are checked against approved pass conditions, failures are classified, and required corrective actions have owners and evidence.

The exact checks still belong in the relevant Documentation validation procedure and in the Toolkit’s Validation sheet.

Connect dependencies with IDs

Use Dependencies / Related IDs to make cross-sheet relationships visible. A task can reference:

• another Task ID that must finish first;
• one or more Risk IDs that can prevent the outcome;
• Validation IDs that provide the acceptance evidence;
• Redirect IDs that must be ready before launch;
• Decision IDs that must be approved before the task can proceed.

Keep IDs short and stable

IDs are most useful when they remain unchanged after creation. Change the task description as the project becomes clearer, but avoid renaming IDs that are already referenced in other sheets or external evidence.

Use Status and Blocking? for different purposes

Status describes progress. Available values are Not started, In progress, Blocked, Completed, Deferred, and Not applicable.

Blocking? answers a different question: whether the unfinished task prevents a required next decision or milestone. Available values are Yes, No, and To be confirmed.

A task can therefore be In progress and still be a blocker, or Blocked operationally without blocking launch if the work belongs to a later controlled backlog.

Review the plan by decision gate

1. Filter to the next milestone or decision gate. Focus on the work that must close before the next project transition.
2. Check dependencies and blockers. Open related risks, validation rows, redirects, and decisions instead of copying their detail into the task row.
3. Confirm the owner and approver are still valid. Reassign responsibility before a due date is missed because ownership is unclear.
4. Update Status only from evidence. A task should be Completed when its acceptance criteria are met and the evidence location is known.
5. Move unresolved work deliberately. If a task is Deferred or Not applicable, record why and ensure any affected risk or approval decision reflects that choice.

Next Steps

Use Risk Register to capture uncertainty that could prevent important tasks from closing. Before migration execution, use Define Acceptance Criteria to turn critical task outcomes into testable validation checks.