Transformation Is Not a Sequence
 Why organizational transformation does not unfold as a linear path from current state to future state Transformation is often represented as a journey. There is a current state. There is a desired future state. Between them sits a transformation program designed to move the organization from one to the other. The logic is familiar: Current State → Transformation → Future State It is useful. It is also potentially misleading. Because organizations do not stop changing while transformation is taking place. People respond to new conditions. Technologies create possibilities that did not exist when the transformation was designed. Decisions made in one part of the organization alter conditions elsewhere. New capabilities emerge. Existing ones may become less relevant. Customers change their behavior. Competitors respond. Regulations evolve. Assumptions become obsolete. And every intervention changes the system into which the next intervention will arrive. Transformation is not a sequence of changes. It is an evolving interaction among changes. That distinction matters. The Comfort of the Sequence There are good reasons why we think about transformation sequentially. Sequences make complexity manageable. We diagnose the current situation, define a target state, identify gaps, design initiatives, establish milestones, assign responsibilities, implement changes and measure progress. There is nothing inherently wrong with doing this. Organizations need direction. Transformation requires coordination. Investments require decisions. Dependencies need to be understood. People need some visibility into where the organization is trying to go. The problem begins when a useful planning representation becomes a theory of how transformation actually happens. A roadmap can easily create the impression that organizational change behaves like the roadmap itself. First A. Then B. Then C. Finally D. But while A is being implemented, people respond to it. Those responses may change B. The consequences of B may reveal that C is no longer appropriate. Something happening outside the organization may make D less desirable than it appeared when the transformation began. And something learned along the way may make possible an outcome that nobody could have specified at the beginning. The roadmap has remained sequential. The organization has not. Organizations Are Systems, Not Sequences Systems thinking has challenged this way of understanding organizations for decades. Russell Ackoff emphasized a fundamental property of systems: the behavior of the whole depends not only on its parts, but on how those parts interact. That distinction changes how we think about transformation. If an organization is treated as a collection of components, transformation can appear to be a series of interventions: change the technology, redesign the process, restructure the roles. But changing a component also changes some of its relationships with other components. And those relationships matter. Consider the introduction of AI into a workflow to improve productivity. The initial intervention may appear straightforward: automate or augment part of the work. But once that happens, the nature of the remaining human work may change. If AI performs more of the initial analysis, professionals may spend more time reviewing, interpreting or handling exceptions. That can change roles, coordination and what managers need to do. It may affect decision rights or escalation paths, alter which capabilities people need, and change the work through which some of those capabilities develop. Eventually, new human and computational capabilities may make another redistribution of work possible. What began as a technological intervention has become an organizational process. Not because somebody necessarily designed every consequence. But because changes interact. The same principle applies beyond AI. A new governance mechanism can change decision behavior. Greater team autonomy can change coordination requirements. The intervention enters an existing system of relationships. The system responds. And that response becomes part of the context for what happens next. Cause and Effect Do Not Disappear To say that transformation is not sequential is not to say that it is random. Nor does systems thinking eliminate causality. It asks us to understand causality differently. Peter Senge distinguished detail complexity — situations involving many variables — from dynamic complexity, where cause and effect may be separated in time and space and where apparently obvious interventions can produce non-obvious consequences. That distinction is particularly important in organizational transformation. An intervention can produce direct effects. Those effects can generate second-order consequences. Those consequences can feed back into the conditions that produced them. Several changes can reinforce one another. Others can counteract one another. Some effects appear quickly. Others become visible only after months or years. An organization may decentralize operational decisions while centralizing data. It may remove hierarchical layers while increasing digital monitoring. It may improve current productivity while changing the experiences through which future capabilities develop. These developments are not necessarily contradictory. They appear contradictory only when transformation is imagined as movement along a single axis. Organizations change across multiple, interacting dimensions. And those dimensions do not necessarily move together. Feedback Changes What Happens Next Donella Meadows placed feedback at the center of understanding system behavior. An intervention produces consequences. Information about those consequences returns to actors in the system. They respond. Their response changes subsequent conditions. That is fundamentally different from imagining transformation as a chain of independent steps. Feedback may confirm that an intervention is working as intended. It may expose unintended consequences, challenge assumptions or reveal dependencies that were previously invisible. But feedback does more than tell us whether implementation is progressing. It can change the transformation itself. What the organization discovers becomes part of the information available for subsequent decisions. Learning is therefore not something that happens after transformation. It is part of how transformation unfolds. Different Parts of the Organization Move at Different Speeds Feedback is also rarely instantaneous. Donella Meadows drew particular attention to delays and to their relationship with the rate at which a system is changing. Delays matter because a system may continue responding to conditions that have already changed, or act before the consequences of previous interventions have become visible. Organizations contain many such timescales. Technology can change rapidly. Processes may take longer. Roles may take longer still. Decision rights may remain largely untouched. Governance may react only after new risks become visible. Culture can continue carrying assumptions inherited from an organizational architecture that formally no longer exists. Capability development operates on another timescale again. The consequence is important: An organization can simultaneously contain elements of its past, its present and its possible future. A team may already be working differently while its performance system still rewards old behavior. Professionals may receive broader responsibility while decision authority remains elsewhere. A structure may become flatter while escalation practices continue to reproduce the previous hierarchy. This is more than a difference in implementation speed. Different rates of change and different feedback delays can create temporary — and sometimes persistent — misalignments across the organizational system. The organization is therefore not simply “before” or “after” transformation. Nor is it necessarily somewhere along a single path between the two. Different parts of the system may be following different trajectories. Some Changes Advance. Others Stop. Some Reverse. Sequential representations also encourage another assumption: directionality. Once an organization becomes more automated, more decentralized, more agile or more digitally enabled, the next stage is easily imagined as involving more of the same. But adaptation does not require movement in only one direction. An organization may delegate work and later restore human intervention. A team may receive greater autonomy and subsequently encounter new governance constraints. A process may be automated and later redesigned because consequences appear that were not visible initially. A structural layer may disappear while some of its functions reappear elsewhere. None of this necessarily means that transformation has failed. It may mean that the system has generated information that changes what the organization should do next. Adaptation can therefore include continuation, acceleration, redirection, stabilization or reversal. The capacity to change direction in response to evidence may itself reflect adaptation rather than transformation failure. A Snapshot Is Not a Trajectory This creates a particular problem when we observe organizations in transformation. We often describe what we see as though it were the new organizational model. But the configuration we observe today may simply be the current position of an unfinished process. A professional who once executed a task may now review work produced by AI. That division of work may stabilize. Or the boundary may move again as capabilities, evidence, risks and confidence change. Human intervention may decrease, remain essential or even be reintroduced after consequences emerge. The present configuration alone cannot tell us which trajectory will prevail. A snapshot of transformation is not the same thing as its trajectory. And trajectory is not the same thing as destination. Transformation Can Change the Problem Itself There is another reason transformation cannot be reduced to sequence. Organizations do not merely respond mechanically to interventions. People interpret what is happening. Different groups can understand the same situation differently. Experience can change those interpretations. Peter Checkland's work on Soft Systems Methodology emerged from the difficulty of treating complex human situations as though there were always a clearly defined problem waiting for an optimal solution. In such situations, inquiry and action can change how participants understand both the problem and what would count as improvement. The organization halfway through a transformation may not simply know more about the original problem. It may understand the problem differently. New evidence can challenge the original diagnosis. Stakeholder experience can reveal consequences that were previously invisible. Capabilities that did not exist when the transformation began can create possibilities that could not previously have been considered. Even the meaning of a desirable future state can evolve. Transformation therefore changes not only possible solutions. It can change the organization's understanding of what it is trying to solve. Transformation Changes the Conditions of Transformation This leads to the deeper implication. Traditional transformation thinking can implicitly treat the organization as the object of change. But organizations do not merely receive interventions. Through feedback, learning and adaptation, they change while being changed. The organization making decisions halfway through a transformation may therefore operate with different knowledge, capabilities, relationships and constraints from those that existed at the beginning. So transformation does something more profound than move an organization toward a target state. Transformation changes the organization, but it also changes the conditions under which the organization continues to transform. This does not mean that everything is unpredictable or that transformation cannot be designed. Some relationships are sufficiently understood to be planned. Dependencies can be managed. Direction can be intentional. Principles, boundaries and governance can be designed. But the more transformation involves complex human interaction, reciprocal adaptation and changing contexts, the less reliably its complete trajectory can be specified in advance. Dave Snowden's work on complexity makes this distinction particularly important. In complex contexts, relationships between cause and effect cannot always be determined reliably in advance. This shifts emphasis toward intervention, observation and learning rather than assuming that the full causal path can be known beforehand. Planning therefore remains necessary. Prediction has limits. The Roadmap Is Not the Transformation None of this makes transformation roadmaps obsolete. A roadmap can coordinate intended change, establish dependencies, responsibilities and milestones, and make direction visible. But a roadmap describes what we intend to change. It cannot, by itself, tell us everything those changes are changing. This requires another practice alongside implementation planning: continuously examining what previous interventions have changed elsewhere in the system, which assumptions still hold, which consequences are emerging and what those signals imply for subsequent decisions. The question is no longer only: What should happen next? It must also be: What is happening because of what we have already changed? That second question changes how transformation is governed. It turns feedback from a mechanism for checking progress into a source of learning about the transformation itself. And it prevents us from confusing fidelity to the plan with fidelity to the purpose. Purpose Is Not Destination If the organization changes while transformation unfolds, and its environment changes at the same time, then even the desired future state cannot always remain fixed. This does not mean abandoning purpose. Quite the opposite. The more uncertain the path becomes, the more important it is to distinguish purpose from destination. A predefined organizational configuration can become obsolete while the purpose that justified the transformation remains valid. The organization may preserve what it is trying to achieve while changing how that achievement should be organized. Transformation is therefore better understood through interacting processes of purpose, intervention, response, feedback, learning and adaptation. Plans, milestones and target states can still exist. But they exist inside a system capable of changing them. Transformation Is Not a Sequence The mistake is not representing transformation sequentially. Sometimes we must. The mistake is confusing the representation with the phenomenon. A sequence can help us coordinate interventions. It does not mean that the organization itself will transform sequentially. So a critical question during transformation is not only: Did we implement what we planned? It is also: What are the changes we have already made changing elsewhere in the system — and how should that change what happens next? Because transformation is not a sequence of interventions leading predictably toward a predefined destination. It is an evolving systemic process in which interventions interact, feedback reshapes subsequent decisions, learning changes understanding, and the organization progressively alters the conditions of its own transformation. And that creates another problem. If transformation does not unfold exactly as designed, completing the planned interventions cannot tell us what the organization has actually become. Implementation tells us what we introduced. It does not necessarily tell us what the system realized. That is where we go next. Article 10 — Implementation Is Not Realization |
Posted on: September 27, 2026 05:34 AM
| Permalink |
Comments (1)
When Integrative Capacity Falls Behind Interdependence
 How Structural Drift Can Emerge A project can have integration and still not have enough. That possibility is easy to miss. The meetings still happen. Governance structures remain in place. Project Managers, product owners, functional leaders, specialists and teams continue to perform their roles. Dashboards continue to report. Information continues to move. Decisions continue to be made. Escalation paths still exist. Nothing necessarily looks structurally broken. And yet the project system may be becoming less capable of recognizing and reconciling the material interdependencies it must recognize and reconcile. A dependency is discovered later than it could have been. A technically sound decision changes an operational condition elsewhere. A trade-off is understood by several people, but not brought together soon enough for its combined significance to be recognized. An escalation occurs correctly, but after the most valuable alternatives have disappeared. A local decision remains legitimate within one boundary while creating consequences beyond it. Individually, none of these observations proves that the project lacks integration. That may be precisely the point. The more difficult problem may begin after integration mechanisms already exist. The question for this article is therefore not: Does the project have integration? It is: Can the project system recognize and reconcile its material interdependencies with sufficient quality, reliability and timeliness for the conditions it actually faces? And what happens when the answer begins to become no? Integration Is Not a Binary Condition Project organizations rarely choose between complete integration and complete fragmentation. Most operate somewhere between those extremes. They use plans, meetings, governance forums, cross-functional teams, digital platforms, reporting systems, escalation mechanisms, standards, routines, interfaces and informal relationships to connect work that has been distributed. Some rely more heavily on identifiable integrating roles. Others distribute integrative work across teams and functions. Many combine both. The existence of these mechanisms matters. But it does not establish that the system possesses sufficient effective integrative capacity. A meeting can exist without the relevant knowledge being present. Information can be available without its significance being recognized. A dependency can be visible without anyone connecting it to a decision being made elsewhere. A trade-off can be identified without sufficient authority to reconcile it. An escalation path can function exactly as designed and still operate too slowly for the decision window involved. A governance forum can receive an issue after earlier choices have already constrained the available alternatives. So the first distinction is fundamental: Formal presence of integrative mechanisms ≠ sufficient effective integrative capacity. This is not an argument against formal mechanisms. It is an argument against treating their existence as evidence that the integrative requirement has been satisfied. Capacity Relative to What? Calling integrative capacity “sufficient” immediately creates another question. Sufficient relative to what? Not every project presents the same integrative challenge. A small project with stable interfaces, limited uncertainty and a handful of tightly connected actors may integrate effectively through relatively simple mechanisms. A different project may distribute knowledge across multiple specialist domains, authority across organizational levels, delivery across suppliers, decisions across teams, and execution across technological and geographical boundaries. The second project does not necessarily require centralization. Nor does it necessarily require more meetings, more governance or more management. But it may create a different integrative demand. That term needs care. Here, integrative demand is analytical shorthand for the material interdependencies requiring recognition or reconciliation under the conditions the project system faces. It is not being proposed as a separate construct. Nor should it become a synonym for complexity. Not every additional stakeholder, dependency or decision automatically creates additional integrative demand. The relevant issue is narrower: What material interdependencies must the project system recognize and reconcile for consequential decisions and actions to remain sufficiently coherent? Three dimensions may matter. Volume How many material interdependencies require recognition or reconciliation? More actors do not necessarily mean more material interdependencies. But as consequential relationships multiply, the number of connections requiring attention may increase. Complexity How difficult are those interdependencies to understand and reconcile? A dependency may cross technical, commercial, regulatory, operational or stakeholder boundaries. Several individually understandable relationships may also interact in ways that make their combined consequences difficult to anticipate. Velocity How quickly do relevant interdependencies emerge, change, or require response? Here, velocity should not be treated as a settled variable. It may involve the rate at which consequential relationships change, the speed at which decisions are being made, or the time available before intervention becomes less effective. The distinction matters because a system capable of reconciling an issue in two weeks may be entirely adequate in one environment and functionally too slow in another. This suggests a working proposition: Integrative capacity should not be assessed only by whether a project configuration can recognize and reconcile material interdependencies, but by whether it can do so with sufficient quality, reliability and timeliness, at a proportionate coordination cost, relative to the volume, velocity and complexity of those interdependencies. The proposition is intentionally demanding. It also needs to survive challenge. More Integration Is Not Necessarily More Capacity One tempting response to rising integrative demand is simply to add integration. More meetings. More reporting. More reviews. More coordination roles. More escalation. More governance. But integrative mechanisms themselves consume attention, time and cognitive capacity. Coordination is not free. A project system could improve its ability to recognize interdependencies while simultaneously imposing such a coordination burden that decision speed, local responsiveness or productive work deteriorates. That means effective integrative capacity cannot be measured by the amount of coordination activity. Nor can the solution automatically be more integration. The relevant question is whether the configuration provides the required integration at a proportionate coordination cost. This also prevents an unwarranted conclusion: distributed systems create more interdependence, therefore centralized systems integrate better. Not necessarily. Centralization has its own information-processing limits. Distributed configurations may place knowledge closer to the point of action, allow specialists to interpret weak signals earlier, and enable local adaptation without waiting for central intervention. The issue is therefore not centralization versus distribution. It is whether the chosen configuration can meet the integrative demand it actually faces. The Middle Condition This brings us to the condition that matters most for this article. Imagine three simplified states. In the first, important interdependencies are not integrated because the necessary mechanisms are absent. That problem is relatively visible. In the second, integrative mechanisms exist and remain sufficiently capable for the demands placed on them. There may still be mistakes, delays and uncertainty, but the architecture is broadly able to recognize and reconcile material relationships when they matter. The third condition is harder to see. The mechanisms still exist. They may even be working as designed. But the relationship between integrative demand and effective integrative capacity has changed. Interfaces may have multiplied. Decision cycles may have accelerated. Authority and knowledge may have become more distributed. External conditions may be changing more rapidly. No single mechanism has necessarily failed. But the architecture that once integrated the project adequately may no longer do so with the same quality, reliability or timeliness. This is the condition Phase 3 needs to investigate. Not: Integration exists / integration does not exist. But: Integration exists / effective integrative capacity may no longer be sufficient. That condition is not, by itself, structural drift. It is the condition under which structural drift might emerge. From Insufficient Capacity to Structural Drift This distinction matters. If effective integrative capacity becomes insufficient relative to material interdependence, that establishes a potential condition. It does not yet establish the phenomenon that follows from it. The potential mechanism lies in what that insufficiency changes. Consequential relationships may begin to be recognized later. Trade-offs may be reconciled only after some options have disappeared. Connections may be recognized inconsistently across interfaces. Local decisions may remain individually defensible while their combined effects become progressively harder to anticipate or reconcile. Teams may increasingly compensate through informal conversations, personal networks, extra checking or manual coordination. Formal mechanisms may continue operating while more integrative work has to occur around them. If such patterns persist, the project system may begin to change in ways that are not captured by the continued formal presence of its mechanisms. That potential emergent change is what this article provisionally calls structural drift. The distinction can therefore be stated more precisely: Insufficient effective integrative capacity is the condition. Degraded recognition or reconciliation of material interdependencies provides a possible mechanism. Structural drift is the hypothesized emergent change in the project system as those effects accumulate or persist. But naming that change does not establish that a distinct phenomenon exists. The term must earn its place. For the purposes of this investigation, the hypothesis is therefore: Structural drift may emerge when persistent insufficiency in effective integrative capacity progressively alters how the project system connects, reconciles or compensates for material interdependencies, even while its formal integrative mechanisms remain in place. The important word is may. Several alternative explanations remain possible. The Alternative Explanations Matter Late recognition of dependencies does not necessarily indicate insufficient integrative capacity. Some dependencies may be inherently unknowable earlier. A technological uncertainty may only become visible through experimentation. A regulatory change may create a new relationship that did not previously exist. A stakeholder may alter a requirement. A supplier may behave unpredictably. A strategic decision may legitimately change the project environment. Similarly, repeated escalation does not necessarily indicate structural drift. It may show that governance is functioning properly. Additional coordination effort does not necessarily indicate architectural weakness. It may be the appropriate response to genuinely complex work. Local decisions producing system-level tensions do not necessarily indicate insufficient integration. Some trade-offs are irreducible. Coherence does not mean eliminating legitimate conflict. And slower decisions are not necessarily worse decisions. Additional time may improve judgment where consequences justify deliberation. These alternatives are not qualifications added to protect the hypothesis. They are part of the test. If structural drift cannot be distinguished from uncertainty, complexity, normal adaptation, poor execution, weak governance or ordinary coordination difficulty, then it adds little explanatory value. What Would Make Structural Drift Distinct? For structural drift to become a useful construct, at least four things would need to be demonstrated. First, there would need to be a recognizable change in fit between the material interdependencies the system must address and its effective integrative capacity. The problem could not simply be that the project was always poorly integrated. Second, there would need to be a plausible mechanism through which that mismatch changes the functioning of the project system. Possible signals might include later recognition of consequential relationships, increasing dependence on compensatory coordination, repeated reconciliation after decision windows have narrowed, or growing divergence between formally valid local decisions and their combined system effects. Third, the resulting pattern would need to be distinguishable from credible alternatives. Fourth, the concept would need to explain something useful that simpler concepts such as poor coordination, complexity, governance failure, information overload or normal adaptation do not already explain adequately. This last test is especially important. There is already substantial thinking about coordination, information processing, interdependence, organizational fit and adaptation. So the purpose is not to rename established phenomena. The question is narrower: Does persistent insufficiency in effective integrative capacity produce a distinguishable change in the project system that is not adequately explained by those existing concepts? If the answer is no, we should use the concepts that already exist. If the answer is yes, structural drift may earn a more specific role. Drift Does Not Mean Failure Even if structural drift exists, another distinction is necessary. Structural drift ≠ project failure. A project may continue delivering while integrative capacity is under pressure. People may compensate. Experienced individuals may bridge interfaces. Informal networks may carry information that formal processes miss. Teams may absorb additional cognitive and coordination work. Managers may intervene manually. Technology may identify patterns that human actors would otherwise miss. Temporary redundancy may create resilience. These mechanisms matter because they can prevent consequences from becoming visible in conventional performance indicators. A project can therefore remain apparently successful while the architecture supporting that performance changes underneath it. But the opposite interpretation is also possible. What looks like compensation may simply be effective adaptation. Informal coordination may not indicate architectural weakness at all. It may be part of the architecture. Additional human effort may be temporary and proportionate. A system that changes its coordination mechanisms as conditions change may be demonstrating resilience rather than drift. So we cannot infer structural drift merely because the formal architecture is no longer doing all the integrative work. The test is harder: Has the system adapted its integrative capacity to changing conditions, or is performance increasingly dependent on compensatory mechanisms because effective capacity has fallen behind? That distinction will matter again when Phase 3 reaches the human burden of integrative work. Technology Can Change Both Capacity and Demand AI and other computational systems add another complication. They may increase integrative capacity by detecting patterns, dependencies, anomalies and relationships across information that distributed human actors may not see. But they may also change integrative demand. Faster recommendations can accelerate decisions. Automated action can narrow intervention windows. Computational systems can introduce new dependencies among data, models, workflows, human oversight and decision authority. Technology therefore cannot simply be placed on one side of the relationship. It may expand capacity. It may expand demand. It may change the nature of both. Article 10 challenged the assumption that computational capability determines legitimate authority or accountability. Article 11 adds a narrower question: Does technological augmentation increase the system's effective ability to integrate material interdependencies faster than it changes the integrative demand the system must meet? The answer cannot be assumed. Quality, Reliability and Timeliness Three dimensions of effective capacity now deserve particular attention. Quality Does integration produce an adequate understanding of the material relationship and its consequences? Recognizing the wrong relationship, connecting incomplete information or reconciling a trade-off on a false assumption is not effective integration simply because integration occurred. Reliability Does the system perform the integrative function consistently enough? A project should not depend entirely on whether one unusually experienced individual happens to notice a relationship at the right moment. Reliability does not require perfect detection. It asks whether the configuration can perform sufficiently dependably under the conditions it faces. Timeliness Does integration occur while meaningful intervention remains possible? This may be the most consequential dimension. A dependency recognized after a decision is irreversible has still been recognized. A trade-off reconciled after contractual commitment has still been reconciled. An escalation made after the viable option set has narrowed may still follow the correct governance path. But in each case, the practical value of integration may have changed. Integration is therefore not only about whether consequential relationships are recognized and reconciled. It is also about when. The Coordination-Cost Constraint There is one final boundary. A project could attempt to make every decision visible to everyone. It could require every interface to be reviewed. Every dependency mapped. Every trade-off escalated. Every decision cross-checked. Every signal retained. That might increase some forms of integrative visibility. It could also make the project almost impossible to operate. So sufficient integrative capacity cannot mean maximal integration. The objective is not to eliminate every possibility of local incoherence. It is to provide enough capacity to recognize and reconcile material interdependencies with adequate quality, reliability and timeliness without imposing disproportionate coordination cost. That word, proportionate, is doing important work. Because a system that preserves coherence only by consuming unsustainable attention may not possess sufficient effective integrative capacity. It may simply be paying increasingly more to compensate for the architecture it has. What Article 11 Can and Cannot Conclude The analysis supports several distinctions more strongly than it supports a new construct. First: The existence of integrative mechanisms does not establish sufficient effective integrative capacity. Second: Integrative capacity is meaningful only relative to the material interdependencies the system must recognize and reconcile. Third: More coordination activity is not equivalent to greater effective integrative capacity. Fourth: Quality, reliability, timeliness and coordination cost matter alongside formal mechanism availability. Fifth: A mismatch between effective integrative capacity and material interdependence is not itself evidence of structural drift. Sixth: Neither insufficient integrative capacity nor structural drift, if it exists, establishes project failure. These propositions are defensible. A stronger claim is not yet. We do not yet have sufficient grounds to conclude that persistent insufficiency in effective integrative capacity produces a distinct phenomenon that should be called structural drift. What we have is a hypothesis worth carrying forward: Structural drift may emerge when persistent insufficiency in effective integrative capacity progressively changes how a project system connects, reconciles or compensates for material interdependencies, even while formal integrative mechanisms remain present. That hypothesis now has a specified antecedent condition. It has potential mechanisms. It has alternatives. It has boundaries. And it has conditions under which it should be rejected. That is enough for the investigation to continue. The More Difficult Question The easiest integration problems are often the visible ones. A missing governance mechanism can be created. An unclear interface can be clarified. An absent decision right can be assigned. A known dependency can be managed. The harder problem may be a project system in which all the expected mechanisms are still present, each appears individually legitimate, and yet their combined capacity is no longer sufficient for the relationships the system must address. Nothing has necessarily failed. But something may be changing. And if that change is real, its consequences may not appear first in schedule, cost or scope. They may appear in the relationship between responsibility and the conditions required to exercise it. That is where the next inquiry begins. Article 12: When Accountability Becomes Structurally Misaligned. |
Posted on: September 25, 2026 04:49 AM
| Permalink |
Comments (2)
PHASE 3 - THE CONSEQUENCES
 Opening Note What Happens When Integrative Capacity Is No Longer Enough? Phase 2 ended without prescribing a new project architecture. That was deliberate. Across five deconstructions, THE AWAKENING questioned relationships that project organizations can easily treat as if they were inseparable. Integration does not automatically imply one integrator. Accountability does not automatically imply coincident authority and causal capacity. Control does not automatically imply centralization. System contribution does not automatically imply role obsolescence. And historical human performance does not automatically establish human exclusivity. The purpose was not to prove that familiar roles, structures or practices should disappear. It was to separate what had been bundled together so that each relationship could be examined more carefully. That work changes what can legitimately be assumed. But it does not yet tell us what happens when the resulting project configuration encounters integrative demands it may no longer be able to meet. That is where Phase 3 begins. From Assumptions to Consequences A project system can distribute leadership and authority. It can locate knowledge across specialists, teams and organizational boundaries. It can allocate different decision rights to different actors. It can combine human and computational contributions. It can use governance mechanisms to establish boundaries, thresholds, escalation paths and intervention rights. And it can distribute integrative responsibility rather than concentrating it in one role. None of these characteristics necessarily creates a problem. Distribution is not fragmentation, and integration does not require every consequential relationship to be recognized by one person. But one requirement remains. The project system must somehow remain capable of recognizing and reconciling the material interdependencies that arise within and across the way its work, knowledge, authority and decisions are distributed. That requirement was already visible in Phase 1. Phase 2 challenged assumptions about where the functions required to satisfy it must reside. Phase 3 asks a different question: What happens when the system's effective integrative capacity becomes insufficient relative to the material interdependencies it must recognize and reconcile? The question is not whether integration exists. It is whether the integrative capacity of the project configuration remains sufficient for the conditions the system is actually facing. Integration Can Exist and Still Be Insufficient Organizations rarely operate with no integrative mechanisms at all. They have meetings. Governance bodies. Project Managers. Cross-functional teams. Dashboards. Escalation paths. Planning processes. Information systems. Reviews. Committees. Standards. And increasingly, computational systems capable of detecting relationships across large volumes of information. Their presence matters. But presence is not the same as capacity. A system may possess mechanisms intended to integrate work and still struggle to recognize consequential interdependencies early enough. It may recognize them but fail to connect the relevant knowledge. It may connect the knowledge but fail to reconcile competing implications. It may identify a trade-off but escalate it too slowly. It may escalate appropriately but only after meaningful alternatives have disappeared. Or it may achieve integration, but at a coordination cost that becomes increasingly difficult to sustain. This creates a distinction that will govern Phase 3: Formal presence of integrative mechanisms ≠ sufficient effective integrative capacity. A more demanding question is therefore required: Can the project system recognize and reconcile material interdependencies with sufficient quality, reliability and timeliness, at a proportionate coordination cost, relative to the volume, velocity and complexity of the interdependencies it faces? That proposition is not yet a conclusion. It is one of the propositions Phase 3 must test. Capacity Must Be Considered Relative to Demand Integrative capacity has little meaning in isolation. A configuration that works adequately under one set of conditions may become insufficient under another. A small project with limited interdependence may rely successfully on informal conversations among a few experienced people. The same mechanisms may become less reliable as the number of actors increases, decisions accelerate, authority becomes more distributed, specialized knowledge becomes more fragmented, organizational boundaries multiply, or contractual, regulatory and technological dependencies become more complex. AI-enabled systems may also increase the speed at which analysis, recommendation and action occur. What changes may be the relationship between what we might provisionally describe as integrative demand and the effective integrative capacity available to meet it. But that relationship should not be converted prematurely into a universal law. More interdependence does not necessarily produce failure. More complexity does not necessarily overwhelm integration. Distributed configurations may develop highly effective mechanisms for connecting partial knowledge and reconciling consequences. Technology may increase integrative capacity as well as integrative demand. Standardization may reduce the number of relationships requiring active reconciliation. Modularity may contain the propagation of consequences. Clear interfaces may reduce coordination requirements. And experienced actors may recognize patterns that formal mechanisms miss. Phase 3 must therefore examine not simply whether integrative demand increases, but whether, under particular conditions, effective integrative capacity becomes insufficient relative to it. Failure May Not Begin With Failure If integrative capacity becomes insufficient, the first visible consequence may not be project failure. The project may continue. Milestones may still be achieved. Governance meetings may still occur. Dashboards may remain green. Individual decisions may remain locally defensible. And each function may continue to perform competently within its own domain. Yet something may begin to change between those domains. A dependency is recognized later than it could have been. A trade-off is deferred. A decision remains locally rational while transferring consequences elsewhere. An escalation occurs after the range of viable alternatives has narrowed. Someone absorbs additional coordination work to compensate for a weak interface. Formal accountability remains attached to an actor whose practical capacity to influence the relevant outcome has diminished. None of these observations, individually, establishes a distinct phenomenon. Nor do they prove that insufficient integrative capacity caused what occurred. But they identify the territory Phase 3 must investigate. The possibility is that systemic difficulty may become visible through friction, delay, unresolved trade-offs, compensatory human effort, accountability tensions or narrowing option space before appearing as conventional project failure. Whether these effects form coherent causal patterns, under what conditions, and with what alternative explanations remains to be tested. The Causal Problem Phase 3 therefore carries a greater evidentiary burden than simply identifying interesting organizational symptoms. Suppose a project experiences repeated rework. Was integrative capacity insufficient? Perhaps. But requirements may have been unstable. Technical uncertainty may have been unavoidable. A supplier may have failed. Resources may have been inadequate. The strategy may have changed. Or the project may simply have encountered uncertainty that no plausible integrative configuration could have resolved earlier. Suppose accountability appears misaligned. That may result from insufficient conditions for exercising responsibility. But it may also result from poor role design, weak governance, unclear objectives, political behavior or individual failure to exercise authority that was genuinely available. Suppose people experience a high coordination burden. That may indicate architectural insufficiency. Or it may be an appropriate cost of managing genuinely complex work. Suppose value deteriorates. That does not establish that unresolved interdependencies caused the deterioration. Phase 3 therefore cannot proceed through association alone. For every proposed consequence, the inquiry must ask: What is the claimed consequence? Through what mechanism could insufficient integrative capacity produce it? Under what conditions should that mechanism operate? What evidence would distinguish the proposed mechanism from plausible alternatives? And what evidence would cause us to reject or materially revise the claim? Without those questions, insufficient integrative capacity could become an explanation for almost any project difficulty. If it explains everything, it explains very little. Five Lines of Inquiry The five articles in this phase form a sequence of inquiry, not a predetermined chain of causation. Article 11 When Integrative Capacity Falls Behind Interdependence How Structural Drift Can Emerge The first inquiry addresses the capacity problem itself. Can structural drift emerge when integrative mechanisms remain formally present but become insufficient relative to the volume, velocity or complexity of the material interdependencies they must recognize and reconcile? Article 12 When Accountability Becomes Structurally Misaligned When Responsibility Exceeds the Conditions Required to Exercise It The second inquiry turns to accountability. What happens when formal responsibility remains in place while authority, visibility, knowledge, capability, discretion or opportunity to act become insufficient? Article 13 The Cost of Deferred Integration How Unresolved Interdependencies Accumulate Over Time The third inquiry examines accumulation. Can unresolved dependencies, deferred trade-offs and lost intervention windows create persistent systemic burdens? And does the provisional idea of integration debt survive serious scrutiny? Article 14 The Human Burden of Integrative Work When People Compensate for Architectural Gaps The fourth inquiry turns to the people inside the system. What cognitive, relational and coordination burden emerges when people compensate manually for limitations in integrative architecture? Observed performance may conceal substantial compensatory human effort. But that effort may represent resilience, architectural insufficiency, or both. The distinction matters. Article 15 When Structural Drift Becomes Consequential From Accumulated Incoherence to Value Erosion and Failure Risk The final inquiry examines consequence at the level of value and project viability. Under what conditions does accumulated systemic incoherence begin to affect value, risk, strategic viability or project outcomes? These inquiries are connected. But their relationship must not be assumed to be linear. Insufficient integrative capacity does not necessarily produce structural drift. Structural drift does not necessarily produce accountability misalignment. Deferred integration does not necessarily become debt. Human compensatory effort may prevent rather than signal failure. And accumulated incoherence may sometimes remain tolerable, reversible or locally contained. Each relationship must survive separately. Consequences Are Not Yet Constructs Terms such as structural drift and integration debt may prove useful. But naming a possible phenomenon does not establish that it exists as a distinct construct. A useful construct must distinguish something sufficiently coherent from adjacent phenomena, have a defensible mechanism, clarify rather than relabel, and provide explanatory or practical value beyond simpler language. Phase 3 will therefore resist the temptation to convert every recurring observation into a new term. The evidence must earn the construct. The Unit of Analysis Remains the Project System Phase 2 broadened the unit of analysis beyond individual roles. Phase 3 must preserve that discipline. If integration becomes insufficient, the explanation cannot automatically be: The Project Manager failed to integrate. Nor: The team failed to collaborate. Nor: Governance failed. Nor: AI failed to detect the relationship. Any of those may be true in a particular case. But integrative capacity can be distributed across people, roles, governance mechanisms, information systems, routines, interfaces and computational participants. The relevant question is therefore systemic: What configuration of actors and mechanisms was expected to provide the required integrative capacity, what integrative demands did it actually face, and was its effective capacity sufficient to meet them? This does not dissolve individual responsibility. Phase 2 already established why systemic explanation should not become distributed impunity. It means only that causal attribution should follow the actual configuration rather than an inherited assumption about where integration ought to have occurred. What Phase 3 Must Establish Phase 3 begins with a hypothesis, not a verdict. The working possibility is that insufficient integrative capacity may become visible before conventional failure through structural friction, deferred trade-offs, accountability misalignment, compensatory human burden and narrowing option space. But that proposition must survive adversarial examination. Phase 3 must establish: Which consequences can defensibly be associated with insufficient integrative capacity, through what mechanisms, under what conditions, and with what alternative explanations. Some proposed relationships may survive. Others may require narrower boundary conditions, different explanations or abandonment. That would not weaken the investigation. It would be the investigation doing its job. THE CONSEQUENCES Phase 1 revealed a problem. Phase 2 took familiar assumptions apart. Phase 3 now asks what follows when the project system's capacity to integrate is no longer sufficient for the material interdependencies it must manage. Not whether integration exists. Not whether one role owns it. Not whether distributed systems are inherently better or worse. And not whether every project difficulty can be traced back to integration. The question is narrower and more demanding: When integrative capacity becomes insufficient relative to material interdependence, what consequences actually follow, through what mechanisms, and under what conditions? Before designing a new architecture, we need to understand the consequences that architecture would need to prevent, absorb or resolve. That is the work of THE CONSEQUENCES. And it begins with a deceptively simple problem: What happens when the project system still has integration, but no longer has enough? |
Posted on: September 23, 2026 05:16 AM
| Permalink |
Comments (7)
What Does AI Actually Change About Authority and Accountability?
 Deconstructing Human Exclusivity in the Project Decision System Article 6 questioned whether a necessary function must reside in one designated role. Integration matters. But the need for integration does not, by itself, prove the need for one integrator. Article 7 then separated accountability from the assumption that responsibility, authority and causal capacity necessarily reside in the same place. Article 8 challenged the assumption that control requires centralization, or that greater autonomy necessarily produces greater adaptability. Article 9 moved the unit of analysis again. The project system may be the broader unit for analyzing required contribution without making the Project Manager an obsolete unit of professional identity. Each deconstruction separated relationships that project organizations often treat as if they were inseparable. Function from role. Accountability from authority. Control from centralization. System contribution from professional identity. Article 10 reaches a boundary beneath all four. Historically, project decision systems have been organized primarily around human actors performing analysis, exercising judgment, making decisions, taking action and being held accountable. Technology could calculate. Store information. Automate workflows. Apply rules. Generate reports. Support decisions. But the project decision system remained fundamentally organized around human agency. That boundary is becoming less stable. AI systems can increasingly analyze large bodies of information. Detect anomalies. Identify dependencies. Model scenarios. Recognize patterns across organizational boundaries. Generate recommendations. Prioritize alternatives. Trigger workflows. And, within configured conditions, perform actions. That creates an apparently simple question: What should humans still do? But that question may begin too late. It already assumes that the relevant problem is how work should be divided between humans and AI. A deeper question comes first: Which project functions actually depend on human execution, judgment or agency, and which have historically been performed by humans partly because no credible alternative previously existed? And beneath that lies an even more difficult problem. If AI can perform a function, does that mean it can legitimately exercise authority over it? If AI contributes causally to a decision, can it be accountable for that contribution? If a human formally approves an AI-generated decision without materially shaping it, where does effective agency reside? And if accountability remains human while consequential decision capacity becomes increasingly computational, what exactly is the human being held accountable for? That is the final deconstruction of Phase 2. 1. Historical Human Performance Is Not Evidence of Human Necessity Many project functions have historically been performed by people. People gather information. Interpret signals. Assess risks. Compare alternatives. Forecast consequences. Recommend actions. Make decisions. Authorize interventions. Monitor results. Escalate exceptions. And explain what happened. It is tempting to infer from this history that these are inherently human functions. But historical concentration does not establish inherent necessity. The same mistake would be familiar from the earlier articles. A function performed by one role does not prove that the function requires that role. Accountability assigned to one actor does not prove that the actor possessed all relevant authority or causal capacity. A control located centrally does not prove that effective control requires centralization. And a contribution historically associated with the Project Manager does not prove that the role is the only configuration through which that contribution can be produced. The same test must now be applied to human agency. Historical human performance is not evidence of inherent human exclusivity. Some functions may genuinely require properties that current AI systems do not possess. Others may not. The deconstructive task is to distinguish them rather than assume the answer. 2. Capability Does Not Settle Authority Suppose an AI system can perform a project function more quickly, consistently or accurately than the human actor who previously performed it. It can detect a schedule anomaly. Identify a contractual dependency. Recognize a cross-boundary risk. Estimate the consequences of a resource decision. Recommend a corrective action. Perhaps it can even execute that action within defined limits. One conclusion follows: The function is at least partly computationally performable under those conditions. Another conclusion does not automatically follow: The AI therefore possesses legitimate authority to decide. Capability and authority answer different questions. Capability asks: Can the function be performed? Authority asks: Who or what is legitimately entitled to determine or authorize what happens? The two are often associated in organizational practice because authority is frequently assigned to actors considered sufficiently capable to exercise it. But capability alone does not establish legitimate authority. An analyst may understand a decision better than the executive authorized to make it. A technical expert may predict the consequence more accurately than the sponsor. A team may possess the knowledge while a governance body possesses the decision right. Article 7 already showed why responsibility, authority and causal capacity should not be collapsed. AI makes that distinction harder to ignore. An AI system may possess substantial analytical or operational capability without possessing authority. But the reverse assumption must also be tested. The fact that authority has historically been exercised by humans does not itself prove that legitimate authority is inherently human. Perhaps some decision rights can be exercised computationally under delegated conditions. Perhaps only bounded discretion can. Perhaps authority remains institutionally attached to human or organizational actors even when execution is computational. Different forms of authority may require different conditions of delegation and legitimacy. The answer cannot be derived from capability alone. But neither can it be derived from tradition. 3. Delegation to AI Is Not One Thing Organizations already delegate. They delegate authority to roles. Decision rights to teams. Approval limits to managers. Operational discretion to specialists. Bounded execution to automated systems. And execution to suppliers and agents. AI extends this problem, but it also complicates it. Consider several different arrangements. An AI system may analyze information but make no recommendation. It may recommend but have no authority to act. It may select among alternatives but require human approval. It may execute actions after human authorization. It may act autonomously within predefined thresholds. It may escalate when those thresholds are exceeded. Or it may continuously adapt actions within a delegated operating envelope. These configurations are not equivalent. Calling all of them “AI decision-making” hides the architecture that matters. The relevant questions are more precise. What has been delegated? Analysis? Recommendation? Selection? Execution? Discretion? Authority? Under what constraints? With what observability? With what intervention rights? And who or what can change those constraints? The presence of AI therefore tells us less than the architecture of delegation surrounding it. AI participation in a decision system does not, by itself, tell us where decision authority resides. 4. Recommendation Can Carry More Decision Influence Than Formal Approval Suggests A familiar governance safeguard is human approval. AI recommends. A human decides. Responsibility therefore remains human. Sometimes that description may be accurate. But not always. Imagine an AI system that processes thousands of variables, identifies the feasible alternatives, ranks them, predicts their consequences and recommends one option. A human receives the recommendation. The underlying analysis is too complex to reproduce independently. The alternatives not surfaced by the system are not visible. The assumptions shaping the ranking are only partially understood. Time pressure makes extensive challenge difficult. The human clicks approve. Who made the decision? Formally, perhaps the human. But the causal contribution to that decision may be more distributed. The AI shaped the information environment. It influenced which alternatives became visible. It structured the comparison. It affected the perceived significance of consequences. And it selected the recommendation presented for approval. The human still performed the formally consequential act of approval. But formal approval alone does not establish the degree of meaningful human influence that preceded it. This does not mean the AI “really decided” and the human did not. That would merely replace one oversimplification with another. It means: Decision authority, decision influence and decision causation should not be treated as equivalent merely because one actor performs the final approval. Human-in-the-loop describes a position in the workflow; whether it constitutes meaningful human oversight depends on the human's actual intervention capacity. Can the person understand the relevant basis of the recommendation? Can they challenge it or request alternatives? And can they intervene while meaningful alternatives remain? A human approval step without meaningful capacity to shape the decision may preserve a human signature while providing much less human control than the workflow appears to contain. 5. Detection Is Not the Same as Organizational Materiality AI introduces another distinction. A system may detect an anomaly. Identify a dependency. Predict a consequence. Recognize a correlation across organizational boundaries. Estimate probability, magnitude, reversibility or exposure. These are potentially important capabilities. But detecting a consequence does not necessarily determine how much that consequence should matter to the organization. Consider the same predicted consequence in two organizations. Both AI systems detect it correctly. Both estimate its probability and magnitude accurately. But one organization operates under stringent safety obligations. The other accepts greater exposure in exchange for speed. The estimated consequence may be the same. Its organizational significance may not be. This suggests an important distinction. Materiality is not necessarily a property of the detected consequence alone. It may depend on the relationship between that consequence and the objectives, values, obligations, thresholds and legitimate interests the project system is expected to protect. AI may still participate extensively in assessing materiality. It can apply predefined thresholds. Model stakeholder effects. Compare outcomes against objectives. Identify regulatory constraints. Represent competing priorities. Detect inconsistencies. And calculate whether a consequence satisfies encoded materiality criteria. But that leaves a deeper question. If an AI system classifies a consequence as material because it satisfies an organizationally defined threshold, has AI determined materiality? Or has it operationalized a prior organizational judgment about what should count as material? The answer may differ by configuration. And even that distinction may become less clear as AI systems participate in recommending or adapting the criteria themselves. So the relevant question is not whether AI can calculate significance. It is: Can AI determine not only that a consequence exists, but the organizational scope within which that consequence should count as material? The word “should” matters. It connects consequence to value, legitimacy, competing objectives, authority and organizational purpose. But it does not prove that the resulting judgment must remain exclusively human. That is precisely what must be tested. 6. Judgment Should Not Be Protected by Definition One easy response to AI is to preserve human exclusivity by redefining whatever AI can do as computation and whatever remains difficult as judgment. That is circular. If AI evaluates alternatives, we may say it only analyzes. If it recommends one, we may say it does not really judge. If it adapts its recommendation to context, we may say genuine contextual judgment still belongs to humans. If it explains the trade-off, we may move the boundary again. Such reasoning makes claims of human-exclusive judgment impossible to falsify. The deconstruction requires a stronger test. What do we mean by judgment? Does it require interpretation under uncertainty? Context sensitivity? Comparison of competing objectives or values? Reasoning where rules are incomplete or exceptions matter? Awareness of consequences for different stakeholders? Ability to justify a decision and respond to challenge? Once the relevant property is specified, we can ask whether it genuinely requires a human actor. Some forms of judgment may prove computationally reproducible. Some may be computationally augmented without being fully transferable to AI. Some may depend on institutional standing rather than cognitive capability. Some may depend on forms of human experience or moral agency that current AI systems do not possess. And some things currently called “judgment” may turn out to be sophisticated forms of analysis that were treated as uniquely human only because humans historically performed them. Human judgment should not be protected from scrutiny by defining it as whatever AI cannot yet do. 7. Authority Is More Than Decision Quality Suppose an AI system consistently recommends better decisions than the authorized human actor. Would that justify transferring authority to the AI? Not necessarily. Decision quality matters. But authority is not merely a prize awarded to the most accurate decision-maker. Organizations allocate authority for multiple reasons. Expertise. Representation. Fiduciary responsibility. Legal standing. Protection of rights. Separation of duties. Institutional legitimacy. And sometimes because the decision affects people whose interests require representation rather than merely optimization. An AI system may outperform a human on prediction without satisfying all of these conditions. But again, the opposite conclusion should not be assumed. Not every form of authority requires all of them. Some decisions are already executed automatically under bounded authority established by human or institutional actors. AI may expand the range of decisions for which such arrangements are feasible. The useful distinction may therefore not be: Human authority versus AI authority. It may be: Which forms of decision authority can legitimately be delegated to, or exercised through, computational systems, under which conditions, to what degree, with which constraints and with what retained capacity for intervention? Authority exercised through a computational system should not automatically be treated as authority held by that system. That makes authority an architectural and institutional question rather than a label inferred from who or what performs the task. 8. Causal Influence Is Already Distributed AI complicates another familiar category. Agency can refer to different things. The capacity to act. The capacity to exercise discretion. Intentional action. Or the ability to materially shape outcomes. These should not be assumed to be equivalent. Project outcomes already emerge from distributed causal systems. A sponsor sets direction. A Project Manager integrates. A team interprets. A specialist recommends. A governance body authorizes. A supplier executes. An information system constrains available options. An incentive changes behavior. A contract limits discretion. AI can now participate in several of these causal and decision functions. It may frame alternatives. Sequence work. Allocate resources within constraints. Generate actions. Trigger interventions. Adapt recommendations as conditions change. Or influence human choices without possessing formal authority. This means that causal influence may become increasingly distributed across humans, organizational structures and computational systems. But causal contribution is not the same as agency in every meaningful sense. And agency is not automatically authority. Nor is either automatically accountability. These distinctions matter because otherwise organizations may place AI into consequential positions while continuing to describe the decision architecture as if only humans shaped the outcome. The opposite error is equally possible. Attributing “agency” to AI too casually may obscure the human and organizational choices that selected the system, defined its objectives, configured its permissions, provided its data, accepted its outputs and determined the conditions of its use. So the question is not simply: Did the AI act? It is: How were decision capacity and causal influence distributed across the decision system, and which actors or mechanisms materially shaped the resulting action? 9. Accountability Cannot Be Solved by Keeping a Human Name on the Decision The simplest governance response to AI is often: A human remains accountable. That may be necessary. But it is not sufficient as an explanation. Article 7 established that legitimate accountability depends on more than formal responsibility. The accountable actor must be examined in relation to authority, capability, information, opportunity to act, constraints on exercise and causal contribution. AI makes that architecture even more important. Suppose a Project Manager remains formally accountable for a decision substantially shaped by an AI system. What could the Project Manager reasonably know or understand? Could they challenge or override the recommendation? Did they choose to use the system, or were they required to use it? Who selected and configured the system? Who controlled the relevant thresholds, data and permissions? And who could intervene when the system's behavior changed? Simply naming the Project Manager as accountable does not answer these questions. Nor does blaming the AI. Accountability should be assessed against how responsibility and authority were allocated, whether the actor was enabled to act, how available discretion was exercised, and what causal contribution can legitimately be attributed, not merely the location of the final human signature. This does not imply distributed impunity. Quite the opposite. The purpose of examining the architecture is to make accountability more defensible. Different actors may be accountable for different aspects of the same AI-enabled decision system. Selection. Configuration. Authorization. Use. Monitoring. Escalation. Intervention. And the exercise or non-exercise of available discretion. The introduction of AI therefore does not eliminate accountability. It makes simplistic accountability allocation harder to defend. 10. Can AI Be Accountable? A harder question remains. Could AI itself ever be accountable? Before answering, the term must be clarified. If accountability means that a system can produce an explanation of its action, preserve an audit trail or be evaluated against performance criteria, AI can participate in accountability mechanisms. But organizational accountability usually means more. An accountable actor can be called to account. Expected to justify conduct. Evaluated against legitimate obligations. Subject to consequences. And situated within an institutional structure of responsibility. Current AI systems do not independently occupy that kind of organizational standing merely because they can explain an output. But that observation does not settle every future configuration. Organizations may create institutional arrangements in which computational agents receive delegated decision rights, operate under explicit obligations and are continuously evaluated against them. Would that constitute accountability? Or only accountability of the humans and organizations that created and governed the agent? The answer depends partly on what accountability is understood to require. Explanation? Normative responsibility? Institutional standing? Capacity to bear consequences? Moral agency? Article 10 should not solve these philosophical and institutional questions by assertion. For project systems, the more immediate conclusion is narrower. Computational participation in accountability mechanisms is not yet equivalent to establishing that an AI system can bear organizational accountability in the same sense as a human or institution. Whether that equivalence could ever become legitimate remains an open question. 11. Human Oversight Must Be More Than Presence If human accountability is retained, meaningful human oversight becomes important. But “human oversight” can conceal very different realities. A human may actively review reasoning and alternatives. Or merely receive an alert. A human may have authority to intervene. Or only authority to escalate. A human may technically possess an override. But exercising it may require information they do not have. Time they are not given. Expertise they do not possess. Or organizational conditions that make intervention disproportionately costly. So the presence of a human in the workflow does not prove the existence of meaningful oversight. The relevant test is functional. Can the human recognize when intervention may be necessary? Can they understand enough of the relevant decision context to challenge the system? Can they access meaningful alternatives? Do they possess legitimate authority to intervene? Can they exercise that authority while intervention can still change the outcome? And are the organizational conditions compatible with exercising it? These questions closely resemble the accountability tests from Article 7. That is not accidental. AI does not replace the problem of enablement. It can intensify it. Human oversight without meaningful intervention capacity may preserve the appearance of human control while weakening its substance. 12. Automation Can Change the Intervention Window AI can also alter when governance becomes consequential. In slower human workflows, decision processes may leave visible moments for review. A recommendation is prepared. A meeting occurs. Approval is requested. Action follows. AI-enabled systems can compress that sequence. Detection, interpretation, recommendation and action may occur in seconds. Or continuously. By the time a human becomes aware of the consequence, the meaningful intervention window may already have narrowed or closed. This does not mean faster automation is inherently less governable. It means governance architecture must account for decision speed. Some controls may need to move upstream. Permissions may need to be established before action. Thresholds before deployment. Escalation rules before exceptions occur. Observability before autonomy expands. Logging before consequential activity begins. And intervention rights before the system enters operating conditions in which human response would arrive too late. This produces an important inversion. I n some AI-enabled systems, effective governance may depend more heavily on ex ante architecture precisely because ex post human intervention becomes less capable of shaping individual decisions. That does not eliminate ongoing governance. Thresholds, permissions, objectives and controls may themselves need to change as conditions change. But it means that “a human can always intervene” is not a sufficient governance design principle. The relevant question is whether intervention remains possible while alternatives are still meaningful. 13. The Human May Move From Decision-Maker to Architect of Decision Conditions If AI increasingly performs analysis, recommendation and bounded action, the human contribution may shift. Not necessarily disappear. Shift. In some configurations, humans may spend less effort producing individual decisions and more effort determining the conditions under which decisions can legitimately be produced. Which objectives and values matter? What may be delegated, and what must be escalated? Which thresholds and evidence requirements apply? Which stakeholders require protection or representation? What uncertainty or reversibility is acceptable? Which decisions require independent review or stop conditions? And who may change these rules? This suggests a potentially important movement: From deciding every action Toward designing and governing the conditions under which action can occur. But this should not be universalized. Some project decisions may continue to require direct human judgment. Some may be performed predominantly through computational systems. Others may move dynamically between human and AI contribution as uncertainty, materiality or context changes. So the proposition is not: Humans become governance architects and AI becomes decision-maker. It is narrower: As computational decision capacity increases, human contribution may increasingly shift from performing individual decision functions toward defining, legitimating and governing the conditions under which those functions are exercised. Whether even those functions remain exclusively human is still part of the test. 14. What, Then, Remains Distinctively Human? At this point, it would be tempting to produce a protected list. Purpose. Values. Ethics. Judgment. Empathy. Accountability. Leadership. Meaning. And declare them inherently human. That would be premature. Some may prove to depend on human properties that computational systems do not possess. Some may continue to require human participation because law or institutional legitimacy requires human standing. Some may be computationally supported while authority remains with human or institutional actors. Some may be distributed across people and systems. And some may prove less exclusively human than professional narratives currently assume. The correct question is therefore not: What can we reserve for humans? It is: Which project functions genuinely require human properties, standing or relationships, and what exactly is the property that makes human participation necessary? If the answer is empathy, what function requires empathy and why? If judgment, what kind? If accountability, what feature of accountability cannot be computationally instantiated? If legitimacy, whose recognition makes the authority legitimate? If ethics, which ethical function cannot be performed through computational reasoning and which requires moral agency or institutional standing? If purpose, who has legitimate standing to define it? Each claim of human exclusivity must identify its mechanism. Otherwise “human” becomes another inherited category protected from deconstruction. 15. What Does AI Actually Change About Authority and Accountability? We can now return to the central question. Which assumptions about human execution, authority, agency and accountability remain valid when AI becomes capable of analysis, recommendation and bounded action? The answer is not that AI eliminates human authority. Nor that accountability can simply be transferred to algorithms. Nor that humans must retain every consequential decision because humans have historically made them. AI changes the project decision system by making previously bundled functions increasingly separable. Analysis can be computational while authority remains human. Recommendation can be computational while selection is shared. Execution can be automated while discretion remains bounded by human-defined conditions. Causal influence can be distributed even when formal approval remains concentrated. Materiality can be computationally assessed against encoded criteria while the legitimacy of those criteria remains separately contestable. Oversight can remain human while becoming ineffective if meaningful intervention capacity disappears. And accountability can remain formally human while becoming less legitimate if the accountable actor lacks the authority, understanding or meaningful capacity to act necessary to discharge it. So AI does not create one new allocation problem. It exposes distinctions that were easier to ignore when humans occupied most positions in the decision system. The relevant design problem becomes: Which functions can be computationally performed, which forms of discretion can legitimately be delegated, where must authority reside, what intervention capacity must be preserved, and how should accountability be allocated in light of how responsibility and authority are allocated, actors are enabled, discretion is exercised and causal contribution is attributed? That question must be answered against the actual decision-system configuration. Not by technological enthusiasm. Not by protecting inherited professional boundaries. And not by assuming that historical human performance establishes permanent human necessity. The Deconstruction The familiar assumption was: Project decisions ultimately require human judgment, human authority and human accountability. That proposition contains several different claims. They should not be accepted or rejected together. Some analytical functions may not inherently require human execution. Some forms of recommendation may not inherently require human generation. Some bounded actions may be legitimately executable without contemporaneous human approval. Some forms of discretion may prove legitimately delegable. Other forms of authority may remain attached to human or institutional standing. And accountability may depend on properties that computational capability alone does not provide. The deconstruction therefore does not lead to: Human → obsolete Nor to: AI capability → AI authority Nor to: Human signature → legitimate human accountability It leads to a more disciplined set of distinctions: Human execution ≠ necessary human exclusivity Computational capability ≠ legitimate authority Decision influence ≠ formal decision right Authority ≠ accountability Causal contribution ≠ singular responsibility Human oversight ≠ meaningful intervention capacity The more rigorous question is: What exactly must be true for a project function to require human execution, human authority or human accountability? Each claim must survive separately. And one proposition survives the deconstruction: Historical reliance on human actors to perform, authorize or govern a function does not establish that human participation is inherent to that function. But a second proposition survives with equal force: The ability of AI to perform or influence a function does not, by itself, establish legitimate authority, accountable standing or the conditions under which that function should be delegated. That completes the central work of Phase 2. Across five deconstructions, the question has not been whether familiar project constructs should disappear. It has been whether the relationships hidden inside them actually hold. Integration does not automatically imply one integrator. Accountability does not automatically imply coincident authority and causal capacity. Control does not automatically imply centralization. System contribution does not automatically imply role obsolescence. And human performance does not automatically imply human exclusivity. What survives is not a roleless, authorityless, control-free or human-free project system. What survives is a harder requirement: Project architecture must make explicit which functions are necessary, where capability resides, how discretion and authority are allocated and legitimized, how consequential interdependencies are recognized, how intervention remains possible, and how accountability is assigned to legitimate accountable actors in light of the distribution of responsibility, authority, enablement, exercise and causal contribution across human, organizational and computational participants. Phase 2 can therefore close without prescribing one universal organizational form. Its purpose was deconstruction. It has established the distinctions and tests through which inherited assumptions about role, authority, control, professional identity and human exclusivity can be examined against actual project-system configurations. The next question is reconstruction. If these familiar relationships can no longer simply be assumed, how should the project system be designed? That is where THE AWAKENING goes next. |
Posted on: September 21, 2026 02:06 PM
| Permalink |
Comments (2)
Who Develops the Capabilities We Still Need?
 Why the Architecture of Work Is Also an Architecture of Capability Formation Over the previous articles in this series, I have explored a recurring idea. The new ways of working in projects are not simply about adopting agile practices, introducing new technologies, changing methodologies or giving teams greater autonomy. They reflect a deeper transformation in the organizational conditions through which projects operate. Purpose, authority, decision-making, governance, resources, human and computational capabilities, organizational boundaries and learning increasingly need to be connected differently if projects, understood as temporary organizations, are to remain adaptive without losing coherence, accountability or the capacity to create value. That transformation raises another question. What happens to capability formation when the architecture of work itself changes? This question becomes particularly important as artificial intelligence assumes a growing share of activities previously performed by people, including planning, analysis, monitoring, reporting, documentation, information consolidation and decision preparation. Much of the immediate discussion focuses on productivity, roles and employment. But there is another consequence. Some of this work did more than produce an output. It also exposed people to problems from which they could learn. If new ways of working change how work, authority, decisions and human-computational capabilities are distributed, they may also change who encounters problems, who investigates them, who makes judgments, who receives feedback, who experiences consequences and who gets the opportunity to try again. When we redesign the architecture of work, we also redesign the distribution of developmental opportunities. And that matters because an organization cannot simply declare the capabilities it will need in the future. Those capabilities have to develop somewhere. The Capabilities Required by New Ways of Working Earlier in this series, I argued that the evolution of project work is changing the contribution expected from the Project Manager. As AI becomes increasingly capable of supporting planning, analysis, monitoring, documentation and decision preparation, the value of the role cannot be understood primarily through those activities. The distinctive contribution increasingly lies elsewhere. Connecting strategy with execution. Integrating capabilities distributed across the organization. Working across functional and organizational boundaries. Preserving context. Facilitating decisions. Detecting emerging dependencies and inconsistencies. Helping temporary organizations remain coherent while adapting. Combining human and computational capabilities without obscuring decision authority or accountability. These are not merely additional tasks. They require judgment, contextual understanding, pattern recognition, relational capability and the ability to operate across boundaries that no single function fully controls. But identifying the capabilities required is only part of the problem. How do people actually develop them? That question becomes increasingly important when the architecture of work that historically provided some of those experiences is itself being redesigned. Work Has an Operational and a Developmental Consequence Organizations normally design work around the result that needs to be produced. A schedule must be developed. A risk must be analysed. A dependency must be managed. A decision must be prepared. The operational output is visible. The developmental consequence is less so. Someone developing a schedule may gradually learn how dependencies interact, where uncertainty enters the plan, why estimates fail and how apparently local changes propagate across a project. Someone supporting a difficult stakeholder discussion may learn how interests, authority and organizational context shape what can legitimately be decided. The task produces an operational result. The experience may also create a developmental opportunity. This does not mean that work automatically produces capability. Capability development also depends on individual effort, reflection, feedback, mentoring, social interaction, prior knowledge and the quality of the experience itself. But work architecture still matters because it distributes access to information, proximity to problems, participation in decisions, responsibility, feedback, consequences and opportunities for practice. The architecture of work is therefore not the same thing as capability formation, but it creates part of the developmental architecture within which capability can emerge. This becomes particularly significant when work is redistributed between humans and AI. The usual questions remain essential. What should be automated or augmented? Where must human judgment remain decisive? Who validates, challenges and decides? Who remains accountable? But another question should now accompany them: What happens to the developmental function of the work when its allocation changes? If AI produces the initial analysis, where does a less experienced professional learn to construct one? If AI identifies dependencies, how do people develop the ability to recognize dependencies the system misses? If AI continuously monitors signals and anomalies, how do people develop the sensing capability required to recognize when the system itself may be wrong? These questions do not demonstrate that automation is undesirable. They demonstrate that automation can have consequences beyond the allocation of tasks. AI Can Reduce Learning. It Can Also Increase It. It would be a mistake to assume that AI necessarily makes people less capable. The same technology can support very different forms of human engagement. One professional may use AI in ways that reduce their own cognitive engagement. Another may use it to examine assumptions, generate counterarguments, explore scenarios, compare interpretations and challenge their own reasoning. One delegates the problem. The other uses AI to engage more deeply with it. Individual agency, effort, curiosity and the willingness to question apparently convincing answers all matter. But architecture matters too. Consider two organizations using essentially the same AI capability. In one, professionals receive AI-generated recommendations and are expected mainly to confirm that the result appears reasonable. In another, professionals are expected to formulate the problem, make assumptions explicit, compare their reasoning with the AI, investigate disagreements, justify decisions and subsequently examine outcomes. Both organizations use AI. Both may improve productivity. But they have not created the same developmental conditions. The relevant question is therefore not whether AI is good or bad for learning. It is: What kind of human engagement does the architecture of human-computational collaboration make more or less likely? Do Not Preserve the Task. Preserve or Redesign the Developmental Function. There is an obvious danger in this argument. If people historically developed capabilities while performing certain tasks, organizations might conclude that those tasks should remain human. That would be the wrong lesson. Many inherited activities exist because information was once difficult to obtain, calculations were expensive, systems were poorly integrated or coordination required manual intervention. Some work is repetitive. Some provides little meaningful development. Some should disappear. An adaptive organization should not preserve an obsolete mechanism simply because it once served a legitimate purpose. The same principle applies here. Historical developmental value does not justify permanent task preservation. The relevant question is not whether the old task should survive. It is whether it performed a developmental function that remains necessary. A report may disappear. The ability to distinguish signal from noise may remain important. Manual schedule updating may disappear. Understanding dependencies and the consequences of change may still matter. The task can disappear while the capability remains necessary. The challenge is therefore to identify the developmental function and decide whether it should be preserved, replaced or redesigned. From Accidental Learning to Deliberate Capability Formation Historically, much professional development occurred as a by-product of work. People learned because they were exposed to problems, observed more experienced colleagues, received feedback, made decisions of increasing significance and encountered situations that did not fit what they had previously learned. Over time, some of those experiences contributed to professional judgment. But this mechanism was never perfect. Experience does not automatically produce learning. Repetition can reinforce poor practice. Consequences can be misunderstood. Years of experience do not necessarily produce years of development. The emergence of AI therefore gives organizations an opportunity not merely to protect old learning pathways, but to examine whether those pathways were ever sufficiently deliberate. If an activity can be automated, the organization can ask: What did people actually learn through this activity? Is that learning still necessary? Was the activity an effective way of developing it? If not, what would be better? The answer may involve progressive exposure to increasingly complex problems, mentoring, simulation, deliberate challenge of AI-generated outputs or post-decision reviews that examine why expectations differed from outcomes. The specific mechanism will vary. The architectural principle is more important: Developmental functions that remain necessary should not be left unaddressed merely because the tasks through which they were historically performed have been automated. From Individual Learning to Organizational Capability This extends an argument developed earlier in this series. Project work generates experience, tests assumptions, reveals limitations and creates opportunities for new knowledge to emerge. But adaptive organizations need more than local learning. They need mechanisms through which temporary experience can contribute to more permanent organizational capability. There is now an earlier question in that chain. What experiences is the architecture of work creating in the first place? Organizational learning depends partly on what individuals and teams have had the opportunity to observe, practise, question and understand. If the architecture changes those opportunities, it also changes some of the raw material from which future organizational capability can emerge. The relationship can therefore be understood as a longer sequence: Architecture of work → Distribution of developmental opportunities → Human engagement and experience → Learning and capability formation → Organizational learning → Future organizational capability → Capacity to adapt and create value. None of these transitions is automatic. But ignoring the earlier links does not make them disappear. This is why capability formation cannot be treated only as an individual career issue or as the responsibility of Learning and Development. It is also shaped by organizational design. Who Develops the Capabilities We Still Need? There is no single answer. Individuals remain responsible for their own development, and organizations cannot learn on their behalf. But managers influence which problems people encounter and how responsibility develops. Experienced professionals provide context, challenge and feedback. Teams shape whether assumptions are questioned and knowledge is shared. Learning mechanisms create opportunities for structured practice. AI can automate, augment, explain, simulate, challenge and provide access to knowledge at a scale previously unavailable. And the architecture of work shapes how these elements are connected. Within the context of work, capability formation therefore emerges from the interaction between individual agency and organizational conditions. Neither should be used to excuse the other. An organization cannot systematically remove meaningful developmental opportunities and then treat every future capability deficit as an individual failure. But individuals cannot expect architecture alone to create capability without effort, curiosity, reflection and engagement. The organization creates conditions. People act within them. Capability develops through the interaction. The Intertemporal Consequence of Work Design This introduces a dimension that can easily remain invisible in transformation decisions. Organizations often evaluate a new way of working primarily through present performance. Does it reduce cost? Increase speed? Improve quality? Reduce risk? Improve coordination or decision support? Those questions remain necessary. But they are not always sufficient. A work architecture can improve performance today while weakening some of the conditions through which capabilities needed tomorrow would otherwise develop. Another architecture may achieve similar performance improvements while deliberately creating new developmental mechanisms. The difference may not appear immediately. It may become visible years later when the organization needs people capable of integrating conflicting perspectives, challenging automated recommendations, exercising judgment under uncertainty, operating across organizational boundaries or recognizing signals that existing systems have not been designed to detect. What later appears as a capability shortage may therefore sometimes have an earlier architectural origin. Today's allocation of work helps shape tomorrow's distribution of capability. This does not mean organizations must develop every capability internally. They can recruit, contract, partner or access expertise through broader ecosystems. But external access does not eliminate the systemic question. If organizations broadly remove the pathways through which particular forms of expertise develop without creating alternatives, recruiting capability from elsewhere merely relocates the problem. Capability formation therefore introduces an intertemporal consequence into the architecture of new ways of working. Designing for Present Performance and Future Capability Throughout this series, I have argued that new ways of working in projects concern more than methodology, technology or isolated changes in team practices. They concern the organizational conditions through which projects remain capable of adapting while preserving direction, legitimate authority, accountability and the capacity to create sustainable value. Capability formation adds another requirement. An adaptive organization must consider not only whether its architecture enables people to act effectively today, but whether it continues to create the conditions through which the capabilities required for adaptation can develop tomorrow. AI makes this issue particularly visible because it allows organizations to redistribute work at unprecedented speed and scale. But the principle is broader than AI. Every significant redesign of work changes, to some degree, the distribution of participation, decision-making, practice, feedback and exposure to consequences. Those changes can influence what the organization becomes capable of doing later. This is why the architecture of work is also, in an important but non-deterministic sense, an architecture of capability formation. Not because work automatically produces capability. Not because historical tasks should be protected. But because work architecture distributes developmental opportunities from which future human and organizational capability can emerge. New ways of working should therefore be evaluated across two horizons: What performance does this architecture enable today? And: What capabilities does it help us develop, preserve or renew for tomorrow? The future of project work will not depend only on what humans and artificial intelligence become capable of doing separately. It will also depend on whether the architectures through which they work together continue to support the development of the human capabilities on which adaptation, judgment, accountability and sustainable value creation still depend. |
Posted on: September 20, 2026 03:48 AM
| Permalink |
Comments (3)
