I was in a project review meeting last Thursday (actually it was more like a project intervention) and witnessed something I’ve seen too many times before. The Project Manager was desperately trying to explain to a roomful of increasingly frustrated stakeholders why half the transformation requirements wouldn’t make it into the initial go-live. The problem? No one had properly prioritised anything at the start. Every business process change had been labelled “critical.” Every system integration was “essential.” Every data migration activity was “urgent.”
It reminded me of that scene in The Incredibles: “When everyone’s super, no one is.” Replace “super” with “critical” and you’ve got the average requirements document.
If this sounds familiar, you’re not alone. I’ve lost count of the projects I’ve seen where everything is a priority, which ultimately means nothing is a priority. It’s like going to a restaurant where every dish is the “chef’s special recommendation” – suddenly none of them are.
This is precisely where MoSCoW prioritisation comes in, and why it’s one of those foundational techniques that can save your project from veering into that dreaded special measures territory.
WHAT IS MoSCoW PRIORITISATION?
MoSCoW is a prioritisation technique that categorizes requirements into four distinct groups, and the capital letters in the name are the clue:
Must Have – Non-negotiables. These are requirements that are absolutely critical to the transformation’s success. Without them, the project fails, plain and simple. In an IT transformation context, these might be core system functionality that enables critical business operations, essential integrations with existing systems, or mandatory data migrations. Think of them as the foundations of your house; you can’t build anything without them.
Should Have – Important but not vital. These requirements are significant and add considerable value, but the transformation can technically be delivered without them in the initial phase. Perhaps they’re process improvements that would streamline operations, or additional integrations that enhance efficiency but aren’t day-one blockers. They’re like having central heating; you really want it, but you could survive a winter without it if you absolutely had to (albeit with a lot of complaining and several extra jumpers).
Could Have – Nice to have. These are desirable elements that would improve the transformation outcomes or add value, but they’re not essential to achieving the core business objectives. They might be enhanced reporting capabilities, additional automation, or nice-to-have integrations with peripheral systems. Think of them as the decorative features; lovely to have, but you’d manage fine without them.
Won’t Have (this time) – Out of scope for this iteration. These requirements have been explicitly identified as not being delivered in the current phase, though they might be considered for future releases. Crucially, this category exists to manage expectations and prevent scope creep.
The “o”s in MoSCoW? They’re just there to make it pronounceable and memorable – a clever bit of acronym engineering!
WHY MoSCoW MATTERS
The beauty of MoSCoW lies in its simplicity and its ability to force honest conversations. Most stakeholders can grasp it immediately, and that’s powerful. You’re not asking people to understand complex scoring matrices or weighted decision models; you’re having a straightforward discussion about what truly matters.
Here’s the thing though – MoSCoW only works if you’re brave enough to have the difficult conversations. I’ve seen too many projects where the PM has categorised 80% of requirements as “Must Have” because they didn’t want to disappoint anyone. That’s not prioritisation; that’s wishful thinking dressed up in methodology.
The real power emerges when you establish clear criteria for each category. At Stoneseed, we often guide our clients through defining what “Must Have” actually means for their specific context. For some, it’s about legal compliance or business continuity. For others, it’s about competitive advantage or customer commitment.
PRACTICAL APPLICATION: MAKING MoSCoW WORK
Let me share a recent example from a client engagement. They were undergoing a major IT transformation – consolidating multiple legacy systems into a single cloud-based enterprise platform. The initial requirements list contained 147 items. Yes, one hundred and forty-seven. I’ve seen shopping lists shorter than that. When we first reviewed it, 118 of those were marked as “essential” or “high priority.”
I’ll pause here while you do the maths. That’s 80% of requirements being absolutely critical. Apparently the other 20% were just there for a laugh.
We facilitated a series of MoSCoW workshops with the key stakeholders. Here’s what we did:
Started with the end in mind. We asked: “What does success look like at go-live?” This helped anchor the conversation in outcomes rather than features.
Applied the 60-25-10-5 rule as a guideline. Roughly 60% of requirements should be Must Have, 25% Should Have, 10% Could Have, and 5% Won’t Have. This isn’t a rigid formula, but it’s a useful sanity check. If you’ve got 90% Must Haves, you’re not doing MoSCoW prioritisation – you’re doing wishful thinking with vowels.
Used the “what happens if we don’t deliver this” test. For each Must Have, we asked stakeholders to articulate the specific consequence of not including it at go-live. If the answer was vague or about future convenience rather than immediate business necessity, it probably wasn’t a Must Have. “It would be really useful” doesn’t cut it when you’re talking about a transformation go-live.
Documented the Won’t Have explicitly. By clearly stating what’s out of scope, you manage expectations and create a buffer against scope creep. It also gives stakeholders confidence that their requirements haven’t been forgotten; they’re just scheduled for a future iteration.
By the end of the workshops, we had 43 Must Haves, 52 Should Haves, 31 Could Haves, and 21 Won’t Haves. The transformation suddenly had clarity. The team knew what to focus on. The stakeholders understood the trade-offs. And crucially, when budget pressure hit mid-project (because it always does), we could intelligently descope the Could Haves and defer some Should Haves to phase two without derailing the entire initiative.
COMMON PITFALLS AND HOW TO AVOID THEM
Everything becomes a Must Have. This defeats the entire purpose. If stakeholders are resistant to prioritizing honestly, you need executive sponsorship to enforce the discipline. Sometimes it helps to impose a hard limit: “We can only accommodate X Must Haves given our timeline and budget. Which ones make the cut?” It’s amazing how quickly people find their inner Marie Kondo when faced with actual constraints.
Won’t Have gets forgotten. The Won’t Have category isn’t a dumping ground to be ignored; it’s a commitment to transparency. Document these items clearly and revisit them during retrospectives or planning for the next phase.
Categories are treated as fixed. Requirements can move between categories as circumstances change. A Could Have might become a Must Have if regulatory requirements shift or business priorities change mid-transformation. A Should Have might drop to Won’t Have if budget gets cut or timelines compress. The categories should reflect current reality, not historical classification.
Insufficient stakeholder involvement. MoSCoW needs buy-in from people with the authority to make trade-offs. In IT transformations, this means engaging business leaders, not just IT teams. If you’re prioritizing in isolation or only with the technical delivery team, you’ll end up with technically-focused categories that don’t reflect business priorities or the realities of organisational change.
THE VALUE OF EXPERIENCED PROJECT RESOURCES
This is where having the right project management resources makes all the difference. Facilitating effective MoSCoW prioritisation isn’t just about knowing the technique – it’s about having the experience and credibility to have those difficult conversations with stakeholders, to push back when everything’s being labeled “critical,” and to guide teams toward realistic, achievable outcomes.
At Stoneseed, our Project Management as a Service (PMaaS) model gives you access to experienced PM professionals who’ve been through this hundreds of times before. They’re not learning on your transformation project; they’re bringing battle-tested expertise that helps you avoid the common pitfalls and navigate the politics of prioritization with confidence.
Whether you need someone to facilitate your MoSCoW workshops, provide interim programme leadership during a critical transformation phase, or embed within your PMO to strengthen governance and delivery capability across multiple workstreams, our flexible resourcing model means you get the right expertise exactly when you need it – without the overhead of permanent hires or the risks of lengthy recruitment cycles.
BRINGING IT ALL TOGETHER
That project review meeting I mentioned at the beginning? After implementing proper MoSCoW prioritisation with one of our experienced consultants facilitating, the same client successfully delivered their transformation go-live on time and within budget. The stakeholders were happier because expectations had been managed properly from the start. The delivery team was more focused because they weren’t constantly being pulled in different directions by competing “critical” requirements.
MoSCoW won’t magically solve every transformation challenge – no single technique will – but it provides a foundation for the kind of honest, productive conversations that lead to successful delivery. Combined with strong leadership, clear governance, and the right resource flexibility, it’s a powerful tool in any Project Manager’s toolkit.
Whether you’re navigating a complex IT transformation, managing changing business requirements, dealing with budget pressures, or balancing competing stakeholder demands, MoSCoW provides that clarity to keep your project on course. Like any good technique, it’s simple to understand but requires discipline to apply well.
And that discipline? That’s what separates projects that struggle from projects that succeed.
More about Project Management as a Service from Stoneseed
Need help implementing effective prioritisation frameworks or navigating complex project challenges? At Stoneseed, our flexible PMaaS model provides experienced Project Management resources exactly when and where you need them. Our consultants bring deep expertise across methodologies, sectors, and project types – adapting to your needs without the commitment of permanent hires. Get in touch at 01623 723910 or visit www.stoneseed.co.uk
