1.1Entering Tasks, Durations & Summary Tasks
The essentials in 30 seconds
- A schedule is built first as tasks: one line per task, named with an action verb, with an estimated duration.
- The hierarchy (WBS) makes the project readable: tasks are grouped under summary tasks (phases) by indentation.
- The summary task calculates its duration and dates by itself from its subtasks: you never enter them by hand.
Running mini-case — Meriem structures the schedule for a building extension
Meriem, project manager in an engineering & construction company in Algiers, starts the schedule for a client's building extension. Her first page is empty: she begins by entering the tasks one per line — “Survey the ground”, “Pour the foundations”, “Erect the structure”, “Install the services” — with an estimated duration for each. But this flat list means nothing to the client. So she creates phase tasks (“Design”, “Structural works”, “Fit-out works”) and indents the relevant tasks underneath, forming a three-level WBS. She then notices that the “Structural works” phase shows its own duration and dates, calculated from its subtasks: she entered nothing on the phase line. Meriem remembers the rule: enter tasks and their duration, structure them into phases, and the summary task calculates itself.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 1.1.
1. Tasks, a hierarchy
The core of a schedule is the tasks. Meriem enters them in the grid, one per line, with their duration (3 days, 2 weeks…). But a construction project is not a flat list: you structure it by grouping tasks under summary tasks (phases), forming a hierarchy — this is the WBS (Work Breakdown Structure).
You indent or outdent lines to create this breakdown: Phase > subtasks. Meriem thus places “Pour the foundations” and “Erect the structure” under the “Structural works” phase.
2. The summary task calculates itself
The summary task summarizes its subtasks: its duration and dates are calculated automatically from them. You never enter them by hand — a beginner habit to lose.
This breakdown makes the schedule readable, allows reasoning by phase and serves as a basis for reporting. Best practice: break down until tasks are of manageable size, named with action verbs.
3. Naming and sizing tasks
A good task has a deliverable, an owner and an estimable duration. A common guide is the 8/80 rule: a task of about 8 h (1 day) to 80 h (2 weeks) has a healthy granularity. Too fine, the schedule becomes unmanageable; too coarse, it can no longer be tracked.
Meriem names each line with an action verb (“Survey”, “Pour”, “Install”) and checks her breakdown: neither micro-management nor big blocks impossible to track.
🔎 Concrete example — 🔎 Concrete example — The 8/80 rule
Finding the right task granularity:
A task between ~8 h (1 d) and ~80 h (2 wk): good size.
Too fine (1 h) → unmanageable schedule;
too coarse (3 months) → impossible to track.
→ each task: a deliverable, an owner, an estimable duration.Reading: Meriem aims for tasks small enough to be tracked, without falling into micro-management.
Reflex: never enter a summary task's duration — it is calculated from its subtasks.
Section vocabulary
- Task
- A work line of the schedule, with a name, a duration and (later) links, resources and costs.
Simple example: Meriem enters “Pour the foundations” with a duration of 5 days.
What it is not: a rough note with no name, duration or owner.
Reflex: one task → one deliverable, one duration.
- Duration
- The estimated working time of a task, expressed in days/weeks/hours and calculated according to the calendar.
Simple example: Meriem estimates “Erect the structure” at 3 weeks.
What it is not: a task with no estimate, impossible to schedule.
Reflex: duration = estimate according to the working calendar.
- Summary task
- A “parent” task grouping subtasks; its duration and dates automatically derive from them.
Simple example: Meriem's “Structural works” phase summarizes the foundations and the structure.
What it is not: entering by hand the duration of a grouping phase.
Reflex: summary task → calculated duration, never entered.
- WBS (work breakdown structure)
- Hierarchical breakdown of the project into phases and subtasks (Work Breakdown Structure).
Simple example: Meriem organizes her site into Design, Structural works and Fit-out works.
What it is not: a long flat list with no hierarchy.
Reflex: structure → WBS in phases.
- Indentation (indent/outdent)
- Moving a task within the hierarchy to place it under a summary task (or out of it).
Simple example: Meriem indents “Erect the structure” under “Structural works”.
What it is not: phase tasks left at the same level as the detail.
Reflex: place a subtask → indent it.
In practice — In practice — Entering and structuring tasks
- Enter the project's task list, one per line, with an estimated duration for each.
- Create phase tasks (e.g. “Design”, “Delivery”) and indent the relevant tasks underneath.
- Note that each summary task calculates its duration and dates by itself from its subtasks.
- Name tasks with action verbs and check that the breakdown is neither too fine nor too coarse.
Step-by-step script — enter and structure like Meriem (5 min)
1) List the project's tasks one per line, with an estimated duration for each. 2) Add phase tasks (“Design”, “Structural works”, “Fit-out works”). 3) Indent the detail tasks under their phase to form the WBS. 4) Check that each summary task's duration is calculated automatically and is not entered. 5) Name each task with an action verb and check the granularity (8/80 rule).
Keep this structure: it is the basis for chaining tasks (links) and for level reporting.
Copy-paste template — my entry checklist
[ ] One line per task, with an estimated duration
[ ] Tasks named with action verbs
[ ] Phase tasks created (summary tasks)
[ ] Subtasks indented under their phase
[ ] Summary task duration/dates not entered (calculated)
[ ] Granularity respected (~8/80 rule)
[ ] WBS readable and ready to be chained with linksSmall project
Meriem uses only one phase and a few tasks, but keeps the task → summary task structure.
Large site
Meriem goes down three WBS levels (project → phases → packages → tasks) to stay readable.
Naming with action verbs
Meriem writes “Install the services” rather than “Services”, for a schedule everyone can understand.
Checking granularity
Whatever the project, Meriem checks that no task is too fine or too coarse (8/80 rule).
✓ Best practices
- Structure into phases (summary tasks) + subtasks.
- Name tasks with action verbs.
- Aim for 8/80 granularity (one deliverable per task).
✗ Common pitfalls
- Entering each task's dates by hand.
- Entering a summary task's duration (it is calculated).
- Breaking down too fine (unmanageable) or too coarse (untrackable).
Key takeaways
- You enter tasks with their duration (calculated according to the working calendar).
- You structure the project into a hierarchy (WBS) with summary tasks (phases).
- Indentation (indent/outdent) places subtasks under their phase.
- The summary task automatically calculates its duration and dates: do not enter them.
48h challenge — apply it tomorrow
Take a real project (even a small one) and create its WBS like Meriem: tasks one per line with duration, phase tasks, then indentation of subtasks. Check that a summary task's duration is calculated automatically. Write in one sentence why you do not enter a phase's duration.
- I can enter tasks with their duration in Project.
- I can structure a project into phases and subtasks (WBS).
- I understand that the summary task calculates its duration and dates by itself.
Frequently asked questions
Should I enter the start and finish dates of each task?
No, and that is the classic beginner mistake. In automatic mode, you enter the duration and the links between tasks, and Project calculates the dates by itself. Forcing dates by hand creates rigid constraints that prevent the schedule from recalculating (see section 1.4). You only fix a date when it is genuinely imposed.
How far should I break down tasks (level of detail)?
Break down until tasks are small enough to be estimated and tracked, without micro-managing. A common guide is the “8/80” rule: between ~8 h (1 day) and ~80 h (2 weeks). Too fine makes the schedule unmanageable; too coarse prevents tracking progress. Each task must have a clear deliverable, an owner and an estimable duration.
How do you structure a project into phases in Project?