Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

MoSCoW Method

~ By Duncan Haughey

MoSCoW written on a blackboard

When managing a project, it is important to develop a clear understanding of the customers' requirements and their priority. Many projects start with the barest headline list of requirements, only to find later the customers' needs have not been fully understood.

Once there is a clear set of requirements, it is important to rank them. This ranking helps everyone (customer, project manager, designer, developers) understand the most important requirements, in what order to develop them, and what not to deliver if there is pressure on resources.

So what is the best method for creating a prioritised list of requirements?

The MoSCoW method can help. MoSCoW stands for must, should, could and would:

  • M - Must have this requirement to meet the business needs
  • S - Should have this requirement if possible, but project success does not rely on it
  • C - Could have this requirement if it does not affect anything else on the project
  • W - Would like to have this requirement later, but delivery won't be this time

The o's in MoSCoW are added to make the acronym pronounceable and are often in lowercase to show they don't stand for anything.

MoSCoW as a prioritisation method is used to decide which requirements to complete first, which must come later and which to exclude.

Unlike a numbering system for setting priorities, the words mean something and make it easier to discuss what's important. The must requirements need to provide a coherent solution, and alone lead to project success.

The must requirements are non-negotiable. Failure to deliver even one of them will likely mean the project has failed.

The project team should aim to deliver as many of the should requirements as possible. Could and would requirements are nice to have and do not affect the overall success of the project. Could requirements are the first to go if the project timeline or budget comes under pressure.

It is essential to have a clear set of prioritised and agreed requirements with the customer, alongside the overall objective, quality criteria, timescale and budget if you are going to deliver a successful project. The recommended method for setting priorities is MoSCoW.


MoSCoW was developed by Dai Clegg of Oracle UK in 1994 and has been made popular by exponents of the Dynamic Systems Development Method (DSDM).


Comments (13)

Topic: MoSCoW Method
5/5 (12)
Gravatar
Full StarFull StarFull StarFull StarEmpty Star
19th September 2019 1:42pm
Sean B (Mississauga) says...
Great article. How do you deal with situations, when the client/sponsor tags all requirements as "M" (Must have). I'm not sure that there's anything wrong with that, after all, they're paying for the project -- but how should a PM manage the fact that all (or 90%) of the requirements tuned out to be 'must-haves'? Is it by demonstrating these must-have requirements from a timeline perspective and asking the client to sign off the expected timeline or reduce some of the must-haves -- would that be the basic way to deal with such a situation?
Gravatar
Full StarFull StarFull StarFull StarFull Star
27th September 2019 9:00am
Frank Turley says...
Hi Sean,

Thanks for your feedback and your questions. I have created a short video that gives examples of questions to ask the user and then the users will decide themselves if M, S or C:
https://www.youtube.com/watch?v=btZxWPu72Zw&t=561s

Regards,
Frank
Gravatar
Full StarFull StarFull StarFull StarFull Star
30th September 2019 5:11pm
Ed Rushman (Orange County) says...
Exactly, although I would usually ask a few questions to qualify. Sometimes, it is because the requirements are at a level where not everything within those is necessary. For instance, what appears to be "all users" may in fact only be a large subset, allowing some to be excluded because they have an alternate method of access.

Sometimes the integration of an ancillary system that is being migrated that doesn't current participate in SSO is expected to change to SSO, but it can be better to leave authentication as is until the main system is up and then tackle SSO as a separate project for the ancillary system. Sometimes MoSCoW is revisited during elaboration of requirements and becomes part of scope change.
Gravatar
Full StarFull StarFull StarFull StarFull Star
8th September 2018 3:23am
Reza (Kuala Lumpur) says...
Sharing my experience: we simplified the method further by combining the should (S) and could (C) into one category called “Nice to Have”. Thus, at the end we had three categories:

  1. Must to Have
  2. Nice to Have
  3. Won’t Have (out of scope)
Gravatar
Full StarFull StarFull StarFull StarEmpty Star
8th September 2015 11:44pm
Nitin Jain (London) says...
Great method. Thanks for explaining it so well here. Would vs Won't debate is not relevant. However, a practical consideration is the inability to sort out the list based on this classification in Excel or any other request tracking system as MoSCoW does not appear alphabetically. Any suggestions for the same? We can do 1-Must, 2-Should, 3-Could, 4-Won't, but that defeats the purpose to some extent.
Gravatar
8th September 2014 6:00pm
Nicole Yaniz (Mokena) says...
Does anyone have a good template they use?
Gravatar
Full StarFull StarFull StarEmpty StarEmpty Star
22nd July 2014 1:54am
Chu (Yangon) says...
Please explain to me about W. It is won't or want. In my first textbook (Agile), it is named as Won't. It is named as Want in Database Frameworks and method.
Gravatar
Full StarFull StarFull StarFull StarFull Star
25th July 2014 8:50am
Duncan Haughey (London) says...
I don't think it really matters whether it is Won't or Want as long as the intent is clear. It is not worth debating which it should be. Won't, want and would are all used and quoted depending on where you look. Personally, I like would, as in, "I would like to have this requirement, but will leave it out this time for consideration at a later date".
Gravatar
Full StarFull StarFull StarFull StarFull Star
21st June 2014 3:53pm
Christina (Athens) says...
Just a point. For the prioritization that involves 3rd party priorities (regulation, legislation) I use "Ought" as well.
Gravatar
Full StarFull StarFull StarFull StarFull Star
18th June 2014 9:39pm
Dan Brenner (Lakewood) says...
The PMBOK has not defined this anywhere, and it isn't in the PMI lexicon either.
  • Must, Should, Could, Would is the "all positive" project manager.
  • Must, Should, Can't, Won't is the "all negative" project manager.
  • Must, Should, Could, Won't is the "balanced" project manager.
I prefer the balanced approach as it allows you to define some things that have been defined as 'out of scope', while still giving a middle ground of things that you could decide to include in the project.
Gravatar
Full StarFull StarFull StarFull StarEmpty Star
18th June 2014 8:33pm
Yaroslav (Slavutich) says...
"W" does not mean "Would", it means "Won't" this is confused.
Gravatar
Full StarFull StarFull StarFull StarFull Star
18th June 2014 9:32pm
Duncan Haughey (London) says...
I'm not sure won't is correct either. I believe the definitive definition is:

'Want to have but will not have this time round'.

This is applied to those requirements that can wait until later development takes place.

Whether you use would, won't or want - these requirements aren't going to be delivered this time round.
Gravatar
Full StarFull StarFull StarFull StarFull Star
21st June 2014 6:00pm
Shilpa Adavelli (Chicago) says...
For requirements prioritization, BABOK says 'W' is for 'Won't', not 'Would' or 'Want' but not necessarily everybody follows the BABOK, so I guess 'Would' would work for some organizations. As long as it is clearly defined what the expectation is and what 'W' stands for, I don't think it's an issue.

Add a comment



(never displayed)



 
2000
Out of 56, 14 or 27, which is the largest?
Notify me of new comments via email.
Remember my form inputs on this computer.

10 Golden Rules of Project Risk Management

Three red dice reading: Manage your risk

The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner.

Critical Path Mapping

Critical path method words on digital screen with world map

The activity network diagram is a method of displaying the timelines of all the various sub-tasks that are involved in any project. So how do you create one?

PMP vs. PRINCE2 Certificates

Senior lecturer in front of his class

What's the difference between the PMP and PRINCE2 certifications? Which one should I choose? Which one's better for my career?

A Brief History of SMART Goals

Set your goals written on blue paper

In this history of SMART goals, I look at where the acronym came from, who developed it, what the critics say and why it has become popular.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Deb McCarthy commented on…
The Role of the Project Manager
- Fri 4 October 5:57am

Ed Rushman commented on…
MoSCoW Method
- Mon 30 September 5:11pm

Shawn Robert Vance commented on…
Better Coaching Using the GROW Model
- Sat 28 September 6:41pm

Latest tweets

General Project Management • Re: Building a UK Community https://t.co/v3vt0mYyE7 about 8 days ago

General Project Management • Dissertation Survey - Please help https://t.co/XwtF8pERkX about 18 days ago

MOSCOW Method https://t.co/uctlvoR733 some questions to ask the user and then the users will decide themselves if M, S or C. #projectsmart about 20 days ago