How to prioritize requirements for ERP System? Meet MoSCoW model

When you decide to by an ERP system, we have many expectations. Many times, while thinking about implementation many ideas come to our minds concerning system requirements and future functionalities. It worth to gather them all together and give them proper priorities. You can use MoSCoW model for this.

Shortly about the model

Setting requirements for the system is one of key activities during ERP selection. But writing down expectations isn’t enough to choose the best system. Creating to wide list of expectations might relate to many customizations, additional costs and significant extension of implementation time.

Read

For structuring expectations it’s worth to use requirements managing method MoSCoW. This method was created by software development expert Dai Clegg during his work at Oracle (NetSuite system provider – LINK). While designing his method Clegg wanted to create a platform for setting priorities to projects of specific duration. In particular, his method was intended for initiatives carried out as part of system implementations / launches. However, this method has become very popular and can be used in various aspects.

In this article I would like to focus on using MoSCoW method in choosing ERP system and its implementation.

MoSCoW – what does it mean?

The MoSCoW model defines 4 priority groups defined for the system requirements:

M – Must have – mandatory requirements that the system must provide.

S – Should have – requirements that should be in the system.

C – Could have – additional requirements, which are desirable but not essential.

W – Won’t have – requirements that will not be implemented (but may be implemented in the future).

MUST HAVE

Group of MUST HAVE requirements it’s a set of functionalities which system must contain. Their operation in the system is not negotiable. The need to implement them may result, for example, from legal provisions. When looking for an ERP system suitable for your company, if you set the MUST HAVE requirements group correctly, you will know what to check / what to ask first. If any of the reviewed systems does not meet the requirements of the MUST HAVE group, it should be rejected.

If you are unsure if given functionality should be in this category, ask yourself 3 questions about this requirement:

• What happens if the functionality is not in the system?
• Is there a simpler way to meet this requirement?
• Can the product / system function without it?

If the system will not work without this functionality or will be useless then it definitely belongs to the “MUST HAVE” group.

SHOULD HAVE

SHOULD HAVE contains requirements which are significant for our implementation but are not essential. If they are not implemented, the system will still work. The functionalities set in this group, however, constitute a significant added value for the system. This group can contain actions that can be introduced in a future version without affecting the functioning of the current one. Priorities set in this category are needed, but they are not necessary for the functioning of the system.

This group will contain requirements which have high importance. The ones for which we will be able to spend additional costs or extend the implementation time. If you need to opt out of certain requirements, you will try to keep the functionality of the SHOULD HAVE group in the system. However, as has already been mentioned, you can allow it to be implemented or postponed their implementation.

COULD HAVE

Requirements from this group are functionalities which are good to have but they’re not very important. Comparing them with MUST HAVE group they are requirements without which the system will still functioning well. They implementation isn’t necessary for basic ERP operation. In this group you shut set requirements which have minor impact on the result and their omission won’t significantly affect our satisfaction with the implemented system.

It is worth placing in this group requirements which we can opt out if necessary.

To overcome the reluctance to change (and implementation of the new system always brings change e.g. in work organization) it is sometimes good to convince sponsors and project owners to include something such as Could (as an “nice to have” element). They are functions that aren’t necessery for system operating but they implementation can make it easier for future users to get used to the new tool, change it and make their work easier.

WON’T HAVE

In WON’T HAVE group there are requirements with the lowest priorities. Placing functionalities that will not be included in a specific release / implementation / update helps manage system expectations.

Contrary to appearances it is really important to set this group of requirements. Its affects not only managing expectations but also managing scope creep. Due to the fact that we will put some functionalities in the WON’T HAVE group, the scope of the project will not be constantly expanded.

WON’T HAVE REQUIREMENTS AND FUNCTIONALITIES NOT FOUND IN THE SYSTEM

In the case of carrying out activities aimed at developing the system in the future, the requirements that have fallen out of the implementation and those included in the WON’T HAVE group will help us create the next MoSCoW model. Those are requirements that first go to the priority list.

In some approaches, a group of requirements classified as W is defined as group X – i.e. eXcluded  from the project. Others here use W as Wish – requirements that are lower in importance and value from the point of view of the entire organization and project than those of the COULD HAVE group.

HOW TO USE MOSCOW METHOD

Using the MoSCoW method, it is worth including representatives of the entire company in the process. This allows you to look at the requirements from a broader perspective, include all necessary functionalities from various departments of the company.

Setting priorities according to the MoSCoW method also helps to determine the effort that will have to be put in to meet the indicated requirements. Therefore, it is worth ensuring that the expectations of different departments are included in each priority group.

How to prepare for the MoSCoW model?

Classification according to the MoSCoW model is usually part of the pre-implementation analysis / project preparation. Taking into account the perspectives of various people in the company (e.g. owner, management board, middle-level manager, operational employee), prioritizing specific requirements can be difficult. In most companies, key decisions are made by high-level management. They determine what requirements should be included in the system and what will not be in it – the second group usually includes those functionalities that are not budgeted, their implementation goes beyond the time frame or is associated with formal and legal restrictions (e.g. protection sensitive data, etc.). To reconcile the expectations of the management with the functional expectations of various departments, it is worth appointing a person or team responsible for the final preparation of priorities and creating a list that reconciles different points of view. This function can be performed by an internal team in a company that is preparing for implementation, a specialist from an external company or a representative of the implementation company / software supplier.

WHY IT IS WORTH APPOINTING A PERSON RESPONSIBLE FOR PREPARING A MOSCOW MODEL

Examples of requirements and different points of view

Integration with the electronic banking module.

For some departments in the company, such functionality will belong to the MUST HAVE group. Its implementation will allow them to avoid interfering with the content of bank transfers, exchanging account numbers, etc. However, for some employees these are requirements belongs to the COULD group, because transaction data can be entered manually, especially if the department / company does not perform many of them. The company will surely also have departments that would themselves qualify this functionality to the SHOULD group, because they believe that they can do without this functionality for a while, but ultimately, due to the number of transactions carried out, the requirement must be implemented to avoid manual registration.

VAT declaration automatically sent from the system.

This functionality, from the point of view of the finance and accounting department, belongs to the MUST HAVE area, because it is required by law. In addition, the requirement is even offered by small systems (which cost several hundred PLN). However, for the head of production who has no contact with this area of the company’s operation, it will not necessarily be MUST HAVE. From his perspective, a VAT declaration can be sent outside the system and this is the responsibility of the accounting departments. In addition, this is not an area of business that brings income.

Author

Piotr Podgórni – Head of Implementation in IT Vision. Solution architect, PM, consultant & trainer. A lot of international projects. Experienced in ERP, DMS, WMS, integration. Knowledge of business areas: accountancy, logistics, warehouse management, manufacturing, controlling, professional services.
Specialization: Microsoft Dynamics NAV/BC, Rambase, Oracle NetSuite