Is the Project Manager Still the Right Unit of Professional Identity?
 From Role Identity to System Contribution Article 6 separated a necessary function from the assumption that it 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 legitimate accountability from the assumption that responsibility, authority and causal capacity necessarily reside in the same place. Article 8 challenged another familiar relationship. Control does not necessarily require centralization. Autonomy does not automatically produce adaptability. And effective control must be evaluated by what the project system needs to protect and govern, not merely by the existence of formal controls. Together, these deconstructions create a more uncomfortable question. If important project functions can be concentrated, distributed or configured through different combinations of actors and mechanisms, what follows for the professional role around which project management has traditionally organized much of its identity? The Project Manager remains one of the most recognizable units of professional identity in the field. People develop qualifications for the role. Develop careers around it. Acquire certifications associated with it. Organizations define responsibilities through it. Competency models describe what professionals in the role should know and be able to do. And professional communities often discuss the future of project management by asking what the future Project Manager should become. That is understandable. Roles provide clarity. They concentrate expectations. They help structure accountability. They support professional development. They make capabilities easier to organize, teach, assess and deploy. But another proposition does not automatically follow: That the role through which project work has historically been organized must remain the primary unit through which professional contribution is understood. That is the fourth deconstruction. Questioning the role as the primary unit for analyzing professional contribution does not yet imply replacing it as a unit of professional identity. Those are different questions. And this article must keep them separate. 1. A Role Is Not the Same as a Contribution A role answers an organizational question. Who is expected to carry particular responsibilities within a given arrangement? A contribution answers a different question. What does an actor, mechanism or technology add to the system's capacity to perform what the project requires? These questions often overlap. But they are not equivalent. A function concerns what must be performed or accomplished. A capability concerns the capacity required to perform it effectively. A contribution concerns what a particular actor, role, mechanism or technology provides toward that performance. And a role is one organizational arrangement through which expectations, responsibilities and often authority are allocated. These distinctions matter because they prevent different analytical levels from collapsing into one another. A Project Manager may integrate work. Facilitate decisions. Coordinate dependencies. Protect commitments. Surface risks. Connect stakeholders. Support governance. Translate information across boundaries. Preserve context. Enable adaptation. And maintain attention on the project as a whole. Those contributions may be highly valuable. But their value does not derive solely from the fact that they are performed by someone holding the title Project Manager. Nor does the fact that other actors can perform some of them prove that the Project Manager role has become obsolete. The analytical problem is different. We should not infer the necessity of a contribution from the existence of a role, nor infer the obsolescence of a role merely because its contributions can be distributed. That distinction matters. A system may require a contribution without requiring a dedicated role. It may also require a dedicated role precisely because responsibility for producing that contribution would otherwise remain insufficiently allocated, enabled or exercised. Different project configurations may therefore produce different answers. 2. Why Professional Identity Forms Around Roles Before questioning role identity, we should make the strongest case for it. Roles reduce ambiguity. They establish expectations. They help people understand what they are responsible for. They allow organizations to recruit, develop and assess professionals against recognizable capability profiles. They provide a language through which authority, accountability and career progression can be structured. They also provide professional communities with something important: identity. Someone can say: I am a Project Manager. That statement communicates more than a list of tasks. It signals a field of practice. A body of knowledge. A professional community. A developmental path. And a claim about the kinds of problems the person is prepared to address. Professional identity therefore has value beyond organization design. It contributes to learning, professional recognition, mobility and community. So the question is not whether professional roles matter. They do. The harder question is: When does a useful professional identity begin to constrain how we understand the contributions the project system actually requires? 3. Role Boundaries Can Clarify Responsibility Role boundaries are not inherently restrictive. They can create necessary clarity. A Project Manager may be expected to maintain an integrated view of the project and its delivery conditions. A Product Owner may be responsible for product priorities. A technical authority may protect architectural integrity. A sponsor may protect strategic alignment and major commitments. An operational leader may protect conditions required for sustainable adoption. These distinctions can make responsibility easier to understand. They can also reduce duplication. Clarify decision rights. Support escalation. And make accountability more defensible. A system in which everyone is responsible for everything may become a system in which nobody knows what they are expected to notice, decide or protect. Role differentiation can therefore support coherence. But differentiation creates boundaries. And boundaries influence more than authority. They can also influence what actors attend to, how they interpret what they see and which consequences they regard as belonging to their field of concern. This is where the role question becomes more difficult. 4. Does Role Identity Shape What We Notice? Formal role boundaries and professional role identity are related but not equivalent. One structures organizational expectations, responsibilities and authority. The other concerns how actors understand their professional position, responsibilities and field of concern. Either may influence attention. They may also reinforce each other. But their effects should not be assumed to be the same. Consider two competent professionals observing the same emerging issue. Both have access to relevant information. Both understand their own responsibilities. Both may interpret the facts correctly within their respective domains. Yet they may not assign the same significance to what they see. One may interpret the issue primarily as a technical concern. Another as an operational constraint. Another as a contractual exposure. Another as a stakeholder problem. Another as a project-level threat requiring integration. The difference may arise from expertise. From access to information. From authority. From incentives. From experience. From organizational position. Or from the boundaries through which each actor understands their own role. This suggests a question worth testing: Does professional role identity influence the scope within which actors interpret consequences as materially relevant? The proposition should not be accepted in advance. Role identity may sometimes narrow attention. But it can also sharpen it. Specialized expertise allows actors to recognize signals that others would miss. A strong professional identity may strengthen a professional's sense of responsibility rather than restrict it. And experienced professionals can reason beyond formal role boundaries. So the issue is not whether roles inevitably produce tunnel vision. They do not. The relevant question is whether some configurations make actors' perceived role boundaries too influential in determining the perceived boundary of consequence. 5. The Boundary of the Role Is Not Necessarily the Boundary of the Consequence Projects divide work because specialization is useful. But consequences do not necessarily follow the same divisions. A technical decision may create operational consequences. A procurement choice may alter implementation options. A financial decision may transfer cost or effort elsewhere. A schedule commitment may narrow the choices available to another function. A product adaptation may alter compliance exposure. A resource decision may affect system-level viability. The actor making the decision may be entirely competent within their role. The problem begins if the organizational or professional boundary through which the decision is interpreted also becomes the perceived boundary of its consequence. That would create a dangerous equivalence: My responsibility ends here, therefore the relevant consequence ends here. But those propositions are not the same. A role boundary may legitimately help define responsibility or decision authority. It does not necessarily define where consequences stop. This distinction is fundamental. The boundary of legitimate authority and the boundary of material consequence need not coincide. Once they separate, the project requires some means of recognizing that separation. That does not necessarily require every actor to see the whole. But it does require the system to avoid treating local role boundaries as if they were natural boundaries of consequence. 6. From Role Boundary to Perceived Scope of Consequence This creates a possible relationship worth examining. Formal role architecture, professional identity and experience may all influence how actors perceive the boundaries of their own field of responsibility or concern. That perceived boundary can influence attention. Attention can influence interpretation. Interpretation can influence the scope within which consequences are perceived as material. One possible pattern is therefore: Perceived role boundary → Attention → Interpretation → Perceived scope of consequence But this should not be treated as a necessary linear sequence. Several qualifications matter. Attention may be directed by governance rather than role identity. Information systems may surface cross-boundary effects. AI may identify a potentially material relationship before any human actor has framed the issue through a professional role. Professional experience may cause an actor to look deliberately beyond formal responsibility. Strong integrative mechanisms may connect partial interpretations before any one actor develops a system-level view. And the same formal role may produce very different perceived boundaries and patterns of attention in different people and organizational environments. So the relationship remains a hypothesis to test, not an architecture to assume. For the present article, its value is narrower. It helps sharpen the question: Can a role remain useful as an organizational unit while becoming too narrow as the primary unit through which professional contribution is understood? 7. The Project Manager Is More Than a List of Tasks A simplistic response would be to decompose the Project Manager role into tasks and distribute them. Planning goes here. Risk management there. Reporting elsewhere. Scheduling to software. Analysis to AI. Facilitation to teams. Governance responsibilities to formal bodies. Integration to multiple actors. Then conclude that little remains. That reasoning is weak. A professional role is not simply the arithmetic sum of its visible tasks. Roles may preserve continuity. Context. Judgment. Relationships. Professional responsibility. Cross-domain interpretation. Project memory. Attention over time. And the capacity to recognize relationships that are difficult to allocate as discrete tasks. The Project Manager can also occupy a structurally valuable position between domains. That position may allow consequences to be connected that remain fragmented elsewhere. So distributing tasks does not prove that the role has lost its contribution. Task decomposability is not evidence of role obsolescence. Nor does automation prove professional redundancy. AI may perform analysis. Generate scenarios. Detect patterns. Prepare reports. Surface dependencies. Support decisions. Or execute bounded actions. But the existence of technological capability does not itself determine where professional judgment, legitimate authority, accountability, contextual interpretation or integrative responsibility should reside. The role question therefore cannot be answered by a task inventory. 8. Perhaps the Unit of Analysis Is the Problem Professional debates often begin with the role. What should the Project Manager do? Which capabilities should the Project Manager develop? How should the Project Manager use AI? Should the role become more strategic, adaptive or business-oriented? These may all be legitimate questions. But they already assume that the Project Manager is the primary unit through which the future system should be interpreted. A different sequence is possible. What must the project system accomplish? Which contributions are necessary? Which capabilities make those contributions possible? Where must they reside? Which need continuity? Which can be distributed? Which require legitimate authority? Which depend on proximity to specialized knowledge? Which require cross-boundary visibility? Which can be supported or performed computationally? Which need identifiable accountability? And only then: What role architecture best supports those requirements? As an analytical sequence, instead of: Role → expected capabilities → system contribution we can begin with: System requirement → necessary contribution → required capability → appropriate configuration The role becomes a possible design consequence rather than the unquestioned analytical starting point. That does not make the role optional by definition. It makes its justification contextual and functional. 9. But the System Cannot Become an Excuse for Role Ambiguity Moving the unit of analysis toward system contribution creates its own danger. If we say: The system integrates, The system governs, The system learns, The system decides, The system adapts, We may conceal the actual actors and mechanisms through which those functions occur. System-level language does not itself identify the actors and mechanisms through which responsibility is exercised. People act. Governance bodies decide. Teams interpret. Algorithms process. AI systems recommend or execute within configured boundaries. Actors escalate or fail to escalate. Organizations allocate resources. So moving from role identity toward system contribution must not dissolve responsibility into vague systemic language. A system-level function still requires an explicit configuration of contribution. Who contributes what? With what capability? With what authority? Under what conditions? Through which mechanisms? With what accountability? And how do those contributions connect? A broader unit of analysis should make contribution more precise, not responsibility more diffuse. This is an important safeguard. 10. Contribution Is Not a Substitute for Professional Identity There is another possible overcorrection. If roles can be decomposed into contributions, perhaps professional identity should simply disappear into capability portfolios. People would no longer be Project Managers. They would merely possess combinations of facilitation, integration, decision, governance, stakeholder, analytical and adaptive capabilities. That conclusion does not automatically follow. Professional identity serves purposes that system architecture alone does not replace. It organizes learning. Supports communities of practice. Creates recognizable standards. Enables career mobility. Preserves traditions of judgment. Provides language for competence and experience. And can create a sense of responsibility that exceeds any one temporary assignment. The fact that system contribution is a broader analytical unit does not prove that professional roles are obsolete as social, developmental or organizational structures. This distinction must be preserved: The appropriate unit for analyzing system contribution need not be the same unit through which professional identity is organized. That may ultimately be one of the most important conclusions of the deconstruction. 11. When Is the Project Manager Role Particularly Valuable? If the Project Manager role is not presumed necessary in every configuration, what conditions strengthen the case for it? One possibility is continuity. Projects with long temporal horizons may benefit from an actor who preserves context across changing teams, decisions and phases. Another is interdependence. Where consequences cross many organizational boundaries, a role with explicit integrative responsibility may reduce ambiguity. Another is fragmentation of authority. Where no single domain can resolve significant trade-offs, an actor positioned to connect those domains may support escalation and coherence. Another is information fragmentation. Where relevant information remains distributed across actors and domains, a role responsible for connecting partial views may provide value. Another is governance complexity. Where contractual, regulatory, stakeholder and organizational arrangements interact, continuity of integrative judgment may matter. And another is limited distributed integrative capacity. A system that has not developed reliable distributed integrative mechanisms may depend more heavily on an identifiable role to compensate for architectural gaps. But these are not universal proofs. A highly capable distributed system may perform some of the same functions through explicit decision rights, strong interfaces, transparent information, mature governance and effective integration mechanisms. The relevant test remains functional and counterfactual. What contribution would be materially weakened if the Project Manager role were absent from this particular configuration, and could that contribution be provided as reliably through another configuration? If the contribution is distinctive, consequential and difficult to reproduce through plausible alternatives, the role has a strong architectural justification. If the same contribution is already performed reliably elsewhere, or can be provided through another configuration without creating greater risk, fragmentation or ambiguity, the case deserves closer examination. 12. From Competency Models to System Contribution Traditional competency models usually ask: What should a Project Manager know? What should a Project Manager be able to do? Those questions remain useful. But system contribution introduces another layer. What capabilities must exist somewhere in the project system? Which must coexist in the same actor? Which may be distributed? Which require continuity, legitimate authority or independence? Which can be augmented computationally? And which require identifiable responsibility to ensure that they actually exist and are exercised? This does not eliminate competency models. It changes their relationship to organization design. A capability may be essential even when no single role owns it completely. A role may remain essential because some capabilities may need to remain combined in the same actor or role. Different actors may provide the same capability at different stages of the project. And a professional role may increasingly be defined not by exclusive ownership of functions, but by the particular contribution it is expected to make within a wider system configuration. This suggests a different professional question: Not only “What must a Project Manager be capable of?” but “What capabilities must the project system possess, and what distinctive contribution should the Project Manager make within that wider configuration of capabilities?” The difference is subtle. But consequential. 13. Professional Identity Without Professional Territoriality Strong professional identity can create expertise, responsibility and community. But it can also create territoriality. This is not unique to project management. Any profession can begin to treat particular activities as belonging to it because they have historically been associated with its role. When familiar allocations are treated too rigidly, they can begin to sound like this: Integration belongs to the Project Manager. Strategy belongs to senior leadership. Requirements belong to business analysis. Technical decisions belong to engineering. Change belongs to change management. Risk belongs to risk specialists. Such distinctions can sometimes be useful. But they can also transform historical allocation into assumed necessity. The deconstructive question is not: Who owns this professionally? It is: What does the system require, who is best positioned to contribute, and what allocation preserves legitimate responsibility and coherence? This does not abolish professional boundaries. It prevents those boundaries from becoming substitutes for architectural reasoning. Professional identity is most useful when it strengthens contribution. It becomes more problematic when preserving inherited role boundaries takes precedence over configuring the capabilities the system requires. 14. The Attention Question, Bounded The earlier attention question can now be bounded more precisely. Professional role identity and perceived role boundaries may influence the scope within which actors attend to and interpret consequences. But they are only possible explanations. Expertise may differ. Experience may differ. Incentives may differ. Information context may differ. Organizational expectations may differ. Power and authority may differ. Actors may also use different thresholds for what they consider material. So the current hypothesis should remain carefully bounded: Professional role identity and perceived role boundaries may influence the scope within which actors attend to and interpret consequences, but the strength, direction and independence of those influences require further testing. We do not need to convert this into a new construct. Nor should we assume that broadening professional identity automatically broadens attention. A professional can hold a broad title and still reason locally. Another can occupy a specialized role and reason systemically. The challenge is architectural as much as psychological. The system must make it possible for locally situated expertise to contribute to wider coherence without requiring every actor to become a universal generalist. 15. Is the Project Manager Still the Right Unit of Professional Identity? We can now return to the central question. Should professional identity continue to be organized primarily around the Project Manager role, or around the contributions and capabilities required by the project system? The analysis does not justify replacing one with the other. It justifies separating the questions. The Project Manager role remains valuable. In some configurations, it may be essential. It can concentrate continuity, integrative responsibility, contextual understanding, facilitation, coordination, governance support and cross-boundary attention in ways that are difficult to reproduce through fragmented contributions. But the existence and historical importance of the role do not prove that every required project capability must continue to be understood through it. Nor does the ability to distribute those capabilities prove that the role should disappear. For analyzing required contribution, the broader project system provides the more defensible starting point. The role should then be evaluated by the distinctive contribution it provides within that configuration. This changes how professional identity is situated within the broader project architecture without abolishing it. The Project Manager can then be understood as one important component within the wider configuration of project contribution rather than the unquestioned unit through which every system requirement must first be interpreted. The relevant test becomes: Under what conditions does organizing professional identity around the Project Manager role strengthen the contributions and capabilities the project system requires, and under what conditions does it constrain how they are recognized or configured? That question cannot be answered by preference alone. Nor by declaring the role obsolete. Nor by preserving it simply because it is familiar. It must be answered against the actual conditions of the project system. The Deconstruction The familiar assumption was: If project work requires a Project Manager, the Project Manager should therefore be the primary unit through which professional contribution is understood. The first proposition may be true in many configurations. It does not automatically prove the second. Roles matter. Professional identity matters. Specialization matters. Continuity matters. Accountability matters. But functions, contributions and consequences do not always remain inside the professional boundaries through which organizations have historically arranged them. So the deconstruction does not lead to: Role → obsolescence It leads to a more disciplined distinction: Professional role ≠ system contribution The two can reinforce each other. But they should not be treated as equivalent. The more rigorous design question is: What contributions and capabilities must the project system possess, how should they be configured, and what distinctive role should the Project Manager play within that configuration? That preserves the profession without making the profession the unit through which every system requirement must first be interpreted. And one proposition survives the deconstruction: The project system may be the broader unit for analyzing required contribution without making the Project Manager an obsolete unit of professional identity. The future of the role should therefore not be decided by asking whether its traditional tasks can be redistributed. It should be decided by asking whether the role continues to provide a distinctive, legitimate and materially valuable contribution relative to plausible alternative configurations. That leaves the final assumption of Phase 2. Project systems have historically been designed around human analysis, judgment, authority, action and accountability. But those relationships are beginning to change. If AI can increasingly analyze information, recognize patterns, recommend decisions and perform bounded actions, which parts of the project decision system still require human exclusivity? That is where THE AWAKENING goes next. Article 10 What Happens When AI Becomes Part of the Project Decision System? Questioning Human Exclusivity in Analysis, Agency and Accountability |
Posted on: September 18, 2026 01:51 PM
| Permalink |
Comments (0)
When Sponsorship Meets Ownership: Does PMI's Responsible Sponsorship Guide Close the Governance Gap?
 Project Professionals are increasingly expected to think beyond delivery. They are expected to understand strategic intent, question assumptions, reassess viability, influence stakeholders, anticipate consequences and remain focused on whether the project is actually creating value. PMI's M.O.R.E. framework captures this expectation through four practices: Manage Perceptions, Own Success, Relentlessly Reassess and Expand Perspective. Projects do not create value simply because deliverables are completed, schedules are maintained or budgets are controlled. Project outcomes emerge from a wider organizational system. But broader expectations of professional ownership create a governance question: If Project Professionals are expected to own more of project success, what authority must accompany that expectation? I explored that question in two previous articles. The first, M.O.R.E. Expands What Project Professionals Are Expected to Own. But Does Their Authority Expand with Their Accountability?, distinguished professional agency from formal authority and questioned how far responsibility for outcomes could expand while consequential decision rights remained elsewhere. The second, When Ownership Meets Governance: Designing Governable Professional Agency for Project Success, developed that argument further. It proposed that broader professional agency requires an organizational architecture connecting access to information, challenge, escalation, recommendation, decision, record and accountability. Since those articles were published, PMI's governance guidance has evolved. PMI has now published the GPM Guide to Responsible Project Sponsorship. The Guide does more than describe what effective Sponsors should do. It makes considerably more explicit the governance architecture surrounding project success. That creates a new question: Does PMI's Responsible Sponsorship Guide close the governance gap created by broader expectations of project-success ownership? Responsible Sponsorship Changes the Question One of the most important contributions of the new Guide is that it does not treat sponsorship merely as executive support. The Guide presents Responsible Sponsorship as a governance discipline. The Sponsor connects strategy to mandate, remains accountable for continued justification, establishes and maintains governance arrangements, defines decision tolerances and escalation thresholds, governs consequential trade-offs and intervenes when decisions exceed project authority. This matters because it shifts part of the discussion from individual professional behavior to organizational architecture. A capable Project Manager may recognize that a business case is deteriorating, identify a strategic inconsistency or conclude that a major trade-off threatens expected value. But recognizing a problem does not necessarily create authority to resolve it. The new Guide makes that distinction considerably clearer. Project Managers operate within an assigned mandate and agreed tolerances. Decisions beyond those boundaries move to the Sponsor and, where necessary, to the appropriate governing body. This provides something the language of professional ownership cannot provide on its own: An identifiable path to legitimate decision authority. That is a substantial development. The Emerging Division of Governance Responsibility The relationship between Project Professional and Sponsor becomes clearer when viewed through the decisions each is positioned to influence or make. The Project Professional remains close to the evolving reality of the initiative. They may reassess assumptions, identify dependencies, surface emerging risks, challenge interpretations, prepare decisions, recommend action, escalate matters beyond their authority and decide within the discretion legitimately assigned to them. The Sponsor occupies a different governance position. The Sponsor maintains clarity of the mandate and continued justification, establishes or preserves decision boundaries, governs consequential trade-offs and acts when decisions exceed project authority. Where the Sponsor's own authority is insufficient, the issue moves to the relevant governing body. This is not a hierarchy of professional importance. It is a distribution of governance functions. And that distribution matters because project outcomes are not produced by a single actor. Strategic choices may belong to executives. Investment decisions may belong to governance bodies. Resources may be controlled by functional organizations. Benefits may depend on business owners or operations. Adoption may depend on users and customers. Commercial outcomes may depend on suppliers and partners. Some project decisions may belong to the Project Manager within agreed boundaries. Others may belong to the Sponsor. Still others require portfolio, executive or governing-body authority. Project success is systemically produced while authority remains distributed. The clearer that distribution becomes, the more important it is to ask what ownership can legitimately mean. Responsible Sponsorship Strengthens the Architecture of Escalation This becomes particularly visible when project conditions change. Consider a Project Professional who concludes that assumptions supporting continued investment are no longer defensible. The professional may have a responsibility to identify the evidence, investigate its significance, challenge the assumptions, communicate the consequences and recommend action. But authority to continue, redirect, pause or terminate the investment may belong elsewhere. This distinction was central to my earlier argument about Governable Professional Agency. An escalation mechanism is meaningful only if authority exists at the other end. The new Responsible Sponsorship guidance strengthens that architecture by making escalation thresholds and authority transitions more explicit. When defined tolerances are exceeded, the matter moves beyond the Project Manager's authority to the Sponsor. Where the decision exceeds the Sponsor's authority, it moves again to the appropriate governing body. That is more than procedural escalation. It connects professional judgment with legitimate organizational authority. The Guide also gives continued justification a clear governance home. Authorization is not treated simply as a decision made at the beginning of a project. The underlying justification must remain defensible as circumstances evolve. This is particularly important for the meaning of Relentlessly Reassess. A Project Professional may reassess, conclude that the evidence has changed and recommend a different course of action. But reassessing justification and possessing legitimate authority to act on that reassessment are different organizational functions. Responsible Sponsorship helps make that boundary visible. STEWARD Makes the M.O.R.E. Relationship More Explicit The Guide goes further than simply clarifying Sponsor authority. Through its STEWARD model, it explicitly connects Responsible Sponsorship with M.O.R.E. That connection is important to the governance question. The Guide does not transfer responsibility for practicing M.O.R.E. from the Project or Program Manager to the Sponsor. Instead, it positions STEWARD as the Sponsor-side governance architecture that creates and protects the conditions within which Project and Program Managers can exercise M.O.R.E. The Guide also cites PMI research indicating that 69% of respondents, including 72% of Sponsors, place primary responsibility for practicing M.O.R.E. with the Project or Program Manager. This makes the emerging division of responsibility more explicit. Project Professionals are expected to exercise broader professional agency toward project success. Sponsors are expected to provide and exercise the governance needed to keep that agency connected to mandate, authority, escalation and continued justification. That is a significant answer to the governance problem raised in the earlier articles. It also provides a stronger test of what remains unresolved. If STEWARD supplies governance conditions for M.O.R.E. while M.O.R.E. remains primarily a Project or Program Manager responsibility, then the central question is no longer whether PMI recognizes the need to connect professional agency with governance. It clearly does. The sharper question is whether that connection also resolves what "Own Success" can coherently mean when consequential decision authority and causal influence remain distributed. So What Does "Own Success" Now Mean? This is where the new Guide creates its most interesting consequence. The clearer PMI becomes about who governs project success, the harder it becomes to treat "Own Success" as undifferentiated outcome accountability. If Sponsors remain accountable for continued justification, establish decision tolerances, govern consequential trade-offs, make decisions that exceed project authority and escalate matters that exceed their own authority, while other actors control resources, benefits, operations, strategic choices and organizational capabilities, then no Project Professional can coherently be assigned undifferentiated accountability for project success as a whole, irrespective of that distribution of authority and causal influence. This does not make "Own Success" wrong. It makes its meaning more important. There is a strong, governance-coherent interpretation of ownership. A Project Professional should not retreat behind the boundaries of task execution. Meaningful ownership requires seeking relevant evidence, understanding strategic intent, questioning assumptions, recognizing consequences beyond immediate delivery, challenging when evidence warrants it, recommending what professional judgment supports, escalating when authority lies elsewhere and acting decisively within legitimately assigned authority. That is meaningful ownership. But professional agency, decision authority and outcome accountability are not interchangeable. A professional may exercise extensive agency toward an outcome without possessing every decision right required to produce it. Likewise, limited authority does not remove responsibility for what the professional could reasonably have been expected to know, challenge, recommend, escalate or do. The appropriate objective is therefore not less ownership. It is differentiated ownership. Professional agency can be broad. Decision authority can remain distributed. Outcome accountability can exist, but it should remain proportionate to the actor's legitimate authority, decision rights, competence, causal influence, relevant knowledge and reasonable opportunity to act. Responsible Sponsorship provides a clearer governance architecture within which this interpretation of "Own Success" can be sustained. Has the Governance Gap Therefore Been Closed? Partly. The Guide makes Sponsor responsibilities for mandate clarity, decision boundaries, escalation, continued justification and consequential trade-offs considerably more explicit. Through STEWARD, it also explicitly connects those governance responsibilities with the conditions required for Project and Program Managers to practice M.O.R.E. Together, these address much of the authority architecture that broader professional ownership requires. But some questions remain. What Happens When Professional Judgment and Formal Authority Diverge? Suppose a Project Professional concludes, on defensible evidence, that a project should stop, challenges the underlying assumptions, escalates the issue and recommends termination. The legitimate authority decides to continue. The risk subsequently materializes. What happens to accountability? The professional remains responsible for the quality and timeliness of the analysis, the communication of uncertainty, the escalation and the actions taken within their authority. But the continuation decision was made by another actor. A governance architecture therefore needs to preserve the distinction between responsibility for professional judgment and accountability for a decision that another actor possessed the legitimate authority to make. Responsible Sponsorship makes the allocation of that authority clearer. But clarity about who decides does not, by itself, completely resolve how accountability should subsequently be attributed when professional advice and formal decision authority diverge. Decision Records Are Necessary, but Dissent Creates a Harder Case The new Guide also strengthens the importance of preserving decisions, assumptions and their rationale. That supports accountability. But a decision record and a record of dissent are not necessarily the same thing. When material disagreement exists, a mature governance system may need to reconstruct more than the final decision. What was known at the time? Which assumptions were challenged? What evidence supported the challenge? What recommendation was made? Who possessed the relevant authority? What decision was ultimately taken, and why? This is not an argument for defensive bureaucracy. It is an argument for accountability integrity. Without contemporaneous evidence, a systemically produced failure can later be compressed into a much simpler narrative around the actor most visibly associated with delivery. The Responsible Sponsorship Guide strengthens decision traceability. I do not find the Guide explicitly establishing how material professional dissent should be preserved when legitimate decision authority chooses a different course. Absence is not rejection. The Guide does not need to contain every possible governance mechanism. But the question remains relevant because broader expectations of professional ownership increase the importance of distinguishing who knew, who advised, who decided and who could legitimately act. Escalation Also Requires Governance Action Responsible Sponsorship clearly expects Sponsors to act when governance thresholds are reached. That is an important advance. But a narrower question remains. What happens when a material issue has been legitimately escalated and cannot be resolved within the Sponsor's own authority? A concern may be acknowledged and formally discussed while work, investment and exposure continue. Procedurally, escalation has occurred. Substantively, the consequential decision may still not have been made. Effective escalation therefore depends not only on identifying where authority resides, but also on whether the governance system can process a material issue within a decision window appropriate to its consequences. This leaves a further question: What obligation accompanies the receipt of a material escalation when a consequential decision is required? A governance architecture may therefore need more than an escalation pathway. It may also need an identifiable decision authority, an appropriate decision window and traceable accountability for whether the issue was considered and acted upon. Otherwise, procedural voice may exist without substantive governance effect. The Hardest Test May Come After the Professional Speaks There is another dimension that formal authority structures cannot resolve alone. Organizations often encourage professionals to challenge assumptions, speak up and act like owners. But those expectations become meaningful only when the organization can absorb inconvenient professional judgment. A Project Professional who genuinely Relentlessly Reassesses may discover that an important assumption no longer holds. Someone who genuinely Expands Perspective may identify consequences that powerful stakeholders would prefer not to confront. Someone who genuinely Owns Success may recommend stopping an initiative that senior leaders remain committed to continuing. At that point, the quality of governance is tested not by whether the organization encouraged the professional to speak, but by what it does after the professional speaks. Can evidence-based challenge be considered without being treated as disloyalty? Can an inconvenient recommendation reach the authority capable of acting on it? Can disagreement be preserved without distorting accountability? Can a legitimate authority reject professional advice while remaining accountable for the decision it was empowered to make? These questions extend beyond sponsorship competence. They concern the organization's capacity to make broader professional agency genuinely governable. Responsible Sponsorship and Governable Professional Agency Are Complementary Responsible Sponsorship and Governable Professional Agency should not be framed as competing architectures. They approach an overlapping governance problem from different positions. Responsible Sponsorship asks what Sponsors and governance systems must do to keep projects strategically justified, properly authorized and governable. Governable Professional Agency asks what organizational conditions are required when professionals are expected to exercise judgment, challenge assumptions, recommend action and protect value while consequential authority remains distributed. The overlap is substantial. Both depend on clear authority, meaningful escalation and decision traceability, and both reject the idea that professional capability can compensate for weak governance. STEWARD makes that complementarity more explicit by positioning Sponsor governance as an enabling condition for M.O.R.E., rather than as a substitute for the professional agency M.O.R.E. expects. The new Guide therefore closes part of the gap identified in my earlier articles. But it also helps reveal the remaining boundary more precisely. The issue is no longer simply whether Project Professionals have enough authority. The deeper issue is whether the relationship among professional agency, distributed decision authority and outcome accountability remains coherent as expectations of responsibility for project success expand. From "Own Success" to Governable Ownership Perhaps the most useful consequence of Responsible Sponsorship is not that it tells Project Professionals to own less. It is that it gives us a stronger basis for understanding what ownership should mean. "Own Success" can be read not as unlimited accountability for the total outcome, but as an obligation to exercise the fullest legitimate professional agency toward success while remaining accountable for one's decisions and actions within legitimate authority, and for outcomes to the extent justified by one's decision rights, meaningful causal influence and reasonable opportunity to act. At the same time, the organization must own its part. Sponsors must exercise the authority assigned to them. Governing bodies must make the decisions that belong to them. Business and operational owners must remain accountable for the conditions they control. And accountability must remain traceable to the actual distribution of knowledge, authority, decisions, actions, omissions and meaningful opportunities to act. That is not diluted ownership. It is governable ownership. Conclusion: The Gap Is Narrower, but the Question Is Sharper PMI's Responsible Sponsorship Guide materially advances the governance conversation. It makes explicit much of the authority architecture that broader expectations of project-success ownership require. Through STEWARD, it also explicitly connects Sponsor governance with the conditions under which Project and Program Managers are expected to practice M.O.R.E. The governance gap within PMI's current articulation of project-success ownership is therefore narrower than when the question was first posed. But closing part of that gap produces an important consequence. The clearer PMI becomes about who governs project success, the harder it becomes to treat "Own Success" as undifferentiated outcome accountability. Project Professionals can and should exercise broad agency toward success. Sponsors can and should exercise the governance authority entrusted to them. Other organizational actors remain responsible for decisions and conditions within their legitimate control. Project success remains systemically produced. The next step is therefore not to choose between professional ownership and organizational governance. It is to make them coherent. Responsible Sponsorship provides much of the governance architecture needed to do so. But the remaining test is whether organizations can preserve the connection between what professionals are expected to understand and challenge, what they are empowered to decide, what others legitimately decide instead, and what each actor can ultimately be held accountable for. That is where sponsorship meets ownership. And that is where "Own Success" becomes governable. |
Posted on: September 17, 2026 12:02 PM
| Permalink |
Comments (3)
When Does Control Preserve Coherence, and When Does It Constrain Adaptability?
 Beyond the Centralization-Autonomy Trade-off Article 6 challenged one familiar assumption. If integration is necessary, someone must necessarily be the integrator. The analysis showed that this does not automatically follow. Integration may be necessary as a system capability under conditions of material interdependence, while the architecture through which that capability is produced can vary. It may be concentrated. Distributed. Or hybrid. Article 7 challenged another familiar assumption. If someone is accountable, we often expect responsibility, authority and sufficient causal capacity to substantially coincide. Again, the relationship proved more conditional. Distributed systems can separate responsibility, authority, knowledge, capability, discretion and causal contribution. Legitimate accountability therefore requires more than identifying who formally owns an outcome. Both deconstructions lead toward another familiar relationship. If distributed action is to remain systemically coherent, some form of control appears necessary. That seems difficult to dispute. Projects operate within constraints. Decision boundaries matter. Commitments must be protected. Risks must be governed. Resources are finite. Safety, regulatory, contractual, ethical and fiduciary obligations may establish limits that cannot legitimately be traded away locally. And some decisions create consequences that extend beyond the authority of those making them. Control therefore matters. But another proposition does not automatically follow: That more control produces more coherence, or that less control produces more adaptability. That is the third deconstruction. 1. Control Is Not the Opposite of Adaptability Control and adaptability are often placed on opposite sides of an intuitive continuum. More control. Less autonomy. Less control. More autonomy. But this reasoning usually contains two assumptions at once. First, that more control necessarily reduces useful autonomy. Second, that more autonomy necessarily improves adaptability. Neither relationship should be taken for granted. Autonomy and adaptability are not equivalent. Autonomy concerns the discretion available to actors within legitimate boundaries. Adaptability concerns the capacity to respond appropriately as conditions change. Greater discretion may support adaptation. It may also produce fragmentation, unmanaged exposure or conflicting local responses. Conversely, some forms of control may constrain discretion while preserving the conditions within which adaptation remains safe and coherent. A safety constraint can protect non-negotiable boundaries while leaving teams free to adapt within them. A financial tolerance can limit exposure without prescribing how value must be delivered. A technical standard can enable distributed work by stabilizing critical interfaces. An escalation threshold can preserve local autonomy precisely because most decisions remain local until a defined condition is crossed. Other forms of control can have the opposite effect. An approval mechanism intended to preserve coherence can delay decisions until useful options disappear. A reporting requirement intended to improve visibility can produce information without improving recognition of what matters. A centralized decision authority can become a bottleneck when relevant knowledge is distributed elsewhere. Control can therefore constrain adaptability. But it can also enable it. The relevant question is not: Control or autonomy? It is: What forms of control preserve the conditions for coherent distributed action without unnecessarily constraining the capacity to adapt? 2. Why Control Exists Before challenging control, we should make the strongest case for it. Projects create interdependence. A local choice can affect cost, schedule, safety, compliance, technical integrity, operational viability, stakeholder commitments or the options available elsewhere in the system. Some consequences can safely remain local. Others cannot. Control can establish legitimate boundaries for discretion. It can protect interests that should not be traded away locally. It can ensure that significant decisions receive appropriate review. It can create traceability. It can prevent actors from externalizing material consequences onto others. It can define tolerances within which local adaptation remains legitimate. And it can ensure that decisions exceeding those tolerances reach an authority capable of addressing them. Control therefore performs more than a restrictive function. It can help make distributed action governable. Control can preserve coherence by shaping how decisions whose consequences cannot safely or legitimately remain local are bounded, surfaced, reviewed or escalated. This is why the issue is not whether projects need control. They do. The harder questions are: What kind? For what purpose? At what level? Through what mechanism? With what degree of discretion? And under which conditions? 3. Not All Control Is the Same The word control hides important architectural differences. A control may prescribe or prohibit an action. Define a boundary. Set a tolerance. Require evidence. Establish a standard. Trigger review. Require consultation. Preserve reversibility. Monitor consequences. Or specify an outcome while leaving the means open. These mechanisms do not have equivalent effects on autonomy. Consider two financial architectures. In the first, every material expenditure requires central approval. In the second, actors may make expenditure decisions independently within explicit financial limits, with wider review required only when defined exposure thresholds are crossed. Both architectures contain control. But they distribute discretion differently. The same applies to technical decisions. A central authority may approve every architectural change. Alternatively, teams may adapt locally within explicit interface constraints, with cross-boundary review required only when a change affects shared dependencies or protected conditions. Again, both architectures contain control. The difference is not control versus no control. It is how control and discretion are configured. This suggests an important distinction: The existence of control does not determine the degree of useful autonomy. Its design does. 4. Control Can Enable Autonomy This becomes clearer when decision boundaries are uncertain. Imagine a team that does not know which decisions it can make independently, which risks it may accept or when escalation becomes necessary. Formal control may appear low. But meaningful autonomy may also be low. Actors can hesitate. Seek unnecessary approval. Escalate defensively. Avoid legitimate decisions. Or exercise discretion inconsistently. Now consider a different configuration. Decision rights are explicit. Non-negotiable constraints are limited and justified. Tolerance levels are understood. Escalation conditions are known. And within those boundaries, actors possess meaningful discretion. Control has not disappeared. But autonomy has become more exercisable. A boundary does not necessarily reduce meaningful discretion. It can define where that discretion is legitimate. Useful autonomy may depend not on the absence of control, but on sufficient clarity about where control ends. The question is therefore no longer how much control should be removed to create autonomy. It becomes: Which controls make distributed discretion safer, clearer and more governable, and which unnecessarily constrain it? 5. When Control Begins to Constrain Adaptability A control can remain legitimate in purpose while becoming problematic in operation. The interest it protects may still matter. The risk may remain real. But the mechanism may impose costs that become increasingly disproportionate to the coherence, protection or governability it provides. Several patterns may indicate this possibility. Decisions repeatedly wait for authorities that add little relevant knowledge or protection. Local adaptations require approval even when their consequences can safely and legitimately remain within local boundaries. Escalations become routine rather than exceptional. Actors develop workarounds because formal mechanisms cannot respond at the speed the work requires. Decision authority remains centralized even though the knowledge necessary to decide has become highly distributed. Controls designed for exceptional exposure become standard requirements for ordinary decisions. Or compliance costs increase while the exposure being controlled remains stable or declines. None of these conditions proves that a control should be removed. Delay may be justified. Redundancy may protect against severe consequences. Central authority may remain necessary where decisions are highly consequential, irreversible or subject to non-delegable obligations. The existence of friction does not establish that a control is excessive. The relevant test is whether the friction remains proportionate to what the control legitimately protects. A control begins to constrain useful adaptability when the restrictions it imposes become insufficiently proportionate to the risks, exposures or legitimate interests at stake, including those arising from material interdependence. But even that test is incomplete. Because a control cannot be evaluated only by observing what happens while it exists. 6. The Counterfactual Matters Suppose an approval takes three days. The delay appears inefficient. Removing the approval might allow the decision to be made in three hours. Is the control therefore excessive? Not necessarily. What does the approval prevent? What information does it introduce? Which interests does it protect? What dependencies does it reveal? What legitimate authority does it bring into the decision? What exposure would change without it? And could another mechanism provide equivalent or better protection at lower systemic cost? A control cannot be evaluated only by the cost of complying with it. Nor can it be justified indefinitely merely by pointing to the risk it was originally created to address. Evaluating both the control and its alternatives requires counterfactual reasoning. What does the control enable, prevent or protect, and what changes if it is retained, weakened, redesigned, replaced or removed? This matters because adaptability is not equivalent to speed. A system that changes quickly while repeatedly creating unmanaged consequences is not necessarily adaptive. Nor is coherence equivalent to stability. A system that preserves every existing constraint while becoming unable to respond to changed conditions is not necessarily coherent. The relevant comparison is therefore between alternative architectures, not simply between control and its absence. 7. The Threshold Problem Distributed authority creates a particularly difficult question. When should a local issue remain local? And when does it become sufficiently consequential to justify wider intervention? If every deviation triggers system-level review, distributed authority becomes largely nominal. Actors may formally possess discretion while meaningful decisions continue to migrate upward. Adaptability weakens. But the opposite configuration is also problematic. If an issue remains local after its consequences have exceeded the conditions within which local discretion remains legitimate, intervention may arrive only after commitments have accumulated, dependencies have propagated or meaningful alternatives have narrowed. Control then arrives too late. This makes the threshold for intervention central to control architecture. A technical variation may remain local until it changes a shared interface. A schedule adjustment may remain local until it threatens a contractual commitment. A resource decision may remain within functional authority until it changes the viability of another critical commitment. A product decision may remain within product authority until its consequences materially alter operational, regulatory or financial conditions. Other issues may justify wider intervention without first becoming cross-boundary. A safety threshold may be crossed. A regulatory condition may no longer be satisfied. A fiduciary limit may be exceeded. A protected right or ethical constraint may become materially implicated. The relevant test is therefore broader than interdependence alone. The system must determine when a consequence, exposure or protected interest has become significant enough to warrant wider attention, and when it has become significant enough to justify wider authority or intervention. If the intervention threshold is set too low, control may unnecessarily constrain autonomy. If it is set too high, intervention may come too late to preserve coherence or protect the interest at stake. There is unlikely to be one universal quantitative rule. Context matters. Reversibility matters. Velocity matters. Risk matters. Interdependence matters. The distribution of knowledge and authority matters. The nature of the protected interest matters. And timing matters. The same consequence recognized early may be manageable through local adaptation. Recognized later, it may require wider intervention. So control architecture must answer not only: What requires intervention? But also: When does intervention become justified, and how will the system know? 8. Visibility Is Not Yet Intervention That question introduces another distinction. A consequence may exist without being visible. It may be visible without receiving sufficient attention. It may receive attention without being recognized as materially significant. Its significance may be recognized locally without being connected to relevant consequences elsewhere. And the resulting issue may be recognized without anyone possessing legitimate capacity to act. These distinctions matter. But they should not yet be converted into a necessary linear architecture. Human attention is not the only mechanism through which significant patterns can be detected. Automated monitoring can surface deviations. Predefined thresholds can trigger escalation. Information systems can connect signals across boundaries. AI may increasingly identify patterns that no individual actor was actively attending to. Governance mechanisms can require review without relying on spontaneous human recognition. So the proposition remains open: Information can be available without being integrated. Visibility can exist without sufficient attention. Attention can exist without recognition of systemic significance. And recognition can exist without legitimate capacity to act. These relationships require further testing. For the present deconstruction, their relevance is narrower. A control architecture cannot preserve coherence merely by making information available. It requires some viable mechanism through which materially significant consequences, exposures or protected interests can receive appropriate consideration and, where justified, legitimate intervention. At the same time, not every visible issue should trigger wider control. Otherwise, an architecture may turn visibility into automatic escalation and thereby erode local discretion. This creates a difficult design question: How can a project remain sensitive to material consequences without converting every local signal into system-level intervention? 9. Beyond Centralization Once control is separated from centralization, the design space becomes wider. Coherence may sometimes require centralized approval. But control can also operate through decision boundaries and standards, tolerances and thresholds, monitoring and feedback, review and escalation, or reversible experimentation. Some mechanisms constrain action before it occurs. Others detect consequences after action. Some prevent. Some guide. Some surface. Some escalate. Some preserve options. Some support accountability without requiring prior approval. The appropriate architecture depends on what must be governed. A highly irreversible decision with broad consequences may justify stronger ex ante control. A reversible local experiment within contained boundaries may justify broad discretion combined with rapid feedback. A decision whose consequences are difficult to detect may require stronger monitoring. A decision whose consequences become rapidly irreversible may require earlier intervention thresholds. This suggests that the centralization-autonomy continuum is too narrow. The more useful design question is: What combination of constraints, discretion, sensing, feedback and escalation is proportionate to the consequences, exposures and legitimate interests the system must govern? 10. Control Architecture Must Also Be Adaptable There is another assumption hidden inside the discussion. We often ask whether actors should adapt within a control architecture. But what about the control architecture itself? A control designed for one configuration of risk, knowledge, technology, interdependence or organizational capability may become less appropriate as those conditions change. That does not make the original control wrong. Nor does change automatically justify its removal. The protected interest may remain entirely legitimate. The relevant question is whether the mechanism remains proportionate to the conditions it now governs. A system capable of adapting its work while treating its controls as permanently fixed may eventually constrain the very adaptability those controls were intended to make governable. The control architecture therefore requires mechanisms for review and reconsideration. Not continuous redesign. Not permanent instability. Not a presumption in favor of less control. But the capacity to examine whether the relationship among purpose, risk, mechanism, discretion and consequence remains defensible as conditions materially change. Control that cannot itself be reconsidered may preserve arrangements designed for yesterday's coherence at the expense of tomorrow's adaptability. 11. Perhaps the Trade-off Is Wrong The familiar framing asks: How much control? How much autonomy? As if one must necessarily be purchased by sacrificing the other. But the analysis suggests that the relevant variables do not sit neatly on one line. Control. Autonomy. Coherence. Adaptability. They interact. But they are not equivalent. More control does not necessarily produce more coherence. Less control does not necessarily produce more adaptability. More autonomy does not necessarily produce better adaptation. And: Coherence does not necessarily require centralization. Poorly designed control can reduce autonomy without producing coherence. Poorly bounded autonomy can increase discretion without producing adaptability. Centralization can sometimes improve protection or consistency while degrading responsiveness and local knowledge. Distribution can improve responsiveness while weakening the capacity to recognize and govern consequences that exceed local boundaries. The real design problem is therefore relational. Which constraints preserve necessary coherence or legitimate protection? Which forms of discretion enable useful adaptation? What makes wider intervention materially justified? And can intervention occur while meaningful alternatives still exist? 12. Control as a System Capability Article 6 moved integration from assumed role ownership toward system capability. A similar distinction becomes useful here. Control should not be reduced to an approval hierarchy or centralized authority. At system level, effective control concerns the capacity to keep consequential action within legitimate boundaries and respond appropriately when those boundaries, assumptions or conditions are materially challenged. That capacity may be produced through multiple mechanisms. Some centralized. Some distributed. Some preventive. Some adaptive. Some human. Some increasingly computational. The architecture should therefore be evaluated functionally. Can it protect legitimate interests and limit unacceptable exposures? Can it preserve coherence where consequences become materially interdependent? Can it preserve legitimate local discretion? Can it detect and respond when relevant boundaries are crossed? And can its own mechanisms be reconsidered when the conditions that justified them materially change? If not, the system may possess controls without possessing effective control. That distinction matters. Controls are organizational mechanisms. Effective control is a system capability. The existence of the first does not prove the second. 13. When Does Control Preserve Coherence? We can now return to the central question. Which forms of control remain necessary for coherence, and under what conditions do they begin to weaken useful autonomy and adaptation? There is no universal threshold. Different project configurations create different patterns of interdependence, reversibility, uncertainty, risk, knowledge distribution, protected interests and consequences. But several conditions emerge from the analysis. Control is more defensible when it protects a legitimate interest or material exposure that cannot safely or legitimately remain within local discretion, and when intervention remains proportionate to the consequence being governed. That intervention should be informed by relevant knowledge and legitimate authority, occur while meaningful alternatives remain, avoid unnecessarily capturing decisions that can safely remain local, and remain open to reconsideration as governing conditions materially change. Conversely, control becomes increasingly difficult to defend when it captures decisions that can safely and legitimately remain within local discretion, centralizes authority without adding necessary knowledge or protection, repeatedly delays adaptation without preserving commensurate value, or continues to operate on assumptions that no longer adequately describe the conditions being governed. This does not produce a formula. It produces a more demanding test: Does this control protect a legitimate interest, limit a material exposure or preserve coherence in a way proportionate to the discretion and adaptive capacity it constrains? The Deconstruction The familiar opposition was: Control ↔ Autonomy More of one appeared to imply less of the other. The relationship does not survive intact. Control can constrain autonomy. It can also make autonomy exercisable. Autonomy can enable adaptation. It can also create consequences that exceed the conditions within which local discretion remains legitimate. Centralization can protect coherence. It can also create delay, information loss and dependency. Distribution can improve responsiveness. It can also weaken effective control when significant consequences or exposures are not recognized and governed in time. So the relevant question is not how to maximize autonomy. Nor how to minimize control. Nor even how to find a universal balance between them. It is: What architecture of constraints, discretion, sensing, thresholds, feedback and legitimate intervention can preserve coherence while allowing adaptation under the actual conditions of the project? That architecture will vary. But one proposition survives the deconstruction: Control is most defensible when it protects a legitimate interest or material exposure with intervention proportionate to the consequences at stake, while preserving discretion where action can safely and legitimately remain local. This is not a case for more control. Nor for less. It is a case for control whose form, location and intensity can be justified by what the project actually needs to protect and govern. And that leaves another assumption to examine. If functions such as integration, accountability and control should be configured around the capabilities, consequences and legitimate interests the project system must govern rather than inferred automatically from inherited organizational arrangements, what follows for the roles through which project management has traditionally organized those functions? Should we continue to begin with the role? Or should we begin with the contributions and capabilities the project system requires? That is where THE AWAKENING goes next. |
Posted on: September 16, 2026 06:53 AM
| Permalink |
Comments (0)
Can Accountability Remain Legitimate When Authority Is Distributed?
 Rethinking Responsibility, Authority and Causal Capacity Accountability appears relatively straightforward when responsibility, authority and action seem to reside in the same place. Someone is responsible. That person has authority. They can act. Consequences follow. Accountability appears to have an obvious destination. But distributed project systems complicate that picture. Article 2 distinguished three dimensions of integrative responsibility: Allocation, Enablement and Exercise. Article 6 then separated the need for integration from the assumption that integration must reside in one designated role. That deconstruction reveals an immediate accountability problem. If responsibility can be distributed across several actors and mechanisms, accountability can no longer safely be inferred from role alone. Responsibility may sit with one actor while relevant authority resides elsewhere. Knowledge may be distributed across specialists, teams, suppliers, operational functions and governance bodies. Capability may depend on resources or expertise controlled by others. Discretion may be constrained by governance, contracts, organizational boundaries or prior commitments. And outcomes may emerge from interactions among decisions made legitimately by several actors rather than from the action of any single one. In such systems, identifying who was formally responsible may be relatively easy. Determining what they can legitimately be held accountable for is much harder. This raises the central question: Under what conditions can accountability remain legitimate when authority, knowledge, capability and discretion reside in different places? When responsibility and authority no longer coincide Accountability is often treated as if responsibility and sufficient authority should closely correspond. If someone is responsible for an outcome, we tend to expect that person to possess sufficient authority to influence it. If the expected outcome is not achieved, accountability for that outcome is often inferred. But distributed systems weaken that correspondence. A project leader may be responsible for project success while major resource, commercial or strategic decisions remain outside their authority. A Product Owner may control prioritization while operational, contractual or architectural consequences extend beyond the product boundary. A technical team may recognize a material dependency without having authority to resolve the trade-off it creates. A sponsor may possess substantial formal authority while depending on knowledge distributed across the system to understand when intervention is required. Responsibility, authority, knowledge, capability and discretion may therefore reside in different places. Once they do, formal responsibility alone becomes an insufficient basis for legitimate accountability. Responsibility is not authority The first distinction is fundamental: Responsibility ≠ Authority Responsibility concerns what an actor is legitimately expected to attend to, protect, decide, enable or accomplish. Authority concerns the legitimate right to make, influence or constrain particular decisions. The two may coincide. But they need not. Assigning responsibility does not create the authority required to exercise it. And possessing authority does not necessarily provide the knowledge, capability, visibility or discretion required to act effectively. This matters because accountability can become structurally distorted in both directions. An actor may be held accountable for consequences they lacked sufficient authority to influence. Or an actor with substantial authority may escape scrutiny because formal responsibility was assigned elsewhere. Neither outcome is satisfactory. Authority is not causal capacity A second distinction is equally important: Authority ≠ Causal Capacity Formal authority tells us something about what an actor is legitimately entitled to decide. It does not tell us everything about what that actor can actually cause, prevent or materially influence. Causal capacity may depend on several conditions. Relevant information may arrive too late. Resources may be controlled elsewhere. Technical possibilities may already have narrowed. Contractual commitments may constrain available choices. Intervention may require cooperation from other actors. Earlier decisions may have made some alternatives prohibitively expensive or practically irreversible. At the same time, actors without final decision authority may possess considerable causal capacity. They may determine which information becomes visible. Frame alternatives. Set technical parameters. Control resources. Configure systems. Shape recommendations. Establish operational constraints. Or make local decisions whose consequences propagate across organizational boundaries. Formal authority can therefore both overstate and understate actual causal contribution. If accountability is to remain legitimate, it cannot be inferred from authority alone. From integrative responsibility to legitimate accountability Article 2 distinguished Allocation, Enablement and Exercise as dimensions of integrative responsibility. Accountability introduces a further analytical question: Attribution. The resulting architecture contains four distinct dimensions. Allocation Who was legitimately responsible for what? Enablement Did the actor possess sufficient authority, knowledge, visibility, capability, discretion and opportunity to exercise that responsibility? Exercise Given those conditions, what did the actor actually do, or fail to do? Attribution Given the actor's causal capacity and actual action or inaction, what causal contribution can reasonably be attributed, and what accountability can legitimately follow from it? These dimensions should not be treated as a necessary linear sequence. They are analytical distinctions. But separating them matters. Responsibility may be appropriately allocated and inadequately enabled. It may be adequately enabled and not exercised. It may be exercised appropriately while the desired outcome still fails to materialize. And an undesirable outcome may occur without establishing that the responsible actor failed. Accountability therefore requires more than identifying who occupied the formally responsible role when the outcome occurred. Enablement is not optional Formal responsibility can support legitimate accountability only if the actor has sufficient conditions to exercise it. Authority matters. Relevant knowledge matters. Visibility matters. Capability matters. Discretion matters. Opportunity matters. An organization may formally allocate responsibility while retaining elsewhere the authority or capabilities necessary to discharge it. That is not sufficient for legitimate distributed accountability. It is a structural mismatch between responsibility and the conditions required to exercise it. But sufficient enablement creates another problem. What happens when the actor could act, yet responsibility was still not exercised? Capacity to act does not guarantee exercise Suppose an actor possesses substantial authority. The relevant information is available. The consequences are visible. The actor has sufficient knowledge and capability. There is still meaningful opportunity to intervene. Structurally, responsibility appears to be enabled. Yet intervention would require challenging a decision the actor previously supported. Or questioning a senior stakeholder. Or exposing a problem within their own function. Or delaying a strategically important commitment. Or confronting a powerful supplier. Or acknowledging that an earlier judgment was wrong. Or placing professional status, relationships or credibility at risk. The actor possesses capacity to act. But exercising that capacity carries a cost. This introduces an important distinction: Responsibility to act is not the same as Capacity to act is not the same as Cost of acting is not the same as Actual exercise and none of these, on its own, determines The legitimacy of holding someone accountable for not acting. These are different analytical objects. Exercise is not only structural Exercise cannot be reduced to the existence of a mechanism through which action is formally possible. Responsibility is exercised by people operating within organizational and relational systems. Formal authority may exist while incentives discourage its use. Escalation channels may exist while escalation is interpreted as failure. Information may be available while challenging its implications threatens established interests. Decision rights may be explicit while power asymmetries make their exercise difficult. An organization may formally encourage challenge while informally rewarding conformity. This does not mean that responsibility disappears. It means that: Exercise is not only structural. It is also behavioral and normative. But this qualification creates an obvious danger. If incentives, relationships, status, fear or political consequences affect the exercise of responsibility, almost any failure to act could potentially be explained by context. That would make accountability meaningless. The existence of a cost does not itself remove responsibility. Leadership can require challenging powerful interests. Governance can require questioning decisions that appear increasingly unsafe or incoherent. Ethical responsibility may require action precisely when silence is easier. The relevant question is therefore not: Was acting costly? It is: What was the nature and significance of that cost, how did organizational conditions shape it, what meaningful alternatives remained available, and what could reasonably be expected from the actor given the responsibility legitimately assigned to them? This prevents two opposite errors. Organizational conditions should not become an automatic excuse for individual inaction. But formal authority should not be treated as proof that responsibility was practically exercisable under all conditions. Non-action is not a simple binary Non-action should not be reduced to a binary distinction between: Unable and Unwilling. Between the two lies a more complex territory. Authority may be formally available but practically constrained. Knowledge may exist but remain fragmented. Materiality may be uncertain. Responsibilities may conflict. Escalation may threaten legitimate relationships or commitments. The consequences of acting and not acting may both be significant. And causal capacity may be partial rather than complete. Accountability must therefore examine the conditions of action rather than infer unwillingness from non-action. Individual and organizational responsibility This is why accountability must be considered at both individual and organizational levels. Organizations do not merely assign responsibility. They allocate authority, distribute knowledge, design decision rights and escalation mechanisms, establish incentives, and shape whether challenge is enabled or discouraged. Individual accountability should not automatically absorb failures materially shaped by organizational architecture. But the reverse is equally important. Organizational conditions cannot automatically absorb individual responsibility. An actor may possess sufficient authority, knowledge, capability, discretion and meaningful opportunity to act, face difficulties that are real but do not eliminate meaningful capacity to act, and nevertheless fail to exercise that responsibility. The analytical challenge is to distinguish these situations rather than collapse one into the other. Accountability requires causal discipline Distributed systems introduce another difficulty. Outcomes may have multiple contributors. A locally legitimate decision may create consequences elsewhere. Another actor may fail to surface those consequences. A governance body may see the issue but postpone intervention. A resource constraint may narrow the available response. A later decision may amplify the original effect. The final outcome may therefore be causally distributed. This does not mean that nobody can be held accountable. It means that accountability should not manufacture singular causality where singular causality did not exist. Different actors may legitimately be accountable for different contributions. One for a decision they had authority to make. Another for information they were responsible for surfacing. Another for a dependency they could reasonably have recognized. Another for an escalation they had sufficient grounds and opportunity to initiate. Another for a trade-off they legitimately accepted. And another for failing to exercise responsibility despite possessing sufficient conditions to do so. Distributed causal capacity may therefore require more precise accountability, not diluted accountability. From accountability to legitimate attribution The resulting shift is this. Accountability should not begin with: Who owns the outcome? It should begin with a more disciplined inquiry. What responsibility was legitimately allocated? Was that responsibility sufficiently enabled? How was it actually exercised? What causal contribution can reasonably be associated with the actor's action or inaction? And only then: What accountability can legitimately be attributed? This makes accountability more demanding. It also makes it more defensible. The architecture can therefore be summarized as: ALLOCATION What responsibility legitimately belonged to the actor? ↓ ENABLEMENT Did sufficient authority, knowledge, visibility, capability, discretion and opportunity exist? ↓ EXERCISE How was that responsibility actually exercised under the conditions affecting action? ↓ ATTRIBUTION Given the actor's causal capacity and actual action or inaction, what causal contribution can reasonably be attributed, and what accountability can legitimately follow from it? These relationships are analytical, not a necessary linear or causal sequence. And one dimension cannot simply be inferred from another. Formal responsibility does not prove enablement. Enablement does not prove exercise. Non-exercise does not prove unwillingness. Action does not prove causal responsibility for the outcome. And an adverse outcome does not retrospectively establish that an earlier decision or action was illegitimate. The accountability paradox of distributed systems Distributed systems create an apparent paradox. As authority, knowledge, capability and discretion become more distributed, attributing complex outcomes to a single actor merely because that actor occupies a formally accountable role becomes harder to defend. Yet the same distribution can make it easier for responsibility to disappear between actors. One response would be to reconcentrate authority and accountability. But that may sacrifice the distributed knowledge, responsiveness and local judgment that complex projects can require. The alternative cannot be accountability without authority. Nor can it be distributed responsibility without attribution. The challenge is to design accountability that follows the actual architecture of responsibility and causal capacity. That means preserving a demanding principle: Distributed authority should not produce either concentrated blame or distributed impunity. The Deconstruction Article 6 separated a necessary function from any assumed single role architecture. Article 7 now separates accountability from another familiar assumption: That formal responsibility, authority and accountability necessarily belong together. Sometimes they do. But distributed systems can separate them. And once responsibility, authority, knowledge, capability, discretion and causal contribution cease to coincide, legitimate accountability requires more than identifying who was formally responsible. It requires examining whether responsibility was appropriately allocated, sufficiently enabled and actually exercised, and what causal contribution can legitimately be attributed to action or inaction. Even sufficient formal authority and capacity may not settle the question. The practical exercise of responsibility can be affected by organizational, relational and personal conditions, including the consequences of acting. Those conditions matter. But they do not automatically excuse inaction. The difficult work lies in determining what could legitimately be expected of the actor under the conditions that actually existed. So perhaps the question is not simply: Who was accountable? It is: Under what conditions is holding someone accountable legitimate when responsibility, authority and causal capacity do not reside in the same place? That distinction may determine whether distributed accountability becomes more precise. Or merely more diffuse. |
Posted on: September 14, 2026 06:08 AM
| Permalink |
Comments (0)
When Transformation Is Not the Answer
 Why Adaptability Begins Before Change 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 new methodologies, introducing new technologies, or making teams more agile. They increasingly depend on the ability of organizations to adapt their structures, decision mechanisms, operating models, governance, and allocation of resources as the conditions around them change. But this raises an even more fundamental question. What if transformation itself is not the right response? A thoughtful comment from Aaron Porter on my previous article brought this question into sharp focus. He asked two deceptively simple questions: Is the organization solving the right problem? Is transformation the appropriate response? Those questions matter because much of the conversation about organizational transformation begins after a critical assumption has already been made: That transformation is necessary. From there, attention naturally turns to readiness, leadership, culture, capabilities, governance, technology, execution, and resistance to change. But an organization can be highly prepared to transform and still be preparing to execute the wrong intervention. That distinction changes where the conversation should begin. Before Readiness Comes Diagnosis When an organization underperforms, encounters disruption, or recognizes that existing ways of working are no longer producing the expected results, there is a natural pressure to act. Sometimes that pressure is justified. But recognizing that something is wrong is not the same as understanding what is wrong. A process may be poorly executed. A capability may remain appropriate but be insufficiently developed. An operating mechanism may work as designed but have become misaligned with a changed environment. A structure may have accumulated unnecessary complexity. A technology or capability may have become obsolete. Or assumptions that once justified existing arrangements may no longer hold. These are not necessarily the same problem. And they should not automatically produce the same response. Before asking how to transform, organizations therefore need to ask a more fundamental question: What problem are we actually trying to solve? Without that diagnosis, transformation can become a response in search of a problem. Transformation Is an Intervention Choice Aaron Porter made another important observation. Sometimes an organization does not need to transform. It may need to repair something that is not working as designed. It may need to optimize something that remains fundamentally sound. It may need to adapt to a changed external condition. It may need to simplify unnecessary complexity. It may need to replace an obsolete capability. It may need to stop doing something altogether. And sometimes it may indeed need a deeper transformation. This distinction matters because the language of transformation can unintentionally encourage organizations to treat scale of ambition as evidence of appropriateness. But an intervention is not better because it is more transformational. It is better when it is proportionate to the problem it is intended to address. A large intervention applied to a poorly diagnosed problem does not become more effective because it is ambitious. It may simply create more unnecessary change. Transformation Appropriateness Is Not Transformation Readiness This leads to a distinction that deserves greater attention. Transformation appropriateness and transformation readiness are not the same question. Transformation appropriateness asks: Is transformation the right response to the problem we have diagnosed? Transformation readiness asks: Do we have, or can we create, the conditions required for that transformation to work? The order matters. An organization may possess strong leadership commitment, adequate funding, capable teams, effective governance, appropriate technology, sufficient decision authority, and a high degree of readiness for change. None of those conditions demonstrates that transformation is the correct intervention. They demonstrate only that the organization may be capable of executing it. Execution capability cannot compensate for an incorrect diagnosis. Nor can readiness turn an inappropriate intervention into an appropriate one. The organization must first establish what kind of change, if any, the evidence actually justifies. Only then does readiness become the right question. Not Every Tension Is an Incoherence Aaron Porter's comment also raised an important challenge to the argument I developed in the previous article. I argued that transformation frequently encounters an Architectural Incoherence Gap between what the organization says it wants to achieve and the conditions it continues to preserve. Organizations may ask for speed while maintaining slow approval mechanisms. They may ask for autonomy while keeping decision authority centralized. They may ask for innovation while penalizing reasonable experimentation. They may ask for collaboration while rewarding local optimization. But there is an important qualification. Not every apparent contradiction is organizational incoherence. Organizations operate under multiple legitimate requirements that can pull in different directions. A bank may need greater experimentation while simultaneously requiring strong controls. A manufacturer may need local autonomy while preserving process standardization. An organization may need greater speed while maintaining governance mechanisms necessary to protect safety, regulatory compliance, financial integrity, or stakeholder interests. These are not necessarily design failures. They may be legitimate organizational tensions. The challenge is not to eliminate one side of every tension. It is to determine whether the organization has deliberately designed the conditions through which competing requirements can coexist. Where should autonomy apply? Where is standardization necessary? Which decisions can be decentralized, and which require independent oversight? Which risks can be accepted locally, and which must be escalated? What should remain stable while other parts of the organization adapt? Incoherence does not arise merely because legitimate requirements coexist. It arises when the organization's architecture persistently undermines, or makes materially more difficult, the reconciliation of the outcomes it expects the system to produce. That distinction matters. Adaptability Is Not Permanent Transformation There is a broader implication. Organizations are increasingly encouraged to become more adaptive. But adaptability can easily be misunderstood as an obligation to change continuously. It is not. As I argued earlier in this series, the most adaptive organizations are not necessarily those that change most frequently. They are those capable of distinguishing when stability continues to create value and when change becomes necessary. Sometimes the adaptive response is to transform. Sometimes it is to modify or strengthen a limited part of the system. Sometimes it is to remove something that no longer serves its purpose. And sometimes the most intelligent response is deliberately to preserve stability. The capacity to change is only one part of adaptability. The capacity not to change unnecessarily matters as well. The Cost of Solving the Wrong Problem Organizations rarely have unlimited transformation capacity. Every significant intervention consumes leadership attention, management capacity, financial resources, organizational energy, employee attention, trust, time, and opportunity. Transformation also introduces uncertainty into systems that often need to continue operating while they are being changed. Unnecessary transformation therefore has a cost even when it is competently executed. There is also a less visible cost. When organizations repeatedly launch transformations that fail to address the underlying problem, people learn from that experience. Future initiatives may encounter skepticism that is subsequently described as resistance to change. But what appears to be resistance may partly reflect organizational memory. People may have experienced previous programs that changed terminology, structures, roles, technologies, or reporting lines without resolving the conditions that originally created the problem. In such circumstances, the more useful question may not be: Why are people resisting transformation? It may be: What has the organization taught them to expect from transformation? Diagnosis therefore matters not only for selecting the right intervention. It also affects the credibility of future change. From Transformation Reflex to Intervention Discipline A more adaptive organization should therefore avoid two opposite errors. The first is structural inertia: continuing existing arrangements after the conditions that justified them have materially changed. The second is transformation reflex: assuming that significant problems necessarily require large-scale transformation. Both can disconnect organizational action from reality. A more disciplined sequence begins differently: What is happening? What evidence supports that diagnosis? Which assumptions have changed? What should remain stable, and what actually needs to change? What type and scale of intervention does the problem justify? Is transformation necessary? And only then: What must already be true for that transformation to work? This sequence changes transformation from an organizational aspiration into a decision that must itself be justified. Aaron Porter ended his comment with that final question: What must already be true for this transformation to work? I would retain it, but place another immediately before it: What must be true for transformation to be the right response in the first place? The first tests readiness. The second tests appropriateness. Both are necessary. Neither can substitute for the other. A Different Understanding of New Ways of Working This brings us back to the broader argument of this series. New ways of working are often associated with greater speed, agility, experimentation, technology, distributed decision-making, and continuous adaptation. All of these can matter. But perhaps organizational maturity is demonstrated not by the amount of change an organization can generate, but by the quality of the choices it makes about change. Can it distinguish symptoms from causes? Can it determine what should remain stable and what should change? Can it select an intervention proportionate to the problem? And can it reconsider those judgments when the evidence changes? If it can, adaptation becomes something more than responsiveness. It becomes disciplined organizational judgment. The next evolution in how organizations work may therefore not be about becoming better at transformation. It may be about becoming better at determining what should change, what should remain, and whether transformation is the right response at all. Because before an organization asks whether it is ready to transform, there is a more fundamental question it should be able to answer: Why transformation? |
Posted on: September 13, 2026 05:16 AM
| Permalink |
Comments (5)
