How to prioritize tasks in project management: the 90-minute framework

To prioritize tasks in project management, run a single 90-minute session: dump every task into one list, score each on deadline pressure, dependency position, and effort-to-impact, then rank them into a backlog you re-score on a fixed cadence. This article walks that framework end to end, including a fully scored 14-task backlog with real numbers and trade-off arguments.

How do you decide which project tasks to prioritize first?

Score every task against four criteria: deadline pressure, dependency position, impact, and effort. A task that scores high on only one of these — say, a stakeholder calling it urgent — will outrank work that actually unblocks three other people. That is how backlogs fill with noise.

Why one-method frameworks fail once you juggle 3+ projects

The Eisenhower matrix sorts by urgency and importance, which works for a single inbox. Across multiple projects it collapses: everything is urgent, "important" becomes a matter of who asked loudest, and dependencies between projects are invisible. Ops leads juggling expense approvals, onboarding, and device rollouts need one score, not four quadrants per project. Tools like Asana and ClickUp offer priority fields, but the field is only as honest as the scoring behind it — see how they compare at Task22 vs Asana.

The four scoring criteria in one pass

• Deadline pressure — What breaks, and when, if this slips? Score 1–5.
• Dependency position — How many tasks are blocked until this is done? Score 1–5.
• Impact — How much outcome value per completion? Score 1–5.
• Effort — How much work does it take? Score 1–5 (inverted).

Weight them to fit your context — deadline-heavy ops work often weights pressure and dependencies above impact.

What does a 90-minute prioritization session look like, step by step?

Step 1: Dump and dedupe (15 min)

Write every task into one list. Pull from email, chat threads, spreadsheets, and stakeholder requests. Remove exact duplicates and merge near-duplicates that describe the same work. You should end up with raw tasks, not organized categories.

Step 2: Score each task (30 min)

Rate every task on impact (1-5) and effort (1-5). Divide impact by effort for a priority score. Tasks scoring above 1.0 go to the top. This is where you decide how to prioritize tasks project management work demands. See Task22 pricing for tool costs if you want scoring automated.

Step 3: Fix dependency inversions (20 min)

Look for tasks blocked by other unscheduled tasks. If Task B depends on Task A, but A sits lower in your ranked list, move A above B. Dependency chains override raw scores because blocked work cannot start.

Step 4: Publish and commit (15 min)

Share the ranked backlog with stakeholders. Post it where the team already works rather than a new tool. Commit to the top items for the next sprint or week. Reopen scoring only when new tasks arrive or scope shifts.

Worked example: scoring a real-shaped 14-task backlog

The raw backlog and first-pass scores

You're running two projects: an office relocation (12 weeks out) and a vendor onboarding program (6 weeks out). Fourteen tasks total. Score each on impact (1-5), effort (1-5), and deadline pressure (1-5). A first pass might look like this: "Order new desks" scores impact 3, effort 2, deadline 5. "Draft vendor approval workflow" scores impact 4, effort 3, deadline 4. "Update the org chart slide" scores impact 1, effort 1, deadline 2.

Where the scores get argued and changed

The raw scores are a starting point, not the answer. The desk order looks low-impact until you check dependencies: it blocks lease fit-out sign-off, internet installation scheduling, mover booking, floor plan confirmation, and the employee move-day briefing. That's five blocked tasks, so you add a dependency multiplier of +2 to its impact, taking it to 5. This is the step most teams skip, and it's why low-impact-looking work quietly sits at the bottom of a backlog while everything behind it stalls.

The same logic applies in reverse: "Research catering options" blocks nothing and can slip a week without consequence, so its deadline score drops from 3 to 2. Run every task through the dependency check before you rank anything, because a task's queue position is a property of the chain it sits in, not the task itself. This is also the honest limitation of any scoring exercise, including one run inside a tool like Task22: the numbers are only as good as the dependency map behind them, and that map lives in your head until you write it down. If your current tool makes mapping dependencies harder than remembering them, that's a switching signal worth acting on; start a conversation with us if you want help pressure-testing your setup.

The final ranked list and what got cut

After adjustments, the ranked top five: vendor approval workflow (14 points), desk order with dependency boost (12), mover booking (11), lease fit-out sign-off (10), payroll cutoff alignment for new vendors (9). Cut or deferred: the org chart slide, catering research, and two nice-to-have process docs. Everything cut gets a revisit date tied to your re-prioritization cadence rather than deleted, which keeps stakeholder conversations honest. Teams that document this kind of tradeoff visibly spend less time relitigating priorities later, a pattern consistent with guidance on transparent prioritization from PMI.

How do dependencies between tasks change prioritization order?

A task's priority isn't just its own score. It inherits from everything downstream: if three high-impact tasks are blocked by one low-impact task, that blocker's effective priority is the sum of what it unblocks. We call this blocker-count scoring, and it takes one pass through your dependency map.

Scoring a task by what it unblocks

For each task, count the scored tasks that depend on it. Add their impact scores to its own. In the worked example's 14-task backlog, the vendor contract (effort-to-impact score of 4) sits upstream of both the equipment delivery chain and the onboarding chain, adding roughly 20 points of inherited priority. It jumps from mid-pack to the top five.

When a 'low priority' task becomes urgent

The reverse matters too. A task scoring 2 on its own can sit at the head of a chain feeding a hard deadline. Its effective priority is the downstream deadline minus the lead time it controls. Flag these in your backlog so they don't get deferred in a weekly triage. We cover chain maintenance in more depth on the Task22 blog.

When should you use MoSCoW versus impact-effort scoring?

Use MoSCoW when you are negotiating scope with stakeholders against a fixed deadline. Use impact-effort when you are sequencing your own team's execution work. Pick one per backlog.

MoSCoW for stakeholder scope conversations

MoSCoW forces a must/should/could/won't conversation, which is exactly what you need when requirements shift mid-project and nobody agrees on what was originally in scope (a common complaint on r/projectmanagement). Its weakness is that everything drifts toward "must" unless you cap the musts. Atlassian's agile guide covers the method's basics if your team has never run it.

Impact-effort for sequencing execution

Impact-effort scoring is a planning tool, not a negotiation tool: it ranks work by value against effort so your team knows what to build first. It fails with stakeholders because "impact" is subjective and invites lobbying.

Running both on the same backlog creates two competing rankings and the arguments that follow. We keep one scoring layer per backlog at Task22 for that reason, and it is also why tools like ClickUp or Asana make you choose a single primary sort.

How do you prioritize tasks when every stakeholder says theirs is urgent?

The fix is to depersonalize the fight. Publish the scoring criteria before intake opens, have stakeholders score their own requests against it, and let the resulting ranked list arbitrate instead of your judgment. When the list outranks someone's request, you are delivering bad news from a process, not from a person.

Publish criteria before intake, not after

Announce the impact-effort scale and deadline rules before anyone submits. Criteria set after intake look like a verdict engineered to reject specific requests. A published rubric also kills scope creep at the door: anything outside the stated criteria is out of scope by definition, not by your discretion.

Make the requester score their own request

Ask each stakeholder to score their own task for impact, effort, and deadline pressure before it enters the backlog. Two things happen. Requesters rarely score their own work as low-impact, so the inflated scores become visible and comparable. And once someone has scored their request, they have accepted the framework, which makes the published ranked list much harder to argue with in your next stakeholder meeting.

How often should a project backlog be re-prioritized?

Run a full re-score of the backlog monthly, check dependency chains weekly, and keep a separate exception path for genuine emergencies. Anything more frequent and you're re-ranking instead of working, which is exactly the overhead that makes people spend more time managing the software than doing the work.

Monthly full re-score, weekly dependency check

Once a month, re-run your impact-effort scores with fresh data: shifted deadlines, new stakeholder requests, completed dependencies. Weekly, do a 15-minute pass that only checks whether dependency chains have broken, since a blocked predecessor can invalidate the top of your ranked list without changing any scores. The Project Management Institute's guidance on iterative planning supports this rhythm of regular replanning over constant reshuffling.

The emergency exception path

When something genuinely urgent lands, slot it above the current top item without re-scoring anything else, log it, and let the monthly session absorb the disruption. If exceptions happen more than once or twice a month, that's scope creep wearing an urgency costume, and it belongs in the re-score, not the backlog.

How does time management fit into task prioritization for project managers?

A ranked backlog without calendar allocation is a wish list. Prioritization tells you the order; time management tells you whether the top of the list can actually ship this week.

Match the ranked list to actual weekly capacity

Take your ranked list and check it against real hours: your own, plus anyone executing the work. If the top five tasks need 30 hours and you have 11 uncommitted hours, the list is fiction. Cut scope at the ranking stage, not mid-sprint, or you end up reacting again, which is the exact failure mode this framework exists to prevent.

Protect execution time from the organizing time trap

The ops leads we hear from spend more time tweaking systems than doing the work. Budget the organizing itself: one 90-minute prioritization session per week, one 15-minute re-rank midweek, nothing else. Block the remaining hours as focus time against the top-ranked tasks, and treat tool admin as a task that gets scored like any other. If maintaining the system outranks shipping, the system is overhead.

FAQ

How do you prioritize tasks when everything is urgent?

Stop arguing about urgency and score instead. Rate each task on deadline pressure, dependency position, impact, and effort, then rank by the results. Publish the criteria before intake so stakeholders score their own requests. When the ranked list outranks someone's task, the bad news comes from a process, not from you.

What is the best method to prioritize tasks in project management?

Match the method to the situation. Use MoSCoW when negotiating scope with stakeholders against a fixed deadline, and impact-effort scoring when sequencing your own team's execution work. Pick one scoring layer per backlog. Running both creates two competing rankings and the arguments that follow them.

How do you prioritize tasks with dependencies?

Score each task by what it unblocks, not just its own merit. Count the scored tasks that depend on it and add their impact to its own. A low-scoring blocker at the head of a chain feeding a hard deadline inherits the downstream deadline minus its lead time. Check chains weekly.

How often should you re-prioritize a project backlog?

Run a full re-score monthly, a 15-minute dependency-chain check weekly, and keep an exception path for genuine emergencies: slot the urgent item above the top, log it, and let the monthly session absorb it. If exceptions exceed one or two a month, that is scope creep, not urgency.

How do you prioritize tasks across multiple projects?

Pull every task from all projects into one list and score it against shared criteria, because urgency stops meaning anything when everything is urgent. Dependencies between projects stay visible in a single backlog. Fix inversions by moving blockers above the tasks they gate, then publish one ranked list rather than per-project queues.