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 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).


Comments (8)

5/5 (7)
Gravatar
Clock icon 8th September 2014 6:00pm
Nicole Yaniz (Mokena) says...
Does anyone have a good template they use?
Gravatar
Full StarFull StarFull StarEmpty StarEmpty Star
Clock icon 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
Clock icon 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
Clock icon 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
Clock icon 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
Clock icon 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
Clock icon 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
Clock icon 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)



 
1000
Which is darker: black or white?
Notify me of new comments via email.
Remember my form inputs on this computer.

The Risky Business of Project Management

Three red dice reading: Manage your risk

It is important at the beginning of any project to go through the risk identification process. Not all project risks are obvious, so here's how.

Project Planning a Step by Step Guide

Businessman finding the solution to a maze

The key to a successful project is in the planning. Creating a project plan is the first thing you should do when undertaking any kind of project.

Break Your PMP Studies Into Small Pieces

A mature student concentrating on her studies

Taking the PMP exam is one of the biggest steps you'll take in your career as a Project Manager. With careful planning you can pass with a minimum of stress.

Stepping Up SMART Goals

What are your goals question in vintage wooden letterpress printing blocks

The SMART acronym is a great tool for making sure our goals and instructions are specific, measurable, attainable, relevant and timed.

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 on what's happening in the world of project management.


Latest Comments

Quinton van Eeden commented on…
Perception Is Not Always Equal
- Thu 30 July 10:56am

Duncan commented on…
Project Management Success with the Top 7 Best Practices
- Wed 29 July 7:11pm

Rafael de la Cruz commented on…
Project Management Success with the Top 7 Best Practices
- Tue 28 July 9:42pm

Latest tweets

Seven of the most important areas to consider when auditing a construction site http://t.co/OXlKGatc4m #pmot #pm #projectsmart about 2 days ago

General Project Management • Wanting to become a PM from a developer role http://t.co/J7KZj8KpJ1 #pmot #projectsmart about 2 days ago

Project Smart has been upgraded! That means you can get all of the benefits on any device. Why not try it now. http://t.co/bj6SjiwOtT #pmot about 3 days ago