Pre-qualification/pre-selection for single use

[jpmckinney]

Context

The proposal in this issue is for pre-qualification/pre-selection leading to a single request for tender (i.e. the pre-qualification stage produces a single-use list of qualified suppliers).

There is another issue for pre-qualification/pre-selection leading to a multi-use list or similar: #909

Background

This issue is to break up #440 into smaller issues. This comment #440 (comment) has a proposal for how to model two-stage procedures in OCDS without causing backwards-incompatible changes. This issue specifically focuses on procedures with a pre-qualification or pre-selection stage.

Broadly speaking, such procedures have a first stage in which potential suppliers submit requests to participate. Submitters are qualified/selected based on their submissions, according to qualification/selection criteria. If there is a limit to the number of qualified candidates, then this stage is known as pre-selection instead of pre-qualification, and involves score/rank criteria instead of pass-fail criteria. Qualified/selected candidates then submit tenders in a second stage. (See UNCITRAL Glossary)

Qualification/selection criteria can presently be expressed using the requirements extension.

Proposal

First stage model

Per #440 (comment), the first stage should be modelled using the tender block. Indeed, this is already the block to which the requirements extension adds a criteria field to express qualification/selection criteria, which need to be known in the first stage. (Related: #590)

The qualification extension – which will be deprecated per the linked comment – is the present solution for pre-qualification/pre-selection and has the same structure as the tender block, with one difference (mentioned later). Given that it has the same structure, most fields in the tender block can be used without modification for the first stage of a procedure with pre-qualification/pre-selection, just as they were in that older solution. awardCriteria, awardCriteriaDetails and awardPeriod will still refer to the award that occurs after the second stage.

As for tenderPeriod, numberOfTenderers and tenderers, we need to make a decision. For tenderPeriod, we can either, in order of preference:

1. Add submissionPeriod and deprecate tenderPeriod. And then, either:
   1. If tenderPeriod is used, then it should be interpreted as 'submission period'.
   2. If tenderPeriod is used, then it should be interpreted as 'submission period for tenders'.
2. Use tenderPeriod to mean 'submission period'.
3. Add a field like participationPeriod to mean 'submission period for requests to participate' and leave tenderPeriod to mean 'submission period for tenders'.

For numberOfTenderers and tenderers, the options are similar. For option 1, the new fields would be numberOfSubmitters and submitters . For option 3, I don't presently have a proposal for field names. (Related: #903)

The first two options are preferred to the third, because, for example, if potential suppliers are looking for opportunities, they care about the submission period for the first stage, not for the second stage. And the first option is preferred to the second, because tenderPeriod is a confusing term for 'submission period'.

Sidebar: We can add qualificationPeriod (the one difference from the qualification extension) to mirror awardPeriod; however, I want to check the supply and demand for this field, as it's more relevant to know the expected date on which invitations to submit tenders will be sent, rather than the start/end date of an internal process. (That said, neither of these concepts is considered in this proposal.)

In terms of party roles, the parties submitting requests to participate should have a 'submitter' party role, to distinguish them from a 'tenderer'.

There is presently no extension (in either the older or this solution) to disclose the requests to participate (i.e. there is no extension that mirrors what the bids extension does for tenders).

Second stage model

Now, to model the second stage, continuing from the linked comment, we'd have a secondStage object to describe the stage, and then an array for each part of the stage (e.g. in a competitive dialogue or an electronic auctoin, there can be many rounds). For this issue, the array would have a single object for the invitation to tender. This object would match the current tender block (though we can decide to update the field names as above), but with fewer fields, so that we're not disclosing the awardPeriod, etc. in two places. What remains is to at minimum decide the name of the array field.

Update: This array field might have different objects depending on the procedure (e.g. competitive dialogue rounds, framework agreement mini-competitions) and techniques (e.g. electronic auction rounds) used. Having different objects in an array is harder to use, implement and validate. Instead, we can have different fields depending on the type of second stage. Similar to initiationType (which is presently used to distinguish PPPs in the first stage), we can add a secondStage.type field. In the case of pre-qualification/pre-selection, the array field can be invitations.

In terms of party roles, the parties that are qualified can be given the 'qualifiedBidder' code from the qualification extension; however, if that extension is rarely used, we can use a more flexible 'candidate' code. There can be an secondStage.candidates field to refer to these parties. Any 'submitter' that is not a 'candidate' can, by implication, be determined to be not qualified; however, an explicit indication can be considered like the 'disqualifiedBidder' code. The parties submitting tenders should have a 'tenderer' party role, like in an open procedure.

Award stage model

We will need to add an invitationID field to relate the Award to the Invitation in secondStage.invitations.

Next steps

• Decide what to do about tenderPeriod, numberOfTenderers and tenderers in tender.
• Decide on the name of the array field to go in secondStage (which is a new object between tender and awards).
• Decide whether to mirror the changes to the tender block in the object for the invitation to tender under the secondStage block.
• Update the titles and descriptions of fields and codes used in the tender block. We can refer to "first stage" and/or to use constructions like "tenders or requests to participate", "invitations to tender or to participate", etc. like in the EU forms.
• Add a 'submitter' code to the partyRole.csv codelist, as above
• Decide whether to add a 'candidate' code, or use the 'qualifiedBidder' and 'disqualifiedBidder' codes from the qualification extension.
• Add an awards.invitationID field.

Note: The preQualificationStatus.csv codelist has no new codes compared to tenderStatus.csv.

[jpmckinney]

@yolile How does the above proposal sound for pre-qualification in Paraguay? There are a few decisions to make, in the bullet list.

[jpmckinney]

For the array field, it would have different objects depending on the procedure (eg competitive dialogue) and techniques (eg electronic auction) used. This is harder to use, implement and validate.

Instead, we can have different fields depending on the type of second stage. Similar to initiationType (which is presently not used except to distinguish PPPs in the first stage), we can add a secondStage.type field.

The field name for the second stage after pre-qualification/pre-selection can be tender, though this might be confusing until the top-level tender is renamed. It can be invitation instead.

[jpmckinney]

@yolile For Paraguay's current implementation, in the tender block, I'd recommend using the current fields (tenderPeriod, etc.), even if the proposal here is to deprecate them in favor of new fields – because it's not certain that the proposed field names will be approved.

If the proposal sounds good to you, then what's left to do is to author the proposal as an extension (minus the deprecations and the changes to titles and descriptions of existing fields).

[yolile]

Thanks for this @jpmckinney , your proposal looks good, but, the only problem that I see with Paraguay is that the prequalification and its tender are different processes so, they have differents ocids. The ocid for the second stage (tender) comes from the planning. And the ocid for the first stage (prequalification) comes from the prequalification itself. And the link between the tender and the prequalification is set when the tender is made, not before. So if we use, for example, the prequalification number as ocid, the planning data will not be disclosed until the tender is made.

[yolile]

Should we use the relatedProcess to link both processes? If yes, should we add the "preQualification" code to the related process codelist? (what I was planning to do we the existing qualification extension)

[jpmckinney]

Hmm, I need to understand how Paraguay's system works:

1. There is a process, whose result is to put suppliers on a list. This list will be used to invite suppliers to submit tenders. The list is single-purpose and single-use, i.e. it is never used for any other invitations to tender. It is already known at the time of this process what the list will be used for. This process never results in any awards or contracts.
2. There is another process, whose result is to award a contract. This process takes the list from the first process, in order to invite the listed suppliers to submit tenders. No other suppliers are invited.

If that's how it works (please confirm), then in OCDS, this must be modelled as one contracting process. A process that, by design, never results in awards or contracts is not what OCDS considers a 'contracting process'. In the UNCITRAL Model Law, in many other jurisdictions, and similarly in OCDS, pre-qualification is just the first stage of a two-stage process.

The thing I don't understand is how it's possible that suppliers are pre-qualified without there being a plan to justify their qualification. If a government has a pre-qualification process to identify qualified suppliers of uniforms, surely there must first be a plan to procure uniforms? If they don't plan to procure uniforms, then they are wasting suppliers' time. Can you clarify?

In any case, if it's impossible to know what invitation to tender the pre-qualification is for until after the pre-qualification is complete, then I suppose there can be one OCID for the pre-qualification + tender and then another OCID for just the planning (which, as it precedes the start of a contracting process, is an exception to the rule above), and using relatedProcesses to relate the two using the existing 'planning' code.

The OCDS governance process decided against having a 'preQualification' code in #371, so using one would not be conforming to OCDS.

[yolile]

The list is single-purpose and single-use, i.e. it is never used for any other invitations to tender.

Sometimes, it can be used for multiples tenders, for examples, when the tenders are too similars example:
https://contrataciones.gov.py/licitaciones/convocatoria/338225-servicios-consultoria-fiscalizacion-obras-construccion-puentes-hormigon-tramos-no-me-1/precalificacion.html#licitaciones_asociadas

Or after an unsuccessful tender the same prequalification can be used for the new one.

if it's impossible to know what invitation to tender the pre-qualification is for until after the pre-qualification is complete,

Yes, it's impossible.

[jpmckinney]

Sometimes, it can be used for multiples tenders, for examples, when the tenders are too similars

I see there are two requests for tender about 7 months apart (first, second). The pre-qualification was completed not long before the first request for tender.

It sounds like this process in Paraguay is more like a 'multi-use list' as defined in GPA:

a list of suppliers that a procuring entity has determined satisfy the conditions for participation in that list, and that the procuring entity intends to use more than once;

This is more like a framework agreement in structure. The proposal above is more for a (typical) restricted procedure in structure. I'll create a separate issue for this distinct structure.

Or after an unsuccessful tender the same prequalification can be used for the new one.

Can you describe or link to an example of this? In other jurisdictions, if a procedure with pre-qualification is unsuccessful, I can't think of an example where the next procedure uses the same list of qualified suppliers (for example, a common problem is that not enough qualified suppliers submitted requests to participate).

[jpmckinney]

New issue is #909.

[duncandewhurst]

Thanks for this proposal @jpmckinney

I'd like to clarify a few points.

Firstly, should:

Qualified/selected tenders then submit requests for tender in a second stage. (See UNCITRAL Glossary)

actually read:

Qualified/selected tenderers then submit requests for tenders in a second stage. (See UNCITRAL Glossary)

Secondly, is something missing from the following part of the proposal? I didn't understand it.

1. Add `submissionPeriod` and deprecate `tenderPeriod`. And then:
   
   1. If `tenderPeriod` is used, then it should be interpreted as 'submission period'.
   2. If `tenderPeriod` is used, then it should be interpreted as 'submission period for tenders'.

Thirdly, I want to check I understood the overall model you are proposing:

{
  "ocid": "",
  "tender": {
    "method": "?"
  },
  "secondStage": {
    "type": "?",
    "candidates": [
      {
        "id": "",
        "name": ""
      }
    ],
    "invitations": [
      {
        "id": ""
      }
    ]
  },
  "awards": [
    {
      "id": "",
      "invitationID": ""
    }
  ]
}

This threw up a couple of questions:

1. Which object should the procurementMethod field should appear on and how should it populated?

2. What is the codelist for the secondStage.type field?

3. Is another field required on the objects in the secondStage.invitations array to indicate which suppliers were invited to a specific round (or call-off)?

[jpmckinney]

1. Thanks! There were a few typos in that paragraph, now corrected.
2. I think an 'either' was missing at the end of the first bullet. Does that clarify?
3. Answers:
   1. procurementMethod is disclosed in the first stage, i.e. tender. It is populated according to the GPA definitions (which match UNCITRAL definitions, though using different terms). In the EU context: 'open' applies only to the open procedure; 'selective' applies to most other procedures, as most others have pre-qualification/pre-selection as the first stage; 'limited' applies in exceptional cases where it is justified to award a contract without a call for competition; 'direct' still applies to single-source procurement (a subset of 'limited').
   2. This is to be determined, once additional second stage types are developed, in separate issues. The one model developed thus far satisfies the types considered thus far.
   3. I'll clarify that this issue is for a single round, to which all candidates are invited. For framework agreements, competitive dialogue, etc. with many mini-competitions, call-offs, rounds, etc. there'll be a new issue (or, it might be covered in Pre-qualification for multi-use list #909).

Separately, I note that some jurisdictions model pre-qualification as a separate process, though this doesn't match the desired semantics of OCDS (New South Wales: #371 (comment)).

[jpmckinney]

UNCITRAL glossary defines:

ID	Term	Definition	Reference
53	Pre-qualification	Defined in the Model Law as: “Procedure set out in article 18 of this Law to identify, prior to solicitation, suppliers or contractors that are qualified.” For the explanation of the terms “solicitation” and “supplier or contractor”, see ## 79 and 85 below.
54	Pre-qualification documents	Defined in the Model Law as: “Documents issued by the procuring entity under article 18 of this Law that set out the terms and conditions of the pre-qualification proceedings.” For the explanation of the term “pre-qualification”, see # 53 above. For the explanation of the term “procuring entity”, see # 62 below.
55	Pre-selection	Defined in the Model Law as: “Procedure set out in paragraph 3 of article 49 of this Law to identify, prior to solicitation, a limited number of suppliers or contractors that best meet the qualification criteria for the procurement concerned.” For the explanation of the terms “solicitation”, “supplier or contractor” and “procurement”, see ## 79, 85 and 58 below.
56	Pre-selection documents	Defined in the Model Law as: “Documents issued by the procuring entity under paragraph 3 of article 49 of this Law that set out the terms and conditions of the pre-selection proceedings.” For the explanation of the term “pre-selection”, see # 55 above. For the explanation of the term “procuring entity”, see # 62 below.

EBRD glossary lists:

UNCITRAL Model Law Terms	Description Notes	Others in use or similar Terms
Pre-selection, pre-selection documents	Choosing amongst the prequalified the ones best qualified to be solicited.	Shortlisting (World Bank, EBRD)