Skip to content

Lab 09 — Identifying Dependencies and Building a Network Diagram

At a glance

Learning objectives

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

  1. Assign dependencies between activities and classify each as mandatory, discretionary, or external.
  2. Distinguish a finish-to-start dependency from other relationships and explain why they are harder to manage.
  3. Build a network diagram that exposes the logic rather than merely illustrating it.
  4. Identify activities and work packages that have no place in the network — a gap that is invisible until someone looks.

Scenario

This lab continues directly from Lab 08, which produced the activity list, durations, and resource capacity for the Admission Management System. The activities are:

# Activity Duration (working days)
A Requirements workshops 5
B Data model design 4
C Applicant form build 6
D Document upload build 5
E Eligibility rules engine 8
F Admin review console 6
G Student-record integration 7
H Security review of the integration 10 (external lead time)
I System testing 5
J UAT and training 4

The team has agreed the following logic, in conversation:

  • Requirements workshops (A) must happen first; nothing can start before them.
  • The data model design (B) follows A.
  • The applicant form (C), document upload (D), and eligibility rules (E) can each start once the data model exists. Doing E in parallel with C and D is a deliberate choice to shorten the build, at the cost of coordinating three workstreams.
  • The administrative console (F) will be built after the applicant form (C) is complete, because it reuses the form's components. This is a convenience decision, not a technical necessity.
  • The student-record integration (G) needs the document upload (D) to be complete, because uploaded documents are referenced by the integration.
  • The integration cannot be considered done until the security review (H) approves it. The review is performed by the university's IT security office and cannot start until G is complete.
  • System testing (I) needs the eligibility rules (E), the administrative console (F), and the approved integration (G with H) — it cannot test what does not exist.
  • UAT and training (J) runs after system testing, and must finish before the academic calendar opens for applications. That window is fixed by the university, not by the project.

Two further facts:

  • The WBS also contains a work package for data migration from last year's spreadsheet-based process. Nobody has mentioned it in the dependency discussion.
  • The team has assumed, without checking, that the security office can begin immediately when asked.

Your role

You are the project manager. Your job in this lab is to make the project's logic visible so it can be argued with — not to produce a diagram for decoration.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

  • Durations are given and should be used as they are.
  • Treat A through J as the complete activity set for now, then test that claim in Task 5.
  • The security office's ten days includes its queue; model it as a single activity with a long duration.
  • Assume a five-day working week.

Tasks

Task 1 — Build the dependency table

For each activity, record:

Field Content
Activity Letter and name
Predecessors Which activities must finish before it starts
Relationship Finish-to-start unless you have a reason to say otherwise
Class Mandatory, discretionary, or external
Justification One sentence — why this dependency exists, not just that it does

Task 2 — Find the discretionary dependencies

At least two dependencies in the scenario are choices rather than necessities. Identify them, state what the choice buys, and state the risk the choice introduces.

Then answer: for each, what would you have to accept if you removed it to shorten the schedule?

Task 3 — Find the external dependencies

Identify every dependency that is owned outside the project. For each, record:

  • who owns it
  • what you must give them, and what they must give you
  • the lead time you cannot control
  • what the project should do now rather than when the dependency becomes urgent

Task 4 — Draw the network

Produce the network as a Mermaid flowchart with activities as nodes and dependencies as arrows. Then check it three ways:

Check Question
Every activity appears Count nodes against the activity list
Every dependency in Task 1 appears as an arrow Count arrows against the mandatory, discretionary, and external rows
No dangling logic Does any activity have a successor it does not need, or a missing predecessor?

Do not calculate dates or floats in this lab — that is Lab 10. Here you are establishing the logic only.

Task 5 — Find the missing work

The WBS contains a data-migration work package that does not appear in the dependency discussion.

  1. Write the migration activity into the network: give it a duration estimate, predecessors, and a successor. Justify each.
  2. State what you would have discovered late if you had not noticed it.
  3. Name one further activity the scenario probably needs but does not mention, and justify it.

Task 6 — Test the team's assumption

The team has assumed the security office can start the review as soon as asked.

  1. State what the schedule looks like if that assumption holds and if it is false.
  2. Write the two-sentence email you would send today to convert the assumption into a fact, naming what you need and by when.
  3. Record the assumption in the form that makes it testable, and say where it belongs (not in the network diagram).

Deliverable

  1. A dependency table with class and justification for every activity.
  2. An analysis of the discretionary dependencies, with what each buys and costs.
  3. An external dependency list with owners and lead times.
  4. A Mermaid network diagram.
  5. The three network checks, completed.
  6. The migration activity written into the network, plus one further missing activity.
  7. The security assumption converted into a checkable action.

Hints and guidance

  • Classify, don't just list. A mandatory dependency cannot be removed; a discretionary one can, and that is exactly what makes it valuable when the schedule is under pressure.
  • External dependencies are managed by booking, not by waiting. The action is to enter the queue early, not to hope the queue is short.
  • A network diagram is a claim about logic. If two reviewers cannot read it the same way, the ambiguity is in your logic, not in their reading.
  • The missing work package is the point of the lab. Every project has at least one; the skill is looking for it rather than finding it at month four.

Self-check criteria

Check How to verify it
Every activity has a class Ten rows, each labelled mandatory, discretionary, or external
Justifications are reasons, not restatements Each says why the dependency exists
At least two discretionary dependencies found F after C is one; find the others and justify your classification
External dependencies have owners Named roles, not "the university"
Network matches the dependency table exactly Node and arrow counts reconcile
Migration is written in with justification Duration, predecessors, and successor all present and argued
The security assumption became an action A dated request to a named owner exists

Reflection

  1. Which dependency, if you removed it, would shorten the schedule most — and what would it cost you?
  2. Why is an external dependency more dangerous than a mandatory internal one, even when both are unavoidable?
  3. The migration work package was invisible. What process failure allowed that, and how would you prevent it on the next project?
  4. Should the network diagram be shown to the steering committee? Justify your answer in terms of what it does and does not communicate.
Model discussion points
  1. Removing "F after C" allows the console to start after B, in parallel with the form. It shortens the calendar but requires two people on overlapping component work, risking integration rework because the console would not reuse the form's components.
  2. Because the project cannot influence it by working harder or smarter; its duration is set by someone else's queue. The only available action is early booking and active follow-up.
  3. Typically the WBS was built before the scope statement was agreed, or the migration was treated as operations rather than project work. The prevention is to reconcile the WBS against the network activity by activity — a mechanical check that finds the gap.
  4. Usually yes, but it does not communicate dates, cost, or progress; if the committee expects a date, the diagram alone will be read as a schedule and mislead them. That is what the next lab produces.

Extension challenge

Add a second team in a different city that will build the administrative console (F) while your team builds the rest. Redraw the network with the ownership boundary marked, and identify the two interfaces where the two teams must agree something in writing before either starts. Then state the single dependency you would most want to convert from "verbal agreement" to a written interface contract, and why.