prioritisation


While generally very well regarded, the MoSCoW technique is sometimes challenged because of the potential ambiguity between the four definitions.


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:


n the most important requirements; n the appropriate order for their delivery ; n which requirements can be put off till future phases of the project. MoSCoW stands for Must, Should, Could and Won’t:


n M – Must have this requirement to meet the needs of the business n S – Should have this requirement if at all possible, but the project’s success doesn’t rely on it


n C – Could have this requirement if it doesn’t affect anything else in the project


n 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 emphasise this as an option).


Just to be clear: 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, while 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.


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 will 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 (e.g. 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.


Emily Berry, Learning Consultant at City & Guilds Kineo


But how


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


e.learning age september 2015 27


Top tips for using MoSCoW successfully n Identify everything you hope to achieve with your project, in line with your (previously) defined objectives. These are your requirements for the project.


n Agree with all stakeholders what each definition means early on in the project (remembering that the definition of Must is non-negotiable).


n 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).


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


n Cost and scope your project by allocating a maximum of 60% total effort for Musts and 40% for Shoulds and Coulds.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46