The MoSCoW technique of prioritising initiative requirements or features
The MoSCoW method of prioritization is well used by Business Analysts, Project Managers and Software Developers. The focus is on identifying and agreeing with key stakeholders what are the core levels of requirements that should be focused on more than others. This process of prioritization will then enable a better outcome in focusing the efforts of the team on the most important aspects of the solution given limited time and cost.
MoSCoW stands for: Must Have, Should Have, and Could Have.
There is significant opportunity for change practitioners to also adopt this technique to better prioritise a range of different change interventions. Too often, change activities are planned as a result of stakeholder requests, and not necessarily as a result of a prioritized approach of what approaches/activities provides the best outcome versus others.
1. Must Haves:
These are core, fundamental requirements that must be there for the end outcome to be there. These are the non-negotiable ones without which the goals of the project cannot be achieved.
For example, in implementing a new system, the users must know that the system is going to replace the previous system and the reason for this. Users must also know how to operate the new system prior to the older system being switched off.
2. Should Haves:
These are features or requirements that would have a high priority to reach the project outcome. These can often be core features that will add to the user/customer experience. However, they are not a must, and given challenges in time or cost they can be deprioritized.
For example, for a new system implementation it would be highly desirable to allow the users to access a sandbox to be able to play with the features prior to the launch to improve their readiness. It could also be that due to the large number of users using the system it makes sense to conduct a large scale awareness campaign to broadcast the arrival of the new system.
3. Could Haves:
These are nice to haves given sufficient resources such as time and cost. These requirements are definitely not critical and can easily be deprioritized as needed.
For example, in implementing the new system it may be nice to have coaching workshops with users prior to the go-live to offer additional learning support for those who may need more help. It could also be various system support materials such as cheat sheets, booklets, etc. to help the user embed the ins and outs of using the new system.
4. Won’t Haves (or Would Haves):
These are potential features or requirements that may be looked at in the future if there is sufficient resources available. This is the lowest in the order of priority, meaning that it will not make significant impact to the outcome of the project.
For example, in implementing the new system refresh training sessions could be offered later down the line for some users after go live. Depending on the organization and previous experiences an ‘embedment campaign’ could also be scheduled to drive continual usage of the system. But given the cost required these are deemed lowest in the priority.
In prioritizing change management approaches and interventions this way, we are adopting a structured method of determining the activities we are investing in to get the right outcome. The clarity of which interventions are core and foundational, versus others that are desirable or nice to haves is important to the success of the initiative. This could also avoid any disagreements or questioning of the change approach further down the line as the approach follows a structured and agreed process with stakeholders.
