Prioritizing Work and Making Decisions

Why Prioritization Is More Than Ranking Work

Prioritization is often treated as a ranking exercise. Identify the most important work, put it at the top, and move down the list. In practice, that is only the beginning, because priorities compete for the same people, budget, attention, and available time while also being constrained by dependencies. Choosing one project, feature, defect, or request means something else may move later, receive less capacity, or remain unresolved, so a priority is not meaningful unless the consequence of that choice is understood.

Urgency complicates this further, because urgent, important, and high priority are not interchangeable. Some work needs immediate attention because a delay would create real customer, operational, financial, contractual, regulatory, or dependency consequences. Other requests feel urgent mainly because someone wants something sooner. Project Managers and delivery leaders therefore have to make defensible choices among several legitimate considerations, often before every fact is available, without pretending that a ranked list or a loud stakeholder has made the decision for them.

Make the Tradeoff Visible

On a software client account I managed, the client had a fixed monthly retainer covering work across its marketing website and its customer facing product platform, with more legitimate requests than the available hours could support at once. Bugs, enhancements, marketing needs, and other requests all had reasons to move, so maintaining a dated priority queue was more than an organizational exercise. Every time something moved up, we had to recognize that something else might move back. That made the consequence of calling work a priority visible, rather than allowing everything to remain important at the same time.

That is the core of useful prioritization. Competing work has to be compared against the conditions that actually matter, including the value it is expected to provide, how time sensitive it really is, what happens if it waits, which dependencies it affects, and whether the people or budget needed to do it are available. Genuine urgency can justify changing the sequence. But a request does not become more important because someone labels it urgent, and adding another priority does not create additional capacity. The Project Manager’s role is often to expose those tradeoffs clearly enough that the person with the appropriate authority can make a deliberate choice, rather than allowing pressure or an unrealistic plan to determine what happens.

The same discipline applies when information is incomplete. A responsible decision does not require knowing everything, but it does require enough information to understand the likely consequences, the assumptions being made, and what could change the choice. Prioritization frameworks and scoring methods can help organize that comparison, but they cannot decide which tradeoff an organization should accept. An earlier decision should also be reconsidered when its underlying assumptions change enough to affect the decision.

Different Priorities Require Different Judgments

That broader comparison matters because different kinds of priority problems call for different judgments. Within a project, prioritization should begin with the outcome the work is supposed to produce. From there, the decision may be about sequencing, urgency, capacity, budget, a contractual or regulatory obligation, or whether the choice can reasonably wait. Treating all of those as the same ranking problem hides the reason something deserves priority in the first place.

The distinction becomes especially important when the consequences differ. A production defect affecting customers may deserve immediate attention even if it was not previously high on the roadmap. A regulatory requirement or critical dependency may need to override work with greater apparent business value because the cost of delay is much higher. In other cases, the right decision may be to protect limited resources for something more important later rather than spend them simply because work is available now. The useful questions are how valuable the work is, what happens if we do it, what happens if we do not, and what the decision prevents us from doing instead.

“A priority decision can look completely reasonable when it is made and still turn out to be wrong once the work gets underway.”

Budget can be a priority constraint in its own right. On a major utility account I managed while working at a digital agency, the client wanted to keep normal monthly spending within a lower range so that more of the available contract capacity remained for larger special projects, emergencies, and future initiatives. Leadership at my agency preferred higher monthly billable utilization, but that did not mean additional work needed to replace the technical work already underway. The competing priorities concerned how quickly the client’s budget should be consumed and what that budget should remain available to support later.

Strategic priorities can create a different kind of tradeoff. At another agency where I worked, I managed a luxury ecommerce program where the work was trending well beyond the budget the project had been planned around. I estimated the additional effort the remaining work would require and presented options for reducing scope, simplifying parts of the experience, or accepting the additional financial impact. Agency leadership chose to accept more of that financial impact in order to maintain the quality of the finished work. We still simplified some elements and deferred some functionality, but the balance clearly favored preserving most of the design and functionality over making deeper cuts to bring the work back within the original budget.

Incomplete information adds another layer of judgment, because waiting is also a decision. If a choice is low cost and easy to reverse, you can often make it with less information and adjust later. But if the decision is expensive, high impact, or difficult to undo, you may want to have stronger evidence before committing. That may sound obvious once it is stated, but it is easy to apply the same standard of certainty to every decision without considering how much certainty the particular decision requires.

Ultimately, the goal is to work out what information you need to decide responsibly and what information would only make you feel more certain. You also need to involve the people with the right expertise or authority, and be clear about which assumptions the decision depends on so you can revisit it if those assumptions change.

When Priority Systems Help or Distort the Work

The software client account described earlier shows what these distinctions look like once competing priorities have to be managed repeatedly. Its dated queue had to account for planned website and customer portal work, bugs, marketing requests, UX needs, and production issues, all competing for the same funded hours. When something new moved up, the practical choices were to delay something else, exceed the retainer budget, or borrow against future capacity.

That system did not eliminate conflict, but it made the conflict explicit. A production issue could deserve immediate attention because of its customer impact, while a marketing request could still be important without automatically becoming the next thing Engineering should do. The constraint stayed visible, so priority decisions had to account for both the value of the new request and the consequence for work already committed.

At a digital agency where I worked, I saw a different pattern at the portfolio level. Leadership paid close attention to utilization and billable hours, and when Engineering or Design capacity appeared available there was pressure to assign more work or pull future work forward. The problem was that available capacity did not necessarily mean there was work ready to use it. Work planned for later often depended on things that had not been completed yet, so starting it early could mean working at risk. Engineering might begin before Design was finished, or Design might begin before the requirements were fully worked out.

Utilization tells you whether capacity is being consumed, not whether the right work is moving effectively. Pulling more work into execution can increase the risk of rework or weaken throughput when dependencies are not ready, even while the organization appears busier. The software client account and the broader agency portfolio were part of the same delivery environment, but they illustrate different priority mechanics. On the client account, limited capacity forced explicit tradeoffs about what would move and what would wait. At the portfolio level, pressure to keep people utilized could push work forward before it was ready.

A Practical Way to Make the Call

That comparison changes how I approach the decision itself. When I am working through a priority choice, I first make sure the team is solving the right problem by being clear about the objective, the decision that needs to be made, and when it is needed. From there, I identify what kind of constraint is driving the choice, whether that is sequencing, urgency, capacity, budget, strategic value, an obligation, or simply the fact that a decision cannot wait for complete information.

Then I separate what is known from what is assumed and what is still unresolved. I look at mandatory commitments, dependencies, available capacity, customer or business impact, the consequences of delay, and the opportunity cost of choosing one option over another. The comparison should focus on what matters to that decision rather than every possible factor. It should also look at both sides of the tradeoff, including what could happen if the work moves forward and what could happen if it waits.

“A request does not become more important because someone labels it urgent, and adding another priority does not create additional capacity.”

Uncertainty changes how much evidence I need, but it does not automatically justify delaying the decision. A choice that is hard to reverse and carries significant downside deserves more investigation than a reversible decision where the team can learn and adjust as it goes. I also separate the information required for a responsible decision from information that would simply make everyone more comfortable. And I make sure the people with the relevant expertise are involved and that the person with authority to make the final call is clear.

Once the choice is made, I want the consequence to be explicit. If one item moves forward, the team should understand what is being delayed, what risk is being accepted, and what new information would cause us to reconsider the decision. When the tradeoff exceeds my authority, available capacity, or the team’s ability to resolve competing commitments, I escalate it rather than pretending the conflict has disappeared.

How to Tell Whether Prioritization Is Working

A priority decision can look completely reasonable when it is made and still turn out to be wrong once the work gets underway. That is why I would not judge prioritization by whether the backlog is neatly ranked, decisions are made quickly, or everyone is fully utilized. Those things tell you what was planned, decided, or consumed. They do not tell you whether the choices are helping the work move.

The agency portfolio example from earlier made that distinction clear. People could appear fully utilized while dependencies were still unresolved or future work was being started before it was ready. In that situation, the utilization number might look healthy while the delivery system was creating more risk. I would pay more attention to patterns such as constant priority changes, unresolved dependencies, repeated context switching, recurring emergencies, work starting before it is ready, and important decisions taking too long. Those are signs that the priorities on paper may not be holding up once they meet the realities of delivery.

Over time, the stronger test is what those decisions produce. Are important commitments being met more reliably? Are avoidable delays becoming less common? Are customer and operational problems being reduced? Is the work producing the value it was supposed to produce? Even good results do not prove that every earlier decision was optimal, and the Project Manager does not control every business outcome. But if the same prioritization approach repeatedly produces instability, missed commitments, and preventable delays, that is evidence worth taking seriously.

Good Prioritization Makes the Consequences Visible

The hardest part of prioritization is rarely deciding which item belongs at the top of a list. It is deciding what you are willing to delay, what risk you are willing to accept, and what you are choosing not to do with limited time, money, and attention. Those consequences exist whether they are acknowledged or not.

Good prioritization makes them visible enough that the right people can make the choice deliberately. The decision does not have to be perfect, and it may need to change when new information appears. What matters is that the tradeoff is understood, the assumptions are clear, and the organization knows what it is choosing and what that choice costs.