Large projects can have many stakeholders, leaving a project without a clear and unified vision, this can at times impact on organisational performance. Defining the scope of requirement at an early stage sets the precedent and boundaries of what the project is and gains alignment from the outset.
What is a MOSCOW model in terms of project management?
The MOSCOW model was created by data specialist Dai Clegg and consists of four aspects. Elements that the project must have, elements which the project should have, elements which a business could have, as well as the elements which the project will not have (this time). Allowing a business to have a set vision of what success looks like and stakeholder agreement of the eventual outcome.
Why do we use the MOSCOW method for project management?
Not only does a MOSCOW project management tool define the boundaries and scope of the project. It also helps to shape the outcomes of what the project will deliver. This is extremely important when prioritising and defining outcomes where a business may have multiple projects running at one point in time, each requiring a vision of outcome.
The MOSCOW project management template takes into consideration performance indicators such as cost and time, as well as factors such as stakeholder importance to gauge an outcome of a project that is both satisfying to the company and stakeholder values. It also defines what is realistic to achieve based on the resources available.
When to use a MOSCOW model for project management.
A MOSCOW model is recommended to be outlined at the beginning of many projects. It is a great way to solidify stakeholder vision and also define the tendering process or the stages of review to ensure compliance to the scope.
Since the MOSCOW template for project management involves inputs from multiple managers in order to gain a broader consensus on the priorities of a project, a benefit of this method would be to ensure project has a larger diversity of ideas from stakeholders in different departments of an organisation. This can be a solution for many members of a project who believe that their opinions are seldom heard and understood by the company. Once alignment is agreed an operational team can deliver the project under the vision of a wider agreement.
Real World MOSCOW Example – Buying a Phone
To make a MOSCOW project easy to define, we have conducted a MOSCOW project on buying a new phone. Something many people can relate to doing intuitively in their own head whilst reviewing the options.
By using the MOSCOW project management method, the aspects of the ideal phone that they would require are laid out alongside less important features. By comparing these features to real-world phones, beside the contrasting these phones with performance indicators such as cost and effectiveness for stakeholders, the company will have had an enhanced understanding of which is the right phone, and which can be discounted and removed from an option. We will review this through the article.
Elements of a MOSCOW Model and how to use them
As discussed earlier, the MOSCOW model has four distinct elements, we will review each of these in more detail below.
Must haves
Features of a project with the highest importance for success are known as ‘must have’ elements. They are imperative to the success of the project and as such are non-negotiable. Without them a project could cease to be successful or seen to be successful by its stakeholders. Due to the simplistic nature of the MOSCOW project management template, these aspects have only a finite number and are more suited towards projects with a lower number of requirements. These features are mandatory and are decided when it is apparent that the project cannot continue if this feature is ignored, there are no ways to accomplish the same result via other features, and if the business cannot function without it.
Real World MOSCOW example must haves
Mentioned earlier was an example of a company purchasing a new phone, if this example were continued, the company would prioritise features of a phone that would be integral for success, such as access to 4G internet as well as the ability to make calls to clients. Since the clients are key stakeholders for organisational success, the ability to make calls to them are non-negotiable, and thus are ‘must haves’ according to the MOSCOW project management tool.
Should haves
Whilst still having a larger impact on the success of a project, the project features that managers ‘should have’ are not vital compared to features that are ‘must haves’. Should the project managers decide to include these features, additional value is created alongside the core values derived from the ‘must haves’
What separates this category of features from the core ‘must have’ features of a project is that these come with the luxury of considering them for future projects without the dangers of impacting the current project, as the original project would still be viable to complete without taking the ‘should have’ features into account.
Real World MOSCOW example should haves
Within the context of the example company, these features would translate to non-essential yet helpful items such as 5G internet. Whilst it would be a benefit to stakeholder relations if the access to them were faster through 5G internet, it is not essential as the use of 4G also supplies the phone with a more basic level of internet access. When the phones are compared against constraints such as cost, it would be up to the project managers to decide if these non-essential, yet advantageous features would be worth the higher price or the time taken to acquire the item.
Could haves
Aspects of a project with a smaller amount of impact on the outcome of a project are known as ‘could haves’. Due to their insignificance, they do not take priority when managing a project. Project managers can afford to remove these features if items in the higher two categories are found and the cost or time to implement are advantageous.
Compared to items on the ‘should have’ category, these have less value, although aspects of the ‘should have’ category are nonessential, they still add overall value, whereas items on the ‘could have’ category are both nonessential and add little value to the project.
Real World MOSCOW example could haves
In the example of a company choosing a phone, one could consider the addition of the high camera quality to be within this category. Although the ability to take high-definition pictures of their premises would be useful for their website, it would not be as valuable as a faster internet to connect with potential clients.
Will not haves
Finally, features which are placed in the ‘will-not-have’ category are not a priority for a certain project. Compared to items on the ‘could-have’ level which have a low priority, these features are not considered, meaning that a consensus is reached within a project that removes certain features entirely, in order to prevent scope creep, Scope creep occurs when many smaller features are added over time, exhausting valuable resources and performance indicators such as cost and time.
Real World MOSCOW example will not haves
A simplistic view of this in the mobile phone choice is the range of colours that a phone has and may be more aesthetically pleasing as a feature, however, if it is more costly, more resources would be depleted, meaning that the money that could be spent on enhancing stakeholder relations such as faster internet to connect to clients would have been used on a less important feature. By understanding that these features are not important to prevent scope creep, this category is important for the formation of a MOSCOW project management template. Whilst of course a phone will have some form of colour, in this example, it “Will Not Have” a bearing on the decision made.
Real World MOSCOW Example – Team signoff
Once the wider team have agreed the MOSCOW elements for the new phone, active agreement and signoff of the scope of the project is required. By actively participating in this, it creates the scope and buy in from the team. Below is an example of a signed off, highly simplistic MOSCOW for the phone.
Real World MOSCOW Example – Solution Signoff
Ultimately, a MOSCOW model is about solution alignment within a project. For this example, we are purchasing a phone, so it is important to review the options available. In this example the team have reviewed three, completely made-up phones.
Aligning to the needs from the agreed MOSCOW model, there is only one choice that the company could logically make. The Schnoodle Fixer delivers everything in the Must Have section. It has 4G internet and 16GB of storage. It also features a high-quality camera and although the memory speed is slow, this was not a consideration. It includes a camera if high quality which outperforms the should have element. Compared the Handsome Universe example, it is c8% cheaper.
MOSCOW is one tool in project management
Hopefully this example has highlighted the importance and power that running a credible MOSCOW model can deliver in project management, but it is only one tool in an arsenal that successful project managers will use in managing projects such as procurement projects or business process re-engineering. MOSCOW is a versatile tool, and can be adapted to many areas, so don’t be constrained in your thinking of it’s use. As a Norfolk based boutique management consultancy, we have implemented MOSCOW models in a variety of situations.