Contract and Award Periods in Tender

timgdavies commented 8 years ago

This issue us under consideration for the 1.1 upgrade.

It builds on discussions in #350.

The issue

Tender notices will often include details of the anticipated period over which a contract should be performed.

We currently lack anywhere in OCDS for this to be specified.

This appears to be an ommission, and partially related to confusion over the tender.awardPeriod fields which I have, in the past, mistakenly interpreted as relating to the period in which an award would be active (i.e. the period the awarded contract would cover). However, tender.awardPeriod is supposed to capture the dates of assessment and final decision making on the contract.

The proposal

We will add tender.contractPeriod to the core standard.

This will be documented as:

"The period over which the contract is estimated or required to be active. If the tender does not specific explicit dates, but indicates a duration, use this to provide estimated dates assuming the contract starts at the time an award is made."

We will update the documentation for tender.awardPeriod to state:

"The period for adjudication and selection of the contract award. The awardPeriod.endDate should be the date on which an award is due to be made. awardPeriod.startDate may be used to indicate the start of an evaluation period."

Questions

Are these definitions adequate? Can they be improved? Suggestions welcome.

Engagement

Please indicate support or opposition for this proposal using the +1 / -1 buttons or a comment. If opposing the proposal, pleas

duncandewhurst commented 8 years ago

Feedback from breakout session at IODC:

There is a typo in the definition of tender.awardPeriod

"The period over which the contract is estimated or required to be active. If the tender does not specifiy explicit dates, but indicates a duration, use this to provide estimated dates assuming the contract starts at the time an award is made."

duncandewhurst commented 8 years ago

Feedback from consultation with Hunt La Cascia, Senior Procurement Specialist at the World Bank:

tender.contractPeriod

Many times this information could be in the implementation schedule of the tender.
Tenders don't usually specify contract start and end dates, but rather a duration, typically months.
There is often a standstill period between award and contract signature - there may be a review of complaints and debriefing unsuccessful bidders.

tender.awardPeriod

If the award period includes evaluation then should it be called the award and evaluation period?
Award only can still be a period - there is still a process to follow in this period: contact the successful supplier, final negotiations, signing.

The World Bank Procurement Regulations also provide some useful diagrams detailing possible award processes:

chrisalexsmith commented 8 years ago

A tender/RFP will specify a validity period normally being 60/90 or 120 days. This entitles the contracting authority to place a contract within the defined validity period and for the bidder to accept it without variation in the terms of conditions originally offered. It does not in itself indicate the expected date of the tender evaluation or contract award but merely the period within which the contracting authority can undertake the evaluation and both parties can conclude a contract on the terms offered by the bidder i.e. price and delivery etc. If the validity period is approaching the expiry date, it can be extended by mutual agreement. From the OC perspective, repeated extensions of validity can suggest a red flag problem with the procurement exercise that or just reflect the normal delays in the evaluation process.

Forecast and actual dates for tender closing, evaluation and contract award and other key milestones are likely to be maintained in the procurement plan.

duncandewhurst commented 8 years ago

@chriscrownagents thanks that clarification is really helpful.

Feedback from consultation with Marcela Rozo, Open Contracting Team Leader, World Bank:

The contract period definition makes sense
The period between the deadline for bid submission and the award date is typically known as the evaluation period rather than the award period

timgdavies commented 8 years ago

I've been looking at whether we could use the duration components of ISO 8601, but RFC 3339 makes clear this is not supported in date-time that we currently use for validating date entries.

Although we could use duration strings from ISO 8601 in another field, and validate it accordingly, the are not terribly human-readable (e.g. 'P3Y6M' for 3 years, 6 months).

As a result I'm wondering whether we should consider some advanced extension where we articulate our own set of fields for describing durations where this is all that is known.

Being able to clearly describe the duration of a contract even when start and end dates are not known would certainly be useful - although it puts requirement to apply logic to deal with multiple kinds of dates (specific, durations with assumed start dates) on the consuming application.

If doing this, we might also look at #200 and #375 and could consider some sort of contractPeriod array, that might look something like this:

{
"contractPeriod": [
    {
       "id":"1",
       "startDate":"",
       "endDate":"",
       "duration":{ 
            "value":"36",
            "interval":"months"
        },
     }
     {
         "id":"2",
         "follows":"1",
         "type":"extensionOption",
         "duration": {
             "value":"1",
             "interval":"years"
         }
    }]
}

Having set this out - I'm not convinced that this more complex object is the way we want to go - but I suspect we will have to find a good way of modelling durations at the very least.

duncandewhurst commented 7 years ago

There is draft schema here for this proposal which adds contractPeriod and contractDuration properties to tender.

contractPeriod is a standard period object for consistency with other uses of xxxxPeriod elsewhere in the schema.

contractDuration is a ISO8601 duration format string, whilst this isn't the most human friendly representation it is standardised and the above link is given in the description for the field in the schema to help users.

We should also include guidance in the schema reference docs on use of the contractPeriod and contractDuration fields when a tender is expected to result in more than one contract.

@Bjwebb the schema also introduces a custom format attribute duration for validation purposes

Assigning to @ekoner to review

timgdavies commented 7 years ago

A couple of things I think we need to check further here:

[x] Is there a need for duration in other places (e.g. Award)
[x] What support is out there for ISO8601 duration format strings

On the second point - I've been looking to explore how this might meaningfully be used in spreadsheets or software, and struggling to come up with anything really good to run with.

Will keep exploring...

ekoner commented 7 years ago

Review

Propose: contractDuration as a duration in days.

Pros:

Simplifies duration for spreadsheets-users
Reduces the need to convert the field for humans
Can be specified as portions of a day (0.5), a day (1), multiple days (100)
More complex periods can be calculated by consuming applications if needed e.g. (3 weeks)

Cons:

Barrier to machine-readablility units - users would have to read the description to know the duration unit
Is not part of a standard like ISO8601

Please indicate support or opposition for this proposal using the +1 / -1 buttons or a comment. If opposing the proposal, please provide reasons.

ekoner commented 7 years ago

@timgdavies asked: Is there a need for duration in other places (e.g. Award)

I'd anticipate only in places where dates are uncertain, so perhaps planning. I will review and link a ticket here if there are any candidates.

ekoner commented 7 years ago

374

Update: Thanks @duncandewhurst for pointing out issues with the version numbers above. For OCDS v1.2 and v2 please read v1.02 and v1.1

I visualised most of the dates mentioned on this thread so that we have a shared understanding of the usual dates found in a Tender pipeline. Please note that the dates aren't necessarily consecutive, I've ordered them in a rough order.

Please indicate support or opposition for this visual using the +1 / -1 buttons or a comment. If opposing the proposal, please provide reasons.

timgdavies commented 7 years ago

I've been thinking about this and reckon @ekoner is right with the suggestion to simple include contract duration in days.

We could even make the field name very explicit for this durationInDays to make use intuitive.

I think we could consider adding durationInDays directly to the period block.

We might want to add some rules about which of startDate, endDate and durationInDays MUST be populated in different places, but I'm noting that with other explicit date fields, such as signatureDate we may be able to make the standard relatively permissive.

For example:

In a 'planning' release, tender.period may only be able to include a durationInDays, and may not have a startDate
In a 'tender' release, tender.period MUST contain a startDate and endDate

This doesn't deal with the issues from #375 about potential renewals of a contract.

timgdavies commented 7 years ago

I've just pushed an updated version of https://github.com/open-contracting/ocds_upgrade_374 which:

Introduces durationInDays to period;
Introduces maxExtentDate to period - addressing some of the issues in #375

both available for use wherever period is in use. This also fixes the definitions of awardPeriod, giving it the title of 'Evaluation and award period' to capture that it covers both (though leaving the field name unchanged), and this adds tender.contractPeriod.

JachymHercher commented 7 years ago

My comment from the 1.1 peer review:

Concerning "We have introduced fields for duration in days, and maximum extent, to the period building block"

We should be careful not to combine two different things: a (time) extension option (called a renewal in the EU directives), which allows the buyer, if he wants, to ask for services for a longer (predefined) period of time. The field maxExtentDate reflects this concept.

It does not, on the other hand, reflect the fact that many contracts can be renegotiated (e.g. changed on the basis of an agreemenet of both parties) in many ways, including e.g. moving a deadline for the delivery of the goods by some months. From the maxExtentDate description, it needs to be clear that this is not covered by this field - currently it's ambiguous. (It could be also worth considering whether it's not clearer to include this field together with the option fields.)

The description of "durationInDays" should also include something about maxExtendDate. I would suggest adding "If both an end date and maxExtentDate are given, the maxExtentDate should be taken into account." at the end. (That's what we propose for eForms.)

The durationInDays description could also be explicit about the fact that it is the duration from the signing of the contract (by the last contractual party).

Concerning "We have introduced contract period in tender and updated the definition of award period."

I'm not sure whether reusing the entire period block is necessary. In the EU, only endDate would be relevant.

For the description of awardPeriod, I would suggest avoiding the word adjudication because at least for me it's a real mouthful and it seems like a synonym for "deciding" or "choosing". Also, in the phrase "The period for adjudication and selection of the contract award", instead of choosing a "contract award" we could simply say that we are choosing a contractor.

jpmckinney commented 7 years ago

Noting that (at least some of) @JachymHercher's comments are reflected in the following commits.

open-contracting / standard