ORGANISATION OF EASTERN CARIBBEAN STATES
REQUEST FOR EXPRESSIONS OF INTEREST
NAME OF PROJECT
- OECS SKILLS AND INNOVATION PROJECT (SKIP)
GRANT NO.: E286
Assignment Title: Consultancy Services for an Independent Technical Assurance (ITA)
Reference No . LC-OECS COMMISSION-558060-CS-QCBS
The Organisation of Eastern Caribbean States (OECS) has received financing from the World Bank toward the cost of the OECS Skills and Innovation Project (SKIP) and intends to apply part of the proceeds to Consultancy Services for an Independent Technical Assurance (ITA).
The objectives of the consulting services ("the Services) are to provide independent, evidencebased technical validation of the existing builds (KTIP and Virtual Campus) and of the sourced EMIS DPG and its adaptation, and to provide feedback to the SDT on how to bring each platform to a regionallydeployable standard through an iterative cycle of review, recommendations, remediation, and signoff.
The OECS now invites eligible consulting firms ("Consultants") to indicate their interest in providing the Services. Interested Consultants should provide information demonstrating that they have the required qualifications and relevant experience to perform the Services. The minimum required qualifications and experience are listed in section 8.0 of the TOR below. The Qualifications and Experience of Key Experts shall not be included in the shortlisting criteria . Key Experts will not be evaluated at the shortlisting stage.
The attention of interested Consultants is drawn to Section III, paragraphs 3.14, 3.16, and 3.17 of the World Bank’s "Procurement Regulations for IPF Borrowers" September 2023 and (‘Procurement Regulations’), setting forth the World Bank’s policy on conflict of interest.
To obtain the maximum degree of comparison among Expressions of Interest (EOIs) and facilitate the evaluation process, the EOI should be a maximum of 20 pages (including annexes) with the following information included below. Any pages exceeding this limit will not be considered for evaluation or shortlisting.
Title page with name of firm submitting the EOI : should contain name of firm (or joint venture and/or a sub-consultancy, if applicable), address, email, telephone, name of contact person and date of submission.
Expression of Interest : including the firm’s general and specific experience, pool of experts etc.
Consultants may associate with other firms to enhance their qualifications, but should clearly indicate whether the association is a joint venture and/or a sub-consultancy. In the case of a joint venture, all partners shall be jointly and severally liable for the entire contract, if selected.
A Consultant will be selected in accordance with the Quality and Cost Based Selection (QCBS) method set out in the Procurement Regulations.
Further information can be obtained at the address below during office hours 08:30 a.m. - 4:30 p.m. (0830 to 1630 hours ).
Organisation of Eastern Caribbean States
OECS Skills and Innovation Projects
P.O. Box 179 Morne Fortune Castries Saint Lucia TEL: +1 758-455-6349/68
E-mail: [email protected]
An electronic copy of the Expressions of Interest must be sent by August 7, 2026, at 4:30 p.m. to:
Yasmine Anatole, Procurement Officer
At the following email address:
copied to:
The email submissions should include the Firm's name and address and shall be clearly marked in the subject line as " Expression of Interest - Consultancy Services for an Independent Technical Assurance (ITA)."
The Terms of Reference for the Submission of Expressions of Interest for this consultancy are provided below.
TERMS OF REFERENCE
CONSULTANCY SERVICES FOR AN INDEPENDENT TECHNICAL ASSURANCE (ITA) FOR THE OECS SKILLS AND INNOVATION PROJECT (SKIP)
Terms of Reference
Independent Technical Assurance (ITA)
Consultancy
Technical Assurance and Iterative Validation of the KTIP, OECS Virtual Campus, and Regionally-Interoperable Post-Secondary EMIS Architecture under the OECS Skills and Innovation Project (SKIP)
Revised draft v 6— 22 June 2026
1. Background and Project Context
The OECS Skills and Innovation Project (SKIP) is a World Bank-financed regional operation implemented by the Organisation of Eastern Caribbean States (OECS) Commission and the participating OECS Member States of Grenada and Saint Lucia. The Project’s Development Objective (PDO) is to enhance youth transversal and advanced technical skills, strengthen regional collaboration in post-secondary education, and foster collaborative innovation across the OECS Member States.
The OECS SKIP is structured around four components:
Component 1 — Fostering Regional Collaboration for Skills and Innovation in the Post
Secondary Space (implemented by the OECS Commission): supports regional public goods, including a shared strategic framework for postsecondary education, harmonised standards and assessment tools, regionally interoperable digital platforms, and mechanisms for crosscountry collaboration.
Component 2 — Strengthening Post
Secondary Institutions and Collaborative Innovation (implemented nationally by Grenada and Saint Lucia): finances institutional strengthening, Regional Enhancement Plans (REPs), programme modernisation, and collaborative innovation projects, drawing on the regional frameworks and tools developed under Component 1.
Component 3 — Project Management and Technical Assistance : supports regional and national project implementation units and technical assistance.
Component 4 — Contingent Emergency Response Component (CERC) : enables rapid reallocation of resources in the event of an eligible emergency.
Component 1 is designed to generate regional platforms, standards, and systems that benefit all nine OECS Member States and create economies of scale that individual countries cannot efficiently achieve on their own. Key activities under Component 1 include: (i) development of a regional strategic framework for postsecondary education; (ii) common learning standards and assessment tools for priority skills; (iii) harmonised standards for postsecondary faculty and institutional leadership; (iv) the OECS Virtual Campus; (v) the Knowledge, Technology and Innovation Platform (KTIP); and (vi) a regionally interoperable postsecondary Education Management Information System (EMIS) architecture.
1.1 Current state of the three Component 1 platforms
The three platforms that fall within the scope of this assignment are at materially different stages and follow materially different delivery models. The Independent Technical Assurance (ITA) Consultancy’s engagement is calibrated to those differences.
Knowledge, Technology and Innovation Platform (KTIP) — The KTIP is in advanced development by the OECS Software Development Team (SDT) and is estimated to be approximately 80% complete based on the latest project assessment. Remaining activities include completion of outstanding functionality, integration, performance optimisation, security hardening, documentation, testing, and deployment readiness activities. There is no "approval to build" milestone for KTIP. The ITA's engagement shall commence with a comprehensive baseline assessment of the existing platform, including validation of the platform's current state of completion, architecture, code quality, security posture, scalability, interoperability, operational readiness, and alignment with project objectives. The baseline assessment shall establish an independent technical benchmark against which future remediation, certification, Results-Based Financing (RBF) approvals for expenditures for a tranche of activities, and deployment decisions shall be evaluated.
OECS Virtual Campus (LearnBoard) — approximately 80% complete. The Virtual Campus is deployed and is in advanced development by the SDT for the OECS MyPD Model. The remaining work consists of feature completion, integration with EMIS and KTIP, hardening, and predeployment activities as aligned with the OECS SKIP Project Appraisal Document. As with KTIP, there is no "approval to build" milestone; the ITA’s engagement begins with a baseline audit of the existing build.
Regionally-interoperable post
secondary EMIS architecture — to be sourced as a Digital Public Good (DPG). The product will not be built from scratch under SKIP. It will be sourced as an established Digital Public Good (such as the DHIS2Ed Education Toolkit and SEMIS), with adaptation and configuration carried out by the SDT and partners to meet OECS regional requirements. There is no "approval to build" milestone for EMIS either; the ITA’s engagement begins with validation of the DPG suitability assessment and the proposed adaptation scope.
The ITA's engagement shall commence with an independent assessment of the DPG selection process, validation of the DPG suitability assessment, and review of the proposed adaptation scope. The ITA shall evaluate technical suitability, interoperability, scalability, sustainability, upgradeability, security, data governance, implementation risks, and value for money, and assess whether the proposed approach represents an efficient, sustainable, and regionally appropriate investment aligned with the objectives of the SKIP programme.
Across all three platforms, a prior technical assessment confirmed the viability of the chosen delivery approach but identified material risks related to scalability and performance at the regional level; integration across heterogeneous systems; production readiness; data governance and crosscountry compliance; and capacity constraints and longterm sustainability.
To mitigate these risks, the OECS Commission will engage a suitably qualified firm to serve as an Independent Technical Assurance Consultancy (ITA), providing independent technical assurance and certification across the lifecycle stages relevant to each platform, operating under the iterative reviewandvalidation model set out in Section 4.
Independence is a foundational requirement. The credibility of the ITA’s findings depends on a firm distinction between the ITA’s assurance role and the SDT’s development role. The ITA reviews and validates; the SDT implements. The ITA’s recommendations should specify what must be remediated and to what standard, with the implementation approach reserved for the SDT. This distinction, set out in detail in Section 4.1, Section 7, and Section 10, is foundational to the assignment and is nonnegotiable.
2. Objective and Role of the ITA
The objective of this assignment is to provide independent, evidencebased technical validation of the existing builds (KTIP and Virtual Campus) and of the sourced EMIS DPG and its adaptation, and to provide feedback to the SDT on how to bring each platform to a regionallydeployable standard through an iterative cycle of review, recommendations, remediation, and signoff.
2.1 Consolidated role description
The ITA shall act as a technical assurance and function across the full lifecycle of the three Component 1 platforms. The role comprises six discrete functions, all of which are exercised iteratively across the validation gates set out in Section 4.2:
Reviewer
: Examine existing platform builds (KTIP, Virtual Campus) and the sourced EMIS DPG and its adaptation against compliance, security, performance, interoperability, accessibility, documentation, and sustainability criteria.
Adviser to the OECS Commission
: Issue specific, actionable recommendations to the SDT through the OECS Commission, scoped at the level of what must be remediated and to what standard, with clear acceptance criteria for revalidation. The ITA shall not prescribe the implementation approach.
Validation
: Revalidate the SDT’s remediation evidence against the acceptance criteria stated in the ITA’s recommendations.
Sign
off
determination: Issue written signoff determinations at each validation gate, which form the basis for tranche progression under the ResultsBased Financing (RBF) framework applied to the SDT’s work.
Risk Reporter
: Identify risks related to integration complexity, production readiness, data governance, quality assurance, capacity, and sustainability, and escalate findings of significant severity in accordance with the Escalation Protocol (Sec. 7.5).
Assurance interface
with the World Bank: Provide credible, timely assessments to OECS Commission management and the World Bank to support informed decisionmaking, tranche approvals, and any subsequent project supervision activities.
This role description is the single, limited-scope document detailing the ITA’s functions. Subsequent sections elaborate the operational mechanics (Section 4), the phased activities (Section 5), and the institutional arrangements that support the role (Section 7).
3. Scope of Work
3.1 Platforms covered
The ITA shall provide technical assurance across the three SKIP Component 1 platforms and their integrations:
Knowledge, Technology and Innovation Platform (KTIP) — existing SDT is at approximately 80% completion;
OECS Virtual Campus / LearnBoard — existing SDT build at approximately 80% completion;
Regional postsecondary EMIS — sourced as a Digital Public Good with SDTled adaptation; and
Supporting infrastructure, cloud environments, and technical and operational documentation associated with each platform.
3.2 Differentiated assurance pathway by platform
Given the different starting positions of the three platforms, the ITA shall apply a differentiated assurance pathway, agreed in the Inception Report (D1). The pathways are articulated below; while KTIP and the Virtual Campus follow the same gate sequence, the substantive content of the review at each gate differs due to their distinct architectures and codebases.
Platform
Starting Position
ITA Pathway
KTIP
Existing SDT build, ~80% complete.
Baseline audit of existing KTIP build → Recommendations → SDT remediation → ITA revalidation & signoff → Predeployment certification → GoLive → Postdeployment review.
Virtual Campus (LearnBoard)
Existing SDT build, ~80% complete.
Baseline audit of existing Virtual Campus build against the approved Mobile Specification and target architecture → Recommendations → SDT remediation → ITA revalidation & signoff → Predeployment certification → GoLive → Postdeployment review.
Regional EMIS
To be sourced as a Digital Public Good (DPG); adaptation by SDT and partners.
DPG suitability & compliance validation → Recommendations on adaptation scope → SDT adaptation → ITA revalidation & signoff → Predeployment certification → GoLive → Postdeployment review.
The ITA’s role is to validate existing or sourced builds and to certify that successive remediation cycles have brought the three platforms to the required standard.
3.3 Integration scope- to ensure proper scope integration across the platforms, the ITA will seek to:
Review and verify APIs and data exchange layers between KTIP, Virtual Campus, and EMIS;
Verify and ensure the application of the following: LTI, OneRoster, and interoperability standards;
Review, verify and ensure Integration with institutional or national systems (SIS, LMS, etc); and
Where applicable, make recommendations to ensure integration with the upstream DPG (e.g. DHIS2Ed) ecosystem to preserve eligibility for community support and updates.
3.4 Assessment Dimensions: The ITA will undertake relevant assessments as follows:
A. Platform-Level
Review the functional completeness against approved specifications;
Assess the platform's performance against usability and identify practical, applicable opportunities for scalability;
Assess and test the platform's security and resilience;
Review and assess code quality and maintainability;
Accessibility and offlinefirst behaviour where applicable.
B. Documentation
The ITA shall assess the completeness, accuracy, and usability of technical and operational documentation associated with each platform, including:
Technical documentation: system architecture document, database migration guide, edge functions guide, README and developer onboarding documentation, API specifications.
Operational documentation: user manuals and inplatform help pages, administrator guide, deployment guide, training materials, and support runbooks.
Documentation completeness is assessed at the G2 Build Completion gate (Section 4.2), not at predeployment, so that any gaps identified can be remediated alongside other build issues.
C. DPG-Specific (EMIS only)
For the regional interoperable EMIS, the ITA shall review and assess:
Conformance with Digital Public Goods Standard criteria;
Fitness of the selected DPG (e.g. DHIS2Ed Toolkit and SEMIS) to OECS postsecondary requirements;
Adaptation scope vs upstream divergence risk;
Longterm upgrade path and community alignment.
D. Ecosystem-Level (System-of-Systems)
Cross-platform interoperability across KTIP, Virtual Campus, and EMIS;
Data consistency and synchronisation;
End-to-end workflows across platforms.
4. Technical Assurance Framework
4.1 Iterative Review
and
Validation Cycle
The ITA shall operate under an iterative reviewandvalidation cycle, applied on a per-platform basis. Each cycle consists of four steps and is the unit on which RBF approval for expenditures for the next tranche of activities proposed by the RPIU is structured:
Step 1 — Review. The ITA reviews the existing build (KTIP, Virtual Campus) or the sourced DPG and its adaptation (EMIS) against the agreed criteria for the cycle.
Step 2 — Recommendations. The ITA issues written recommendations to the SDT. Recommendations shall be scoped at the level of what must be remediated and to what standard, with clear acceptance criteria.
Step 3 — SDT implementation and testing. The SDT implements the recommendations and conducts its own internal testing. The SDT shall submit to the ITA a remediation evidence pack documenting the changes made, the testing performed, and the results obtained.
Step 4 — Re
validation and sign
off. The ITA revalidates the platform against the acceptance criteria stated in its recommendations. Where the criteria are met, the ITA issues a written signoff for the build phase, thereby triggering approval of expenditures for the corresponding RBF tranche of RPIU activities. Where criteria are not met, the cycle returns to Step 2 with revised or supplementary recommendations.
Cycles are platformspecific. KTIP, the Virtual Campus, and the EMIS may proceed through their cycles in parallel or in different sequences, as agreed in the Inception Report.
Decoupling ITA fees from SDT performance. The ITA’s entitlement to its own contractual fees is determined by the delivery of each ITA deliverable (Section 6), not by whether the SDT achieves a positive signoff in any given cycle. A Remediation Required determination represents a completed and payable piece of ITA work as much as a Validated determination does. This separation is critical to the integrity of the assignment: the ITA’s fees must not depend on the speed or quality of the SDT’s remediation, since such dependence would create a structural incentive to issue premature positive signoffs. RBF approval of expenditures for the tranche of activities is to the RPIU, on the strength of ITA signoff; the ITA itself is paid on the OECS Commission’s acceptance of its determinations and reports per Section 6.
4.2 Validation Gates
Each platform progresses through a sequence of validation gates. The gates are eventbased: a gate is triggered when the SDT submits the corresponding deliverable package, not on a fixed calendar date. A mapping of the milestones and key dates will be presented during the inception meeting. The gates and their applicability per platform are as follows:
Gate
Trigger
Deliverable from SDT
ITA Role
Outcome on Sign-off
G1 — Baseline / DPG Validation
SDT presents the current build status pack (KTIP, VC) or DPG suitability assessment and adaptation plan (EMIS) at the point of ITA engagement.
Build status pack documenting work completed to date (KTIP, VC); DPG suitability assessment and adaptation plan (EMIS).
Review and acknowledge the baseline; confirm that the scope, architecture, and DPG positioning are consistent with the SKIP requirements, as documented in the project documents; record any observations to inform subsequent gates.
Baseline of record established. Expenditures for Tranche 1 of activities proposed by the RPIU are approved.
G2 — Architecture Lock-in & Pilot Validation
SDT submits an integrated build with pilot deployment in selected institutions across lead Member States, supported by load-testing evidence and pilot monitoring data.
Integrated build with technical and operational documentation; architecture specification proposed for lock-in; security, performance and load-testing results against agreed thresholds; pilot deployment in selected institutions with monitoring data over an agreed observation window; user acceptance testing outcomes from pilot sites.
Review, recommend, re-validate. Confirm architecture is fit for regional deployment and may be locked in; verify load and performance behaviour under realistic institutional conditions; certify pilot outcomes against acceptance criteria.
Architecture locked in. Expenditures for Tranche 2 of activities proposed by the RPIU are approved.
G3 — Regional Go-Live & Post-Deployment
SDT submits the regional innovations deployment plan and proceeds with rollout across Member States.
Regional deployment evidence across the nine Member States; post-deployment monitoring data; operational handover documentation; sustainability and support arrangements.
Validate regional innovation deployment, conduct a final audit, and issue sustainability recommendations.
Regional go-live certified. Expenditures for the final tranche of activities proposed by the RPIU are approved.
Within each gate, the fourstep iterative cycle (Section 4.1) may be repeated as many times as is necessary for the platform to meet the acceptance criteria. The ITA shall not artificially compress the cycle, but recommendations and revalidations shall be issued within the timeliness windows set out in Section 4.3.
ITA mobilisation timing. Given that KTIP and the Virtual Campus are at approximately 80% completion, ITA mobilisation must take place as soon as practicable following procurement, and shall not be deferred to align with the EMIS DPG sourcing timeline. The OECS Commission RPIU shall ensure that the procurement schedule supports mobilisation in time for the first G1 baseline audit of KTIP and the Virtual Campus. Where ITA mobilisation cannot be completed in time for an applicable gate, the OECS Commission RPIU shall document the gap and either (a) defer the affected gate or (b) authorise SDT continuation under a documented risk acceptance, with ITA retrospective review at the next gate.
4.3 Decision Authority and Timeliness
At each validation point within a gate, the ITA shall issue one of the following determinations:
Validated
: The platform meets the agreed acceptance criteria for the gate. The ITA issues a written signoff, and the corresponding expenditures for the RBF tranche of activities proposed by the RPIU are approved.
Validated with Recommendations:
The platform meets the gate criteria, but the ITA has identified non
blocking recommendations to address in the next cycle. Signoff is issued, and the expenditures for the tranche of activities proposed by the RPIU are approved.
Remediation Required: The platform does not yet meet the gate criteria. The ITA issues specific recommendations with acceptance criteria; the SDT remediates and resubmits. The approval of expenditures for the tranche of activities proposed by the RPIU is deferred until revalidation is positive. The ITA’s own fee for the cycle is payable on issuance of this determination per Section 6.
Critical Issues: The ITA has identified issues of a nature or severity that require escalation under the Escalation Protocol (Sec. 7.5). Approval of expenditures for the tranche of activities proposed by the RPIU is suspended pending the RPIU and World Bank's determination of next steps.
Review turnaround. The ITA shall issue its determination within 10 working days of receipt of the complete deliverable package or remediation evidence pack from the SDT. Where the ITA requires further information, the 10workingday clock pauses upon issuance of a written information request and resumes upon receipt. The SDT shall respond to ITA information requests within 5 working days. The OECS Commission recognises that the SDT operates as a volunteer regional network, and prolonged review periods materially affect the SDT’s ability to maintain delivery momentum.
Recommendations specificity. Each recommendation issued by the ITA shall include: (i) a clear statement of the issue identified; (ii) the standard or criterion that is not met; (iii) the acceptance criteria that the SDT’s remediation must satisfy; and (iv) the evidence required from the SDT to support revalidation. The ITA shall not issue findings that are nonspecific, that prescribe a particular implementation approach, or that require openended further review.
Dispute resolution. Where the OECS Commission RPIU or the SDT documents a goodfaith technical disagreement with a Remediation Required or Critical Issues determination, the RPIU may, with World Bank concurrence, refer the matter to an independent technical panel for a binding second opinion. The panel shall comprise three subjectmatter experts who have not previously been engaged on the Project, jointly nominated by the OECS Commission and the World Bank. The cost of the panel shall be borne by the Project. This mechanism does not extend to findings issued under the Escalation Protocol (Sec. 7.5).
5. Phased Activities
5.1 Inception, Baseline Audits, and DPG Validation
On mobilisation, and applied per platform, the ITA shall:
Establish the audit framework, including benchmarks, technical risk register (with risk severity classification, mitigation actions, ownership, and escalation triggers), reporting formats, and escalation thresholds;
For KTIP, conduct a baseline audit of the existing build, covering architecture, codebase quality, security posture, performance, accessibility, documentation completeness, and operational readiness, and produce a prioritised recommendations register;
For the Virtual Campus, conduct a baseline audit of the existing build against the Mobile Specification and target architecture, on the same dimensions as KTIP, and produce a prioritised recommendations register;
For the regional EMIS, validate the DPG suitability assessment and the proposed adaptation scope, covering DPG Standard conformance, fitness to OECS postsecondary requirements, divergence risk, and upgrade path, and produce a recommendations register for the adaptation;
Review development methodology, tooling, version control practices, documentation standards, and governance arrangements applied by the SDT;
Validate threetofiveyear Total Cost of Ownership (TCO), adoption scenarios (low/medium/high), vendor lockin risks, and local capacity readiness;
Confirm scalability and interoperability assumptions;
Produce the Inception Report (D1) documenting the audit approach, platformspecific pathway, risk register, and agreed oversight schedule; and
Produce perplatform G1 Validation Reports (D2) — a Baseline Validation Report for KTIP, a Baseline Validation Report for the Virtual Campus, and a DPG & Adaptation Validation Report for the EMIS — each with a determination per Section 4.3 and an associated recommendations register where applicable.
5.2 Iterative Review and Remediation Oversight
During the buildcompletion and integration stages, the ITA shall, per platform:
Conduct iterative reviews against the recommendations issued at G1, validating SDT remediation evidence packs and issuing successive determinations per Section 4.3;
Review codebase or equivalent verification evidence, API specifications, and integration architecture;
Review technical and operational documentation completeness at G2, including system architecture documents, database migration guides, edge functions guides, API documentation, user manuals, administrator guides, and deployment guides;
Monitor timeline realism against platformspecific schedules, capacity constraints, and dependencies;
Produce Iterative Audit Reports (D3) at each cycle, documenting the review, the recommendations, the SDT response, the revalidation outcome, and the signoff determination.
5.3 Testing, Validation, and Quality Assurance
Assess functional and integration testing, performance and load testing, and security and penetration testing;
Validate defect resolution against the recommendations issued in prior cycles;
Develop the Testing and Validation Report (D4) , review testing, security, and UAT outcomes, and provide security and performance clearance.
Minimum benchmarks (to be refined at inception):
≥ 99.5% system availability;
Defined concurrent user capacity across Member States;
Acceptable API response times; and
Zero critical vulnerabilities at go-live.
5.4 Data Governance and DPI Readiness
Data ownership and classification;
Cross-country governance model;
Privacy and compliance frameworks;
Audit trails and traceability;
DPG community alignment and upstream contribution arrangements (EMIS).
5.5 Pre
Deployment Certification and Go
Live
Review deployment and rollout plans, including phased country onboarding strategies;
Conduct a production readiness assessment, covering system stability, security posture, integration completeness, and operational readiness;
Issue a perplatform Go
Live Certification (D5) : Go, Conditional Go, or NoGo.
No deployment shall proceed without ITA certification.
5.6 Post
Deployment and Scale Readiness
Monitor earlystage system performance, integration stability, and user adoption;
Review handling of postdeployment defects and change requests;
Develop Post
Deployment Reports (D6) describing the outcomes of the monitoring activities;
Validate readiness for regional scaling; and
Develop the Final Audit Report (D7) with recommendations for scaling and sustainability across all three platforms.
6. Deliverables and Payment Structure
Each substantive deliverable is delivered per platform: KTIP, OECS Virtual Campus, and Regional Post-Secondary EMIS. The payment share for D2 through D6 is split across the three platforms, so that the ITA’s entitlement under any deliverable is contingent on completion of that deliverable for each platform to which it applies. D1 (Inception) and D5 (Final Audit) are single combined deliverables across all three platforms.
The ITA is paid for delivering its own determinations and reports. The ITA is not paid contingent on the SDT achieving a Validated outcome: a properlyissued Remediation Required or Critical Issues determination is a delivered piece of ITA work and is payable on the same basis as a Validated (or Validated with Recommendations) determination. Conversely, approval of expenditures for the RBF tranche of activities proposed by the RPIU is contingent on the ITA’s Validated or Validated with Recommendations signoff for the corresponding gate.
Ref
Deliverable
Description
Per Platform Share
Total Share
D1
Inception Report and Workplan
Single combined report covering KTIP, Virtual Campus, and EMIS: audit framework, scope confirmation, per-platform pathway, pilot scope and load-testing thresholds for G2, risk register, review schedule.
—
10%
D2a
G1 Baseline Validation Report — KTIP
Baseline audit of the existing KTIP build with determination per Sec. 4.3 and recommendations register.
5%
—
D2b
G1 Baseline Validation Report — Virtual Campus
Baseline audit of the existing Virtual Campus build with determination per Sec. 4.3 and recommendations register.
5%
—
D2c
G1 DPG & Adaptation Validation Report — EMIS
Validation of the DPG suitability assessment and the proposed adaptation scope with determination and recommendations register.
5%
D2 sub-total: 15%
D3a
G2 Architecture Lock-in & Pilot Validation Report — KTIP
Per-cycle audit reports across the G2 review-and-validation cycle: architecture review, load and performance testing review, security and UAT outcomes, pilot deployment validation across selected institutions, recommendations register, SDT remediation responses, re-validation outcome, sign-off determination, and architecture lock-in certification. This triggers the approval of SDT KTIP expenditures for tranche 2 activities.
13.33%
—
D3b
G2 Architecture Lock-in & Pilot Validation Report — Virtual Campus
Per-cycle audit reports across the G2 review-and-validation cycle: architecture review, load and performance testing review, security and UAT outcomes, pilot deployment validation across selected institutions, recommendations register, SDT remediation responses, re-validation outcome, sign-off determination, and architecture lock-in certification. This triggers the approval of SDT Virtual Campus expenditures for tranche 2 activities.
13.33%
—
D3c
G2 Architecture Lock-in & Pilot Validation Report — EMIS
Per-cycle audit reports across the G2 review-and-validation cycle: architecture review, load and performance testing review, security and UAT outcomes, pilot deployment validation across selected institutions, recommendations register, SDT remediation responses, re-validation outcome, sign-off determination, and architecture lock-in certification. This triggers the approval of SDT EMIS expenditures for tranche 2 activities.
13.34%
D3 sub-total: 40%
D4a
G3 Regional Go-Live & Post-Deployment Report — KTIP
Go / Conditional Go / No-Go certification for regional rollout; post-deployment stability and adoption findings; sustainability recommendations for KTIP. This triggers the approval of SDT KTIP expenditures for the final tranche.
8.33%
—
D4b
G3 Regional Go-Live & Post-Deployment Report — Virtual Campus
Go / Conditional Go / No-Go certification for regional rollout; post-deployment stability and adoption findings; sustainability recommendations for Virtual Campus. This triggers the approval of SDT Virtual Campus expenditure for the final tranche.
8.33%
—
D4c
G3 Regional Go-Live & Post-Deployment Report — EMIS
Go / Conditional Go / No-Go certification for regional rollout; post-deployment stability and adoption findings; sustainability recommendations for EMIS. This triggers the approval of SDT EMIS expenditures for the final tranche.
8.34%
D4 sub-total: 25%
D5
Final Audit Report
Single combined report across KTIP, Virtual Campus, and EMIS: scale readiness and sustainability recommendations across the regional deployment.
—
10%
Total contract value: 100%, comprising D1 (10%) + D2 (15%) + D3 (40%) + D4 (25%) + D5 (10%). The per-platform structure ensures that the ITA's payments are tied to completion of work on each named platform, rather than to a single global completion event that could be dominated by the slowest platform.
All deliverables shall be submitted in English using both Word and PDF formats.
7. Reporting and Institutional Arrangements
7.1 Reporting Line: The ITA shall report to the OECS Commission through the reporting line confirmed by the OECS Commission prior to contract effectiveness. The reporting arrangement shall preserve the ITA’s independence from the SDT and from any other unit of the OECS Commission whose work is subject to audit. For daytoday coordination, the ITA shall liaise with the RPIU Project Manager and/or the relevant Technical Specialists. The ITA reports to the Director General or his designee, who shall be confirmed in writing by the OECS Commission prior to the issuance of the request for proposals.
7.2 Independence and Non
Interference: The ITA operates as an independent function. OECS Commission leadership commits to ensuring the ITA’s independence is protected and that no impediment is placed on the ITA’s access or on the integrity of its findings.
7.3 Constructive Engagement with the SDT: The iterative reviewandvalidation model requires the ITA to engage constructively with the SDT throughout each cycle. The ITA shall: (i) issue recommendations that are clear, specific, and actionable; (ii) make itself available for technical clarification discussions on the meaning and scope of its recommendations, without prescribing implementation; (iii) share draft determinations with the SDT before finalising, to allow opportunity to respond to or clarify factual matters; and (iv) maintain a working relationship oriented toward bringing each platform to the required standard. This constructive engagement does not affect independence; final conclusions, recommendations, and signoff determinations remain the ITA’s sole determination.
7.4 World Bank Interface: The ITA’s deliverables shall be submitted simultaneously to the OECS Commission and to the World Bank task team. The ITA may be requested to participate in project implementation support missions, midterm reviews, or technical briefings organised by the World Bank. Coordination on such requests shall be managed through the RPIU.
7.5 Escalation Protocol: If the ITA identifies a finding that poses a significant risk to the Project, including serious technical failure, system instability, security breaches or vulnerability, material deviation from approved design, data integrity breaches or risks, or misuse of project resources, the ITA shall notify the senior officer to whom it reports (Sec. 7.1) in writing within 5 working days. The OECS Commission shall acknowledge and advise on next steps within 5 working days. The SDT lead shall be notified at the same time as the senior officer to enable a timely operational response. The World Bank shall be informed within the same 5workingday window, accompanied by a brief contextual note from the OECS Commission RPIU where the RPIU determines such context is necessary for accurate interpretation of the finding. The provision of an RPIU contextual note shall not delay World Bank notification beyond 5 working days.
7.6 Access and Cooperation: OECS Commission staff and consultants, including members of the inhouse development team (i.e. SDT), are required to cooperate fully with the ITA and to provide timely access to all documentation, source code, test environments, development records, and personnel reasonably requested. As far as practicable, the OECS Commission shall invite the ITA to relevant technical meetings specific to design reviews, sprint reviews, testing sessions, and demonstrations. The ITA shall be granted readonly access to the inhouse team’s source code repositories, architecture documentation, test environments and logs, deployment pipelines, project management tools, and documentation repositories. The Project Manager in the RPIU shall respond to ITA information requests within 5 working days.
8. Qualifications and Staffing
The assignment shall be delivered by a firm. Individual consultancy arrangements are not permitted, in line with World Bank requirements for the assignment. The firm shall mobilise the key expert team set out in Section 8.2 and shall meet the firmlevel experience