MoSCoW Principle

Prioritise actions and resources to maintain control in time critical environments

Note: Firstly, listen to the audio discussion the read the text.

Back in 2008, I was managing a project for an international defence company in a challenging environment. The project was complex, and it quickly became clear that meeting all the objectives wasn’t realistic due to various constraints.

Part of the job involved submitting a weekly summary to a government minister.

To ensure my reports provided clear, credible reasons for the decisions I was making, I needed to add a recognised and practical method to support my decisions and explain why – They are whats known as satisficing decisions.

That’s when I first started using the MoSCoW Principle to add weight to my methodology.

In this lesson, we’ll explore how this widely used method can help you categorise, prioritise, and make decisions effectively on what will or won’t be implemented in the crisis management plan and the reasons why.

Its works well when your analysing the reasonable and practicable process to what mitigation will be implemented.

Note: There is a MIldot Group premium article on whats reasonable, practicable and evidencing principles.

Lesson Objectives

This lesson will introduce you to:

The principles of the MoSCoW prioritisation framework.
How priorities change during a crisis.
The application of MoSCoW to crisis management and business continuity.
Practical methods for prioritising people, resources and organisational effort.

Learning Outcomes

By the end of this lesson, you will be able to:

Explain the principles of the MoSCoW framework.
Apply the MoSCoW principle to crisis management and business continuity.
Prioritise activities using the Must Have, Should Have, Could Have and Won’t Have model.
Recognise the need to review and adapt priorities as an incident develops.

Some Background

The MoSCoW principle (Must Have, Should Have, Could Have, and Won’t Have) was created by Dai Clegg while working at Oracle in 1994. This prioritisation framework was introduced as part of the Dynamic Systems Development Method (DSDM), an Agile project delivery framework.

The MoSCoW principle provides a structured way to prioritise requirements or tasks based on their importance to project success.

It has since been widely adopted across industries for its simplicity and effectiveness in managing stakeholder expectations and ensuring the focus on delivering critical elements first.

The acronym “MoSCoW” stands for four categories of prioritisation:

M – Must have
S – Should have
C – Could have
W – Won’t have (this time)

Principle Definitions

After completing the protective security counter terrorism Needs, Threat, Vulnerability, and Risk Assessment (or a similar process to identify requirements), you’ll end up with a long list of potential requirements.

Next, you’ll evaluate the mitigation strategies available, apply a protection in depth approach, and consider response and recovery options. Some of that information will be documented in the crisis management and business continuity plans.

These lists and strategies need to be broken down, prioritised, and reported clearly, with valid explanations to support your decisions and recommendations.

Here’s a detailed explanation of each category and how to use the MoSCoW principle effectively:

1. Must Have

Definition:

These are non-negotiable requirements that are critical to for success. Without these, the project or operation would fail or not meet its primary objectives.

Characteristics:

Essential for system functionality or delivery.
Considered the Minimum of requirements.
Must be completed to ensure the goals, regulations, and laws are met.
Crisis management is delivered effectively.

2. Should Have

Definition:

These requirements are important but not critical. They add significant value, but the plans can still succeed without them in the short term.
A Should Have could also be an Enabler for a Must Have.

Characteristics:

High priority but not mandatory for laws and regulations.
Can be revisited at milestones.
Workarounds might be available if these are not implemented immediately.

3. Could Have

Definition:

These are desirable features or requirements that would enhance the plans but are not essential.
They are often considered nice to have and can be deprioritised without significant impact.

Characteristics:

Lower priority compared to “Must Have” and “Should Have.”
Typically included if time, cost and resources allow.
Often used to differentiate a basic plan to a comprehensive plan.

4. Won’t Have (this time)

Definition:

These are requirements or features that are agreed upon as out of scope for the current situation.
They may be revisited in the future.

Characteristics:

Clearly documented and communicated to avoid scope creep.
Not critical to current goals but may be considered in subsequent phases.
Helps manage stakeholder expectations.

How to apply the MoSCoW Principle

Gather Requirements:

Collect all potential requirements, tasks, or features from stakeholders, team members, and end-users.

Facilitate Prioritisation Discussions:

Engage with stakeholders to assess the importance and urgency of each requirement.
Discuss trade-offs and constraints like budget, time, and resources (Reasonable & Practicable).

Categorise Requirements:

Assign each requirement to one of the four MoSCoW categories.
Use questions like:
- What will happen if this is not delivered?
- Can the mitigation still succeed without this feature?
- Is there a workaround available?

Communicate and Document:

Clearly document the prioritisation and share it with all stakeholders to manage expectations.

Ensure alignment on the scope of deliverables.

Regularly Reassess:

Review the MoSCoW categories as plans progress.
Business priorities and constraints might change, necessitating re-prioritisation.

Benefits of Using MoSCoW

Clarity: Provides a clear framework for prioritisation.
Focus: Helps teams concentrate on what is most important for success.
Efficiency: Avoids wasting time and resources on low-priority tasks.
Stakeholder Alignment: Ensures all parties understand and agree on priorities.

Common Pitfalls and How to Avoid Them

Overloading the ‘Must Have’ Category:

Avoid marking too many requirements as Must Have, as this defeats the purpose of prioritisation.
- Be strict about what is truly essential. Assess Laws, Regs, Aims & Objectives.

Poor Stakeholder Engagement:

Involve all relevant stakeholders in prioritisation to prevent misalignment.
- Facilitate workshops to ensure consensus.
- Senior Management must be aligned with your decisions.

Lack of Reassessment:

Regularly review priorities, especially in dynamic situations where requirements can change.

Ignoring Dependencies:

Consider dependencies between tasks or features.
A Could Have might become a Must Have if it enables the aims and objectives.

Examples

These are only examples, but they do cover lots of real world systems you may need or not.

Must Have

These are critical capabilities. Without them, the organisation is unlikely to manage the crisis effectively.

A documented Crisis Management Plan.
A documented Business Continuity Plan.
Defined crisis management team roles and responsibilities.
Incident reporting and escalation procedures.
Emergency contact lists for staff and key stakeholders.
A reliable incident communication and message management system.
Procedures for communicating with employees, customers and regulators.
Alternative methods of communication if primary systems fail.
Business critical function recovery procedures.
Regular exercising and testing of crisis and continuity plans.

Should Have

These significantly improve the organisation’s ability to respond but are not essential during the first stages of the incident.

Department specific continuity plans.
Pre prepared media statements and communication templates.
Stakeholder communication matrices.
Mutual aid or supplier support agreements.
Remote working arrangements for key personnel.
Recovery checklists for critical business functions.
Incident log templates and decision recording processes.
Staff welfare and wellbeing procedures following an incident.
Training programme for crisis management team members.

Could Have

These provide additional resilience and improve efficiency but their absence is unlikely to prevent an effective response.

Crisis management software dashboards.
Mobile incident management applications.
AI assisted message drafting and information management.
Live operational status dashboards.
Dedicated crisis management room with specialist technology.
Automated staff notification systems.
Social media monitoring tools.
Digital document libraries and knowledge management systems.
Specialist external crisis communications advisers.

Won’t Have

These are capabilities deliberately excluded because they offer little value, duplicate existing arrangements or are disproportionate to the organisation’s risk.

Multiple crisis management software platforms performing the same function.
Bespoke systems with no identified operational requirement.
Highly complex reporting processes that delay decision making.
Expensive technology that staff have not been trained to use.
Communication tools unsupported by existing business processes.
Recovery arrangements for non critical business functions during the initial response.
Unnecessary approval stages before issuing urgent communications.
Capability that exceeds the organisation’s identified threat and risk profile.

Worked Example

Scenario: A serious violent attack has occurred at the main entrance to a busy shopping centre. Several people have been injured, members of the public are fleeing the area, emergency services are responding, and the incident is attracting significant public and media attention.

The Crisis Management Team has been activated to coordinate the organisational response.

Priority	Example
Must Have	Activate the Crisis Management Team. Confirm the safety and accountability of staff. Notify the emergency services if required and establish liaison. Activate the incident response and crisis management plans. Issue an initial holding statement to employees and key stakeholders. Establish a reliable incident communication and message management process. Record key decisions and actions. Protect critical information and maintain business critical operations where safe to do so.
Should Have	Provide regular updates to staff, tenants and partner organisations. Prepare approved media statements and customer communications. Establish welfare support for affected employees. Begin planning for partial reopening or alternative business operations. Maintain detailed decision logs for post incident review.
Could Have	Establish a dedicated family information centre. Use specialist crisis management software to monitor actions and communications. Monitor social media to identify misinformation and emerging concerns. Engage external public relations advisers to support longer term reputation management.
Won’t Have	Conduct a full debrief during the response phase. Produce detailed recovery reports before the incident is stabilised. Implement non essential business improvement projects. Reopen unaffected areas solely for commercial reasons before they have been assessed as safe. Introduce new systems or procedures that have not been tested or trained.

Learning Point

This example demonstrates that the MoSCoW principle is not simply about creating a list of priorities.

It helps crisis managers allocate limited time, people and resources to the activities that will have the greatest impact on protecting life, supporting the emergency response, maintaining organisational control and enabling recovery.

As the incident develops, priorities should be continually reviewed. For example, once the immediate response has stabilised, media management, stakeholder engagement and business recovery activities may move from Should Have to Must Have, reflecting the changing needs of the organisation.

Paralysis by Analysis

Something to consider for any occasions when you have to make decisions and keep things moving forward.

Paralysis by analysis refers to the state of overthinking or overanalysing a situation to the point where no decision or action is taken and creates risk stagnation. This often occurs when someone is trying to find the perfect solution or make the best possible decision.

Making good enough decisions is often the better approach. A good enough decision provides a foundation to start taking action.

You can learn from the results and adjust as needed, which is often more effective than overanalysing beforehand.

The good enough decision focuses on progress and is typically more valuable than perfection. Moving forward with a reasonable decision helps you achieve results and iterate over time.

The Balance = Satisficing vs. Maximising

Satisficing: Opting for an option that meets basic requirements and is good enough. This approach reduces stress and promotes action.

Maximising: Searching for the absolute best option. While sometimes necessary (high-stakes decisions), it can lead to paralysis by analysis.

In most situations, satisficing is the better approach because it balances thoughtfulness with practicality.

This doesn’t mean settling for mediocrity but rather recognising when further analysis won’t significantly improve the outcome.

Summary

Each example emphasises how the MoSCoW principle can prioritise requirements effectively while ensuring the right balance between feasibility and operational success.

Can also be used while applying the Reasonable and Practicable test. To keep moving forward use the Good Enough Principle.