The MoSCoW technique
Shaping the future of learning
So much to do but not enough time (or money)? This is a common predicament for many of us
Say you buy a house that needs renovating from top to bottom. Would you channel Laurence Llewelyn-Bowen and redesign every room overnight, filling it with designer furniture and replacing all the wallpaper? It’s more likely that you’d identify the priority (or most offensive) areas and tackle those first. The dirty old carpet might have to go before you move in, but for now you can live with the 1970s fireplace.
As so much of the prioritisation we do is sub-conscious, it can be easy to forget how useful it is as a technique for identifying the relative importance of a whole host of desired requirements, tasks, products and services. They’re all important, but which will deliver the biggest, most immediate benefits?
At Kineo we meet clients who’d naturally like to create bespoke, award winning elearning but have a limited timeframe and budget. We also meet clients who have ambitious plans for expanding their digital strategy but are subject to a staggered release of funds or constrained by their technical infrastructure for the foreseeable future.
It can be tempting to try and squeeze all the desired requirements into the agreed timeframe or budget, but inevitably the quality of the final outputs will suffer or not be fit for purpose. Also, too much pressure can be put on available resources. Something has to give.
So in situations like these, we find it helpful to use a technique known as MoSCoW. This is traditionally used in management, business analysis and software development to create a list of prioritised requirements. Whilst neither a radical or new technique (it was defined by Dai Clegg of Oracle UK Consulting in 1994), it can be extremely effective in identifying:
- the most important requirements
- the appropriate order for their delivery
- which requirements can be put off till future phases of the project.
MoSCoW stands for Must, Should, Could and Won’t:
- M - Must have this requirement to meet the needs of the business
- S - Should have this requirement if at all possible, but the project’s success doesn’t rely on it
- C - Could have this requirement if it doesn’t affect anything else in the project
- W - Won’t have this requirement this time but would like to have it later (sometimes Would or Want is used instead of Won’t to emphasis this as an option).
(The Os in MoSCoW are added to make the word pronounceable: they do not stand for anything.)
Essentially the technique operates on a scale from business critical down to ‘nice to have’ if the scope, budget or timeframe changes. The Must requirements are non-negotiable, or the Minimum Usable SubseT. A Must is a ‘big ticket item’: without it, the project could be unsafe, illegal, or pointless.
You could say ’why not just prioritise requirements numerically, identifying them as number one, two, three and so on?’ But this is hard to do - too many requirements become number ones because they all seem as important as each other. No one wants to demote a requirement to the bottom of the pile. The same goes for a system like High, Medium or Low: it lacks the specific definitions that enable you to prioritise in accordance with your project’s primary goals and success criteria. With MoSCoW it’s much easier to see what you’re doing during prioritisation and why.
If even one Must is not included, the project is considered a failure (if this isn’t the case, or there is a manual workaround, then it wasn’t a Must in the first place). Therefore, whilst you may try to deliver all the Musts, Shoulds and Coulds to begin with, it’s likely that you’ll lose a few Shoulds and Coulds if your timeframe or budget is threatened. You should strive not to lose them all, as this is where the added value and benefits come in: without the Shoulds and Coulds the project won’t be as successful or engaging as it could be.
But how can you maximise your chances of developing more than just the Musts? A helpful rule of thumb is to cost and scope the project so that it takes a maximum of 60% of the total effort to achieve the Musts and a maximum of 20% to achieve the Shoulds (taking 80% when the Musts and Shoulds are combined). This leaves 20% contingency to either achieve the Coulds or protect the Musts and Shoulds.
While generally very well regarded, the MoSCoW technique is sometimes challenged because of the potential ambiguity between the four definitions. For example, how can you distinguish between a Should and a Could? There is no golden rule, but a Should can be distinguished from a Could by evaluating the impact on the business if it’s not met (in terms of associated costs and people affected) or of course, the anticipated benefits for the business if it is.
Naturally there’ll always be debate in the team about the priorities, but that needn’t be a barrier to using this simple but helpful technique. The important thing is for all stakeholders to agree what the definitions mean early on in the project and have a system in place for handling any differences in opinion (eg by appointing a final decision maker, such as the project sponsor). Overall it provides a framework for keeping you focused on what’s important and not getting distracted by the ‘fun stuff’ or personal preferences.
Our top tips for using MoSCoW successfully
- Identify everything you hope to achieve with your project, in line with your (previously) defined objectives. These are your requirements for the project.
- Agree with all stakeholders what each definition means early on in the project (remembering that the definition of Must is non-negotiable).
- Categorise every requirement. As well as identifying the work you must carry out to achieve success, this allows you to create a roadmap of future enhancements (and ensure that the Coulds and Woulds are not forgotten).
- Control the number of Musts. Ask yourself ‘will the project fail if this isn’t met?’ - if the answer is no, demote it. Be strict with yourself.
- Cost and scope your project by allocating a maximum of 60% total effort for Musts and 40% for Shoulds and Coulds.