You have listed your requirements and now you have been asked to prioritise them…
You want everything? And all of it in phase one?
Well, the reality is that you probably won’t get it all. Certainly not without risk to your budget and timeline. And, let’s be brutally honest here, saying that all of your requirements are a ‘priority one’ isn’t really prioritising at all is it?
Every project needs some flexibility, and without understanding, in advance, what you really need your new system to do and prioritising your requirements accordingly, you risk project failure. Luckily there are several features of MoSCoW prioritisation that are designed to help you to avoid wanting it all!
The challenge of fixed scope
Before we look at prioritisation, let’s take a moment to understand why a fixed scope is so problematic.
There are three constraints to every project; the scope (and this includes the complexity of the scope), the timescale and the cost, and any change to one of these constraints necessitates a corresponding change to at least one of the others. An increase in project scope will lead to an increase in budget, and a likely increase in time. If you want to speed up delivery you may need to descope requirements or increase the budget.
Remember that your delivery partner will have produced their time and budget estimations based on their understanding of your requirements at the time. It is only when their development begins that the complexity will be fully realised, potentially impacting the scope constraint.
Assuming that you do not have an unlimited budget, and a long, slow project is undesirable, the only variable that remains is the project scope. Prioritisation is key to defining the acceptable variance of your project scope. If you define all your requirements as Must Haves, you are fixing the scope of your solution, meaning that the only remaining variables are time and budget; at least one of these will certainly be exceeded.
What is MoSCoW?
MoSCoW stands for Must have, Should have, Could have and Won’t have (this time). Even the narrative names, rather than simple numeric system, provides a framework and definition to work to. Let’s take a look.
Must Have requirements provide the minimum that your organisation needs to conduct business successfully, and delivery of these items alone should provide some benefit. However, a solution that delivers only the Must Haves, although business viable, is unlikely to meet the expectations of the wider business.
Should Have requirements should be delivered under normal circumstances, and it is reasonable to assume that the majority will be delivered. A solution that delivers both the Must and Should Have requirements will meet the expectations of the business.
Could Have requirements might be delivered but are the least critical to your business. They provide a layer of contingency and could be dropped if the project becomes constrained by time or budget. A project that delivers Could Have requirements can be considered to exceed expectations.
Won’t Have (this time) requirements are those that will be delivered in future phases of the project. Your new system will provide a stable foundation for future development and descoping for the future will allow you to go-live earlier and start realising the benefit of the new solution.
Keeping the Must Have’s in Check
Typically, no more than 60% of your requirements should be prioritised as Must Have and around 20% of the requirements should be Could Haves. This means that there is always some contingency in your development to ensure that all the Must Haves are delivered, regardless of the complexity of these requirements.
As the development team plan which requirements will be worked on in each sprint, they will assign, and expect to deliver, a percentage of Should and Could Have items. These requirements can, however, be easily descoped from that sprint to ensure that the project remains to time and budget if required.
It is sometimes easier to start from a position where all your requirements are considered a Won’t Have. This means that you must justify why each requirement is needed and helps you think about what your minimum viable solution might be.
A simple way to think about your requirements is to ask yourself, “what would happen if this requirement was not delivered”? If the answer is anything other than, “the business cannot run” then you can decide whether it is a Should or Could Have requirement.
You can also consider whether there are workarounds if a requirement is not delivered. If there are, and the workaround is not so inefficient to make it counterproductive, then you should prioritise that requirement as a Should or Could Have.
Finally, think back to the main objectives of the project. If your requirement does not directly impact a project objective, then it is not a Must Have item.
Prioritisation to fix cost and time
New technologies are expensive, and budgets are never unlimited. This is especially true for non-profits who are dedicated to the delivery of important services and should, rightly, be protected.
Equally, it is important that your project does not slip behind schedule, and you are able to benefit from your new technologies as quickly as possible. The efficiencies and opportunities that your new system will bring should be realised as quickly as possible, giving your business the tools to meet your strategic objectives.
Prioritising is a vital part of a successful project. It keeps the development team focussed on the items that are most important to you and empowers the project team to take quick decisions about scope. Using the principles of a MoSCoW approach gives you a toolkit to make this task easier, allowing you to vary your project scope as required, to keep the project to time and budget.
