When managing any project, be it web design or something completely different, the project is usually broken down into many tasks, each with varying priority levels. Understanding these priorities and the order in which to approach them is pivotal to ensuring a project remains on track and those all-important elements are delivered as soon as possible. One way to manage this is through the use of the MoSCoW method.
The MoSCoW method, at its heart, is an analytical tool that allows a company to categorise particular tasks based on how fundamental they are to the project. The priorities are then usually agreed upon with the project owner or stakeholder to establish a common and agreed understanding surrounding the importance of delivery within the timeframe allocated for a project.
MoSCoW (other than being the capital of Russia) is an acronym that stands for, and sets, the project’s requirements. These are:
M – Must Have
Tasks labelled with ‘Must Have’ are absolutely crucial to the delivery of the project. From a Project Management perspective, all ‘Must Have’ tasks must be handled first to ensure these are included as a minimum before the product or service launches. Recognising that ‘Must Have’ tasks are fundamental to the project means that, internally, a project manager can press the importance of these elements, as delivering the project with a single ‘Must Have’ task missing, could be considered a failed project.
S – Should Have
Where ‘Must Have’ tasks are essential, all other allocations using the MoSCoW method are ways of prioritising “nice to have” tasks – an “if we can squeeze it in, we will do” approach (if you will). The highest priority of these is ‘Should Have’, which are still important but not crucial for the launch. ‘Should Have’ tasks on some occasions may be as pivotal as ‘Must Have’ jobs. However, the difference between the two lies in the time available for the project and establishing a realistic view of what is achievable in said time. So any tasks that are important but fall outside of the time available (taken up by the more important ‘Must Have’ tasks), are usually considered ‘Should Have’ features.
C – Could Have
Any features prioritised as ‘Could Have’ could be considered bonuses – it’d be great to get these into the project, but they aren’t essential. ‘Could Have’ tasks are started when all ‘Must Have’ and ‘Should Have’ tasks are complete, and there’s still time and resources available within the project.
W – Won’t Have
Last and, in this case, definitely least are ‘Won’t Have’ tasks. ‘Won’t Have’ features are usually agreed upon as dispensable by the stakeholders and, although they should still be included within the scope of a project, they aren’t traditionally scheduled into a dev or work queue by a Project Manager. ‘Won’t Have’ tasks are often revisited at the end of a project with the company and stakeholders to review any extra time and costs to implement these features if they’re still needed or wanted.
While the MoSCoW method has some drawbacks – for example, the prioritising process sets the importance of a feature but doesn’t allow you to decide between all tasks with the same priority – it’s a great way of aligning on expectations with a client, and delivering an agreed product.