Bill Hartman proposes the MoSCoW mode for helping Designers to set creative priorities but it works for all new initiatives basically like requirements, new experiences or new products. MoSCoW is a technique for helping to understand priorities. The letters stand for:
- Must Have
- Should Have
- Could Have
- Won’t Have this time
The reason to use MoSCoW is that the problem with simply saying that requirements are of High, Medium or Low importance is that the definitions of these priorities are missing. Using MoSCoW means that priorities are specific. The specific use of Must, Should, Could or Won’t Have implies the result of failing to deliver that requirement.
Must Have
These provide the Minimum Usable Subset (MUS) of requirements which the project guarantees to deliver. This may be defined using some of the following:
- Cannot deliver on target date without this
- No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
- Not legal without it
- Unsafe without it
- Cannot deliver the Business Case without it
- Shark bite with mosquito frequency
Ask the question, “what happens if this requirement is not met?” If the answer is “cancel the project – there is no point in implementing a solution that does not meet this requirement” then it is a Must Have requirement. If there is some way round it, even if it is a manual workaround, then it will be a Should Have or a Could Have requirement. Downgrading a requirement to a Should Have or Could Have does not mean it won’t be delivered, simply that delivery is not guaranteed.
Less is more must always be your approach.
Should Have
- Important but not vital
- May be painful to leave out, but the solution is still viable
- May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork, etc.
A Should Have may be differentiated from a Could Have by reviewing the degree of pain caused by it not being met, in terms of business value or numbers of people affected.
Could Have
- Wanted or desirable but less important
- Less impact if left out (compared with a Should Have)
Won’t Have this time
These are requirements which the project team has agreed it will not deliver. They are recorded in the Prioritised Requirements List where they help clarify the scope of the project and to avoid being reintroduced ‘via the back door’ at a later date. This helps to manage expectations that some requirements will simply not make it into the delivered solution, at least not this time around.
Conclusions
Marketers, if you are not capable to set your priorities, you will probably build what I call a Frankenstein: a mix of everything, most probably ugly and not answering to the core needs of the client/consumer/user.
