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