How to do a MoSCoW Analysis and prioritise requirements effectively in a complex environment?
As a Business Analyst, the question of how to prioritise requirements may seem like an easy question to answer but it can also be wrought with a variety of complications and interesting complexities. Once you have overcome these potential complexities which can come with requirements prioritisation, the most relevant Business Analysis technique to apply is what is known as the MoSCoW Analysis.
This blog article will cover both how to apply the MoSCoW Analysis for requirements prioritisation as well as the considerations and complexities for a Business Analyst to understand about their environment before attempting to prioritise requirements.
So let’s start by talking about some of these complexities that can face a Business Analyst when it comes to requirements prioritisation.
#1: Different perspectives on what is important
This is probably the single most important factor that affects the Business Analysts ability to facilitate the activities around prioritisation of requirements. This is all about the key stakeholders of the project all having different opinions about what constitutes a certain level of priority. For example: The project manager might want to prioritise requirements based on when he/she will be able to deliver (based on timeframes, budget and resourcing) each requirement whereas the business stakeholder might want to prioritise requirements based purely on the value it will deliver to the business as a whole (regardless of timeframes, budgets or resourcing). When faced with a team that all have a different perspective on what is important it is very difficult for a Business Analyst to get a true priority agreed.
#2: Lack of leadership
This factor walks hand in hand with the previous factor (and is most likely the cause of it!) where people have different perspectives on what takes priority. A lack of leadership in the project or initiative team causes confusion around what is important and this is when people will end up providing their own perspective around priorities rather than following business priorities or guidelines. This causes problems in various ways and can put the Business Analyst in a very awkward position. Sometimes this lack of leadership can mean that a stronger or more senior stakeholder might get the requirements prioritised according to his/her team’s preferences due to his/her position and level of influence in the organisation rather than it being the true priorities for the good of the organisation. This leads to requirement priorities which is not necessarily being implemented in the most valuable or efficient manner and consequently reflects badly on the project as a whole.
It is imperative for a Business Analyst to receive clear direction from their project manager or project steering committee about what are the clear business objectives (with their relative priorities outlined) that requirements must deliver against so that the Business Analyst can use these business objective priorities to guide the conversations when requirement prioritisation activities take place.
#3: Not prioritising requirements
In some organisations or projects there is simply no formal and explicit effort undertaken to prioritise requirements at all. This doesn’t mean requirements are not in some sort of priority, it simply means that the requirements are not prioritised in a structured and collaborative way. This type of approach can cause problems when expectations are not managed about what will be delivered by when but it can also be that prioritising the requirements are very clear cut in a particular type of project and hence this informal way works in those circumstances. So although the Business Analyst must be very careful when choosing to not formally go through a requirements prioritisation activity, it can be the most logical and suitable approach for certain types of projects.
#4: Priority levels are not well defined
The last complexity or consideration for the Business Analyst to pay careful attention to before embarking on requirements prioritisation activities are simply the definition of the priority levels and what each priority means. Many organisations have adopted a method or set of priority levels which they are used to using without it necessarily being the most effective way to prioritise.
It is best for the Business Analyst to stick to an agreed best practice Business Analysis technique for requirements prioritisation, such as the MoSCoW Analysis. This ensures that the Business Analyst can be confident that they are using a method that has been proven to work in many different business analysis requirements prioritisation situations.
So now that we have discussed some of the common complexities in projects and organisations that make requirements prioritisation somewhat tricky for the Business Analyst lets now look at the MoSCoW Analysis technique and how best it can be applied.
The MoSCoW Analysis Technique
The MoSCoW Analysis is a very common and effective requirements prioritisation technique because it allows not only for three clear priority levels but also covers the requirements that will end up not being included in the currently delivery or project at all. This works very well because it allows people to explicitly agree the different priorities including the requirements, which will be excluded or referred to a future release.
Let’s have a look at how this prioritization technique works:
MoSCoW is an acronym.
M = Must
‘Must’ level requirements are those requirements which will definitely be included to be delivered. There is no negotiation around whether they will be delivered and are considered mandatory requirements.
S = Should
‘Should’ level requirements are those requirements which should be included if at all possible. If the project have capacity and time and it will not jeopardise any of the “Must” requirements, then these requirements should be delivered or included in whatever the prioritisation is done for.
C = Could
The ‘Could’ level requirements are the requirements which could be included if it doesn’t have any impact on any of the ‘Should’ or ‘Must’ requirements.
W = Won’t
The ‘Won’t’ level requirements tend to be the requirements which will not be included to be delivered or implemented this time but are requirements that would be favoured for a future delivery or implementation.
In Conclusion
As a final point to make, it is important that although the Business Analyst uses a best practice requirements technique, the outlined complexities listed here should be addressed as much as possible prior to embarking on a requirements prioritization activity to ensure a successful and accurate outcome.
