Blog Posts Process Analysis

Project Selection Process S070

Blog: Biz-Performance, David Brown

S070 – Prioritise by Criticality

SIIPS Selection Processes (S).png

DEFINITION

S070 Prioritise Requirements Matrix by criticality.pngPrioritise 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.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="http://www.businessprocessincubator.com/content/project-selection-process-s070/?feed=html" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples

BPMN.org

XPDL.org

×