Moscow Analysis – Prioritising Your Requirements for Delivery

MoSCoW Analysis – Prioritising Your Requirements for Delivery

It often happens in a project that there are more stakeholder requirements defined and documented than what a project is capable of delivering. This is mostly because of project budget constraints, time constraints or in some cases because a requirement doesn’t strictly fall within the overall scope of what the project has been set up to deliver. As most Business Analysts would know, there are also often requirements included which are technically not feasible or at closer inspection simply too large to be included. This again brings us back to the budget and timeframe limitations we often have to face when we are a part of a project.

So what should a Business Analyst do when faced with a problem of too many requirements than what would be deliverable in the above types of scenarios? This is where requirements prioritisation comes into play. There are a few different techniques which you can choose to follow, such as a simple voting system, time-boxing or Budgeting or the more common technique called: The MoSCoW Analysis.

The Moscow Analysis

If we refer back to the IIBA ® Business Analysis Body of Knowledge definition of this technique it summarises the meaning of this technique very clearly and concisely.
The BABOK Definition is as follows:
MoSCoW Analysis divides requirements into four categories: Must, Should, Could, and Won’t.
Category descriptions are as follows:

  • Must: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
  • Should: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
  • Could: Describes a requirement which is considered desirable but not necessary and therefore will be included if time and resources permit.
  • Won’t: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

The above Moscow Analysis therefore aids the project team to plan their delivery of requirements based on priorities. This is a very strong enabler for delivery planning.

How would you go about performing the Moscow Analysis in your project?

It really depends on the overall purpose of prioritising the requirements within your specific project environment but could be approached in the following ways:

Run a requirements prioritisation workshop:

If you choose to follow the workshop approach it is a great idea to include the stakeholders who provided the requirements and have some level of authority to make prioritisation decisions. The workshop approach is very effective because people in the room have to also justify why a particular requirement is being nominated as a Must, Should, Could or Won’t. The downside of this approach is that this can take a significant amount of time if you have a large group of stakeholders and a lot of requirements!

Perform the Moscow Analysis in a small group & Validate:

An alternative approach to the workshop requirements prioritisation is for a smaller group to do their Moscow analysis on the requirements and then to only validate by way of a review with a wider group. This way you can achieve the prioritisation effort quicker but the downside is that people who have not been engaged directly might feel like their requirements have not been prioritised fairly.

Perform the Moscow Analysis based on regulatory or other critical process aspects:

More often than not, the Moscow analysis is almost “forced” by a regulatory reason or some other critical business process reason which dictate the Moscow analysis outcomes. This is in a way easier when a clear driver is doing the prioritisation to a large extent for the project. It is still very valuable to perform an explicit Moscow Analysis so that the stakeholders can clearly see the requirements priorities.