Annex 2: Statement of work. Table of contents

Transcription

1 UNFCCC/CCNUCC Page 1 Annex 2: Statement of work Table of contents Annex Objective... 2 Engagement... 2 Overall approach... 2 Partnering... 3 Quality and reviews... 3 Developer contract... 4 Operator contract... 4 Coordination and decision-making... 4 General constraints... 6 Development component... 6 Operational Component... 9 Project planning Developer planning Operator planning Suggested schedule Payment Stages... 16

2 UNFCCC/CCNUCC Page 2 Annex 2 Statement of work Objective 1. The purpose of the ITL is to monitor the validity of the transactions conducted by registries under the mechanisms defined in Articles 6, 12 and 17 of the Kyoto Protocol and the modalities for the accounting of assigned amounts under Article 7.4 of the Kyoto Protocol. 2. The objectives of the work under this RFP, as elaborated in subsequent annexes, are: (a) (b) to develop the ITL, including requirements review, software design and development, testing, support of software deployment, documentation and training, second line support, change management and organizational support. to configure and operate the ITL, including data centre infrastructure, networks, testing and acceptance, service desk and first line support to users, support for the initialization of registry connections to the ITL, strategic technical support to the secretariat, and change management and organizational support. 3. The selected vendor/s will follow the specifications contained within this RFP and work with the ITL s users and the secretariat s agents to deliver this. Engagement 4. A vendor may propose to deliver either: (a) (b) (c) the development component of this RFP (as the Developer), as described in Annex 12, or the operational component of this RFP (as the Operator), as described in Annex 15, or both components together (as the Developer and Operator). 5. The vendor must make clear which component(s) it is proposing. 6. Proposals that combine the development and operational components are encouraged. 7. If the proposal is for only one component, the vendor is encouraged to select a sub-contractor which can perform the other component. 8. The secretariat reserves the right to assess and award the two components separately. The proposal should clearly separate the two components in the technical and financial proposals. 9. A vendor may, as part of its proposal, sub-contract portions of development and/or operational components. Overall approach 10. The ITL development and operation is part of a broader programme of work within the secretariat to facilitate emissions trading and the accounting of assigned amounts under the Kyoto Protocol. 11. The ITL is to operate prior to, during and beyond the first commitment period under the Kyoto Protocol ( ). The process of connecting registries and the CITL is to begin in the 3rd quarter of 2006 with the review of registry/citl documentation by the Operator. The fully deployed ITL is to be tested and accepted, including by the secretariat, no later than 31 October 2006 in order for registries and the CITL to conduct their initialization testing. Subject to the availability of funds and mandates from the COP/MOP, the ITL will continue operating until at least Annex 2: Statement of work Page 2

3 UNFCCC/CCNUCC Page 3 Partnering 12. The secretariat is seeking a strategic partnering arrangement to help it implement its mandated functions. As well as offering implementation services, a vendor should be able to provide longer-term strategic support and technical expertise to the secretariat. The secretariat will lead the work on the ITL and drive its technology direction and business architecture itself, but will require support with sound feedback, technical advice, and architectural skills, from its vendor/s. The Operator, in particular, will need a broad mixture of skills and experience to achieve this. Some of these skills may be needed on an everyday basis, while others may be needed only occasionally. 13. The successful vendor/s will support the secretariat in most of the technical and administrative aspects of the development and operation of the ITL. This will include: (a) (b) (c) (d) (e) (f) (g) (h) (i) building the ITL software, including administrator application and interfaces designing and building a resilient hosting environment (at two sites) with production and preproduction ITL environments deploying and accepting the ITL into a pre-production and production environments Operating and maintaining the ITL and managing change relating to the ITL supporting registries and STLs which connect to the ITL, including through defining and implementing initialization processes for these connections Coordinating data issues, including through ensuring that balances reconcile between the ITL, registries and STLs supporting the distribution of summarised or transactional data into other reporting systems providing strategic technical support to the secretariat, including in relation to the ITL, the RSA Forum and support for improvements in market processes supporting the work of the registries 14. The development of the ITL may re-use existing tools and development work, including source code and documentation that have been used for other equivalent applications, if the vendor considers this to be advantageous regarding time, cost, and/or quality. For example, the CITL was developed as an extension of the ITL software specification (see Annex 13). Some ITL functionality was not required for the CITL, and was therefore not developed for it, while some additional functionality was defined and developed for the unique purposes of the CITL. The European Commission has agreed to make available the CITL source code and documentation to any vendors which may wish to make use of it. 15. Further information on the CITL is contained in annex 17. Vendors wishing to view the full source code of the CITL may do so. In order to arrange this, vendors should contact Mr Kanwarjit Sachdeva at the secretariat (at facsimile no. (+49) ) by 11 November Quality and reviews 16. The external delivery dates noted are sensitive and the secretariat wishes these to be achieved without loss of quality and usability. The Developer should therefore demonstrate a method or quality regime with deliverables and activities that can be clearly explained, measured and tracked. It should note its controls and mechanisms to ensure that requirements, issues and risks are managed, and cost and scope controlled, while receiving adequate input from the secretariat and other parties. 17. The system operations and support require 24/7 attention and hence the Operator should be able to demonstrate its confidence and experience in operating under a quality environment. It should be able to identify its required documentation, procedures, and processes, and explain how its service desk and technical teams will operate and support the ITL applications. 18. The secretariat will subject the development of the ITL design, source code and documentation to peer review by a 3 rd party. Adequate and appropriately timed review points are to be incorporated by the Developer into the development process and schedule for this purpose. The Developer is to take due account of recommendations made under this peer review process. 19. The secretariat reserves the right to subject the project management of the ITL development to review by a 3 rd party. Adequate and appropriately timed opportunities are to be provided by the Annex 2: Statement of work Page 3

4 UNFCCC/CCNUCC Page 4 Developer to allow the secretariat to assess whether it wishes to engage a 3 rd party for this purpose and to allow such a review to take place. The Developer is to take due account of recommendations made by the secretariat as a result of such a project management review process. Developer contract 20. Subject to the availability of funds and mandates from the COP/MOP, the secretariat wishes to contract the Developer until Once the initial development work is complete and has been accepted by the secretariat, and once the warranty period has ended, the Developer will provide services under maintenance and support arrangements. A detailed SLA is to be defined for this purpose. Operator contract 21. Subject to the availability of funds and mandates from the COP/MOP, the secretariat wishes to contract the Operator until A detailed SLA is to be defined with the Operator (based on Annex 15). 22. In order to provide flexibility over this long contract period, for both the secretariat and the Operator, a biennial contract review will take place. The first review is to be completed by the end of February 2009 and subsequent reviews are to be completed in two-yearly cycles thereafter. Any contract revisions will generally be effective from the beginning of the subsequent calendar year. This timing is in order to feed results from the contract review process into the biennial budget cycle of the secretariat. The first relevant secretariat biennium budget is This biennial contract review is to: (a) (b) (c) (d) (e) identify changes to, additions to, or the withdrawal of, services to be supplied by the Operator identify major technological and operational changes identify efficiencies that may be implemented in the contracted services update the security processes and risk assessment for the ITL ref network design consolidate any changes which have occurred since the previous contract review 24. The contract review is to take place on the basis of the review scope and preferences stated by the secretariat and an assessment by the contract review team (see below). Coordination and decision-making 25. The coordination and decision-making concerning the activities of the secretariat, Developer and Operator will occur through the bodies set out below. The secretariat retains ultimate authority over the ITL and related activities (within its contractual agreements and constraints). Annex 2: Statement of work Page 4

5 UNFCCC/CCNUCC Page 5 Body Roles and responsibilities Frequency Member roles ITL Coordinates the realisation of ITL objectives Chaired by the steering secretariat group ITL change forum Contract review team Oversees scope, budget, and expenditure; mandates actions and coordinates adequate responses from the vendor/s and the secretariat; ensures that the roles and responsibilities are appropriate Monitors progress of the ITL and related activities and ensures they meet requirements, quality and cost parameters Ensures issues and risks are understood and appropriately addressed Engages other stakeholders, considers the results of quality reviews, and reports upwards within the secretariat and vendors as required. Resolves issues of responsibility between the Operator and Developer Coordinates and approves major and minor changes that would alter the scope, timing, organization or impact of ITL activities Assesses changes to the data exchange standards proposed in the context of the RSA Forum and makes appropriate recommendations to the secretariat Engages expertise and stakeholders to ensure that changes are assessed and appropriately approved Reports to the steering group and escalates issues as required Resolves issues of responsibility between the Operator and Developer Recommends to the secretariat major changes regarding the scope of the requirements under the contract Reviews and benchmarks technology direction, processes, and major changes Meets monthly (meets more often during development or sensitive periods) Meets as required (probably monthly at first) Biennial review (first review to be completed by March 2009, thereafter to be completed every two years) Members include the senior project representative(s) from the Developer and Operator; may also include quality advisors and other stakeholders, as required A working group, reporting to the steering group Members include representatives of the Developer and Operator; may also include quality advisors and other stakeholders, as required Secretariat sets scope of contract review and indicates its preferred changes Members mostly from the Operator (this may vary depending on the secretariat s brief) 26. The Developer and Operator will normally attend these meetings of these bodies at the secretariat s offices in Bonn. Meetings may take place by phone or video conferences, at the discretion of the secretariat. 27. After systems goes live, issues to be addressed in these bodies are expected to revolve increasingly around enhancements, deployment of upgrades, bug-fixes, reconfiguration, and ongoing maintenance. The change forum will become the primary manager of these items. The input of the Developer is expected to decrease and the input of the Operator is expected to increase over the lifetime of the ITL. Annex 2: Statement of work Page 5

6 UNFCCC/CCNUCC Page 6 General constraints 28. The Developer and Operator must conduct all documentation and external communication in English. All development and operational work must be annotated in English. 29. The secretariat will not provide any resources, locations, environments, development software or equipment for the development and operation of the ITL. Development component 30. The Developer is to undertake the development activities specified in Annex 12, taking into account the target performance quality specified in Annex 11. Annexes 13 and 14 contain specifications to be met through the development of the ITL. The development component is summarized in this section. 31. The specifications contained in Annexes 13 and 14 may be considered stable. The data exchange standards contained in Annex 14 have been successfully implemented by national registries, the CDM registry and the CITL. The software specification contained in Annex 13 was primarily based on the data exchange standards and provided the basis for the successful development of the CITL. 32. The progress of the Developer will be reported to, and reviewed by, the ITL steering group. 33. The Developer is to provide a warranty on its software for 180 days, beginning with the acceptance by the secretariat of the software in the live production environment. During this warranty period, the Developer will perform break/fix operations on the software at no extra fee. After this warranty period, the Developer will maintain and fix application problems under maintenance and support arrangements. It will maintain core software skills and a development/test environment under those arrangements. Specification Annex 13: Software specification Annex 14: Data Exchange Standards Outline description This describes the software specification of the ITL, including: Transaction processing, reconciliation processing and administrative processes Database entity relationship diagrams, data element definitions, lookup tables and values Functions and components (web services) Transaction and reconciliation checks ITL system interfaces, including for registries, STLs, secretariat data systems, and data analysis and reporting tools Administrator application This software specification, though detailed, is included to identify the required functionality, the scope of work and estimate of effort. The Developer is to review and validate this specification and seek advice from the secretariat in making any amendments. This specification defines in detail the sequence, content, format and security of messages to be communicated between registry systems. All registries and STLs must connect to the ITL using the appropriate version of these standards. The ITL must therefore support these standards. Annex 2: Statement of work Page 6

7 UNFCCC/CCNUCC Page 7 Development task 1. Review of requirements 2. Software design and development 3. Hardware and software configuration support * 4. Support of software deployment and operation * 5. Testing and acceptance * Outline description The Developer will review the software specification It will, with the secretariat, analyse, clarify and extend the specifications where the specification is incomplete or lacking in detail and resolve any errors or inconsistencies The Developer will build the ITL software and its associated systems It will test those systems on its own development infrastructure The Developer will select a technical architecture for the system, advised by the Operator The Developer will liase with the Operator to ensure that the final software design complements the Operator s configuration at an appropriate level, and that the chosen layered products (hardware, software, and network components) can be supported by the data centre infrastructure. The secretariat will review and approve the final design to ensure it fits into its ICT strategy An ITL production system will be deployed into the live site and the backup site for normal live use. One pre-production system will be deployed into the Operator s environment for the initialization of registry/citl connections to the ITL. Another pre-production environment will be made available as required for ad-hoc test purposes. The Developer will assist the Operator with the creation of operational scripts for these environments (start-up, shut-down, monitoring, tidyups, etc) and assist in the initial deployment into the pre-production environments. The Developer will prepare test plans, cases, data, procedures and scripts It will run tests to ensure that the system meets the functional and nonfunctional requirements The Operator will assist the Developer in conducting end-to-end testing on code hosted from its data centre, and will accept the delivery of working software into its production and pre-production environments. The secretariat will test the ITL and its supporting applications, and accept it if appropriate, once deployed into the Operator s environment. 6. Documentation The Developer will prepare adequate documentation for the Operator to fit into its day-to-day operational tools. Both Developer and Operator will work together to agree requirements and fulfil these requirements 7. Training The Developer will familiarize the Operator and the secretariat with the characteristics of the software needed for testing, deployment, initialization and ongoing administration and support (this may need to be updated periodically in line with software changes). 8. Hand-over code All source code and documentation will be delivered to the secretariat at key times during and after the development, at times incorporated in the Developer s schedule. Annex 2: Statement of work Page 7

8 UNFCCC/CCNUCC Page 8 Development task Outline description 9. 2 nd line support * The Operator will provide 1 st line support via its service desk and will only escalate difficult ITL application issues to the Developer. 10. Initialization support * Responses to issues by the Developer may require out-of-hours working in order to respond in a timely way. Target response times will be defined in a detailed SLA which will be consistent with the Operator s SLA. The Developer will support the Operator s service desk through many of the steps involved in the initialization of registry/citl connections to the ITL, in particular at the beginning. This is to include test cases and scripts, knowledge-transfer, training, documentation, site visits, and on-site support. The Developer will work up the test plan to be used during initialization, with review and support by the Operator. The Operator will be responsible, through its service desk, for the support of registries and the CITL and the coordination of initialization schedules. Many registries will be initialised independently. The initialization of EU registries and the CITL will need to be coordinated and may need activation on the same date. 11. Secretariat support The Developer will be expected to contribute to the strategic thinking of the secretariat. This may include providing advice on the efficient use of technologies, assessing the implications of changes, adoption of best practice, and technology refresh. 12. Maintenance and support 13. Contract steering and organizational support It will review the technical architecture and support component in the context of the biennial contract reviews. The Developer may need to provide technical services related to the ITL application to the secretariat in its support of the RSA Forum. The Developer may need to provide ad-hoc support to demonstrate the ITL. It will be encouraged to participate in other related technical forums on its own account. The Developer will make itself available, under maintenance and support arrangements, to support the software and respond to requests for changes during the operation of the ITL. The Developer will: participate in coordination bodies and change management * These items are to be closely coordinated with the Operator. See below. Annex 2: Statement of work Page 8

9 UNFCCC/CCNUCC Page 9 Operational Component 34. The Operator is to undertake the operational activities specified in Annex 15, taking into account the target performance quality specified in Annex 11. The operational component is summarized in this section. 35. The activities of the Operator will be reported to, and reviewed by, the steering group. Operational item 1. Data centre infrastructure Outline description The Operator will: 2. Internal networks The Operator will: review and approve components of the data centre infrastructure which are recommended by the Developer* provide input to the Developer regarding operability work to ensure resilience and fail-over through the selection of the network and data centre architecture concerning the primary and secondary sites* procure ITL hardware, databases, and layered products to be installed in its data centres provide physical locations of ITL equipment within segregated, secure rack space, with all appropriate connections, power, etc perform testing, pilot testing and roll-out of the ITL provide 24/7 production management of the live production environment in accordance with Annex 11 provide an initialization and other pre-production test environments provide support in performance, resilience and business continuity planning manage system monitoring and problem escalation manage operations and security (access, virus, OS, patches) provide configuration management and change management cooperate with the Developer in its development of appropriately specified software and formally accept production code, scripts and documentation from the Developer* provide network design, connections, VPN equipment and tools to be used by its data centres and service desk* configure networks and manage security and certificates monitor internal networks and manage their support and escalation Annex 2: Statement of work Page 9

10 UNFCCC/CCNUCC Page 10 Operational item Outline description 3. External networks The Operator will: 4. Technical administration to registries and CITL 5. Initialization support issue an early recommendation of the network specification to registries, for them to budget, procure and deploy, and assist them in establishing and troubleshooting connections configure networks and manage security and certificates monitor external networks and manage their support and escalation The Operator will: provide a 1st-line service desk with overall ownership of problems* run a trouble-ticketing system, with access to an information/knowledge base, and escalation procedures* liase with registries. This may include sending out messages, announcements, and coordinating schedules 1 perform low-level data administration (supporting static data, troubleshooting reconciliation issues) providing basic user statistics on behalf of, or through, the secretariat The Operator will: provide a service desk and coordinate and schedule the initialization process for all registries and STLs* define documentation standards and review documentation assist in production of test scripts and provide oversight of testing* make site visits (where necessary) supervise re-testing where initialization encounters problems coordinate the data migration from the CITL to the ITL* provide a simple collaboration tool for the secretariat to communicate with its user base during and after initialization. This should include a shared issue-tracking environment for the use of all participants during and after initialization The Operator will be responsible for the direct support of registries and STLs. The Developer will initially provide support but this will be phased out rapidly as the service desk gains experience 1 Note the working language for the ITL and the RSA Forum is English. Annex 2: Statement of work Page 10

11 UNFCCC/CCNUCC Page 11 Operational item 6. Strategic technical support to the secretariat 7. Contract steering and organisational support Outline description The Operator will: procure and manage sub-contracts and layered products provide technical support to the secretariat, such as contributions to change processes, documentation, information gathering and statistics* assist in development of the data exchange standards and procedures to be implemented by registry system administrators support the secretariat in meetings, including the RSA Forum, and demonstrations of the ITL, participate in quality reviews and audits The Operator will: participate in coordination bodies and change management report on SLA performance and the monitoring and escalation of issues conduct or support periodic audit requirements, performance reviews * These items are to be closely coordinated with the Developer. See above. Project planning 36. Detailed schedules are to be prepared for the development and operational components of the work on the ITL. These schedules must be jointly coherent through each schedule and identify consistent inputs and outputs to and from the other schedule. 37. The schedules must reflect the following key external deadlines: (a) (b) (c) (d) registries and the CITL must be informed of network equipment specifications and/or certificates early in the process in order to give them sufficient time to budget for and install their secure communications a pilot testing version of the ITL is to be available to interact with participant systems no later than 31 August 2006 the process of connecting registries and the CITL is to begin in the 3rd quarter of 2006 with the review of registry/citl documentation by the Operator; the fully deployed ITL is to be tested and accepted by no later than 31 October 2006 in order for registries and the CITL to conduct initialization testing. key registries and the CITL should have activated their initialized connections to the ITL by no later than 1 April 2007 in order to allow them to process transactions. Developer planning 38. The Developer will prepare and manage its own project plan that identifies its schedule in delivering the requirements under the development component. It will manage and control its resources and output and will work with the Operator, the secretariat and stakeholders in order to ensure that the plan is met and that deliverables are of appropriate quality. The project plan will show the project management approach adopted by the Developer. Annex 2: Statement of work Page 11

12 UNFCCC/CCNUCC Page The project plan will describe the nature and timing of internal and external milestones, including: (a) key iterations in the software development (b) key liaison points with the Operator (c) key liaison points with registries and the CITL (d) key documentation and training deliverables (e) key review and feedback points for the secretariat and quality reviews (f) the preparation and implementation of testing, in particular for acceptance and initialisation (g) delivery and archiving of source code (h) resource allocation Operator planning 40. The Operator will prepare and manage its own project plan that identifies its schedule in delivering the requirements under the operational component. It will manage and control its resources and output and will work with the Developer, the secretariat and stakeholders in order to ensure that the plan is met and that deliverables are of appropriate quality. The project plan will show the project management approach adopted by the Operator. 41. The project plan will describe the nature and timing of internal and external milestones, including: (a) (b) (c) (d) (e) (f) (g) key deliverables key liaison points with the Developer key liaison points with registries and the CITL development and implementation of SLA reporting key review and feedback points for the secretariat and quality reviews delivery and archiving of source code resource allocation Suggested schedule 42. This section contains a suggested schedule, based on the key external deadlines specified above and the secretariat s assessment of some of the other major milestones. This is a joint schedule for both the development and operational components of the work relating to the ITL. With the exception of the specified external deadlines, the schedule is indicative only and is provided to guide proposals. Annex 2: Statement of work Page 12

13 UNFCCC/CCNUCC Page 13 Suggested schedule Start Development 1 Apr Aug Oct Apr 2007 Deploy Developer s collab. tool SW reqmts, design & build Develop test data & scripts Agree initial HW & SW config Confirm Operator s SLA Prep. service desk &Tech Ops Specify external network config. Specify & procure environm ts Deploy 1 st cut ITL modules Deploy Operator s collab. tool Confirm pilot test dates Propose initialization schedule Start initialization doc review Deploy SW for pilot testing Service desk & Ops. training Pilot tests: connectivity testing Pilot tests: end-to-end testing Deploy v1 ITL into initialization Confirm initialization schedule Initialization connectivity tests Perform initialization in stages Agree SLA reporting Test, commis n other interfaces Deploy v1 onto live environment Live technical ops start Live tx-logging starts Most/all Parties fully operational Design backup environment Procure & install backup eqpt. Backup test & acceptance Secondary backup site live Timeline not to scale External milestone Internal milestone Date/sequence Task Notes 1 April 2006 Start of work under the development component (ASAP) (ASAP) (ASAP) (ASAP) Developer starts requirements review and software design Developer provides a collaboration tool for resolving problems, questions, etc relating to the software specification Participants are informed of network connectivity requirements Developer agrees hardware and software configuration with Operator. Ref: itracker Early notification is required so participants can assign budgets and schedule work with contractors Early specification is required so Operator can develop its SLA and prepare infrastructure Annex 2: Statement of work Page 13

14 UNFCCC/CCNUCC Page 14 Date/sequence Task Notes By 31 Aug 2006 By 31 Oct 2006 Development and confirmation of SLA with Operator and start of work under the operational component Developer and Operator specify and agree on live, test and pre-production environment designs. Secretariat approves the design. Operator develops an infrastructure design. Developer deploys first-cut ITL software modules (e.g. communications hub) onto a test or pre-production environment. Operator s issue tracker and knowledge base software is deployed Service desk confirms pilot testing dates with participants, in consultation with Developer Service desk indicates approximate initialization schedule with all participants Initialization starts with review of registry/citl documentation. Service desk collects initialization documentation and coordinates and tracks their review and approval Developer deploys a complete release of software for pilot testing Developer and Operator train and familiarise service desk staff in application, procedures and support tools Pilot test participants test for connectivity Developer, Operator (service desk) conduct pilot tests with participants Developer releases v1.0 of software, including administrator application. Operator tests and accepts software into initialization environment. Secretariat accepts software Normal operations start on initialization environment (backups, monitoring, technical support, etc) Service desk confirms initialization testing schedule with all participants Initialization participants, including CITL, conduct preliminary network connectivity tests Operator contract may be assessed and awarded separately from the Developer contract Subject to review after performance tests and feedback from registry experience. Secretariat needs to ensure this is consistent with its long-term ICT strategy. Developer trains/familiarises Operator with system Operator s service desk support tools in place. Ref: itracker Service desk is first set up as a skeleton force and assumes key contact role with pilot testing participants Service desk assumes role as key contact point for all initialization participants and circulates test plans and data in advance Satisfactory documentation is a prerequisite before initialization testing may start Pilot test version needs to be tested and accepted Service desk assumes role as key primary technical contact for participants Technical test to ensure pilot participant s networks are ready, in order of: CDM registry, other registry developers and CITL ITL external testing of preproduction systems site visits. Acceptance is subject to satisfactory testing and connectivity to CITL Schedule to be phased, and to take into account busy registry periods Technical tests to ensure initialization networks are ready Annex 2: Statement of work Page 14

15 UNFCCC/CCNUCC Page 15 Date/sequence Task Notes By 1 Apr 2007 End Feb 2009 Initialization participants, including CITL, conduct initialization testing in stages, with support of the service desk. Service desk informs participants of initialization results and activation schedules Service reporting of SLAs with Developer and Operator are agreed Test and commission ITL interfaces Production release of software, including administrator application deployed into live environment. Secretariat accepts software Normal operations start on production environment (backups, monitoring, technical support, etc) First participants go live on production environment Operator, including service desk, accept software and hardware running at secondary site Key registries and CITL to have activated their initialized connections and be operational with the ITL First biennial contract review completed Visits to the major sites may be required for service desk familiarisation and support Participants connections are to be approved by the secretariat After trialing through initialization Activation of interfaces for other secretariat systems Release is subject to satisfactory initialization Assisted by Developer Subject to successful fail-over drill Annex 2: Statement of work Page 15

16 UNFCCC/CCNUCC Page 16 Payment Stages 43. Three milestones are specified below for payment to be made for the initial development of the ITL software under the development component of this RFP. Subject to the satisfactory completion of the relevant deliverables, fixed costs will be paid in three equal amounts at these milestones. Variable costs will also be paid at the same milestones, subject to their conformity with the financial proposal and satisfactory completion of the relevant deliverables. 44. Thereafter, once the warranty period has ended, payment will be made regularly (quarterly) on the basis of work undertaken under maintenance and support arrangements. Stage Development payment milestones Target Date D1 D2 D3 Deployment and acceptance of complete ITL software for pilot testing, including detailed technical design, detailed software architecture, installation scripts and manual, user guide and reference, operations guide, test plan, test cases, test procedures and test scripts Deployment and acceptance of complete ITL software into initialization environment, accepted by the Operator and secretariat, including full documentation and training delivered Deployment and acceptance of complete ITL software into live environment and acceptance of all work by the secretariat by 31 August 2006 by 31 October Three milestones are specified below for payment to be made for the initial set-up of the ITL under the operational component of this RFP. Subject to the satisfactory completion of the relevant deliverables, fixed costs will be paid at these milestones (note that the percentage of the total fixed costs to be paid at each milestone does not need to be equal). Variable costs will also be paid at the same milestones, subject to their conformity with the financial proposal and satisfactory completion of the relevant deliverables. These costs should include direct costs for hardware and 3 rd party software. 46. After the third milestone has been reached and paid, payment will be made regularly (quarterly) on the basis of work undertaken for the ongoing support and operation of the ITL. Stage Operational payment milestones Target date O1 O2 O3 Pilot test environment ready and accepted by Operator, with ITL software deployed in it for the first pilot testing participants Initialization environment ready and accepted by the secretariat, with ITL software deployed in it for the first initialization participants Live environments at primary and secondary sites ready and accepted by the secretariat, and first registry goes live - by 31 August 2006 by 31 October Annex 2: Statement of work Page 16