Bottom line up front: Artificial Intelligence projects fail for the same reasons Enterprise Resource Planning, Customer Relationship Management, Robotic Process Automation, and reengineering projects failed — and business owners and change management professionals must do differently this time. This paper names the human discipline — People, Preparation, and Readiness — that the first two perspectives depend on: the AI tier taxonomy, the harness framework, the Problem Selection Architecture, and the Return Classification Gate. Paper #7 in the Thought-OS™ reading order.

Don Lovett, Fractional CFO & Managing Principal · ProjectBits Consulting · June 2026

The AI Success Architecture: the AI tier taxonomy and Return Classification Gate (calibration & classification) feeding the governance harness — In / On / Under the Loop with their detective, monitoring, and automated controls.

For the Business Owner Reading This First

If you have invested in Artificial Intelligence (AI) tools and the returns have been unclear, the problem is rarely the technology and rarely your team. The more common culprit is a sequence of decisions made in the wrong order — or not made at all. The tool was selected before the problem was defined. The problem was defined before the return category was named. The return category was named before anyone asked whether the organization was prepared to sustain the governance posture the tool required.

When results fall short, the failure tends to be attributed to adoption resistance or, worse, pinned on the business operator with a ‘you don’t understand AI well enough’ label. That framing protects the people who sold the implementation and penalizes the people who funded it. This paper proposes a different frame: business owners who take structured action — defining the right problem, selecting the right AI tier, declaring the right human oversight position, and building the measurement architecture before deployment — capture returns that are real, defensible, and compounding. Those who skip those steps tend to fund expensive science projects.

This paper gives you the vocabulary, the sequence, and the governance architecture to be the decision maker who captures the return — not the cautionary tale in someone else’s case study.

Abstract

This paper makes four arguments. First: the failure patterns visible in AI deployments today are structurally identical to those from prior enterprise technology hype cycles — Manufacturing Resource Planning (MRP), Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), business process reengineering, and Robotic Process Automation (RPA) — and the lessons from those cycles exist in the change management literature and are not being applied. Second: the two disciplines named in The Two Perspectives — knowledge governance and operational data integration — are necessary but not sufficient. A third perspective, People, Preparation, and Readiness, closes the gap that neither technical architecture nor data governance addresses alone. Third: every AI investment must be anchored to one of three return categories — drive revenue, save cost, or keep you out of jail — and the measurement architecture that validates the return must be designed before deployment, not discovered afterward. Fourth: change management professionals carry a dual obligation — to coach business owners toward better AI outcomes and to demonstrate the practices they teach from their own operational experience, not from a few exploratory prompts.

The paper introduces a precise taxonomy distinguishing generative AI, structured AI, and agentic AI, and connects that taxonomy to the ProjectBits CFO Operating System (CFO-OS) Harness Framework, which defines four human-AI relationship positions — Above, In, On, and Under the Loop — as the governance architecture that determines whether AI deployment is a managed, accountable capability or an unreviewed autonomous actor. It introduces a Problem Selection Architecture grounded in decision science and connects problem selection to a Return Classification Gate anchored in governance frameworks including the Committee of Sponsoring Organizations (COSO), Control Objectives for Information and Related Technologies (COBIT), and the National Institute of Standards and Technology (NIST) AI Risk Management Framework (AI RMF). The intellectual lineage runs from Peter Senge and Prahalad-Hamel through the reengineering and RPA waves to the harness governance architecture required for responsible agentic AI deployment today.

1. What We Mean by AI

Before any change management framework can be applied to AI adoption, we need to be precise about what AI means in 2026. The term is being used to describe three substantially different categories of technology with different capability profiles, different reliability characteristics, different governance requirements, and very different implications for human oversight and return measurement. Treating them as interchangeable is one of the primary reasons AI investments are miscalibrated at the point of the purchase decision.

The conflation of these categories produces a repeating pattern: a vendor demonstrates a generative AI capability in a curated environment. The business owner maps it to a use case that requires structured AI with governed data and documented processes. The deployment produces inconsistent results because the governance architecture appropriate for structured AI was never built. The post-mortem blames adoption resistance or pins the failure on the business operator with a ‘you didn’t understand it well enough’ label. The actual cause was categorical mismatch between what was purchased, what the use case required, and what return category the investment was targeting.

Generative AI — the co-pilot tier

Generative AI alone — the Large Language Model (LLM) tier that includes tools like ChatGPT, Claude, Gemini, and their embedded equivalents appearing across productivity software — produces text, analysis, code, images, and structured content on demand in response to prompts. It is the co-pilot model: the business owner or their team provides context and direction, the AI generates a draft or analysis, and a human evaluates and acts on the output.

Generative AI has no persistent memory of prior interactions beyond the current session, no inherent awareness of the organization’s accessible digital corpus, and no ability to take action in external systems. It is a reasoning and generation engine, not an execution engine. Its outputs are probabilistic — statistically likely responses given training data and the current prompt, not a deterministic application of explicit rules. A confident-sounding output is not evidence of a correct one.

The appropriate human relationship with generative AI is consistently In the Loop or Above the Loop — positions defined in Section 3. Generative AI deployed without human review of individual outputs is generative AI deployed outside its appropriate governance tier, regardless of how impressive the demonstration appeared.

Structured AI — the governed tier

Structured AI is generative capability that has been grounded, constrained, and governed by the organization’s own knowledge, data, and policy architecture. This is where Retrieval-Augmented Generation (RAG), domain-specific fine-tuning, classifier pipelines, and policy enforcement live. The AI’s outputs are shaped by the organization’s accessible digital corpus, bounded by its documented rules, and auditable against its standards.

This is the tier that The Two Perspectives was written to address. Knowledge governance and operational data integration are the prerequisites for structured AI because they are the architecture that makes grounding, constraining, and governing possible. A business owner attempting to deploy structured AI without a governed knowledge corpus and integrated operational data is attempting to build the second floor of a building without a first floor. The outputs will look like structured AI while behaving like generative AI with better marketing.

Policies that govern structured AI may be explicit, documented, and enforced systematically through automated rules — or they may be logically sound but not yet systematically enforceable, depending on the decision type and the maturity of the governance architecture. That distinction matters for audit defensibility: a policy that exists only in a document and is not enforced in the workflow is an intention, not a control.

Agentic AI — the execution tier

Agentic AI executes multi-step workflows, makes sequential decisions, and takes actions in external systems — scheduling, filing, transacting, communicating, querying, updating — with varying degrees of human involvement depending on how the governance architecture has been designed. This is the tier where the distance between an impressive demonstration and a production-ready deployment is largest, and where the consequences of miscalibrated governance are most significant.

An agentic system is not a tool that produces outputs for human review. It is an actor that produces consequences in systems the business depends on. The scale of those consequences compounds with the volume, variability, and velocity of decisions the agent makes: agentic systems can touch dozens of connected applications, process large numbers of decisions within a short window, and produce audit trails that are significantly harder to reconstruct after the fact than any prior automation generation. The RPA generation discovered that connecting and directing applications through optimistic screen scraping — assuming the underlying system’s moving parts would stay fixed — was neither scalable nor maintainable. Agentic AI inherits that lesson at higher stakes.

The CFO-OS Harness Framework enforces governance boundaries in agentic deployments through an approval gate — a checkpoint in the workflow where the system pauses and requests human authorization before taking consequential action. This gate is either built into the architecture by design or it is absent, in which case the system acts without meaningful authorization. The full technical specification of this mechanism, including the approval gate architecture and the six-state workflow machine, is treated in the CFO Operating System whitepaper.

Agentic AI without a defined harness position and explicit approval gates is not a managed AI deployment. It is an unreviewed autonomous actor operating inside the organization’s systems. In COSO terms, it constitutes an undocumented control environment change with potential audit and regulatory exposure. In practical terms, it is the setup for the kind of failure that becomes visible only after it has propagated to a scale that is difficult or costly to reverse.

The Taxonomy Test. Before any AI project is scoped, name the tier: generative, structured, or agentic. The governance architecture, human oversight model, return category, readiness requirements, and harness position all follow from that answer. Skipping this step produces the categorical mismatch that is among the most common and most expensive AI project failure modes — and one that business owners, not their vendors, tend to absorb.

2. The Evolution Line Nobody Is Reading

The AI adoption wave of the 2020s did not arrive without predecessors. It is the latest point on an evolutionary line that runs from traditional workflow automation through robotic process automation and intelligent automation to the generative and agentic systems being deployed today. Each generation expanded capability. Each generation also expanded the economic and efficiency consequences when governance was inadequate. And each generation was deployed with roughly the same governance maturity as the one before it — because the business owners and project teams buying the new capability were rarely the ones who had done the post-mortems on the prior one.

What changes with each generation is the speed of the hype cycle and the sophistication of the vendor community. Vendors in the current AI cycle are often prepared to offer meaningful initial discounts and rapid onboarding — until the capability becomes embedded in the organization’s workflows and the switching cost makes replacement difficult. Business owners who recognize this pattern early are in a position to negotiate governance requirements, audit rights, and exit provisions before the dependency is established.

The full evolutionary arc

MRP and ERP (1980s–1990s): the process discipline lesson. Software does not change behavior — process redesign does. Implementation failure rates were frequently documented above fifty percent. Root cause was consistent: underprepared business operators, undertrained workforces, and change management treated as a line item rather than a workstream. The financial controls expected by early COSO thinking were rarely extended to the new system’s control environment.

Business Process Reengineering (early 1990s): the prioritization lesson. Correct methodology applied without a prioritization filter produces expensive disruption without strategic return. Prahalad and Hamel’s core competency framework was the correction the reengineering wave needed and largely ignored.

CRM (late 1990s–2000s): the adoption discipline lesson. Tools that don’t fit the workflow don’t get used. Data quality degrades when entry discipline isn’t established. Gartner documented failure rates between forty-seven and sixty-three percent across CRM implementations — figures that would have been familiar to anyone who lived through ERP.

RPA (2010s): the process understanding lesson. Bots fail when the underlying system’s moving parts change, when exceptions appear that the rule set didn’t anticipate, and when processes that looked standardized turn out to have informal variants that may not be documented anywhere. Business owners who succeeded with RPA were those who invested in process understanding and documentation before automating. Those who automated the mess first paid for it twice.

Intelligent Automation (2010s–2020s): the confident-wrong-answer lesson. Combining RPA with Optical Character Recognition (OCR) and basic Machine Learning (ML) classification handled more exception types but introduced a new failure mode: the system processed exceptions it wasn’t equipped to handle, producing wrong outputs without flagging uncertainty. The human reviewer who would have caught those cases had often been removed as part of the efficiency justification for the automation.

Generative, Structured, and Agentic AI (2020s–present): all prior lessons apply simultaneously, at higher speed, with larger blast radius. The volume, variability, and velocity of decisions that agentic systems make adds a governance dimension that prior generations did not face at the same scale — alongside vendors who are prepared to offer initial discounts until capabilities are embedded and difficult to replace.

The RPA bridge

RPA deserves particular attention because it is the most direct ancestor of agentic AI and the one whose lessons are most immediately transferable. RPA practitioners developed a two-position model for human oversight: attended automation, where a human was present while the bot ran, and unattended automation, where the bot ran on its own. That distinction was a primitive version of the harness framework — it recognized that different processes required different levels of human presence but lacked the vocabulary and governance architecture to make that recognition operational across complex multi-step workflows.

Every RPA deployment built without process understanding and documentation, without exception handling logic, and without a maintenance ownership model accumulated technical debt that some organizations are still carrying. Bots may run in production that are not documented anywhere — the business rule they encode may not be formally captured, the person who authorized them may have moved on, and when the underlying system changes, the bot fails in ways that take disproportionate time to diagnose. That is AI Debt before the term existed — and it represents a COBIT governance gap: the separation between governance (who authorized and is accountable for this process) and management (who runs it day to day) was never established.

Agentic AI deployed without the harness framework will tend to produce the same debt at a scale RPA never approached. When the COSO or Sarbanes-Oxley Act (SOX) control documentation described a human review step, it did not automatically update when the human was replaced by an autonomous agent. The control gap opens silently and may remain invisible until an audit, a regulatory examination, or a consequential failure makes it visible.

The RPA Lesson. RPA taught business owners that automation without process understanding and documentation is fragile, and that removing the human reviewer without replacing the review function with something equally reliable is not an efficiency gain — it is deferred failure. Agentic AI is RPA with a graduate degree. The governance lesson applies with more force, not less.

3. The Harness Framework

The ProjectBits CFO Operating System introduces a governance architecture for human-AI relationships called the AI Harness Framework. It defines four positions that describe the relationship between human judgment and AI action across any workflow, decision type, or automation context. The framework is introduced here at the level of change management and governance application; the full technical specification — including the approval gate mechanism, the six-state workflow machine, and the Open Policy Agent / Rego (OPA/Rego) policy enforcement architecture — is treated in the CFO Operating System whitepaper.

The harness position is a governance decision, not a technical decision — and governance decisions belong to the business owner, not the implementation team. The appropriate harness position for any AI application is determined by answers to human and organizational questions: How significant and impactful are the consequences of an AI error in this specific context, including reputational damage? How quickly are errors detectable before they propagate? How well-governed is the policy the AI is operating under? How mature is the organization’s ability to monitor, intervene, learn, and fix or improve the system? Those questions cannot be answered by the vendor or the team that built or configured the system.

The harness framework has direct COSO implications. The COSO Internal Control — Integrated Framework defines control activities as the policies and procedures that ensure management’s directives are carried out. Every harness position defines a different control activity architecture. When a business owner changes their harness position — particularly when moving toward Under the Loop — they are changing their control environment. That change requires documentation, testing, and ongoing monitoring under COSO standards. For the broader ecosystem philosophy within which the harness framework operates, see The Hill-Climbing Machine.

Above the Loop

Above the Loop describes the human relationship in which the business owner or a designated governance authority authorizes investment and resource allocation, sets policy, defines the boundaries within which the AI operates, and reviews aggregate outcomes — but does not participate in individual AI decisions. The human is the architect of the system’s operating parameters and accountable for the outcomes it produces.

In COSO terms, Above the Loop is the control environment layer — the governance tone, the risk appetite, and the structure within which all other control activities operate. It is appropriate for senior leadership in well-governed structured AI deployments where policy has been rigorously defined and feedback loops that surface exceptions are functioning. It is not an appropriate starting position — it should be earned through demonstrated performance at In the Loop and On the Loop positions first.

The change management implication: Above the Loop requires business owners and leaders who understand what they are authorizing, can read the performance signals the system produces, and know what anomaly patterns should trigger policy review. This is a governor training requirement, not a user training requirement — and most AI project training programs conflate the two or address neither consistently.

In the Loop

In the Loop describes the human relationship in which a person reviews AI output before action is taken. The AI produces a recommendation, a draft, a classification, or an analysis. A human evaluates it and decides whether to act, modify, or reject it before anything consequential happens. The human is a required step in every transaction.

In COSO terms, In the Loop is a detective control activity — designed to catch errors before they propagate into systems or decisions that are difficult to reverse. It is the appropriate default position for generative AI across virtually all organizational contexts, and for structured AI in any context where the economic or reputational cost of an AI error is material.

The inside observation about In the Loop deployments is worth naming directly: when the review step is not funded with adequate time and clear criteria, team members effectively become expensive quality assurance reviewers approving outputs they do not have the context to meaningfully evaluate. A workflow that nominally includes human review but provides no time for it, no training on what to look for, and no measurement of whether reviews are happening has drifted to de facto Under the Loop — with all the governance risk that position carries — while maintaining the paperwork of In the Loop. This gap between nominal and actual harness position is among the most common and consequential AI governance failures, and among the most common sources of control deficiency findings when AI deployments eventually face audit scrutiny.

On the Loop

On the Loop describes the human relationship in which a person monitors a running AI process and retains the ability to intervene — but does not approve each individual output. The AI operates continuously; the human watches aggregate behavior, receives alerts when policy boundaries are approached, and intervenes when the feedback loop reveals problems rather than waiting for a periodic audit cycle to surface them.

In COSO terms, On the Loop combines preventive control activities (policy boundary enforcement) with monitoring activities (ongoing evaluation of whether controls are functioning as designed). It requires more sophisticated governance infrastructure than In the Loop — because the human is not reviewing individual decisions, the system that surfaces which situations require human attention must itself be trustworthy and auditable.

The change management implication: On the Loop requires a different training curriculum than In the Loop. The monitor is reading system-level signals and interpreting aggregate patterns, not evaluating individual outputs. Business owners who move processes from In the Loop to On the Loop without retraining the humans responsible for oversight have not improved their governance posture — they have moved their people out of the workflow and left the monitoring function unfilled.

Under the Loop

Under the Loop describes AI operation within pre-approved policy boundaries where the system acts without human review at the point of each individual decision. Business owners define the policy, rely on the feedback loop to reveal problems, and intervene when it does — but there is no human in the operational chain between AI decision and AI action on individual transactions.

In COSO terms, Under the Loop is a fully automated control environment. It is appropriate for a narrower category of decisions than is typically assumed: high-volume, low-variance situations where the economic cost, including reputational damage, of an AI error is bounded and recoverable, the AI’s accuracy has been validated at a production-grade standard against a measured baseline, the policy is documented and formally approved, and the feedback loop is functioning. Each of those conditions should be demonstrated, not asserted.

Under the Loop is where RPA’s unattended automation lived — and where some of its most significant failures accumulated. The failure mode is consistent: a business owner moves to Under the Loop before the conditions are met, confident the tool is reliable enough, and discovers the reliability ceiling when a failure occurs at a scale that makes it visible or even catastrophic — one that the In the Loop review step would have caught before it propagated. In COBIT terms, this represents a governance gap: the evaluate-direct-monitor cycle was not completed before autonomous action was authorized.

The Harness Principle. The harness position is not a feature of the AI system. It is a governance decision about the organization’s relationship with the AI system — a COSO control environment decision that belongs to the business owner, documented formally, and measured continuously. An undeclared harness position defaults to Under the Loop by omission. For the ecosystem context, see The Hill-Climbing Machine.

The harness as a governance decision matrix

The matrix makes visible what most AI project designs leave implicit: Under the Loop requires the highest organizational readiness, not the lowest. It is the position that business owners should arrive at through demonstrated performance at prior positions — not the position they start at because autonomous operation is the most economically efficient design on paper. In COBIT terms, the progression through In the Loop, On the Loop, and eventually Under the Loop follows the evaluate-direct-monitor governance cycle, with demonstrated performance at each stage before the next is authorized.

4. The Irony of Systems Thinking

Peter Senge published The Fifth Discipline in 1990 — the same year Prahalad and Hamel published their core competency article and three years before Hammer and Champy published Reengineering the Corporation. Senge was responding to the same organizational pathology the reengineering movement was attempting to address: processes that had calcified, organizations that could not learn from their own experience, and management approaches that optimized components while the whole system degraded.

His diagnosis was more fundamental than the reengineers’. Where Hammer and Champy said the processes are wrong and need to be redesigned, Senge said the thinking is wrong and needs to be redesigned. Business owners and their organizations fail not because their processes are suboptimal but because they cannot see the system those processes operate within. They manage symptoms rather than causes. They optimize locally and create problems downstream. They react to the most recent visible event rather than the pattern that generated it.

The AI irony

Thirty-five years after The Fifth Discipline, AI practitioners are making the same mistake Senge diagnosed in the generation that ignored him. The irony is sharp enough to name directly: we are using one of the most sophisticated pattern-recognition, relationship-mapping, and second-order reasoning tools ever built, and we are deploying it using the same fragmented, linear, solve-the-visible-symptom project logic that Senge spent his career arguing against.

Large language models reason across connected concepts and context. They can identify non-obvious relationships, surface second-order effects, and hold multiple perspectives simultaneously. The AI is doing systems thinking. The project team deploying it frequently is not. The result is AI systems that answer questions about the visible symptom competently while the systemic cause goes unaddressed — producing local efficiency improvements while leaving the constraint that actually limits the organization’s performance or its ability to serve customers untouched.

The harness framework adds a systems dimension to this irony. Moving from In the Loop to Under the Loop is a feedback loop removal decision. The human reviewer in an In the Loop workflow is a feedback mechanism — catching errors, surfacing patterns, and returning information about where the system underperforms. Removing that reviewer without replacing the feedback function is a systems design failure, not an efficiency improvement. Senge’s framework predicts the outcome: the system loses its ability to detect and correct its own errors, confidence in outputs remains high, and problems compound invisibly until something fails at a scale that makes them visible or even catastrophic.

The Senge Irony. We are deploying systems thinking tools using non-systems thinking project methods. The AI reasons across connected concepts and context that the project team is not looking for. That is not a technology problem. It is a practitioner preparation problem — and the business owner who understands this is in a position to demand better from both their vendors and their advisors.

The five disciplines as a readiness lens

Senge’s five disciplines function as a practical AI readiness lens for business owners evaluating their organization’s preparation:

• Systems thinking: does the project team understand the system the AI will operate within — the feedback loops, the second-order effects, the consequences of removing human judgment from specific decision points?
• Personal mastery: does the workforce have the clarity of purpose and commitment to continuous improvement that productive AI use requires — or will the AI tend to confirm existing biases rather than surface new information?
• Mental models: does the organization have accurate shared models of how each AI tier works, what it is reliable for, and where it characteristically fails?
• Shared vision: is there genuine organizational alignment on what the AI is supposed to accomplish and what success looks like — stated in return category terms before the tool is selected?
• Team learning: does the organization have the feedback loops and the psychological safety to surface AI failures quickly, learn, and improve — or will failures be minimized and rationalized rather than investigated?

Senge also named seven organizational learning disabilities that map onto AI project failure modes with uncomfortable precision. The belief that someone else is responsible for problems predicts the vendor-blame response when AI outputs fall short. The illusion of taking charge predicts the deployment-as-success definition that declares victory at go-live and measures nothing afterward. The fixation on events rather than patterns predicts the whack-a-mole approach to AI error correction that addresses the visible wrong answer without investigating the systemic reason it was produced.

5. The Problem Selection Architecture

One of the more expensive mistakes an AI project can make is solving the wrong problem well. The second is solving the right problem at the wrong tier, at the wrong harness position, without a return category defined. The Problem Selection Architecture introduced here is designed to prevent both — by forcing a structured sequence of diagnostic questions before any solution design begins. The sequence also surfaces a question that can save significant time and investment: who has already solved this problem, and what can be learned from their approach before building from scratch?

The architecture draws from five bodies of decision science and operations research that the AI project community has largely not encountered, because they live in academic and consulting traditions that predate the AI era and have not been translated into AI project practice. They were developed precisely for the situation AI projects face: complex, contested, human-system problems where the wrong problem definition is frequently the root cause of the right solution failing.

Step 1 — Ackoff’s mess distinction: are you solving a problem or inside a mess?

Russell Ackoff distinguished between problems — discrete, bounded challenges that can be addressed independently — and messes, which are systems of interacting problems that cannot be solved independently because addressing one changes the conditions of the adjacent ones. Most organizational situations that AI is being applied to are messes, not problems. The business owner who treats a mess as a problem will fund a solution that optimizes one variable while degrading others, generating new downstream problems that were not anticipated in the original scope.

Ackoff also distinguished between resolving a problem (accepting a satisfactory outcome), solving it (finding the optimal outcome within the current system design), and dissolving it (redesigning the system so the problem no longer exists). AI projects tend to target solving. The dissolving option — which may produce better outcomes at lower cost and with fewer governance complications — is rarely on the table because it requires questioning the system rather than optimizing it.

The entry question for any business owner considering an AI investment: is this a problem or a mess? If it is a mess, which interacting problems compose it, and what is the relationship between them? AI applied to one problem in a mess without mapping the adjacent problems tends to make the overall situation more complex, not simpler.

Step 2 — Cynefin: what domain is this problem in?

Dave Snowden’s Cynefin framework, developed at IBM in the late 1990s and published formally in 2007, categorizes problems into five domains based on the relationship between cause and effect. Understanding the domain determines the appropriate AI tier and the maximum responsible harness position:

• Clear: cause and effect are obvious to most participants; best practice applies. Generally appropriate for structured and agentic AI in well-governed contexts.
• Complicated: cause and effect require expertise to understand; good practice developed through analysis applies. Appropriate for structured AI; In the Loop to On the Loop depending on validation maturity.
• Complex: cause and effect are only visible in retrospect; emergent practice applies. Open-loop design is important; AI assists human judgment but should not routinely replace it.
• Chaotic: no discernible cause-and-effect relationship; novel practice required. AI in an advisory or research role; autonomous action is not appropriate.
• Disorder: it is unclear which domain applies. Domain classification should precede any AI application design.

Generative AI applied to Complex domain problems produces confident outputs for situations that do not have deterministic solutions. Agentic AI deployed Under the Loop in Complex domain problems is among the more dangerous combinations currently being sold at scale and implemented without this classification having been performed. The domain assessment should happen before the solution design begins.

Step 3 — Theory of Constraints: where is the actual bottleneck?

Eliyahu Goldratt’s Theory of Constraints, introduced in The Goal (1984), establishes that a system’s performance is determined by its weakest constraint — think of Herbie on the hike, the slowest member of the troop whose pace sets the speed of the whole column regardless of how fast everyone else moves. Improving any non-constraint produces local efficiency with zero improvement in the outcomes the organization or its customers care about.

Applied to AI project selection: the question is not which processes AI can improve, but which constraint is limiting the outcome the business owner cares about most. AI applied to a non-constraint produces activity metrics and zero movement on what matters. AI applied to the actual constraint — even imperfectly, even at a conservative harness position — moves the system. Most AI projects are applied to non-constraints because the constraint is harder to address and a non-constraint was visible in the vendor demonstration.

The Theory of Constraints forces the question: if this AI deployment worked exactly as demonstrated, what would change in the system’s overall performance for the outcomes the business depends on? If the honest answer is not much, the project is likely a non-constraint application and may deserve lower priority regardless of its technical elegance.

Step 4 — Prahalad-Hamel: what does this organization have to be great at?

Before the constraint analysis can be completed, there must be agreement on what the system is optimizing for — which requires clarity on the organization’s core competencies. Prahalad and Hamel’s framework asks: what are the two or three capabilities this organization must be genuinely excellent at — capabilities that are strategically differentiating, difficult to replicate, and directly connected to the organization’s ability to serve its customers or execute its mission?

AI investment tends to produce the strongest and most defensible returns when it concentrates on strengthening core competencies. Everything else is optimization at the margin. The entry question for a change practitioner in a client engagement is not what can AI do for you, but what does your organization have to do better than most to serve your clients well, and can AI strengthen that capability specifically?

Step 5 — Value-Focused Thinking: start with outcomes, not alternatives

Ralph Keeney’s Value-Focused Thinking (1992) inverts the conventional approach to decision making. Alternative-focused thinking starts with available options and evaluates them against criteria — and tends to miss the best solutions because you can only evaluate alternatives you have already considered. AI projects conducted through alternative-focused thinking start with the vendor’s capability catalog and look for organizational problems to map onto it.

Value-focused thinking starts with the outcomes the business owner genuinely needs to improve — stated in terms of the three return categories: what revenue needs to grow, what cost needs to be reduced, what risk needs to be governed — and works backward to ask what capabilities are required and whether AI is the right mechanism for building or assembling those capabilities. This sequencing tends to produce project portfolios with more defensible return profiles than alternative-focused thinking.

Step 6 — Soft Systems Methodology: structure the problem before designing the solution

Peter Checkland’s Soft Systems Methodology (SSM), developed at Lancaster University in the 1970s and 1980s, was created because hard systems engineering kept failing when applied to human activity systems — systems where the problem definition itself is contested among stakeholders. SSM’s central insight is that in human activity systems, there is rarely a single objective problem to be solved; there are multiple competing framings held by different stakeholders, and the work of problem structuring is to surface, negotiate, and align those framings before any solution is designed or identified.

The CATWOE analysis embedded in SSM forces explicit answers to six questions that AI projects routinely leave implicit:

• Customers: who benefits from the transformation the system performs, and who is affected adversely by it?
• Actors: who performs the transformation — and when that actor is an AI system, who is accountable for its performance and its errors?
• Transformation: what is being converted into what? Stated precisely, not aspirationally.
• Worldview: what assumption makes this transformation meaningful? Whose worldview does the system serve, and whose does it not?
• Owner: who has the authority to stop or modify the system? In COSO terms, who is the control owner?
• Environment: what external constraints does the system operate within — regulatory, competitive, contractual, cultural?

A business owner who cannot complete a CATWOE analysis for their AI project has not defined the problem — they have named it. An agentic AI system deployed without a documented Owner — the person with authority to stop it — has no meaningful governance accountability. In COSO terms, there is no control owner. In COBIT terms, the governance layer is missing.

Step 7 — Kepner-Tregoe: specify the problem with IS/IS NOT precision

Charles Kepner and Benjamin Tregoe’s problem analysis methodology, introduced in The Rational Manager (1965) and updated in The New Rational Manager (1981), provides the precision discipline that AI project scoping consistently lacks. Their IS/IS NOT framework specifies a problem across four dimensions — what it is, where it occurs, when it occurs, and what its extent is — alongside explicit statements of what it is not in each dimension.

An AI application scoped against a Kepner-Tregoe problem specification can be tested against a clear definition of what it is supposed to address. An AI application scoped against a vague problem statement — improve our customer experience, reduce operational friction, accelerate our reporting cycle — cannot be meaningfully tested against anything, which is a primary reason it cannot later demonstrate return on investment: the problem was never defined precisely enough to measure whether it was addressed.

The Problem Selection Standard. A problem that cannot be described using Ackoff’s mess/problem distinction, placed in a Cynefin domain, connected to a system constraint, linked to a core competency, grounded in value-focused outcomes, structured with a CATWOE analysis, and specified with IS/IS NOT precision has not been defined. It has been named. Named problems do not produce measurable returns. Defined problems do — and the business owner who defines their problem before selecting a solution is the one most likely to capture the return.

6. The Return Classification Gate

Every purposeful AI investment does at least one of three things measurably: it drives revenue, saves cost, or keeps the business out of regulatory, legal, or reputational jeopardy. An investment that cannot be connected to at least one of these return categories in a way that produces a measurable outcome before funding is approved is in danger of becoming an expensive science project. It may still have value as a learning investment — but it should be funded, governed, and measured as one: with an explicit hypothesis, a defined learning objective, staged funding, and a documented decision point at which the business owner evaluates whether to continue, modify, or stop. Keep in mind that pilots sometimes unintentionally become production systems — accumulating costs, governance gaps, and user dependencies before anyone has formally decided to deploy.

The Return Classification Gate is not a financial model. It is a governance checkpoint that forces three answers before the investment is authorized: which return category does this investment primarily target, what is the minimum credible return estimate in that category measured how and over what time horizon, and what is the cost of inaction — what does the business owner lose or risk if this problem is not addressed.

Return Category One: Drive Revenue

Revenue return from AI investment takes three primary forms. Revenue acceleration: AI that shortens sales cycles, improves lead qualification, or reduces time-to-close produces a return measurable against baseline sales cycle metrics. Revenue expansion: AI that enables the organization to serve more clients, enter new markets, or deliver higher-value services with existing capacity produces a return measurable against capacity and market penetration metrics. Revenue protection: AI that reduces client churn, improves service delivery consistency, or enables proactive relationship management produces a return measurable against retention and lifetime value metrics.

Revenue returns are usually the most compelling AI investment case and the most frequently overstated. The measurement discipline requires baseline sales cycle data, client retention data, and capacity metrics established before deployment — not after. Revenue returns attributed to AI without those baselines are assertions, not evidence — and assertions do not survive a serious budget review or an investor question.

Return Category Two: Save Cost

Cost return from AI investment takes two primary forms. Direct cost reduction: AI that reduces manual effort in defined processes produces a return measured in time recovered and reallocated to higher-value work. Cost avoidance: AI that prevents errors, reduces rework, or catches exceptions before they propagate produces a return measured in error rates and correction costs. Both require baselines established before deployment.

Cost returns are the most commonly targeted and the most commonly undermeasured. The fixation on headcount reduction and replacement as the primary cost return metric is a recipe for governance failures: it creates organizational incentives to remove human oversight before the AI is ready to operate without it, and it generates the internal resistance that adoption frameworks are then blamed for failing to overcome. The honest cost return measure is net of governance overhead: gross savings minus the total cost of operating the AI system, maintaining the harness position, funding the review or monitoring function, and updating the control documentation. Gross savings without governance cost is the number that appears in most AI ROI presentations. Net return is the number that matters.

Return Category Three: Keep You Out of Jail

Compliance and risk governance returns from AI investment are the most systematically undervalued in project justification and the most consequential when absent. ‘Keep you out of jail’ is shorthand for a category that includes regulatory compliance, transaction substantiation and audit defensibility, litigation risk reduction, data governance, and the prevention of outcomes that are low-probability but potentially existential in magnitude.

The COSO ERM framework’s 2017 update addresses this directly: risk appetite is a strategic decision, and the organization’s tolerance for specific risk exposures should be explicitly stated and connected to AI deployment decisions by someone authorized to make risk appetite assessments — not asserted by the team that built or configured the system. An agentic AI system operating Under the Loop in a compliance-sensitive domain without current COSO or SOX control documentation is not a neutral technology decision. It is an unauthorized risk appetite decision that accumulates exposure silently until an audit, an examination, or a failure makes it visible.

The asymmetry of compliance returns deserves explicit treatment. Revenue and cost returns are roughly proportional to the investment. Compliance returns are asymmetric: the probability of a specific adverse outcome may be low, but the magnitude when it occurs can range from significant to existential — a regulatory penalty, a material audit finding, a lawsuit enabled by ungoverned AI output, or a data breach traced to an undocumented agentic workflow. The COSO ERM framework exists precisely to prevent that asymmetry from being discounted in investment decisions.

AI deployments that touch regulated data, compliance processes, financial reporting, or customer-facing decisions carry a compliance return category that should be evaluated before the investment is approved. The NIST AI RMF’s four functions — Govern, Map, Measure, Manage — provide the AI-specific risk governance architecture that bridges COSO principles to current AI deployment realities.

The Return Gate Test. Drive revenue: measurable, baselined, attributed. Save cost: net of governance overhead, baselined, attributed, not dependent on headcount removal to be economically viable. Keep you out of jail: risk exposure quantified, COSO or SOX control documentation current, harness position formally authorized by someone with risk appetite authority. If the investment cannot produce a credible answer in at least one category before funding is approved, it is not ready to be funded as a business investment.

The minimum viable return threshold

Not every AI investment requires a transformational ROI. But every purposeful AI investment needs a return category, a magnitude estimate, a time horizon, and a measurement methodology — before funding. If the return does not clear the organization’s minimum threshold in at least one of the three categories, the investment should be structured as a research project and governed accordingly: explicit hypothesis, defined learning objective, staged funding with a decision point, and a documented answer to the question of what the business owner will do if the pilot does not demonstrate the projected return. Because pilots sometimes drift into production systems without a formal deployment decision, the governance documentation should specify the conditions that would trigger that decision — before the pilot begins, not after the dependency is established.

7. The Third Perspective

The Two Perspectives named two disciplines that determine whether a small business can extract value from AI: knowledge governance — a governed, canonical, retrievable corpus of the organization’s accumulated knowledge — and operational data integration — entity-resolved, integrated operational data that lets AI answer questions about the organization’s actual current state. Those two perspectives are technical and architectural. They are necessary, and they are not sufficient.

The Third Perspective is People, Preparation, and Readiness. It is the human discipline that determines whether the technical architecture the first two perspectives describe is actually adopted, sustained, and improved — or whether it becomes a sophisticated capability that the organization is not prepared to operate. The first two perspectives build the machine. The Third Perspective prepares the people who run it and the organization that depends on it.

People

The people dimension addresses a question most AI project plans never ask explicitly: who is accountable for what, at which harness position, with what training, and with what authority to intervene? Every harness position implies a different human role with a different skill set. The reviewer in an In the Loop workflow needs evaluation criteria and the time to apply them. The monitor in an On the Loop workflow needs the ability to read aggregate signals and the authority to intervene. The governor in an Above the Loop position needs policy literacy and the ability to interpret performance signals. The control owner named in the CATWOE analysis needs the authority to stop the system. When those roles are unnamed, unfilled, or filled by people who were not trained for the specific position, the harness exists on paper and not in practice.

Preparation

Preparation has five components for AI projects that the prior cycles established collectively and the harness framework makes specific:

• Process understanding and documentation: AI systems applied to processes that are not understood and documented cannot be validated, audited, or improved — and undocumented processes cannot have COSO control activities defined for them. This is the RPA lesson applied forward and upward.
• Harness position definition: for each use case, the appropriate human-AI relationship position must be declared, documented, resourced, and authorized before deployment. The review workflow for In the Loop must be designed and funded. The monitoring infrastructure for On the Loop must be built. The policy documentation and control environment update for Under the Loop must be completed and approved through the appropriate governance channel.
• Return classification: the return category, magnitude estimate, time horizon, and measurement methodology must be documented before funding is approved. Baseline measurements must be taken before the AI system goes live. Pilot governance should specify the conditions that would trigger a formal production deployment decision.
• Communication architecture: staged before launch, with clear explanation of AI tier, harness position, human oversight responsibilities, and return category tailored to each stakeholder group — including the people whose workflows will change and who need to understand why.
• Success criteria: outcome metrics defined, baselined, and agreed upon — specific to the AI tier, the harness position, and the return category — before a single user touches the system.

Readiness

Readiness is the scored organizational state assessment that answers whether the business owner’s organization is prepared to deploy a specific AI system at a specific harness position targeting a specific return category. The five dimensions:

• Leadership alignment: genuine agreement on AI tier, harness position, return category, success criteria, and COSO control ownership — documented, not assumed.
• Workforce capability: role-specific skills for the declared harness position — reviewer skills for In the Loop, monitoring skills for On the Loop, governance literacy and risk appetite understanding for Above the Loop.
• Process documentation maturity: processes understood and documented at the standard required for the declared harness position and the COSO control activity it represents.
• Governance maturity: policies explicit, approved, and enforced systematically where possible and logically where systematic enforcement is not yet achievable; COSO or SOX control documentation current; COBIT governance-management separation maintained; NIST AI RMF functions addressed.
• Measurement infrastructure: baseline metrics established, measurement methodology documented, attribution design complete, minimum viable return threshold defined and agreed upon by the business owner before investment is authorized.

The Readiness Test. If the business owner and their team cannot score themselves on these five dimensions, at the harness position they intend to deploy at, targeting the return category they have declared, before deployment begins — they are not ready to deploy. The assessment itself is the first change intervention. The score is the receipt that makes the eventual return claim credible.

8. The Practitioner’s Own House

Change management professionals coaching business owners through AI adoption face a version of the physician health problem: credibility is enhanced when the practitioner follows the practices they recommend. A change professional who advises clients to define AI tier and harness position before deployment, complete a Problem Selection Architecture before scoping, pass the Return Classification Gate before funding, and build measurement architecture before go-live — while running their own practice without any of these disciplines — is coaching from theory rather than experience.

The most common question a business owner asks after the methodology is presented is some version of: have you done this yourself, and what happened? Doing a few exploratory prompts into a large language model is not much of a credibility builder for that question. The practitioner who has taken an ecosystem approach — building a governed AI stack, applying the harness framework in their own practice, measuring outcomes against a baseline, and documenting what worked and what required adjustment — is in a fundamentally different position. The Hill-Climbing Machine illustrates what that ecosystem approach looks like in practice and why it produces a different quality of practitioner testimony than tool experimentation.

Applying the full framework to your own practice

• AI tier and harness position: what tier of AI is the practice currently using, and at which harness position? If generative AI tools are producing client deliverables without a systematic review standard, that is de facto Under the Loop for a generative tool — the highest-risk position for the least appropriate tier. Naming the actual position is the first step toward governing it intentionally.
• Problem Selection Architecture: has the practice applied Ackoff’s distinction, Cynefin domain classification, and a constraint analysis to its own operational challenges before deciding which AI tools to adopt? Or did it adopt tools because the demonstration was impressive and the subscription was affordable?
• Return Classification Gate: for each AI tool the practice uses, which return category does it target? What was the baseline before adoption? What is the current measured return? If those questions cannot be answered, the practice is accumulating AI Debt in its own operations while advising clients to avoid it.
• Governance documentation: are the practice’s COSO-equivalent control activities — the review steps, the quality standards, the oversight accountabilities — documented for its AI-assisted processes? If a client or a regulator asked for an audit of how the practice uses AI, what would that audit find?
• Knowledge corpus governance: the practice’s methodologies, frameworks, case histories, and accumulated pattern library are an accessible digital corpus. Is it governed, canonical, and retrievable by a structured AI system in a form that produces reliable outputs — or is the most valuable asset in the practice stored in a way that makes it unavailable to the tools the practice is recommending clients adopt?

The dual obligation

The change management professional entering an AI engagement in 2026 carries a dual obligation. The first obligation is to the business owner: to apply the best available knowledge — including the hard-won lessons from prior cycles that the client’s team may not have experienced — to increase the probability that the AI investment produces its intended return rather than joining the quiet accumulation of expensive lessons that nobody documented because nobody wanted to be associated with the outcome.

The second obligation is to the field: to document what works, what does not, and why, in a form that advances the collective knowledge base. The change management field built its methodology from documented ERP and CRM failures. The AI rollout failures happening now will produce the next generation of methodology — but only if practitioners are documenting them with the receipts standard: specific outcomes, specific baselines, specific attribution, specific lessons. Assertions without evidence are not receipts. Business owners deserve receipts.

Conclusion: The Complete Framework

The Two Perspectives named the technical and operational disciplines that determine AI readiness. The Third Perspective names the human discipline without which the first two cannot deliver their value. The AI tier taxonomy provides the categorical precision that investment decisions require. The harness framework provides the governance architecture that determines the human-AI relationship at each decision point. The Problem Selection Architecture provides the structured diagnostic sequence that ensures the right problem is being addressed before the right solution is designed or assembled. The Return Classification Gate ensures that investment is connected to a measurable return before it is funded. The governance stack — COSO, COBIT, NIST AI RMF — provides the audit and compliance language that connects AI deployment to the control environment the organization’s stakeholders already expect.

The plain-language test for all of it: does this AI investment drive revenue, save cost, or keep you out of jail — measurably, with a baseline, with attribution, with a defined harness position, with COSO or SOX control documentation current, at an AI tier the organization can govern responsibly? If the answer to all parts of that question is yes, build the measurement architecture and deploy. If not, return to the Problem Selection Architecture and find the problem that does pass the test. The business owner who takes that structured action is the one most likely to capture the return, defend it under scrutiny, and build from it toward the next stage of AI maturity.

The argument from the evolutionary arc is not that AI will fail. It is that AI deployed without these disciplines will tend to fail in the same ways and for the same reasons as every prior wave — and that the practitioners with the experience and the tools to prevent those failures are the change management professionals who lived through the prior cycles, documented the lessons, and built the methodologies that exist to be applied now. The question is whether those practitioners will bring that knowledge to bear with the urgency and the precision the moment requires — or whether the business owner on the other side of the table will absorb another expensive lesson that someone else’s case study will eventually use as a cautionary tale.

The Financial Maturity Staircase applies to AI governance maturity the same way it applies to financial operations: business owners move through positions sequentially, and skipping positions compounds earlier gaps rather than bypassing them. The complete framework above is not a layer added on top of an AI project. It is the prerequisite architecture that gives the AI project a legitimate claim to the return it is promising — and gives the business owner who builds it a position of genuine strength when the inevitable question arrives: how do you know this is working?

This paper is the seventh in the ProjectBits reading order. Read the series in order at projectbits.com/method. The intellectual lineage of this paper runs from Russell Ackoff, Peter Checkland, Dave Snowden, Eliyahu Goldratt, Ralph Keeney, and Kepner-Tregoe through Peter Senge and Prahalad-Hamel and the reengineering and RPA waves, to the COSO, COBIT, and NIST AI RMF governance frameworks that anchor the Return Classification Gate.

ProjectBits Consulting · projectbits.com/method · Reston, VA. ProjectBits Thought-OS™ is a trademark of ProjectBits Consulting, Inc. This paper is published for practitioner and client education.