A Project Kickoff Plan That Survives Reality

A PROJECT KICKOFF PLAN — TEMPLATE + WORKED EXAMPLE ==================================================== PART 1 — THE TEMPLATE (fill in the blanks) 1. SCOPE - What we are building (one sentence, no adjectives). - What is explicitly IN (features/artifacts). - What is explicitly OUT (non-goals — this prevents scope creep). - Definition of done: the single measurable outcome that ends the project. 2. CONSTRAENTS - Time budget (calendar + total hours). - Money budget (if any). - Team size / who is actually available. - Hard limits: tech stack, platform, licenses, availability of people/gear. 3. MILESTONES (each = a shippable artifact, not an activity) - M1 ... M4, each with: what ships, by when, and the exit test ("it's done when..."). 4. DECISION OWNERS (one name per decision area — no consensus-by-default) - Product/scope decisions: X. - Technical/design decisions: Y. - Money/spend decisions: Z. - Tie-breaker / final call: X. 5. RISKS (top 3-5, each with: likelihood, impact, and a pre-agreed mitigation) - Format: Risk | L/M/H probability | L/M/H impact | Mitigation. 6. WEEKLY CADENCE (fixed rhythm, same day/time every week) - Monday: async status update (everyone posts 3 lines: done / blocked / next). - Wednesday: 30-min sync call (decisions only, not status). - Friday: demo of the week's artifact + retro (one thing to keep, one to change). 7. FIRST-WEEK PLAN (day-byday, tiny tasks, no task longer than ~2 hours) - Day 1: setup repo/workspace, write the one-sentence scope somewhere visible. Day 2: spike the hardest unknown (the thing you don't know how to do yet). - Day 3: build the thinnest vertical slice end-to-end. - Day 4: get one real user/feedback pass on that slice. - Day 5: fix the top 3 feedback items; update the plan if reality disagrees with it. ==================================================== PART 2 — CONCRETE EXAMPLE Project: "Pantry" — a tiny web app that tells you what to cook from what's already in your fridge. 1. SCOPE - Build: a single-page web app where you enter fridge items and it suggests 3 recipes you can cook with them. - IN: item entry, recipe suggestions, "mark item used" flow, mobile-friendly layout. - OUT: user accounts, grocery lists, nutrition tracking, mobile apps, any AI/ML — recipes come from a hardcoded local list. - DONE when: a non-technical friend enters 5 random fridge items and gets a usable recipe suggestion in under 10 seconds, on their phone. 2. CONSTRAINTS - Time: 4 weeks total, ~5 hours/week per person. - Money: $0 — free tier hosting only. - Team: 2 people (Alex: code; Sam: design + testing), both part-time. - Hard limits: plain HTML/CSS/JS, no build toolchain, no backend — everything runs client-side. Recipes stored as a static JSON file. 3. MILESTONES - M1 (Week 1): Static page renders + recipe list loads. — Exit test: open index.html in a browser, see 20 recipes. - M2 (Week 2): Item entry + matching logic works. — Exit test: enter "egg, flour, milk" → 3 recipes shown. - M3 (Week 3): "Mark used" flow + mobile layout. — Exit test: full flow works on a phone, no horizontal scroll. - M4 (Week 4): Friend-test pass + polish + deploy. — Exit test: the DONE criterion above passes. 4. DECISION OWNERS - Which recipes make the list, wording, UX: Sam (final). - Matching logic, code structure, hosting: Alex (final). - Any spend (should be zero): Alex. - Tie-breaker on scope changes: Sam — and the rule is: if it doesn't fit in the 4 weeks, it goes to the OUT list. 5. RISKS - Recipe list too small → suggestions feel useless | M | H | Mitigation: seed 40 recipes in week 1, not 20. - Matching logic too naive (exact-match only) → no suggestions | M | M | Mitigation: allow "any one ingredient missing" from day 1. - Scope creep (accounts, lists) | M | H | Mitigation: every new idea goes to a parking-lot file; reviewed only at week 3 retro. - One person drops out mid-project | L | H | Mitigation: both know the whole codebase; no silos. 6. WEEKLY CADENCE (every week, same slots) - Mon 09:00 — async status: each posts done / blocked / next (3 lines, no meetings). - Wed 12:00 — 30-min sync: decisions only (e.g. "do we fuzzy-match or not?"). - Fri 16:00 — demo of that week's milestone + 2-minute retro: keep one thing, change one thing. 7. FIRST-WEEK PLAN (Alex + Sam) - Day 1: Alex scaffolds index.html + loads recipes.json; Sam writes the first 20 recipes and the one-sentence scope pinned to the repo README. - Day 2: Spike the matching logic on paper + in console — figure out the "one missing ingredient" rule before any UI. - Day 3: Thin vertical slice: enter 3 items → see 3 suggestions. Ugly is fine. - Day 4: Sam walks a friend through it; capture 5 raw reactions, no fixes yet. - Day 5: Fix the top 3 feedback items; if feedback says the concept is wrong, rewrite scope before week 2 starts. Rule of thumb for the whole project: every week must end with something someone can click. If a week doesn't, the plan is wrong — fix the plan, not the pace. Save this as a file if you want it editable: /home/hermeswebuitoo/workspace/kickoff-plan.md — say the word and I'll write it there.