DoAssignment study guide
B4.3 · Show project tasks and milestones
Learn to show project tasks and milestones through clear examples and targeted practice.
Ontario Grade 11 Computer Science
Software Development
Making a project’s work and important checkpoints easy to see
A project plan is easier to understand when people can see both the work to be done and the important points that show progress. In this lesson, a task means a piece of work that needs to be completed. A milestone means a significant checkpoint in the project, such as an agreed review or a completed project stage. A milestone is not another name for a task: it marks a point to check or recognize progress. The focus here is to show project tasks and milestones clearly. The examples use imaginary school projects, so their dates and details are scenario information rather than claims about real events.
What you will learn
- Explain the difference between a project task and a milestone.
- Present project tasks and milestones in a clear, useful format.
- Use task details and milestone checkpoints to show how project work is organized over time.
- Review a project plan for missing, unclear, or misleading information.
1. Make the work visible
Start with the project’s intended result: what should be ready when the project is finished? Then list the tasks that contribute to that result. A task should describe an action clearly enough that a team member can tell what work is expected. “Prepare the presentation slides” is more informative than “slides,” because it names an action.
A milestone marks an important point in the project rather than a piece of work to carry out. For example, “presentation outline approved” can be a milestone: it indicates that the team has reached a checkpoint. The work of drafting and reviewing the outline belongs in tasks. A milestone can help a team see whether it has reached a planned stage.
To show project work, use a format suited to the people who need to read it. A short task list may be sufficient for a small project. A table can make the task, person responsible, and planned date easy to scan. A calendar-style schedule can show when tasks and milestones are expected. Choose a clear format; extra decoration is not a substitute for useful information.
- Tasks describe work to do.
- Milestones identify significant project checkpoints.
- A clear description helps others understand what is expected.
2. Show timing and responsibility
A useful project display connects each task to a person or group responsible for it and, when appropriate, a planned time. Dates help readers understand when work is expected, but they should be realistic for the scenario and agreed by the project team. If a date changes, update the display so it does not continue to suggest an obsolete plan.
Arrange tasks in an order that makes sense for the project. Some work needs to be finished before another task can begin. For instance, a team may need to agree on a survey question before collecting responses. Showing this order helps people understand how the plan fits together. Do not present tasks as simultaneous if the described work requires one to happen first.
Place milestones where they help readers recognize a meaningful checkpoint. A milestone might be a review of a draft, approval of a plan, or completion of a project stage. The milestone should be distinguishable from the tasks leading to it. A plan with only milestones can hide the work; a plan with only tasks can make it difficult to spot the major checkpoints.
- Include responsibility and planned timing when they help make the plan usable.
- Show a sensible order when one task depends on earlier work.
- Make milestones noticeable and distinct from the work that leads to them.
3. Check that the display communicates
Before sharing a project plan, read it as if you were a teammate joining the project. Can you tell what needs to be done, who is taking responsibility, and when the work is planned? Can you distinguish the tasks from the milestone checkpoints? If not, revise the wording or layout.
Look for tasks that are too broad, such as “finish project.” That phrase does not show what work is included. Break it into understandable actions that reflect the project scenario. Also look for milestones that are too vague, such as “make progress.” A checkpoint is more useful when it states what will be true at that point, such as “first draft reviewed by the team.”
A display communicates a plan, not proof that work has already happened. Use wording and status labels carefully. A planned date should not be mistaken for a completed date, and an upcoming milestone should not look achieved. Update the display as the project changes, while keeping it focused on the tasks and milestones people need to follow.
- Use specific descriptions rather than broad labels.
- Keep planned work distinct from completed work.
- Review the plan from a reader’s point of view and revise unclear parts.
Example plan: class information display
| Planned point | Entry | Type | Responsible person or group |
|---|---|---|---|
| May 15 | Gather club information | Task | Team member A |
| May 18 | Draft the display text | Task | Team member B |
| May 20 | Display draft reviewed by the team | Milestone | Whole team |
| May 23 | Prepare the display | Task | Team member A and B |
| May 24 | Display ready to share at the class meeting | Milestone | Whole team |
Worked example
Plan a class information display
A small team will make a display about a school club. They have agreed to share it at a class meeting on May 24. Show a plausible set of tasks and milestones that makes the preparation visible. The dates below are invented for this example.
- Identify the workList actions that contribute to the display: gather club information, draft the display text, and prepare the display. These descriptions show work rather than merely naming project topics.
- Mark checkpointsAdd a milestone for the team’s review of the draft and another for the display being ready to share. These are checkpoints that help show progress, not extra work descriptions.
- Read the planThe team can use the table to see who is responsible and what is planned next. Since the example has no actual completion information, it reports planned dates only.
Answer: A clear plan can list gathering information, drafting text, reviewing the draft, preparing the display, and having the display ready for the class meeting. The review and ready-to-share points are milestones; the other entries describe tasks.
Check: The plan is useful because it separates work from checkpoints and shows a plausible order leading to the stated sharing date.
Worked example
Make a broad task more useful
A team’s project list contains one entry: “Prepare the club survey.” The team needs to show the work and a meaningful checkpoint, but the project scenario gives no real dates. Improve the plan without inventing dates.
- Clarify the actionThe original entry does not show what “prepare” includes. Rewrite it as a few actions that someone can understand, such as drafting survey questions and reviewing the questions with the team.
- Add a checkpointUse a milestone such as “survey questions reviewed by the team.” This states a significant point to check. It does not claim that the review has already happened.
- Keep unknown details honestBecause no dates or assigned people are provided, do not make them up. The team can add those details after agreeing on them.
Answer: Show “draft survey questions” and “review survey questions with the team” as tasks, then show “survey questions reviewed by the team” as a milestone. Add dates and responsible people only when the team has agreed on them.
Check: The revised display is more informative without presenting invented dates or completed work as facts.
Worked example
Review a project display
A team shares this plan: “Make website; milestone: work finished; launch Friday.” The project is a school club information page. The team has not said what “finished” means or which Friday is intended. Identify what should be clarified.
- Clarify the task“Make website” is broad. Replace it with actions that fit the project, such as drafting the club information page and reviewing its text. The plan should show the work rather than leave it hidden inside a general phrase.
- Clarify the milestone“Work finished” does not identify what checkpoint has been reached. A more informative milestone might state that the club information page has been reviewed and is ready to share, if that matches the team’s intended checkpoint.
- Clarify the timing“Friday” is not specific enough for someone reading the plan later. The team should agree on the intended date and show it clearly. Until then, the display should not imply that a definite date was established.
Answer: Revise the broad task into understandable actions, name the milestone as a specific checkpoint, and replace “Friday” with a clearly agreed date. Keep the milestone and any launch date visibly planned unless the team confirms completion.
Check: Each proposed change addresses an information gap in the original display without assuming facts that the scenario does not give.
Common mistakes and how to avoid them
Treating every project entry as a task, including “draft approved.”
Correction: A task describes work to do; “draft approved” is a checkpoint showing that a review stage has been reached.
Using broad labels such as “do project” or “make progress.”
Correction: Use descriptions that show the action or the specific condition that marks a checkpoint.
Adding precise dates or responsible people without agreement or information.
Correction: Show only details the team has established. Mark missing details for the team to decide rather than presenting guesses as facts.
Showing planned work as if it has already been completed.
Correction: Keep planned dates and upcoming milestones distinct from completed work.
Lesson summary
- A task is a piece of work to complete; a milestone is an important project checkpoint.
- Show tasks and milestones in a format readers can scan and understand.
- Include timing and responsibility when known and useful, and show task order when it matters.
- Review wording and status so the display communicates the plan rather than implying unsupported facts.
Check your understanding
Question 1
Which entry is best described as a milestone?
- Draft three questions for the club survey
- Ask two members to review the draft questions
- Survey questions reviewed and approved by the team
- Write the club name at the top of the page
Show answer and explanation
Survey questions reviewed and approved by the team
This entry identifies a checkpoint showing that a review stage has been reached. The other choices describe work to do.
Question 2
A plan says “finish display soon.” What is the best improvement?
- Keep the phrase because all team members will interpret it the same way
- Replace it with specific tasks and a clearly described checkpoint; add an agreed date if known
- Label “soon” as the milestone date
- Remove every milestone so the plan contains only dates
Show answer and explanation
Replace it with specific tasks and a clearly described checkpoint; add an agreed date if known
Specific work and a meaningful checkpoint are easier to understand. A date belongs in the plan only when it has been established.
Question 3
A team has not chosen a completion date. What should its project display do?
- Invent a likely date so the plan looks complete
- Show a date from another team’s project
- Leave the date unconfirmed and make clear that the team still needs to decide it
- Mark the milestone as completed
Show answer and explanation
Leave the date unconfirmed and make clear that the team still needs to decide it
A project display should not present an invented date as agreed or imply that unfinished work is complete.
Key terms
- Project task
- A piece of work that needs to be completed as part of a project.
- Milestone
- A significant checkpoint that marks an important point or stage in a project.
- Project display
- A list, table, or other clear presentation that shows project tasks and milestones.
- Planned date
- A date the team intends to meet for a task or milestone; it is not evidence that the work is complete.
Continue through ICS3U
View the complete ICS3U Ontario Grade 11 Computer Science curriculum and lessons
- B4.2 · Clarify a program specification with stakeholders
- B4.4 · Compare expected and actual results in a test plan
- B1.1 · Choose problem-solving strategies for different tasks
- B1.2 · Solve problems alone and in a team
- B1.3 · Plan a solution using an input–process–output model
- B2.1 · Adapt a program template to a specification
About this lesson and its review
Published by DoAssignment. This reviewed lesson follows Ontario Grade 11 Computer Science (ICS3U), expectation B4.3. 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.