The Router in the Boardroom: Fixing Projects with Network Thinking

Hatched by Warish

Apr 14, 2026

9 min read

5 views

82%

What do your router and your PMO have in common?

When your device connects to the internet it gets an IP address that tells the network where it belongs and how to reach it. The router at home asks the provider for an external address and then gives every device a private address that only matters on the local network. Domain names are human friendly labels that DNS translates into those numeric addresses so you do not need to remember a string of numbers. Underneath that neat simplicity is a stack of rules that decide how data is routed, how lost packets are retried, and how two machines verify they are ready to exchange important information. Those rules determine whether a video plays smoothly or a request times out.

Now imagine a large project. People join, roles are assigned, a methodology is chosen, and someone is expected to make sure it all arrives where it should. Most organisations have a Project Management Office and many apply a defined methodology, yet training, clarity, and consistent risk practices remain spotty. The result looks eerily familiar to anyone who has seen a misconfigured network: devices that cannot find one another, messages that never arrive, repeated retries that clog capacity, and frustrated users blaming the wrong component.

This essay takes that similarity seriously. It proposes that projects fail less because of people or tools alone and more because organisations neglect the network properties of work: addressing, naming, routing, and transport. I will show how simple network concepts become practical management protocols, how they expose why PMOs can feel busy but ineffective, and how to configure organisational wiring so commitments actually reach their destination.

The hidden infrastructure of delivery

Physical cables and radio waves are obvious in a network but they are only the base of what makes communication reliable. The Internet Protocol gives every endpoint an address. DNS translates human language into that address. Routers maintain routing tables that decide the best path for each packet. Transport protocols confirm reception and resend what is lost. These pieces together create an ecosystem that tolerates failure, reorders parts, and still produces coherent service.

Organisations have analogous layers that are often informal or implicit. People have roles and skills that act like addresses. Job titles and role descriptions attempt to mimic DNS but often map to multiple people or to no one at all. Decision rights and escalation paths perform the routing function, but when those routing tables are out of date the wrong people get pulled into low value decisions. Project methods try to act like transport protocols, promising reliable handoffs, but without consistent training and institutional memory those handoffs become best guesses.

Consider this common snapshot: an organisation retains a PMO, applies a defined methodology to most projects, and engages in risk management most of the time. Yet only about half of the workforce doing projects are professionally trained and fewer organisations provide accredited training. The PMO may be present and active, but the ecosystem around it is underconfigured. That mismatch is what makes the PMO look like a router that has been plugged into the network without any routes loaded.

Read the network: five analogies that become management tools

Below are five direct mappings from network engineering to project practice. Each mapping is concrete and actionable. Together they form a new lens for diagnosing and fixing delivery failure.

Addressability: make every work item resolvable to a single responsible endpoint. In networks an IP address uniquely identifies a host so packets get delivered. In projects every task, decision, and requirement needs a single accountable owner who can accept or reject the request. Ambiguous ownership is like two devices claiming the same IP. It produces collisions, retries, and ultimately silence when neither agent takes responsibility.
Organizational DNS: standardize role names and create a registry that maps roles to people and permissions. DNS avoids the pain of remembering numeric addresses by resolving names to addresses. Organisations suffer when titles are reused inconsistently across teams or when the same title maps to widely different authority. A lightweight registry that documents who is the single canonical owner for common role names eliminates that ambiguity and speeds resolution of cross team requests.
Routing tables of decision rights: codify who decides what, and how decisions propagate. Routers maintain routing tables and propagate only necessary information; they do not attempt to carry every packet. Organisations benefit when routing tables of decision rights are explicit and minimal. That prevents the PMO from becoming a choke point by giving clear local authority for routine choices and reserving escalations for genuinely complex or risky items.
Transport protocols for commitments: define handshakes, acknowledgements, and retransmission policies. TCP does not assume the network is flawless; it creates a handshake to begin a conversation and a retransmission policy for lost packets. Projects need rituals that act like handshakes: short alignment meetings that confirm scope, deadlines, and assumptions; explicit acknowledgements when a handoff is accepted; and predefined escalation triggers when acknowledgements are not received.
Bandwidth and headcount as capacity planning: measure throughput, not just headcount. Routers and links have finite bandwidth. When traffic exceeds capacity latency goes up and packets drop. Treat PMO headcount, team bandwidth, and time as capacity variables. If scope or responsibilities increase but headcount falls, expect delivery failures unless you redesign the flow or reduce packet size.

These analogies are not just clever metaphors. They become operational tools when translated into specific rules and checklists that teams actually use.

A practical framework: the Four Protocols of Reliable Delivery

To move from metaphor to practice, use a short framework that mirrors the layers of a simple network stack. Each protocol is a set of rules you can audit and improve.

Protocol 1: Addressing

Every deliverable and decision must list a single owner by name and by role. That owner is resolvable through the organizational registry. 2. Owners may assign deputies but they must be explicit and visible to any requester. 3. Ownership records are part of the scoping document and updated during change control.

Protocol 2: Naming and Discovery

Create an organizational DNS: a simple searchable registry that maps role names to people, permissions, and contact pathways. 2. Standardize role names across programmes so a single label always means the same authority. 3. Use the registry during onboarding and during scoping to avoid role collisions.

Protocol 3: Routing and Escalation

Maintain a routing table of decision rights: define which decisions are local, which are escalations, and who receives escalations. 2. Keep routing tables small and current; remove obsolete routes when responsibilities change. 3. Design routing for locality: empower teams to decide routine issues and route only exceptions to the PMO or governance board.

Protocol 4: Transport and Reliability

Use handshake rituals for every commitment: a short alignment, a written acknowledgement, and an acceptance test for the handoff. 2. Define retransmission policies: when does a missed acknowledgement trigger a follow up, an escalation, or reallocation of resources. 3. Keep packet sizes small by breaking scope into smaller, testable increments that can be confirmed quickly.

If these four protocols are in place your project behaves more like a robust network and less like a set of well intended but disconnected humans.

Concrete example: the DNS failure that broke a release

A software team prepared a major release with multiple dependencies across architecture, security, and operations. The PMO scheduled a final integration window and expected the security group to sign off on penetration test results. No single person was recorded as owner of the security sign off; three people had the title that sounded closest and each assumed someone else had the authority to approve. The result was the equivalent of a DNS collision: the release manager pinged the name but got no reliable address back.

The release stalled for several days. Teams retried the handoffs, meetings multiplied, and the integration window expired. Some stakeholders blamed the PMO for poor planning and others blamed the security team for slowness. The deeper failure was an absence of addressability and a missing handshake policy. If the organisation had used the Addressing and Transport protocols it would have identified a single security approver in the scoping doc and required a written acceptance before the release window was booked. A small change to the configuration would have prevented large delays.

Why PMOs often feel like slow routers

A PMO can add enormous value. It standardizes methods, aggregates metrics, and guides risk management. Yet many PMOs suffer from two related problems that make them appear ineffective. First, they are overloaded when scope increases but headcount shrinks. Second, they are undercredentialed when the surrounding organisation does not invest in training so only some practitioners understand or follow the protocols that the PMO expects.

When a router is overloaded its latency increases and it drops packets. When a PMO is overloaded it creates queues, generates meetings, and enforces uniform procedures that are either too heavy or ignored. When training is missing, methodology becomes a cosmetic label rather than a reliable transport protocol. The presence of a PMO is necessary but not sufficient. Configuration, capacity, and shared protocols matter more.

Key Takeaways

Create addressability for every important task and decision: one named owner, one accountable role, one visible deputy.
Build a simple organizational DNS: standardize role names and maintain a searchable registry that maps names to authority and contact paths.
Codify routing rules: document who decides what, where routine authority lies, and when to escalate to the PMO or governance.
Require transport rituals: handshake meetings, written acknowledgements, and explicit retransmission policies for missed commitments.
Measure throughput and capacity, not just headcount: if responsibilities grow while capacity shrinks, redesign flow or reduce packet size by splitting scope.

A closing reframing

Most interventions in project work aim at people, incentives, or tools. Those are important. But they miss a deeper lever: the configuration of the social network that moves commitments from intention to delivery. Thinking in terms of addresses, names, routes, and transport turns vague accountability into resolvable endpoints, converts repeated delays into predictable capacity problems, and transforms governance from gatekeeping into traffic engineering.

If you walk into your next project review and think like a network engineer you will ask different questions. Who resolves the name I just used? Where does this decision route if the owner is unavailable? What is our retransmission policy when an acceptance is missing? These questions sound technical but they reveal practical changes you can make today. In truth, reliable delivery is less about a heroic manager and more about a well configured system that knows where to send a message and how to confirm it arrived.

Reimagine the PMO as a router operator, not a policeman. Configure the organisation so that commitments have addresses, names resolve, routes are clear, and transport is reliable. When you do that projects stop behaving like fragile human chains and start behaving like engineered systems that tolerate failure and still deliver value.