Delegation with Purpose: Building Autonomy and Developing Capability
 Delegating means assigning responsibility for a task or outcome, together with the authority to make decisions within agreed boundaries. Effective delegation requires the resources and support needed to fulfil that responsibility. When it also develops judgment and autonomy, it becomes an investment in the organization’s future. A leader may delegate a task while continuing to decide every detail. They may demand a result without providing resources. They may announce autonomy and intervene whenever someone chooses a different approach. In these situations, the work changes hands, but the ability to act remains limited. Delegation with Purpose connects the expected outcome with the development of the person taking responsibility. It seeks to create value today while leaving people better prepared for future challenges. Decide Before Delegating Delegation begins by understanding what should be assigned, why, and to whom. The RCPCV method structures this decision through five stages: Gather, Consult, Think, Communicate, and Verify. The acronym retains the initials of the original Portuguese terms. Consultation involves the person being considered for the responsibility and the other people affected. It helps identify availability, experience, dependencies, and support needs while keeping responsibility for the decision clear. Choosing someone requires considering competence, availability, and the support needed, alongside opportunities for development. Set Clear Conditions for Delegation Before the delegation decision is communicated, four aspects need to be clear:
The leader remains accountable for the conditions they are responsible for providing. The person taking on the work is accountable for exercising the responsibility and authority assigned to them. Assigning responsibility without authority or resources can leave someone accountable for an outcome they lack the means to deliver. Follow Through to Develop Autonomy Well-founded trust helps leaders give people space. Follow-through helps identify difficulties, support decisions, and learn from execution. The level of oversight should reflect the person’s experience, the complexity of the work, and the potential consequences. A new challenge may require demonstration, guidance, or more frequent reviews. Autonomy can grow as capability is demonstrated. Leaders need to respect decisions made within the agreed boundaries. A solution different from their own preference is not, by itself, a reason to withdraw autonomy. When difficulties arise, it is important to understand what happened before concluding that commitment or competence was lacking. Additional support, revised resources, or a temporary reduction in autonomy may be necessary, with clear explanations and continued review. A Practical Example Consider a hypothetical situation: a director intends to delegate the preparation of a client proposal to a less experienced manager. She consults him about availability, readiness, and support needs, while also hearing from the other people affected. After careful consideration, she clarifies the expected outcome, quality criteria, deadline, and resources. The manager can organize the work and coordinate internal contributions; final commercial approval remains with the authorized role. Before they proceed, she asks him to explain his understanding of the responsibility, what he can decide, and when he should seek support. They agree on a review before any external commitments are made. At the review, the proposal is incomplete. The director feels tempted to finish it herself but first seeks to understand the difficulty. The manager has identified a mismatch between the requested deadline and available capacity but has not yet worked out the alternatives. She helps him examine the assumptions and consequences. He develops the options, explains the reasoning behind his recommendation, and completes the proposal. Her support addresses the specific difficulty while preserving his responsibility and decision-making authority. Even if the client rejects the proposal, execution, judgment, and continuing support needs can still be assessed. Completing one proposal does not, by itself, demonstrate autonomy. That capability needs to be assessed as he takes on further responsibilities. Assess What Remains Delegation should be assessed through its outcome, execution, and the capability developed. Can the person take on similar responsibilities with less support? Do they recognize when they need help? Was the effort sustainable? In regenerative leadership, both the work accomplished and the capability that remains matter. Delegating with purpose means getting work done while developing other people’s ability to understand, decide, and act responsibly. In your next delegation, what outcome do you want to achieve, and what capability do you want to help develop? Reference: Stephen R. Covey, The 7 Habits of Highly Effective People, discussion of stewardship delegation and the Green and Clean example. |
Posted on: October 22, 2026 06:34 AM
| Permalink |
Comments (0)
RCPCV™: A Method for Decision-Making and Continuous Improvement
 Gather, Consult, Think, Communicate, and Verify. Five stages in a continuous cycle connecting information, people, decisions, implementation, and learning. A decision begins before it is announced and continues to require attention after implementation has begun. Between understanding a situation and evaluating the results of a decision, there is an ongoing process of gathering information, consulting people, thinking carefully, communicating, and following up. In regenerative leadership, this process seeks to achieve results in the present while preserving or developing the capabilities, autonomy, and relationships the organization depends on to respond to future demands. I developed RCPCV™ to structure this work. The name comes from its five stages in Portuguese: Recolher, Consultar, Pensar, Comunicar e Verificar, meaning Gather, Consult, Think, Communicate, and Verify. The method organizes decision-making into five interconnected stages within a continuous improvement cycle. Consulting the people affected is always part of the process. The decision is made after weighing the information gathered and the contributions received. Communication explains and sells that decision. Verification monitors implementation, evaluates results, and informs learning and subsequent decisions. Time runs through the entire method. Latency is used here in an operational sense: the time between a need arising and the corresponding response, whether obtaining information, receiving a contribution, deciding, communicating, starting implementation, or responding to what verification reveals. It is important to examine both the time spent within each stage and the waiting time between stages. Examining latency involves distinguishing the time needed to carry out the work, avoidable waits, and the time needed to observe results. The aim is to carry out each part of the process in time to serve its purpose, with a depth of analysis appropriate to the importance, urgency, and consequences of the decision. 1. Gather the FactsThe first step is to understand the situation requiring a decision. What is happening, and what factors are contributing to the situation? What do we want to achieve? What resources do we have? What commitments have we made? What known constraints, dependencies, and consequences shape the choice? Gathering involves seeking relevant information and distinguishing what we know from what we estimate, interpret, or assume. An assumption may be supported by earlier data or may be a hypothesis that still needs to be verified. A predicted delay, for example, needs to be examined to understand its cause: does it arise from a technical dependency, a lack of capacity, or an estimate that has not yet been confirmed? Each explanation may point to a different decision. This stage prepares the consultation. An initial set of facts helps us ask better questions, identify the people affected, and recognize gaps and issues that still need clarification. Information also has a time dimension: when was it produced, when does it become available, and how long does it remain relevant to the situation? Gathering must take into account the time needed to obtain and validate data, as well as the consequences of information arriving late or already being out of date. Consider a hypothetical example that will run through all five stages: two projects each require the same specialist exclusively for the same week. The leader begins by gathering information about deadlines, activities, dependencies, viable alternatives, and the foreseeable consequences of allocating that resource. 2. Consult the People AffectedConsultation is always part of RCPCV™. People affected by the decision may bring practical knowledge that is not included in the initial reports, identify unforeseen risks and consequences, and explain how the situation is experienced by those who will have to implement the decision or bear its consequences. Consultation also brings clarification. It helps clarify facts, questions, perspectives, interests, and consequences. In the two-project example, consultation involves the specialist and the people affected by how the specialist’s time is allocated. It may reveal that one activity requires uninterrupted attention to maintain context, that another allows preparatory work, or that a change in priority will affect a third team’s commitments. These contributions may justify gathering further information. Gathering and consulting work together: what we hear helps us understand what we still need to investigate. Psychological safety provides an environment in which people can share information, disagree, raise questions, and flag risks. The leader is responsible for ensuring that no relevant person is excluded and that contributions are heard and examined seriously. Listening respectfully also involves understanding the facts, experiences, or assumptions underlying conflicting contributions. Organizing consultation includes establishing when contributions are needed, giving people the conditions they need to prepare them, and avoiding unnecessary waits for meetings or responses. Urgency requires organizing participation in time for it to inform the decision, while maintaining the inclusion of the people affected. Consultation does not dilute the decision-maker’s responsibility or automatically turn the decision into a vote. It helps clarify the situation and provide a sound basis for the choice. Responsibilities for the decision, implementation, and follow-up must remain distinct and clear. 3. Think Carefully and DecideAfter gathering information and consulting people, it is necessary to think carefully. This stage brings together the available information and the contributions received, examines differing perspectives and alternatives, assesses risks, and weighs the losses and gains associated with each option. The organization’s purpose and established limits guide the assessment of what is important to achieve and protect. Which alternative best addresses the situation? What benefits does it offer? What losses does it entail? Do we have the resources needed? What will happen if we postpone the decision? In the example, both teams may have legitimate needs. After listening and weighing the options, the leader may conclude that the specialist should give priority to the project with a dependency affecting a higher-priority organizational commitment. The specialist’s work on the other project is postponed. Consultation and careful consideration help the leader recognize that consequence and plan ways to mitigate it. Understanding both teams’ interests does not make a resource divisible when both need it during the same period. Thinking carefully also involves assessing whether the available information is sufficient to make a decision or whether a gap warrants further investigation. Contributions from the consultation help with this assessment. The decision-maker recognizes that relevant uncertainty may remain. Timing is part of the assessment: by when does the decision need to be made? What are the consequences of waiting? Could additional information change the choice in time to make a difference? Deciding when to act requires weighing the benefit of further analysis against the cost of delay. In close cases, when careful consideration identifies no relevant difference between two acceptable alternatives, the leader may use a random draw as a tie-breaking procedure. In that case, the well-considered decision is to accept either alternative and deliberately use that procedure to move the process forward. This stage ends with a well-considered decision, ready to be communicated and implemented. 4. Communicate the DecisionCommunicating means explaining and selling the decision that has already been made. Selling the decision means demonstrating its value and rationale. It involves making clear what was decided, why, and how the choice aligns with the organization’s purpose. It includes addressing objections, acknowledging the consequences for the people affected, and building acceptance and commitment to implementation. The credibility of this communication rests on the work carried out in the earlier stages. Communication should make clear how the contributions received during consultation were considered and which criteria informed the choice. In the example, the leader explains the priority assigned, the criteria considered, the impact on the second project, and the measures planned to mitigate the delay. The leader clarifies what each person is expected to do, with what resources, and within what timeframes. Consultation, fact-gathering, and careful consideration have already taken place. When communicating, the leader presents a decision that has been worked through to guide action. Instructions are communicated in a group setting to promote a shared understanding among all recipients and clarify each person’s responsibilities and the dependencies between their actions. No one who needs to receive the decision may be excluded. The leader must confirm that everyone understands what they are expected to do. A written record helps maintain clarity and confirm what has been established. A person may understand the decision and commit to implementing it even if their initial preference was different. Communication connects the considered choice with the commitment to put it into practice. It is important to track the interval between making the decision, communicating it, and ensuring that recipients are in a position to act. In the example, the teams and the specialist need to be informed of the priority in time to prepare the work and reorganize the commitments affected. 5. Verify Implementation and ResultsAfter communicating, the leader monitors implementation and its effects. Is the decision being implemented correctly and with commitment? Did implementation begin when it needed to? Are resources available and being used efficiently? Have obstacles or waits emerged that are blocking the work? Has the context changed? Are the results favorable to the organization? Implementation involves its own time requirements: mobilizing resources, starting activities, addressing dependencies, and resolving obstacles. These intervals need to be tracked, including when a difficulty is identified and how much time passes before a response. Verification requires distinguishing three dimensions:
Similarly, a favorable result does not, on its own, prove the quality of the decision or its implementation. It may have benefited from favorable circumstances that should be recognized. In the example, the leader checks whether the priority commitment was met, how much the second project was actually delayed, what additional costs arose, and whether the allocation overloaded the specialist. The leader compares these effects with what was considered when making the decision, including the results of the mitigation measures. The leader also examines whether information became available, consultation took place, and the decision was made and communicated in time, and whether any waits delayed the start or continuation of the work. Verification itself must take place at the appropriate time. It is necessary to distinguish the time an effect needs to become observable from the delay in detecting and assessing it. Verifying too late may prolong harm; drawing conclusions too early may mean judging an outcome as a failure before it has had time to emerge. This is the stage at which the need to adjust implementation or revise the decision itself is assessed. When that happens, the process returns to gathering information, consulting people, thinking carefully, and communicating. It is important to track the interval between recognizing that need and putting the response into practice. The possibility of revision does not remove the need for careful consideration beforehand: some consequences can be remedied, but others involve irreversible losses. Learning depends on examining experience and applying what is learned to subsequent decisions. In regenerative leadership, verification also includes examining the decision’s effects on people’s capabilities, mutual trust, and the conditions the organization depends on to continue creating value. Five Stages in a Continuous CycleRCPCV™ connects a decision with its implementation, the experience it produces, and what we learn from that experience: Gather → Consult → Think and decide → Communicate → Verify → a new cycle. Each stage serves a specific function within the method:
When verification leads to learning that is put into practice and to effective corrections, the cycle contributes to developing the organization’s capacity and preparing teams for subsequent challenges. Making a decision involves gathering the facts, consulting the people affected, thinking carefully, explaining and selling the choice, and following through on its implementation and results. Which stage deserves more attention in your organization’s decision-making? |
Posted on: October 18, 2026 06:51 AM
| Permalink |
Comments (0)
The Same Change Can Succeed and Fail at the Same Time
 Why transformation outcomes depend on what we examine, at what level, for whom, by which criteria and over what period Organizations often ask whether a transformation succeeded. Did performance improve? Were costs reduced? Did teams become more autonomous? Did the organization become more adaptable? These are legitimate questions. But there is a problem hidden inside the question: What exactly do we mean by success? A transformation can improve performance in one part of the organization while creating difficulties elsewhere. It can benefit one stakeholder while imposing costs on another. It can produce immediate gains while weakening capabilities needed later. It can succeed according to one criterion and fail according to another. This does not mean that success is arbitrary. It means that success is always success with respect to something. So before concluding that a transformation succeeded or failed, we need to make explicit what is being evaluated. The Same Change Can Produce Different Judgments Consider an organization that introduces AI into a workflow. The technology reduces the time required to complete certain tasks. Productivity increases. From an operational efficiency perspective, the change may appear successful. But suppose the same change also reduces the opportunities through which less experienced professionals learn how to analyse problems, recognize exceptions and develop judgment. From a capability-development perspective, the picture may be different. Suppose customers receive faster responses, but employees experience greater monitoring and less discretion. Again, the evaluation changes. None of these observations invalidates the original productivity gain. Different judgments do not necessarily mean that one of them is wrong. They may be evaluating different aspects of the same organizational reality. The problem begins when one of those judgments is treated as if it represented the whole transformation. What Are We Evaluating? The first question concerns the object of evaluation. A transformation can affect work, authority, capabilities, relationships and organizational performance simultaneously. Suppose a new operating model reduces cycle time. If cycle time is the object of evaluation, the evidence may indicate improvement. But the same operating model may also change how decisions are made, how knowledge circulates or how people develop. Those are different objects. Evaluating one does not automatically evaluate the others. This distinction matters because organizations often move too quickly from: This indicator improved to: The transformation succeeded. The second statement is much broader than the first. Evidence about one object should not automatically be generalized into a judgment about the whole system. At What Level Are We Looking? The second question concerns the level of analysis. A change can improve performance locally while creating problems at another level of the system. A team may become faster because it receives greater autonomy. But if several teams optimize their work independently, coordination across the organization may become more difficult. A business unit may reduce its costs by transferring activities to a shared service. The unit's financial indicators improve. But the shared service may become overloaded, increasing delays elsewhere. Both observations may be accurate. They refer to different levels of the system. Local improvement is not automatically system improvement. And system improvement cannot always be inferred from the performance of its individual parts. The question is therefore not only whether performance improved. It is: At what level did it improve — and what happened at the other levels affected by the change? Success for Whom? A third question concerns the stakeholder. Organizational transformations redistribute more than tasks. They can redistribute benefits, costs, opportunities, authority and risk. A process that improves convenience for customers may increase workload elsewhere. Automation may reduce costs while changing developmental opportunities for people entering a profession. None of this means that different stakeholder interests can always be reconciled. Nor does it mean that every stakeholder consequence should be given identical weight. It means that statements about success need to identify whose experience, interests or outcomes are being considered. Without that clarity, “the transformation succeeded” can conceal an important distributional question: Successful for whom? According to Which Criterion? Even when we agree on the object, level and stakeholder, evaluation can still change depending on the criterion being used. The same intervention may increase efficiency, reduce cost, strengthen resilience, improve customer experience or affect learning and trust. These criteria are not interchangeable. And they do not necessarily move in the same direction. An organization can become more efficient while becoming less resilient. It can reduce cost while increasing dependency. It can increase local autonomy while weakening coherence across the system. The problem is not that organizations use different criteria. They should. The problem arises when one criterion silently becomes a proxy for overall success. A transformation judged only by cost tells us what happened to cost. It does not, by itself, tell us what happened to the organization as a whole. Over What Period? There is another dimension that can radically alter the judgment: Time. A transformation can produce benefits immediately and costs later. Or it can create short-term disruption while building capabilities that generate value over time. A new technology may initially reduce productivity while people learn how to use it. Later, performance may improve substantially. Another intervention may produce immediate efficiency gains while gradually increasing dependency, reducing redundancy or weakening the development of human capability. The judgment therefore depends partly on when we evaluate. This is particularly important because organizations often evaluate transformation according to reporting cycles that are shorter than some of the consequences they are trying to understand. What looks successful after three months may look different after three years. And what appears unsuccessful during transition may eventually prove valuable. Time does not merely reveal additional outcomes. It can change how earlier evidence should be interpreted. Success and Failure Are Not Always Opposites We often speak about success and failure as if they occupied opposite ends of a single scale. But organizational change can produce multiple consequences simultaneously. A transformation can therefore be successful in one respect and unsuccessful in another without either judgment necessarily being false. This is not a logical contradiction. The same realized change is not being judged differently under identical conditions. The judgments refer to different objects, levels, stakeholders, criteria or time horizons. Success and failure can coexist because they may refer to different dimensions of the same realized change. This does not make evaluation impossible. It makes evaluation more demanding. This Does Not Mean That Everything Is Relative There is an obvious danger in this argument. If every transformation can be examined from multiple perspectives, does that mean that any result can be described as either success or failure? No. Evidence still matters. Criteria still matter. Causal relationships still matter. Some objectives will have been explicitly established in advance. Some obligations, constraints and thresholds cannot simply be redefined after the fact. The purpose of examining transformation across these dimensions is therefore not to make judgment arbitrary. It is the opposite. It is to make the basis of judgment explicit and examinable. Instead of simply saying: The transformation succeeded. We need to make explicit what that judgment refers to. That does not weaken evaluation. It makes evaluation more rigorous. Evaluation Requires a Frame A success story can be factually correct and still be incomplete. So can a failure story. The question is not whether the story is positive or negative. The question is what it leaves outside the frame. A judgment about transformation requires five questions to be made explicit: What are we evaluating? At what level? For whom? According to which criterion? Over what period? The judgment may differ depending on any one of these — even when the underlying observations remain the same. This gives us a more precise way to understand transformation evaluation: Evaluation depends on the object, level, stakeholder, criterion and time horizon through which realized change is examined. This is not a formula for calculating success. Nor is it a scorecard. It is a discipline for making explicit what a claim of success or failure actually refers to. The Same Change Can Succeed and Fail at the Same Time The previous two articles established two distinctions. Transformation is not a sequence. It unfolds through interaction, feedback, adaptation and changing conditions. And implementation is not realization. What is introduced does not determine the organizational configuration that develops. Now a third distinction becomes necessary. Realization is not evaluation. Knowing what changed does not, by itself, tell us what that change means. Meaning depends on what we examine, at what level, for whom, according to which criterion and over what period. So the three questions form a progression: How does change unfold? What does change become? What does change mean? Or, more compactly: PROCESS → REALITY → EVALUATION Rigorous evaluation depends on understanding what was realized, just as understanding realization benefits from knowing how change unfolded through the system. A roadmap can guide transformation without fully describing how it unfolds. An intervention can be implemented without determining what the organization becomes. And evidence of improvement can be valid without establishing that the transformation succeeded as a whole. These distinctions do not make planning, implementation or evaluation less important. They make it necessary to understand what each can tell us, and what it cannot. The challenge is therefore not simply to implement change or demonstrate improvement. It is to understand how change unfolds, what the organization actually becomes, and how the consequences of that change should be evaluated. PROCESS → REALITY → EVALUATION Three distinct questions, connected by the same requirement: to examine the transformation that actually unfolds, rather than assume that what was planned, implemented or measured tells the whole story. |
Posted on: October 11, 2026 04:21 AM
| Permalink |
Comments (0)
What Must Exist Even When No Single Role Owns the Whole?
 Identifying the Functions Project Systems Still Require The project is being managed. Work progresses. Decisions are made. Risks are addressed. Governance operates. Responsibilities may be distributed across teams, governance bodies, platforms and technological agents. No single role necessarily owns the whole. That may be appropriate. But it raises a question roles cannot answer: What must still exist for the project system to function as a coherent whole? THE AWAKENING began by questioning whether PMI's evolving conception of project management is progressively hollowing out the distinctive professional contribution of the Project Manager, and whether distributed project architectures preserve effective integrative capacity. Redistribution alone answers neither question. First, we must investigate what the system requires. From Roles to Requirements A role-first analysis follows: Existing role → Current tasks → Tasks redistributed or automated → Remaining role It describes professional change but cannot establish which functions remain necessary. THE EMERGENCE reverses the inquiry: System requirement → Candidate function → Necessity assessment → Candidate capabilities → Possible mechanisms → Allocation across human and technological actors → Role implications This is an analytical sequence, not a mandatory linear procedure. A candidate function may prove necessary, substitutable or unnecessary under specified conditions. Redistribution may also reveal requirements obscured by historical roles. Requirements determine what we investigate. Inherited roles do not determine what must survive. Function Is Not Mechanism Function ≠ mechanism. An escalation path may resolve conflict. A dashboard may provide visibility. An approval gate may constrain decisions. A Project Manager may coordinate dependencies. None establishes, merely by existing, the underlying function or its necessity. What system requirement is each arrangement attempting to satisfy? Different mechanisms may realize the same function. A mechanism may disappear while its function remains necessary; alternatively, the underlying requirement may itself disappear. We must distinguish requirements, candidate functions, capabilities, mechanisms and actors rather than preserving practices—or declaring functions obsolete—because historical owners change. Follow the Function. Follow the Consequences. Decisions may move to teams; coordination to platforms; monitoring to automation; analysis to AI agents. But associated consequences may migrate with a function, remain elsewhere, be redistributed, change, propagate, disappear or persist without an identifiable locus. Follow the function. Follow the consequences. Do not assume they travel together. Separate observation does not imply independence. It prevents one trajectory from being inferred from the other. An actor may remain accountable while consequential decisions move elsewhere. Redistribution may also improve accountability or eliminate consequences created by the previous architecture. A diagnostic chain helps reconstruct what happens: Who does → knows → coordinates → recommends → decides → overrides → monitors → controls → is accountable → learns → develops → captures value → bears consequences? These thirteen elements are not thirteen necessary functions. They distinguish activity, knowledge, authority, accountability, learning, value and consequences. Their distribution and interaction can reveal mobilized capabilities, consequential dependencies and hidden requirements. Integration Across Boundaries Consider a distributed project. Each team performs well. Each decision is locally legitimate. Governance mechanisms operate as designed. Yet decisions interact across technical, organizational or stakeholder boundaries. How are interdependencies identified when they cross individual actors' boundaries of visibility? What enables a response when adjustments cross several decision rights? How are consequences recognized when locally reasonable decisions interact? Perhaps teams, governance bodies, platforms and agents collectively provide that capacity. Perhaps technology resolves some interdependencies without active intervention. Neither possibility requires a universal integrator. But locally effective components do not, by themselves, establish system-level integration. The requirement, if it exists, must be investigated independently of its historical owner. Testing a Candidate: Control Control is easily confused with hierarchy, supervision, approval, compliance, enforcement or sanctions. None should define the function in advance. Consider a legitimate constraint: a safety requirement, financial boundary, technical standard, ethical limitation or stakeholder commitment. Suppose it is not followed. What happens? Constraint → Expected behaviour → Actual behaviour → Deviation → Detection → Legitimacy assessment → Response → Consequence → Subsequent behaviour A formal constraint is not necessarily consequential. Detection is not response; response is not consequence; consequence is not subsequent behavioural change. Compliance alone does not reveal what produced it. Professional norms, peer regulation, transparency, technical guardrails and formal authority may produce similar outcomes through different mechanisms. The question is not simply who controls the project? It is: What function or capability, if any, must exist for legitimate constraints to remain consequential when no single role owns the whole? Control is a candidate function, not an established irreducible requirement. One provisional hypothesis is that it remains necessary under specified conditions, through distributed, social, normative or technological mechanisms. The hypothesis must be refutable: Can a distributed system preserve consequential commitments, coherence, legitimate accountability and adaptation without a control function, rather than merely relocating it? Failure to identify control is not evidence of absence. Nor can every behavioural influence be labelled control; that would make the hypothesis unfalsifiable. Credible alternatives and competing explanations must be examined before necessity is inferred. Why Deviations Matter Normal operation may conceal how commitments are preserved. Deviations expose what happens when expectations and behaviour diverge: a standard is challenged, an authority boundary exceeded, an AI recommendation conflicts with professional judgment, or legitimate commitments become incompatible. Non-compliance is not necessarily governance failure. Justified exceptions, discretion and revision may be essential. Conversely, compliance does not establish effective or legitimate governance. The underlying requirement may involve detecting material deviations, assessing legitimacy, responding appropriately, preserving accountability and revising constraints. Whether these are functions, capabilities or mechanisms remains open. Tension can reveal a requirement. It cannot predetermine its architecture. Presence, Technology and Future Capacity Formal presence does not establish effective capacity. An escalation path may exist but act too late; accountability may be assigned without sufficient information or authority; human review may occur without a meaningful opportunity to intervene. The reverse inference is equally unsafe: preserved performance does not identify what produced it. Effective capacity may depend on distributed mechanisms, technology, human compensatory work or conditions that will not persist. Investigate the capacity actually mobilized, not merely the formal architecture or observed outcome. Technology does not settle necessity. Automating an activity does not prove that its underlying requirement disappeared. Nor does human accountability establish that humans retain the authority, knowledge or opportunity to exercise it. Requirements may extend beyond current performance. A system may deliver successfully today while weakening its ability to satisfy requirements tomorrow. Automation may alter opportunities to develop judgment, expertise or leadership. Alternative mechanisms may regenerate necessary capabilities; some capabilities may cease to be required. Current capacity and capability regeneration are distinct. Whether regeneration is itself a necessary function, a supporting condition or unnecessary under particular architectures remains open. Value and consequences also matter. The actor executing work may not capture its value; the decision-maker may not bear its consequences. Redistribution may create requirements that become visible only when benefits, burdens and effects across system boundaries are examined. These trajectories must be investigated, not presumed to establish new functions. What Would Establish Necessity? Historical prevalence, standards and professional intuition can suggest candidate functions. They cannot establish necessity. A defensible claim must address six interdependent analytical requirements: 1. Specify the system requirement. What must be preserved or accomplished, and under which conditions? 2. Identify the candidate function. How might it satisfy that requirement independently of a familiar role? 3. Examine absence or insufficiency. What changes when it is missing or inadequate, and which capacities actually sustain outcomes? 4. Investigate substitutes. Could another function satisfy the requirement, another mechanism realize the function, or a changed architecture eliminate the requirement? 5. Test competing explanations. Could observed deterioration or success arise from resources, information, incompatible constraints or other causes? 6. Specify boundary conditions. Is necessity claimed for one configuration, plausible alternatives or more general circumstances? These are not sequential steps whose completion proves necessity. They constrain what may legitimately be inferred from evidence. A system may deteriorate when a function is removed simply because it was not reorganized. Suppose the Project Manager no longer integrates information: can teams, governance bodies, platforms and agents collectively preserve the required integrative capacity? If so, the historical allocation may be replaceable. If not, the observed architecture may lack capacity—but that does not prove the Project Manager must be restored. The inquiry must allow a function to prove unnecessary, substitutable or conditionally necessary. What Article 16 Establishes PMBOK 8 recognizes configurations where project management responsibilities are distributed without a formally titled Project Manager. This establishes a possibility recognized by the standard—not its prevalence, effectiveness or professional consequences. Two questions remain connected but distinct. Professional: If historically associated functions remain necessary but are adequately realized elsewhere, what distinctive contribution, if any, justifies the Project Manager role? If redistributed inadequately, what follows? Professional contribution must be demonstrated, not inherited. Architectural: What must distributed configurations provide to preserve integration, coherence, adaptation, legitimate accountability and value, including capabilities needed over time? Neither centralization nor distribution establishes sufficiency by itself. A necessary function may exist somewhere in an architecture without being effectively exercised at system level. That distinction leads to the next investigation: Article 17 – What Makes Integrative Capacity Effective? From Functional Presence to System-Level Capability |
Posted on: October 09, 2026 05:37 AM
| Permalink |
Comments (1)
PHASE 4 – THE EMERGENCE
 Opening Note THE AWAKENING began with two related questions about the future of the profession and the architecture of project management. The first three phases did not simply confirm the propositions behind those questions. They investigated them. And that investigation changed what can legitimately be claimed. A function does not necessarily require a particular role. The redistribution of responsibility does not, by itself, establish the disappearance or devaluation of professional contribution. PMBOK 8 recognizes integration. The question is therefore not whether integration has been forgotten, nor whether every project requires one universal integrator. The more demanding question is how integrative responsibility is configured when leadership, authority and management responsibilities are distributed, whether that responsibility is adequately enabled, and how it is actually exercised. THE EMERGENCE takes the investigation forward from those findings without losing sight of the questions that gave rise to the series. If no single role can be assumed to own the whole, what must the project system still be capable of doing? This phase does not begin by asking what the future Project Manager, Project Professional or Project Leader should become. Nor does it begin with a predefined model of leadership or a list of competencies inherited from existing roles. Its epistemic function is requirement discovery. The purpose is to identify the functions, capabilities and architectural conditions required to preserve coherence, adaptation, legitimate accountability and value across distributed project systems. That changes the question. Earlier phases established that a necessary function does not necessarily require a particular role, that capabilities and responsibilities can be configured across different actors and mechanisms, and that formal presence does not by itself establish effective system-level capacity. THE EMERGENCE begins from those distinctions rather than reopening them. It asks which requirements persist. A role may disappear while a function remains necessary. A mechanism may change while the underlying requirement remains. But the reverse must also remain possible: some functions inherited from previous organizational architectures may prove unnecessary when the conditions that once made them necessary no longer exist. The existence of a function must therefore not be inferred from the historical existence of a role. But neither should the disappearance of a role be treated as evidence that the function has disappeared. No prior list of functions is treated as canonical. Existing concepts and leadership architectures form part of the intellectual context of this research, but they do not determine what this phase must find. A candidate function must survive because the project system requires what that function accomplishes, not because it corresponds to an existing role, competency model or leadership framework. This requirement-discovery process is also necessary to return rigorously to the two questions from which THE AWAKENING began. For the professional question, it is not enough to observe that responsibilities historically associated with the Project Manager have been redistributed. We must first establish which functions and capabilities remain necessary, whether and how they are being realized elsewhere in the project system, and what their redistribution ultimately means for the distinctive professional contribution of the Project Manager. For the architectural question, it is not enough to establish that integration is recognized or that governance mechanisms exist. We must determine what functions, capabilities and conditions are actually required for integration to remain effective when authority, knowledge, decision-making and management responsibilities are distributed, and whether different configurations can satisfy those requirements. Neither inquiry predetermines its answer. The investigation may ultimately strengthen, qualify or contradict the propositions that gave rise to either question. For the same reason, this phase postpones the Regenerative Project Leader™ question until the required functions and capabilities have first been identified. The sequence is deliberate. Article 16 asks what the project system cannot afford to leave unrealized. Article 17 investigates what makes those functions effective at system level rather than merely present somewhere within the system. Article 18 examines which elements can be performed, supported or delegated technologically and which, if any, require human judgment, legitimacy or accountability. Article 19 investigates which responsibilities, if any, must remain associated with leadership beyond delivery, including purpose, strategic intent, value, stakeholder consequences, sustainability and long-term viability. Only then does Article 20 ask whether the functions and capabilities identified across the phase converge strongly enough to justify a distinct leadership archetype, or whether they are better understood as a distributed capability architecture. That question has no predetermined answer. The investigation may find that essential capabilities can remain distributed across the project system without converging in a distinct leadership archetype. It may find that some requirements are contingent rather than universal. It may find that functions historically associated with leadership can be performed through different organizational or technological mechanisms. Or it may find that apparently distributed requirements repeatedly converge around a coherent configuration of leadership capabilities. Each of those outcomes must remain possible. THE EMERGENCE therefore reverses the conventional direction of role design: Do not begin with the leader and ask what capabilities the role should possess. Begin with the project system and ask what capabilities the system cannot afford to lose. Only after those requirements have been established can we ask where they should reside, how they should be exercised, how they may be distributed across human and technological actors, and what their distribution ultimately means for leadership, for the professional contribution of the Project Manager, and for the architecture through which project coherence is preserved. THE EMERGENCE is therefore an investigation into what the future project system must still be able to do, not an attempt to define in advance the competencies of the future Project Manager. Whether those requirements ultimately converge into a leadership architecture is a question for the investigation, not a premise of it. And whether the findings ultimately support, qualify or challenge the propositions that gave rise to THE AWAKENING must likewise remain an outcome of the investigation, not an assumption built into it. |
Posted on: October 07, 2026 05:05 AM
| Permalink |
Comments (0)
