Remove preQualification extension and update guidance accordingly

[jpmckinney]

Related: open-contracting/standard#906

https://standard.open-contracting.org/profiles/ppp/latest/en/framework/#ii-1-pre-qualification

[jpmckinney]

Still pending as of 2020 annual review of OCDS for PPPs.

[jpmckinney]

@duncandewhurst As I understand, the PQ extension is based on only this, on page 56 http://pubdocs.worldbank.org/en/143671469558797229/FrameworkPPPDisclosure-071416.pdf:

Request for qualification
Pre-qualification or short list
Request for proposal

As such, a lot of requirements seem to have been anticipated that perhaps aren't strictly necessarily. Mainly, what matters is to describe the first stage, whether it's PQ or not. For that, we have the tender block. The profile goes further in allowing the same level of the detail for the second stage (using the tender block for the second stage), but this isn't strictly necessary under the framework (nor are such details commonly publicly available, since the second stage just involves interaction with known, qualified bidders). The https://extensions.open-contracting.org/en/extensions/secondStageDescription/master/ can be used or expanded to provide some of the details about the second stage (published at the time of the first stage).

In this way, we can align OCDS for PPPs with OCDS, and delete the confusing pre-qualification extension repository.

[duncandewhurst]

I'm in favour of aligning with OCDS. Are we ready to do that before open-contracting/standard#906 is resolved though?

It's worth noting that the framework recommends disclosing some information at the second stage, e.g. Box 1 on page 38:

_	Disclosed elements
TENDER DOCUMENTS	Expressions of interest, RFQ, RFP (including evaluation criteria, preferred bidder negotiation criteria), draft contract, detailed project report,minutes of bidders’ meetings, all communications with bidders during procurement, modifications to documents.
EVALUATION	Names of bidders, names of shortlisted bidders at RFQ, name of preferred proponent,comparative analysis of bids.

Table 8 on page 35 also suggests that at least India and British Colombia disclose information on both RFQs and RFPs.

Although some of this information is described as 'tender documents' the aim of the profile was to provide a means of publishing it as structured data.

So I think we'd need the secondStage object to report the shortlisted bidders (candidates) and to disclose documents like the minutes of bidders meetings etc.

[jpmckinney]

"names of shortlisted bidders at RFQ" seems to be the only item covered by OCDS for PPPs 1.0.0-beta2 that isn't covered by OCDS. This could be resolved by adding a "qualified" code to the bidStatus.csv codelist.

That said, I think it's also important to consider two things:

1. Does/Can anyone actually publish this as structured data? If not, it's not a major issue for there to be an open issue on OCDS for PPPs (OCDS has lots of open issues!).
2. Misalignment between OCDS and profiles is a major issue. Quick example: OCDS for PPPs is much easier to explain as OCDS + extensions, instead of OCDS + extensions + renaming of fields + incompatible pre-qualification extension, etc.

"Tender documents" can be disclosed at tender/documents with an appropriate documentType to communicate the semantics. A more ideal solution might be to have secondStage/documents, but until that is agreed and implemented, it's not a major issue for tender/documents to take on the duty of all post-planning and pre-award documents.

"names of bidders" go in the bids extension. I don't think OCDS for PPPs or OCDS have any field for "comparative analysis of bids". I don't know if "name of preferred proponent" is the same as "preferredBidders," which is just "suppliers".

I don't think open-contracting/standard#906 needs to be resolved. In the worst case, we have one concept ("names of shortlisted bidders at RFQ") that can't be expressed as structured data. That's a better situation than the present situation.

[duncandewhurst]

1. Does/Can anyone actually publish this as structured data? If not, it's not a major issue for there to be an open issue on OCDS for PPPs (OCDS has lots of open issues!).

I don't expect we'd find many examples of anyone publishing this as structured data, because there is little structured data published about PPPs anyway.

In terms of whether anyone can publish it, OCDS for PPPs and World Bank Framework are geared towards developing new systems for collecting and publishing data on PPPs (compared to OCDS which is mostly about publishing data from existing systems) so anything 'can' be published.

That said, I'm happy with adding "qualified" to bidStatus.csv and documenting this in the PPP profile.

2. Misalignment between OCDS and profiles _is_ a major issue. Quick example: OCDS for PPPs is much easier to explain as OCDS + extensions, instead of OCDS + extensions + renaming of fields + incompatible pre-qualification extension, etc.

Agreed, the alignment is important and since we can model the elements from the WB framework without relying on secondStage then I'm happy that we don't need to wait for #906 to be resolved.

I don't know if "name of preferred proponent" is the same as "preferredBidders," which is just "suppliers".

I think it's safe to assume they are the same.

[duncandewhurst]

@jpmckinney before I draft changes to the documentation, please let me know if the below is what you have in mind.

I listed the relevant elements of the framework in a spreadsheet and made a note of the changes required.

Once done, the Procurement Information section of the framework reference would look something like this:

II Procurement Information

Dates and summary details, links to all procurement documents, final feasibility study, including land acquisition, social, environmental, and rehabilitation related information, reports of independent procurement auditors (if any)

Procurement procedures can involve one or more competitive stages:

• In single-stage procedures, procuring entities invite suppliers to bid without submitting any prior information.
• In multi-stage procedures, the procuring entity issues an invitation to participate in the process based on which suppliers submit requests to participate. The procuring entity then assesses the submissions and establishes a list of qualified suppliers to invite to bid.

In OCDS, a contracting process has a single competitive stage, the tender section. This represents the initiation of the process, when procuring entities invite suppliers to take part, either by submitting bids or by submitting requests to participate in a pre-qualification process.

II.1 First stage

Use the tender section to describe the first stage of the contracting process, whether that is the tender itself, or a pre-qualification stage.

II.1.1 Dates - Submission period

... tender/period

II.1.2 Dates - Enquiry period

... tender/enquiryPeriod

II.1.3 Dates - Qualification period

II.1.4 Summary details - Submission method

... tender/submissionMethod

II.1.5 Summary details - Eligibility criteria

... tender/eligibilityCriteria

II.1.6 Invitation documents

... renamed from 'RFQ documents', no change to existing guidance

II.1.7 Dates - Award period

... moved from II.3.3, no change to existing guidance

II.1.8 Dates - Contract period

... moved from II.3.4, no change to existing guidance

II.1.9 Summary details - Procurement method

... moved from II.3.5, no change to existing guidance

II.1.10 Other documents

... moved from II.3.9, no change to existing guidance

II.2 List of pre-qualified suppliers

For procedures with a pre-qualification stage, the list of pre-qualified suppliers should be published using...

... no change to existing guidance

II.3 Tender

II.3.1 Dates - Tender period

II.3.2 Dates - Enquiry period

II.3.6 Summary details - Submission method

II.3.7 Summary details - Eligibility criteria

II.4. Evaluation criteria

... no change to existing guidance

II.5. Evaluation committee information

... no change to existing guidance

II.6. Negotiation parameters

... no change to existing guidance

II.7. Pre-bid meeting minutes

... no change to existing guidance

[jpmckinney]

Looks good. I might have suggestions on wording which we might do in Google Docs, for example:

In OCDS, a contracting process has a single competitive stage, the tender section

There is no competitive stage in the case of a direct award, so this would be worded differently. The tender section is also, semantically, used to describe the procedure as a whole (fields like procurementMethod).

[duncandewhurst]

In OCDS, a contracting process has a single competitive stage, the tender section

There is no competitive stage in the case of a direct award, so this would be worded differently. The tender section is also, semantically, used to describe the procedure as a whole (fields like procurementMethod).

I've drafted changes to documentation in #245 in order to preserve formatting, but I'm happy for you to move some content to a Google Doc for further editing. This sentence came from https://standard.open-contracting.org/latest/en/guidance/map/pre-qualification/#the-ocds-model so we should update that once we've agreed on better wording.

There's a couple of points to clarify before before the PR is ready for review:

Were you anticipating removing the "qualification" codes from releaseTag.csv (added in the ppp extension)?

"names of shortlisted bidders at RFQ" seems to be the only item covered by OCDS for PPPs 1.0.0-beta2 that isn't covered by OCDS. This could be resolved by adding a "qualified" code to the bidStatus.csv codelist.

Could you clarify how you see using bids for this working in a multi-stage procedure? Would there be separate Bid objects for the response to the RFQ and the response for the RFP?

[jpmckinney]

Were you anticipating removing the "qualification" codes from releaseTag.csv (added in the ppp extension)?

I hadn't thought about it. I would suggest removing them, and then having a conversation in open-contracting/standard#792 about whether/how to add them back in OCDS 1.2.

Could you clarify how you see using bids for this working in a multi-stage procedure? Would there be separate Bid objects for the response to the RFQ and the response for the RFP?

Yes. Bids don't have a way to indicate to what they are responding, but it's possible to disambiguate between first and second stage based on dates (e.g. bids/details/date before tender/tenderPeriod/endDate for RFQ, and after for RFP).

[duncandewhurst]

Please could you check that this draft guidance for the list of pre-qualified suppliers is what you had in mind and provide a description for the new 'qualified' bidStatus code? Would it simply repeat the description of the 'valid' code but omit the mention of evaluation?

II.2. List of pre-qualified suppliers

Pre-qualification or shortlist.

Details of suppliers that submit a request to participate should be provided using Organization objects in the parties array.

For each request to participate:

• Add a Bid object to the bids/details array
• Set its .id incrementally
• Add an OrganizationReference to its .tenderers array and set the .id and .name to the supplier's .id and .name from the parties array
• Set its .date to the date the request was received
• If the bidder is shortlisted or invited to submit a proposal following the pre-qualification process, set its .status to 'qualified'.

Example: See section I.14.2 for JSON and flattened examples of the organization building block.

[jpmckinney]

I forgot about the 'valid' code - we should just use that.

Where does "Pre-qualification or shortlist" come from? Pre-qualification is an activity, a shortlist is a list of qualified tenderers – so they aren't really alternatives in an "or" pair.

Since we use / notation elsewhere in the profile, we should omit the initial periods, to avoid mixing notations.

[duncandewhurst]

Where does "Pre-qualification or shortlist" come from? Pre-qualification is an activity, a shortlist is a list of qualified tenderers – so they aren't really alternatives in an "or" pair.

That's the terminology from the World Bank's framework. We've interpreted it as the latter, hence the way the element is named. If I remember correctly we included the original terminology to make it easier for implementers to reference the framework.