Jawn Lam

Priority-Based Requirements Matrix

Problem Solving & Decision MakingEssay3 min read

A tool to methodically organize and prioritize the different elements of a project or idea.

Adapted from MoSCoW prioritization (Dai Clegg, Oracle UK, in Clegg and Barker, Case Method Fast-Track, 1994, later the DSDM standard), with the musts-versus-wants split of Kepner-Tregoe Decision Analysis (Charles Kepner and Benjamin Tregoe, The Rational Manager, 1965).

What it is for

The purpose of the Priority-Based Requirements Matrix thinking tool is to methodically organize and prioritize the different elements of a project or idea. It's particularly useful in creative and innovative processes where clear documentation and understanding of required outcomes are essential for success. This tool assists in:

  1. Identifying Essential Elements. Determining which components are absolutely necessary for the project's success.
  2. Prioritizing Components. Ranking elements based on their importance, utility, and relevance to the core objectives.
  3. Distinguishing Between Wants and Needs. Differentiating between essential elements and those that are merely desirable.
  4. Eliminating Unnecessary Elements. Identifying aspects that are not required or could potentially hinder the project.
  5. Facilitating Team Alignment. Ensuring all team members have a shared understanding of what is crucial, beneficial, or irrelevant to the project.

By using this tool, teams can achieve a more focused and efficient approach to project planning and implementation, ensuring that key requirements are met and resources are optimally allocated.

Why use it

Documenting the expected results or products of a project is a crucial but often neglected step in creative and innovative processes. Without a clear understanding and agreement on what the final requirements are, it's challenging to generate effective ideas or solutions.

How to use it

Classify the elements of your idea or solution based on their importance or necessity, at one of four requirement levels:

  • 3, Mandatory. These are essential elements that must be included in any proposed idea or solution.
  • 2, Top Priority. Elements that are highly beneficial and should ideally be included.
  • 1, Low Priority. Elements that are desirable but not essential ("wants" rather than "needs").
  • 0, Not Required. Elements that should not be included in the proposed idea or solution.

If the categories provided don't suit your project's needs, feel free to create your own classification system. It can be helpful to prioritize or rank the requirements within each category you define, to give clarity on their importance or order of implementation.

Requirements sorted into four levels

Six requirements of a new scheduling tool for field crews, each at a level from 3 (mandatory) to 0 (not required). Write your own requirements over them and set each one's level; the counts follow. Illustrative.

2 Mandatory2 Top Priority1 Low Priority1 Not Required

  1. Not classedMandatoryTop PriorityLow PriorityNot Required
  2. Not classedMandatoryTop PriorityLow PriorityNot Required
  3. Not classedMandatoryTop PriorityLow PriorityNot Required
  4. Not classedMandatoryTop PriorityLow PriorityNot Required
  5. Not classedMandatoryTop PriorityLow PriorityNot Required
  6. Not classedMandatoryTop PriorityLow PriorityNot Required

3 Mandatory: Essential elements that must be included in any proposed idea or solution. 2 Top Priority: Elements that are highly beneficial and should ideally be included. 1 Low Priority: Elements that are desirable but not essential ("wants" rather than "needs"). 0 Not Required: Elements that should not be included in the proposed idea or solution.

Where it fits

The process recommends it at Establishing the Requirements, the last step of the Objective phase, after the goal is written and before any facts are gathered.

Related tools