DoAssignment study guide

B1.1 · Define scope, tasks, deliverables and schedule

Learn to define scope, tasks, deliverables and schedule through clear examples and targeted practice.

Ontario Grade 12 Computer Science

Software Development

ICS4U B1.1: defining scope, tasks, deliverables, and schedule

Before a team begins building software, it needs a shared picture of what it intends to complete and how it will organize the work. ICS3U programming experience helps you recognize the difference between an idea and a finished program. This lesson focuses on defining the project’s scope, tasks, deliverables, and schedule. These are connected but distinct parts of a plan: what is included, what work must happen, what results will be produced, and when those results are expected.

What you will learn

  • Explain how scope, tasks, deliverables, and schedule work together in a project plan.
  • Turn a bounded project idea into tasks and identifiable deliverables.
  • Create an illustrative schedule that places tasks in a sensible order.

1. Start with a boundary: scope

Scope describes what a project will include and, just as importantly, what it will not include. A project idea such as “make a school club app” is too broad to guide a team: it does not say which parts of club activity the software will support. A more useful scope might say that the project will provide a list of clubs, meeting times, and contact details, while leaving out account creation and online sign-up.
The boundary gives the team a basis for planning decisions. When someone suggests a feature, the team can ask whether it belongs in the agreed scope. If it does not, the team can leave it out of this project rather than quietly adding work and making the plan unreliable. Scope should be understandable to both the people doing the work and the people expecting the result.
A well-bounded scope names the intended result and sets limits. It is neither a list of every small action nor a vague wish. For this expectation, keep the focus on defining and organizing the project.
  • State what the project will include.
  • Name important exclusions so expectations are clear.
  • Use the scope as a boundary when deciding whether proposed work belongs in the project.

2. Connect tasks and deliverables

Tasks are pieces of work needed to complete the project. They should be concrete enough that a team can assign responsibility and recognize when the work is done. “Work on the program” is difficult to check. “Enter the agreed club names and meeting times into the club list” describes a more specific piece of work.
A deliverable is an identifiable result the project will produce. It may be a document, prepared information, or a completed program. A task is an activity; a deliverable is an outcome. One task may help produce a deliverable, and several tasks may be needed for one deliverable.
For example, collecting and confirming club contact details is a task. A checked list of club names and contact details is a possible deliverable. Writing down both helps prevent a planning gap: listing activities without saying what they are expected to produce.
  • Describe tasks as pieces of work that can be completed and checked.
  • Describe deliverables as identifiable project results.
  • Make the connection between planned work and its expected result clear.

3. Put the work on a schedule

A schedule places planned tasks in time. It can show when work is expected to start and finish, or show the order and planned period for each task. A schedule should reflect dependencies: for instance, a team generally needs to agree on which information belongs in a club list before preparing that list.
A schedule is a plan, not a claim that every task will finish exactly as predicted. Its purpose is to make intended timing visible so the team can coordinate and notice when a planned result is not ready. It is more useful when it refers to named tasks and deliverables rather than vague stages such as “do project.”
Keep the schedule consistent with scope. Adding a feature may require additional tasks and a changed finish date. When circumstances change, the team can revise the schedule and communicate the revised expectation.
  • Place tasks in a sensible order and assign planned time periods.
  • Show how work that depends on earlier decisions follows those decisions.
  • Treat a schedule as a planning tool that can be reviewed and updated.

4. Check that the plan fits together

A useful project plan has alignment. The scope describes the intended boundary; tasks describe work inside that boundary; deliverables identify the results; and the schedule says when the work and results are planned. If the scope promises a club list but no task prepares club information, the plan has a gap. If a task is listed but contributes to no agreed result, the team should clarify why it is included.
Review the scope to confirm what is included and excluded. Inspect the tasks and ask whether they cover the agreed work. Identify the deliverables and ask whether they are observable results. Finally, check whether the schedule places tasks in a workable order and makes expected timing clear.
Dates and durations in the examples are illustrative planning choices for those scenarios, not measurements or universal standards. A real team would set its schedule based on its agreed work and circumstances.
  • Check that each deliverable fits the scope and has supporting tasks.
  • Check that scheduled work is ordered sensibly.
  • Revise connected parts of the plan together when the scope changes.

Worked example

A focused club-information project

A student team wants to make a simple club-information program. Create a plan that states a bounded scope, tasks, deliverables, and an illustrative three-week schedule.
Illustrative club-information project schedule
checked informationprepared listWeek 1: agree on fieldsWeek 2: check details anWeek 3: review program a

The sequence links planned work to expected results.

  1. Define the boundary
    The scope is a program that presents club names, meeting times, and contact details. It does not include account creation or online sign-up. Naming exclusions prevents those features from being treated as promised work.
  2. Name work and results
    Tasks include agreeing on the information fields, collecting and checking club details, preparing the program’s club list, and reviewing it against the agreed scope. Deliverables are the agreed field list, checked club information, and completed club-information program.
  3. Place the work in order
    The field list comes first because it tells the team what information to collect. The team then checks the information, prepares the program, and reviews the result. The timeline shows one reasonable illustrative schedule; it is not evidence that the work has been completed.
Answer: Scope: display club names, meeting times, and contact details; exclude accounts and online sign-up. Tasks: agree on information fields, collect and check details, prepare the club list in the program, and review it. Deliverables: agreed field list, checked club information, and completed program. Schedule: week 1, agree on fields and collect details; week 2, check details and prepare the list; week 3, review the program against the scope.
Check: The plan fits because the tasks produce the named deliverables, and the schedule places information decisions before preparation and review.

Worked example

A class reading-list project

A class wants a small digital reading list for a course. The team has three weeks for its illustrative plan. Show how a clear scope can guide tasks, deliverables, and timing.
Illustrative reading-list project schedule
information gatheredlist preparedWeek 1: agree on fieldsWeek 2: check informatioWeek 3: review list agai

Preparation follows agreement and information checking.

  1. Limit the scope
    The project will present titles, authors, and brief descriptions for an agreed course reading list. It will not provide online borrowing or student accounts. This boundary keeps the expected result specific.
  2. Derive tasks and deliverables
    The team must agree on the list’s fields, gather and check the reading information, prepare the digital list, and review it. Those tasks support deliverables: the agreed fields, checked reading information, and completed digital list.
  3. Schedule the work
    The team agrees on fields before gathering information, checks the gathered information before preparing the list, and reviews the list after preparation. The example uses weeks as planning periods, not as a guarantee of completion.
Answer: Scope: a digital list showing titles, authors, and brief descriptions for an agreed set of course readings; no borrowing service or student accounts. Tasks: agree on fields, gather and check reading information, prepare the list, and review it. Deliverables: agreed fields, checked reading information, and completed list. Schedule: week 1, agree on fields and gather information; week 2, check information and prepare the list; week 3, review the result against the scope.
Check: If the team added online borrowing, it would be changing the scope. The tasks, deliverables, and schedule would need review rather than treating the added feature as already planned.

Worked example

Revising a plan when scope changes

A team has planned a program that displays school event names, dates, and locations. After planning, someone requests an additional feature: displaying event contact details. Explain how the team should keep the plan consistent.
Illustrative schedule after a scope change
event details checkedupdated list preparedWeek 1: confirm fields aWeek 2: check informatioWeek 3: review against r

The added information is included in the work and checked in the final review.

  1. Compare the request to scope
    The original scope names event names, dates, and locations. Contact details are not among those stated items, so the request is a proposed scope change rather than work already promised.
  2. Update connected planning parts
    If the team agrees to include contact details, it should add the related task of collecting and checking those details, identify the updated event information as a deliverable, and review whether the schedule still fits. If the team does not agree to the change, it should keep the original scope and schedule.
  3. State the expected plan
    For this example, assume the team accepts the request. The revised scope includes names, dates, locations, and contact details. Its plan now names work and results for the additional information, and the schedule includes time for that work. The timeline shows the revised sequence as an illustration.
Answer: Revised scope: display event names, dates, locations, and contact details. Tasks: confirm the information fields, collect and check event details, prepare the event list, and review it. Deliverables: agreed fields, checked event information, and completed event list. Revised illustrative schedule: week 1, confirm fields and collect information; week 2, check information and prepare the list; week 3, review the list against the revised scope.
Check: The important planning move is not simply to add a feature to the scope statement. The team also updates the supporting tasks, deliverables, and schedule so they describe the same project.

Common mistakes and how to avoid them

Writing a broad idea such as “make an app” as the scope.
Correction: State the intended content or service and name meaningful exclusions so the project boundary can guide decisions.
Treating a task and a deliverable as the same thing.
Correction: Describe the task as work to do and the deliverable as the identifiable result that work helps produce.
Listing tasks without checking their order.
Correction: Arrange tasks so that needed decisions and information are available before dependent work begins.
Adding work to the scope but leaving the original schedule unchanged without review.
Correction: When scope changes, reconsider the related tasks, deliverables, and planned timing together.

Lesson summary

  • Scope sets the project boundary by identifying what is included and excluded.
  • Tasks are pieces of work; deliverables are identifiable results.
  • A schedule places tasks and expected results in a sensible planned order.
  • The four parts should agree, and connected parts should be reviewed when the plan changes.

Check your understanding

Question 1

Which statement best describes a deliverable?
  1. A specific piece of work the team performs
  2. An identifiable result the project is expected to produce
  3. A list of features that might be added later
  4. A date chosen without reference to project work
Show answer and explanation
An identifiable result the project is expected to produce
A deliverable is an identifiable project result. A specific action is a task.

Question 2

A team adds contact details to an event program’s agreed scope. What should it do next to keep the plan consistent?
  1. Leave the tasks and schedule as they are because the scope statement is enough
  2. Remove all deliverables from the plan
  3. Review the tasks, deliverables, and schedule to account for the added work
  4. Treat the new feature as completed as soon as it is requested
Show answer and explanation
Review the tasks, deliverables, and schedule to account for the added work
An accepted scope change may require new work and a revised expected result or timing, so the connected planning parts should be reviewed.

Question 3

Why should a project team schedule information checking before preparing a list that depends on that information?
  1. The schedule should show a sensible order for dependent work
  2. A deliverable must always be scheduled before its tasks
  3. Scope applies only after the program is finished
  4. Tasks cannot be connected to deliverables
Show answer and explanation
The schedule should show a sensible order for dependent work
When preparation depends on checked information, placing the check first makes the planned sequence sensible.

Key terms

Scope
The agreed boundary of a project, including what it will and will not include.
Task
A piece of work planned as part of completing a project.
Deliverable
An identifiable result the project is expected to produce.
Schedule
A plan that places project tasks and expected results in time or in a planned order.

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