The Adaptive Work V
A navigation model for complex shared work — from the moment you recognize a need all the way through to sustainable use in the real world. Not a project template. A discipline.
Structure for work that has no simple answer
Most work fails not because people are not smart enough, but because the work was never structured well enough. The Adaptive Work V is borrowed from systems engineering's V-model and translated into the language of human work — for teams, leaders, partners, and organizations navigating complex, high-stakes shared decisions.
The left side of the V defines the work — from stakeholder need to architecture and design. The right side verifies and validates the work — from integration and testing through real-world use and sustainment. The bottom of the V is implementation — where the designed solution meets reality.
The V is not a checklist. It is a reminder that decisions made early (about requirements, functions, and design) are the ones that determine whether the solution will actually work for the people it was built for.
The Adaptive Work V — Overview
Who is affected? What do they actually need? What constraints exist?
What must the team or solution be able to do — before choosing how?
How will required functions be structured, allocated, and delivered?
The designed solution meets reality. Components are selected, built, or arranged.
Do the pieces connect? Do they work together across roles and conditions?
Does it perform the required functions? Was it built correctly?
Does it meet the real stakeholder need? Can it be used, maintained, and sustained?
What each phase actually asks you to do
Before anything else, map your stakeholders. Who uses, maintains, funds, approves, resists, or lives with the outcome? Who has authorization to represent a stakeholder group? Who is absent but needs to be present for validation to be meaningful? Who requires continuing contact rather than symbolic representation?
Requirements are not the same as preferences or assumptions. They are the bounded conditions — including constraints — that the solution must meet. Skipping this step produces solutions that solve the documented problem rather than the actual one.
- Map all affected stakeholders before forming the team
- Identify constraints as carefully as requirements
- Do not skip to solutions while requirements are still forming
A function is something the team or system must be able to do for the work to succeed. Not a role. Not a tool. Not a job title. A capability required by the work itself.
The discipline of naming functions before selecting solutions prevents one of the most common failures in shared work: choosing a tool, platform, person, or approach because it is familiar or available — rather than because it performs the required function. Functions come before products. Always.
- Name required functions before selecting team members, tools, or approaches
- Distinguish core coverage, accessible coverage, and external expert coverage
- Identify who is responsible for risk monitoring and decision documentation
Architecture is the design decision about how required functions will be organized, allocated, and connected. It is not the solution itself — it is the structure that allows the solution to function correctly. Poor architecture produces correct components that fail to integrate.
In human work, architecture includes: how authority is structured, how information moves, how decisions are documented, how stakeholder access is maintained, and how the work will be sustained once it leaves the design phase.
Individual components can each pass their own tests and still fail when combined. Integration testing exposes whether the pieces actually connect across roles, responsibilities, workflows, relationships, constraints, and the larger receiving system.
In human work, this may mean piloting a new process, running a structured decision session with the full team, or testing a communication protocol under conditions that resemble the real environment — not the idealized one.
Verification asks whether the integrated system performs the required functions. It is the discipline of checking whether the group built or arranged the solution correctly — according to the functions and requirements it defined. Verification is not the same as stakeholder approval.
In human work, verification may examine whether a new process documents decisions, supports handoffs, protects stakeholder access, meets compliance requirements, preserves role clarity, or performs the operational functions it promised.
A solution can be verified — technically correct — and still fail validation. It may meet documented requirements but not solve the actual problem. It may function in a meeting but fail in real life. It may satisfy the sponsor but harm the users. Validation brings the work back to the people, roles, conditions, and consequences that made the work necessary in the first place.
Sustainment ensures that a solution does not end at approval. A solution that cannot be used, supported, maintained, reinforced, adapted, or sustained in the receiving system — regardless of how well it was designed — has not succeeded. Transition into use is part of the work, not a handoff event.
Mini-Vs: Complete cycles for bounded work
A Mini-V is a complete Adaptive Work V cycle applied to a bounded work effort — a specific decision, a particular team challenge, a defined project component. It is not a shortcut or a simplified version.
The level of formality scales with the stakes. Low-risk, reversible, low-consequence decisions can move through a Mini-V quickly and informally. High-stakes decisions — with significant stakeholder impact, legal or ethical exposure, high cost, transition burden, or sustainment risk — require formal, documented discipline at every stage.
The discipline of the V does not disappear at low formality. The questions still apply — they are just answered more quickly, with less documentation, in contexts where the consequences of error are recoverable.
Scaling factors — when to increase formality
When errors are costly, harmful, or irreversible
When many people are affected, or affected people are vulnerable
When decisions create obligations, rights, or duties
When you can't see the full system from where you're standing
When the cost of undoing or maintaining the solution is significant
Valid team formation comes first
Do not ask who should be on the team until you know what the team must be able to do.
Rule 1: Functions Before Names
List every function the team must be able to perform for the work to succeed — before you think about who. Functions come from the work, not from who is available or politically convenient.
Rule 2: Stakeholder Access First
Who uses, maintains, funds, approves, resists, or lives with the outcome must have meaningful access — not just symbolic representation. A team that excludes key stakeholders cannot validate its own work.
Rule 3: Don't Define the Problem Until the Team Is Valid
A team that is missing key functions or stakeholder perspectives will define the problem incorrectly — systematically, reliably, and without knowing it. Form the valid group first. Then define the work.
Ready to apply the Adaptive Work V to your situation?
Download the Adaptive Work V Canvas worksheet — free, structured, and ready to use for your next bounded work effort.