Principle 7:
Evaluate Independently and Relationally

This principle focuses on external context and relationships between Units of Effort. It requires work to be evaluated both on its own and in relation to other Units that share timing, dependencies, or outcomes. While each Unit retains its own FLOW classification, viewing Units relationally can reveal a higher coordinating Unit that must be managed separately.

Summary

A task may belong to multiple Units of Effort—atomic (individual task sets) and relational (grouped task sets). Each Unit should be classified independently, based on its own scale and complexity. This dual perspective helps assess dependency, coordination, and optimization needs. Some units may appear simple on their own but become complex when viewed as part of a larger Unit of Effort.

Evaluating work relationally does not change the FLOW classification of individual Units of Effort; it reveals a higher coordinating Unit that must be classified and managed separately.

This principle complements Principle 6 by focusing on external relationships rather than internal structure.

Examples

Procurement Example

Independent: One PR for 10 office chairs – FLOW A.

Relational (Higher Unit of Effort): Coordinating five PRs from the same team, same vendor, within a single budget cycle → FLOW C
(Each individual PR remains FLOW A; the higher-level coordination Unit of Effort is FLOW C due to timing and dependency management.)

Education Example

Independent: Grading a single assignment – FLOW A.

Relational (Higher Unit of Effort): Coordinating grading for 120 assignments ahead of progress reports while aligning with curriculum changes → FLOW B or C (Individual grading tasks remain FLOW A; the coordination effort carries the higher FLOW.)

IT Example

Independent: Resetting a user password – FLOW A.

Relational (Higher Unit of Effort): Managing a system-wide credential reset for 200 users prior to a platform launch → FLOW B
(Individual resets remain FLOW A; the migration effort is the classified Unit.)

Logistics Example

Independent: Delivering a single package to a local office – FLOW A.

Relational (Higher Unit of Effort): Coordinating same-day delivery of 150 sensitive items across five locations → FLOW C or D, depending on scale (Each delivery remains FLOW A; the multi-site coordination is the higher Unit of Effort.)

Healthcare Example

Independent: Administering a single vaccine – FLOW A.

Relational (Higher Unit of Effort): Planning and executing a mass vaccination event for 3,000 people, including site setup, staffing, and reporting → FLOW D (Individual vaccinations remain FLOW A; the event itself is the Unit being classified.)

Quick Case Study

Scenario: A buyer is assigned 10 PRs, each under $5k.

Independent View: Each PR is FLOW A – low complexity and small scale.

Relational View: All PRs are for the same vendor, require bundled shipping, and have a shared deadline. Together, they are a FLOW C Unit of Effort because of timing, coordination, and vendor negotiation.

Common Mistakes

Treating every Unit in isolation and missing cumulative complexity.
Failing to group related Units, leading to redundant handling or missed synergies.
Ignoring downstream impacts caused by sequential or dependent Units.

Red Flag Indicators

High rework or delays when tasks are reviewed individually.
Surprises in delivery timelines or dependencies.
Multiple team members touching seemingly “simple” work.

Key Diagnostic Questions

What other Units of Effort are connected to this one?
Would grouping improve flow or coordination?
If this Unit were done incorrectly, what else would be affected?

Local Application Prompts

Look at a list of 20 tasks (Units of Effort) and try to group them based on vendor, goal, timing, or output.
Take one Unit and map all others it directly or indirectly connects to.

Alignment Risks

Teams treating aggregated FLOW C work as FLOW A due to item-level simplicity.
Disconnected ownership models where no one sees the full picture.
Tools or dashboards showing units separately with no way to link them.

Systems Design Anchors

Build systems that allow multi-level aggregation (e.g., PRs → Project → Initiative)
Create alerts when related Units cross FLOW boundaries when grouped.
Enable toggling between individual and relational views of Units of Effort.

Role Implications

Analysts: Need to assess both granular and grouped data.

Managers: Must ensure teams aren’t siloed by Unit-level blindness.

Operators: Should flag when individual tasks (Units) feel connected or bundled in practice.

Principle 7: Evaluate Independently and Relationally

Principle 7:
Evaluate Independently and Relationally