Have you found most prioritisation methods ambiguous?
If you’ve ever found wading through the vast number of prioritisation methods available confusing, consider the MoSCoW method as a more effective framework.
It provides a clear and simple structure, ensuring critical requirements are focused on and alignment to business goals and objectives are met. Additionally, this method avoids scope creep, where new requirements are not considered fully and added throughout the project lifecycle - often leading to going overbudget or overtime.
With this method, it’s important to ensure best results by involving all stakeholders – as well as reviewing and updating priorities on a regular basis to ensure priorities are continuing to be relevant and aligned to project goals. Furthermore, to avoid any confusion, it’s important to be clear and specific on requirements – as well as rearranging or adjusting priorities when circumstances or information changes.
The MoSCoW Method Acronym
What does the ‘MoSCoW’ acronym stand for?
1. Must have: project essential requirements – the project could not proceed without them
2. Should have: important requirements not critical to the project’s success
3. Could have: desirable requirements - but not necessary for project success
4. Won’t have: Deemed unnecessary / unfeasible for the current project.
The Method’s History
Whilst working at Oracle, Dai Clegg, software developer, created MoSCoW. Originally, it was created to assist his team in prioritising tasks during development work on product releases. Because it overcomes problems associated with simpler prioritisation approaches, MoSCoW works particularly well for project-based tasks. It is usually too simplistic and ambiguous to classify priorities into simply ‘high, medium, or low’. This is because it becomes challenging to define each priority, and it also does not map out any expectations; so, to avoid confusion, it is crucial to clearly define each priority.
Simply sequentially numbered priorities are weaker - as they deal less effectively with items that have a similar importance and may lead to prolonged discussions over an item that should be placed higher or lower on the priority list. In comparison, a ‘must have’ and ‘could have’ provides a clear indication of items and clear expectations for completion.
Minimum Usable Subset
The Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver. These may be defined using some of the following:
- The act of delivering at a specific time does not offer any significant benefits,
- Not legal without it,
- Unsafe without it,
- Cannot deliver a viable solution without it.
To determine if it is a ‘must have’ requirement, ask the following question: ‘what happens if this requirement is not met’? If the answer is that you would have to cancel the project, then it is a ‘must have’. If, however, it’s possible to work around the problem – including a painful workaround, then it should be classified as a ‘should have’ or ‘could have’ requirement but means that the deliverable is not guaranteed.
Comparison to Traditional Project Management
Generally, in project management, all requirements are treated as essential due to the expectation that all will be delivered. To determine effort allocation for ‘must have’ requirements, it is important to remember anything other than a ‘must have’ is merely a possibility. Furthermore, the ‘must have’s’ define the minimum usable subset (guaranteed deliverables).
In terms of how they will work and their definitions, it is important to consider how priorities are mapped out well before the project – the definition of a ‘must have' is very clear – although the difference between ‘should have’ and ‘could have’ is not. Due to its subjectivity, it is critical to ensure that there are clearly defined boundaries.
Each task has its own level of importance, priorities are established before starting the work, and these should be reassessed as work progresses.
When new work arises, it’s critical to be careful in introducing new requirements and not to increase the percentage of must-haves beyond an agreed project level. Priorities of uncompleted requirements should be reviewed throughout the project lifecycle to ensure they are valid, and at a minimum they should be reviewed at the end of each timebox and project increment.
Other Considerations
Using this MoSCoW prioritisation method, you can also use other non-time-based constraints, such as budget, needs and skillsets. This is because it can be used to prioritise tasks within any type of time-boxed project. Due to its flexibility, it can also be used alongside other constraint types. In terms of best practice, gaining input from all key stakeholders is critical.
Examples of an objective ranking or scoring system include:
- Weighted Scoring: A method that assigns different weights or importance to various factors/criteria when evaluating or ranking items, the method includes assigning numerical values / weights to each criteria, based on importance - then calculating a total score by multiplying the weight of each criterion by its corresponding rating or score.
- Value v Complexity: This compares the value or benefit of a particular item or feature with its level of complexity or effort required for implementation. It helps prioritise items or features based on their potential value and the resources needed to develop or implement them.
- Kano Model: Technique used to classify and prioritise customer requirements or features based on their impact on customer satisfaction. It categorises features into different groups: basic features expected by customers, performance features that positively impact satisfaction when present, and delight features exceeding customer expectations and create high satisfaction when included.
- Bug-a-Feature: Concept where a reported bug in a software or product is considered and treated as a potential new feature. Instead of considering it solely as a defect, it is evaluated from the perspective of adding value and enhancing the product's functionality.
- Opportunity Scoring: This method is used to assess and rank potential opportunities, such as sales leads or business prospects, based on predefined criteria. It involves assigning scores or ratings to each opportunity based on factors like potential revenue, probability of success, customer fit, and strategic alignment, allowing for prioritisation and resource allocation.
Are You Ready For a Digital Revolution?
Contact us today to set up a free consultation.
We're happy to teach you more about the services we offer.
