Skip to main content

Prioritisation of Improvement Options

When we have identified a number of options to improve our process, it’s important to prioritise these in terms of cost vs benefit and/or effort vs impact.

Once we have agreed the values of High, Medium and Low for each axis, we plot where each option will fall on the grid.

Generally we should be looking to prioritise opportunities which fall within the green boundary. Any that fall in or around the red boundary could warrant further consideration.

Tip

It may be useful to compare results from both grids, as what may look like a good low cost option could in fact create a lot of effort and vice versa.

Example Prioritisation Grids

MoSCoW

MoSCoW prioritisation is a technique which can be used to identify which requirements should be delivered as part of a change initiative.

Requirements are likely to range from “show-stoppers”, without which the process simply wouldn’t work; to “nice-to-haves”, which are likely to add little or no value to the overall output of the process (although they may keep your stakeholders happy).

M - Must have requirements

Must have requirements are needed to form the minimum useable process. They will usually include any regulatory requirements and / or requirements which deliver the minimum viable output for your customer.

S - Should have requirements

Should have requirements provide a mechanism for flexibility and contingency in the delivery of changes. Ideally they will be delivered in the first phase, if this is not possible then a work around will need to be implemented. Typically these requirements become the 'must haves' in the next phase of change delivery.

C - Could have requirements

Could have requirements should be considered especially those which are easy and inexpensive to implement. Like the 'should haves' these 'could have' requirements can be held back for future phases.

W - Won't have this time requirements

Won't have this time requirements are recognised but set aside for consideration at a later date. They may need other requirements to be delivered before they can be implemented. In some cases these requirements may be completely de-scoped from the initiative.