Every project plan starts the same way: as a few sentences. “We’re launching the new site in six weeks — design first, then build, content can overlap with build, and we need a week of QA before go-live.” That’s a real plan. It has phases, an order, a deadline. What it doesn’t have is a shape anyone can point at in a meeting.
A Gantt chart is that shape — bars on a calendar, one per task, arranged so you can see what happens when and what’s waiting on what. Getting from the sentences to the chart is the part most people dread, and it’s why so many plans stay trapped in someone’s head. It doesn’t have to be painful. Here’s the whole process, whichever tool you end up using. (Not sure a timeline is even the right shape for your plan? Start here — it’s one question.)
The four things every timeline needs
However you make the chart, it’s built from the same four ingredients. If your plain-English description contains them, the chart almost draws itself:
- Tasks — the chunks of work, named the way your team actually talks about them. “Design,” “Build,” “Taste-testing photos.” Five to twelve is the sweet spot; past twenty you’re writing a to-do list, not a timeline.
- Durations — how long each chunk takes. Rough is fine. “About two weeks” beats a falsely precise “11.5 days” that nobody believes anyway.
- Dependencies — what can’t start until something else finishes. This is the ingredient people skip, and it’s the one that makes a chart worth reading. “Build starts when design is done. Photos can happen during build.”
- Milestones — the moments that matter to people outside the work: the launch, the review, the handoff. A milestone is a diamond on the chart and a date in an email.
Notice that all four fit comfortably in spoken English. You already say things like this out loud. The whole trick of planning is writing down what you’d say. (And when someone in the room reaches for the certified vocabulary — critical path, slack, finish-to-start — the plain-English glossary translates.)
Write the paragraph first
Before you open any tool, write your plan as one short paragraph. Not bullet points — a paragraph, with the ordering words left in: first, then, while, once, by.
First two weeks: design. Then three weeks of build — content writing can overlap with the second half of build. Once build and content are both done, one week of QA. Launch by March 28.
Those ordering words are your dependencies. “Then” is a finish-to-start link. “While” and “overlap” are parallel tracks. “Once X and Y are done” is a merge. “By March 28” is a milestone with a deadline. A paragraph like this is a complete project plan in about fifty words — everything after this step is just rendering.
Three ways to render it
The spreadsheet way. List tasks down column A, dates across row 1, and fill cells to make bars. It works, and everyone’s done it once. The problem shows up on Tuesday when the design phase slips two days and you’re re-coloring forty cells by hand. Spreadsheets store the picture of a plan, not the plan — they don’t know your bars are connected. (If the spreadsheet is where your team lives anyway, we wrote the honest guide to Gantt charts in Google Sheets — three methods, exact formulas, and the limits.)
The project-management-suite way. Heavyweight PM tools make excellent Gantt charts and will happily manage resources, budgets, and burndown too. If you run a twenty-person program, that’s your answer. If you need a timeline for a six-week project, you’ll spend more time setting up the tool than doing the plan — and everyone you share it with needs an account and a tutorial.
The plain-English way. This is the gap ganttchart.ai exists to fill: paste in the paragraph you wrote above and it comes back as a real chart — tasks, durations, dependencies, and milestones on a proper timeline, in seconds. The AI writes the first draft; you stay the editor. Drag what it got wrong, rename what it guessed at, and share the result as a link with no accounts on either end. We built it because we kept writing that paragraph and resenting every tool that made us re-type it as form fields. (The full story is in the case study.)
The mistakes that sink timelines
We’ve drawn a lot of these charts, for our own projects and everyone else’s. The failures are predictable:
- No dependencies. A chart where every bar starts on day one isn’t a plan, it’s a wish. If nothing on your chart is waiting on anything else, you haven’t finished thinking.
- Too many tasks. The chart is for the room, not the worker. “Design” is one bar even if it’s forty tickets. Detail lives in your issue tracker; the timeline earns its keep by being readable at a glance.
- No slack. If the plan only works when nothing slips, the plan doesn’t work. Give the bars room to breathe — or at least put the milestone a week after the last bar ends and don’t tell anyone why.
- Treating the first draft as final. A timeline is a conversation starter. The moment it meets reality it will be wrong somewhere; the question is whether your tooling makes the correction cost thirty seconds or thirty minutes. Cheap edits are the difference between a chart people update and a chart people quietly stop believing.
Ten minutes, start to finish
That’s genuinely the budget. Write the paragraph (three minutes — you already know the plan). Render it (seconds, if the tool meets you where the plan already is). Adjust the two bars the first draft got wrong (two minutes). Share the link. You still have five minutes before the meeting — which, not coincidentally, is exactly the moment we designed for.
If you’d rather start from a finished chart than a blank page, we keep five worked Gantt chart examples — a website launch, a product launch, an app MVP, a house move, and a meetup — each with the exact prompt that generates it.