Field Note: The Wrong Tools for the Right Problem
Why Your PM Toolkit Breaks Down in Federated Environments, and What to Use Instead
Domain: Federation Architecture / Interface Stewardship Author: Anthony Veltri | anthonyveltri.com Related Doctrine: Doctrine 24: Stewardship Places the Burden on the Steward | Doctrine 11 Companion: Agency vs. Outcome Operational Basis: Hurricane Katrina (2005), Hurricane Florence (2018), iCAV / DHS GII OneView (296,000+ users, 22 components), NATO/Coalition coordination environments
Scene
You have been here. I know because I have been here too, more times than I care to count.
The room is not going the way it should. You have done everything right. You built the RACI. You assigned responsible parties. You documented the requirements. You sent the status report. You built the Gantt. You put the risk register together. Your project management software is color-coded and current and completely irrelevant to anything happening in this room.
Someone across the table, someone who does not report to you and whose agency has its own mandate and its own leadership and its own definition of what “coordinating on this” means, is explaining with great patience why the thing you need them to do is not on their priority list this quarter.
You nod. You make a note. You go back to your desk and your supervisor asks how it went and you say “we are working through some coordination challenges” and your supervisor says “okay, we need to push harder on this, can you follow up more aggressively?” And you send the follow-up email knowing full well it is not going to change anything.
That feeling, the specific exhaustion of applying a tool correctly in a context where it cannot work, is what this field note is about.
This is not a criticism of project managers. It is not a criticism of PMI. The people in these rooms are usually skilled, experienced, and doing exactly what they were trained to do. That is precisely the problem.
Break
Before going further, one distinction matters a lot here.
A matrix organization is still one organization. Authority is divided and sometimes contested, but there is eventually a ceiling where it consolidates inside a single governance structure. A federated environment is different in kind, not just degree. When I say federated, I mean coordination across independent owners of priority, budget, and mandate, parties who answer to different chains of command, operate under different legal authorities, and cannot be compelled by anyone in the room, including you. Hurricane Katrina. Cross-jurisdictional healthcare networks. NATO coalition operations. Multi-agency disaster response. Interagency data sharing initiatives across 22 DHS components.
In those environments, the ceiling does not exist. Or rather it exists so high, Congress, a cabinet secretary, a treaty organization, that invoking it takes longer than your initiative has runway.
Here is what PMI actually says about this, in the places most training pipelines do not dwell on.
PMBOK Sixth Edition, Table 2-1, documents that project manager authority ranges from “little or none” in functional structures to “low” in weak matrix settings, and that budget control often sits with functional management rather than the PM. The same edition acknowledges that projects operate “within the constraints imposed by the organization through their structure and governance framework.” PMI’s research on interorganizational project networks goes further, defining those networks as relationships that both “enable and constrain” the management of projects, with governance operating at the network level rather than inside any single project organization.
PMI has also published, in its learning library, a direct statement that complex systems “change spontaneously in unpredictable ways,” which “aggravates the effectiveness of the current management toolset focusing on planning and control.” That sentence is not in the PMP exam prep materials. It should be.
My argument is not that PMI missed this. I have held my PMP since 2009, along with their Agile (PMI-ACP) and Business Analysis (PMI-PBA) certifications. I know exactly what is in this toolkit, and I know how hard practitioners study to master it. My argument is that the training pipeline does not transmit the limits of these tools, and there is a structural reason why.
The overwhelming majority of PMP preparation material is not designed to produce sophisticated project practitioners. It is designed to pass the exam. That is not a criticism of the people who wrote it or the people who used it. It is a description of what the market selected for. Exam prep distills a large, nuanced body of knowledge into testable formats: definitions, process groups, input-tools-output sequences. Nuance that cannot appear on a multiple choice question does not survive the distillation. The acknowledgment that authority varies sharply by organizational structure is in PMBOK 6. The acknowledgment that complexity degrades planning and control toolsets is in PMI’s own learning library. Neither of those ideas shows up cleanly as a four-option exam question, so neither survives intact into most practitioners’ working understanding of the framework.
The result is a profession of skilled, certified practitioners who were handed the authority-assuming version of the toolkit because that is the version that can be tested. They studied hard. They passed. They showed up to federated coordination problems with what they had been given. The mismatch was upstream of them the whole time.
That gap has consequences I have watched unfold across multiple operational environments, and what follows is my attempt to name them clearly, so practitioners in federated roles can stop blaming themselves for a mismatch that was built into the assignment before they arrived.
The Five PM Tools That Break in Federation – The Toolkit Breakdown.
The RACI Matrix
The RACI assumes you can assign Responsible, Accountable, Consulted, and Informed. It assumes that once you write a partner’s name in the Responsible column, something happens. In a traditional project with a shared authority structure, something does happen. There is a reporting chain. There is a governance ceiling. There is a consequence for non-performance that someone in your chain can invoke.
In a federated environment, that ceiling is absent. So you build the RACI and you send it around and some partners agree to it because agreeing costs them nothing and costs you nothing to extract, and then when the work needs to happen you discover that being listed in the Responsible column of a document they did not author does not make them responsible in any operational sense. The RACI is a record of your intentions. It is not a record of their commitments.
I sat through this at Hurricane Katrina. I watched it again at Florence. The RACI was always present. The partners it named were frequently not.
What you need in that environment is not an assignment matrix. You need a diagnostic that tells you who thinks they own what, who thinks someone else owns it, and where the gap between those two beliefs is producing failures. That is a different artifact doing a different job. The Seam Map was developed from this specific operational failure pattern. It does not assign. It documents reality, including the vacancies.
The Requirements Document
The Requirements Document assumes partners will rise to meet a defined standard. In a traditional project environment, this is reasonable. You control who is on the project or your organization does.
In a federated environment, partners meet you at whatever capability level they currently operate. Some bring refined data. Some bring raw material. Some bring good intentions and a spreadsheet from 2019.
When we built iCAV, which eventually became DHS GII OneView serving 296,000 users across 22 components, we faced this decision directly: require all components to meet a data standard, or build something that could work with what they actually had. A requirements document that said “all partners will provide data in format X” would have been accurate for about four of them. The other eighteen would have been excluded or would have performed compliance without integration.
This is the ore versus gemstones problem we discussed previously: when you write strict requirements assuming perfectly refined data (gemstones), you reject valuable but unrefined raw material (ore). But the ore is still valuable. You just need a different process at the seam. The Interface Control Card addresses this by documenting actual capability levels and pre-authorizing the decisions that follow when partners arrive with what they have, rather than what you specified.
The Risk Register
This one is the most quietly devastating because it creates the appearance of governance while delivering very little of it.
The Risk Register assumes you can mitigate risks through your own actions. You identify a risk, assign an owner, document a mitigation strategy, update the probability and impact scores. It is satisfying work. It produces a document that looks like control.
In a federated environment, your most consequential risks live inside organizations you do not control. The largest item on your register is typically some version of “Partner Agency X does not integrate their system in time,” and the mitigation is “follow up regularly with Agency X POC.” That is not mitigation. That is correspondence with an optimistic label.
PMI’s complexity research supports this directly: complex systems change in unpredictable ways and that degrades the effectiveness of planning and control toolsets. A risk register is a planning and control artifact. When your most significant risks are embedded in sovereign partner organizations operating under independent mandates, the register documents your anxiety. It does not reduce your exposure.
What replaces it in a federated environment is not a better risk register. It is pre-authorized decision rules for when risks materialize, encoded in the Interface Control Card, so that the response does not require a meeting, an escalation, or a compulsion that was never available in the first place.
The Gantt Chart and the Status Report
Briefly, because practitioners who have worked in these environments will not need much elaboration.
The Gantt assumes you control the timeline and the dependencies. In a federated environment, you control your own work and you are a dependent variable in everyone else’s. Your Gantt is accurate for the nodes you own. It is speculative for the rest, and the rest is usually most of it.
The Status Report assumes visibility into all work streams. In a federated environment, partners report to their own leadership first. If they report to you at all, it is because they chose to, not because the governance structure requires it. Opacity is the default condition, not an exception to be managed. Your status report reflects what partners chose to share on a given week, which is a different thing than the status.
Schema
The pattern across all five tools is the same. Each one assumes either the ability to assign, the ability to require, the ability to mitigate, or the ability to see. In a federated environment operating under independent mandates, those assumptions are structurally absent. They do not become available through harder follow-up, more assertive emails, or executive pressure on partners who answer to a different chain of command.
When a manager tells a coordinator to push harder on sovereign external partners, they are not providing a better tool. They are applying internal stakeholder logic to an external stakeholder problem. The door opens the other way. Pushing harder does not open it. It signals to the partners that you do not understand the environment, and that damages the enrollment relationships that were doing the actual coordination work.
PMI documents the ingredients of this problem. Limited formal authority in matrix structures. Complexity degrading planning and control toolsets. Single-integrator models breaking down in complex systems. The PMBOK and its companion materials contain the pieces. My claim, grounded in twenty years of operational experience across disaster response, interagency systems architecture, and coalition coordination, is that in federated work those ingredients are not edge cases. They are the recipe.
The practitioner who was handed a RACI, a Gantt, a requirements document, a risk register, and a status report template and pointed at a multi-agency federated coordination problem was not given a degraded toolkit. They were given the wrong toolkit entirely. That is not a reflection of their skill. It is a reflection of a gap in how federated coordination has been prepared for and taught.
The artifacts in the Stewardship Kit, the Seam Map, the Interface Control Card, and the Quick Reference Card, were built from that gap. They do not assign. They document. They do not require. They pre-authorize. They do not mitigate risks you cannot control. They create decision rules for when those risks arrive. They do not assume visibility. They create conditions for voluntary information flow.
They were built in operational environments where the other tools had already been tried and found wanting. That is not a criticism of project management. It is a description of what federation requires that project management, as currently taught, does not yet provide.
Author: Anthony Veltri, PMP, PMI-ACP, PMI-PBA | anthonyveltri.com Cite as: Veltri, A. (2026). The Wrong Tools for the Right Problem: Why Your PM Toolkit Breaks Down in Federated Environments. Interface Stewardship Field Notes. anthonyveltri.com Related Artifacts: Seam Map | Interface Control Card | Quick Reference Card Related Field Notes: When You Call a Committee a Team | The Bundle Test PMI Source References: PMBOK 6th Edition, Table 2-1 (Organizational Structure Influences); PMBOK 6th Edition, Section 2.4 (Governance); PMI Learning Library, “Complex Business Environments” (planning/control degradation in complex systems); PMI Research, Interorganizational Project Networks; PMI Agile Practice Guide, Section 4.2.3 (Project Managers Use Servant Leadership)
Last Updated on February 22, 2026
