System
When it comes to prioritizing the different parts of a project it's not always clear how to go about it. There's never enough time and everything seems to be essential for the final product. That's where prioritization techniques like the MOSCOW method come in. This guide will show you how the MOSCOW prioritization method takes large, complex projects and categorizes their parts in a way that makes success more likely given time and budget constraints.
At its core, the MOSCOW prioritization method is a set of four categories and definitions for what sort of things go into those categories. It's a very simple but effective method that forces all the people involved in the project to agree on what work can realistically be done given certain constraints and sets clear expectations for what success looks like.
Additionally, the system has built-in slack in the event that things start to go off the rails as they sometimes do. That means that as long as you follow the guidelines, you can be fairly confident you'll be able to complete your project even when things don't turn out exactly as planned.
The name of the system itself is an acronym derived from the four categories that make it up. Must have, Should have, Could have, and Won't have. The O's are just there to make it an actual word and so easier to remember.
While the original system was developed by Dai Clegg while working at Oracle, it's since been adopted for other areas outside of software development and is useful for all kinds of project based work.
MOSCOW prioritization works by establishing four distinct categories where tasks, features, or requirements could go. Those categories are 'Must have', 'Should have', 'Could have', and 'Won't have'.
The first step is to meet with the stakeholders. This includes the people that will execute the project and those that will receive the finished product. Once gathered, you must agree on the definitions of the four categories.
Next, you would list all the activities, features, tasks, or requirements that the stakeholders consider part of the project. Once you have that list you go through it together and decide which category each item fits under given the project's constraints. These constraints are generally around time, budget, and other resources.
That's the basic rundown of the system but there's quite a bit of nuance to actually using it effectively. Let's go through each of the categories and explain how they work.
Must have
Items in the 'Must have' category are those that you consider absolutely critical to a project's success. If these items are not done, you would cancel the entire project - that's how important these items should be. Anything you could remove from the project, and it would still work - even imperfectly and with workarounds, should not go in this category. This is reserved for the absolute essentials.
Should have
These are items that while not essential, would add a lot to the final project. Items that you really want to include in the project but if they were not completed - the project as a whole would still work. These also tend to be the most painful to leave out of the project.
Could have
Items in this category are those that we would like to include but are not necessary. The main difference between this category and the 'Should have' one is the degree of pain we would feel if these were completely left out of the project. In other words these are the nice-to-haves. If there's enough time and resources left over, we'll get to these.
Won't have
The 'Won't have' category is especially useful. It's not enough to prioritize the parts of a project we wish to complete. By explicitly stating what parts will be excluded from the project, it sets expectations for all stakeholders from the very start.
Establishing what will not be part of the project from the beginning prevents stakeholders from trying to expand the scope of the project without the clear understanding that they would also be jeopardizing the completion of the project.
Assigning items to the categories
When assigning items to the categories, you also need to consider the amount of resources each item will take to complete. Without this constraint you could simple make a list of items, decide they're all 'Must haves' assign them to that category and call it a day. However that would only set you up for failure.
The MOSCOW method suggests you assign no more than 60% of the total resources available for the project to completing the items in the 'Must have' category. By resources we mean time, budget, and effort.
This doesn't mean you should only use up to 60% of your resources for completing these items and then stop if it's not enough. It's only meant to give you enough slack in case things don't work out according to plan. When things go wrong, as they sometimes do, you'll still be able to complete this category of items and have a barebones but functional project.
For the 'Should have' and 'Could have' categories, no more than 20% of the resources should be assigned to each of these. And when deciding which items to exclude from the project when pressed for time or resources - the first category to get cut is the 'Could have' one followed by the 'Should have' one.
We've created a simple template for you to copy and get started if you want to use the MOSCOW prioritization method for your next project. We've included some basic guidelines on the template to make it a little easier to get started, especially if you're working with others and want to make sure you're following the basic rules.
Getting started
Once you've rounded up all the relevant stakeholders for the project, start by listing all the parts you think you'll need under the '✅ Items' column. This will serve as a placeholder so you don't have to figure out exactly where everything goes as you think of it.
Once you've collected all the tasks, requirements or todos for the project - discuss the available resources and establish a limit. This will usually be a time limit but can also come down to the budget or constraints around the availability of certain team members. By figuring out the maximum resources you'll have available to complete the project, you can then start to figure out how much work can actually be done given those constraints.
Let's say your project has a time constraint of two weeks (ten workdays) to complete. That means if we follow the standard guidelines of MOSCOW prioritization, the items that make up the 'Must have' category should be given about six days to be completed. The items in the 'Should have' category two days, and the items in the 'Could have' category two days as well.
Remember that the project will be worked on starting from the 'Must have' category and only until it's complete and there are resources left will you move on to the next category 'Should have' and so on.
Now you can start to pull items from the '✅ Items' column and discuss with your stakeholders which category each item belongs under. There's no right or wrong way to do this as long as the 'Must have' category takes up no more than 60% of the total resources you've allocated to the project and you're only putting the bare essentials.
So you go down the list you created with your stakeholders until all the items are under one of the four categories.
In the worst of cases where your estimates are way off or you run into a serious issue, you'll be able to cut the 'Could have' and 'Should have' categories and still have a complete project if you followed the guidelines. That ultimately is one of the goals of this system, to structure projects in a way that builds in slack to accommodate unforeseen issues and problems without jeopardizing the project completely.
The MOSCOW method is a great way to structure all kinds of project based work. By taking the time to categorize the items based on how essential they are to the completion of the project, you can ensure that even when things don't go according to plan, you'll still have a high likelihood of completing the project and that what you finish will be useful.
Even thought this method is primarily used in team settings, it's worth considering for personal projects where you're the only person working on them. By using the same structure you would use with stakeholders with yourself, you can prepare your own projects in a way that sets you up for success.
View the template to copy it and get started
View template
