Product-based planning II: product flow diagrams, dependencies and schedules

Lesson 8 defined what Ridgeline Water's project must deliver: a project product description, a product breakdown structure and product descriptions. This lesson completes product-based planning with the product flow diagram, which shows the order in which products must be created, and then follows the remaining planning steps from products to activities, dependencies, estimates and a schedule. CON-210 covers critical path scheduling in more depth in a construction setting; here the focus is on how PRINCE2 connects the schedule to products.

The product flow diagram

A product flow diagram (PFD) shows the sequence in which products are developed and the dependencies between them. It is usually drawn from top to bottom or left to right, starting with products that exist already or come from outside the project, and ending with the final product. Every product in the lowest level of the product breakdown structure should appear in the PFD, and the arrows show which products must exist before another can be created. Intermediate groupings from the PBS do not appear, because they are not real products.

Drawing the PFD is often where planning teams discover misunderstandings. In Ridgeline Water's case, the IT team assumed it could build the billing interface as soon as the meters arrived, but the supplier pointed out that the interface needs the head-end system configured, which in turn needs the radio network. That single conversation moved the billing interface later and changed the critical path. A PFD is cheap to draw and to change, so it is the right place to have these conversations.

External dependencies deserve their own scrutiny. They should be monitored, and the plan should note who outside the project is responsible for each one. A delay in an external product is often the earliest warning of a stage exception, because the project cannot speed it up by its own efforts.

From products to activities

Once the products and their sequence are known, the planner identifies the activities needed to create each product, including the quality activities from each product description, such as reviews and tests, and the management activities such as stage-end reporting. For simple products, one activity may be enough; for complex products, several. Activities are then given dependencies, which mostly follow the product dependencies, plus any extra ones such as a resource that cannot do two things at once.

Including quality activities as explicit activities is important. A plan that lists build the billing interface but not the end-to-end billing test will look shorter and cheaper than it really is, and the test will either be skipped or will cause a delay. PRIN-131 covers how quality activities are recorded in the quality register.

Estimates and the schedule

With activities and dependencies identified, the planner estimates each activity, using the techniques from lesson 7, and builds a schedule. A widely used method is the critical path method: a forward pass calculates the earliest start and finish of each activity, a backward pass calculates the latest start and finish that would not delay the end date, and the difference is the float. Activities with zero float form the critical path; any delay to them delays the whole stage.

The code below applies the method at product level to the pilot stage, using durations in weeks. It first sorts the products into an order where every product comes after its predecessors, then runs the forward and backward passes.

products = {   # name: (duration in weeks, predecessors)
    "Supply contract":         (0, []),
    "Pilot meters delivered":  (4, ["Supply contract"]),
    "Pilot radio network":     (6, ["Supply contract"]),
    "Head-end configured":     (5, ["Pilot radio network"]),
    "Pilot meters installed":  (5, ["Pilot meters delivered", "Pilot radio network"]),
    "Billing interface":       (8, ["Head-end configured"]),
    "Alert design":            (4, ["Head-end configured"]),
    "Customer communications": (3, ["Alert design"]),
    "Pilot live and measured": (8, ["Pilot meters installed", "Billing interface",
                                    "Customer communications"]),
}
# topological order (Kahn's algorithm)
indeg = {p: len(d[1]) for p, d in products.items()}
succ = {p: [] for p in products}
for p, (_, preds) in products.items():
    for q in preds:
        succ[q].append(p)
order, ready = [], [p for p in products if indeg[p] == 0]
while ready:
    p = ready.pop(0)
    order.append(p)
    for s in succ[p]:
        indeg[s] -= 1
        if indeg[s] == 0:
            ready.append(s)
# forward pass
es, ef = {}, {}
for p in order:
    d, preds = products[p]
    es[p] = max((ef[q] for q in preds), default=0)
    ef[p] = es[p] + d
end = max(ef.values())
# backward pass
lf, ls = {}, {}
for p in reversed(order):
    lf[p] = min((ls[s] for s in succ[p]), default=end)
    ls[p] = lf[p] - products[p][0]
print(f"{'product':25} {'ES':>3} {'EF':>3} {'LS':>3} {'LF':>3} {'float':>5}")
for p in order:
    fl = ls[p] - es[p]
    print(f"{p:25} {es[p]:3} {ef[p]:3} {ls[p]:3} {lf[p]:3} {fl:5}{'  critical' if fl == 0 else ''}")
print(f"stage duration: {end} weeks")

product                    ES  EF  LS  LF float
Supply contract             0   0   0   0     0  critical
Pilot meters delivered      0   4  10  14    10
Pilot radio network         0   6   0   6     0  critical
Head-end configured         6  11   6  11     0  critical
Pilot meters installed      6  11  14  19     8
Billing interface          11  19  11  19     0  critical
Alert design               11  15  12  16     1
Customer communications    15  18  16  19     1
Pilot live and measured    19  27  19  27     0  critical
stage duration: 27 weeks

The pilot stage takes 27 weeks. The critical path runs from the supply contract through the pilot radio network, head-end configuration and billing interface to pilot live and measured. The pilot meters have ten weeks of float in delivery and eight in installation, so delays there do not affect the end date unless they exceed the float. Alert design and customer communications have only one week of float, so they are nearly critical: a small slip there would move the end date.

What the schedule tells the board

A schedule is not just a timetable for the team. It tells the board where time tolerance is fragile and which risks matter most. For Ridgeline Water's pilot, the billing interface sits on the critical path with an estimate of eight weeks; lesson 7's three-point estimate suggested the integration work could easily run longer. The board might therefore ask for an earlier start on interface design, using a test version of the head-end, or accept a wider time tolerance for the pilot stage.

Resources and leveling

A schedule based only on dependencies assumes unlimited resources. In reality, people and equipment are limited, and two activities that could happen at the same time may need the same specialist. Resource leveling adjusts the schedule so that demand for each resource stays within what is available, usually by moving activities with float. If there is not enough float, leveling extends the schedule, and the critical path may change.

Leveling is one reason why plans need the people who will do the work. A schedule that looks fine on paper can be impossible if the same expert is booked twice. Team managers, who know their people's availability, are best placed to spot such conflicts when they plan their work packages.

Schedules in different forms

PRINCE2 does not prescribe how a schedule is presented. Bar charts, often called Gantt charts, are the most common because they are easy to read. Network diagrams show dependencies more clearly. Milestone charts suit board members who need only key dates. Agile teams may use a product roadmap and timeboxes instead of a detailed bar chart. The choice should suit the audience: the board needs milestones and the critical path; team managers need detailed task schedules.

Product-based planning in agile contexts

Product-based planning works well with agile delivery. The PBS and product descriptions define the products at a level suitable for the board, while agile teams break products down further into features and user stories in a product backlog. Timeboxes, such as two-week sprints, fix time and cost while allowing the detailed scope within each product to flex. PRIN-150 covers tailoring PRINCE2 for agile projects; here it is enough to note that the board can control at product level while teams plan iteratively below it.