‘How-to’ for MoSCoW Method: Resolving Fundamental Problems

Published on December 8, 2018

The MoSCoW method exists for many years already and the common opinion is that this method is for prioritising requirements, business or technical. It is used for achieving a shared understanding (Problem #1) with stakeholders on the priority they (Problem # 2) identify for each requirement.

Apparently, MoSCoW is only a method of describing priorities for implementation of each requirement. How the priorities are defined and who makes these decisions remains behind the scene. Who influences the decisions is a different question.

To understand the major driver for particular requirements, we have to look a bit higher into the hierarchy of an organisation. I mean the entire company, not its IT. We can see there a corporate strategy usually expressed in the monetary terms, market positions and market domains, i.e. in tasks defining what the company top management (and, possibly, shareholders) wants and needs to reach. The strategic objectives are understood in the form of business capabilities that, for the implementation purposes, grouped in portfolios and, further, in the programmes. Each one of them has its own objectives. Together they form a hierarchy where the lower level is a detalisation of objectives of the higher level.

Thus, when we climb down to the level of Programme or Project, their tasks also have objectives in the mentioned hierarchy. This takes place in both business and technology parts of the company. Evidently, individuals, which later become stakeholders, influence the objectives at each level, but the drivers remain with the hierarchy of corporate objectives.

This analysis of corporate environment for each task clearly shows that the preferences of individual stakeholders for each requirement should be in line with the Programme or Project objectives. Otherwise, they should be challenged against the Programme or Project objectives. This is the basic benchmark that helps to separate subjective wishes from the objective requirements. This is true for both business and technology parts of each Programme and Project.

A Change Management is a well-accepted mechanism for managing changes in the company via recognising and implementing requirements for delivering particular business objectives. The main duty of a Change Management is to preserve realisation of objective requirements. However, there are a lot of examples where requirements are substituted by someone’s wishes (like ‘this manager wants that’). Well, subjective requirements also can be accepted and addressed, but their priorities should be conditional: the objective requirements must be realised first (as ‘M’ or ‘S’ in MoSCoW) and, if resources and time allows, subjective requirements may be realised as well (as ‘C’ in MoSCoW).

Nevertheless, for example in IT, usually all business requirements are ‘must have’ (‘M’ in MoSCoW). There are two reasons for this: 1) a notion of objective, coming from ‘above’, requirements and subjective ones is presented in the business realm and people try to camouflage personal needs as objective – ‘must have’ – which gives them higher chance for realisation, and 2) when a requirement is defined by a person or a small team of people based on his/her/their needs, such requirement is seen very important for those people, i.e. ‘must have’ as well. However, the Best Practice states that all requirements specified in the business should be validated in the business before they ma be exposed to IT. In real life, this Practice is usually omitted resulting in many troubles in Programmes and Projects.

The Problem #3 is in an artificial separation between business and technology parts in the Programmes and Projects. The management and architectural functions should cross this boundary and have equal authority over the business operational processes and technology means of the Programmes or Projects. The major benefits for the company from such ‘umbrella’ management-and-architecture are:

1.     Consistency of the requirements – all requirement authors should represent the business reasons and values of articulated requirements to the Programme/Project Steering Committee. This will significantly reduce subjectivity of them and increases linkage to the corporate strategic directions and needs
2.     Better resource management – the human and technology resources can be better prioritised and aligned with the business plans
3.     Management of the Programme/Project can have better visibility and flexibility in the tactical decisions even when IT implements the tasks in an agile manner (focus on the present step).

Currently, we have business requirements that are defined for IT while no Target Operating Model (TOM) in business is defined. This allows business Change Management to create unnecessary and even valueless sub-requirements in the form of uncontrolled Use Cases and User Stories related to HOW the Programme /Project should implement the tasks instead of WHAT to be implemented. I do not accept when a Change Management dictates Programme/Project management how to realise specified tasks. A Change Management is usually incompetent in the methods of delivery and is not responsible for the delivery. In order to avoid such invasion of Change Management, a special control and methods may be recommended for gathering requirements (in business and technology) and their validation. Just an individual opinion of a business BA is immaterial unless it is supported by objective needs and values that can be used in the business value streams of TOM. An absence of TOM leads to weakened control over deviations from the objectives.

Method #1. If requirements are only in the phase of gathering, each expressed statement may be accepted as a requirement for a particular Programme / Project if all conditions below are satisfied:

a)      A relevance to the strategic objectives of the company, or its division, or its department is specified and makes sense

b)     A business value that could be created by implementation of this requirement is specified and can be positioned in the TOM value stream (existing or new)

c)      A relevance to the objectives of the Programme or Project and makes sense. Related management (with architectural support) should decide on the relevance, not business Change Management. A requirement may be quite valid from the business perspectives, but not related to the current Programme or Project.

Method #2. If requirements are already gathered and Method #1 was not applied, the management of the Programme or Project must perform a requirement analysis – the revision and acceptance exercise. Each requirement should be accompanied by the Acceptance Criteria, which can be expressed in a way that without an additional information such as business value and relevance to the Programme/Project objectives the requirement is not accepted into implementation. This is about value-for-money and value-to-the-market; the power of a good management is not in making no mistakes, but in how well it is in the mistake overcoming.

Concluding this observation, we can state a few Tips for the practitioners.

1.       Never argue with a stakeholder – let him/her to face the project objectives and Programme/Project management
2.       A requirement may be important, but not for your project [“customer is always right, but not always right for you”]
3.       Requirements must reflect the objectives and never considered as a self-sufficient entity – if a stakeholder wants something, this must be included in the objectives. If it is not included, it does not matter for the project.
4.       “It is imperativefor 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”.
5.       “The safe percentage of Must Have requirements, in order to be confident of project success, is not to exceed 60% Must Have effort”.

“Prioritisation can be applied to requirements/User Stories, tasks, products, use cases, acceptance criteria and tests, although it is most commonly applied to requirements/ User Stories”.