Contract extension and renewal

[timgdavies]

This issue is under consideration for the 1.1 milestone.

It builds on previous discussions in #200, #179, #184, #274

The issue

In many systems, a contract can legitimately be extended.

In these cases, there is a need to capture information on:

• What extension options are envisaged at tender time;
• What extensions options are agreed at award or contract time;
• What extension options have been exercised

In other cases, contracts are reviewed at a set point, and renewal processes are undertaken. There is a business use-case for knowing about upcoming renewal processes.

What we are proposing

Introducing a period.maxExtent field which can be used to provide the latest date a contract should be extended to.

Introducing two fields to tender, award and contract.

• extensionsPermitted: [0 - 100]
• extensionOptionDetails: free text

Introducing the contract.extendsContractID field that references a contract.id value from the same contracting process, so that a contract extension can refer back to the contract it extends.

Adding a relatedProcess (see #371) codelist entry for replacementProcess

Example

"tender": {
    "contractPeriod": {
        "startDate": "2017-01-01T00:00:00Z",
        "endDate": "2017-12-31T00:00:00Z",
        "maxExtent": "2018-12-31T00:00:00Z"
    },
    "extensionsPermitted": 1,
    "extensionOptionDetails": "The contract may be extended for a period of up to 12 months at the buyer's discretion and subject to satisfactory performance from the supplier over the initial term"
},
"awards": [{
    "contractPeriod": {
        "startDate": "2017-01-01T00:00:00Z",
        "endDate": "2017-12-31T00:00:00Z",
        "maxExtent": "2018-12-31T00:00:00Z"
    },
    "extensionsPermitted": 1,
    "extensionOptionDetails": "The contract may be extended for a period of up to 12 months at the buyer's discretion and subject to satisfactory performance from the supplier over the initial term"
}],
"contracts": [{
    "period": {
        "startDate": "2017-01-01T00:00:00Z",
        "endDate": "2017-12-31T00:00:00Z",
        "maxExtent": "2018-12-31T00:00:00Z"
    },
    "extensionsPermitted": 1,
    "extensionOptionDetails": "The contract may be extended for a period of up to 12 months at the buyer's discretion and subject to satisfactory performance from the supplier over the initial term"
}]

Outstanding questions

Should this be in core or in an extension?

Engagement

Please indicate support or opposition for this proposal using the +1 / -1 buttons or a comment. If opposing the proposal, please give clear justifications, and where possible, make an alternative proposals.

Please leave a comment indicating whether you think this proposal should form part of the core standard or whether it should be an extension.

[siwhitehouse]

The EU, in their new TED Notice forms, also ask for

Estimated date(s) for subsequent call(s) for competition:

and in the GPA there is this

Article VII: 2(c)
for recurring contracts, an estimate, if possible, of the timing of subsequent notices of intended procurement

Is it worth including an additional field for estimated dates of subsequent notices?

[timgdavies]

The new EU forms break this down into a number of fields, separating the concepts of renewal and recurrent procedures.

In OCDS 1.1 we will now be introducing period, and maxExtent for periods, as well as allowing links to a renewal or recurrent procedure's OCDS data using relatedProcess.

However, as there have been no requests in this thread for this to go into core, I would propose that for 1.1 this is handled by an extension.

@siwhitehouse would you be able to include this in your work on extensions for trade and make a first suggestion for this? I keep getting caught up in trying to find a simple structure that can capture the different cases, but we might just need to introduce a couple of different properties here.

EU Forms:

[siwhitehouse]

@timgdavies Yes, I'll include this in the extensions for trade. I think you could be right about using separate properties as, although they are similar concepts, the requirements for data capture are quite different.

[timgdavies]

This was left out of 1.1 on grounds of available time, and as it will be possible to add as a community extension at a later date.

Separate work is taking place which may contribute to this in the near future.

[jpmckinney]

Noting that this issue is distinct from the question of recurrence/recurring/recurrent contracts.

[jpmckinney]

This issue is primarily a continuation of #200, which exclusively discusses renewals in an EU context (except where the conversation took tangents that became separate issues). In the EU, however, there is no concept of 'maxExtent' within the published data or standard forms. The forms have only:

• II.2.7 Duration of the contract, framework agreement or dynamic purchasing system
  • This contract is subject to renewal (checkbox)
  • Description of renewals (free-text)

There's a reference to a standard for English local government having 'Contract maximum extension date', for which I found an example. Given the little evidence for this concept, I propose it be used in a local extension for now.

I can't find any evidence for extensionsPermitted being expressed as a number in any jurisdiction. I can only find evidence for expression as a boolean.

As for the information collected in TED, see this proposal (which eliminates the need for a boolean) and contribute to its related issue.

[jpmckinney]

I forgot that maxExtentDate was in the Period object (added as part of #374) 🙇‍♂️