A project plan is the shared record of what the project must deliver, who owns each next action, and how success will be checked. A decision record briefly preserves an important choice, its evidence, and its consequences so the team does not have to reconstruct it from memory or chat history.
Goal: maintain one project plan that names outcomes, owners, checks, decisions, risks, and handover responsibilities.
Prerequisites: the supervisor has identified the project, its owner, and the approved location for the authoritative plan.
Execution context: edit the plan in the supervisor-approved repository or collaboration system. Do not create a second planning location for the same project.
Use this guide when you own a project or deliverable. Keep the plan in the supervisor-approved repository or collaboration system. Do not create a second task board when the project already has one.
Start small: for a fictional beam test, record "produce a checked force curve", "run the documented synthetic test", "prototype lead" and "test output matches the expected curve" as outcome, next action, owner and check. Use the existing project record. The templates below are lookup aids as the project grows, not extra Passport assessment artifacts.
1. Confirm The Project Record#
Before planning, write down:
Project:
Supervisor:
Plan location:
Code location:
Durable data location:
Final handover location:
Expected: each location has an owner and authorized collaborators can open it. Do not put credentials or confidential data in the plan.
2. State The Outcome And Acceptance Check#
Write one concrete outcome and how it will be checked:
Outcome:
Accepted when:
Deadline:
Owner:
Example:
Outcome: A prototype records force measurements for one hour.
Accepted when: The test completes for 60 minutes and the result file passes the documented validation script.
Deadline: 2026-11-20
Owner: Prototype lead
Avoid goals such as “finish simulation” that do not define observable success.
3. Define Three To Six Milestones#
Each milestone needs a deliverable, owner, date, and check.
| Milestone | Deliverable | Owner | Date | Check |
|---|---|---|---|---|
| Baseline | Existing method reproduced | Named role | YYYY-MM-DD | Documented test passes |
| Prototype | Small working implementation | Named role | YYYY-MM-DD | Demonstration completed |
| Validation | Results on agreed cases | Named role | YYYY-MM-DD | Review criteria met |
| Handover | Code, data, report, instructions | Named role | YYYY-MM-DD | Successor reproduces check |
List dependencies explicitly. If validation needs an experiment, dataset, license, or compute allocation, assign the person who obtains it.
4. Keep One Weekly Action List#
At each short project check-in, update only:
Completed since last check:
Next actions: action | owner | due date
Blocked: blocker | decision/help owner
New or changed risks:
Decisions made:
An action without an owner is not assigned. A blocker without a decision owner will remain blocked.
5. Record Important Decisions#
Create a short decision record when a choice changes an interface, dependency, dataset, model, experiment, compute request, or handover.
Date:
Decision:
Owner:
Options considered:
Evidence:
Reason:
Verification:
Consequences or open questions:
AI assistance used, if any:
Record the decision after a person reviews it. An AI suggestion is an option, not a decision or verification result.
6. Track Only Actionable Risks#
Keep a small table and update it when evidence changes.
| Risk | Trigger or evidence | Prevention | Response | Owner |
|---|---|---|---|---|
| Equipment unavailable | Reservation not confirmed | Reserve early | Use approved fallback | Named role |
| Data loss | Only copy is temporary | Maintain durable copy | Restore from named source | Named role |
| Compute waste | Low measured utilization | Start with small request | Stop and right-size next job | Named role |
| Protected data exposure | Unapproved service proposed | Check policy first | Contain and report | Named role |
Remove a risk only after its owner verifies that it no longer applies.
7. Prepare Handover Before The End#
Use the Project Handover Lab. Confirm that a successor can find:
- the exact code revision;
- environment and setup files;
- authoritative inputs and outputs;
- one verification command and expected result;
- known limitations;
- access, retention, and cleanup owners.
Verification#
- The project has one authoritative plan.
- The outcome has an observable acceptance check.
- Every current action, blocker, risk, and milestone has an owner.
- Important decisions name evidence and verification.
- Code, data, access, and results have a handover destination.
- The plan contains no credentials or unnecessary confidential material.
If Blocked#
- Scope is unclear: ask the supervisor to choose the outcome and acceptance check before adding tasks.
- Two plans disagree: stop updating both and ask which one is authoritative.
- No owner is available: record the item as blocked; do not self-authorize access, data use, or publication.
- The plan becomes administrative work without decisions: keep only milestones, actions, blockers, decisions, risks, and handover information.
Ask For Help When#
The project has no named owner, two systems claim to be authoritative, a decision changes access or data handling, or the handover destination is missing. Ask the supervisor to decide the ownership boundary rather than creating another unofficial plan.
Verified: 2026-09-05. Review by: 2027-03-05. Owner: project supervisor.