DoAssignment.ca

DoAssignment study guide

B1.4 · Plan a Software Project Timeline

Learn to track a project with a schedule or gantt chart through clear examples and targeted practice.

Ontario Grade 12 Computer Science

Software Development

ICS4U B1.4 — Track a project with a schedule or Gantt chart

A project plan is useful only if the team checks it as work proceeds. In ICS3U, you may have divided a programming project into tasks. Here, the focus is tracking those tasks with a schedule or Gantt chart. The examples use invented classroom projects and dates to show how to record progress; they are not estimates of how long real projects should take.

What you will learn

  • Explain how a schedule or Gantt chart helps a team track project work.
  • Compare actual progress with planned timing.
  • Record delays and agreed schedule changes clearly.

1. Review: tasks and planned timing

A project task is a piece of work the team can identify and check, such as drafting a page or reviewing a program. Before tracking starts, list the tasks and choose a consistent time scale, such as project weeks. For each task, record its planned start and finish.
A schedule records tasks and their planned timing. A Gantt chart presents that schedule visually: tasks are placed against a timeline, often as bars that cover their planned periods. The team can see which work is planned for each period and check how far the project has progressed.
A milestone is a notable point for checking progress, such as a completed draft. Use task names and milestone descriptions that make the work clear. “Finish the first draft” is easier to check than “work on project.”
  • List clear tasks and planned timing before tracking progress.
  • A Gantt chart shows task timing against a timeline.
  • A milestone marks a notable point for checking progress.

2. Compare the plan with actual progress

At a check-in, identify the current date or project period. For each task, find out whether it has not started, is in progress, or is complete. Record what has actually happened, then compare that status with the planned timing. A planned finish date does not mean the task is finished.
If a task is behind its planned timing, note the difference and communicate it to the team. Keep the original plan visible rather than quietly replacing dates. If the team agrees on a change, record the revised timing and make clear that it is a revision. When useful, include when the change was agreed.
A schedule or Gantt chart helps the team see what is complete, underway, and still ahead. It is a shared record for checking and discussion, not a guarantee that the project will finish on time.
  • Record status from observed work, not from planned dates.
  • Make delays and agreed changes visible.
  • Continue checking progress against the current plan.

3. Keep the tracking record useful

Use consistent time units and labels so that everyone reads the schedule the same way. If a task's status is unknown, find out rather than guessing. Mark work complete only when it is finished.
A simple tracking routine is: check the current period; review each task's actual status; compare that status with the plan; record any difference; and update the schedule if a change is agreed. The routine keeps the plan and the team's observations distinct.
A schedule can prompt a useful question: what needs attention now? It cannot answer every project question by itself. The team must discuss a delay and agree on any revised timing before treating it as the current plan.
  • Keep task labels, time units, and status descriptions clear.
  • Separate what was planned from what has happened.
  • Use check-ins to identify work that needs attention.

Worked example

Example 1: Check progress at a meeting

A team plans a four-week class website project: choose content in Week 1, create three page drafts in Weeks 2–3, and review the pages in Week 4. At the end of Week 2, content selection is complete and one of the three drafts is complete. What should the team record?
Website project: planned periods and Week 2 check
thenthenChoose content | plannedDraft 3 pages | plannedReview pages | planned W

Connected task stages show the planned sequence; labels distinguish the Week 2 status from the plan.

  1. Read the planned timing
    The plan places content selection in Week 1, drafting in Weeks 2–3, and review in Week 4. Those dates describe the plan, not proof that the work is complete.
  2. Record the observed status
    At the Week 2 check-in, content selection is complete. Drafting is in progress because one draft is finished and two remain.
  3. Keep future work visible
    The schedule should continue to show the planned Week 4 review. The team can monitor the remaining drafts at its next check-in; the information given does not establish that the review timing has been missed.
Answer: Record content selection as complete and page drafting as in progress, with one of three drafts complete. Keep the planned Week 4 review visible and check progress again.
Check: The recorded status matches the stated work; it does not mark the unfinished drafts or review as complete.

Worked example

Example 2: Record a delay without hiding the plan

A club project schedule places poster design in Week 1 and printing in Week 2. At the end of Week 2, the design is still being revised and printing has not started. Show how to update the project record.
Poster project: planned tasks and Week 2 status
thenDesign | planned Week 1Print | planned Week 2 |

The connected tasks follow the planned sequence. Status notes describe the end-of-Week 2 check.

  1. Compare the plan and status
    The planned design period has passed, but revision is continuing. Printing was planned for Week 2 and has not started. Both the planned timing and the reported status matter.
  2. Record the difference
    Mark design as in progress and printing as not started. Add a note that the planned timing has slipped; do not mark either task complete or silently remove the original dates.
  3. Agree on any revision
    The team should discuss revised timing and record it only after agreement. The information provided does not establish what a new date should be.
Answer: Record design as in progress and printing as not started. Note that the original Week 1 and Week 2 timing has slipped, and add revised dates only after the team agrees on them.
Check: This update shows actual progress and preserves the original plan without inventing replacement dates.

Worked example

Example 3: Communicate an agreed revised plan

A team planned to prepare a demonstration in Week 1 and present it in Week 2. At the end of Week 1, preparation is not complete. The team agrees to use Week 2 for preparation and Week 3 for the presentation. What should the updated schedule communicate?
Demonstration project: original and revised timing
thenPrepare | original WeekPresent | original Week

Connected tasks show their sequence. Each task label includes the original period, revised period, and Week 1 status where relevant.

  1. Record the check-in
    At the end of Week 1, preparation is not complete. Record its actual status and preserve the original plan of preparation in Week 1 and presentation in Week 2.
  2. Show the agreed revision
    The team has agreed to prepare in Week 2 and present in Week 3. Add that revised timing to the schedule and label it as the current plan, not as completed work.
  3. Keep tracking
    At the next check-in, compare actual progress with the revised timing. A revised plan describes intended future work; it does not show that the work has happened.
Answer: Show preparation as incomplete at the Week 1 check, preserve the original Week 1 and Week 2 plan, and clearly mark the agreed revised plan: preparation in Week 2 and presentation in Week 3.
Check: The schedule communicates both the change and the current status without treating future work as complete.

Common mistakes and how to avoid them

Changing planned dates without recording that they changed.
Correction: Make revisions visible so the team can distinguish the original timing from the current plan.
Marking a task complete because its planned finish period has arrived.
Correction: Record the task's actual status based on the work completed.
Treating a Gantt chart as proof that the project will finish on time.
Correction: Use it to inspect timing and progress; it does not guarantee an outcome.

Lesson summary

  • A schedule or Gantt chart shows project tasks and planned timing.
  • Tracking means checking actual task status against that plan.
  • Record delays and agreed revisions clearly, then continue checking progress.

Check your understanding

Question 1

A task was planned to finish this week, but some work remains. What is the best update?
  1. Mark it complete because its planned finish week has arrived.
  2. Record it as in progress and note the difference from the plan.
  3. Delete its planned dates so the schedule looks current.
  4. correctIndex": 1,
Show answer and explanation
Record it as in progress and note the difference from the plan.
Status should reflect the work actually completed, while the schedule should make the difference from the plan visible.

Question 2

The team agrees to move a presentation to a later week. What should the schedule show?
  1. The agreed revised timing, identified as a change from the earlier plan.
  2. The presentation as complete, because the team discussed it.
  3. Only the earlier date, even after the team agrees on a new plan.
  4. correctIndex": 0,
Show answer and explanation
The agreed revised timing, identified as a change from the earlier plan.
A useful update communicates the current agreed plan while distinguishing it from the original timing.

Key terms

Schedule
A record of project tasks and their planned timing.
Gantt chart
A visual schedule that places project tasks against a timeline.
Milestone
A notable point used to check project progress.
Status
A description of a task's actual state, such as not started, in progress, or complete.

Continue through ICS4U

View the complete ICS4U Ontario Grade 12 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 12 Computer Science (ICS4U), expectation B1.4. It is a study resource, not an official curriculum publication.

Before publication, content is checked for structure, mathematical or chemical notation, calculations, course boundaries, and readability. Errors can still occur, so corrections are welcomed.

Official curriculum reference

Report a correction or ask a question