Most project failures aren't from bad planning. They're from planning that's too elaborate to survive contact with real work. To plan a project from scratch, you need six things written down in plain language: the outcome you want, the deadline, the top three risks, the first concrete action, the second and third actions, and a weekly check-in with yourself or your team. That's it. That's a real project plan. Gantt charts, work breakdown structures, and RACI matrices are useful for 40-person cross-functional efforts. If you're a solo operator or a small team, they're process theater that eats time you could spend building. Below is a minimum-viable planning method that survives real-world chaos and finishes projects.
What "planning a project" actually means
Project planning is the act of turning "I want to do this thing" into "I know the next three moves and when I'll check whether I'm still on track." Not a document. A decision state.
The reason most personal projects (side businesses, home renovations, learning a skill, writing a book) fail isn't lack of planning. It's the wrong kind of planning. People spend three weeks in Notion designing the perfect project structure and then never do the actual work. The document becomes a proxy for progress. This is the number one solo-project killer, and it's why anti-methodology approaches (like Rework by Jason Fried and DHH, or the "smallest testable thing" ethos of lean startup) exist as a corrective.
Your goal in planning is to reduce uncertainty just enough to start, then let real work generate more information than any planning document ever could.
The 6-step minimum viable plan
Step 1: Write the outcome in one sentence. "Ship a working prototype of the reservation app by October 15." Not "improve customer experience." Not "explore opportunities in the reservation space." A specific artifact, done by a specific date. If you can't write this in one clean sentence, you don't have a project yet — you have a vibe. Fix that first.
Step 2: Write the top three risks. Not fifteen. Three. What are the most likely reasons this project fails or slips? For a side project, common answers: "I run out of motivation by week 3," "I discover the tech is harder than I thought," or "life gets busy and I stop showing up." Naming risks up front is 80% of managing them. You now know what to watch for.
Step 3: Break the outcome into 3-5 milestones. For the reservation app: (1) design flow sketched, (2) backend live and testable, (3) frontend wired, (4) private beta with 5 users, (5) public launch. Each milestone should be a real inspection point — something you or a stakeholder can look at and say "yep, that's real progress." Not "did some work on backend."
Step 4: Write the first concrete action. Not "start on Milestone 1." A specific, physical, next action. "Open Figma and sketch the reservation flow — 45 minutes." The kind of action you could do right now if you had 45 minutes. This is Allen's GTD "next action" concept applied to project starts — the most common project-death moment is the ambiguity between "I have a project" and "I know what to physically do first."
Step 5: Write the next 2-3 actions after the first. Just enough to see the immediate path. Don't plan the whole project — you don't have enough information yet. Planning past 2-3 actions in a genuinely new project is a waste of your planning energy because reality will invalidate half of it by week 2.
Step 6: Schedule the weekly check-in. Same day, same time, every week, on your calendar. In the check-in you ask three questions: What did I ship this week? What am I shipping next week? What just changed that I need to plan around? Ten minutes. Written in the same document as the plan.
That's the whole plan. Six sections, maybe one page. If it takes more than 45 minutes to write, you're overthinking.
The specific twist most planning advice misses
Planning is not a one-shot activity. It's a rhythm. The weekly check-in is the load-bearing beam of any real project — without it, your plan goes stale within two weeks and stops matching reality. The plan document is a living record of what you thought at the moment of planning; the check-in is where you update it against what actually happened.
The other missed twist: the first milestone should be reachable in one week or less. Not one month. One week. If your first inspection point is 30 days out, you'll drift. If it's 5-7 days out, you'll create real momentum by hitting a visible thing early. Reforecast from there. This is why lean startup methodology insists on "shortest possible cycle to real feedback" — the same logic applies to solo projects.
How to plan a project when you don't know what you don't know
Some projects have huge unknown-unknowns. You're building something you've never built. You're launching in a market you don't understand. Traditional planning breaks down here because the plan you write on day 1 is wrong on day 8.
The fix: plan the learning, not the outcome. Your first milestone isn't "ship the thing." It's "answer the biggest unknown." For a new business: "run three customer interviews and validate the top pain point." For a new technical project: "build the smallest possible spike that proves the core assumption works." For a book: "write one chapter and see if it holds up."
You reduce risk not by planning harder but by shrinking the loop between plan and learning. Each learning cycle makes the next round of planning more accurate. This is how research projects, startups, and creative work all actually get done — not through better upfront plans but through faster iteration on smaller unknowns.
What to skip and what to keep
Skip these unless you're managing 5+ people or a $100k+ budget: - Gantt charts (over-plan tools that make you feel productive without producing anything). - Detailed work breakdown structures. (Overkill for solo work.) - Risk registers with likelihood/impact scoring. (Three named risks in a sentence each is plenty.) - RACI matrices. (Only useful when you have >5 stakeholders per task.)
Keep these even for a one-person project: - The one-sentence outcome + deadline. - The three risks. - The next 2-3 concrete actions. - The weekly check-in.
The Chillcore approach
Chillcore doesn't do project planning — there are already 40 tools for that. What Chillcore does is fix the moment when the plan is written, the first action is clear, and you still don't do it. That's not a planning problem; that's an avoidance problem. You name the task you're avoiding and Chillcore makes life mildly unbearable until it's done, using Coach, Drill Sergeant, or Demon (18+) tone. If you're stuck in the planning-forever loop where you keep restructuring your Notion doc instead of shipping, Coach mode is designed for exactly that pattern. If your problem is genuinely that you don't know what to do, skip us and read this pillar first.
Related reading
- How to Plan Your Week: A 20-Minute Sunday Ritual That Actually Works
- Task Prioritization: 4 Methods Ranked by How Well They Actually Work
- The Getting Things Done (GTD) Method in Plain English
- The task planning pillar: how to actually plan and finish what you start
Frequently asked questions
Q1: What tools do I need to plan a project?
A: Whatever you already use. A Google Doc, a plain text file, a notebook, or Notion — all fine for a one-page plan. The mistake most people make is spending a week picking the perfect project management tool before they've written the plan. Write the plan in whatever's fastest, then decide if you need a tool. For solo projects, you usually don't. For team projects, use whatever your team already runs. Adopting a new tool just for one project creates friction that kills the project before the tool starts helping.
Q2: How detailed should my project plan be?
A: Just detailed enough to know what to do next and what "done" looks like. Anything more is speculation. A useful test: if you couldn't sit down right now and execute the first three items on your plan without asking anyone anything, the plan isn't detailed enough. If you have a 40-page Gantt chart mapping every week for the next four months, it's too detailed and will be wrong by week 3. Aim for one page for solo projects, up to five pages for small-team projects.
Q3: How do I stay on track after I plan the project?
A: The weekly check-in is the single most important tactic. Same day, same time, every week, non-negotiable. In it, you compare what you shipped to what you planned to ship, note what changed, and adjust the plan. Without this ritual, your plan goes stale within two weeks and you're back to working from vibes. The other tactic: keep the plan document open in a browser tab you see every day. Out of sight, out of mind is a real force. Projects that live in a bookmark you never visit die quietly.
Written for Chillcore — the app that won't let you chill. Try Coach mode free →