ICT SERVICES AGREEMENT SCHEDULES
SCHEDULE 2.1
SERVICES DESCRIPTION
Section A - Product Description
1. PRODUCT TITLE
ICT Services Agreement - Schedule 2.1 (Services Description).
2. PURPOSE OF PRODUCT
The purpose of the schedule is to specify the Services (including any Deliverables) that the Authority is seeking to procure and that are to be provided under the Agreement by the Contractor. The services requirements should be specified with sufficient detail and certainty to ensure that they are clear, quantifiable and achievable.
3. COMPOSITION
-
The Services Description should be a comprehensive and unambiguous description of the scope of the Services that the Contractor will be obliged to deliver to the Authority. It should contain the detail of what the Services are, as opposed to the Contractor Solution (Schedule 4.1) that describes how, from a technical perspective, the Services are to be delivered.
-
It is assumed that the Authority is unable to specify its requirements comprehensively and in detail at the outset (because if it were able to do so that would suggest that the open or restricted procurement procedures should be used). Accordingly, the schedule is likely to evolve from a relatively high level statement of the Authority's needs and requirements issued at the start of the procurement process and set out in a descriptive document that accompanies or complements the OJEU notice. That description will then be supplemented by additional detail derived from a greater understanding of the possibilities that the Authority will gain during the competitive dialogue process and through consideration of information from bidders.
-
The schedule should not list the technical components that the Contractor will use to deliver the Services. These will be specified in schedule 4.1 (Contractor Solution).
4. DERIVATION
-
Authority’s requirements as specified in the initial procurement documentation.
-
Information from Bidders received during the competitive dialogue.
-
Draft Services Description schedule forming part of the final tender documentation issued after the end of the competitive dialogu
5. RELATED CLAUSES & SCHEDULES
Clauses: |
Section C - Service Supply 40.3 and guidance to clause 40.5 (Authority Data) See guidance to clause 44.1.3 (Contractor's Obligations) and clause 44.3 See guidance to clauses 48.5 to 48.7 (Malicious Software) |
Definitions: |
"Additional Services" |
Schedules: |
Schedule 2.2 (Service Levels) |
6. ALLOCATION
Ownership of, and responsibility for, the schedule rests with the Authority. It remains the sole expression of the services being procured and must not be unfairly influenced by one bidder’s proposed solution over another. The initial statement of the Authority's requirements should be issued to bidders at the start of the competitive dialogue. The Authority should consider any information they receive from bidders before proceeding to develop the schedule further as part of the final ITT documentation. During the dialogue phase, the Authority's technical and commercial team and advisors should work with their counterparts from the bidders to further develop the initial description of requirements into the agreed Service Description that will be the baseline for the final ITT.
7. QUALITY / REVIEW
-
Authority to develop agreed Services Description with the bidders during contract development phase of the procurement.
-
Authority expertise: technical, project management, commercial/procurement.
Section B - Guidance
1. INTRODUCTION
This model ICT Services Agreement is a contract for outputs and should not be used to procure inputs.
2. DEVELOPING THE AUTHORITY REQUIREMENTS
The primary responsibility for defining the business objectives and the requirements rests with the Authority; however the Contractor should contribute to help ensure that the requirements are expressed in clear and precise language in the Agreement. The process for agreeing the Services Description is to some degree dictated by the public procurement procedure you are using. In this guidance use of the competitive dialogue procedure is assumed.
3. AUTHORITY REQUIREMENTS AND THE SERVICES DESCRIPTION
3.1 The fundamental consideration in developing requirements is that if you cannot articulate what you want, the market will not be able to deliver it. Unclear objectives, poor linkage between those objectives and the intended outcomes, lack of clarity about what is required (and why) will lead to project failure. It is essential that the Authority's senior management has a clear vision of the rationale for, and desired outcome of, the project. The Authority's business objectives should provide a solid foundation for the project and a baseline against which all negotiation and progress can be measured.
3.2 The vision must be reflected in a clear statement of the requirements, with no scope for ambiguity or uncertainty about the intended outcome. At the early stages of a procurement (i.e. before a draft Agreement has been produced) it may not be possible, especially for complex ICT projects, to produce a fully detailed specification and the competitive dialogue procedure recognises this. It is, however, important that the purpose of the project is clearly expressed in terms that the market can understand in the OJEU notice and the accompanying descriptive document.
4. THE SERVICES DESCRIPTION
4.1 The Services Description defines the scope and specification of the Services to be provided by the Contractor to the Authority and, as such, is integral to the performance obligations of the Contractor under the Agreement.
4.2 The quality of the Services Description will directly impact upon the performance obligations of the Contractor, and consequently the quality and value ultimately derived by the Authority under the Agreement. If the scope of the Services is poorly drawn it is likely to result in increased costs for the Authority. Further, if the specification is vague, inaccurate or incomplete, it may lead to disputes between the parties. Getting the Services Description right before the Agreement is entered into is one of the keys to a successful ICT services contract.
4.3 The Services Description should take its structure from the Authority's initial descriptive document which will have been included as part of the documentation issued to bidders invited to participate in the competitive dialogue. The schedule will draw upon detail gathered during the dialogue with bidders. The Authority's requirements and each bidder's proposals should be jointly reviewed and explored by the Authority and the bidder during the contract development/dialogue phase. The Authority should then ensure that these documents are developed into an agreed and comprehensive description of what the Contractor is required to deliver and this will form part of the draft contract documentation that accompanies the final invitation to tender.
4.4 Developing a detailed Services Description before the final invitation to tender is important in order to avoid contracting on the basis of a high-level statement of objectives so that the only real detail is in the Contractor Solution. If the Services Description is comprehensive then the Contractor Solution can be restricted to how the Services will be delivered. If the Services Description is insufficiently detailed there is a danger of having to read two documents to discover the detail of the Authority's requirements. This creates confusion and leads to arguments about which is the "dominant" document in the hierarchy. Because of the nature of the procurement process, and because the procurement regulations make it clear that once you have received the final tenders you are limited to fine-tuning it is not permissible to create a "cocktail" of the Authority's requirements and the Contractor's solution; for example in a period of post-tender negotiations.
4.5 When it issues final invitations to tender, the procuring Authority must be in a position to have established a common requirements baseline against which it evaluates the bidders' responses. If, on the other hand, the competitive dialogue procedure were to be seen as a process for developing a mixed requirement / solution document for each bidder individually, then tender evaluation becomes extremely difficult.
4.6 Accordingly, the development of a comprehensive Services Description schedule does not mean that one can dispense with a Contractor Solution schedule. There will still be two schedules in the contract and the difference between them is best summarised by the 'what' / 'how' dichotomy. What is not recommended is to have two documents containing the 'what' expressed in different degrees of detail.
5. CLASSIFYING THE SERVICES
5.1 The following definitions of services could be used to distinguish the Authority's requirements:
5.1.1 Core Services: these are services for which the requirements are fully defined at contract signature and the payment for which is included in the schedule of charges (also agreed at contract signature).
5.1.2 Additional Services: these are services for which the requirements are again fully defined at contract signature and which the Contractor must be capable of delivering. However the price for these services is not catered for in the price agreed for the Core Services at contract signature (save where there is an allowance up to a certain volume or cost limit for additional services). Nevertheless the Contractor must provide these services if requested to do so, but if they are requested (and they go beyond any allowances permitted within the schedule of charges), there will be an increase in the charges. This increase should be based on prescribed rates (e.g. day rates per Contractor employee engaged in delivering the additional services) or a prescribed method of calculation.
5.1.3 The use of additional services can help in circumstances where there is a need for an element of choice and the parties are already able to define the requirements in respect of the services involved.
5.1.4 Additional services can be further broken down into:
5.1.4.1 catalogue services: i.e. specified supplies or services that are listed in a catalogue in an Agreement schedule for a firm price (either as a set price or through a pricing mechanism using agreed parameters) and can be “called off” or ordered during the term of the Agreement; and
5.1.4.2 executable options: i.e. a specified service listed in the Agreement for a firm price (either as a set price or through a pricing mechanism using agreed parameters). The main difference from a catalogue service is that an executable option is a significant addition to the services delivered under the Agreement.
5.1.5 Future Services: these are services that do not fall into any of the above categories and their requirements have not been fully defined at contract signature. The Authority should not use an approach that results in a significant level of Future Services. In general Future Services should only be used by the Authority if:
5.1.5.1 it is very clear about what it wants to achieve; and
5.1.5.2 will be able to negotiate the changes in services properly and manage the contract fully.
5.1.6 In most cases value for money will best be achieved by allowing for competition for Future Services. If there is any doubt about the certainty of the future requirement, the Authority should consider carefully whether it should be included in the procurement at this stage. It may be prudent to run a separate procurement exercise later.
5.2 Where Future Services are used in the Agreement they should be made subject to the change mechanism (schedule 8.2) and an established methodology for agreeing any additional costs. Consider whether it is appropriate to describe some of the Future Services that are envisaged (only where the requirements are not capable of being fully defined at the point of contract signature) in a separate schedule at a high level. The agreement may specify an indicative price for the delivery of these services, together with details of how this price has been estimated.
5.3 Note: any requirement for Future Services may only be specified in the Services Description if the requirement is within the scope of the relevant OJEU notice.5.4 Further categorisation of the Services
5.4.1 For the benefit of the Authority's understanding and to ensure that the business criticality of the Services is fully quantified, it is advisable to align the Services Description to the way that the Authority's business is categorised. The Contractor may attempt to package the services in a way which suits its own needs or in such a manner that it is able to reuse the package of services to sell into other customers.
5.4.2 Additionally it may aid the Authority's understanding of the Services by differentiating between tangible services (which require human interaction, such as management services) and intangible services (which are automated, such as network services). A clear differentiation of the services will greatly assist objectivity and reduce the likelihood of disputes and changes through the term of the Agreement.
6. RELATIONSHIP WITH SERVICE LEVELS
6.1 The Services Description specifies what will be performed, as distinct from the standard (or service levels) to which those services will be performed. The two elements are inextricably linked although a separation is necessary to reflect, in particular, the transition between the build and operational phases; this is a critical feature of an ICT Services Agreement in that it is rarely possible to test the quality of service delivery until the full operational phase of the project. Specifying an output and testing that output before service delivery commences is not enough to ensure that the quality of service provision is satisfactory and is maintained through the life of the Agreement.
6.2 The Services Description is therefore closely linked with the Service Level schedule (schedule 2.2) which sets out the levels to which the Contractor will deliver the Services and the mechanisms for monitoring the Contractor's performance. Typically each Service stream (line item) will have an associated Service Level or set of Service Levels and, as such, Service Levels can be seen as an extension of the Service Description in that each Service Level will be a qualitative measure of a quantitative output.
6.3 The Service Level schedule and the Charging schedule (schedule 7.1) will set out the consequences of a failure by the Contractor to achieve the requisite quality of service and will typically prescribe a service credit regime.
7. DRAFTING THE SERVICES DESCRIPTION SCHEDULE
7.1 Certainty and clarity
7.1.1 Certainty and clarity are key to a workable (and enforceable) Services Description and underpin the core performance obligations of the Contractor. In order to achieve certainty and clarity, the drafting of the schedule should:
7.1.1.1 clearly and comprehensively set out all of the Services that the Contractor will provide and the specifications of those Services; and
7.1.1.2 specify to whom the Contractor will provide those Services, and, as appropriate, when and where it will so provide.
7.1.2 The actual description of the Services should be ring-fenced from any description of Service Levels and any Authority Responsibilities.
7.1.3 Other than in exceptional circumstances, the Services Description (the "what") must take precedence over the Contractor Solution (the "how"). However, in circumstances where the Services provided by the Contractor interface with the Authority's and other third party's services and systems the specifications and requirements of the interfaces will need to be set out in the Agreement. Unless these are covered off in greater detail in a separate document (e.g. an appendix to the Services Description or a separate schedule covering interfacing requirements), then the Services Description should seek to define these interfaces and the Contractor's responsibilities for creating, managing and maintaining the interfaces. A clear delineation of the Contractor's responsibilities in relation to interfacing is important to reduce: (i) the burden on the Authority to manage relationships between suppliers; and (ii) the likelihood that a supplier will seek to shift blame for a defect or failure onto another supplier (it may prove difficult for the Authority to deduce where the responsibility for the failure lies). To avoid an over emphasis placed on any technical interfacing methodology, they should be expressed as being secondary to the requirements described in the Services Description in order to maintain focus on the delivery of systems and services defined in the outputs.
7.1.4 The Services Description must not be written in anything approaching a "sales" style nor should it use "aspirational" language. The Services Description must make clear and unambiguous statements about what is required. The Service Description should be written in mandatory/contractual language, for example, the description of an incident management service should not state that it is "designed to minimise the impact of an incident" but, instead, provide that the Contractor "shall minimise the impact of an incident".
8. SPECIFIC ISSUES ARISING OUT OF FLUID OR VOLATILE REQUIREMENTS
8.1 In certain projects, the deliverables defined at contract award (ie the core services) are unlikely to reflect the requirements fully at the end of the contract term. Due to their close relationship with core business activities, ICT projects are more likely than other types of project to be affected by changes to business practice. As the scope and impact of such changes are difficult to foresee, it may be difficult to gauge their possible impact on the requirements or the Contractor Solution when these documents are prepared at the start of the project.
8.2 This gives rise to a tension between the need for clear requirements, and the need for flexibility. However, contracts should not be constructed on the basis that a fixed state will exist; flexibility does not in itself create contractual uncertainty. As a general principle, the correct way to handle any variations to the requirements should be to subject them to a change control mechanism. Leaving 'room for manoeuvre' in the requirements is not an acceptable approach.
8.3 Where requirements are rapidly changing or developing it may be preferable to opt for shorter-term contracts.
Section C - Pro-forma / Example Schedule, Services Description
[Guidance: It may be necessary to introduce new definitions at this point to ensure that the purpose, phases and elements of the project are clearly defined. It is important to check that any definitions relating to the project or the services that have been already used in the body of the Agreement, do not conflict with the Services Description to ensure consistency.]
9. INTRODUCTION
[Guidance: The introduction is used to outline the high level deliverables from the project and how the Contractor will facilitate the completion of the project through the provision of services to the Authority. The following wording has been included as a guide to the type of issues covered in the introduction, but this should be carefully tailored to suit each Agreement and set of circumstances.]
9.1 [Outline why the Authority has identified that it needs the Contractor to provide the services.]
9.2 This schedule sets out the intended scope of the Services to be provided by the Contractor and to provide a description of what each Service entails.
[Guidance: Please note that the draft agreement and definitions anticipate suitable definitions being provided in the Services Description of "Pre-Operational Services" and "Operational Services" to distinguish those aspects of the Services which are relevant to before or after ATP. If the project structure means that these items are not appropriate then the agreement and definitions will need to amended accordingly.]
10. CORE SERVICES
[Guidance: The Core Services describes the services that will form the main activities undertaken by the Contractor in fulfilment of the Agreement. The services required from the Contractor must be carefully considered and specified. The headings below are included for guidance purposes only. Examples of what Core Services may cover are as follows:
10.1 Generic Services
[For each service you may wish to give some general background, describing the nature of each service; and
insert a non-exhaustive list of specific activities for each service]
10.2 Project Support Services
10.3 Technical Services
10.4 Requirements Analysis Services
10.5 Design Services
10.6 Development Services
10.7 Integration Services
10.8 Deployment Services
10.9 Training and Communication Services
10.10 Support and Maintenance Services
10.11 Software Integration Services
10.12 Procurement Activity Support Services
10.13 Obligation to provide a Business Process Manual (as defined in schedule 8.5 (Exit Management) including details as to its contents and timings for its supply together with obligations to update and supply copies to the Authority.]
[Guidance: The Authority may wish to set out any technology refresh requirements in the Services Description.]
[Guidance: There will often be Services that need to be migrated into separate schedules either due to their complexity or the level of detail required to define the requirements. If this is the case then the Service Description must refer out to the other schedules, for example it is assumed in this Agreement that Testing Services will be defined in schedule 6.2. The following schedules may need to be treated in this way:
Testing Services - set out in schedule 6.2
Business Continuity and Disaster Recovery - set out in schedule 8.6
Standards - set out in schedule 2.3
Security Requirements set out in schedule 2.
11. ADDITIONAL SERVICES
[Guidance: Additional Services are optional elements of the service which the Authority may choose to 'call down' from a list of pre-determined, pre-priced services provided by the Contractor.]
12. FUTURE SERVICES
[Guidance: A high level description of any envisaged future services should be listed under this section together with an indicative price and a breakdown explaining how the price has been derived.
Future Services are optional elements of the service which the Authority may choose to 'call down', but where the scope of the service has not yet determined or priced. The Authority must have previously specified any Future Services in the OJEU notice. The use of Future Services will need to be carefully considered on a case by case basis and procurement law issues will need to be addressed. As much detail as possible should be included in relation to the Future Services, e.g. the procedures for agreeing the precise scope of the services and, in particular, the pricing mechanisms and methodology which will apply]