Install Toolbar

Site Map

See Article Categories

MoSCoW Method

By Duncan Haughey, PMP
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 ensure they are ranked. This helps everyone (customer, project manager, designer, developers) understand the most important requirements, in what order to develop them, and those that won't be delivered 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 in the project.
  • W - Would like to have this requirement later, but it won't be delivered this time.

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

MoSCoW as a prioritisation method is used to decide which requirements must be completed first and which must come later or will not be completed at all.

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 and have to be delivered. Failure to deliver even one of the must requirements 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.

To deliver a successful project, it is essential that a clear set of prioritised requirements are agreed with the customer, alongside the overall objective, quality, timescale and budget. 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).

Speech bubble Don't forget to leave your comments below.

Comments (7)

W is for Won't
You have this wrong (though it's a popular misconception). W is for Won't i.e. out of scope of the project. You should take a look at the source you've cited.

Please correct to avoid further confusion. Thanks.
#1 - MarkB - Thursday 21st February 2013 - 13:03
I am a firm believer in this method in order to make an Agile project ever be deemed successful or on-time by the stakeholders. However, I was wondering what kind of ratio (M:S:C) others generally end up with (or manage to convince the stakeholders to allow) - as surely if the project is very M/S heavy then you lose all the flexibility in the project scope and increase the risk...
#2 - Jamie - Thursday 21st February 2013 - 16:57
W is for Want
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.
#3 - Duncan - Sunday 24th February 2013 - 09:23
Would, won't, want
I prefer "would" myself because it's less definite than "won't". Won't could be interpreted as a function that is undesired (for whatever reason), which isn't what the W is meant to represent.

Would is a bit more open, as in "Would like this, but it's not going to happen".

In any case I agree with Duncan. Whatever you choose to use doesn't matter much as long as the definition is the same.
#4 - Dennis - Thursday 28th February 2013 - 13:35
Director of Customer Implementation
The PMBOK has not defined this anywhere, and it isn't in the PMI.org 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.
#5 - Dan Brenner - Friday 1st March 2013 - 15:33
For requirements prioritization, BABOK says 'W' is for 'Won't', not 'Would' or 'Want' but not necssarily 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.
#6 - Shilpa Adavelli - Thursday 20th June 2013 - 18:41
Would Vs Won't
I prefer WOULD because if you use WON'T ... it means that you are talking about something you are not going to do ... FOR WHAT?
#7 - Dom - Saturday 14th December 2013 - 06:15
Name
Email (will not appear online)
Title
Comment

Article Categories

Requirements Gathering 101
Requirements gathering is an essential part of any project and a key project management skill. Read 10 rules for successful requirements gathering.

Project Requirement Needs For Success: Important Considerations
A company with poor requirements practices is just asking for over-budget costs and regular failure, according to a report by IAG Consulting.

The Role of a Business Analyst
This article examines the multifaceted role of the Business Analyst and gives a depiction of the duties and skills required to embark on such a career.

Information Icon Dealing With an Impossible Deadline:

  1. Renegotiate the deadline.
  2. Employ additional resources.
  3. Reduce the scope of the project.

Speech bubble Discover our online forum where you can ask questions, find out tips from other people and share your experience.