Prioritizing LMS Requirements Using the MoSCoW Method

A very useful technique is to use a meaningful word set such as the MoSCoW method.

Introduction

To make the most informed decision when evaluating and selecting a Learning Management System, the business and technical requirements need to be properly prioritized.  A very useful technique is to use a meaningful word set such as the MoSCoW method.

The meaning of the MoSCoW word set helps stakeholders understand what they are doing during prioritization in a way that other methods of prioritization do not.

Overview

The first step to evaluating potential Learning Management Systems is to develop a clear understanding of the requirements and their priority. This helps everyone understand the most important requirements and objectively compare systems that meet the requirements.

Traditionally, requirements are ranked Low, Medium or High. In another common prioritization method they are assigned a numeric value. However, when using either of these methods, every requirement can be ranked as important. After all, they are important or they wouldn’t have made the list of requirements.

So what is the best method for creating a prioritized list of requirements? The MoSCoW method can help. MoSCoW stands for MUST, SHOULD, COULD and WOULD/WON’T:

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

The use of MoSCoW was first developed by Dai Clegg of Oracle UK Consulting; in CASE Method Fast-Track: A RAD Approach; although he subsequently donated the Intellectual Property Rights to the Dynamic Systems Development Method (DSDM) Consortium.

Although developed as means of prioritizing requirements for the software development process, the MoSCoW method can be adapted to the Learning Management System selection process.

MoSCoW Prioritization Method

MoSCoW as a prioritization method is used to decide what requirements must be included and what requirements are optional for success. Unlike a numbering system for setting priorities, the words have specific meaning. This makes it easier to discuss what’s important.

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.

Beyond that, the goal is to find a system that provides as many of the SHOULD requirements as possible. COULD and WOULD/WON’T requirements are ‘nice to have’ and do not affect the overall success of the system selection process.

Definitions of the Word Set

All requirements are important, but they must be prioritized to deliver the greatest and most immediate business benefits. While it’s desirable to find a system that provides all of the M, S and C requirements, it is generally not possible.

MUST (M)

Requirements labeled as MUST have to be included in the first implementation for the project to be a success. If even one MUST requirement is not included, the project delivery would be considered a failure. Think of MUST as the Minimum Usable SubseT.Example: The LMS must keep a record of an individual learner’s learning activities.

SHOULD (S)

SHOULD requirements are as important as MUST, although SHOULD requirements are often not as critical or have workarounds, allowing another way of satisfying the requirement. They are important and of high value to the user.Example: The LMSshould allow a manager to assign learning activities to a group of learners based on their job title.

COULD (C)

Requirements labeled as COULD are less critical and often seen as nice to have. The project is still considered a success if the functionality is not included.Example: The LMS could send out notifications to an individual that his or her certification is going to expire within 90 days.

WOULD/WON’T (W)

WOULD/WON’T requirements are either least-critical, lowest-payback items, or not appropriate for the first implementation. These are requirements that stakeholders want to have, but have agreed will not be included in the first implementation.Example: The LMS won’t support printing of certificates in the first release but may do so in the next phase.

The examples in the table above demonstrate that the Learning Management System features have been discussed in a decreasing order of priority – from what the system must have, to what it should have, could have and won’t have.

A properly prioritized list of requirements includes a healthy number of Should Have and Could Have requirements. Typically, no more than 50% of the requirements are prioritized as Must Have.

Implementing the Method

The process described below is employed after all requirements have been gathered and agreed upon by all stakeholders.

1. Using a common format, distribute the requirements to all stakeholders.
2. Each stakeholder assigns priorities to the requirements that fall under their purview.
3. Assemble all stakeholders.
4. Agree on a decision-making process for reaching consensus.
5. Display the requirements and prioritize each one based on the input of the stakeholder(s).
6. If multiple stakeholders have different opinions on the priority assignment of a requirement, utilize the agreed upon decision-making process to reach consensus.
7. Finalize and publish the list of prioritized requirements.

Summary

Traditionally, requirements are ranked Low, Medium and High. Or they are assigned a numeric value. However, when using these methods, everything has to potential to be ranked #1 or High.

The MoSCoW prioritization method is used to decide what requirements must be included and what requirements are optional for success. Unlike a numbering system for setting priorities, the words have specific meaning. MoSCoW stands for:

MUST have (or Minimum Usable Subset)

SHOULD have

COULD have

WON’T have (but WOULD like in future)

The method provides a common language for all stakeholders and focuses attention on what matters most to the business.