Plan a project in stages, prove the risky part, and export a workbook that keeps working.
See the Method tab for how the pieces fit, and the Keyboard tab for every shortcut.
The mistake a first plan makes is pretending the whole thing is knowable on day one. It is not, and a plan that claims otherwise is wrong in a way nobody can see. So commit only the stages you can actually plan — real tasks, rough durations, named owners — and mark the later ones Outline. They stay on the page and on the Timeline as a shape, but the forecast finish, the critical path and the baseline stop at the committed work, and the report says what it left out. Nothing in an outline phase can be late, because nobody has promised it yet.
A new plan is a draft: it has no dates, and nothing gives it any until you ask. List the work, give each task a duration and say what it waits for, and leave the Start and End columns as the dashes they are. The critical path already answers from the durations, so you can see the chain before a single date exists; the baseline waits, because there is nothing to commit to yet. When the list is honest, the schedule bar offers two ways out. Schedule from durations shows you every date it is about to write, and from then on the dates follow the durations. Type the dates myself hands the columns to you and never moves them. A plan that dated every task the moment it was typed was answering a question nobody had asked yet.
Once scheduled, the dates fall out of what each task waits for. Pin a start date only when the date is real — a booked room, a vendor's delivery — and leave everything else to move when the work in front of it moves. Once a task has started, what actually happened outranks what was planned: the scheduler anchors on the real start, and a changed duration upstream cannot rewrite history.
Take the baseline when the committed work is agreed. It is the set of dates that “late” is measured against, and without one every date you move quietly becomes the new plan. Then, at the end of each stage, do the same thing again deliberately: commit the next phase, give its tasks durations, and re-baseline as a planned increment. When something slipped, re-baseline and say that instead. The report counts the two apart — “re-baselined 3 times (1 after a slip, 2 planned)” — so a plan built in stages does not read as a plan that keeps slipping, and a slip cannot hide inside a re-plan.
The list of open decisions is what the next stage is waiting on. Give each one an owner, a date to decide by, the options in play and what would settle it. Past its date, it turns the report amber like any other thing being carried. When the answer has to be found rather than chosen, that is a spike: make it a criterion on the proof of concept, test it, and point the decision at it with Informed by.
A phase has a goal at the top and a review at the end — what surprised you, and what the next stage does differently because of it. The review appears once the phase is finished, and it is the record the next wave is planned from. Write it before you re-baseline, not after.
Everything on the Report is derived from the rest of the project: the colour, the forecast, the slipped milestones, the open decisions. The only parts you write are the summary and the asks. If the colour is wrong, fix the plan; if you must override it, the derived answer still shows beside yours.
Everything is stored in your browser's sessionStorage, on this device and this browser only. Nothing is uploaded anywhere.
Coaching notes. The bordered notes throughout the app can each be dismissed with the × that appears when you hover them, and stay dismissed on this browser.
Every project exports on its own. Excel (.xlsx) is the version to circulate; Word (.rtf) and Markdown give you the status report as prose. For a backup you can load again, use Export project data, which writes a .pumapack file — drop one back onto the window to import it.
Danger zone. This erases every PumaPlanner record in this browser. Export a backup first.
Type DELETE EVERYTHING to confirm:
.pumapack backup of this project.pumapackPumaPlanner is for the person who has been handed a piece of work to run and has never been taught how. It holds the four documents that get asked for — a charter, a plan, a proof-of-concept result and a status report — and it takes the view that the useful part of project management is a small number of habits rather than a methodology: say what is out of scope, write success criteria that can come out against you, put exactly one name against each decision, and never write a status report by hand. It explains each of those where you meet it, then gets out of the way and exports something you can send to a sponsor.
PumaWorx is a suite of offline, single-HTML productivity apps that run entirely in your local browser. The entire suite is a personal, open source vibecoding project.