Procurement plans

[jpmckinney]

Motivation

1. Procurement plans should be disclosable as machine-readable data in a timely fashion.
2. It should be possible to link a contracting process to a procurement plan. In other words, a contracting process should not store a copy of the procurement plan.

Discussion

The facts so far:

1. OCDS allows linking to a procurement plan using planning/documents with a documentType of procurementPlan (motivation 2). These documents are presently often PDFs or HTML (1).
2. Procurement plans are not contracting processes. Therefore, it seems inappropriate to create an OCDS release for a procurement plan (1).
3. The individual items of a procurement plan will someday be directly related to contracting processes; so it might, at first, seem promising to create an OCDS release for each item. However, many items can be combined into one process, or one item can be split into many processes, in ways that are impossible to predict at the time of the plan's publication. Therefore, it is impossible to create OCDS releases for individual items of a procurement plan in a timely fashion (1).
4. OCDS allows linking between processes using relatedProcesses, whose relationship can be set to planning, defined as "This contracting process follows on from the related planning process." However, this code is meant to relate processes, not to to relate a process to a plan (2).
5. OCDS documents no explicit format for procurement plans (1). However, there are very few common fields in procurement plans that are not covered by fields in OCDS. Therefore, it's possible that an identical or similar schema can be used for procurement plans.

We might need to refine, and we might disagree on, the facts. This issue is partly to figure that out.

Proposals

Based on the facts, these seem to be the possibilities:

1. Provide a schema for procurement plans (which might be a subset of the release schema), and allow linking to the plan through the existing planning/documents field (or a new field).
2. Recommend linking to the plan through the existing planning/documents field, but provide no prescribed machine-readable format.
3. In contradiction to the facts, use the release schema for procurement plans and allow linking to the plan through the existing relatedProcesses.

Relevant prior discussion: https://github.com/open-contracting/standard/issues/72#issuecomment-59840914

Related: #371, #440, CRM-3698

cc @duncandewhurst

[duncandewhurst]

Thanks @jpmckinney, I prefer proposal 1, some thoughts on the options below:

1. Provide a schema for procurement plans (which might be a subset of the release schema), and allow linking to the plan through the existing planning/documents field (or a new field).

This could also be linked via relatedProcess using a .scheme other than 'ocid', however the semantics of process may still not fit exactly.

2. Recommend linking to the plan through the existing planning/documents field, but provide no prescribed machine-readable format.

We have seen demand to provide structured data on procurement plans (at least from Belarus and NSW Australia and probably elsewhere if we were to review past engagements with other publishers), which this option doesn't really address.

3. In contradiction to the facts, use the release schema for procurement plans and allow linking to the plan through the existing relatedProcesses.

Since the items on a procurement plan may have different estimated approach to market dates, they can't be represented using the .items list in a single tender block, so additional fields would need to be added to the planning object, in which case we'd be suffering the 'procurement plans are not contracting processes' issue without really benefiting from re-using the release structure.

Sharing examples where procurement plans have been expressed as machine readable data in OCDS:

• Belarus
• NSW Australia

[jpmckinney]

I've scheduled for 1.2, so that it is at least discussed as part of that release. Given that this would be a fairly significant change, we might end up having to re-schedule its ultimate deployment.

[duncandewhurst]

The UK government requires departments to publish commercial pipelines (which seem analogous to a procurement plans) and defines a set of fields that should be disclosed, in this document.

Most of the fields in the commercial pipeline can be represented using objects and fields which already exist in OCDS.

We should consider this in any work on structuring procurement plan data

[duncandewhurst]

Adding some more detail on the examples noted above:

Belarus represents each procurement plan using a single contracting process in OCDS, adding an 'items' array to the planning section in OCDS to represent the items due to be procured under the plan. There doesn't appear to be a link between the procurement plan and the tenders which result from it.

NSW Australia represents each procurement plan using multiple contracting processes in OCDS, with each item on the plan represented as a separate contracting process. Additional fields are added to the tender object (e.g. estimatedDateToMarket: "Quarter 4 2016/2017") and there is a link to the tenders resulting from the plan (relatedRFT)

[yolile]

Chile is going to publish their procurement plan using items in the planning section as Belarus, too. They have the relation with the tender but after the tender is made not before.

[yolile]

Paraguay will also publish their data using planning/items. A drafted extension for that is available here: https://gitlab.com/dncp-opendata/ocds_planning_items_extension

cc @duncandewhurst

[duncandewhurst]

From @pindec's call with Ethiopia:

In Ethiopia, before specific tenders are identified, there is a master list during the planning stage of, for example, all the required items/budget info etc.. Only later are specific individual tenders identified.

[pindec]

Noting from a call with Lagos:

• Most procurement plan lines ends up with only one tender, but may have multiple awards. The tender will become a package divided into lots.
• Some procurement plan lines become multiple tenders.
• The dividing up of plan line entries into tenders happens at the Evaluation Stage.
• The specific items in the procurement plan are generally the same as the ones that go into the tender stage, but can be reviewed.

[jpmckinney]

Quick note to add details from CRM-5594.

[duncandewhurst]

Paraguay will also publish their data using planning/items. A drafted extension for that is available here: https://gitlab.com/dncp-opendata/ocds_planning_items_extension

Development Gateway authored a similar planning items extension for Makueni County. cc @mpostelnicu

[jpmckinney]

This issue hasn't been updated in a while. As part of 1.2, a distinction has been made between planning processes and contracting processes. With that, it should be easier to model procurement plans as planning processes (assuming they don't represent some third option).