Gantt Chart Builder

# Gantt Chart Builder (GanttProject) — Lab 1 (Beginner) **Tool:** Gantt Chart Builder — in-house timeline simulator **Tool key:** `ganttproject` **What the simulator actually gives you:** a form with three fields — task name, start day, and duration (in days) — an "+ Add Task" button, a horizontal bar chart that renders each task as a proportional bar positioned by its start day, double-click on a task's label to delete it, and a "Save This Chart as a Project" button. There is no built-in dependency field and no automatic critical-path calculation — both of those are things *you* simulate by choosing start days deliberately and reasoning about the chart yourself. There's also no in-place edit: to change a task, you delete it and re-add it with new values. **What you're practicing:** timeline planning and sequencing dependent tasks — the foundational skill everything later in this series builds on. **Estimated time:** 20–30 minutes **Prerequisites:** none — this is the entry point for the tool. --- ## Setup 1. Click **Open** to launch the builder. You'll see three sample tasks already on the chart (Requirements gathering, Design, Build) — leave them for now, you'll replace them shortly. 2. Pick a small project you understand well enough to sequence from memory. A hobby project works fine. Examples if you're stuck: "Plan a weekend trip," "Launch a personal blog," "Bake a layered cake for a party." 3. Since the tool has no dependency field, decide now that you'll simulate dependency the only way this tool allows: **by setting a task's start day equal to the day its predecessor finishes.** Keep that rule in mind for every task you add. --- ## Step-by-step 1. **Clear the sample tasks.** Double-click each task's label (Requirements gathering, Design, Build) and confirm deletion. Start from an empty chart. 2. **List out the tasks for your project, in the order they need to happen.** Write this list somewhere outside the tool first — 6–8 tasks is plenty for a first pass. Real timeline planning starts with a sequence in your head, not with bars on a chart. 3. **Give each task a rough duration**, in days, based on how long it would realistically take. Don't worry about precision — a rough gut estimate is exactly what real early-stage planning uses too. 4. **Add your first task starting at day 0.** Use the form: task name, start = `0`, duration = your estimate. Click **+ Add Task**. 5. **Mark which tasks depend on others finishing first**, and add them accordingly. For any task that can't start until an earlier one is done (you can't design before you've gathered requirements, you can't ice a cake before you've baked it), set its **start day equal to the previous task's start day plus its duration.** For example, if "Gather requirements" starts at day 0 with a duration of 3, "Design" should start at day 3. 6. **Add every task from your list this way, one at a time**, always calculating the start day from whatever it depends on. For tasks that *don't* depend on anything finishing first (they could happen anytime, or in parallel with something else), give them a start day that reflects that — they don't have to wait. 7. **Look at the resulting timeline.** Is anything longer than expected? Does one bar dominate the chart? Is there an obvious point where several bars all seem to funnel through one task? 8. **Save your chart.** Click **Save This Chart as a Project** and give it a specific, descriptive title (e.g. "Weekend Trip — Timeline v1"), not something generic like "My Chart." --- ## Reflection (write 2–3 sentences) - Which task turned out to be the biggest single chunk of time on your chart? - Was there a task you initially assumed had no dependency, but realized while building the chart that it actually needed to wait on something? --- ## Success checklist - [ ] Chart has 6–8 tasks, each with a name, start day, and duration - [ ] At least 3 tasks have start days calculated from a predecessor's start + duration (not just guessed) - [ ] At least one task's start day reflects that it *doesn't* depend on anything finishing first - [ ] One sentence written identifying the longest or most central task on the chart - [ ] Chart saved with a specific, descriptive title **Tip:** real projects usually have one task that everything else waits on — find yours and think about how you'd shorten it. You won't fully solve that problem in this lab (that's Labs 2 and 3), but starting to notice it now is the habit worth building early.

# Gantt Chart Builder (GanttProject) — Lab 2 (Intermediate) **Tool:** Gantt Chart Builder — in-house timeline simulator **Tool key:** `ganttproject` **Building on Lab 1:** you built one timeline with simulated dependencies. Now find the sequence that actually controls your project's end date — the critical path. **What you're practicing:** identifying a critical path by reasoning about the chart yourself (the tool has no automatic calculation), and confirming it with a real test rather than a guess. **Estimated time:** 35–45 minutes **Prerequisites:** Lab 1 (or comparable familiarity with adding tasks, calculating start days from dependencies, and reading the chart). --- ## Setup 1. Click **Open** to launch a fresh chart, or reopen your Lab 1 project if the tool allows continuing it — otherwise start clean. 2. Choose a project big enough to need **at least 8 tasks**, with real dependency chains between several of them — not just one long straight line. Examples: a website relaunch, a small home renovation, planning a multi-day event. 3. Remember the tool's constraints going in: no in-place edit (delete and re-add to change a task), no automatic dependency or critical-path logic — every start day is something you calculate and enter by hand. --- ## Step-by-step 1. **Build a timeline with at least 8 tasks and real dependencies between several of them.** Plan the full list and each dependency relationship outside the tool first, then enter tasks with start days calculated the same way as Lab 1 (a dependent task's start = predecessor's start + predecessor's duration). Make sure at least two tasks can run in parallel — i.e., two different tasks that both depend on the same earlier task finishing, but don't depend on each other. 2. **Trace the longest chain of dependent tasks from start to finish.** Follow the chain of tasks where each one's start day is set by the one before it, all the way from day 0 to the day your project actually ends (the highest `start + duration` value on the chart). That chain is your **critical path.** 3. **Write down which tasks are on that chain**, in order, before moving on. You'll need this list for the next two steps. 4. **Confirm it with a real test, not just a guess: pick a task NOT on your critical path** — one that has slack, meaning something else on the critical path is still running while it happens. Delete it and re-add it with **more duration** than before (add several days). Ask yourself: does the project's end date move? It shouldn't — because nothing on the critical path depended on that task's finish time. 5. **Now do the opposite test: pick a task that IS on your critical path.** Delete it and re-add it with more duration. This time, manually recalculate and re-enter the start day for every task downstream of it on the critical path — since the tool won't cascade the change for you, you have to do it by hand, task by task, in order. Confirm the end date now DOES move by exactly the amount you added. 6. **Identify which single task on your critical path is the biggest single chunk of time.** That's your best target for shortening the whole project — not the biggest task overall, specifically the biggest one that's *on the chain controlling the end date.* 7. **Save your chart with a note identifying your critical path.** Since there's no dedicated notes field, add the note as part of your project title or as a description you keep alongside it, e.g. "Website Relaunch — Critical Path: Requirements → Design → Build → QA → Launch." --- ## Reflection (write 3–4 sentences) - Which tasks ended up on your critical path — did that match your instinct before you traced it, or did it surprise you? - What was different about updating a critical-path task (cascading the change downstream) versus a non-critical one (no cascade needed)? - Which single task would you target first if you had to shorten this project by a few days, and why that one specifically? --- ## Success checklist - [ ] Chart has at least 8 tasks with real dependency chains, including at least one pair of tasks running in parallel - [ ] Critical path traced and written down as an ordered list of tasks - [ ] Confirmed: adding duration to a non-critical-path task did NOT move the end date - [ ] Confirmed: adding duration to a critical-path task DID move the end date, with downstream tasks correctly recalculated - [ ] One task identified as the best target for shortening the overall project - [ ] Chart saved with the critical path noted in the title or an accompanying note **Tip:** shortening a task that ISN'T on the critical path never speeds up the overall project, no matter how much time you save on it — always check the critical path before "optimising" any one task. This is the single most common mistake in real-world timeline planning, and the entire point of this lab is to make you feel it happen once, on purpose, so you recognize it instantly later.

# Gantt Chart Builder (GanttProject) — Lab 3 (Expert) **Tool:** Gantt Chart Builder — in-house timeline simulator **Tool key:** `ganttproject` **Building on Labs 1–2:** you built a timeline, then found its critical path. Now practice the skill real project timelines actually get used for — reacting to a delay. **What you're practicing:** replanning around an unexpected delay: tracing its downstream impact, deciding on a real mitigation, and communicating the change the way a project coordinator would to a stakeholder. **Estimated time:** 45–60 minutes **Prerequisites:** Lab 2 (this lab assumes you can trace a critical path and manually cascade start-day changes; a fresh 8+ task timeline is fine if you'd rather not reuse Lab 2's). --- ## Setup 1. Open your Lab 2 timeline if you still have it, or build a fresh one to the same standard: at least 8 tasks, real dependency chains, at least one pair of tasks running in parallel. 2. This lab has two deliverables: **(a)** an updated chart reflecting your replanning decision, and **(b)** a short written replanning note. Budget time for both. 3. Recall the tool's constraints: no in-place edit (delete + re-add to change any task), no automatic recalculation — every downstream start day you update is done by hand, in order. --- ## Step-by-step ### Part A — Re-establish the baseline 1. **Take your Lab 2 timeline (or build a fresh 8+ task one) and identify its critical path again.** Write it down as an ordered list of tasks, the same way you did in Lab 2 — you need a clean "before" state to compare against once the delay hits. ### Part B — Simulate the delay 2. **Simulate a realistic delay: add several extra days to one critical-path task, as if it hit an unexpected problem.** Pick a task partway through your critical path, not the very first or very last task — delays in the middle of a project are the ones that actually test your replanning skill, since they have both upstream history and downstream consequences to manage. Delete that task and re-add it with the extra duration. 3. **Trace how that delay pushes every dependent task after it.** Starting from the delayed task, walk downstream through your critical path (and any parallel branches that were relying on it) and manually recalculate each one's new start day. Delete and re-add each affected task with its corrected start day, in order — don't skip ahead, since each one depends on the corrected value of the one before it. 4. **Note the new project end date** once every downstream task has been updated. Compare it to your original Lab 2 end date — the difference is the size of the delay's actual impact, which may be larger or smaller than the raw number of extra days you added, depending on how much slack existed elsewhere in the chain. ### Part C — Decide on a response 5. **Decide on a response: can any later task be shortened, run in parallel instead of after, or is the end date simply going to move?** Consider each option honestly: - **Shorten a later task** — delete and re-add it with reduced duration, if that's realistic for the task (cutting scope, adding resources, accepting more risk). - **Run something in parallel instead of after** — if a later task doesn't strictly need the delayed one to finish first, question whether you modeled that dependency correctly in the first place. Give it an earlier start day that reflects it running alongside something else instead of waiting. - **Accept the new end date** — sometimes there's no honest way to claw back the time, and pretending otherwise is worse than just accepting and communicating the new date. Pick one of these (or a combination) and **justify your choice in a sentence** before updating anything further. 6. **Update the chart to reflect your decision and the new resulting end date.** If you chose to shorten or parallelize a task, delete and re-add it with the new values, then re-cascade any tasks that depend on *it* the same way you did in step 3. ### Part D — Communicate the change 7. **Write a 2–3 sentence "replanning note" as if explaining the change to a stakeholder:** what happened, what you did about it, what the new date is. Keep it concrete and free of jargon — a stakeholder wants to know what changed and what it means for them, not the mechanics of how you recalculated it. *Example shape:* "Design sign-off ran 4 days over due to an extra approval round. We're running QA and documentation in parallel instead of sequentially to recover 2 of those days. New launch date: [date], 2 days later than originally planned." 8. **Save your finished chart and note as your final project for this tool.** If there's no dedicated notes field, add the replanning note as part of your project title or as an accompanying description saved alongside the chart. --- ## Reflection (write 3–5 sentences) - How much of the delay did your mitigation actually recover, if any — and was that a realistic amount, or optimistic? - Which was harder: correctly tracing the downstream impact of the delay, or deciding on and justifying a response to it? - If you had to do this again for a real project, what would you want the tool to do automatically that you had to do by hand here (e.g. auto-cascading start dates)? --- ## Success checklist - [ ] Original critical path re-established and written down as a baseline - [ ] Delay simulated on a critical-path task partway through the chain (not the first or last task) - [ ] Every downstream task's start day manually recalculated and updated, in order - [ ] New project end date identified and compared against the original - [ ] A response chosen from shorten / parallelize / accept, with a one-sentence justification - [ ] Chart updated to reflect the chosen response and its new end date - [ ] Replanning note written (2–3 sentences, stakeholder-facing, states what happened / what was done / new date) - [ ] Final chart and note saved together **Tip:** real project plans are rarely "predict once, then follow perfectly" — practicing how you REPLAN after a delay is a far more useful, realistic skill than practicing the first draft of a timeline. A project coordinator who's good at building a clean initial Gantt chart but freezes the first time something slips is far less valuable than one who's calm and methodical about the second version.