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.
The issue isn’t that people can’t prioritise projects; it’s that they often confuse prioritisation with a polished wish list. Real prioritisation means making trade-offs, saying no, and asking uncomfortable questions: what are we solving, who cares, what happens if we don’t do it, can we deliver it now, and who owns it? Frameworks won’t make the decision for you, but they do make the mess visible — and that’s usually where better choices begin.
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—Impact, Confidence, Ease
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.