Resolving Project Prioritization Conflicts Without Going to the CEO

Here is the project prioritization conflict every PMO eventually faces. Two projects are competing for the same senior engineer. Both project managers believe their project is the portfolio's highest priority. Both sponsors agree with their respective PM. The PMO lead gets pulled into a conversation that starts as "can you look at the resource allocation" and ends, two weeks later, with someone's calendar showing a meeting with the CEO to sort it out.

The escalation to the CEO was not forced by the complexity of the conflict. It was forced by the absence of a protocol for resolving it earlier. The two PMs did not have access to the same portfolio information. There was no established priority ranking the PMO could point to. The PMO lead had no clear authority to make the call. So the conflict rose until it reached someone with enough authority to impose a resolution, which is the organizational equivalent of bypassing the fuse and running current directly through the wire.

Project prioritization conflict is the natural output of a portfolio without explicit priority architecture. It is not a people problem. The PMs are doing exactly what they should do: advocating for the projects they are accountable for. The problem is that the PMO has not given them the shared context and criteria that would let the conflict resolve at a lower level.

TL;DR. Most project priority conflicts are not actually disagreements about priority. They are information deficits: the two PMs do not have the same view of the portfolio, the same criteria for what priority means, or the same visibility into what the other project is carrying. A three-step protocol (surface the constraint, apply portfolio criteria, make the decision visible before the resource commits) resolves the majority of conflicts without escalation. The infrastructure that makes the protocol work is a portfolio priority register maintained by the PMO.

Why project prioritization conflicts escalate

Three failure modes push priority conflicts upward.

No shared priority criteria. When each PM and sponsor defines priority according to their own frame (strategic importance to their business unit, urgency of the deadline, revenue at stake), two projects can both be legitimately "highest priority" by different measures. There is no way to resolve that conflict without first agreeing on the measure. If the PMO has not established shared criteria before the conflict arrives, the conflict cannot be resolved at the PMO level.

No portfolio visibility. The PM on Project A does not know what Project B is carrying. They do not know that Project B is three weeks from a critical deadline, that its sponsor is the CFO, or that losing the same senior engineer for two weeks would push it into a contractual penalty window. Without that information, the PM on Project A is not being unreasonable by pushing hard. They are optimizing with incomplete information. Providing that information is a PMO function, not something that should wait until a conflict forces it.

The PMO lead avoids the decision. The most common failure mode: the PMO lead tries to facilitate a conversation between the two PMs rather than making the call. Facilitation is appropriate when both parties need to understand each other's perspective. It is not appropriate when the PMO has the information and authority to make the decision and is instead using process to defer a call they own. When the PMO lead asks "what do the two of you think?" instead of "here is how the portfolio priority register scores this," the conflict continues and the next step is escalation.

The root cause: most priority conflicts are information deficits

Across the majority of priority conflicts that reach PMO escalation, the core problem is not that the two projects are genuinely tied in strategic priority. It is that neither party has enough information to see that they are not tied.

When both parties have full portfolio information, including the other project's deadline dependencies, resource situation, strategic score, and sponsor commitment, about two-thirds of apparent conflicts resolve themselves. One project is clearly higher priority by the shared criteria, and the PM on the lower-priority project recognizes it when they see the full picture.

The remaining third involves genuine conflicts where both projects are approximately equal in priority and the resource constraint is real. Those conflicts need a decision, not just better information. The PMO lead makes that decision using the portfolio priority register as the basis, and surfaces it to both sponsors simultaneously.

The resource heatmap tool is useful here because it makes the resource constraint concrete before the conflict conversation starts. When the PMO lead can show both PMs the current resource allocation across the portfolio, the conversation shifts from "my project needs this engineer" to "there are three projects competing for this engineer and here is the full picture."

Step 1: Surface the actual constraint

Before applying priority criteria, identify what is actually being contested. Most priority conflicts are framed as project-level conflicts ("my project is more important than your project") when they are actually resource-level conflicts ("we both need this engineer for the next three weeks").

The PMO lead's first question is not "which project is higher priority?" It is "what specifically cannot happen on each project if the shared resource goes to the other?" This question often reveals that the constraint is narrower than the conflict suggests. Project A needs the senior engineer for architecture review on a specific component. Project B needs them for a client demo. The engineer can do the architecture review on Tuesday and Wednesday and the demo prep on Thursday. The conflict was framed as an either-or when the actual resource conflict was about eight specific hours.

This happens in approximately a third of priority conflicts. The conflict was not about priority at all. It was about scheduling. Resolving it required only visibility into both projects' actual resource needs, not a portfolio priority decision.

When the constraint is genuinely exclusive (the engineer cannot do both, in either order, within the available time), surface that clearly. "Project A needs this engineer full-time for twelve days starting Monday. Project B needs them for six days starting the same date. There is a real conflict here, and it requires a priority decision."

The diagram below shows the three-step protocol for resolving a priority conflict before it reaches executive escalation.

Step 2: Apply the portfolio priority criteria

When the conflict is a genuine resource contest, the PMO needs a scoring basis that is not invented in the moment. The portfolio priority register provides that.

The register is a living document that ranks every active project against four criteria: strategic alignment (how directly does this project serve the organization's current priorities), delivery risk (what happens to the portfolio if this project slips), dependency level (how many other projects or operational functions depend on this project's completion), and ROI or value delivery timeline (when does the value land and what is the cost of delay).

Each project gets a score on each dimension, using whatever scale the PMO defines (a simple 1-3-9 scale works for most PMOs). The scores are calculated at project initiation and updated quarterly. When a conflict arrives, the PMO lead pulls the register, finds both projects, and compares their scores on the specific dimensions most relevant to the conflict.

A project that scores highest on delivery risk and dependency level takes priority in a resource conflict, because a slip creates the most downstream damage. A project that scores highest on ROI timeline takes priority when the contested resource is needed to hit a value-delivery milestone. The criteria are not always determinative, but they make the decision grounded rather than arbitrary.

Two important constraints on this process. The register scores must be calculated before the conflict arrives: scores calculated during the conflict are influenced by the outcome the scorer wants. And both PMs must have access to the register, not just the PMO lead. When the PM on the lower-priority project can see the register and understands how their project scores relative to the other one, the conflict is substantially easier to close. They are not conceding to arbitrary PMO authority. They are conceding to criteria their own project agreed to at initiation.

The PMO maturity tiers framework identifies portfolio priority management as a characteristic of mature PMOs, and the absence of a priority register as a distinguishing feature of reactive ones. Reactive PMOs resolve every priority conflict individually, using different criteria each time, and the organization loses confidence in the PMO's judgment because the decisions are not explainable.

Step 3: Make the decision visible before the resource commits

The third step is the one most PMO leads skip: telling both sponsors the decision simultaneously, in writing, before the resource allocation is executed.

This does two things. It prevents the losing sponsor from learning about the decision from their PM after the fact, which always feels worse than learning it directly. And it gives both sponsors a brief window to appeal the decision if they have information the PMO lead did not have (a client commitment that wasn't in the project file, a deadline that moved) before the resource is committed and the conflict is closed.

The communication is brief. "Project A and Project B both required [engineer] for [date range]. Based on the portfolio priority register, Project A's delivery risk score (9) and dependency level (9) exceed Project B's (3 and 3, respectively), so [engineer] is allocated to Project A for [date range]. Project B's PM is aware and has been offered [alternative]. If you have information that changes this analysis, please flag it by [date] before the allocation is confirmed."

That communication is not an invitation to relitigate the decision. It is the PMO lead documenting their reasoning, giving sponsors a narrow window to surface new information, and closing the decision with both parties informed. Sponsors who receive that communication understand that the PMO lead made the call with explicit criteria and documented reasoning. They may disagree. They rarely take it to the CEO.

When escalation is the correct answer

The three-step protocol resolves most priority conflicts. It does not resolve all of them.

When two projects have equal scores on the priority register, when the conflict involves a business commitment the PMO lead does not have authority to adjudicate, or when the conflict requires a decision about organizational priorities that is genuinely above the PMO's pay grade, escalation is the right call. The difference between appropriate escalation and escalation as conflict avoidance is whether the PMO lead has done steps one and two before going upward.

When the PMO lead escalates after steps one and two, they bring a specific decision with specific criteria, a specific constraint, and a specific recommendation. "Project A and Project B are genuinely tied on the priority register. The constraint is [engineer] for [date range]. Both sponsors have seen the analysis. My recommendation is Project A based on [specific criterion], but both options carry [specific cost]. I need your authority to make this call." That is an escalation the CEO or executive team can resolve in fifteen minutes.

When the PMO lead escalates without steps one and two, they bring a conflict. "The two PMs both believe their project is highest priority and they are both asking for [engineer] at the same time." That is not a decision the CEO can make efficiently. It becomes a meeting, then a follow-up, then another meeting, then a precedent that trains the whole organization to escalate priority conflicts to the top rather than to the PMO.

The escalation framework for project managers defines when issues should move upward and at what level they belong. The same logic applies to PMO-level priority decisions: escalate when you lack the information or the authority, not when you lack the willingness to make the call.

Building the PMO as the adjudicator, not the messenger

The long-term goal is not to resolve individual priority conflicts more efficiently. It is to build the PMO's reputation as the place where priority questions are answered, so that PMs stop taking them directly to executive sponsors.

That reputation is built by two behaviors. The first: making clear, documented priority decisions quickly. When the PMO lead applies the protocol and issues a decision within 48 hours, with reasoning the sponsors can see, the organization learns that PMO involvement produces resolution rather than process. The second: enforcing the decisions. A priority decision that gets quietly overridden by a sponsor's informal conversation with the functional manager teaches the organization that PMO decisions are advisory. Once that lesson is learned, every priority conflict goes around the PMO to the sponsor directly, which is the situation the protocol was designed to prevent.

The PMO Maturity Assessment includes portfolio priority management as one of twenty governance dimensions. PMOs that score poorly on it typically have two patterns: no priority register, and a PMO lead who mediates rather than adjudicates. PMOs that score well on it have both a maintained register and a PMO lead who makes the call, documents the reasoning, and tells both sponsors simultaneously before the resource commits.

Run the free PMO Maturity Assessment Twenty questions about how your PMO handles priority decisions, resource allocation, and portfolio governance. Get a structured profile of where your function stands in about ten minutes. No signup required. → Open the assessment