I’ve been struck a few times on recent projects that people don’t seem to understand properly the MoSCoW framework for prioritising requirements. Perhaps I’m being unfair and that the priorities I’ve seen have been warped by over-enthusiastic stakeholders intimidating business analysts, but there’s little point in using this framework unless you’re going to do so with a degree of rigour.
So I thought I’d share my interpretation and hopefully this will help you fight your corner when you’re trying to explain to stakeholders how the prioritisation works.
Firstly, MoSCoW is an abbreviation of the following priorities: Must Have, Should Have, Could Have, Won’t Need. I don’t know why I’ve seen templates from global organisations which list W as Would Need. What do they suppose that means? They would need it if they could think of a reason why? Anyway, once you’ve the nomenclature clarified, here’s what those headings actually mean:
The system you’re looking to put in place simply isn’t worth having unless that requirement is met. The requirement is core to the business case and the project benefits. It’s the main reason why you’re looking for a new system in the first place. Any stakeholders who tell you that their requirement is a Must Have, you need to ask them: if the system met all the other requirements, you’d still reject it because it didn’t meet this one? What is it about failing to meet this requirement that would mean we couldn’t meet our Return On Investment target?
These requirements aren’t necessarily core to the central business case for a new system, but they obviously add value. Since the system you’re adopting is about changing your business models to become more successful, more productive and ultimately more profitable, it would be stupid not to do this when we’ve an opportunity to do so. The stakeholder accepts that not meeting this requirement wouldn’t kill the project, but equally the business recognises that this is a very good idea with a clear ROI and really should be included in project scope.
Often when you’re gathering requirements you have a clear idea of the kinds of systems that are available and how they can meet your organisation’s needs. These systems do things that are pretty cool which you’d like to do, but current business processes or system limitations prevent you from doing right now. If this feature were available, you’d be likely to benefit from it in future. There’s either a relatively small business case for doing this, or a business case that’s yet to be proven but would probably become clear once you started to use the system.
When a major new project kicks off, lots of stakeholders who’ve been waiting for an opportunity to make a business change to their own area see it as an opportunity to piggy-back their requirements onto the first thing they see that has both budget and traction. The requirement is likely to be valid, but not close enough to the scope of what you’re planning to be applicable to the new project. It can be quite hard negotiating what’s a Could Have and what’s a Won’t Need, but a good way to do this is to provide workarounds or quick wins for the peripheral requirements and demonstrate how you can address these outside the existing project. You need to remind stakeholders that scope creep is a guarantee of project failure and they’re much more likely to get their requirements delivered outside your project than in an über-project whose complexity, budget and delivery date will be continually expanding.
The other kind of requirement you Won’t Need are features offered by a supplier that are outside the remit of your project, but where the vendor is offering another module for a really fantastic deal. Again, remember that scope creep is the enemy of success. Get your supplier to focus on delivering a great solution and establishing confidence, and they’re much more likely to be able to sell in further to your organisation once they’ve developed a solid track record.
Over many years I’ve found MoSCoW a really useful way of establishing priorities. It informs business case development, project planning and the way you frame requirements and user stories. But it’s only useful if you get it right in the first place. So stick to the straight and narrow and you’ll get the most from it too.