The MoSCoW Method

The MoSCoW Method

Is The MoSCoW method useful in Salesforce implementations?

This is the overarching question we will be answering in this article. We will explain the MoSCow method, how it can be used, and what needs to be considered in order to make it a resounding success.

Firstly, what is MoSCoW?

The MoSCoW method is all about prioritisation – typically being used in business analysis, project management, and software development. It is a framework that helps a group of stakeholders prioritise what is most important in terms of delivery, by aligning user stories or functionality against a set of criteria:

M – Must be included in the delivery

S – Should be included in the delivery

C – Could be included in the delivery

W – Would like to have, but are not feasible for this delivery

How do we really use MoSCoW?

MoSCoW is used early in the project lifecycle and can be particularly useful where you have a group of stakeholders with different professional drivers. The first thing any manager of a MoSCoW project needs to do is align the stakeholders on the overall vision for the project and the objectives that underpin this. Any Salesforce project delivery should have these parameters clearly established from the outset also.

Once this is done and the requirements and user stories are established for the project, the manager will then work through each of these requirements with the team and agree whether they should be considered M, S, C, or W. Where there is an inconsistency of opinion, it is important to look back to the vision and objectives to help decide how important the requirement is in helping you fulfill your mission.

The output is a clearly defined set of requirements that are ranked in order of prioritisation by the key project stakeholders. This means that where agile delivery methods are used, sprints can be used to start delivering the ‘Must’s’ and work their way through to the ‘Should’s’ and ‘Could’s’ depending on the amount of remaining time in the sprint.

At the end of the project there is then typically a wrap-up phase where the team will assess what has been delivered, what can be swept up for prioritised delivery in the final phase, and how important the remaining ‘Should, Could, Would’s’ are now that the delivery has been implemented. This may inform the next phase of work.

Will this way of working help me achieve better results in my Salesforce delivery?

In most cases yes, although there are a few factors to consider such as the size of your team, the personalities of the stakeholders, the complexity of the scope, and the timeline for delivery. Typically, MoSCoW is most beneficial for Salesforce implementations where:

  • There are a lot of stakeholders whose requirements need to be consulted
  • There are different professional drivers and objectives amongst the team
  • The timelines are tight and the expectations high
  • You have a strong enough leader to be able to manage the team to commit to the prioritisations and keep them accountable throughout the delivery

If the above are parameters of your team and your Salesforce delivery, then we would recommend considering using the MoSCoW method.

The MoSCoW method when applied in the right way brings a lot of benefits:

  • Ensuring the business priorities are met
  • Successfully managing return on investment against a fixed timeline
  • Making sure that all stakeholders feel heard and are invested in the success
  • Ensuring that rollout delivers clear benefit for the end-users which will secure user adoption

Can MoSCoW go wrong?

Simply put, yes. The most important factor in the success of MoSCoW is the project lead. A strong leader will need to make sure that the vision and objectives are clear and that they can rationalise all requirements with the team against the appropriate prioritisation. This is not just a one-time job though, as the project progresses, project stakeholders may continue to push for changes in prioritisation to suit their individual priorities or changing needs. It is then down to the project lead to make sure any concerns are listened to and accounted for appropriately, but that the process and priorities are not changed without significant rationale as this is likely to displace other stakeholders.

Interested in reading more of our articles? Please click here.