Principle 20:
Custom FLOWs with Purposeful Boundaries

Summary

While the FLOW A-S (Universal FLOWS) classifications cover most work scenarios, organizations may define custom FLOWs to manage recurring or strategic Units of Effort that fall outside the standard levels. These custom FLOWs must be clearly scoped, consistently applied, and transparently governed – or risk becoming arbitrary categories that undermine system cohesion. Custom FLOWs are not exemptions; they are localized extensions anchored in FLOW logic but tailored to context-specific realities.

 

Examples

• A defense logistics center creates “FLOW L” to track long-lead items critical to readiness. It spans A-C level PRs but triggers proactive sourcing and policy review.

• A University implements “FLOW R” for research-related purchases that require separate governance, even if low complexity.

• A healthcare system introduces “FLOW X” for experimental workflows or pilot programs – marked as temporary and excluded from normal performance tracking.

​

Quick Case Study

Scenario: Introducing FLOW L for long lead procurement

​

Unit of Effort: Procurement of components with extended production timelines impacting mission readiness

​

Context: A defense logistics office noticed that PRs for long-lead items (e.g., aircraft turbine blades) were being mixed into standard FLOW B and C categories. These items required early action, monitoring, and escalation – but the FLOW classification didn’t distinguish them, leading to missed deadlines and readiness issues.

​

FLOW Response: The team created a custom FLOW (“L” for Long-Lead) applied across A-C PRs that met specific timing or supply chain risk criteria.

• Entry was triggered by a sourcing lead time threshold >300 days

• FLOW L PRs triggered automatic alerts, biweekly review, and visibility on executive dashboards

​​

Outcome:

• Readiness-sensitive PRs received prioritized and tailored handling

• FLOW L became a bridge category – not bypassing FLOW A-C logic, but enhancing it with custom rules

• Within six months, late award rate on long-lead items dropped by 40%

• The FLOW L logic was proposed for broader adoption across other commands

 

Common Mistakes

• Treating every task as its own FLOW classification without considering the project’s aggregate complexity

• Assigning the FLOW level of one hard subtask to the entire Unit of Effort without evaluating the full picture

• Forgetting that a FLOW C level effort may contain FLOW A and FLOW B tasks

​

Common Mistakes/Red Flags

• Creating custom FLOWs without documented criteria or rationale

• Using custom FLOWs to bypass governance or hide inefficiency

• Allowing custom FLOWs to overlap confusingly with FLOW A-S

• No phase-out plan for temporary or pilot FLOWs

• Proliferation of one-off FLOWs with no system-wide availability

 

Key Diagnostic Questions

• Why isn’t this Unit of Effort captured within FLOW A-S?

• What rules govern the entry, processing, and exit of this custom FLOW?

• Are stakeholders aligned on how to interpret this custom FLOW?

• Is there a mechanism to retire or evolve this custom FLOW over time?

 

Local Application Prompts

• “If we didn’t label this as a custom FLOW, which universal FLOW would it fall under?”

• “What are we solving for that justifies a custom FLOW?”

• “Could this custom FLOW become a future FLOW C or other candidate?”

• “Are we managing or masking complexity with this custom FLOW?”

​

Alignment Risks

• Fragmentation of systems and reporting

• Inconsistent workload distribution or oversight

• Loss of FLOW clarity across teams

• Normalization of exceptions as standard practice

​

Systems Design Anchors

• Create naming conventions for custom FLOWs that clarify their purpose (e.g., FLOW L = Long-Lead; FLOW R = Research).

• Define entry and exit rules for each custom FLOW.

• Build bridges between custom FLOWs and Universal FLOWs tracking to maintain cohesion.

• Establish review cycles to retire or revise custom FLOWs.

• Require custom FLOWs to be logged in a central registry with owner, scope, and rationale.

​

Role Implications

Leaders: Must approve and steward custom FLOWs with clear intent, not convenience

Analysts: Must track performance and interactions between custom and Universal FLOWs

Operators: Must be trained on how and when custom FLOWs apply

Auditors/System Architects: Must ensure custom FLOWs don’t create systemic blind spots

​