Principle 14: Classification Independent of Who Performs It

This principle separates the nature of the work from the capability of the person performing it. A task does not become simpler because an expert handles it, nor more complex because a junior struggles. FLOW classifications remain stable regardless of assignment.

Summary

The FLOW level of a Unit of Effort should be determined based on its inherent scale and complexity, not the skill or experience of the person assigned to it. A simple task doesn’t become FLOW C just because a junior employee struggles with it; nor does a complex task drop to FLOW A because a seasoned expert handles it with ease.

Examples

Unit of Effort: Reviewing a simple PR for office supplies using a templated checklist.

Performer: Senior contracting officer.

FLOW Classification: FLOW A – low complexity/low scale.

Why: The task is inherently simple, regardless of how skilled the reviewer is.

Unit of Effort: Creating a custom procurement strategy for a joint-service multi-year equipment contract with international stakeholders.

Performer: Expert with 20 years of experience.

FLOW Classification: FLOW D – High Scale

Why: The strategic design and cross-system coordination drive the classification, not the expert’s confidence.

Unit of Effort: Generating a monthly report using a semi-automated dashboard with minor manual edits.

Performer: Intern.

FLOW Classification: FLOW B – low complexity/moderate scale.

Why: The task structure is consistent and scalable, even if the intern struggles.

Incorrect Examples

Unit of Effort: Approving pre-priced catalog items in a purchase portal.

Performer: Intern who takes a long time and asks many questions.

FLOW Mis-Classification: FLOW C – high complexity/low scale.

Correction: Still FLOW A – task is inherently simple and standardized.

Unit of Effort: Manual review of flagged vendor quotes for risk.

Performer: Automation bot with AI Pre-Sorting.

FLOW Mis-Classification: FLOW A because the bot makes it look easy.

Correction: Still FLOW C – the discretion and risk analysis define the task complexity, not the automation.

Quick Case Study

Scenario: A senior analyst processes a highly technical procurement requiring multiple stakeholder approvals, custom contracting, and strategic coordination.

Mistake: Classifying the Unit as FLOW A because the analyst completes it easily.

Relational View: The Unit of Effort remains FLOW C due to its inherent complexity and coordination needs – regardless of who performs it.

Common Mistakes

Basing FLOW on who’s assigned instead of the actual task design.
Downgrading FLOW level because a high performer completes it quickly.
Upgrading FLOW level just because someone struggles with it.
Ignoring system implications of complexity when masked by expertise.

Red Flag Indicators

“It’s easy for her, so it must be simple”
“Let’s assign it to our best person and call it FLOW A.”
“He couldn’t handle it – maybe it’s FLOW C?”

Key Diagnostic Questions

If someone new were assigned this, how much discretion or coordination would be required?
What would happen if we assigned this to someone at a junior level?
Does the task involve decision-making, escalation, or cross functional planning?

Local Application Prompts

Reclassify one Unit of Effort currently tied to a specific person by evaluating that task only.
Review historical workflows: were any reclassified due to who performed them?
Challenge your team: “Would this FLOW level still apply if a temp did it?”

Alignment Risks

Misallocation of Resources (overloading high performers with hidden FLOW C Units of Effort)
Skewed reporting on complexity, making workflows appear simpler than they are.
Failure to scale processes because classification was tied to elite performers.

Systems Design Anchors

Design roles based on expected FLOW types, not personal ability.
Use standardized assessment criteria to classify Units of Effort.
Establish escalation (assignment) paths that reflect FLOW, not individual bandwidth.
- Escalation paths should be based on the inherent complexity and scale of a task (its FLOW classification) – not on who happens to have time or is good at figuring things out.
- In other words:
  - Escalate FLOW C tasks to roles designed to handle FLOW C, not just to “whoever can handle it right now.”
  - Don’t route high complexity issues to someone just because they’re smart or available – that masks true workflow design needs.
- If you escalate or assign based on people, not FLOW, you:
  - Overload capable individuals with mismatched work.
  - Break the system’s ability to scale or standardize.
  - Obscure the fact that a Unit of Effort should have had a more structured response.
- For example, let’s say:
  - A PR is created that is low complexity and moderate in scale (FLOW B)
  - A former colleague calls the manager and requests an informal expedite for the PR. Instead of assigning it to a FLOW B buyer per FLOW protocol, the manager sends it to “Rachel”, a senior FLOW C buyer who’s known to move things fast.
  - Over time Rachel becomes the default go-to, not because it is her job, but because she’s fast and capable.
    - Thus, an ongoing opportunity cost is incurred every time Rachel processes a PR that is not FLOW C.
- In summary, escalate or assign tasks (Units of Effort) based on what they are, not who’s around to fix them.
  - In this way the system is resilient, repeatable, and role aligned – not dependent on heroic effort or informal fixes.

Role Implications

Analysts: Need clarity on what defines FLOW beyond individual execution.

Managers: Must avoid shaping FLOW definitions around high performers.

Trainers: Should emphasize complexity awareness over speed of completion.