Appendix B

Contract
Management
Procedure
 Contents

1. Introduction

2. Purpose of Contract Management

3. Aims of this document

4. Level of Contract Management

5. Priorities

6. Contract Management Process

7. Contract Implementation

7.1 End-user Information Packs

7.2 Supplier / Buyer Events

8. Software Contracts

9. Contract Management Plan

10. Contract Performance Review Meetings

11. Change Control

12. Change Control Procedure

13. Exit Strategy

Appendix 1 – Software Contract renewal checklist

Appendix 2 – Contract Management Plan
Appendix 3 – Contract Variation Template
Appendix 4 – Contract Extension Template
1. Introduction

This procedure has been created as part of the Contract Management Framework in conjunction
with, the Contract Management Policy and Statement of Principles; it also compliments the Council’s
Procurement Strategy. Furthermore, it recognises the aims and values set out within the National
Procurement Strategy 2018.

The Contract Management Procedure sets a foundation for the implementation of a consistent
approach to contract management across all service areas, in order to drive value from new and
existing contracts.

As well as implementing consistent cross-service processes for contract management, the Council
aims to improve existing supplier relationships through increased effective engagement and at the
same time maximise spend with local businesses and SMEs.

2. Purpose of Contract Management

The function of Contract Management is to:

• ensure a contract is successfully executed

• provide a formalised method of monitoring supplier performance against contract requirements
• ensure that there is clarity of the roles and responsibilities by all parties relating to contract
management
• monitor overall compliance by all parties to the terms of the agreement and contract, refining and
improving KPIs, SLAs and service delivery through honest, open communication between the
supplier and the Council, delivering improvements to both parties
• improve and develop relationships with key supplier representatives based on mutual trust and
understanding, open communications and a joint approach to managing delivery
• realise estimated and planned savings through continuous monitoring of spend
• identify potential additional savings and benefits through proactive contract management
• co-ordinate the supply chain
• provide a focus for development of initiatives / innovation
• deliver learning and knowledge transfer
• drive continual improvement
• Ensure effective and timely procurement planning

3. Aims of this Document

Supporting the objectives set out in the Council’s Procurement Strategy, this procedure aims to
provide a standard corporate approach and guidance to contract management, defining clear
ownership for operational day-to-day management throughout the lifecycle of a contract.

This procedure will achieve its aims by defining the procedure for developing and maintaining close
relationships with business partners and key providers, and creating a consistent, standard contract
management process, applicable to all goods, services and works.

4. Determine Level of Contract Management

It is important when developing the Contract Strategy to determine the level of management required
for the proposed contract once awarded, based on size, value and organisational risk, as this will
influence and determine the frequency and content of supplier review meetings.

Guidelines are given below, but each service, will need to consider the appropriate level of
management required for individual contracts, by considering factors such as value and length of
contract, business criticality and dependency, number of customers / end-users, public visibility,
openness to complaints or challenges, risk, performance criteria and compliance with requirements
of governing bodies.
 • Low level - ensuring compliance to the contract by monitoring management information from the
supplier, end-user feedback, managing delivery, and compliance of the contract.

• Medium level - managing the performance of the contract and the supplier through management
information monitoring, end-user feedback and a minimum of one performance review meeting
held per annum.

• High level - managing the performance of the contract and the supplier using a combination of
management information monitoring, and quarterly (or other frequency determined) meetings.

5. Priorities

Priority areas to achieve contract management objectives include the:

 Implementation of standardised templates for managing and documenting supplier meetings

consistently across all commodity / category areas.
 Incorporation of a mechanism to review council performance and feedback within review meetings
 Introduction of management meetings with identified key suppliers for each category, with an aim
of continuous improvement in the execution of contracts.
 Regular review of both contract performance and supplier performance through structured joint
and service-inclusive meetings to improve output, savings and knowledge, and to reduce risk
 Encouragement of prime contractors to engage with local suppliers and SME’s through the
inclusion of Community Benefit / Sustainability clauses, and early engagement in commodity
strategies
 Standardisation of the supplier management process, and implementation of rigorous controls to
manage the supplier database and transactions within Procurement systems.
 Continual review of the Contract management process to ensure it remains fit-for-purpose.

6. Contract Process

This document sets out the procedure that is used to manage contracts and the supplier relationship
post-supplier selection and contract award. Equally, it applies to the management of existing
contracts.

The Contract Management process begins with migration and mobilisation, and continues through
a post-contract award meeting with the successful supplier, which as a guideline, should be
conducted within 1-3 weeks of the contract award. The purpose of this meeting is to discuss the
contract implementation phase and agree roles, responsibilities, identify activities and agree SLA’s,
KPI’s, timescales and expectations. It is important to keep in regular contact with the supplier during
the contract implementation phase and to arrange meetings and maintain open dialogue throughout.

7. Contract Implementation

Contract Implementation consists of three distinct phases:

• Mobilisation - the process of moving from contract award to 'go-live' i.e. the point when a user
can actually buy from the contract
• Migration - facilitating the movement of an organisation to a new contract post 'go-live'
• Communication – ensuring all stakeholders are aware of the contract and what it involves

Actions that should be considered to migrate and mobilise a contract include:

7.1 End-User Information Packs

An information pack may be required to communicate and publicise the contract to inform end-users
of its content, which can contain key information about the use of the contract including:
 • contract objectives, details of the goods and services available, prices, supplier contact details,
ordering and invoice process, returns / complaints / escalation process, and Contract
management process.

Any information pack should be proportionate to the contract, and should demonstrate how it delivers
best value and provides information relating to the benefits of the contract, e.g. cost savings, KPIs,
SLAs, improvements in quality and service.

7.2 Supplier / Buyer Events

Depending on the size, value and risk level involved with the contract, a useful way to raise
awareness of the contract amongst end users is to organising a Supplier / Buyer ‘launch’ event to
give stakeholders who have yet to meet as part of the selection and award stage, the opportunity to
meet each other, and present details of the contract and what it affords. This is also an opportunity
to distribute information packs / buyers guides. Where a large number of users are affected, it may
be useful to also publish a news item via the Intranet.

8. Software Contracts
It is widely accepted that services are not going to replace or renew a software contract when all that
is needed is an upgrade; however, there are certain parts of a contract that need to be reviewed and
therefore a procedure in place to manage software contracts. Appendix 1 provides more detail on
contract considerations for reviewing, renewing or replacing software contracts.

Process to Review, Renew or Replace

This section gives guidance on how software contracts should be reviewed, renewed or replaced,
taking into consideration the following matters:

 All contracts should have an end date / identify any extensions

 Corporate impact of change
 Support needed for change
 Interfaces
 Benchmarking
 Functionality - Doing what it needs to do (or not?),
 Value
 Risk
 Length been in place

Many companies lease systems and software on an annual basis and have to find a way of keeping
track of renewal dates. Unfortunately, many software suppliers fail to notify customers of renewal
dates and either continue to take direct debit payments or disable the software when payment is not
received on time. Both can be equally detrimental to a business and can be avoided or mitigated by
appropriate planning and monitoring.

It is important to review the cost and efficiency of leased services regularly to ensure that:

a) the performance still meets requirements; and

b) financially, it is the best deal in the market place.

The same applies to annual software maintenance payments, domain name renewals and even I.T.
equipment which are leased.

9. The Contract Management Plan

Once the contract implementation has been completed and the level of management determined, a
Contract Management Plan, see Appendix B for an example, should be constructed which outlines:
 • Roles & responsibilities
• Agreed level of management (low/medium/high)
• Contract objectives
• Performance Management Framework, e.g. KPIs & SLAs
• Mobilisation Plan
• Migration Plan
• Contract Compliance
• Escalation process (within supplier organisation and the council)
• Review meeting schedule
• Risks & issues

This will need to be agreed with your supplier. All of these, in particular, the routes for escalation
and the review meeting schedule should have been built into the initial Contract(s) Strategy and
tender, with reference to the fact that a Contract Management plan will be developed.

10. Contract Performance Review Meetings

Performance Review Meetings are an important part of the Contract Management process and
provide Service Users and the Supplier with an opportunity to focus on what is going well, identify
any problems at an early stage and agree opportunities for improvement and innovation.

For contracts / suppliers where a medium level of management is being applied, there should be at
least one performance review meeting per year. Meetings for Contracts / Suppliers where a high
level of management is being applied should be held at least quarterly.

Meetings should focus on:

i Review of Actions and Minutes from previous meeting(s)

ii Supplier Business Review, with updates on new products / product developments, customer-
affecting issues (e.g. product issues, recalls), complaints, etc.
iii Council Business Review / Service Improvement Plan Update
iv KPI review – (to determine current level of performance (Improving / Degrading)
v Sustainability & Other Benefits Realisation
vi Review of risks and Issues
vii Issues for escalation
viii Financial Monitoring (Spend monitoring, P2P, Invoicing, financial stability).
ix Areas of Improvement (e.g. Innovation, new process)
x Change Control

These are suggested agenda topics for discussion however these will need to be adapted for specific
types of contract and / or suppliers.

The initial performance review or inaugural or kick-off meeting should also include a 'Lessons
Learned' session with the supplier on the tendering and contract implementation process, and cover
areas such as roles and responsibilities, performance levels, invoicing arrangements, etc.

Meetings should recur as agreed until the contract approaches its completion, and documented
(minutes, actions, change in performance) throughout, with actions followed up as agreed.

Minutes of meetings and agreed actions should be communicated to all stakeholders following each
meeting (supplier & service area management, Policy & Governance Team for SLT reporting).

11. Change Control

Changes (variations) to services, procedures or contracts are likely to occur throughout the lifecycle
of a contract, especially lengthy and / or major, strategic contracts, which could have an effect on
many aspects of the contract including:
 • Service delivery
• Scope of work
• Performance
• Costs
• Product availability / changes to specification / obsolescence / revision of rates
• Whether the contract continues to represent value for money

The primary aim in managing variations is to minimise their likelihood, however sometimes change
is inevitable, therefore the specification and management of change (Change Control) is an integral
and important part of contract management and administration. Change control procedures should
be included within the contract and discussed at the inaugural meeting.

The respective roles and responsibilities of both parties in the change control process must be clearly
identified, along with procedures for raising, evaluating, costing and approving change requests.

A single change control process should be applied to all contract changes. Flexibility does however
need to be built into the process to deal with issues such as emergencies. A change control process
should provide clear steps and clearly allocated ownership and responsibilities for:

• Requesting changes
• Assessment of impact
• Prioritisation & authorisation
• Agreement with provider
• Control of implementation
• Documentation and communication of change
• Updates to terms & conditions where applicable

If a specific change, or cumulative changes significantly increase or decrease the scale or scope of
the contract, the responsible Contract Manager must question the contract’s ability to achieve best
value and value for money overall.

Similarly, the Contract Manager must also ensure that any changes do not take the contract outside
the scope of the original tender in relation to the UK thresholds advertisement, or permitted
extensions to contracts. When this is in doubt, the change should be referred to the Policy &
Governance team or One Legal for guidance.

The same level of diligence should be applied to contract variations as that applied to letting a
contract.

12. Change Control Procedure

The change control procedure as detailed in the Contract should be used by services and supplier
to enable changes to the contract, to provide clarity and documentary evidence of the change, and
agreed actions. Appendix 3 details a contract variation template.

13. Exit Strategy

As a contract progresses, the Contract Managers will have responsibility for ensuring that both
parties are working towards the planned fulfilment and exit of the contract, and the procurement
process for securing subsequent supply arrangements if required.

The Exit Strategy should involve a full review of the Contract's performance. This should include a
‘lessons learned’ review which incorporates feedback from end-users and the supplier.

The final review and lessons learned should be clearly documented and communicated to
appropriate stakeholders, as it may inform any subsequent procurement for similar commodities in
the future.
 Appendix 1 – Reviewing, Renewing or Replacing Software Contracts

It is widely accepted that services are not going to replace or renew a software contract when all that is
needed is an upgrade; however, the Council needs to have a procedure in place to manage software
contracts.

This section gives guidance on how you should review, renew or replace your software contracts,
taking into consideration the following matters:

 All contracts should have end date

 Corporate impact of change
 Support needed for change
 Interfaces
 Benchmarking
 Doing what it needs to do (or not?), functionality
 Value
 Risk
 Length been in place

Software review checklist

Product:
 If perpetual licence – does the Council have the right to use unless breach?
 If term licence – are support and upgrades included?
 Licence types – is it concurrent, named?
 Licence definitions
 Affiliates usage permitted
 Do the Council have the ability to make backup, DR, TEST, DEV copies of software at no
charge?
 Are pricing guarantees for incremental purchases included?
 Price increase caps on additional licences
 Electronic delivery of software
 Software warranty – time frame, language including free from time bombs
 Acceptance testing
 Existing licence trade-in
 Inability to change licence model w/o approval
 Training prices if applicable
 No ‘then current’ or ‘then in effect’ language
 No automatic renewals
 Manuals included for all purchases / upgrades
 Licence compliance guaranteed only if software delivered to designated group / dept
 Installation included with software price
 Language re: future product evaluation

Maintenance and support:

 Operating Systems Upgrade guarantee
 Escalation procedures
 Severity levels, service level response times
 Maintenance %, based on purchase price
 Caps on maintenance increases (3% or CPI)
 Specific support hours
 Support on discontinued product
 Separate billing of maintenance and support
 Discount on pre-paid maintenance
 Penalties for missed P1 calls / SLAs
Terms and Conditions:
 Use of name clause
 Payments due net 30 days from receipt of undisputed invoice
 Protection against assignment of product
 Audit rights – 30 days, 15 business days

Software licences and maintenance: checklist

This checklist contains a list of the main issues for suppliers and services to consider when negotiating
software licences and maintenance and support agreements.

Software licences and maintenance: main points for customers to consider

Validity of licence
• Does the supplier warrant its right to grant the licence and indemnify the service against infringement
of any third party’s rights? Are there any circumstances or conditions which suggest that the right to
grant a licence might be subject to a third party’s consent and, if so, has that consent been obtained?

Extent of licence
• Does the licence cover all the users who might reasonably be expected to use the software (for
example, subsidiaries, associated companies, facilities management companies)?
• Does the licence contain restrictions on the uses to which the software might be put (for example, if
it is only for the benefit of a named company) or on the manner of its use (for example, if it is only
for use on a particular computer processing unit (CPU) or at a particular site)? If so, are these
acceptable to the service?
• Is the term of the licence satisfactory?
• Are there commercial reasons for seeking restrictions on the extent to which the supplier may permit
the software (or similar software) to be used by others?

(Note that licences that refer to hardware have sometimes produced results that are uncertain and
unwelcome (from the service’s point of view) when they have been applied to multiple-core servers and
virtualised environments.)

Clear drafting of licence scope is key. The move to the cloud, APIs & interoperable systems makes clearly
drafted licence scope terms critical.

Maintenance obligations
• Are maintenance obligations clearly defined? If different priority is to be given to different categories
of fault, does the suggested prioritisation reflect the relative commercial significance of the faults to
the user? Are the suggested response times and “times to fix” satisfactory? Can the support be
given in all necessary languages at all necessary locations?
• If the supplier can terminate its maintenance obligations on notice, consider the effects of such
termination. Can the user obtain satisfactory maintenance from a third party?

Fees
• Are the provisions as to licence fees clear and fair? Has best advantage been taken of any discount
or “bundling” offered by the supplier? Does the agreement set out how any additional fees will be
calculated if the service’s use of the software changes (for example, by increasing the number of
software users or sites)?
• Are the provisions as to maintenance fees clear and fair? Is third-party maintenance available and,
if so, would it offer better value?
• To what extent are upgrades included in the licence and/or maintenance package? To what extent
is continued maintenance dependent on the purchase of upgrades at additional cost (how many
versions of the software does the supplier or maintenance company support)?

Rights to back-up, alter and maintain

• Does the licence allow the user to make copies of the software for back-up, testing or other
 purposes?
• Does the licence include the right for users (and consultants and others engaged or employed by
users) to alter or maintain the software? If so, do they have appropriate access to the source code
and any necessary tools?
• If the terms of access to the source code are covered by an escrow agreement, is the escrow agent
reliable and are the conditions for release of the software clear and easily enforceable? Will the
source code be kept up to date?

Delivery, installation and testing

• In what form is the software to be delivered (for example, on disc, CD-ROM or electronically) and
when?
• Determine responsibility for installation.
• Obtain an acknowledgement from the supplier that any hardware or associated items which the
service is purchasing for use in conjunction with the software are satisfactory for the performance
of the software in accordance with its specification.
• Will the software be tested before acceptance? If so:
• is the service clear what will constitute success: that is, are the service’s requirements well
understood and will the proposed testing regime ensure that they have been met?
• do the proposed tests cover “real life” use; for example, will they accurately demonstrate the
way the software will perform in the environment in which it is intended to function and with the
volumes it is intended to handle?

Warranties and indemnities

• Expect as a minimum:
• a warranty as to the licensor’s right to grant the licence (see Validity of Licence) and an
indemnity against third party claims;
• a warranty as to the conformity of the software with its specification or description.
• Consider the need for specific warranties on other matters (such as in relation to euro compliance).
• Has the service secured an indemnity against losses arising from claims that its use of the software
infringes the intellectual property rights of a third party?

Other terms
Consider carefully the effect of other terms dealing with:

• Confidentiality
• GDPR
• Dispute resolution
• Limitation of liability
• Termination and remedies
• Assignment
• Third party rights
• Boilerplate