Project Selection Process S070

S070 - Prioritise by Criticality

DEFINITION

Prioritise the defined requirements to identify which ones are absolutely essential (mandatory) and without which any proposed solution would be unacceptable.

SUMMARY

The project team works with the key managers from the client organisation to categorise and agree priorities for each detailed requirement or question in terms of criticality, eg Knockouts, Business Critical and Desirable requirements.  It may also be possible to identify and delete any superfluous requirements.  The team should try to identify and focus on the key differentiating factors.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Finish):

• definition of detailed requirements or questions - R100 / R150

Dependent procedures (Finish-Start):

• issue of Invitation to Tender (ITT) - S080

RECEIVABLES

• detailed requirements (usually in Requirements Matrix format)

DELIVERABLES

• Requirements matrix prioritised by criticality

TOOLS

• Examples: Scoring Worksheet

DETAILED DESCRIPTION OF TASKS

The purpose of this process is to identify which aspects of the requirements are absolutely vital, and without which any proposed solution would be unacceptable.  This is useful for two main reasons:

• It helps the potential bidders to decide whether their solution may be feasible and thus avoid wasted effort both on the vendor’s part in preparing the tender and on the project’s part in evaluating the proposed solution.
• It  is used by the team to identify and reject proposals which would not meet the minimum essential requirements.

The results of this analysis may also be used to help in the definition of priorities by weight and the subsequent comparison of compliant tenders, but note that the concepts and purposes are not identical.

Mandatory / desirable

The concept of criticality used to be referred to as “Mandatory and Desirable” and the resulting tables were referred to as MAD lists.  Whilst this was theoretically a good approach it presented difficulties in practice because participants in the selection process tended to misapply the concept of “Mandatory”.  It was found frequently that requirements were labelled as “Mandatory” because they were seen as very important requirements without which the solution would be unsatisfactory.  However, with hundreds or thousands of requirements it was inevitably found that most proposed solutions failed to meet at least one of these requirements.   When this happened the project team would usually re-examine the requirements an d decide that they were not quite so mandatory as had been first stated.

To circumvent this problem, we now prefer to use different expressions to make the meaning of the concepts more clear.

Categories

The recommended approach is to use a three-tier system of priorities.  These would represent:

Knockouts	These are requirements which are absolutely vital to any proposed solution.  If a “knockout” requirement cannot be met then that solution should be rejected immediately.
Business Critical	These are requirements which are critical to the operation of the business.  If they cannot be met it would result in significant difficulties.  A failure to meet a business critical requirement would seriously reduce the attractiveness of the solution but would not rule it out.
Desirable	These are requirements which are genuinely of value to the organisation but which would not present any major operational difficulties if they could not be met.

Approach

The starting point for the process is the list of requirements, normally in the form of a requirements matrix  (which should already have been identified and agreed - see eg Process S040).  Alternatively, it may be possible to combine this process with the detailing of the list of requirements, depending on the organisation and complexity of the requirements.

The Requirements Matrix should show a list of detailed requirements, issues or questions in a format suitable for publication to potential vendors.  This will be annotated with a code to show the criticality of each item.

The criticality is best determined in a workshop with the key managers.  Alternatively, lists can be sent out to the managers individually, but it is hard to impose the correct understanding of the categories and to gain consensus in this way.