DoAssignment study guide

B1.2 · Develop a product against its project plan

Learn to develop a product against its project plan through clear examples and targeted practice.

Ontario Grade 12 Computer Science

Software Development

ICS4U study lesson for Ontario Grade 12 Computer Science — B1.2

In ICS3U, you have experience creating programs and dividing a larger task into manageable steps. This lesson focuses on coordinating that work against a project plan: using the plan to guide development, checking whether work is progressing as expected, and responding when it is not. A plan is useful only if the team refers to it while making the product. The examples use small, illustrative projects; their dates and tasks are examples, not official timelines or performance targets.

What you will learn

Explain what it means to develop a product against a project plan.
Use planned tasks, milestones, and deliverables to guide development.
Compare actual progress with the plan and identify a delay or change.
Choose and record a practical adjustment while keeping the project goal in view.

1. From a plan to day-to-day development

A project plan describes how a team intends to develop a product. For this lesson, a plan may identify the product goal, tasks, people responsible, intended order, target dates, and the deliverable expected from each task. A deliverable is a concrete result of work, such as a screen design, a working feature, or a tested release candidate.

To develop against the plan, begin by checking what the project is meant to produce and what work is scheduled next. Complete the task, produce its stated deliverable, and compare the result with the plan. The comparison is about the project’s actual state: what is complete, what remains, and whether the timing or task sequence has changed.

A plan guides work but does not make every unexpected issue disappear. If work takes longer than intended, a needed resource is unavailable, or a deliverable is not ready, the team should make the situation visible and decide how to proceed. The goal is not to pretend the original dates were met; it is to make a considered adjustment and keep the product goal clear.

Use the plan to decide what work and deliverable come next.
Compare completed work with planned work.
Make delays and changes visible rather than silently ignoring the plan.

2. Monitor progress and make a reasoned adjustment

A simple progress review asks three questions: What did the plan expect by now? What is actually complete? What is the next sensible action? Answering with specific tasks and deliverables is more useful than saying only that the project is “going well” or “behind.”

When the actual work differs from the plan, first identify the difference. Then consider its effect on the remaining tasks. For example, a late screen design may delay implementation if the implementation depends on that design. The team can then choose an adjustment, such as revising the schedule, changing the order of tasks when dependencies allow, or reducing a feature only if that still meets the intended product goal and the change is agreed upon.

Record important decisions in the plan or project notes: what changed, why, who is responsible for the next action, and what date or deliverable is now expected. This gives teammates a shared view of the current plan. It also prevents a revised target from being confused with the original target.

A project plan is not a promise that every step will happen exactly as first written. Developing against it means using it as the working guide, checking progress, and managing changes deliberately. An adjustment should be connected to the project’s goal and the work still required, rather than made merely to make a progress report look complete.

Describe the difference between planned and actual progress precisely.
Consider how a delay affects later tasks before changing the schedule.
Record the reason for an adjustment and the new expected action or deliverable.

3. Use the plan throughout product development

The plan should be consulted at the start of work, during progress checks, and when deciding what to do next. At the start, confirm the task and expected result. During work, note whether the deliverable is taking the expected path. At a review, compare actual status with the plan and agree on any needed change.

This practice helps a team coordinate its work. If a task is unfinished, the team can identify the remaining work instead of treating the task as complete. If a change affects another task, the people responsible can discuss the effect before relying on an outdated date or assumption.

Keep the level of detail useful. A plan that is too vague to show tasks and deliverables is hard to use for progress checks. A plan that is not updated when decisions are made can also mislead the team. The purpose is a shared, practical guide to developing the product, not paperwork for its own sake.

In the examples, the timelines show planned stages and a point where actual progress is reviewed. They are illustrative project plans, not evidence about how long similar projects should take.

Check task status against the current, agreed plan.
Ensure a reported completion corresponds to the expected deliverable.
Keep the plan useful by recording agreed changes.

Worked example

A feature is not ready at the planned review

A team plans a classroom club app. Its plan schedules a club-list screen design for Day 1, implementation for Days 2–3, and a review of the working feature on Day 4. At the Day 2 check, the design is incomplete. What should the team do to continue developing against the plan?

Club app feature plan and review

The original plan sets an order; the Day 2 check reveals that the design deliverable is unfinished.

Compare plan and actual work
The plan expects the screen design to be ready before implementation begins. The actual deliverable is incomplete, so the team should not report the design as finished or assume implementation can proceed unchanged.
Check the effect on the next task
Implementation is scheduled after design and depends on knowing what screen to build. The team should identify the remaining design work and consider whether the implementation dates are still realistic.
Agree and record an adjustment
The team can assign the remaining design work, agree on a revised implementation schedule, and update the Day 4 review expectation if needed. The plan should record the new deliverable or date and the reason for the change.

Answer: The team should report the design as incomplete, identify the remaining work, check its effect on implementation, and agree on a recorded adjustment. It should not quietly treat the planned date as met.

Check: The response uses the plan to assess actual progress and manage the next task instead of ignoring the discrepancy.

Worked example

A completed task does not yet meet its deliverable

A team’s plan says that by the end of Day 3 it will deliver a working event-search feature that can display matching events. At the review, the search screen is present, but it displays the same events for every search. How should the team describe progress and plan the next work?

Event-search deliverable review

A plan’s deliverable includes the expected result, not only the presence of a screen.

Check against the expected result
The deliverable is a working search feature that displays matching events. Having a screen is partial progress, but the stated behaviour is not yet present.
Report status accurately
The team can report that the screen is complete while the search behaviour remains unfinished. Separating these facts makes the remaining work clear.
Update the next action
The team should identify the work needed for matching results, assign responsibility, and decide whether the next planned date remains reasonable. If it changes, record the revised expectation and why.

Answer: Report the screen as complete but the feature deliverable as incomplete. Identify the missing search behaviour and agree on the next task and any schedule adjustment.

Check: Progress is measured against the deliverable in the plan, not merely against whether some visible work exists.

Worked example

A task order needs adjustment

A team plans to create a help page after finishing a settings screen. During development, the team learns that the help page can be drafted independently and the settings screen will take longer than expected. The product goal remains unchanged. What plan-based response could the team make?

Adjusted illustrative task sequence

The help-page draft can move earlier if it is independent of the unfinished settings screen.

Identify the change
The settings screen is taking longer, and the help page does not need to wait for it. The team should confirm that the help-page work is genuinely independent before changing the sequence.
Reconsider the schedule
If the tasks can proceed independently, drafting the help page while settings work continues may make better use of the team’s planned work. This does not mean the settings deliverable is complete.
Revise the shared plan
The team should record the adjusted order, who will draft the help page, and any changed dates for settings or review. It should keep the original product goal in view and communicate the updated plan.

Answer: After confirming the tasks are independent, the team may schedule the help-page draft while settings work continues. It should record the revised sequence and dates, while still tracking the settings screen as unfinished.

Check: The adjustment follows from the work’s relationship and is made visible in the shared plan.

Common mistakes and how to avoid them

Treating a scheduled task as complete because its target date has arrived.

Correction: Check whether the planned deliverable exists and meets the description; report unfinished work honestly.

Changing a date or task order without telling the rest of the team.

Correction: Agree on the adjustment and record it so the team has a shared current plan.

Calling a project behind schedule without identifying what differs.

Correction: Name the planned task or deliverable, its actual status, and the effect on the next work.

Lesson summary

Developing against a project plan means using it to guide tasks and expected deliverables.
Compare planned progress with actual progress throughout development.
When circumstances change, consider the effect on remaining work, agree on a practical adjustment, and record it.
The plan is a working guide; accurate status and clear communication help the team use it.

Check your understanding

Question 1

A planned feature review is due today, but one required behaviour is unfinished. What is the most plan-based response?

Mark the feature complete because the review date has arrived.
Report what is complete and incomplete, identify the remaining task, and agree on any recorded adjustment.
Remove the behaviour from the product without discussing the product goal.
Keep the original status report unchanged until the entire project ends.

Show answer and explanation

Report what is complete and incomplete, identify the remaining task, and agree on any recorded adjustment.

The team should compare the actual deliverable with the plan, report the gap accurately, and decide how to proceed.

Question 2

Why might a team revise its task order?

Any task can always be moved without checking what it depends on.
A task may be done earlier when it is independent of delayed work, if the team records the agreed change.
Changing task order proves that the original plan was useless.
A revised order means the delayed task should be reported as complete.

Show answer and explanation

A task may be done earlier when it is independent of delayed work, if the team records the agreed change.

A changed order can be reasonable when tasks are independent, but the team should check the relationship and update its shared plan.

Question 3

Which progress statement is clearest when a screen is built but its planned search behaviour is missing?

The whole feature is complete.
The project is bad.
The screen is complete; the search behaviour remains unfinished.
There is no progress to report.

Show answer and explanation

The screen is complete; the search behaviour remains unfinished.

This separates completed work from the part of the planned deliverable that remains.

Key terms

Project plan: A working guide that identifies the intended product work, tasks, timing, and expected results.
Deliverable: A concrete result expected from a task, such as a design or a working feature.
Actual progress: The work and results that are genuinely complete at a given point in the project.
Adjustment: An agreed change to planned work, order, or timing in response to the project’s actual situation.

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.2. 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