How to Prioritize with the MoSCoW Method

ProjectManager.com

Prioritize and manage tasks and projects. Try ProjectManager.com and get award-winning PM tools that can help you manage every aspect of your work.

Get a Free 30-Day Trial of Our PM Software

Do you need help prioritizing tasks when managing a project? There’s an acronym for that! It’s called the MoSCow method and it is a great technique to help with prioritization.

How to Prioritize with the MoSCoW Method:

Managing a project is often about managing what you will – and won’t! – get done in the given project timeline. When there are no priorities set, projects can quickly become free-for-alls, with the loudest voices in the room getting their work prioritized over others, often not at the benefit of the project or the organization.

But there’s a different approach. It’s called the MoSCoW method for defining and managing requirements and tasks in a project.

Here is a list to clarify what those requirements are:

Must-Have Requirements

Another way to refer to this is as the minimum usable subset (MUS) or what the project must deliver. In other words, the project must deliver these on the target date for the project to remain on track. No delay is acceptable. It is either going to take the project off track, it’s unsafe or even illegal not to have this done by the time given in the project’s business case.

A way to understand if you’re dealing with a MUS is by asking yourself, “What happens if this isn’t met?” If the answer is, “The project fails,” then you have a MUS. Any workaround that can be devised to continue with the project and not jeopardize its success, means this isn’t a MUS.

Should-Have Requirements

This type of requirement is almost as important as a MUS, but it’s not vital to the success of the project. In other words, the project doesn’t depend on this requirement. You might not want to leave it out, as it could have great impact on the project, but in the end it can be done without causing any irreparable harm. Again, leaving out this requirement means a lot of work⁠ (finding a solution, changing stakeholder’s expectations, maybe experiencing some inefficiency⁠), but the project can go on.

Could-Have Requirements

The difference between a should-have requirement and a could-have requirement is simply by figuring out the degree of pain that would be caused by not meeting it. That is, how will it impact the business value of the project, how many people would be affected, etc. Therefore, a could-have requirement is something you’d like but is less important than a should-have requirement. There will be an impact if it’s left out of the project, but less than the impact of a should-have requirement.

What We Will Not Have This Time

Here is where you can collect those requirements that are not feasible for a specific release. Maybe next time, but the project remains strong without them. This is a great way to avoid project scope creep. Once initiatives are placed in the not have time category, teams know that they’re not a priority for this go-around and can place them on the back-burner and out of their mind. This allows them to focus more sharply on those requirements that are important to the project.

Requirements Gathering

But before you can prioritize, you must have something to prioritize. This is called the requirements gathering part of the process. It’s not specifically a part of the MoSCoW method, but you to gather requirements effectively in order to prioritize effectively.

This is more than asking yourself a few questions and then moving on to the next stage in the project. Time must be spent to make a thorough requirements gathering.

Related: Free Requirements Gathering Template

It’s a four-step process that can be used for projects big and small. The size of the project will only impact the length of time it takes to complete this process.

  • Elicitation: This step means you start asking questions and actively listening to the answers, through interviews with stakeholders, those with experience, etc., also facilitated sessions, prototypes and questionnaires are other tools you can use.
  • Validation: Now you start to analyze the data collected to make sure the information is accurate and represents the needs and expectations of the stakeholders. You’ll  begin consolidating, rationalizing, looking for overlaps, gaps, etc.
  • Specification: You’ll move onto prioritizing and formalizing the data into a requirements definition report. You’ll also want to make sure they can be tested.
  • Verification: Finally, you’ll verify that the requirements are accurate and communicate the needs and expectations of your stakeholders. The requirements are reviewed and approved.

By following this process to define what are essential and non-essential requirements for your project or product development, you can quickly see where your focus should be. This method also helps you to make sure you come to a conclusion about what those priorities are for each requirement early in the process.

How ProjectManager.com Maintains Quality in Your Project

ProjectManager.com is a cloud-based project management software that can make sure your requirements are being met throughout the life cycle of the project. Because our software is giving you real-time data, you’re able to meet your priorities.

Our real-time dashboard shows real-time data that is displayed over six different project metrics. These numbers are crunched and illustrated in colorful, easy-to-read graphs and charts that keep project managers keenly assessed of the progress on their priorities.

Our project dashboards deliver data in real time so data is always accurate.

Workflow is also visualized with kanban boards that keep teams focused on their priorities. Online Gantt charts can link dependencies and teams can collaborate at the task level, adding comments, documents and images.

There’s so much more that ProjectManager.com offers. To get a full picture of what we can do to help you better manage your next project, try our free 30-day trial today.

Watch Our Leadership Expert Explain the MoSCoW Method

Leadership guru Susanne Madsen leads this training video on how to use the MoSCoW Method to prioritize your requirements in a project.

Here’s a screenshot for your reference.

a better way to prioritize projects

Thanks for watching!

Pro-Tip: The Moscow technique is a great way to frame conversations with clients, to understand what they want and what are just nice to haves. This way, you’re not wasting time and they’re not being obscure. It’s a win-win for project kick-offs with clients.

Transcript:

Hi, I’m Susanne Madsen. Welcome to this whiteboard session on how to prioritize requirements with the MoSCoW technique.

In the MoSCoW technique, the “M” stands for a “must have requirement,” it is non-negotiable, we must have it.

The “S” stands for “should have requirement,” if at all possible, we should have it.

The “C” stands for “could have requirement,” it’s not essential, but we could have it if we have extra time or extra budget, and the “W” stands for something that we will not have this time around.

You see, on most projects, we talk about something that is either in-scope or out of scope. Using the MoSCoW technique gives you a more granular view, and it helps you make sure that you deliver the top, top priorities to your clients first.

Let’s look at an example. Imagine that you are the project manager for a conference. You sit down with your stakeholders and you ask them, “What must there be for this conference? What are all your must-have requirements?”

And your client says, “Okay, we must have a venue within five kilometers of the city center.”

“Okay, what should we have, if at all possible?”

“Well, we should really have a goody bag for each delegate to walk away with.”

“Okay, what could we have?”

“Well, let me think, we could have several tracks of speakers, but really, it’s not that important, it’s nice to have if we have extra time and budget, let’s do it.”

“What will we not have?”

“We will not have any alcohol at the event,” and you do that with all other requirements, but the power of MoSCoW is that you can also use it at a more detailed level, to look at the features of a requirement.

Let’s take an example with a goody bag. Imagine that you have now delegated that to Dan, and Dan would like to know what your expectations are, so Dan asks you, “What must there be in the goody bags when I deliver them?”

And you say, “Okay, we must have a copy of the conference program.”

“Fine. What should we have in there?”

“Well, we should really have a branded item, maybe like a pen, or something like that.”

“Okay, what could we have in there?”

“Well, we could have something sweet, but it’s nice to have, it’s really not essential.”

“What will we not have?”

And you decide that you will not have any soft drinks or water because they will make the bag too heavy.

So you see, you can use “MoSCoW” at a very high level, but also at a low level. When you use it at the low level, it helps you to delegate the tasks better.

Thank you for watching, please visit us again at ProjectManager.com.

(This post updated December 2019)

Related Posts

Deliver Your Projects
On Time and Under Budget

Start planning your projects.

Start 30-Day Free Trial