Risk Based Prioritisation

There are many ways to prioritise requirements from a customer. One of the most used ways is the MoSCoW the requirements. Split them into Musts, Shoulds, Coulds & Wont's. Unfortunately customer burnt by previously failed waterfall projects have a tendency to set everything as a Must, making it difficult to get a picture of what are the key requirements.

Ultimately every requirement delivers an element of value back to the customer. Therefore if we can apply this value to each requirement we can produce an indicative scale from highest to lowest. For example we could apply a value of revenue generated, or new customers signed up. The total of requirements would give us a total value for the project, and each individual requirement would then be a percentage of this.

Applying this type of "business currency" to requirements ensure that we can focus on the highest value requirements early in the delivery cycle With the option of deliverying them into production and hence release their value early in the cycle, which can only be good for the customer

The next stage is then to sort the requirements into relative risk, so that we can understand which could have the highest ( or worst ) impact on our project and therefore should be addressed early enough to ensure we can mitigate the risk without endangering the whole projects

This starts to give us a split of requirements into 4 sections, as shown in the above diagram. High Risk/High Value, High Risk/Low Value, Low Risk/High Value and Low Risk/Low Value.

It thus makes sense to address the High Risk/High Value items first as the potential impact is the highest, but also the amount of value each could release is also the highest. We then address all the Low Risk/High Value items next, and pick up any Low Risk/Low Value items if we have capacity.

At all times we try and avoid High Risk/Low Value items as they have the potential for a large impact, for caparatively little value release