Efficient at the Wrong Things

The meeting had been running for forty minutes, and nothing about the organization's actual situation had come up.

The time went to status updates and milestone completions, with RAG ratings across eighteen active projects. Every report was accurate. Every project was being managed. And none of it touched what the leadership team actually needed to understand. A competitor had just announced a product move that changed three assumptions the current portfolio was built on. Nobody had named it yet, because it was not on the agenda.

Drucker identified this failure decades ago. Efficiency is doing things right. Effectiveness is doing the right things. One of the most dangerous failures I have seen in enterprise leadership is becoming highly efficient at the wrong things. The efficiency hides the misalignment until the consequences are too large to ignore.

The Readiness Gap belongs to the whole enterprise, not to any single function. But a gap is easier to see in one place than everywhere at once. The Project Management Office makes a useful running example because it often sits where strategic commitments turn into delivery. So Part I uses the PMO as a case study in miniature. If you have never worked near one, read it as a question about any function built to coordinate work: what preparation should exist before a coordinated response is required?

Before I tell you what I think the PMO can become, I want you to reconsider something you probably already believe: that the PMO exists to deliver projects. The belief is understandable. The PMO was designed to improve delivery. Many maturity models emphasize delivery capability, and many certifications validate delivery skills.

Across more than two decades of enterprise leadership, I saw PMOs judged on one main question: did they help the organization deliver more reliably than before? Usually the answer was yes. PMOs deliver, and that matters. But a different question stayed with me, one that delivery performance could not answer: why do organizations with highly mature PMOs still struggle to execute strategy?

The Project Management Institute's ongoing Pulse of the Profession research has documented that delivery maturity alone does not guarantee that initiatives produce their intended strategic outcomes. This book locates one relevant gap upstream of delivery. The argument is not that project management is insufficient or that projects are unimportant; projects are often how organizations respond to strategic demands. In the organizations I worked in, the PMO improved delivery while the preparation for a cross-functional response got less attention.

In those organizations, the PMO was measured mainly on doing things right: on-time delivery, budget variance, and methodology compliance. Those measures did not always ask whether the work still fit the strategy. A PMO could report on-time delivery above ninety percent, budget variance under three percent, and strong compliance. At the same time, the organization could still struggle to produce the outcomes its portfolio was meant to deliver. The dashboards were impressive. The outcomes were not.

When I traced the pattern back to the executive team, it matched what I had seen many times before. The PMO was good at answering, "Are we delivering what we planned?" It had no shared way to ask, "Is what we planned still what we should be doing, given what has changed?" That is not a failure of project management. It is a question about what the function is expected to produce.

Roger Martin and A.G. Lafley describe strategy as a set of integrated choices about "where to play" and "how to win." A function built entirely for delivery answers neither question while believing it is doing its most important work.

The reactive PMO defines success by delivery metrics. Those numbers tell leadership what is happening with the work. They say almost nothing about whether the organization is becoming more capable of executing the strategy it has committed to.

The ready PMO defines success by organizational capability. Does the executive team share an understanding of the Strategic Situations it is managing? Are the decisions only executives can make being made at the right time? Can a response deploy in hours instead of being assembled over weeks? Is each situation teaching the organization something that permanently improves its readiness? Those are different questions, and they require a different function. You cannot build it by adding rigor or governance to a delivery-focused PMO. It takes a fundamental change in what the PMO believes it exists to do.

The counterargument I hear most often: if the PMO stops focusing on delivery, who manages delivery? Delivery stays important. Projects still need managing, portfolios still need prioritizing, and governance still has to work. The question is whether delivery is the main measure of the function's value, or one activity serving a larger purpose.

Consider finance. Finance processes transactions and produces financial statements, but the CFO is not measured on whether the accounts were reconciled on time. The CFO is measured on whether the enterprise's financial health is being actively managed, protected, and developed. The PMO should work the same way.

Project management is necessary. It is not the purpose. The purpose is larger: making sure understanding, alignment, preparation, and learning are built into the organization before any project begins.

I spent years inside organizations that could not make this shift. Their PMOs had defined their value entirely around delivery metrics, which left them exposed to the next delivery failure and unable to build the capability that would have prevented it. The PMOs I built that made a lasting difference measured themselves by different questions. Each was a version of Drucker's point about effectiveness: an organization can be extraordinarily efficient at work that does not produce what it needs.

The PMO that asks delivery questions will matter less as artificial intelligence takes over the administrative work project management has always required. The PMO that asks capability questions will matter more as the cost of poor preparation compounds. One is building toward a future that needs it. The other is defending a past that is being automated.

Alignment Is the Purpose

There is a question I began asking in every organization I was brought in to lead, usually in the first week. I asked PMO leaders, executives who owned major initiatives, and the people doing the coordination work: why does this function exist?

The answers were almost always correct and almost always incomplete. They described what the function did, not what it was designed to produce. That gap is where most of the dysfunction I diagnosed over two decades lived.

It is the gap Drucker warned about. The first question to ask about any function is not what it does but what it is supposed to accomplish. What contribution does it make that no other function makes? Not which tasks would disappear if it vanished, but which organizational capability would.

When I asked that about PMOs, the answer kept coming back the same. Delivery capability lived in the project teams, the technical functions, and the business units. The PMO's distinctive contribution was something they could not produce for themselves: the integrated view across all of the organization's commitments. From there the PMO could see where those commitments conflicted or reinforced each other, and it could drive the leadership conversations those conflicts required. The PMO's purpose was alignment. Not agreement.

Confusing the two has caused more organizational dysfunction than almost any management concept I know. Agreement is people sharing the same opinion before a decision is made. When a leadership team faces a hard strategic choice, unanimous agreement beforehand often means someone is not being honest, or the decision is not actually hard. Healthy decision-making surfaces competing views and examines them before committing.

Alignment is what should exist after the decision. People who argued different positions commit to a shared direction and coordinate their actions toward it. You can have alignment without agreement, and the situations that need alignment most are the ones where genuine agreement is least likely: decisions that trade off legitimate competing interests.

I watched this failure get expensive in a transformation I led inside one large organization. The executive team made a controversial decision about a major technology implementation and left what looked like a productive meeting. Three months later the implementation had fragmented, because each function had mapped the same decision onto its own mental model. Chapter 2 looks at the communication failure behind this pattern through other organizations: a decision can be communicated without being interpreted together.

In one organization I led, the PMO was the only function working regularly with all five executive teams. It saw these conflicts before they reached executive governance; project managers were flagging issues weeks ahead. The function had real pattern recognition but no authority to act on what it saw. That experience points to one valuable PMO contribution: closing the distance between decision and execution. The PMO does that by helping leaders interpret the decision together, surfacing conflicts between functions, and building the shared understanding execution requires. Its cross-functional view made it useful there, though another structure could provide the same view elsewhere.

I have also watched the success mode, and it looks nothing like better people. I have seen it hold in several organizations across different industries, and what made it work was never the specific decision. It was the architecture the organization had built before the decision was needed. These were leadership teams in real disagreement, with senior leaders holding positions on strategy, resources, or direction that no single decision could satisfy. Where those disagreements still produced coherent execution, the leaders were not better at compromise or more mature. The organization had designed for this.

Decision rights were explicit before the disagreement arrived. Everyone in the room knew who would make the call when consensus was not possible. Accountability was public: outcomes were tracked against the decision, and the decision was tracked against who made it. And information flowed honestly enough that the person making the call worked from an accurate picture, not a curated one.

When those conditions exist, disagreement changes. People argue more candidly because they know the argument has a defined endpoint. Commitment after the decision is real, not diplomatic, because quiet non-compliance becomes visible. The leader who made the call knows the outcome will be measured against it, which sharpens the decision. The leaders who disagreed know they are accountable to the outcome, not to the agreement, which makes their commitment professional rather than personal.

Patrick Lencioni argues that organizational health, not raw intelligence, is the greatest untapped advantage. That is this chapter's point in other words: alignment is built into how a leadership team decides and commits, not into how clever its members are. What I saw in these organizations was not better people or a stronger culture, though both were present. It was better architecture. Disagreement, decision, and commitment each had a defined structure, and the people worked inside a system that made coherent execution more natural than fragmented execution.

Where I saw it fail, it almost always failed the same way. Decision rights were ambiguous, so the person who believed they had authority and the person who actually had it both moved after the meeting. Accountability was opaque, so non-compliance stayed invisible until it was expensive. Information was curated, so the decision was made against an incomplete picture.

Notice what this means for you as a leader. The split decision that held was not held together by the quality of the leaders. It was held together by the quality of the system they worked inside. Good systems make good leadership more consistent. Weak systems make good leadership more heroic, and more fragile. The decision held not because the leaders agreed, but because the architecture was built before the disagreement arrived.

This changes what the PMO does in every meeting it runs. A steering committee designed to inform runs through status and adjourns with leaders informed and alignment no closer. A steering committee designed to align opens with a different question. "Since our last meeting, has the Strategic Situation we are responding to changed in any way that requires us to reconsider our approach?" Then it organizes around what the organization is learning. Its job is not to report. It is to make misalignment visible before execution reveals it.

Drucker also argued that a purpose must be simple enough to state in a sentence and specific enough to act on; otherwise it is only an aspiration. Stated that way, the PMO's purpose is to create the conditions under which the organization can turn strategic decisions into coordinated action.

Governance that builds shared understanding before important decisions serves that purpose. Governance that enforces methodology compliance serves another. A PMO can carry both, but its capacity is finite, so its priorities matter. In PMOs I led, people sometimes described the purpose as "deliver projects more reliably." I wanted more than that: an organization that could think together, decide together, and move as one. The gap between those two answers is what made the larger preparation question visible. A PMO's cross-functional view makes it a useful lens for that work, though not the only place it can live. ---