Project Management

Week 5: Introduction to Project Planning and Network Diagrams

Activity Identification
The Invisible Foundation of Project Planning
One of the most critical yet least understood stages of project planning is activity identification. This process defines not
what the project will deliver (deliverables), but how those outcomes will be achieved through concrete efforts (activities). If
activities are poorly defined, even the most sophisticated scheduling software will inevitably produce plans that collapse
when confronted with reality.
1.1 Relationship Between Activities and Work Packages (WBS)
In the project management literature, activities and work packages are complementary but conceptually distinct
constructs:
• Work Package: The lowest level of the Work Breakdown Structure (WBS). It represents an independent unit of work, can
be budgeted, and is assigned to a specific owner.
• Activity: A time-consuming element represented in the project network diagram.
Key Difference:
A single network activity may include one or more work packages. While the WBS represents the hierarchical structure of
work, activities represent the temporal flow of work and the logical dependencies among tasks.
1.2 Difference Between “Activity” and “Deliverable”
Although often used interchangeably, these concepts have fundamentally different managerial implications:
• Deliverable: A measurable and verifiable output produced during the project lifecycle (e.g., a technical manual, software
code, report, or building). Deliverables are typically expressed using nouns.
• Activity: The actions required to produce a deliverable. Activities are typically expressed using verbs (e.g., “writing code,”
“conducting tests”).
Managerial Importance:
Deliverables define what the project is, whereas activities define how the project is executed.
Activity Identification
1.3 Risks of Activity Detail Level: Over-Detailed vs. Under-Detailed
The level at which activities are decomposed directly affects the manageability of the project:
• Over-Detailed Activities:
Excessive detail increases management and reporting costs, generates exponentially growing calculation complexity, and
creates an illusion of “false precision.” It may also constrain the team and encourage micromanagement.
• Under-Detailed Activities:
When activity durations are excessively long (e.g., a single 26-week task), the risk of back-end loading emerges. Team
members delay effort under the assumption that “there is still time,” and delays become visible only at the end—when
corrective action is no longer possible.
• Rule of Thumb:
An activity should typically not exceed 5–10 working days or one reporting period.
Relationship Between WBS and Activities
1.4 Relationship Between Activities and Scope Control

Activities must fully reflect the approved project scope. If an activity is

omitted from the network diagram, the corresponding work is
effectively forgotten at the organizational level, resulting in a violation
of the 100% Rule.

If this omission is not detected early, the critical path is calculated

incorrectly, and the consequences appear later as cost overruns or
schedule delays.
Activity Identification
Integrated Responses to Key Questions
Is this an activity or a work package? Where do I draw the line?
If a unit of work can be budgeted and assigned to a specific owner, it is a work package. If that same unit is placed into the
project network with logical predecessors and successors—thus becoming part of the time flow—it functions as an activity.
How do I know an activity is measurably complete?
Completion should be determined using exit criteria and tangible outputs. Asking only “what percentage is complete?” can
be misleading; a finished activity should result in a document, approval, or physical output.
Why does the network diagram appear to work but collapse in reality when an activity is omitted?
Software cannot detect logical omissions; it only calculates the dependencies provided. When an activity is missing, the
critical path (longest path) appears artificially shorter, creating the illusion that there is ample slack.
Does excessive detail strengthen planning or create false certainty?
Excessive detail usually produces false certainty. The strength of planning lies not in the number of activities, but in the
accuracy of the logical relationships between them.
Precedence Relationships and Dependencies
Where Arrows Become Logic
In project network diagrams, the logic that governs the flow between activities is far more than simply drawing arrows. This
stage establishes the logical framework that determines the project’s real-world feasibility and flexibility. Precedence
relationships are the core mechanism that defines how long a project will take and which activities become critical.

Typical Precedence Relationships

2.1 Types of Dependencies (FS, SS, FF, SF)
Although Finish-to-Start (FS) is the most commonly used relationship in
traditional network diagrams, four dependency types are required to
reflect real-world complexity:
•Finish-to-Start (FS):
The successor activity cannot start until the predecessor finishes. This is
the most basic relationship
(e.g., walls cannot be built before excavation is completed).
•Start-to-Start (SS):
The successor activity can start only after the predecessor has started.
Often used to accelerate schedules by enabling overlap.
•Finish-to-Finish (FF):
The successor activity cannot finish until the predecessor finishes
(e.g., documentation cannot be completed before system testing is
finished).
•Start-to-Finish (SF):
The completion of one activity depends on the start of another. This
relationship is rarely used in practice.
Precedence Relationships and Dependencies
Integrated Responses to Key Questions
2.2 Mandatory, Discretionary, and External Dependencies •Does this activity truly need to come first, or is it just
“how we always do it”?
Dependencies between activities can be analyzed across three distinct
Discretionary (soft logic) dependencies are frequently
logical layers:
mistaken for mandatory ones due to organizational habit.
Mandatory Dependencies (Hard Logic): This unnecessarily extends project duration. During
Non-negotiable constraints dictated by the nature of the work itself planning, the key question is whether the dependency is
(e.g., walls must exist before a roof can be constructed). technically required.
Discretionary Dependencies (Soft Logic): •Is this dependency technical or a managerial preference?
Dependencies based on managerial preference or organizational norms. Technical dependencies are hard logic, while managerial
Although often framed as “best practices,” they are not technically required choices represent soft logic. Soft logic is often introduced
and may unnecessarily serialize work, reducing schedule flexibility. due to resource constraints or quality concerns, but these
links should be the first candidates for removal under
External Dependencies: schedule pressure.
Dependencies outside the control of the project team •Why am I serializing activities that could run in parallel?
(e.g., waiting for government approvals or supplier deliveries). Parallel work is often serialized due to limited resources or
2.3 Lags and Leads risk aversion. While understandable, this practice directly
extends the project’s total duration by lengthening the
To better align network diagrams with real-world conditions, lags and leads critical path.
are introduced: •How can a single incorrect dependency distort the entire
Lag: critical path?
A mandatory waiting period between activities A network diagram functions like a chain. When a
(e.g., waiting three days for concrete to cure after pouring). predecessor relationship is defined incorrectly, scheduling
software recalculates the entire project based on that
Lead: faulty logic. This may create artificial criticality or conceal
Allows a successor activity to begin before the predecessor is fully real risks.
completed, enabling schedule compression.
Network Diagrams – Logic or Drawing?
Developing Temporal Thinking, Not Aesthetic Layouts
Network diagrams represent the temporal map of a project. They are not decorative drawings but the logical skeleton of
project planning. The core issue at this stage is not how boxes are arranged, but how task dependencies and time
constraints interact to form a coherent system.
3.1 Purpose of Network Diagrams: A Complement to Gantt Charts
Gantt charts (bar charts) are popular because they provide an intuitive visualization of activities along a time scale.
However, their major limitation is their inability to clearly represent complex interdependencies between activities.
Network diagrams answer questions such as “Why can’t this task start?” or “Which activities will be affected if this task is
delayed?”
For this reason, network diagrams are primarily planning tools, while Gantt charts are better suited for reporting and
communication.
3.2 Conceptual Logic of Forward Pass and Backward Pass
•Forward Pass:
Calculates the earliest possible project completion time
(Expected Time – TE). The basic rule is that an activity can
start only after all its predecessors have finished.
Therefore, at a merge point, the largest Early Finish (EF)
value becomes the Early Start (ES) of the succeeding
activity.
•Backward Pass:
Works backward from the fixed project completion date
to calculate the latest allowable start times. The Late
Finish (LF) of an activity is determined by the smallest Late
Start (LS) among its successors. Basic Structure of an AON Network Diagram
Network Diagrams – Logic or Drawing?
3.3 The Critical Path: Why Is It the “Longest” Path?
The critical path is the longest-duration path through the network and determines the total project duration. Intuitively, just
as the strength of a chain is limited by its weakest link, the speed of a project is constrained by the slowest sequence of
activities.
Any delay in an activity on the critical path results in an equal delay to the overall project.
3.4 Network Diagrams and Uncertainty
Network diagrams manage uncertainty through the concept of slack (float). When activity durations are uncertain or
probabilistic, the PERT technique is applied to estimate the likelihood of completing the project by a given date.

Integrated Responses to Key Questions Activity Precedence Sequence (Example)

•What decisions is a network diagram meant to support?
Network diagrams support decisions regarding where to assign the
most skilled personnel, how to balance resources, and which activities
should be accelerated (crashing) when delays occur.
•Why is the critical path not necessarily the “most risky” path?
This is where the concept of sensitivity becomes relevant. If multiple
near-critical paths exist, small deviations can instantly make them •When does a network diagram simplify reality, and
critical. A network with a single critical path may actually be less risky when does it distort it?
than one with several near-critical paths. A network diagram simplifies reality when it assumes that
•Are activities with float really “safe”? activities cannot overlap (standard FS logic). It distorts
No. Activities with float often trigger Student Syndrome, leading teams reality when it ignores real-world lags or parallel
to postpone work until the last moment. Once float is consumed, these
processes such as laddering, artificially extending the
activities become critical. Float should be treated as risk insurance, not project duration.
expendable slack.
Arrow Diagrams (AOA) and the Logic of Representation
An “Outdated” Method That Still Teaches How to Think
There is a pedagogical trap in this topic: Arrow Diagramming (AOA) is often labeled as an “old method,” yet it remains one
of the most powerful tools for teaching logical thinking in project planning. While modern tools favor convenience, AOA
forces planners to confront the underlying structure of dependencies.
4.1 Comparison of AOA (Activity on Arrow) and AON (Activity on Node)
Two primary approaches are used to construct project network diagrams:
• AON (Activity on Node):
Activities are represented by nodes (typically boxes), while arrows indicate logical sequencing and dependency. Most
contemporary project management software adopts this approach.
• AOA (Activity on Arrow):
Activities are represented by arrows. Nodes (circles) represent events, marking the start or completion of activities.
Arrow Diagrams (AOA) and the Logic of Representation
4.2 The Concept and Invention of the Dummy Activity
Dummy activities were invented specifically to ensure logical consistency in AOA diagrams:
Representation Logic: Shown using dashed arrows.
Characteristics: Zero duration and no resource consumption.
Why Are They Necessary?
They prevent two activities from sharing identical start and finish nodes and allow complex precedence relationships to be
represented correctly (e.g., when Activity D depends on both A and B, while Activity C depends only on B).
A Tool That “Saves the Plan”:
Although dummy activities perform no real work, they prevent logical conflicts and rule violations within the network. In this sense,
they are planning devices that preserve coherence rather than productivity.
4.3 Strengths and Weaknesses of AOA
Strengths
Event Orientation:
AOA emphasizes milestones and critical events more explicitly.
Logical Discipline:
Planners are forced to think more rigorously about dependencies, as logical errors (such as loops) are more visible in AOA diagrams.
Weaknesses
Complexity:
AOA diagrams are more difficult to draw and interpret than AON diagrams.
Limited Flexibility:
Modern techniques such as activity splitting are harder to represent.
Dependence on Dummy Activities:
Incorrect use of dummy activities can quickly make the diagram confusing and unmanageable.
Arrow Diagrams (AOA) and the Logic of Representation
4.4 Why Modern Software Prefers AON
Most contemporary project management software (e.g., MS Project) favors AON for several reasons:
1. Visual Clarity:
Advances in computer graphics make it easier to display and read data (ES, EF, LS, LF) within nodes.
2. Avoidance of Dummy Activities:
Dummy activities add computational and conceptual overhead; AON eliminates this complexity.
3. Lower Error Risk:
Modifying and updating AON diagrams is faster and less error-prone than working with AOA diagrams.
Critical Questions to Emphasize
Is a dummy activity just “empty air”?
No. It represents a waiting point or a logical lock within the network.
Which method clarifies dependencies more effectively?
AOA, because activities (arrows) must converge at events (nodes), making dependency logic explicit.
Pedagogical Value:
Learning AOA instills milestone awareness from the very beginning of a project manager’s thinking.
Week 5 Narrative – From Tasks to Temporal Logic
Week 5 marks the transition from what a project consists of to how time actually flows within it. Project planning begins to
matter not when activities are listed, but when their logical and temporal relationships are made explicit.
The week starts by reframing activity identification as the invisible foundation of planning. Activities are not deliverables,
nor are they merely detailed to-do items; they are the units through which time, effort, and dependency enter the project
system. Poorly defined activities may still produce a schedule—but one that collapses under real-world conditions.
From there, the focus shifts to precedence relationships, where arrows stop being decorative and start becoming causal.
Dependencies are revealed as a mix of technical necessity, managerial preference, and external constraint. Understanding
the difference between hard logic and soft logic becomes essential, because unnecessary serialization quietly lengthens
the critical path and reduces flexibility.
With this logic in place, network diagrams emerge as tools for temporal reasoning rather than visual layout. Forward and
backward passes translate dependency logic into decision-relevant information: where risk concentrates, where flexibility
exists, and where it only appears to exist. The critical path is introduced not as the “most important” path, but as the one
that constrains the entire system.
Finally, Arrow Diagrams (AOA) challenge students to confront the logic beneath modern software interfaces. Dummy
activities, often dismissed as artificial, expose the discipline required to model events, milestones, and logical locks
correctly. Although AOA is rarely used in practice, it remains a powerful pedagogical lens for understanding why schedules
behave the way they do.
By the end of the week, planning is no longer about drawing charts. It becomes an exercise in temporal logic, dependency
awareness, and disciplined simplification—the mental infrastructure behind every credible project schedule.