Principle 2:
Single FLOW Classification Only

Summary

Each Unit of Effort must be assigned a single FLOW level (A-D or S) based on a consistent evaluation of complexity and scale. This assignment ensures clarity, prevents overlap, and enables clean routing, governance, or action planning. A Unit of Effort cannot be two FLOW levels at once.

​

Examples

Effort:  Print updated office labels for new cubicle assignments.

Why FLOW A: Simple, low-scale, no coordination or discretion required.

Wrong Approach: Labeling it “A and B” because it affects multiple people.

Correct Application: It’s still FLOW A – the scale isn’t operationally significant.

​​

Effort:  Execute a $16,000 purchase request for toner cartridges for the division.

Why FLOW B: Minor coordination and low complexity, but moderate in scale due to dollar value.

Wrong Approach: Labeling it “FLOW A/B” just because the item is routine. Scale plays a critical role.

Correct Application: One FLOW Level – B – because it is low complexity and moderate in scale.

​​

Effort:  Prepare a contract for specialized legal translation services across five languages.

Why FLOW C: High complexity due to language coverage, legal nuance, and coordination.

Wrong Approach: Labeling it as “B for scope, C for legal” – this breaks the model.

Correct Application: One FLOW Level – C – based on the overall complexity.

​​

Effort:  Launch a sourcing strategy for new aircraft maintenance hub.

Why FLOW D: Large-scale, formal design required, wide-reaching implications.

Wrong Approach: “C+D hybrid” – because of high complexity and large scale.

Correct Application: One FLOW Level – D – based on the scale alone, even if the effort is low complexity.

​​

Effort:  Handle a congressional inquiry into a one-off vendor relationship.

Why FLOW S: Not part of normal FLOWs – highly irregular, politically sensitive.

Wrong Approach: Trying to classify it using A-D logic.

Correct Application: FLOW S – special case handling.

​

Quick Case Study

An office is reviewing a procurement package involving a small-dollar software renewal. Though one reviewer sees some coordination as being required due to IT security checks, the package as a whole has low complexity and only moderate scale – making it FLOW B. Labeling it both A and B would confuse governance and delay routing. The team agrees on FLOW B.

 

Common Mistakes

• Assigning multiple FLOW levels to a unit due to differing perspectives (e.g., one says FLOW B, another says FLOW C).

• Trying to split the classification in other ways (e.g., “it’s 80% FLOW B and 20% FLOW C”)

• Over-classifying to FLOW S when the task just has an exception, not true special handling

• Letting subjective judgement override the structured evaluation of complexity and scale

 

Red Flag Indicators

• FLOW classification keeps changing based on who’s looking.

• Two people assigned to the same unit are interpreting it’s FLOW differently.

• A Unit of Effort is described with multiple FLOW levels in documentation or slides.

• Meetings spend more time debating the FLOW level than acting on the task.

 

Key Diagnostic Questions

• Is this Unit of Effort being evaluated as a whole, or are we mixing in attributes from other levels or external fragments?

• Are we trying to account for supporting Units of Effort by giving the parent Unit a hybrid label?

• If reviewers disagree, can we isolate the source of complexity or scale that triggered the debate?

• Would another team classify this unit the same ways based on the same facts?

 

Local Application Prompts

• Take a task (e.g., “prepare a policy memo”) and assign it a single FLOW level. Justify why it isn’t a mix of the two.

• Review 3 tasks you’ve recently done. Were they FLOW A,B,C,D, or S? Force a single choice and reflect on how that clarity could have helped planning.

• Teach a teammate to classify one of your shared efforts. Do you both land on the same FLOW level?

 

Systems Design Anchors

• Systems should enforce single-tagging of FLOW for Units of Effort.

• Workflow tools should disallow hybrid or fuzzy labeling.

• Exception tracking should be handled outside the FLOW level itself (e.g., metadata or tags).

• Routing, resources, and review logic should be keyed off a single FLOW input.

 

Role Implications

Managers: Must drive consensus early on a FLOW level and resist hybridizations.

Analysts: Must document FLOW logic used per unit to defend classification in reviews.

Operators: Need clear, consistent FLOW tags to know the expected handling path.

Executives: Should audit for consistency in FLOW tagging as part of governance.