Principle 9:
Strategic Aggregation of Units

Summary

Strategically grouping related Units of Effort can reveal a new, higher coordinating Unit of Effort with its own complexity, scale, and intent. Rather than analyzing tasks only in isolation, related Units may be intentionally aggregated when they share a common objective, outcome, or dependency. This aggregated Unit must be evaluated and classified separately, often requiring different coordination, governance, and resource alignment.

​

Strategic aggregation does not change the FLOW classification of individual Units of Effort; it introduces a higher coordinating Unit that must be classified and managed separately.

​​

Examples

Unit of Effort: Office Equipment Orders

Individual Units: Ten small purchase requests (PRs) for laptops, mice, and docking stations across departments.

Initial FLOW: Each appears to be a standalone FLOW A PR (low complexity – low scale) 

Aggregation Insight: All PRs support a coordinated onboarding wave for 50 new hires.

Aggregated FLOW: Coordinated onboarding equipment procurement → FLOW C, due to:

• Cross-functional alignment

• Budget alignment

• Timing and delivery logistics

Takeaway: The aggregated Unit of Effort carries its own FLOW classification and resource needs, while individual PRs remain FLOW A.

 

Unit of Effort: Training Workshops

Individual Units: Several isolated requests for Microsoft Excel training

Initial FLOW: Each appears to be a standalone FLOW A Training Request (low complexity – low scale) 

Aggregation Insight: All originate from the same department within a 30-day period.

Aggregated FLOW: Aggregation reveals a department-wide upskilling initiative. FLOW B (low complexity – moderate scale)

Takeaway: By bundling, leadership can authorize a full contract, reducing cost and improving coordination.

​

Unit of Effort: Maintenance Work Orders

Individual Units: Routine repair requests at different facilities

Initial FLOW: All appear to be FLOW A (standard maintenance) 

Aggregation Insight: All involve the same system model (HVAC-12af) and are recurring

Aggregated FLOW: Could be bundled as part of a new preventative maintenance program. 

Takeaway: Aggregating reveals the need for a systemic fix rather than reactive responses.

 

Quick Case Study

A procurement office is overwhelmed with hundreds of micro-purchases. Individually, they are all FLOW A. However, they all relate to a new software rollout across departments. By aggregating them into a project bundle, the unit shifts toward FLOW C due to coordination and risk. This reclassification prompts oversight, cross department planning, and process streamlining.

​

Expanded Case Study (Complex Principle)

Context

• A logistics command is rolling out communications upgrade kits to 12 remote military installations.

• Each kit consists of around 40 parts (wires, routers, cases, batteries, mounting hardware)

• Each individual part is purchased via standard PRs – all FLOW A: routine items, easy sourcing, low dollar value

​

Initial Approach

• Each base’s supply team began processing PRs separately.

• Buyers processed them as independent, low risk requests with no project context.

• PRs were issued over several weeks. No centralized coordination existed.

• Some parts arrived early, others late. A few were ordered twice. One base forgot to order cables entirely.

​

Result

• Delays in 7 of 12 installations

• Field teams deployed without complete kits

• Emergency orders required (extra cost, overtime)

• Leadership asked why a “simple rollout” failed

​

Revised Approach: FLOW C oversight layer introduced

• A program officer was assigned to manage the communications kit rollout as a FLOW C Unit of Effort

• PRs were still processed as FLOW A by the same buyers, but:

• All PRs were tracked in a centralized dashboard

• A master kit list was validated and frozen before PRs were issued

• Orders were sequenced and bundled for shipment

• A single delivery window was enforced per base

• Delays or exceptions triggered real-time escalation

​

Outcome

• All 12 bases received kits on time

• Costs were lower due to bundled freight and early planning

• Field teams installed everything without delay

• The FLOW A work was unchanged in how it was processed, but FLOW C management enabled synchronization, visibility, and delivery.

​

Common Mistakes

• Treating related tasks as isolate units. (e.g., people process each task individually without recognizing a shared purpose.)

• Failing to reevaluate FLOW after aggregation. (e.g., teams combine tasks into a project but still classify at the original FLOW level)

• Assuming all tasks must be aggregated. (e.g., Over-aggregation dissimilar efforts into a single unit leads to irrelevant complexity)

• Delaying aggregation until after problems arise. (e.g., only recognizing a pattern in hindsight – after delays or other issues emerge)

• Ignoring strategic triggers (Time, Source, or Intent.) (e.g., failing to spot patterns like tasks from same team, same time frame, etc.)

• Not updating stakeholders on FLOW change (e.g., even when aggregation happens correctly, the updated FLOW level is not shared)

• Mixing aggregated and non-aggregated Units in reports (e.g., reporting mix of individual and bundled Units without clarity)

 

Red Flag Indicators

• You’re analyzing tasks individually even though they clearly share a common goal.

• The classification feels off (e.g., a bunch of FLOW As together clearly feel like more than FLOW A.

• You’re duplicating effort or repeating processes that could be unified under a single structure.

 

Key Diagnostic Questions

• Do these units of effort share a purpose, deadline, or dependency?

• Would bundling improve coordination or reduce confusion?

• Does the group as a whole trigger a higher level of complexity or scale then any one individual Unit?

 

Local Application Prompts

• Identify 5 small tasks today that might actually be part of a larger Unit of Effort.

• Review a recent project and ask: were any sub-tasks incorrectly FLOWed because they weren’t bundled?

​

Alignment Risks

• Misclassifying a group of low-level tasks as separate FLOW A units may lead to

• Missed coordination needs

• Understaffed or underdesigned efforts

• Decision-making that ignores systemic effects

​

Systems Design Anchors

• When designing systems, ensure the architecture supports dynamic bundling – the ability to roll up or collapse individual Units into clusters based on shared attributes or goals. This allows better FLOW classification and resource planning.

​

Role Implications

Analysts: Must identify natural clusters and propose re-aggregation.

Managers: Should define aggregation rules and thresholds (e.g., dollar value, shared vendor, timeline).

Leadership: Needs to ensure aggregated efforts receive the appropriate FLOW treatment.