The last post in this series, EVM / EVMM-Style Visibility, ended on a specific note: the difference between reporting activity and controlling delivery.
This post picks that thread up and asks what happens when the system supporting delivery begins to participate more actively in that control—collecting updates, recognizing uncertainty, proposing actions, and helping people decide what should happen next.
What a control tower actually is
In this lab, a portfolio control tower means something more specific than a dashboard.
It brings visibility across projects together with a defined process for intervention: reviewing a resource conflict, changing a sequence, escalating a risk, and recording the decision.
That requires two things at once: the judgment to understand what a signal means in context, and an operating structure capable of turning that judgment into accountable action.
It also requires clarity about authority.
A system may be technically capable of changing a schedule without being authorized to make that decision. A useful control tower needs to distinguish what it can observe, what it can recommend, and what it has permission to change.
The gap between visibility and control
MYT’s governance lab work has been exploring how Microsoft Project, Dataverse, and Power BI can support connected delivery oversight. The EVM / EVMM work extends that thinking into planned versus actual progress, variance, ownership, readiness, and delivery confidence.
Together, those structures help answer: “What is happening, and how does it compare with the plan?”
The next questions are harder:
1. What should happen next?
2. Who needs to respond?
3. Who decides?
A slipping task can consume available slack. That can threaten a downstream sequence or contribute to a resource conflict elsewhere. Recognizing that chain and responding still depends heavily on someone noticing it, interpreting it, and bringing it to the right decision-maker in time.
The next layer of this lab explores how an agent might help.
Where agentic tools change the equation
The starting point is a familiar delivery problem: collecting a reliable status update.
Consider a team member saying:
“The migration is basically finished, but reconciliation is still waiting on Finance.”
There is useful information in that sentence, but it is not yet a dependable schedule update.
Does “finished” mean the technical execution is complete? Is validation still outstanding? Who owns the remaining action? Does the next activity depend on reconciliation?
A conversational assistant could ask those follow-up questions, connect the response to the correct task, and prepare a structured update for review.
That is an early, practical test of agentic reporting: whether the assistant can recognize uncertainty and help resolve it before that uncertainty becomes a misleading status.
The PMO still owns the delivery judgment. The agent helps gather and organize the evidence that judgment depends on.
Where MYT starts
This begins as a lab exploration.
The first build will examine a narrow reporting loop: a Teams-based assistant that requests an update about an assigned task, clarifies the response, and prepares the resulting status for the delivery system.
The first question is whether that loop can work reliably within MYT’s existing environment.
Direct schedule updates will depend on the scheduling platform, supported integration methods, licensing, and permissions available. Establishing those boundaries is part of the lab work.
The intended progression is straightforward:
• Collect an update against a known task.
• Clarify progress, remaining work, blockers, and ownership.
• Present the proposed changes for confirmation.
• Record the accepted update through a supported route.
• Make the result visible in delivery reporting.
The record should preserve who supplied the update, what changed, and whether a person reviewed or approved it.
At this stage, changes to baselines, dependencies, and resource assignments would remain subject to explicit human review.
The first proof is deliberately small: can a conversation become an accurate, traceable delivery update?
Building toward portfolio oversight
If that first loop works, the next step is to examine the quality and implications of the information being collected.
A schedule-quality assistant could inspect plans against defined checks and propose corrections. A later experiment could explore dependency impacts, readiness gaps, or resource conflicts across more than one project.
Each step would need its own evidence.
Collecting status reliably does not, by itself, demonstrate that an agent can reason reliably about a complex schedule. Finding a conflict does not establish that its proposed reassignment is the right decision.
Those capabilities need to be tested against the delivery structure, with clear limits on the agent’s authority.
The portfolio control tower is the direction of travel. The first reporting loop is the next build.
From reporting to accountable action
Visibility helped us understand what exists and what is happening.
Delivery control connected that activity to the plan, the variance, the readiness, and the decisions needed to keep work moving.
This next layer asks a further question:
When something begins to drift, who—or what—notices, what evidence supports the concern, and how does it reach someone who can act?
That is the thread running through this series: from CoE visibility, through native governance and delivery control, toward more responsive and accountable oversight.
The next MYT lab will begin with one task, one conversation, and one recorded update.
That is a small step. It is also a concrete place to start proving what the larger idea requires.
