MoSCoW Method

MoSCoW Method - ToolsHero

This article explains MoSCoW Method in a practical way. After reading you will understand the basics of this powerful project management tool.

What is the MoSCoW Method?

Prioritising is often challenging. Particularly when it comes the implementation of new ideas and/or technologies. Everyone in an organisation always wants everything to be done right away and that is practically impossible. There are several tools available to make prioritisation easier. The MoSCoW method is one them.

Dai Clegg from the software company Oracle invented MoSCoW Method. The method labels each requirement, making it easier to prioritise.

Even though the origin of this prioritize method is in software development, it is also highly applicable for market launches, product launches, starting a new business or change processes. With MoSCoW Method, requirements are determined for the result of the project or product.

The MoSCoW Method is about setting requirements by order of priority. The most important requirements need to be met first for a greater chance of success.

The MoSCoW Method is an acronym made up of the first letters. The two Os have been added to make the word ‘moscow’ readable, they don’t have any meaning themselves. The M stands for ‘Must haves‘, S for ‘Should haves‘, C for ‘Could haves‘ and W for ‘Won’t haves‘ or ‘Would haves‘.

Moscow methodology - Toolshero

Requirements

It’s a good idea to first specify the requirements before starting the MoSCoW Method. When determining the requirements, you should take into account what is important to all the stakeholders. Brainstorming with everyone involved will lead to good, qualitative requirements.

The requirements are prioritised to prevent them from becoming to expensive or unrealistic. The main goal is to come up with requirements that add the most value for the company. The project requirements are divided into one of the following categories:

M – Must haves

These are about the minimal requirements that are determined in advance that the end-result has to meet. Without meeting these requirements, the project fails and the product won’t be use-able. They are a necessity for a workable product and there is no alternative. The ‘Must haves’ are essential. MUST is also explained as an acronym that stands for Minimum Use-able SubseTs.

Example: As an extra exam assignment, University of Applied Sciences Automotive students have been asked to design a car that can at least drive (minimal requirements). It’s okay if the car only has a chassis, without any bodywork. It’s about the construction of the individual parts and drive train to the combustion engine. In this case, the Must have is that they have a drivable car by the end of the academic year.

S – Should haves

These are additional and much desired requirements that have a high priority, but are not essential for a usable end product. The product will be usable even if these requirements aren’t met. When they are met, they will only add to the value of the product. Depending on the available time, you can always return to these requirements at a later time.

Example: The University of Applied Sciences Automotive student might like to add a tow bar to the car (should have), but as long as the car can drive without the tow bar, their project will be successful. They can always add the tow bar at a later stage.

C – Could haves

These requirements can be considered if there’s time left. If not, it’s no problem and will not have a negative effect on the final result. The ‘Could haves’ have a lower priority than the ‘Should haves’. This option will only be included if there really is more than enough time to make it work. This category is also referred to as ‘nice to have’; they’re more a wish than an absolute requirement.

Example: The University of Applied Sciences Automotive students would perhaps like to install a tachometer in the car. It’s not an important (exam) requirement, but it’d be great if they manage to do it.

W – Won’t haves (and would haves)

These are about wishes for the future that are often impossible to realise or cost a lot of time. If it’s simply not possible, it’s best not to waste any energy on it. If it is achievable, then a lot of time (and money) will have to be invested and it’s labelled a ‘Would have’. ‘Would haves’ are often followed upon at a later stage after the initial project is finished.

Example: The University of Applied Sciences Automotive students don’t have to make a car that will actually drive on public roads. It’s meant for study. If they do want to take it on public roads, it will need bodywork and comply with safety standards. It also involves getting approval from the Vehicle Standards Agency in elaborate process.

Deadline

Correctly applying and sticking to the MoSCoW Method will lead to a clear way to lead a project. Everyone involved with the project will know what needs to be done first, when it has to be finished and why it’s important. By assigning priorities to requirements, a project becomes more manageable and it’ll be easier to meet the deadline.

Development and support of a project is also made easier by initially ignoring less important requirements. By focusing on the key requirements, you end up with a sell-able product that meets the minimum requirements. That way, must haves become unique selling points, which will benefit the buyer.

It’s Your Turn

What do you think? How do you apply the MoSCoW Method in your project or organisation? Do you recognize the practical explanation or do you have more additions? What are your success factors for applying the MoSCoW Method?

Share your experience and knowledge in the comments box below.

If you liked this article, then please subscribe to our Free Newsletter for the latest posts on Management models and methods. You can also find us on Facebook and Google+.

More information

  1. Baxter, R. (2004). Software engineering is software engineering. In 26th International Conference on Software Engineering, W36 Workshop Software Engineering for High Performance System (HPCS) Applications (pp. 4-18).
  2. Stephens, R. (2015). Beginning Software Engineering. Wrox Publishing.
  3. Hatton, S. (2008). Choosing the right prioritisation method. In Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on (pp. 517-526). IEEE.
  4. Robson, W.A., Simon, Shena. (2014). Moscow in the making. Taylor & Francis Ltd.

How to cite this article:
Mulder, P. (2017). MoSCoW Method. Retrieved [insert date] from ToolsHero: https://www.toolshero.com/project-management/moscow-method/

Add a link to this page on your website:
<a href=”https://www.toolshero.com/project-management/moscow-method/”>ToolsHero: MoSCoW Method</a>

Did you find this article interesting?
Your rating is more than welcome or share this article via Social media!

MoSCoW Method, 5 / 5 (3 votes)

LEAVE A REPLY

Please enter your comment!
Please enter your name here