Gantt Chart Planner

What this tool does

CM8-238 turns a list of tasks into a Gantt chart. Enter each task with a short ID, an owner, a start and an end date, what it depends on and how far along it is; the tool draws the bars, fills them to percent complete, marks today, finds the tasks with no room left before their successors, and prints a schedule report. It runs inside this single file — no account, no upload, no network request of any kind.

What a Gantt is, and what it is not

A Gantt chart is a communication and sequencing tool. Its value is that it forces people to agree, in public, on what happens before what, who does each piece and roughly when. Half the arguments a project needs to have surface while somebody is drawing the bars.

What it is not is a prediction, and that is worth being blunt about, because a Gantt chart is unusually good at looking authoritative. The bars are crisp, the dates precise to the day, the percentages carry decimals — and every one of those numbers came out of somebody's head. The finish date is arithmetic performed on estimates, and arithmetic does not make an estimate more accurate, only more certain-looking. The specific limits of a chart like this one: it assumes work starts the moment its predecessor finishes, which assumes the person is free — nothing here levels resources. It counts calendar days, not working days. It knows only the dependencies you typed, and the one that wrecks projects is usually the one nobody wrote down. And it treats the plan as a single line of best guesses rather than a range; the gap between "12 days" and "9 to 20 days, most likely 12" is the gap between a schedule and a wish. None of that makes the chart useless — it makes it a model. Treat it as the current shared agreement, not a forecast.

Building the plan properly

Every task is a verb with an owner and a deliverable. "Foundations" is a heading; "pour the machine foundation — groundworks contractor — signed pour record" is a task. If you cannot say what will exist when it is finished, you cannot tell whether it is finished. One named owner per task, never a department.

Durations come from effort and availability, not optimism. Ask how many person-days of work there are, then how much of each week that person actually has. Six days of work from somebody who gives you two days a week is a three-week bar. The optional effort column records both numbers so you can see the gap, which is where most schedules quietly fail — and the reverse case too, where a 28-day concrete cure is elapsed time with almost no effort in it.

Break work down until a task runs from a few days to a few weeks. Shorter and you are managing a to-do list; longer and you cannot tell it is off track until it is too late to act.

Dependencies, and why finish-to-start is usually enough

A dependency records that one task cannot begin until another has finished. List the predecessor IDs, comma-separated, in the depends on field: T3, T4 waits for both.

This tool models finish-to-start dependencies only. Scheduling software also offers start-to-start, finish-to-finish and start-to-finish links with lead and lag times; those are not modelled here. Finish-to-start covers the great majority of real links — you cannot install the machine until it is delivered, or commission it until it is wired — and where you need an overlap, split the task in two or set the successor's start date directly. Nothing stops you starting a task before its predecessor ends; the tool reports negative slack, an honest way of saying the plan contradicts itself. Record real constraints, not habits: "we always do it in that order" is not a dependency.

Slack, and the chain that actually sets the finish date

Subtracting the one day makes slack read correctly: a successor starting the very next morning leaves zero slack, because a single day of delay pushes it.

Tasks with zero or negative slack are drawn red, and together they form a chain running through the plan. That chain determines the finish date: slip any task on it by a day and the whole project moves by a day, while a task with fifteen days of slack can drift for a fortnight and change nothing. This is the critical path idea in plain language, and it tells you where to put your attention and your contingency.

Be clear about the simplification. The tool computes slack directly from the dependencies you entered: for each task, how far away is the earliest start of anything waiting on it. It does not run a full critical-path network analysis — no forward and backward pass, no early and late dates, no total and free float, no rescheduling. Tasks with no successors show "—". If your dependency list is incomplete, the red chain is incomplete too.

Reporting progress honestly

Percent complete is the most abused number in project management. It is self-reported, unverifiable, and under gentle pressure it drifts upward: a task is 50% done for a week, 80% for three weeks, then 90% for a month. The reason is not dishonesty. On most work there is no way to measure how much is left, so people report time spent, and that correlates poorly with how close the thing is to finished. The practical answer is to make the number carry as little weight as possible: break work down until 0% and 100% are the only figures you need. Binary reporting cannot drift, and twenty short tasks with eleven genuinely closed tell you more than five long ones averaging 64%. Where you must estimate, anchor it in something countable — eight of twelve panels wired. And define "done" before the task starts, review and sign-off included.

The expected % column gives that figure something to argue with: it is how far through its own calendar window a task is today, so one halfway through its dates should be around 50%. The health column compares the two within a tolerance you set on the Settings tab. It is a rough test — a task that waits three weeks for a delivery then finishes in two days reads Behind for most of its life and is fine. Use it to decide what to ask about, not who is failing.

Milestones

A milestone is a point in time with no duration: a decision, a handover, a delivery, an approval. Set the type to Milestone and give it the same start and end date — the tool insists on that, and draws a diamond rather than a bar. Good milestones are events somebody would notice happening: "machine delivered to site", "handover certificate signed". Bad ones are progress fractions dressed up as events; "design 50% complete" is a percentage with a date stapled to it.

Updating the plan, and the discipline of re-baselining

Update weekly, at a fixed time. Walk the Attention table — overdue, blocked, behind or zero slack. For each, the question is not "how is it going" but "what is the new end date and what does it move". Then update percent complete, close what is finished and add what has appeared.

What separates a useful plan from a decorative one is what you do when dates slip. The temptation is to quietly drag the bar right and say nothing, so the chart always looks current. Do that a few times and the plan stops meaning anything: it records where things are, which you already knew, rather than where they were supposed to be. Instead, re-baseline deliberately. Export the current file and keep it — that dated export is your record of what was promised — then rebuild the dates and say so out loud, with the reason. A project with three declared baselines is well managed; one on its eleventh silent slip has no plan at all.

Reading the timeline

• The dashed today line. Every bar it passes through should be partly filled. A bar today has crossed with no fill is work that should have started and has not.
• Bars ending left of today that are not green. One overdue task on the zero-slack chain matters more than five with weeks of float.
• Bars that have not moved between updates. A fill identical seven days later means the task is blocked or not being worked — and the chart will not tell you which.
• The delivery profile. If most finishes pile into the final month, the risk has been pushed to the end, where there is no time left to absorb it.

FAQ

Can I plan more than one project in the same file? Yes. Enter the project name on each task; dependencies and slack resolve within a project, so IDs need only be unique inside one.

Why does a two-day task show three days? Duration counts both the start and the end day, so Monday to Wednesday is three days.

Does it skip weekends and holidays? No — it counts calendar days and has no idea which days you work. Allow for non-working days when you choose the end date.

Why is slack blank on some tasks? Nothing depends on them, so there is no successor to measure against.

Saving your work

Tasks, settings and the report header are written to this browser's local storage as you type. That storage belongs to one browser on one computer, so another browser or a tool that clears site data will not have it. Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere, and the way you keep a baseline. Export CSV gives you the task list for spreadsheet work. Reset erases everything, with no undo.

Accuracy & disclaimer

The arithmetic is simple and the tool does it faithfully: durations, elapsed calendar progress, slack from the dependencies you recorded, and a weighted average of percent complete. Everything that decides whether the plan is any good sits above that arithmetic — whether the task list is complete, the durations realistic, the dependencies the real ones, and the progress figures honest. The tool does not run a full critical-path network analysis, does not level resources, models finish-to-start links only, and counts calendar days rather than working days. It is a planning aid, not a forecast and not a commitment.