Mission Goal
Create a simple Gantt-style project plan for your mission build, from “today” to “demo day”. Your plan must show dependencies across teams and include checkpoints that catch problems early.
Why it matters
Space projects are not “a big to-do list”. They are a network of dependencies. A project manager makes sure the right work happens in the right order, with proof at each stage.
Inputs from other teams
- Payload/Build: build steps, parts constraints, and test requirements.
- Comms: when comms must be tested and what “link works” means.
- Data/Telemetry: what data must be collected and how it’s verified.
- Launch/Platform: integration deadlines and physical constraints (power, mass, mounting, handling).
What you must produce (deliverables)
- One-page Gantt plan (hand-drawn or digital): tasks, owners, and dates/sessions.
- Dependency map: at least 6 dependencies (“Task B cannot start until Task A passes”).
- Definition of Done for at least 6 tasks (what evidence proves completion).
Step-by-step
- Pick your horizon: plan for the next 2–6 sessions (or up to your demo date).
- List tasks: keep them chunky (10–20 tasks max).
- Assign owners: one owner per task (a person or a team).
- Mark dependencies: draw arrows or write “depends on…”.
- Add gates: at least 3 “proof points” (e.g., “payload bench test passed”).
- Define Done: for each gate, specify evidence (photo, log file, screenshot, checklist).
- Risk-check your plan: find one task that could slip and add a buffer or fallback.
Success criteria
- Your plan has clear dependencies and doesn’t assume parallel work that can’t happen.
- At least 3 checkpoints stop you from discovering failure at the last minute.
- “Done” is measurable (not “it works”, but “we have this proof”).
Evidence checklist
- Photo/export of the Gantt plan.
- Dependency list (6+ items).
- Definitions of Done (6+ tasks).
- One short retro note: “What did we schedule earlier than we first thought?”
Safety & ethics
- Never schedule unsafe steps without supervision (tools, heat, cutting, batteries).
- Build in time for safe testing; don’t compress safety to “if time”.
- Be honest with evidence: don’t mark tasks done without proof.
Common failure modes
- Fantasy parallelism: assuming two tasks can run at once when they share the same people/tools.
- No integration time: “It worked on our bench” isn’t the same as “it works together”.
- Vague Done: tasks get “completed” without any measurable evidence.
- No buffers: one slip breaks everything.
Stretch goals
- Add a critical path highlight: which tasks, if delayed, delay everything.
- Add a fallback plan (Plan B mission outcome) if a major dependency fails.
- Add a “comms window” task: when your team gives updates to everyone else.
Scaffolding Example (optional)
You are allowed to reuse structures and formats from other teams — but not their decisions.
Example: Decision tree for anomalies
- If rocket/payload looks unsafe → Abort and reset.
- If data is missing but safety is OK → Hold for troubleshooting.
- If everything is safe and ready → Go to countdown.
Example: “Hold” checklist
- Call “HOLD” loudly. Freeze movement near the pad.
- Confirm safety perimeter intact.
- Identify cause (leak? loose fin? sensor not logging?).
- Fix one issue only, re-inspect, resume poll.
Example: Post-mission debrief prompts
- What surprised us? What failed first? What should we standardise?