Principle 15:
Every Unit Has Constraints

Summary

No Unit of Effort operates in a vacuum. It is always shaped, bounded, or influenced by a unique combination of constraints – such as time, policy, capacity, authority, budget, or data. These constraints define how a Unit of Effort can be executed and who has the power or tools to act on it.

 

Constraint vs. Unit Attribute

Unit attributes inform or trigger constraints, but they are not constraints themselves. Think of attributes as descriptors and constraints as boundaries or rules that act upon those descriptors.

​

Definitions

Unit Attributes: Inherent features or data points of the Unit of Effort.

• Dollar value, classification level, urgency, technical specs, testing requirements, NAICS code, special coding

​

Constraints: Rules, limits, or required conditions that govern how the Unit of Effort can be handled, often based on its attributes.

• If estimated dollar value of award exceeds x, then pre-solicitation review is required.

​

Summary: Attributes describe the Unit of Effort. Constraints decide what happens because of those attributes.

​

Example:

• A PR has a unit attribute of $300,000

• PRs over $250,000 require review by legal prior to award.

Why it Matters:

• This distinction helps in automating routing, designing systems, and auditing FLOW:

• Attributes are static or data-fed.

• Constraints drive actions based on those attributes.

 

Quick Case Study

A contract specialist receives a purchase request (PR) estimated at $80,000. The PR itself is the Unit of Effort. However, it must be awarded under the $100,000 simplified acquisition threshold, comply with FAR requirements, be processed with 7 days, and align with the team’s available bandwidth. These constraints dictate whether the specialist can award it solo or must escalate it, adjust terms, or reassign it.

​

Common Mistakes

• Treating constraints as fixed when they’re negotiable. (e.g., assuming a hard deadline without confirming flexibility.)

• Ignoring hidden or systemic constraints. (e.g., a system that only allows certain codes or formats.)

• Failing to document or communicate constraints (e.g., leaving out the funding expiration date in a handoff)

• Assuming constraints are the same across Units of Effort. (e.g., different PRs or tasks may have different policy ceilings or rules)

 

Red Flag Indicators

• A Unit of Effort bounces repeatedly between people or departments.

• No one is sure who has final authority, or which rule applies.

• The same effort takes widely different amounts of time in different offices.

• People rely on “tribal knowledge” rather than documented constraints.

 

Key Diagnostic Questions

• What are the hard constraints on this Unit of Effort? (e.g., time, cost, authority)

• Which of these constraints are policy-driven, system-driven, or person-driven?

• Are any constraints outdated or incorrect?

• Who owns or governs each constraint?

 

Local Application Prompts

• List all the constraints affecting a current Unit of Effort you’re handling.

• Identify one constraint you could negotiate, reframe, or remove.

• Ask a peer what constraints they operate under – are they different?

 

Alignment Risks

• Misaligning the Unit of Effort with someone not authorized to act under its constraints.

• Overlooking dependencies that are constraint-driven (e.g., legal review required over $50k).

• Designing processes that assume constraints don’t exist or won’t shift.

​

Systems Design Anchors

• Build intake systems that capture constraints explicitly.

• Use constraint types (e.g., legal, temporal, procedural) as metadata to route work.

• Make constraints auditable – e.g., every action can trace back to a constraint set.

​

Role Implications

Analysts: Can map constraints to bottlenecks for systemic improvement.

Leaders: Must routinely review which constraints are serving the mission and which are obsolete.

Operators: Should be empowered to challenge unnecessary or unclear constraints.