2026-0081 JChat Engineering Support (NS) - WED 10 Jun

Deadline Date: Wednesday 10 June 2026 Requirement: JChat Engineering Support Location: Offsite with remote access to NCIA software factory and collaborating with NCIA team members with occasional travel to locations throughout NATO Note: Please refer to your Subcontract Agreement, article 6.4.1.a, which states “Off-Site Discount: 5% (this discount is applicable to all requirements, and applies when the assigned personnel are permitted to work Off-Site, such as at- home)". Please be sure to price this discount in your overall price proposal when submitting bids against off-site RFQs Period of Performance: From contract signature until 31 December 2026 Required Security Clearance: NATO SECRET (or higher) 1. INTRODUCTION The NATO Information and Communication Agency (NCI Agency) located in The Hague, The Netherlands, is currently involved in the development of new capabilities for NATO as well as in the support of existing capabilities. JChat has been developed by the NCI Agency to provide operators with a text-based asynchronous chat capability. Chat communication is used daily by the operators to pass information, coordinate operations, and support collaborative decision-making. JChat is providing one-to-one chat, group (multi-user) chat and multi-user conferencing (moderated chat) and is based on Instant Messaging (IM) technology. In order to support these activities, the C2 Centre is looking for a team of maximum six developers to augment the NCIA team. 2. PURPOSE The purpose of this Statement of Work is to define the scope, deliverables, pricing, and governance for the delivery of new versions of the JChat Client and server software. 3. OBJECTIVES The following objectives have been defined for this statement of work: Support the preparation of a new release of the JChat Java Client. Support the preparation of a new release of the JChat Web Client. Support the preparation of a new release of the JChat Openfire Server. Support the preparation of a new release of the M-Link server for JChat. Represent the JChat team in test events. Maintain the development pipeline. 4. SCOPE OF WORK The scope is defined in terms of business outcomes and capabilities rather than detailed functional specifications. The detailed implementation shall be refined iteratively through the Product Backlog. 4.1 Scope Flexibility The Client may substitute or reprioritize Product Backlog items at any time, provided that: the estimated effort over all work packages remains within a tolerance band of ±10% of the baseline backlog; and no change to the Firm Fixed Price is required. Such flexibility is required as there are dependencies on COTS products (M-Link) and open-source products (Openfire) with their own delivery timelines. Also, the effort on each of the work packages may be changed based on priorities from the operational community. However, it is expected that the overall effort over all work packages will remain the same. The introduction of new work packages or scope increases beyond the tolerance band of +10% shall constitute a Change Request. 5. DELIVERY APPROACH The Supplier shall deliver the Services using Agile principles consistent with Scrum, including iterative development, incremental delivery, and continuous stakeholder feedback. Minimum Agile Practices Required: Scrum approach based on a two-week development activity, including Planning meetings, Retrospective meetings, Closure meetings, Backlog refinement meetings. Continuous integration and testing. 6. WORK PACKAGES Activities under the various work packages, except WP05, will be expressed in deliverables. WP01: Participate in Scrum meetings. Estimated per developer at 2.5 hours of standup per two-week development activity, four hours of refinement per two-week development activity, four hours of review per two-week development activity, a retrospective meeting and planning meeting per two-week development activity. Estimated Work Package weight: implicit (cost considered included in overall SoW). WP02: Support the preparation of a new release of the JChat Java Client. Under this work package the contractors of the supplier will support the development of a new version of the JChat Java client software following the Scrum methodology based on a backlog of tickets maintained in JIRA by the Purchaser. All activities for the preparation of the release, e.g. development, documenting, testing and reviewing, release building will be expressed as tickets with Story Points (SP) under this work package. Estimated Work Package weight: 32%. WP03: Support the preparation of a new release of the JChat Web Client. Under this work package the contractors of the supplier will support the development of a new version of the JChat web client software following the Scrum methodology based on a backlog of tickets maintained in JIRA by the Purchaser. All activities for the preparation of the release, e.g. development, documenting, testing and reviewing, release building will be expressed as tickets with Story Points (SP) under this work package. Estimated Work Package weight: 40%. WP04: Support the preparation of a new release of the JChat Openfire Server. Under this work package the contractors of the supplier will support the development of a new version of the JChat Openfire software following the Scrum methodology based on a backlog of tickets maintained in JIRA by the Purchaser. All activities for the preparation of the release, e.g. development, documenting, testing and reviewing, release building will be expressed as tickets with Story Points (SP) under this work package. Estimated Work Package weight: 14%. WP05: Support the preparation of a new release of the M-Link server for JChat. Under this work package the contractors of the supplier will test and integrate a new version of the JChat M-Link server software following the Scrum methodology based on a backlog of tickets maintained in JIRA by the Purchaser. All activities for the preparation of the release, e.g. development, documenting, testing and reviewing, release building will be expressed as tickets with Story Points (SP) under this work package. Estimated Work Package weight: 4%. WP06: Participate in events on behalf of the JChat team. Under this work package at least one of the contractors of the supplier will represent the JChat team during the CWIX IPC event and the INTEND event. For this work package travel will be required to the location of the CWIX IPC event (location unknown at the moment) and to The Hague for the INTEND exercise. Travel cost is included in the cost of the overall SoW. Estimated Work Package weight: 0% (cost considered implicit to the SoW). WP07: Maintain the development pipeline. Under this work package the contractors of the supplier will maintain and implement changes to the development pipeline (tool chain) for the JChat products following the Scrum methodology based on a backlog of tickets maintained in JIRA by the Purchaser. Estimated Work Package weight: 10%. 7. DELIVERABLES The following deliverables are expected from this SoW: WP01 A. Daily standups: Daily update on the progress made by developers, a plan for the coming day and potential impediments. B. Refinement meetings: Discussed and refined tickets in JIRA that are Ready to start working on. C. Planning meetings: Realistic scope for the upcoming development period, based on priority of tickets in the backlog. D. Retrospective meetings: Constructive retrospective feedback, aimed at improving the cooperation in the team and at improvement of the overall development process for JChat. KPIs: Tickets have a clear description of what has to be done in the ticket. Comments are regularly added by the developer to which the ticket is assigned and during state transitions. Retrospective comments are documented and at least one comment is actioned. WP02 E. At the end of each two-week development activity, a working snapshot build of the JChat Java Client that contains the tickets implemented (designed, coded, documented, reviewed and tested) so far. F. At completion of the work package, a release candidate of the JChat Java Client that contains the results of all implemented tickets. G. At completion of the work package, a test report that demonstrates that the release candidate has been tested thoroughly and residual risk is small enough to justify the software to be released. KPIs: ≥ 80% delivery per two-week development activity. Build success rate ≥ 95%. SonarQube score A for Security, Reliability, Maintainability, Security hotspots. No critical defects in release candidate. KPI Weights – WP02 (Weight = 32%): WP Delivered 40%; Acceptance Rate 25%; Defect Density 20%; Sprint Commitment Reliability 15%. KPI Targets – WP02: Completed WP ≥ 95%; Accepted stories ≥ 98%; Critical defects 0; Sprint predictability ≥ 90%. WP03 A. At the end of each two-week development activity, a working snapshot build of the JChat Web Client that contains the tickets implemented so far. B. At completion of the work package, a release candidate of the JChat Web Client that contains the results of all implemented tickets. C. An Electron version of the web client as a standalone version of the web client. D. At completion of the work package, a test report that demonstrates that the release candidate has been tested thoroughly and residual risk is small enough to justify the software to be released. KPIs: ≥ 80% delivery per two-week development activity. Build success rate ≥ 95%. SonarQube score A for Security, Reliability, Maintainability, Security hotspots. No critical defects in release candidate. Cross-browser compatibility compliance. KPI Weights – WP03 (Weight = 40%): WP Delivered 35%; User Story Acceptance 25%; Automated Test Coverage 20%; Defect Density 20%. KPI Targets – WP03: Planned WP delivered ≥ 95%; Story acceptance ≥ 98%; Test coverage ≥ 80%; Critical defects 0. WP04 A. At the end of each two-week development activity, a working snapshot build of the JChat Openfire Server that contains the tickets implemented so far. B. At completion of the work package, a release candidate of the JChat Openfire Server that contains the results of all implemented tickets. C. At completion of the work package, a test report that demonstrates that the release candidate has been tested thoroughly and residual risk is small enough to justify the software to be released. KPIs: ≥ 80% completion per two-week development activity. Server uptime in test environment ≥ 99%. SonarQube score A for Security, Reliability, Maintainability, Security hotspots for code written by NCIA or NCIA contractors (not the open source community). No critical defects. KPI Weights – WP04 (Weight = 14%): WP Delivery 30%; Server Stability 30%; Defect Resolution 20%; Documentation Completeness 20%. KPI Targets – WP04: Planned WP completed ≥ 95%; Critical defects 0; Availability during testing ≥ 99.5%; Documentation accepted 100%. WP05 A. At the end of each two-week development activity, a working snapshot build of the JChat M-Link Server that contains the tickets implemented so far. B. At completion of the work package, a release candidate of the JChat M-Link Server that contains the results of all implemented tickets. C. At completion of the work package, a test report that demonstrates that the release candidate has been tested thoroughly and residual risk is small enough to justify the software to be released. KPIs: ≥ 80% delivery per two-week development activity. Integration success rate ≥ 95%. No critical integration defects. KPI Weights – WP05 (Weight = 4%): Integration Success 40%; Test Pass Rate 30%; Defect Resolution 20%; Documentation 10%. KPI Targets – WP05: Integration tests passed ≥ 95%; Critical defects 0; Documentation accepted 100%. WP06 A. The team has been represented in CWIX IPC by at least one person. For this event travel will be required. B. The team has been represented in INTEND exercise by at least one person. C. Reports from participation in events have been discussed with a representative of the Purchaser. KPIs: ≥ 1 qualified representative per event. ≥ 90% attendance of required sessions. Active participation (testing, demos, coordination). Report delivery within 10 working days. ≥ 3 actionable insights per event. ≥ 1 review meeting with Purchaser. WP07 A. A maintained development pipeline with up-to-date versions of tools as a result of tickets implemented for this work package. KPIs: CI/CD uptime ≥ 98%. Build success rate ≥ 95%. KPI Weights – WP07 (Weight = 10%): Pipeline Availability 30%; Automation Success Rate 30%; Change Implementation Success 20%; Documentation 20%. KPI Targets – WP07: Pipeline uptime ≥ 99%; Build success rate ≥ 95%; Failed deployments < 5%; Documentation accepted 100%. 8. PAYMENT MILESTONES The following proofs of deliverable are expected from this statement of work: The payment shall be dependent upon successful acceptance of the deliverable completion report and the Delivery Acceptance Sheet (DAS). Final payment for each deliverable shall be determined in accordance with the extent to which the defined KPIs for that deliverable have been achieved. KPI validation shall be performed by NCIA POC. The Contractor may invoice 1 or more work packages together. The invoiced amount shall be equal to the sum of the agreed total bid percentages stated in the latest agreed Work Packages Delivery Schedule. Invoices shall be accompanied with a Delivery Acceptance Sheet signed by the Contractor and the NCIA POC, or the assigned Service Delivery Manager. The work packages cannot be invoiced before their defined payment milestone. Overall Payment Distribution: Outcome-based delivery (all components) 85%; Final Acceptance 10%; Events & Reporting 5%. Payment will be done after every two completed two-week development activities. The following payment milestones exist for this SoW: 29 July: Invoicing can be done for two-week development activities 1 and 2 26 Aug: Invoicing can be done for two-week development activities 3 and 4 23 Sep: Invoicing can be done for two-week development activities 5 and 6 21 Oct: Invoicing can be done for two-week development activities 7 and 8 18 Nov: Invoicing can be done for two-week development activities 9 and 10 16 Dec: Invoicing can be done for two-week development activities 11 and 12; invoicing can be done for WP05 30 Dec: Invoicing can be done for two-week development activities 13 and 14 Final Acceptance: Invoicing can be done five days after completion of the last deliverable or after completion of two-week development activity 14 Activity Period Budget (APB): The Activity Period Budget shall be calculated as 85% of the total SoW value divided by twelve (12) activity periods. Payment for each activity period shall be based on the achievement of the agreed KPIs and acceptance criteria for the deliverables associated with that activity period. The amount payable for an activity period shall be calculated as: Payment = Activity Period Budget × Performance Score where the Performance Score is the weighted achievement of the applicable KPIs for the reporting period. The maximum payment for any activity period shall not exceed the Activity Period Budget. Activity Period Budget = (85% × SoW Value) ÷ 12 Performance Score = Σ (Deliverable Weight × KPI Achievement) Payment ≤ WP Activity Budget 9. ROLES & RESPONSIBILITIES The purchaser’s Project Manager has final authority over backlog prioritization and acceptance decisions. Governance & Measurement Rules Work Package Acceptance Work packages are counted only when tickets are accepted by Purchaser. Partially completed tickets = 0 WP credited. Reopened tickets deducted from future WP totals. Review & Approval Period review = formal acceptance checkpoint. Purchaser has 5 working days to accept/reject deliverables. Risk Controls If velocity drops below 70% (28 SP) for 2 consecutive periods without valid reason (e.g. summer leave), the Supplier will be asked for a corrective action plan, additional reporting and eventually replacement of personnel. Purchaser Responsibilities Provide timely feedback and decisions. Ensure access to the NATO Software Factory (maximum of six accounts). Provide computers for the members of the development team (maximum of six). Supplier Responsibilities Production of stated deliverables. Maintain a team of qualified people. Quality assurance. 10. CONTRACTOR QUALIFICATIONS [See Requirements] 11. SCHEDULE The work shall end not later than 31 December 2026. 12. INTELLECTUAL PROPERTY RIGHTS Intellectual Property rights of any work produced under this SoW are with NCIA. 13. PRACTICAL ARRANGEMENTS The following is a non-exhaustive list of practical arrangements for the work under this SoW: a. A computer for the work under this SoW will be provided by NCIA. b. The contractor will be required to work off site. c. Two physical meetings with the entire team will be held at the Purchaser’s premises in The Hague. All costs related to attending these meetings are for the supplier. No claims will be accepted by NCIA. d. The work will be done on the NATO Software Factory using the computer provided by NCIA. e. It is expected that no more than six software engineers of the contractor will work on this SoW. ANNEX B: REFERENCE CARD The following gives an indication of story point sizing under this SoW: 1-point story: A smallest possible change, a trivial change or a singular task. Characteristics: no logic change; no risks or unknowns; likely < 1 hour of work; no testing complexity. 2-point story: Small but not trivial; multiple tasks (testing, documenting) might be involved. Characteristics: simple backend OR frontend change; clear requirements; minimal testing; no edge cases. 3-point story: Medium, but still safe for a sprint. Characteristics: multiple steps; some business logic; requires testing across components; known solution, moderate effort. 5-point story: Bigger, more uncertainty, but still acceptable. Characteristics: multiple technical concerns; error handling required; UI + backend + storage; some uncertainty or edge cases. 8-point story: Big/complex, but possible to implement. High testing effort. Characteristics: significant logic; performance considerations; UX decisions; high testing effort; should be considered for splitting if possible. 13-point story: Big/complex; needs more clear refining but possible to refine. Characteristics: high uncertainty; multiple workflows; external integrations; most edge cases are clear; should always be split before sprint planning. 20-point story: Too big/complex; refining is more complex. Characteristics: high uncertainty; solution design is complex; edge cases remain unclear; should always be split before sprint planning. 10. CONTRACTOR QUALIFICATIONS For this consultancy, NCIA is looking for a supplier that is able to provide six experienced software developers who can be productive from the start with the maintenance of the existing JChat Java client software (based on Swing) and JChat web client software (based on Angular). The proposed developers have proven knowledge and experience with XMPP Chat Client development in Java and Angular, development of Openfire plugins and M-Link server. The proposed developers for this work each require the following qualifications (a lower level of experience in one of the criteria can be compensated by a high level of experience in another criteria; this applies for maximum of one developer and is for the Purchaser to judge): The proposed developer has a degree in informatics, computer science or a closely related engineering field. The proposed developer has a track record (at least five years) in software development using Java, including Java Swing and web development using Angular. The proposed developer is well able to produce efficient, clear, readable, maintainable and high-quality code. The proposed developer has a track record (at least five years) with development of chat related products based on XMPP, including but not limited to the implementation of XEPs, the M-LINK Server, the Openfire Server and the Openfire plugin framework, and troubleshooting XMPP communication. The proposed developer has solid experience with working with Scrum. The proposed developer has relevant and recent experience in continuous software integration and automated testing, including knowledge of test automation frameworks, using Maven, Jira, GitLab, Zephyr. The proposed developer has a flexible, cooperative and customer focussed attitude; sets high standards for quality and quantity; monitors and maintains quality and productivity; works in a systematic, methodical and orderly way. The proposed developer is able to speak and write fluent English since the work is conducted in English. The proposed developer has the nationality of one of the NATO nations. Must hold a valid NATO SECRET (or higher) Security Clearance as from the start date of the contract.