In your business role, do you find prioritising projects difficult? That’s the question I asked on Twitter last week, expecting a landslide of exasperated sighs and virtual nodding. What I got was far more interesting—and mildly alarming. Only 19% of people said yes. A comfortable majority (55.2%) proudly responded no, while a rather telling 25.7% admitted they’d never really thought about it. Another survey followed: “Does your team often struggle to deliver impact due to limited resources, tight deadlines, or being spread too thin?” This time, 37.7% confessed it was a problem. It made me realise how few people actually know how to prioritise projects in a way that truly aligns with their team’s capacity and business goals.
So let’s talk about that. Because I’m convinced the issue isn’t that people don’t know how to prioritise projects. It’s that they think they’re doing it right, when in fact they’re winging it with just enough polish to look convincing.
I’ve worked with enough teams and execs to spot the signs. The leadership sessions where everyone brings their shiny project ideas, and somehow, they all make the cut. The meeting ends with a roadmap that’s more wish list than strategy. Three months later? Half the team is burnt out, a third of the initiatives have stalled, and someone’s still fiddling with that internal podcast pilot that no one asked for.
It’s not the ideas that are the problem. It’s the decision-making—or lack thereof. Knowing how to prioritise projects is about being brutally honest about trade-offs. Saying no to good ideas in favour of the right ones. And having the guts to stand by those decisions.
I’ve seen the whole spectrum. The gut-feel approach, where someone scans the backlog and decides what’s hot based on mood and coffee strength. The client-led chaos, where whatever’s loudest or most urgent gets done next—even if it derails everything else. And, of course, the spreadsheet monks, who’ve built a six-tab scoring matrix that outputs a project priority index with decimals. Lovely in theory. Useless once the market moves.
Learning how to prioritise projects starts with admitting a few things. First, we can’t do it all. Every time we say yes to something, we’re quietly saying no to something else. Usually without telling anyone. That new automation project might be a win, but if it eats into your support team’s bandwidth, don’t act surprised when your churn rate ticks up.
Second, urgency isn’t a reliable compass. The thing that’s screaming loudest isn’t always the thing that matters most. Putting out a small fire can feel productive. But sometimes it’s better to let it smoulder while you deal with the big picture stuff that actually shapes your next quarter.
Third, prioritisation isn’t heroic. It’s not the genius move of a lone PM or a spreadsheet whisperer. It’s a team game—and a messy one. It involves listening, compromise, and—shock horror—saying no to things people are emotionally invested in.
So how do I approach it now? It’s more art than science, but I ask a few simple, uncomfortable questions:
What are we actually solving here, and who genuinely cares about the outcome? If the answer’s vague or broad, it’s probably a vanity play.
What happens if we don’t do it? If no one’s life is worse and the business doesn’t wobble, maybe it can wait.
Where does this sit against the other ten things we already said were top priority? Spoiler: they can’t all be top.
Can we execute it properly, right now? If the answer involves borrowing people from three departments and a unicorn who knows legacy code, the answer is no.
Who owns this? If everyone’s excited but no one wants to lead, it’s a hobby project in disguise.
Still, asking tough questions isn’t always enough. Sometimes you need a bit of structure to keep your thinking honest. I’ve had mixed luck with frameworks, but a few have stood the test:
There’s ICE—Impact, Confidence, Ease. It’s the scrappier cousin of RICE and good when you’re moving quickly. I use it when I don’t have the time (or patience) for deep scoring sessions. The trick is not to overthink it. You’re looking for relative weight, not scientific precision. Great for MVPs, sprint planning, or when your team’s just trying to get traction.
ICE Example Scenario
ICE Score = Impact x Confidence x Ease
Then there’s RICE—Reach, Impact, Confidence, and Effort. It’s not perfect, but it gets you to slow down and quantify things before blindly charging ahead. I’ve used it to rank product features, internal initiatives, even which marketing experiments to keep funding. It’s especially handy when you’ve got a lot of data and a bit of time to think. Good for product teams and medium-sized bets where you need justification for saying yes (or no).
The MoSCoW method—Must, Should, Could, Won’t—is another one. It forces teams to admit that not everything can be a must. I’ve run workshops where we’ve MoSCoW’d entire roadmaps and ended up with half the list under “Could,” and it was a huge relief. Ideal for stakeholder sessions and for managing expectations during planning phases when everyone believes their project is critical.
And finally, the Eisenhower Matrix. Simple but effective: urgent vs important. Anything that’s neither? Toss it. I’ve used it as a reality check when my week starts looking like a to-do list written by an anxious octopus. Brilliant for personal prioritisation or helping execs who are stuck in reactive mode. It brings a much-needed lens of perspective.
The hard bit isn’t choosing—it’s defending the choice. Especially when someone’s favourite idea gets cut. But if you make the logic visible, if you show the trade-offs, it becomes less about politics and more about clarity.
And when the next shiny thing rolls in—whether it’s an AI integration or a leadership off-site in Tuscany—you’ve got your priorities stable enough to say, “Nice idea, but not now.”
I won’t pretend I’ve mastered it. I’ve still made bad calls, overcommitted, underdelivered, and let half-baked work run too long. But over time, I’ve learned that doing fewer things, really well, beats chasing every clever idea that crosses your desk.
Learning how to prioritise projects isn’t about control. It’s about focus. The kind of focus that lets you ship, learn, and move forward without leaving a trail of burned-out teams and forgotten plans.
So next time someone asks how I prioritise projects, I don’t say, “It’s easy.” I say, “It’s hard. And I’ve got the scars to prove it.” But if we stop pretending it’s just about confidence and start treating it like a strategic skill, maybe—just maybe—we’ll all stop mistaking motion for progress.