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)
When Structural Drift Becomes Consequential
 From Accumulated Incoherence to Value Erosion and Failure Risk The project is still delivering. Milestones are still being reached. Problems are still being solved. People are still carrying integrative work. Trade-offs are still being managed. Exceptions are still being absorbed. The project may even appear successful. And yet something may have changed. Decisions that once preserved flexibility now constrain what can happen next. Dependencies that once required coordination now determine which options remain possible. Workarounds that once solved local problems have become conditions on which other parts of the project depend. Responsibilities remain formally clear, but the conditions required to exercise them have changed. People continue to preserve coherence, but doing so requires increasing attention, coordination or intervention. None of these conditions necessarily means that the project is failing. But they create the final question of this phase: When does structural drift become consequential? More precisely: Under what conditions does accumulated systemic incoherence begin to affect value, risk, strategic viability or project outcomes? Drift Is Not Failure Article 11 introduced structural drift as a hypothesis. It asked whether a project system can gradually change as effective integrative capacity becomes insufficient relative to the volume, velocity or complexity of its material interdependencies. But drift is not failure. A project can change structurally and continue to perform. It can develop new routines. Redistribute coordination. Create informal interfaces. Rely more heavily on particular people. Accept temporary inconsistencies. Defer reconciliation. Adapt governance mechanisms. Change how authority is exercised. Some of those changes may increase resilience. Some may preserve useful flexibility. Some may be efficient responses to uncertainty. Others may create burdens or dependencies that matter later. The existence of drift therefore tells us very little by itself. The relevant question is not: Has the project changed? It is: What consequences, if any, are being created by the way the project system has changed? Consequence Requires a Mechanism It is tempting to construct a simple sequence: insufficient integrative capacity → structural drift → incoherence → failure But that sequence would assume precisely what this phase has been trying to investigate. Each relationship requires its own mechanism. Insufficient integrative capacity may contribute to structural friction without producing structural drift. Structural drift may occur without producing material incoherence. Incoherence may exist without affecting value. A project may absorb substantial incoherence through redundancy, adaptation, human judgment or available slack. And poor outcomes may occur for reasons unrelated to integrative capacity. So Article 15 cannot ask merely whether a project with structural drift later performed poorly. It must ask: What changed in the system, how did that change alter consequential relationships, and through what plausible mechanism did those altered relationships affect value, risk, viability or outcomes? Without that mechanism, temporal sequence is not causal explanation. What Does “Consequential” Mean? Not every consequence matters equally. A new meeting is a consequence. Additional coordination is a consequence. A delayed decision is a consequence. A workaround is a consequence. Additional cognitive effort is a consequence. But Article 15 is concerned with a stronger threshold. When does what has been happening inside the project begin to affect something materially important? That may include: Value because expected benefits are reduced, delayed, transferred or made more costly to realize; Risk because exposure increases, intervention becomes harder, or consequences become more difficult to contain; Strategic viability because the project becomes less capable of supporting the purpose or strategic conditions that justified it; or Project outcomes because delivery, quality, benefits, stakeholder effects or other material results are affected. These categories may overlap. They are not offered as an exhaustive taxonomy. They identify different ways in which internal systemic conditions may become consequential beyond the friction through which they first appeared. Value Erosion Is Not the Same as Project Failure A project does not need to fail before structural incoherence matters. It may deliver what was specified while producing less value than expected. It may reach a milestone while narrowing the benefits that remain achievable. It may remain within budget while transferring cost elsewhere. It may satisfy one stakeholder while creating consequences for another. It may meet scope while weakening operational usability. It may deliver an output while making the intended outcome more difficult to achieve. This distinction matters because traditional project signals may remain acceptable while the value relationship is deteriorating. So the relevant question is not simply: Did the project succeed or fail? It is: Did the evolving project system alter the conditions under which intended value could be created, preserved or realized? That is a different test. Local Success Can Coexist With Systemic Loss This returns us to one of the earliest tensions in THE AWAKENING. A local decision can be legitimate. A team can meet its objective. A supplier can satisfy its contract. A workstream can deliver its output. A manager can act within authority. And yet the combined consequences can still be unfavorable for the project system. This is not because local success is irrelevant. It is because local success and system-level value are different units of evaluation. Consider a technical optimization that improves performance but increases operational complexity. A procurement decision that reduces acquisition cost but limits future adaptability. A schedule recovery action that preserves a milestone but reduces testing opportunity. A governance decision that accelerates approval but reduces the time available to surface consequential interdependencies. Each decision may be defensible within its own frame. The systemic question is whether their combined consequences remain coherent with what the project is trying to achieve. Structural drift becomes relevant when the relationships among such decisions change in ways that materially alter that coherence. Accumulated Incoherence Does Not Mean Accumulated Error The phrase accumulated systemic incoherence needs care. It does not mean that the project has accumulated a growing list of mistakes. Nor does it require individual decisions to have been wrong. Article 5 already established the possibility that locally legitimate decisions can become globally incoherent. Article 13 added a temporal dimension: unresolved material interdependencies may remain connected to later decisions and commitments. Article 14 added another possibility: people may preserve observable coherence through integrative effort that is not fully visible in formal mechanisms. Accumulated incoherence therefore refers to something narrower than accumulated error. It concerns the possibility that relationships among decisions, dependencies, responsibilities, commitments and adaptations become progressively less compatible with one another or with the conditions required to preserve project-level coherence. That possibility still requires evidence. The number of decisions is not evidence of accumulation. Complexity is not evidence of incoherence. Change is not evidence of drift. And drift is not evidence of damage. The Threshold May Depend on the Remaining Capacity to Absorb Projects can absorb a great deal. People resolve conflicts. Teams adapt. Managers intervene. Buffers absorb variability. Contingency absorbs uncertainty. Governance mechanisms escalate exceptions. Stakeholders renegotiate expectations. Technical architectures accommodate change. Informal relationships bridge gaps. This capacity to absorb disturbance may explain why structural friction does not immediately become visible as poor performance. But absorption is not necessarily unlimited. The relevant question may therefore be: When does the project system lose sufficient capacity to absorb, reconcile or redirect the consequences of its own internal incoherence? That threshold could arise for different reasons. The volume of consequential interdependencies may increase. Available attention may decrease. Options may narrow. Reversibility may decline. Slack may be consumed. Key people may become overloaded or unavailable. Commitments may become harder to change. External conditions may shift. Or several of these may interact. None should be assumed to be necessary. But they suggest that consequence may depend not only on the existence of incoherence, but also on the remaining capacity of the system to absorb it. Option Space Matters Article 13 asked whether deferred integration can become more consequential as subsequent decisions and commitments reduce reversibility or increase connectedness. That question becomes particularly important here. A project may tolerate an unresolved interdependency while several alternatives remain available. The same unresolved relationship may become much more consequential after contracts are signed, interfaces are fixed, systems deployed, stakeholders committed or operational dependencies established. The underlying issue may not have changed. The available response may have. This suggests a possible mechanism: Systemic incoherence → continued commitments → narrowing option space → reduced ability to reconcile consequences → greater material exposure But this sequence is only a hypothesis. Narrower option space is not automatically harmful. Commitment is necessary for projects to progress. Irreversibility is not inherently poor design. And preserving options indefinitely may itself destroy value. The relevant question is whether the remaining option space is sufficient for the consequences the system may still need to reconcile. Risk Can Increase Before Failure Appears Failure is an outcome. Risk concerns exposure before the outcome is known. That distinction matters. Structural drift may become consequential by changing exposure even when no adverse outcome has yet occurred. A project may become more dependent on one person. More sensitive to one interface. More difficult to reverse. More reliant on an assumption. More vulnerable to delayed information. More dependent on successful human compensation. More exposed to a decision whose consequences propagate across multiple parts of the system. None of these conditions proves that failure will occur. But they may change the distribution or materiality of possible consequences. The relevant question is therefore not: Has something already gone wrong? It is: Has the evolving configuration materially changed what the project is exposed to, how consequences could propagate, or how effectively the system could respond if they did? That is a risk question rather than a failure claim. Strategic Viability Can Change While Delivery Continues Projects do not operate in a frozen strategic environment. Markets change. Technology changes. Regulation changes. Stakeholder expectations change. Organizational priorities change. New information changes what is valuable. A project configuration that remains internally capable of delivering may nevertheless become less aligned with the conditions that justified the project. This creates a difficult attribution problem. If strategic viability deteriorates, is that because the project system drifted? Or because the external environment changed? Or because strategy itself changed? Or because the project failed to detect and integrate those changes quickly enough? These are different explanations. Structural drift should not become a convenient label for every case in which a project becomes strategically questionable. The stronger question is: Did the way the project system evolved materially reduce its ability to recognize, interpret or respond to changes that were relevant to continued strategic viability? Only then does integrative capacity become a plausible part of the explanation. Consequences Can Be Transferred Article 13 established that burden may persist through transfer rather than through visible continuation of the original issue. The same principle applies to consequences. A project may preserve schedule by transferring effort to operations. Preserve budget by reducing maintainability. Preserve local performance by increasing coordination elsewhere. Preserve delivery by accepting future remediation. Preserve one stakeholder's value while reducing another's. Preserve current flexibility by increasing future exposure. The project itself may therefore continue to look successful while consequences appear somewhere else. This creates an attribution challenge. Where should we look for the consequence? If evaluation stops at the project boundary, transferred consequences may disappear analytically even though they remain real organizational consequences. But widening the boundary indefinitely creates the opposite problem. Almost every project can be connected to distant consequences. So the relevant boundary must remain tied to material causal relationships and legitimate project objectives, obligations and affected interests. System thinking requires broader boundaries. It does not justify unlimited attribution. Failure Is Not a Single Event Even the word failure requires care. A project can fail to meet a milestone. Fail to deliver an output. Fail to realize intended benefits. Fail to remain strategically viable. Fail to protect a stakeholder interest. Fail to adapt when assumptions change. Or deliver successfully while producing consequences that undermine the value it was intended to create. These are not equivalent. Article 15 therefore should not treat project failure as a single binary endpoint. Nor should it redefine every value shortfall as failure. The relevant analytical question is: Which material outcome was affected, relative to what objective, obligation or legitimate expectation, and through what mechanism? Without that specificity, “failure” explains very little. The Project May Still Look Healthy One of the most difficult possibilities is that consequence and visibility may not occur at the same time. The system may continue to produce acceptable indicators while dependencies deepen. Human intervention may continue to resolve emerging conflicts. Workarounds may continue to function. Buffers may still exist. Options may still be sufficient. The consequences may therefore remain contained. This does not establish that deterioration is occurring beneath the surface. Nor does it establish that successful compensation necessarily delays observable consequences. Those possibilities require evidence. But it does mean that: Absence of visible failure is not, by itself, evidence that the relationships supporting project performance remain unchanged. This is as far as Article 15 should go without stronger evidence. Whether successful compensation can systematically increase the interval between the emergence of systemic deterioration and observable consequence remains an open hypothesis. It should not be assumed. Consequence May Be Nonlinear Another possibility must remain open. The relationship between incoherence and consequence may not be proportional. A project may absorb several unresolved tensions with little observable effect. Then one additional commitment, dependency or external change may alter the consequences substantially. That does not necessarily mean a hidden threshold exists. Nor does it justify describing every late-stage problem as a tipping point. But linear reasoning may be insufficient. The effect of an unresolved interdependency may depend on what else has happened around it. The consequence of losing a key person may depend on how concentrated contextual knowledge has become. The consequence of a delayed decision may depend on how much option space remains. The consequence of one local optimization may depend on other optimizations already embedded elsewhere. The relevant question is therefore: Do consequences arise from individual conditions independently, or from interactions among conditions that have become mutually reinforcing or increasingly difficult to reconcile? That distinction matters for both explanation and intervention. Early Friction May Be a Signal, but Not a Diagnosis The working hypothesis for this phase was: Insufficient integrative capacity may become visible first through structural friction, deferred trade-offs, accountability misalignment and narrowing option space rather than immediate project failure. The previous articles examined parts of that possibility. Article 11 examined structural drift. Article 12 examined accountability misalignment. Article 13 examined deferred integration and persistent burden. Article 14 examined human integrative work and compensation. Article 15 can now ask what evidentiary value these conditions may have. But the answer cannot simply be yes. Structural friction may arise from legitimate adaptation. Deferred trade-offs may preserve option value. Accountability tension may reflect temporary transition. Narrowing option space may represent necessary commitment. Human compensation may be effective integrative capacity. None is a failure signal by definition. Their significance depends on mechanism, persistence, materiality, interaction and context. So the phase hypothesis survives only in a bounded form: These conditions may provide earlier evidence of changing systemic relationships, but none can independently establish insufficient integrative capacity or predict project failure. That is a much more defensible proposition. The Counterfactual Still Matters Suppose a project experiences value erosion. How do we know that structural drift contributed? We need to ask: What would reasonably have happened if the relevant integrative relationships had been recognized and reconciled differently? Would value still have declined? Would the same exposure have existed? Would strategic viability still have changed? Would the same outcome have occurred because of external conditions, technical uncertainty, market change, execution failure or another cause? This is difficult. Projects do not provide experimental controls. But without some counterfactual reasoning, attribution becomes retrospective storytelling. A bad outcome followed structural drift. Therefore structural drift caused the bad outcome. That inference is not sufficient. The mechanism and credible alternatives must survive. Alternative Explanations Must Survive Poor project outcomes may result from many causes. Technical failure. Unrealistic objectives. Resource constraints. External shocks. Market change. Regulatory intervention. Supplier failure. Poor execution. Weak leadership. Inadequate expertise. Strategic error. Stakeholder conflict. Simple uncertainty. Bad luck. And combinations of these. Some of these may themselves interact with integrative capacity. But they should not be relabelled as integration problems merely because integration is the focus of this series. That would make the theory absorb every failure and therefore explain none of them well. The discriminating question is: Can a plausible mechanism connect insufficient integrative capacity, through identifiable changes in project relationships or response capacity, to the material consequence being examined, relative to credible alternative explanations? If not, the consequence should not be attributed to insufficient integrative capacity. Structural Drift Is Not Necessarily the Cause There is another possibility. Structural drift may be a response to deteriorating conditions rather than their cause. Teams may create informal coordination because uncertainty increased. Authority may redistribute because the environment became more volatile. Workarounds may proliferate because external change invalidated the original design. People may carry more integrative work because the project entered a difficult transition. In such cases, drift and poor outcomes may share a common cause. Or drift may actually reduce the severity of those outcomes. This is an important adversarial test. Observed sequence is not enough. Even when structural drift precedes an adverse consequence, we must still ask whether it: Contributed to the consequence, Mitigated it, Merely accompanied it, or Was itself produced by the same underlying conditions. Without that distinction, causal attribution remains weak. When Does Drift Become Consequential? We can now formulate the question more precisely. Structural drift becomes consequential not merely when the project system changes, nor when friction appears, nor when people work harder. It becomes consequential when changes in the relationships through which the project operates can be plausibly connected to material effects on value, exposure, strategic viability or outcomes. That may occur when: material interdependencies are no longer recognized or reconciled with sufficient quality, reliability or timeliness; subsequent commitments make unresolved relationships harder to reconcile; responsibility remains while the conditions required for meaningful exercise weaken; human compensation becomes increasingly necessary to preserve acceptable performance; available capacity to absorb or redirect consequences declines; or combinations of these conditions materially change what the project can still achieve or withstand. These are not diagnostic criteria. They are possible mechanisms. No single condition is sufficient. And their presence does not establish causality. What Phase 3 Can and Cannot Conclude Phase 3 began with a question: What consequences may emerge when integrative capacity becomes insufficient relative to material interdependence? The investigation now supports several bounded propositions. 1. Insufficient integrative capacity need not become visible first as project failure. It may become visible through changing relationships, recurring friction, unresolved interdependencies, accountability misalignment, narrowing option space or increasing human integrative effort. But none of these conditions independently proves insufficiency. 2. Structural drift is not inherently dysfunctional. It may represent adaptation, resilience, redistribution or legitimate response to changing conditions. Its significance depends on what relationships change and what consequences follow. 3. Deferred integration can create persistent burden under some conditions, but persistence, accumulation and debt are not equivalent. A mechanism must connect deferral to later burden. 4. Formal responsibility can remain while the conditions required for meaningful exercise become insufficient. But responsibility-capability mismatch must be distinguished from ordinary difficulty, temporary constraint and other explanations. 5. Human integrative work can be part of effective integrative capacity or compensation for its insufficiency. Observable behaviour alone may not distinguish the two. 6. Successful compensation may preserve performance while making underlying insufficiency harder to detect. This remains a working hypothesis, not an established general relationship. 7. Internal systemic conditions become consequential only when a plausible mechanism connects them to material effects on value, exposure, strategic viability or project outcomes. Temporal sequence or correlation is not enough. 8. Poor outcomes cannot be attributed to insufficient integrative capacity without credible alternative explanations and counterfactual reasoning. Integration must not become a universal explanation for project difficulty. What Phase 3 Cannot Establish Phase 3 does not establish that: distributed project systems necessarily lose coherence; structural drift necessarily follows distributed leadership; informal coordination indicates weak architecture; deferred integration is inherently undesirable; human compensation is evidence of dysfunction; narrowing option space is necessarily harmful; AI necessarily increases or reduces integrative capacity; structural drift predicts project failure; or insufficient integrative capacity is the primary explanation for poor project outcomes. Those claims would exceed what the inquiry can support. Phase 3 has instead established the analytical conditions under which the hypothesis can be investigated more rigorously. The Consequence Is Not the Starting Point It is easy to begin with failure. A project missed its objective. Value declined. Risk materialized. A strategy became unviable. Then we work backwards looking for explanations. But THE AWAKENING has taken the opposite route. It began with distribution. Then integration. Then local legitimacy and systemic coherence. Then the assumptions connecting roles, authority, accountability, control and human agency. Only after those relationships were separated did Phase 3 ask what their consequences might be. That sequence matters. Because failure does not tell us which architecture would have prevented it. And success does not tell us that the architecture was adequate. A project can succeed because its architecture was effective. It can succeed because people compensated. It can succeed because conditions were forgiving. It can fail despite strong integrative capacity. And it can fail partly because consequential relationships were not recognized or reconciled while meaningful intervention remained possible. The outcome alone cannot tell us which explanation is true. The End of Phase 3 The question that opened this phase was not: Does insufficient integrative capacity cause project failure? It was: What consequences may emerge when integrative capacity becomes insufficient relative to material interdependence? The answer is necessarily conditional. Consequences may emerge through changing dependencies, deferred reconciliation, accountability misalignment, reduced option space, human compensatory burden, changing exposure and declining capacity to absorb incoherence. But those mechanisms are neither universal nor independently diagnostic. They require evidence. They require boundary conditions. They require alternative explanations. They require counterfactual reasoning. And they require us to distinguish what the system contains from what it transfers, what it absorbs from what it resolves, and what merely changes from what becomes materially consequential. The working hypothesis can therefore be reformulated in a more disciplined form: Insufficient integrative capacity may become visible through structural friction, deferred trade-offs, accountability misalignment, narrowing option space and increasing dependence on human integrative effort before material effects appear in conventional project outcomes. That is not a prediction. It is not a universal sequence. And it does not establish that any one of those conditions indicates failure. It identifies where evidence may need to be sought before the final consequence becomes the only thing we can see. Because by the time incoherence becomes visible as failure, the most important question may no longer be why the project failed. It may be: What changed earlier in the system, while different outcomes were still possible? |
Posted on: October 05, 2026 05:02 AM
| Permalink |
Comments (1)
