When Agility Becomes Mechanical
 The Hidden Cost of Weak System-Level Integration Agile approaches changed an important assumption about how projects can adapt. Not every decision needs to travel upward. Not every change should wait for central approval. Not every problem is best understood far from the work. Teams can exercise judgment. Feedback can shorten the distance between evidence and response. Decision-making can move closer to relevant knowledge. Learning and adaptation can occur where the work is actually happening. These are significant capabilities. But the previous reflections exposed a condition that complicates the picture. As leadership, authority and management responsibilities become more distributable, the interdependencies among the decisions they produce do not disappear. And when those interdependencies are insufficiently recognized or reconciled, something subtle can happen. Adaptive practices can remain active. Teams can continue responding. The project can continue moving. Yet its capacity to adapt coherently as a whole can weaken. This is what I mean by mechanical agility. Not failed agility. Not false agility. Not merely the mechanical performance of agile practices. And not an argument against autonomy. For the purposes of this inquiry: Mechanical agility is a condition in which adaptive practices and local learning remain active, while the architecture becomes insufficient to connect and reconcile their material consequences across the wider system. The question is therefore not simply whether teams are agile. It is: Can local adaptation remain systemically coherent when the decisions it produces are materially interdependent? 1. Agility Changed Where Adaptation Can Occur Traditional project structures often concentrated substantial planning, coordination and decision authority within formal management arrangements. Agile approaches challenged that concentration. They enabled more sensing, judgment, learning and adaptation to occur closer to the work. Teams inspect outcomes. Customers and users provide feedback. Priorities can change. Solutions can evolve incrementally. New information can influence subsequent decisions without waiting for an entire planning cycle to be completed. This can reduce the distance between evidence and action. But it also changes the architecture through which adaptation occurs. When teams, product roles, managers and other actors can respond to different signals at different speeds, adaptation can emerge from several places across the project system. That can be valuable. But it raises another question: What connects adaptations whose material consequences extend beyond the boundaries within which they were made? 2. Local Adaptation Is Not Sufficient for System Adaptation A team can adapt effectively to what it sees. That does not necessarily mean the wider project has adapted coherently. A Product Owner may reprioritize work in response to customer evidence. A technical team may change an architecture in response to performance data. Another team may alter sequencing because of a dependency. Operations may introduce a constraint based on serviceability. A sponsor may protect a strategic milestone as conditions change. Each response may be timely, rational and legitimate within its own context. Yet their consequences can interact. A locally beneficial change can alter another team's dependency. A faster delivery choice can increase operational exposure. A customer-driven priority can affect a contractual commitment. A technical improvement can consume capability required elsewhere. The distinction is therefore fundamental: Local adaptation concerns the ability of a part of the system to respond to relevant change. System adaptation requires the consequences of those responses to remain sufficiently coherent across the interdependent whole. Agile practices can substantially strengthen local adaptive capacity. They do not, by themselves, remove the need to integrate consequences that cross local boundaries. 3. Autonomy Does Not Remove Interdependence Autonomy is valuable partly because not every decision should require central intervention. But autonomy does not make decisions independent. A team may possess legitimate authority over how it performs its work while remaining dependent on shared architecture, funding, suppliers, platforms, regulatory requirements, other teams or downstream operations. This creates an important distinction: Decision autonomy concerns where legitimate decision authority resides. System coherence concerns whether the consequences of different decisions remain compatible enough for the project to function as a whole. These principles do not inherently conflict. The difficulty arises when one is treated as sufficient for the other. More local autonomy can improve responsiveness without resolving cross-boundary interdependencies. More central control can make some dependencies easier to govern while weakening local judgment and responsiveness. The architectural question is therefore not how to maximize autonomy or control. It is: Which decisions can remain local, and when do their consequences become sufficiently material and interdependent to require integration beyond the local boundary? 4. Fast Feedback Can Still Have a Narrow Boundary Agility rightly emphasizes feedback. Feedback allows assumptions to be tested. It exposes differences between expected and actual outcomes. It creates opportunities for learning and adjustment. But the speed of a feedback loop does not determine the breadth of the system it represents. A team can receive rapid usability feedback while remaining unaware of an operational consequence. A product function can observe customer behaviour without seeing portfolio-level resource effects. A technical team can detect performance degradation without understanding a contractual implication. An AI-enabled system can identify a local pattern without representing every organizational constraint affected by the response. The feedback itself may be excellent. The limitation may be its scope. A project cannot deliberately adapt to material consequences that remain outside the feedback structures through which those consequences can become visible. Faster feedback is therefore valuable, but not always sufficient. The architecture must also determine which consequences need to cross boundaries, who needs to see them and whether they become visible while meaningful intervention remains possible. 5. Iteration Creates Opportunities for Learning, Not Learning Itself Iteration is another essential capability. But iteration and learning are not equivalent. A team can execute short cycles repeatedly while leaving important assumptions unchallenged. Metrics can improve while the wrong objective is being optimized. Retrospectives can identify local friction without revealing systemic causes. Delivery can accelerate while strategic relevance weakens. Iteration creates repeated opportunities for adjustment. Learning requires something more. Evidence must be connected to assumptions, decisions and consequences. At system level, that becomes more difficult because evidence itself is distributed. Different actors see different parts of reality. Different metrics represent different objectives. Different feedback loops operate at different speeds. Some consequences emerge outside the team or only after the immediate delivery cycle. This creates another important distinction: Iteration creates opportunities for learning. Integration helps determine whether relevant learning can reach the interdependencies it needs to influence. Without that connection, adaptation can remain locally intelligent while becoming systemically incomplete. 6. Motion Is Not Coherence Mechanical agility may not look dysfunctional. That is one reason it can be difficult to detect. Work may continue flowing. Iterations may continue. Backlogs may be refined. Throughput and cycle time may improve. Teams may demonstrate progress. Stakeholders may attend reviews. The adaptive machinery appears active. But activity is not coherence. A project can become more efficient at producing outputs without becoming more capable of preserving coherence among the decisions, constraints and consequences that shape those outputs. This is not a criticism of metrics. Metrics make selected dimensions of reality visible. The risk emerges when what is measurable locally becomes a proxy for what matters systemically. A team metric can tell us whether work is moving. It cannot, by itself, tell us whether the collection of decisions producing that movement remains coherent across the project system. The more important question therefore becomes: Are we merely increasing the speed of local response, or improving the capacity of the whole system to adapt to what it is learning? Those are different achievements. 7. Mechanical Agility Is an Architectural Condition Mechanical agility should not be understood as a criticism of teams. Nor should it automatically be treated as poor implementation of an agile framework. The condition can arise even when teams are capable, disciplined and genuinely adaptive within their legitimate boundaries. Imagine a project in which:
Interdependencies are not reconciled quickly enough. Or the actors expected to integrate them lack sufficient visibility, authority, knowledge or opportunity to act. The problem is not an absence of agility. It is a separation between local adaptive capacity and system-level adaptive coherence. Mechanical agility therefore describes what can happen when adaptive mechanisms remain operational while the integrative conditions required for coherent system-level adaptation become insufficient. That makes it an architectural condition, not a methodology. 8. The Answer Is Not Less Autonomy Recognizing this condition can lead to an attractive but simplistic conclusion: reduce autonomy. That does not necessarily follow. Reducing autonomy can recreate bottlenecks. It can move decisions away from relevant knowledge. It can slow feedback. It can weaken useful ownership. And it can make adaptation depend on actors who are too distant from changing conditions. The alternative is not to choose between autonomy and integration. It is to design them as complementary capabilities. Autonomy enables adaptation to occur where relevant knowledge and legitimate authority reside. Integration connects adaptations when their material consequences cross those boundaries. Local actors can remain capable of responding where the consequences of their decisions remain appropriately local. Integrative mechanisms can become more active when those consequences cross boundaries or create material system-level tensions. The objective is therefore neither maximum autonomy nor maximum central control. It is adaptive coherence. 9. From Team Agility to Adaptive Coherence Team-level agility remains important. But in an interdependent project system, it cannot be the only object of attention. We also need to ask whether the wider system can:
It is its systemic extension. A project may therefore require both: Local adaptive capacity, the ability of actors close to the work to sense, learn and respond, and System-level integrative capacity, the ability to recognize and reconcile the material interdependencies created by those responses. Together, they can support what this series will call adaptive coherence. For the purposes of this series, adaptive coherence refers to the capacity of an interdependent project system to adapt while keeping its differentiated responses sufficiently coherent as a whole. Mechanical agility describes the condition in which local adaptive capacity remains active while system-level integrative capacity becomes insufficient. 10. The Hidden Cost When system-level integration is weak, the first visible consequence may not be project failure. It may be drift. Teams remain productive. Local decisions remain defensible. Delivery continues. But interdependencies become harder to reconcile. Trade-offs accumulate or are deferred. Strategic intent can be interpreted differently across boundaries. Risks can emerge through interactions rather than through any single decision. And increasing effort may be required to reconcile consequences created by adaptations that were entirely reasonable when viewed locally. This is the hidden cost of mechanical agility. The danger is not that the project stops adapting. It is that: The project can continue adapting through its parts while progressively weakening its ability to adapt as a coherent whole. That is different from rigidity. A rigid system struggles to adapt. A mechanically agile system may adapt repeatedly and still drift. The Revealing Agile approaches did not eliminate the need for integration. Nor do the foundational Agile principles imply that they should. They expanded where sensing, judgment, learning and adaptation could occur. That can make project systems more responsive. But as adaptation becomes more distributed, the architecture must also account for the material consequences created across those distributed responses. The challenge is therefore not: How do we make teams less autonomous? Nor: How do we restore centralized control? It is: How do we preserve local adaptive capacity while keeping materially interdependent adaptations sufficiently coherent at system level? Because a project can have autonomous teams. Fast feedback. Short iterations. Frequent learning. Continuous delivery. And still face a deeper structural problem: Its parts may be adapting while the whole is losing adaptive coherence. And that takes us to the next reflection. PMBOK 8 Recognizes Integration. How Is Integrative Responsibility Allocated When Leadership Is Distributed? The first three reflections have progressively narrowed the question. Leadership can be distributed. Integrative responsibility can also be distributed. Agility can increase the number of places from which adaptation emerges. Now the argument must be tested against the profession's own architecture. Not to ask whether PMBOK 8 recognizes integration. It does. But to ask something more precise: When leadership, authority and management responsibilities are distributed, how explicitly does PMBOK 8 establish how integrative responsibility should be allocated and what conditions are required for it to be exercised across the project system? |
Posted on: September 02, 2026 03:47 AM
| Permalink |
Comments (0)
Who Integrates What Has Been Distributed?
 The Architecture of Integrative Responsibility The first reflection revealed a structural shift. Project leadership, authority, knowledge and management responsibilities no longer need to converge in a single role. They can be configured across sponsors, Project Managers, product roles, teams, functional leaders, governance structures, partners and, increasingly, AI-enabled capabilities. That distribution can be rational. It can place decisions closer to relevant knowledge, preserve useful autonomy and improve responsiveness. But distribution does not remove interdependence. A decision made legitimately in one part of a project can alter constraints, risks, commitments or possibilities elsewhere. And that brings us to the question left open by the first reflection: Who integrates what has been distributed? The instinctive response is to look for a person. Perhaps the Project Manager. Perhaps the sponsor. Perhaps someone else with sufficient authority. But that may already frame the problem too narrowly. The deeper question is: When project leadership and management responsibilities are distributed, how is integrative responsibility allocated, enabled and exercised so that the system remains coherent as a whole? That is an architectural question. And answering it requires us first to clarify what integration actually means. 1. Integration Is Not Governance Governance and integration are closely connected. But they perform different functions. Governance establishes structures within which legitimate organizational action occurs. It can define decision rights, responsibilities, accountability, escalation paths, oversight, constraints and decision boundaries. Integration addresses another problem: How do differentiated decisions, actions and dependencies continue to work together without undermining the coherence of the whole? Governance can establish who is authorized to decide and within what boundaries. Integration becomes necessary because decisions made within those legitimate boundaries can still interact in consequential ways. A sponsor may protect a strategic priority. A Product Owner may reprioritize value. A team may adapt its technical approach. A functional leader may reallocate scarce capability. Each action may fall legitimately within its respective domain. Yet their consequences may intersect. Governance structures legitimate action, decision rights, accountability and oversight, and may provide mechanisms through which interdependencies are addressed. Integration concerns whether those interdependencies are actually recognized, connected and reconciled across the project system. Good governance can enable integration. Poorly designed governance can constrain it. But governance and integration should not be treated as equivalent. 2. Integration Is More Than Coordination Integration can also be confused with coordination. Coordination matters. Activities must connect. Dependencies must be visible. Information must move. Interfaces must be managed. Work must be synchronized where necessary. But a project can be well coordinated and still contain unresolved systemic tensions. Two teams can synchronize their delivery while pursuing objectives that become mutually incompatible. A governance forum can circulate accurate information without resolving a consequential trade-off. A dashboard can expose a dependency without determining what should happen when two legitimate commitments can no longer both be preserved. Coordination connects activity. Integration reconciles material interdependence. Sometimes that reconciliation requires communication or adjustment. Sometimes it requires escalation. And sometimes it requires a consequential decision between objectives that cannot all be satisfied simultaneously. Coordination can be one mechanism through which integration is achieved, but coordination alone does not guarantee that material interdependencies will be reconciled. 3. Integration Is Not Alignment Either Alignment is also necessary, but insufficient. People can understand the strategy. Teams can share objectives. Stakeholders can agree on priorities. And still make decisions that become incompatible as conditions evolve. Projects change. Assumptions change. New information emerges. Constraints tighten. Resources become scarce. Risks interact. Priorities compete. Alignment achieved at one moment cannot pre-resolve every future interdependency. Integration therefore cannot mean maintaining permanent agreement. It requires the capacity to preserve sufficient coherence through change, tension and trade-off. Alignment establishes shared orientation. Integration helps preserve that orientation when interdependencies create consequences that must be reconciled. 4. What Actually Requires Integration? If integration is not identical to governance, coordination or alignment, what exactly must be integrated? Not everything. And not everyone into one centralized structure. What requires integration are the material interdependencies capable of affecting the coherence of the project as a whole. They may arise between strategic intent and delivery choices, customer value and organizational constraints, technical decisions and operational viability, project commitments and product priorities, local autonomy and cross-boundary dependencies, short-term delivery and longer-term value, or human judgment and AI-enabled analysis or action. Multiplicity alone does not create fragmentation. The integrative problem emerges when an action or decision in one part of the system creates consequences that matter elsewhere. This allows a more precise formulation: For the purposes of this inquiry, integration can therefore be understood as the organizational capacity to recognize, connect and reconcile material interdependencies so that differentiated decisions and actions remain sufficiently coherent at system level. The word sufficiently matters. Perfect coherence is neither realistic nor necessarily desirable. Complex projects contain legitimate tensions, competing objectives and unavoidable trade-offs. Integration does not eliminate them. It makes consequential interdependencies visible and creates the conditions through which they can be addressed. 5. Ownership Is Necessary, but Not Sufficient Once integration is understood as a function, the natural response is to ask who owns it. That matters. But ownership alone is insufficient. An organization can formally assign integration to a Project Manager while withholding the authority required to resolve a cross-boundary conflict. It can assign responsibility to a team that lacks visibility beyond its local environment. It can establish a governance forum with broad visibility but insufficient speed to intervene while consequential choices remain reversible. It can give a sponsor authority without enough operational information. Or it can distribute integrative responsibility across several actors without making their interfaces explicit. The question is therefore not only: Who owns integration? It involves three distinct dimensions. Allocation Who, or what configuration of actors, is expected to recognize and address material interdependencies? Enablement Do those actors have sufficient visibility, information, authority, capability, access, discretion and opportunity to intervene? Exercise Through what interactions, decisions, escalation mechanisms, feedback loops and trade-offs is integration actually performed? These distinctions matter because: Formal responsibility without sufficient integrative capacity does not create effective integration. 6. Integrative Responsibility Can Itself Be Distributed Integration does not logically require a single integrator. A Project Manager may hold substantial integrative responsibility in one configuration. In another, responsibilities may be shared among the Project Manager, sponsor, product leadership and teams. Highly autonomous teams may reconcile some interdependencies directly and escalate others when they exceed local authority, knowledge or visibility. Complex ecosystems may rely on several boundary-spanning roles, forums and decision mechanisms operating at different levels. Hybrid arrangements are possible. The critical question is therefore not simply whether integrative responsibility is centralized or distributed. It is whether its architecture matches the pattern of material interdependencies that the project actually contains. If an important dependency crosses several organizational boundaries but no actor or mechanism can operate legitimately across them, an integration weakness can emerge. If several actors share integrative responsibility but ownership of an interdependency remains ambiguous, responsibility may diffuse. Conversely, concentrating too much integrative responsibility in one actor can produce overload, bottlenecks and distance from relevant local knowledge. There need not be one universal integrator. What is required is an architecture of integrative responsibility appropriate to the system being integrated. 7. Integrative Responsibility Must Be Enabled Role assignment alone cannot create integration. An actor cannot reliably integrate consequences they cannot see. Visibility matters. They cannot resolve a tension they lack the authority or legitimate standing to address. Authority matters. They cannot evaluate a trade-off without sufficient knowledge of its context and consequences. Knowledge matters. They cannot exercise a responsibility for which they lack the relevant capability. Capability matters. They cannot act meaningfully where rules or structures leave them without sufficient discretion. Discretion matters. And they cannot intervene after the meaningful opportunity to influence the outcome has already disappeared. Opportunity to act matters. These conditions are not interchangeable. Authority without knowledge can produce poorly informed decisions. Knowledge without authority can reveal problems without enabling action. Responsibility without capability can create nominal ownership without effective control. Accountability without sufficient authority, capability, discretion or opportunity to act can become organizationally incoherent. Integrative responsibility therefore depends on a configuration of: Visibility, authority, knowledge, capability, discretion and opportunity to act. The title of "integrator" means little if the architecture does not preserve enough of these conditions for integration to occur. 8. Integration Is a Boundary Problem Some of the most consequential integration problems do not arise within established role boundaries. They arise across them. Between strategy and delivery. Between project and product. Between project and operations. Between customer value and regulatory obligation. Between organizational units. Between internal teams and suppliers. And, increasingly, between human judgment and AI-enabled recommendations or actions. Roles typically define responsibilities within boundaries. Interdependencies cross them. An actor can therefore perform exceptionally well within a legitimate domain and still participate in a system-level outcome that no one intended. Not necessarily because the actor failed. Not necessarily because governance was absent. And not necessarily because a decision was irrational. But because: Local legitimacy does not automatically produce global coherence. Integration is therefore inherently boundary-spanning. Its purpose is not to eliminate differentiated authority. It is to ensure that material interactions among differentiated authorities, responsibilities and decisions can become visible and resolvable at the level where their combined consequences matter. 9. When Legitimate Decisions Become Incompatible Consider a project in which several actors make individually defensible decisions. A Product Owner reprioritizes work to protect customer value. A technical team selects an architecture to protect reliability. A functional leader reallocates scarce expertise to another critical initiative. A sponsor protects a strategic deadline. Each decision may be legitimate within its own authority boundary. Yet the combination may no longer be coherent. The project then faces a different category of problem. Not: Which decision is wrong? But: Which combination of decisions remains sufficiently coherent with the project's objectives, constraints and legitimate commitments? Local optimization alone cannot answer that question. The system needs the capacity to identify the interaction, make the trade-off visible and enable a legitimate response while meaningful intervention remains possible. That is integrative work. And this is where a distributed project system reveals whether it possesses integrative capacity or merely distributed responsibility. 10. The Architecture of Integrative Responsibility We can now return to the original question: Who integrates what has been distributed? The answer cannot be reduced in advance to a single role. The more important question is whether the project possesses an explicit architecture of integrative responsibility capable of answering: Who can see the material interdependency? Who is responsible for surfacing it? Who has legitimate authority to act? Who must participate in the trade-off? Who can intervene while meaningful options still exist? Who remains accountable for the resulting decision? And what happens when these conditions reside in different places? This is where distribution becomes an architectural problem. Not because distributed leadership is inherently weak. But because: Distributed responsibility without sufficient integrative capacity can leave consequential relationships between otherwise legitimate decisions unresolved. The challenge is therefore not to put everything back at the center. Nor is it simply to appoint an integrator. It is to make the architecture of integration as explicit as the architecture through which leadership, authority and management responsibilities have been distributed. The Revealing Project leadership can be distributed. Authority can be distributed. Knowledge can be distributed. Decision-making and management responsibility can be distributed. Integrative responsibility can also be distributed. But one condition remains: The interdependencies among those distributions still have to be recognized and reconciled somewhere in the system. That is the architectural challenge. Not: Who controls the whole? But: How does the whole remain coherent when no single actor necessarily contains it? And that leads directly to the next reflection. When Agility Becomes Mechanical The Hidden Cost of Weak System-Level Integration Autonomy can remain active. Teams can continue delivering. Iterations can continue. Metrics can continue moving. And yet a deeper question remains: Is the system still adapting as a whole, or are its parts merely moving faster? |
Posted on: August 31, 2026 09:11 AM
| Permalink |
Comments (5)
The New Ways of Working in Projects
 A New Architecture for Adaptive Organizations Throughout this series, I have sought to examine three recent documents that I consider particularly relevant to understanding the evolution of Project Management. The new Agile Practice Guide shows that the discipline has evolved far beyond the choice between predictive and agile approaches. The Manifesto for Enterprise Agility shows that adaptation no longer depends only on teams and increasingly involves the organization as a whole. The Closing the Change-Readiness Gap report shows that many transformations continue to fail not because methodologies are absent, but because the organizational conditions required to sustain change deteriorate during implementation. Across the previous four articles, I have sought to demonstrate that these documents, although addressing different topics, converge in the same direction. Taken together, they show that the evolution of Project Management does not result from replacing one methodology with another. It reflects a deeper transformation in how projects, organizations, people, and technologies interact to deliver change and create value in contexts characterized by increasing complexity, interdependence, and a continuing need for adaptation. This leads naturally to a broader question. What, then, characterizes the new ways of working in projects? In my view, the answer does not lie in a specific methodology or in the adoption of a new set of practices. It lies in the evolution of the organizational logic within which projects operate. Projects are progressively understood not only as execution mechanisms, but as temporary organizations embedded within broader organizational systems, capable, depending on their nature and context, of contributing to the adaptation of the permanent organization and to its capacity to create value. This evolution can be understood through eight fundamental transitions. These transitions do not represent sequential stages, nor do they mean that the principles that established the discipline have lost their validity. They represent complementary shifts in emphasis that reflect the adaptation of Project Management to the challenges faced by organizations that are increasingly complex, interdependent, and knowledge-intensive. Together, they are organized into four interdependent domains:
1. From Execution to Sustainable Value Creation For decades, project success was predominantly assessed by the ability to deliver the defined scope, meet agreed deadlines, and control planned costs. These dimensions remain indispensable. Without execution discipline, consistent results are difficult to achieve. However, execution performance alone does not provide a sufficient basis for evaluating the broader outcomes and value associated with a project. A project can finish on time and within budget, deliver all specified requirements, and still fail to produce relevant benefits for customers, the organization, or society. It can also achieve its immediate objectives at the cost of degrading organizational capabilities, creating technical debt, reducing future flexibility, or increasing risks that only become visible after the initiative has closed. This requires us to distinguish between related but different dimensions. Execution performance tells us how the project was carried out against the applicable commitments and criteria. Outcomes tell us what that execution produced or made possible. Value requires us to go further and assess the relevance of those outcomes, for whom they are relevant, over what time horizon, and with what benefits, costs, risks, or consequences. Creating value therefore comes to mean contributing to relevant outcomes and conditions during and beyond the realization of the project. That value may take different forms:
What changes is the frame within which these capabilities are understood. They cease to be ends in themselves. They become instruments through which the purpose that justified the project can be realized and through which the project can contribute to the creation and protection of sustainable value. Broadening the focus from execution to value does not eliminate the assessment of project performance. It places it within a broader evaluation architecture. Execution performance, outcomes, and value should therefore be assessed as related but distinct dimensions. 2. From the Plan to Guiding Purpose Planning remains one of the most important capabilities in Project Management. Complex projects require clear objectives, explicit priorities, credible estimates, work sequencing, dependency management, and effective coordination mechanisms. The problem was never the existence of plans. The real challenge is recognizing that no plan can fully anticipate a context that is constantly changing. New opportunities emerge. Constraints change. Risks materialize in unexpected ways. Technologies evolve. Customer needs change. Assumptions that were initially valid cease to reflect reality. When this happens, simple fidelity to the plan can lead precisely to a departure from the strategic intent that justified the project. It is in this context that purpose assumes a guiding role. Purpose does not replace the plan. It gives the plan meaning. While the plan organizes the action initially envisaged, purpose provides the reference point needed to decide when that action should be maintained, adjusted, or substantially revised. However, a purpose formulated only in generic terms will rarely guide relevant decisions effectively. To fulfil that role, it needs to be translated into concrete elements that legitimize adaptation and guide team action. These elements include:
Adaptive projects do not plan less. They plan with the recognition that the path may evolve without necessarily changing the strategic direction. Purpose offers greater continuity than the plan because it provides the reference point through which the plan itself can be reinterpreted whenever reality requires it. Purpose may also evolve when the strategic context changes significantly. But such evolution should result from a conscious strategic decision, not from circumstantial adjustments in execution. This is one of the most significant changes in the new ways of working in projects. Planning is no longer understood as an attempt to predict the future exhaustively. It becomes a mechanism for coordination, learning, and adaptation, continuously guided by purpose and sustainable value creation. 3. From Hierarchical Authority to Contextual Authority Hierarchical structures continue to play an indispensable role in organizations. They establish responsibilities, allocate resources, define governance mechanisms, and ensure accountability for decisions with greater impact. However, the increasing complexity of projects has made it clear that not every decision can, or should, depend exclusively on formal authority. In environments characterized by high interdependence, rapid change, and increasing specialization, many decisions depend on proximity to the problem, the quality of available information, relevant expertise, and the ability to act at the right moment. Whenever authority remains excessively distant from operational reality, response times increase, hierarchical escalations multiply, relevant context is lost, and the capacity to adapt is reduced. The new ways of working in projects seek to respond to this challenge through a more contextual distribution of authority. This is not about replacing hierarchy or advocating universal models of self-management. It is about recognizing that different decisions require different combinations of formal authority, knowledge, responsibility, and capacity for intervention. In this context, I propose understanding contextual authority as: Authority legitimately assigned to those who have the appropriate combination of knowledge, capability, proximity to the problem, necessary discretion, and opportunity to decide or act, within the limits defined by organizational governance. This definition highlights a fundamental distinction. Proximity to the problem, by itself, does not legitimize a decision. Likewise, technical expertise alone is not sufficient. The legitimacy of authority depends on an appropriate combination of:
It complements it. Governance remains responsible for defining limits, allocating decision rights, and preserving accountability. Within that framework, certain decisions can move closer to those who are best positioned to make them. The objective is not merely to decide faster. It is to improve the quality and legitimacy of decisions, strengthen their capacity for effective implementation, and support the organization’s capacity to adapt. In the new ways of working in projects, authority is progressively understood not only as an attribute of hierarchical position. It is also understood through the legitimate distribution of decision rights and capacity for intervention according to context, while preserving governance, responsibility, and sustainable value creation. 4. From Operational Efficiency to Organizational Adaptability Efficiency remains an indispensable capability for any organization. Improving processes, reducing waste, using available resources effectively, and increasing productivity remain legitimate and necessary objectives. However, increasing market volatility, technological acceleration, and interdependence between organizations have shown that efficiency alone no longer guarantees sustainability. An organization can achieve very high levels of efficiency precisely because it has been optimized for a particular set of conditions. When those conditions change, that same optimization can become a constraint. Highly standardized processes may inhibit innovative responses. Overly rigid structures may delay critical decisions. Resources permanently operating at full capacity may reduce the ability to absorb unexpected disruption. Capabilities that were once distinctive may lose relevance in the face of new technologies, new business models, or changing customer expectations. It is in this context that adaptability assumes a strategic role. Adaptability does not mean improvisation. Nor does it mean continuously changing priorities or structures without criteria. It means preserving the capacity to reconfigure the organization when the conditions that supported the existing configuration no longer produce results that remain appropriate to the relevant conditions and objectives. That reconfiguration may involve:
It seeks to preserve the organization’s capacity to continue creating value when the context changes. This is precisely why efficiency and adaptability are not necessarily competing objectives. Efficiency improves the performance of the current configuration. Adaptability allows that configuration to be questioned and transformed when it no longer responds adequately to reality. The most adaptive organizations are not necessarily those that change most frequently. They are those that can distinguish when stability continues to create value and when change becomes necessary. This distinction represents an important evolution in how organizational performance is understood. For a long time, the main challenge was to optimize relatively stable systems. Today, the challenge also lies in preserving the capacity to transform them without compromising responsibility, coherence, learning, or strategic direction. In the new ways of working in projects, excellence no longer results only from operational efficiency. It results from the capacity to combine execution discipline with learning, experimentation, and adaptation. Efficiency enables the existing system to be executed better. Adaptability enables that system to be questioned and transformed when it no longer responds adequately to reality. 5. From Coordinating Activities to Preserving Coherence Coordination has always been one of the central responsibilities of Project Management. Planning activities, managing dependencies, synchronizing teams, and controlling interfaces remain indispensable capabilities for turning objectives into results. However, as projects have increasingly been carried out within more distributed organizations, more interdependent ecosystems, and contexts of continuous change, it has become clear that coordinating activities is no longer enough. It is possible to execute hundreds of tasks correctly and still progressively lose the connection between what the project is doing and what the organization is trying to achieve. When this happens, the problem is no longer one of coordination. It becomes a problem of coherence. Although these concepts are often used interchangeably, they address different challenges. Coordination seeks to ensure that people, teams, and activities work together in an integrated manner. Coherence seeks to ensure that those activities remain sufficiently compatible with the project’s purpose, the organization’s strategy, decision criteria, available capabilities, and the outcomes that justify the initiative. A project may demonstrate excellent operational coordination and, at the same time:
But it is no longer coherent. In the new ways of working in projects, preserving and reassessing coherence therefore becomes a permanent responsibility. This requires purpose, decisions, capabilities, incentives, governance, and execution to remain sufficiently compatible for adaptation to occur without fragmenting the system. It is important to emphasize that coherence does not mean uniformity. Adaptive organizations depend on diversity, experimentation, and learning. Different teams may adopt different solutions. Similar projects may follow different approaches. Changes in context may justify substantial shifts in direction. Coherence does not eliminate that diversity. It seeks to ensure that diversity remains understandable, justifiable, and compatible with the organization’s strategic objectives. A practice, structure, or capability that was previously coherent may cease to be so when the context changes. A change may therefore require abandoning practices, structures, or capabilities that were once considered exemplary. The problem does not lie in change itself. It lies in introducing changes that inadvertently destroy the conditions required to continue creating value. In the new ways of working in projects, coordination ceases to be the final objective. It becomes a necessary condition for preserving something more important. Coordination keeps the work connected. Coherence seeks to ensure that those connections remain guided by a legitimately applicable purpose and by value creation. 6. From Managing the Project in Isolation to Integrating with the System For a long time, projects were understood as relatively autonomous initiatives. They had their own objectives, dedicated resources, specific control mechanisms, and their own success criteria. That perspective remains useful for understanding the management of an individual initiative. But it has become insufficient to explain the reality of contemporary organizations. Today, few projects truly exist in isolation. Each initiative continuously interacts with products, operations, programs, portfolios, partners, suppliers, customers, technology platforms, regulatory requirements, and other changes taking place at the same time. It receives resources from the permanent organization. It competes for limited capabilities. It produces changes that will need to be absorbed by operations. The work carried out within the project may generate knowledge that is relevant to other initiatives. It produces impacts that frequently extend beyond the initially defined scope. As a result, the project can no longer be understood only as an independent unit of execution. It can also be understood as a temporary organization embedded within broader organizational systems. This change significantly alters the perspective of Project Management. The challenge is no longer only to optimize the performance of the individual initiative. It also involves understanding and managing the relationships that connect the project to the systems on which it depends and on which it has effects. That integration requires consideration of, among other things:
Some initiatives are predominantly technical, operational, or departmental, with relatively limited interaction with the broader organizational system. Others, by contrast, cross multiple functional areas, involve different organizations, transform critical processes, or contribute to changes in business models. The greater the interdependence, the greater the need to understand the project as an element of integration and not merely as an execution mechanism. This perspective does not change the temporary nature of projects. It changes how we understand their function. The project remains oriented toward producing a specific change. But that change is understood as part of a broader system of value creation. In the new ways of working in projects, managing an initiative effectively also means understanding the system that makes the initiative possible and that will need to integrate its results. In sufficiently interdependent contexts, the project can no longer be understood only as a unit of execution. It also becomes a mechanism of organizational integration. 7. From Exclusively Human Collaboration to Human-Computational Collaboration Artificial intelligence represents one of the most significant transformations currently taking place in organizations. Much of the discussion has focused on the automation of tasks traditionally performed by people. Planning. Risk analysis. Information processing. Document production. Monitoring. Forecasting. Decision support. However, the deeper impact of artificial intelligence may lie not in replacing activities, but in transforming the very nature of collaboration. For decades, project work was based almost exclusively on cooperation between people. Today, computational capabilities increasingly participate in the production of information, identification of patterns, exploration of scenarios, formulation of recommendations, and support for decision processes. Projects therefore cease to mobilize only human capabilities. They begin to integrate human and computational capabilities within the same work architecture. This evolution raises challenges that go far beyond technology. The question is no longer only what artificial intelligence can do. It also becomes necessary to determine:
On the contrary. It makes it even more important to preserve the conditions that legitimize that responsibility. Holding someone responsible for a decision requires that the person actually have the authority, knowledge, capability, discretion, access to relevant information, and a real opportunity to intervene. Whenever those conditions cease to exist, the organization risks assigning responsibility without preserving the conditions that make that attribution legitimate. The real challenge therefore ceases to be exclusively technological. It also becomes architectural. It consists of explicitly defining how work, decision-making, supervision, and responsibility are distributed between human and computational capabilities. Artificial intelligence may significantly expand the analytical capacity of organizations. But its value will also depend on the quality of the organizational architecture within which it is used. In the new ways of working in projects, technology ceases to function only as a support tool. Computational capabilities become part of the organization’s capability architecture and, when appropriately integrated, can expand analytical capacity and support, challenge, or complement human judgment, without eliminating the need for legitimately attributed responsibility. The future of Project Management will depend not only on the quantity or sophistication of artificial intelligence being used, but also on the quality of the organizational architecture that frames collaboration between human and computational capabilities. 8. From Local Learning to Organizational Learning Learning has always been part of Project Management. The work carried out in projects generates experience, tests assumptions, reveals limitations, and may produce new knowledge and opportunities for learning. For a long time, however, a significant part of that learning remained essentially local. Teams learned. Projects ended. People moved to new initiatives. Lessons were recorded. But a significant part of that knowledge never truly reached the organization. The problem does not lie only in whether learning exists. It also lies in the organization’s capacity to transform relevant experience into learning and to allow that learning to contribute to more enduring organizational capability. The new ways of working in projects recognize that the value of learning does not depend only on what each team discovers during execution. It also depends on the organization’s capacity to preserve, interpret, adapt, and reuse relevant knowledge in future contexts. This transformation requires far more than lessons-learned repositories. It requires an organizational architecture capable of transforming relevant experience into learning and allowing that learning to contribute to organizational capability. That architecture includes, among other elements:
Solutions that are effective in one project may prove unsuitable in another context. Organizational learning does not consist of automatically replicating what worked. It also consists of developing the capacity to distinguish between transferable principles and context-dependent practices. Each project may therefore represent more than an opportunity to deliver results. It may also contribute to the organization’s progressive development of its capacity to understand, decide, adapt, and create value. In the new ways of working in projects, learning ceases to be merely a possible consequence of execution. Organizational learning becomes a strategic dimension of the organization’s future capability. The legacy of a project lies not only in what it delivers. It also lies in what it enables the organization to understand, decide, and do better afterwards. An Integrated Architecture for the New Ways of Working in Projects The eight transitions presented throughout this article do not constitute independent changes, nor do they represent a mandatory evolutionary sequence. They describe different manifestations of the same organizational transformation. Together, they are organized into four interdependent domains that make it possible to understand the evolution of Project Management beyond the methodological dimension. The first domain, Direction, redefines what guides action. Execution remains indispensable, but it is understood as an instrument for creating value. The plan remains necessary, but it ceases to be the only reference point for decision-making. Purpose provides the stability needed to adapt the path without losing strategic direction. The second domain, Governance and Coherence, redefines how decisions are distributed and articulated. Authority moves closer to those who have legitimate conditions for deciding. Coherence seeks to ensure that those decisions remain sufficiently compatible with purpose, strategy, organizational capabilities, and intended outcomes. The third domain, Organization and Adaptation, broadens the unit of analysis of Project Management. Efficiency and adaptability are not necessarily competing objectives and can complement one another. At the same time, the project ceases to be seen only as a temporary initiative and is understood as a temporary organization embedded within broader organizational systems. The fourth domain, Capabilities and Learning, incorporates two decisive transformations. On the one hand, it recognizes that value creation may result from collaboration between human and computational capabilities. On the other, it recognizes that learning generated in project contexts may contribute to the development of the organization’s future capability when mechanisms exist to preserve, interpret, adapt, and reuse it. The relevance of this architecture does not lie in each of these dimensions in isolation. It lies in the way they reinforce one another. An organization will struggle to adapt if it preserves efficiency while ignoring learning. It will struggle to distribute authority sustainably without preserving coherence. It will not create value consistently if it loses the connection between purpose, decision-making, and execution. Nor will it fully benefit from artificial intelligence if it does not preserve the conditions that legitimize human responsibility. It is precisely this interdependence that characterizes the new ways of working in projects. They do not represent a new methodology. They represent a conceptual architecture for understanding how direction, governance, adaptation, capabilities, and learning interact to sustain the creation and protection of value in adaptive organizations. A Definition of the New Ways of Working in Projects Based on the analysis developed throughout this series, I propose the following definition: The new ways of working in projects represent an evolution of Project Management that extends execution management to include the creation and preservation of the conditions that enable projects, understood as temporary organizations, to respond and adapt to relevant changes within the context of the permanent organizations in which they are embedded, integrating value-oriented direction, contextual authority legitimized by governance, organizational coherence, systemic integration, human-computational collaboration, and organizational learning, in order to contribute to the creation and protection of sustainable value in contexts characterized by high complexity, interdependence, and change. From this perspective, sustainable value refers to the creation and protection of relevant benefits and other outcomes without unjustifiably degrading the conditions that enable the organization to continue learning, adapting, deciding responsibly, and creating and protecting value in the future. This definition does not replace the principles that have historically structured Project Management. Planning, and the management of scope, schedule, cost, quality, risk, resources, and stakeholders remain fundamental capabilities. What changes is the frame within which those capabilities are applied. The discipline progressively ceases to focus only on execution excellence. It also becomes concerned with preserving the organizational conditions that make that execution relevant in a context of continuous change. Conclusion This series began with an apparently simple question. Why is talking only about methodologies no longer sufficient to understand the evolution of Project Management? Across the first four articles, I sought to show that three recent documents point, from different perspectives, toward the same evolutionary direction. The new Agile Practice Guide broadens our understanding of adaptation and value creation. The Manifesto for Enterprise Agility shows that team agility depends on the adaptive capacity of the organization. The Closing the Change-Readiness Gap report shows that transformation can fail when the organizational conditions required to realize change cease to exist. In this fifth article, I have sought to take one further step. Rather than examining each of these contributions separately, I have proposed a conceptual synthesis that seeks to explain what they reveal when considered together. The new ways of working in projects do not represent a break with the discipline we know. They represent the continuation of its evolution. An evolution in which excellence is no longer measured only by the ability to execute projects efficiently, but also by the capacity to preserve direction, responsibility, coherence, adaptation, learning, and sustainable value creation. It is in this sense that I propose understanding the new ways of working in projects. Not as a new methodology. Nor as another management trend. But as a conceptual architecture that helps us interpret how projects, as temporary organizations, permanent organizations, people, and computational capabilities interact to transform strategic intent into outcomes and sustainable value. The evolution of Project Management goes beyond doing projects better. It also requires us to understand how projects can help organizations execute, decide, learn, adapt, and create value in a world of continuous transformation. |
Posted on: August 30, 2026 03:10 AM
| Permalink |
Comments (1)
When Project Leadership Becomes Distributed
 The Structural Shift Reshaping Project Management Something important is changing in project management. Not because projects no longer need leadership. Not because the Project Manager is disappearing. And not because one methodology has replaced another. The change is more structural. Leadership, management responsibilities and decision authority no longer need to converge in a single role. A sponsor may shape strategic direction. A Product Owner may determine value priorities. A Project Manager may integrate work across domains. Teams may make decisions close to execution. Functional leaders may control critical capabilities. Governance bodies may establish decision boundaries and escalation paths. Customers, partners and suppliers may influence choices that materially affect outcomes. And AI increasingly augments how information is interpreted, alternatives are generated and decisions are prepared. None of this means that leadership has disappeared. It points to something different: Project leadership is becoming increasingly distributable. And that changes how we need to understand the architecture of the project. 1. From a Role-Centered View to a Distributed System Project leadership has often been represented through a role-centered model. At its center sits the Project Manager, surrounded by plans, resources, stakeholders, risks, decisions and delivery responsibilities. Reality has always been more complex than that representation. Sponsors govern. Functional managers control resources. Customers shape requirements. Teams contribute expertise and judgment. Senior leaders make decisions beyond the authority of the Project Manager. Even in role-centered configurations, project leadership need not be exercised by one person alone. But the Project Manager has often provided a visible point around which much of the project could be understood and organized. That representation is becoming less sufficient for understanding how many contemporary projects are actually led. Project environments combine predictive, adaptive and hybrid approaches. Work crosses organizational boundaries. Product and project structures coexist. Teams operate with different degrees of autonomy. Governance can be centralized, decentralized or hybrid. Decision authority may vary according to the nature and consequences of the decision. The result is not necessarily less leadership. It is a different topology of leadership. Leadership may emerge from several places. Authority may reside elsewhere. Relevant knowledge may be distributed even more widely. And management responsibilities may be configured differently according to context. The relevant question is therefore no longer simply: Who is the Project Manager? It is: How is the project actually being led? 2. Distribution Is Not Disappearance This distinction matters. When responsibilities associated with one role are exercised by several actors, it is tempting to conclude that the role has been hollowed out. That conclusion moves too quickly. A function can be redistributed without disappearing. Authority can become differentiated without becoming absent. Leadership can become shared without becoming weaker. Autonomy can increase without eliminating accountability. And integration can be achieved through different organizational configurations. The structural shift is therefore better understood as a change in allocation. Who has authority over what? Where does the relevant knowledge reside? Who can make which decisions? Who can commit resources? Who interprets strategic intent when conditions change? Who can see consequences beyond a local boundary? Those questions need not produce the same answer. This is why distributed does not fully describe the phenomenon. The deeper change is that leadership, authority and management responsibilities are becoming increasingly distributable. They can be configured differently according to the project, governance model, delivery approach, organizational structure and nature of the work. That flexibility can be a strength. But it also changes the conditions under which the project must remain coherent as a system. 3. Distribution Can Be Rational There are good reasons not to concentrate every decision and responsibility in one role. Relevant knowledge is often distributed and locally situated. Specialists may understand technical realities that others cannot fully see. Teams close to the work can often respond more quickly to changing conditions. Product decisions may require authority different from delivery decisions. Strategic choices and operational choices may legitimately belong at different levels. And some decisions benefit from being made closer to the knowledge required to make them. Distribution can therefore improve responsiveness. It can support autonomy. It can reduce unnecessary decision bottlenecks. It can enable specialization. And, in appropriate contexts, it can increase adaptability. The question is not whether this evolution should simply be reversed. The question is what this evolution requires from the architecture around it. 4. Leadership, Authority, Knowledge and Responsibility Are Different Distributed project environments make distinctions visible that role descriptions can easily obscure. Leadership is not authority. A person may influence direction without possessing formal decision rights. Authority is not knowledge. Someone may legitimately make a decision without possessing all the information relevant to its consequences. Knowledge is not responsibility. The person who understands a consequence may not own the decision or action associated with it. Responsibility is not capability. Someone may be assigned responsibility for an outcome without controlling all the conditions required to achieve it. Responsibility is not accountability. Responsibility for performing work and accountability for consequences do not necessarily reside in exactly the same place. And management responsibility is not necessarily system-level visibility. An actor can manage a legitimate part of the project exceptionally well while seeing only part of the whole. These dimensions can therefore be allocated differently across the same project system. We may encounter distributed leadership with concentrated authority. Distributed decision rights with concentrated accountability. Distributed knowledge with centralized decision authority. Or hybrid configurations combining several of these patterns. That is not inherently a defect. It is an architectural condition that needs to be understood. 5. Expanding the Unit of Analysis If leadership can be exercised across several actors, analysing the Project Manager alone becomes insufficient for understanding how the project is actually led. A fuller unit of analysis is therefore the project system, not the Project Manager in isolation. Consider a difficult trade-off. The sponsor may understand strategic importance. The team may understand technical feasibility. The Product Owner may understand customer value. The Project Manager may understand dependencies, commitments and delivery consequences. Finance may understand economic exposure. Operations may understand what the organization can absorb after delivery. A supplier may control a critical external dependency. An AI-supported system may identify patterns or alternatives that none of these actors detected independently. Where can leadership emerge? Potentially across several of these actors. Where does authority reside? Not necessarily in the same places. Where does accountability reside? Again, it may differ. A contemporary project can therefore be understood as a network of differentiated but interdependent capacities. Understanding how it is led requires analysing not only the actors themselves, but also the relationships between them. 6. Interdependence Is the Hidden Variable Distribution becomes architecturally significant because project decisions are rarely independent. A team can make a technically sound decision that changes cost exposure. A Product Owner can make a rational prioritization decision that affects a regulatory commitment. A sponsor can protect strategic value while creating delivery consequences elsewhere. A functional manager can optimize scarce resources while weakening another critical dependency. Each decision may be legitimate within its own frame. Tension can emerge in the relationships between those frames. This is why the central issue created by distribution is not simply: Who has authority? It is also: How are interdependent decisions kept coherent when the authority to make them resides in different places? Different project configurations may answer that question differently. What matters at this stage is more fundamental: Distributing authority does not eliminate the interdependencies among the decisions being distributed. The more distributable leadership, authority and management responsibilities become, the more important it becomes to understand how those interdependencies are recognized and reconciled. 7. Recentralization Is Not the Automatic Answer Recognizing the difficulty of distributed interdependence can lead to an apparently simple response: return authority to a central Project Manager. That does not necessarily follow. Centralization can carry significant costs. It can distance decisions from relevant knowledge. It can create bottlenecks. It can weaken useful autonomy. It can concentrate cognitive load in people who cannot realistically understand every relevant element of a complex project. And it can create the appearance of control without the information required to exercise that control intelligently. Distribution, however, is not sufficient by itself either. Distributed authority can preserve proximity to knowledge and increase responsiveness while still leaving interdependent decisions insufficiently reconciled. Neither centralization nor distribution is sufficient as an organizing principle on its own. What matters is the architecture through which autonomy, authority and interdependence are structured. The challenge is therefore more demanding than choosing between centralized and distributed leadership. It is to preserve the benefits of distribution without losing the ability of the project to act as a coherent whole. That is not primarily a question of hierarchy. It is a question of architecture. 8. AI Adds Another Layer to Distribution AI adds another dimension to this transition. AI systems can augment analysis, identify patterns, synthesize large volumes of information and support forecasting, planning and risk identification. Increasingly agentic systems may also perform bounded actions within project workflows. But greater cognitive or execution capability does not automatically produce greater system-level coherence. An AI system can optimize against a bounded objective without representing every relevant organizational, strategic, regulatory or ethical constraint. It can improve the quality or speed of a local decision without resolving tensions between objectives elsewhere in the system. AI therefore does not remove the architectural question created by distribution. In AI-enabled project environments, integration increasingly extends beyond differentiated human roles and decisions. Technological capabilities can now shape analysis, recommendations and, increasingly, bounded actions within project workflows. The architectural question therefore expands: How should those technological capabilities coexist with human authority, responsibility and accountability while preserving coherence across the project system? 9. The Core Architectural Question This changes the question with which the profession should begin. Not: Is the Project Manager disappearing? Not: Should teams have more autonomy? Not: Does Agile weaken leadership? And not: Should leadership return to the center? Those questions begin with roles or methods. The more fundamental question begins with the system: When project leadership, management responsibilities and decision authority become increasingly distributable, what conditions allow the project to remain coherent as a whole? That question does not assume that distribution is a problem. It does not assume that integration has been forgotten. And it does not assume that a new role is required. It asks us to examine the architecture through which differentiated but interdependent actors continue to produce coherent collective action. That is a different conversation about the future of project management. 10. The Revealing What appears to be changing is not the disappearance of leadership. Nor is it necessarily the disappearance of the Project Manager. It is the way leadership, authority, knowledge and management responsibilities can be configured across the project system. That shift asks us to move beyond leadership understood primarily through roles and examine leadership through a system of differentiated responsibilities, authority, knowledge and interdependence. If that is the emerging condition, the challenge ahead is not to decide who should regain control. It is to understand what must happen between the parts so that distribution does not become fragmentation. A project can distribute leadership. It can distribute authority. It can distribute decisions. It can distribute management responsibility. But it cannot distribute away the need for the whole to remain coherent. And that takes us to the next question: Who integrates what has been distributed? Next in THE AWAKENING: Article 2 - Who Integrates What Has Been Distributed? The Architecture of Integrative Responsibility |
Posted on: August 28, 2026 04:46 AM
| Permalink |
Comments (0)
THE AWAKENING
 A Reflection Series on the Future of Project Leadership Something is changing in project management. Not simply in the methods we use. More fundamentally, in how leadership, authority, decision-making and management responsibility are organized across the project system. Projects increasingly operate through multiple actors. Sponsors shape direction. Product roles influence value and priorities. Teams exercise greater autonomy. Governance structures shape how decision authority is allocated. Specialists contribute increasingly differentiated knowledge. AI is beginning to augment how information is interpreted, decisions are prepared and work is performed. None of this means that leadership is disappearing. It means that leadership and management responsibilities are becoming increasingly distributable. And that raises a different question: As leadership, decision authority and management responsibilities become increasingly distributable, what preserves the coherence of the whole? Project management already recognizes the importance of integration. The challenge is therefore not whether integration matters. It is how integrative responsibility is allocated, enabled and exercised when no single actor necessarily possesses the authority, knowledge, visibility or capability required to understand and shape the entire system. This matters because distributed systems create a particular possibility: A decision may be legitimate within one role. Another may be legitimate within another. A team may optimize rationally within its boundaries. Governance may act correctly within its authority. And yet those decisions may not remain coherent together. The problem, then, is not distributed leadership itself. Nor is the answer necessarily a return to centralized control. The deeper question is architectural: How do we preserve system-level integration while retaining the autonomy, specialization and distributed authority increasingly present in contemporary project environments? Over the coming weeks, THE AWAKENING will examine that question progressively. Not by assuming that the Project Manager has disappeared. Not by assuming that agility has weakened leadership. And not by assuming in advance that a new leadership archetype is the answer. Instead, we will examine what has changed, where integrative responsibility resides, under what conditions locally legitimate decisions can become globally incoherent, what current project management already provides, and what may still need to evolve. Because the future of project leadership may depend less on putting control back at the center, and more on understanding how coherence can be preserved across increasingly distributed configurations of leadership and authority. THE AWAKENING begins there. |
Posted on: August 26, 2026 07:33 AM
| Permalink |
Comments (0)
