Lesson 1 — Activities, Dependencies, and Duration¶

At a glance

Module: 06 — Schedule Management
Level: Intermediate
Estimated time: 40 minutes
Example project: the LMS

Learning objectives¶

By the end of this lesson you should be able to:

Derive activities from work packages and estimate their duration.
Identify dependencies and classify them as mandatory, discretionary, or external.
Distinguish effort from duration and explain why the difference changes a schedule.
Build a network diagram that shows activities and their dependencies.

Prerequisites¶

Module 05 — Scope & Requirements Management

Introduction¶

A work breakdown structure tells you what the work is. A schedule tells you when it happens, and the two are not the same. Turning one into the other requires three steps: identify the activities, work out what depends on what, and estimate how long each takes.

This lesson does those three steps. The next lesson finds the sequence that determines the finish date, and examines what it costs to shorten it.

1. From work packages to activities¶

A work package is a deliverable-sized chunk of scope. An activity is a unit of work you will schedule, which may be a whole work package or part of one.

Split a work package when its parts have different dependencies or different owners. Otherwise leave it whole — scheduling at a finer level than you manage creates work and no information.

Work package	Activities	Why split
Submission form and validation	Design the form; build the form	The design gates the file storage work
File storage and access rules	Configure storage; implement access rules	Access rules need a security review (external dependency)

2. Dependencies¶

A dependency is a relationship in which one activity's progress relies on another. Classify them, because each class is managed differently.

Class	Meaning	Example
Mandatory	Physically unavoidable	You cannot test code that does not exist
Discretionary	A choice, usually for convenience or safety	Doing design before build rather than alongside
External	Controlled outside the project	A security review, or a supplier's delivery date

Discretionary dependencies are the interesting ones. They look mandatory but are not, which is why they are the first place to look when a schedule must be shortened — and also the first place rework appears if you remove them carelessly.

Most dependencies are finish-to-start: B cannot begin until A finishes. Others exist (start-to- start, finish-to-finish, start-to-finish), but they are used far less and should be flagged when used, because they mean the plan is not a simple chain.

3. Effort is not duration¶

Effort is the amount of work; duration is elapsed time. The distinction matters because the relationship between them is not fixed.

One person on a 5-day task: effort 5 days, duration 5 days.
Two people on the same task: effort still about 5 days, duration maybe 3 — not 2.5. Coordination adds overhead.
A task waiting on an external review: effort 1 day, duration 3 weeks.

Only duration goes into a schedule. Confusing the two is the most common arithmetic error in planning, and it always produces an optimistic plan.

LMS (illustrative)

"Implement access rules" is estimated at 1 day of effort, but the security review has a two-week lead time that the project does not control. Recorded as effort, the activity looks like one day and the schedule is two weeks wrong. Recorded as duration, the external dependency is visible and can be booked early.

4. Building the network¶

A network diagram shows activities as nodes and dependencies as arrows. Building it forces you to state the dependencies explicitly, which is where the value lies — the diagram itself is a by-product.

flowchart LR
    accTitle: A small activity network with parallel work
    accDescr {
    Setting up the environment leads to designing the data model, which leads to two activities that
    can run in parallel: building the submission form and building file storage. Both converge on
    integration testing.
    }
    A[Set up environment] --> B[Design data model]
    B --> C[Build submission form]
    B --> D[Build file storage]
    C --> E[Build grading view]
    D --> F[Integration testing]
    E --> F

Read it as: testing cannot start until both storage and grading are done. That single fact is what makes the next lesson's analysis possible.

Key terms¶

Term	Meaning
Activity	A schedulable unit of work, often derived from a work package
Dependency	A relationship in which one activity relies on another
Mandatory dependency	Unavoidable, dictated by the nature of the work
Discretionary dependency	A choice, often for safety or convenience
External dependency	Controlled outside the project
Effort	The amount of work, in person-hours or person-days
Duration	Elapsed calendar time
Network diagram	A diagram of activities and their dependencies

Worked example¶

Task: derive activities, dependencies, and durations for the first release of the illustrative LMS submission capability. All durations are invented for illustration.

Step 1 — List activities from the work packages. From the Module 05 WBS: set up the development environment; design the submission data model; build the submission form; build file storage; build the grading view; run integration testing.

Step 2 — Classify each dependency.

Activity	Depends on	Class
Set up environment (A)	—	—
Design data model (B)	A	Mandatory
Build submission form (C)	B	Mandatory
Build file storage (D)	B	Mandatory
Build grading view (E)	C	Discretionary — could overlap with C
Integration testing (F)	D, E	Mandatory

Step 3 — Estimate effort, then state duration. A: 2 d. B: 2 d. C: 4 d. D: 3 d. E: 3 d. F: 3 d. All are single-owner activities, so effort and duration are equal here. Note that explicitly — it is an assumption, not a law.

Step 4 — Draw the network. The diagram above is the result.

Step 5 — Check for missing dependencies. Export for the exams office was in the WBS but has no place in this network. Either it belongs in this release and needs activities, or it does not — and if it does not, that must be written down. A WBS item with no schedule presence is a gap.

Step 6 — Note the external dependency. Integration testing needs a staging environment owned by IT operations. That is external, so record who provides it and by when, and treat its lead time as part of the duration.

Common misconceptions¶

“Adding people shortens a task proportionally”

Rarely. Coordination overhead grows faster than headcount for work that has to be shared, and some tasks cannot be split at all. Two people rarely halve a duration.

“All dependencies are mandatory”

Many are choices. Separating discretionary dependencies from mandatory ones tells you where a schedule can legitimately be shortened — and where removing the dependency would create rework.

“A network diagram is the schedule”

It shows sequence and logic, with no dates and no resource contention. It is the input to a schedule, not a schedule.

Practical activity¶

Build a network. Take one release of an example project.

List the activities, each with an effort and a duration estimate.
Build a dependency table and classify every dependency.
Draw the network as a Mermaid flowchart.
Mark every external dependency and state who controls it.
Check your WBS from Module 05 for anything with no place in the network.

What "good" looks like: at least one discretionary dependency identified as such, one external dependency with a named owner, and at least one WBS item you realised had no schedule presence.

Self-assessment¶

Why does confusing effort with duration always produce an optimistic schedule?
What is the difference between a mandatory and a discretionary dependency, and why does the distinction matter when shortening a schedule?
Give an example of an external dependency and explain how it should be recorded.
Apply it — inventory migration. One work package is estimated at 80 person-days and the plan gives it one developer for 80 days. That developer also covers production support one day each week. Separately, a security review of the migration is required before go-live; it is performed by a team outside the project and has a two-week lead time from request.

Hint: A strong answer recomputes the duration from the working pattern and classifies the review as a dependency type.

Show answers

Because effort is usually the number people know, and duration is always at least as large — often much larger when work is shared, interrupted, or waiting. Using effort as duration removes waiting and coordination from the plan, so the schedule is short by exactly the effects that are hardest to see.
A mandatory dependency is unavoidable; a discretionary one is a choice. When shortening a schedule, discretionary dependencies are the only ones that can legitimately be removed or overlapped — which is why identifying them matters. Removing a mandatory dependency is not an option, only a source of rework.
A security review, a supplier delivery, or an environment provisioned by another team. Record it with a named owner outside the project, its expected lead time, and the activity it gates — so the schedule reflects the lead time rather than assuming it away.
Eighty person-days of effort is not an 80-day duration. With one day a week on support, the developer has about four productive days per week, so the work occupies 80 ÷ 4 = 20 weeks — before holidays, absence or coordination, none of which the plan should assume away. The security review is an external dependency: it is not yours to control, so record it with its named owner outside the project, the two-week lead time, and the activity it gates, and place the lead time in the network rather than treating it as free. If it can run in parallel it may not be critical, but that has to be shown, not assumed. And adding a second developer to shorten it does not halve the duration — duration = effort ÷ (people × efficiency), and coordination lowers efficiency.

Summary¶

Activities come from work packages; split only where dependencies or owners actually differ.
Classify dependencies as mandatory, discretionary, or external, because each is managed differently.
Effort is work; duration is elapsed time. Only duration belongs in a schedule.
Building the network is what forces dependencies into the open; the diagram is a by-product.

Further learning¶

Lesson 2 — Gantt Charts, the Critical Path, and Float analyses the network you have built.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — schedule management.

Next¶

Continue to Lesson 2 — Gantt Charts, the Critical Path, and Float.