Expression of Interest (EOI) – Development of the National Minerals Database

Expression of Interest (EOI)

Development of the national minerals database.

Reference Number:83472480

Publication date: 02.09.2024

Introduction

The Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH is a federally owned international cooperation enterprise for sustainable development with worldwide operations. The GIZ Office in Kigali covers GIZ’s portfolio in Rwanda and Burundi. GIZ Rwanda/Burundi implements projects on behalf of the German Federal Ministry for Economic Cooperation and Development, the European Union and other commissioning authorities in the following priority areas: Sustainable Economic Development; Good Governance; Climate, Energy and Sustainable Urban Development; Digitalization and Digital Economy; and regional projects in the Great Lakes Region.

2 Context

2.1 The company

As a service provider of international cooperation for sustainable development and international education, the Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH is committed to a future worth living for all people worldwide. With more than 50 years of experience in a wide range of fields, from economic and employment promotion to energy and environmental issues to the promotion of peace and security, GIZ applies its expertise as a federal enterprise in around 120 countries with various clients – from the German Federal Government, institutions of the European Union, the United Nations, the private sector, and governments of other countries. GIZ cooperates with companies, civil society actors and scientific institutions. In this way, it contributes to the successful interaction of development policy and other fields of policy and action. The main client of GIZ, which is based in Eschborn, Berlin and Bonn, is the German Federal Ministry for Economic Cooperation and Development (BMZ).

Gender equality is one of the key values of our company and of the work we do. It is a prerequisite for and driver of sustainable development and a viable future of society. That is why we take a gender-sensitive and wherever needed a gender-differentiated approach within all our programs. GIZ fosters equal rights and opportunities for everyone, regardless of their gender, sexual orientation, and gender identity.

2.2 Project background

The Manual for the Regional Certification Mechanism (RCM) outlines the minimum requirements and essential processes for implementing the RCM, part of the Regional Initiative against the Illegal Exploitation of Natural Resources (RINR) in the International Conference on the Great Lakes Region (ICGLR). It aims to establish responsible mineral supply chains for the four Designated Minerals (“3TG” – Tin, Tantalum, Tungsten, and Gold), involving intermediaries like mines, traders, transporters, processors, and exporters.

The RDS project modernizes and standardizes the data sharing for relevant data according to the RCM and reporting of mineral supply chains at national and regional levels, enhancing visibility, efficiency, and reliability. Its goal is to create a secure data-sharing platform for ICGLR members, improving the region’s reputation among international mineral buyers, especially those concerned with Conflict-Affected and High-Risk Areas (CAHRAs). The project aims to establish a collaborative, efficient, and transparent regional mineral trade ecosystem using digital traceability and secure data-sharing technologies.

2.3 GovStack approach

The adoption of GovStack plays an important role during the implementation of this initiative. It builds capacities throughout the digitization of Government services – on the governmental as well as non-governmental side and focuses on:

• Awareness building: across public and private stakeholders by trainings, participation on conferences, workshops, especially with:

  • Local private implementation partners

  • Government clients

  • Government institutions

• Capacity Building: enabling civil servants to understand and use the GovStack approach for improved service implementation

• Operationalize the adoption of the GovStack approach by establishment of implementation capacity.

• Technical support: support of ministries to adopt the GovStack approach by using four building blocks and supporting in the implementation of use cases to create evidence for the rapid adoption rate.

Utilizing the approach described, Govstack adheres to seven core principles during the stages of design, development, and roll-out.

2.3.1 User-Focused

Creating the most effective tools starts with empathetic engagement, comprehending, and crafting solutions that cater to the needs of the end-users. A user-focused technological solution will exhibit characteristics such as:

• User-centric design methodologies.
• Ensuring users have the “Right to be forgotten” by allowing data erasure.

2.3.2 Openness:

Govstack champions the use of open technologies, which can help in lowering costs and preventing dependency on specific vendors. Open technology is characterized by:

• Adherence to open standards.

• Alignment with Digital Development and Digital Investment Principles (available at https://digitalprinciples.org/ and https://digitalinvestmentprinciples.org/ ).

• Preference for open-source software whenever feasible.

• Encouragement of open development practices (see https://standard.publiccode.net/).

• Adoption of cloud-native technologies like Docker/Docker Compose/OCI containers where possible.

2.3.3 Sustainability:

Applications should be built sustainably, guaranteeing they continue to receive updates and maintenance. A key aspect of sustainability includes:

• Favoring a microservices architecture over a monolithic approach to enhance interoperability, development speed, deployment speed, and system reliability.

2.3.4 Security:

In deploying any technology, ensuring its security is crucial, with the following security features:

• Development methodologies and standards that emphasize quality and security.

• Various certification levels to indicate compliance with standards.

• Routine security scans and audits.

• Openness to public ratings and reviews.

• Detailed logging and error management.

2.3.5 Accessibility:

Ensuring technology solutions are accessible to everyone is critical. Accessible design features include:

• Availability across multiple platforms: web, mobile, SMS, and/or voice interfaces, with support for assistive technologies like screen readers.

• Single Sign-On (SSO) capabilities for accessing multiple services with one login.

• Open development and deployment methodologies welcoming contributions.

• Community-led development of tools for documentation and support.

• Availability of blueprints, templates, and documentation.

2.3.6 Flexibility:

In embracing the notion that Building Blocks should be adaptable and reusable, supporting various applications with minimal adjustments, Govstack focuses on:

• The reuse of Building Blocks in different scenarios.

• Autonomy of each Building Block.

• Interoperability among Building Blocks through adherence to common standards.

• Ease of setup for Building Blocks.

• Utilization of standardized protocols for configuration and communication among Building Blocks.

• Offering Building Blocks as a service to foster ICT development.

2.3.7 Robustness:

In the implementation of Building Blocks, the following principles should be upheld:

• Operability in environments with limited resources, such as intermittent power, low bandwidth, or unreliable connectivity.

• Scalability to ensure high availability and reliability.

• Use of API-only based approaches for decoupling.

• Preference for asynchronous communication patterns decoupled through brokers to optimize interactions.

• Adoption of eventual consistency models for data management.

For comprehensive specifications and more detailed information about Govstack, please refer to the following link: https://govstack.gitbook.io/specification/

2.4 Context within the ICGLR

The ICGLR (International Conference for the Great Lakes Region), established in 2006, is an intergovernmental organization aimed at promoting peace, security, and development in the Great Lakes region.

The ICGLR Regional Certification Mechanism specifically focuses on the responsible sourcing of minerals, particularly tin, tantalum, tungsten, and gold (3TG). These minerals are commonly referred to as conflict minerals, as their extraction has been linked to funding armed conflicts in the region. The certification mechanism is designed to ensure that minerals from the Great Lakes region are sourced and traded responsibly, without contributing to conflict or human rights abuses.

Key components of the ICGLR Regional Certification Mechanism include:

1. Certification Process: The mechanism involves a certification process that includes traceability and due diligence to verify that minerals are sourced responsibly. This is intended to prevent the trade of conflict minerals.

2. Cooperation and Collaboration: The ICGLR mechanism encourages collaboration among governments, the private sector, and civil society to address the challenges associated with responsible sourcing of minerals.

3. Capacity Building: Efforts are made to enhance the capacity of local governments, mining communities, and industry stakeholders to implement and comply with responsible sourcing practices.

4. Monitoring and Reporting: The mechanism includes monitoring and reporting mechanisms to track progress and address any issues that may arise in the implementation of responsible mining practices.

The ICGLR has published in 2019 the Manual of the Regional Certification Mechanism of the ICGLR to describe the minimum Requirements of the International Conference of the Great Lakes Region (ICGLR) Regional Certification Mechanism (RCM: annex 3) and how they shall be implemented in Member States. It includes specificly requirements to track and share the data related to the chain of custody of minerals.

Core components for the future tracking and data sharing mechanisms and target architecture will be:

• National CoC tracking Solutions

• Database Connectors to connect national CoC Solutions with the data sharing Solution

• Data Sharing Solution

• National Minerals Databases with full sovereignity of data within the member states

• Regional Minerals Database

Duration for this contract starts 1^st October 2024 to May 30^th 2025.

2.5 Objective of the commission/subject of the procurement

Mineral traceability came into force at the beginning 2012 when the US Securities and Exchange Commission (SEC) approved a law mandated by Dodd-Frank Wall Street Reform and Consumer Protection Act requiring companies to publicly disclose source of minerals that originated in DR Congo or an adjoining country. It requires companies to disclose whether the sourcing of minerals in their products benefited armed groups.

The subject of this procurement is the design/architecting and development/configurations and implementations of the following component of the target architecture.

• National Minerals Database

In addition the contractor shall provide change management and capacity development activities complimenting an agile delivery approach, to ensure the smooth operation of the software by ICGLR / respective future operators.

3 Requirements for the IT solution

3.1 General conditions and Architecture vision

GIZ and the ICGLR developed an architectural vision for the idea of an overarching mineral traceability Solution including all necessary components. This architectural vision will be the basis for all measures within the framework of the development of the service tendered in this contract.

The architecture vision for the implementation of the epics of this tender follows the outline described in Annex 1: Architecture Vision Minerals Flow Data Vault. It provides the foundation for all components to be implemented under this tender.

3.2 Challenges to be tackled by the IT Solution

The Solution aims to tackle several challenges within the mineral supply chain. These challenges include, but are not limited to, the following:

3.2.1 Data Collection and Accuracy

• Complex Supply Chains: Mineral supply chains are often long and complex, involving multiple intermediaries from the mine to the end product.

• Data Integrity: Ensuring that the data collected at each stage is accurate, consistent, and tamper-proof is difficult.

• Standardization: Lack of standardized data formats and protocols can hinder the seamless integration of data across different systems and stakeholders.

3.2.2 Technology Integration

• Interoperability: Different players in the supply chain may use varied IT systems, making it challenging to integrate and share data.

• Legacy Systems: Older systems may not support modern traceability Solutions, requiring significant upgrades or replacements.

3.2.3 Verification and Compliance

• Regulatory Requirements: Keeping up with varying regulations across different countries and regions adds complexity.

• Certification Processes: Ensuring that certifications and audits are carried out effectively and that the results are properly integrated into the traceability system.

3.2.4 Security and Privacy

• Data Security: Protecting sensitive data from breaches and cyber-attacks is paramount.

• Privacy Concerns: Balancing the need for transparency with the protection of proprietary or sensitive information.

3.2.5 Cost and Investment

• Initial Setup Costs: Implementing comprehensive traceability systems can be expensive.

• Ongoing Maintenance: Regular updates, maintenance, and IT audits require continuous investment.

3.2.6 Stakeholder Collaboration

• Coordination: Ensuring cooperation and communication between diverse stakeholders, including miners, manufacturers, regulators, and customers.

• Training and Awareness: Educating all stakeholders about the importance and use of traceability systems.

3.2.7 Scalability and Flexibility

• Scalability: Developing Solutions that can scale with the growth of the business and increasing supply chain complexity.

• Adaptability: Ensuring the system can adapt to changes in regulations, market conditions, and technological advancements.

3.2.8 Blockchain and Emerging Technologies

• Implementation Challenges: While blockchain offers a promising Solution for traceability, its implementation can be complex and resource-intensive.

• Adoption Rates: Ensuring widespread adoption among all stakeholders can be slow and challenging.

3.2.9 Environmental and Social Governance (ESG)

• Sustainability Metrics: Incorporating and verifying sustainability metrics into the traceability systems to meet ESG goals.

• Ethical Sourcing: Ensuring that minerals are sourced ethically and without human rights abuses.

3.2.10 Transparency and Consumer Trust

• Building Trust: Convincing consumers and stakeholders of the reliability and transparency of the traceability system.

• Visibility: Providing sufficient visibility into the supply chain without compromising competitive advantages.

Addressing the challenges identified requires an IT Solution that meticulously adheres to the Govstack principles, incorporating both functional and non-functional requirements with a user-centric approach. This Solution must cater to a diverse array of stakeholders within ICGLR Member states’ traceability ecosystem, ensuring their unique needs and roles are effectively supported:

• Miners: Employees working directly within mining sites.
• Mining Operators: Owners or licensed associations/companies engaged in mining activities.
• Local Mineral Processors: Licensed entities undertaking mineral processing operations.
• Local Mineral Smelters: Entities licensed for smelting activities within ICGLR Member states.
• Local Manufacturers: Companies using minerals as raw materials for manufacturing, based in ICGLR Member states.
• Local Mineral Exporters: Licensed businesses involved in the export or trading of minerals.
• International Mineral Processors: Overseas entities licensed for mineral processing.
• International Mineral Smelters: Companies based abroad, licensed for smelting activities.
• International Manufacturers: Overseas companies using minerals as manufacturing raw materials.
• Mineral Transporters: Licensed companies, associations, or individuals responsible for the transportation of minerals.
• Government Officials: Key state actors overseeing the mining sector.
• Customs Officials: Authorities involved in the regulation of mineral exports and imports.
• Civil Society Officials: Representatives from NGOs and advocacy groups monitoring the mining sector.
• Due Diligence Entities: Companies, associations, or individuals specializing in verifying compliance within the supply chain.
• Financial Institutions: Banks and other financial entities facilitating transactions within the mining sector.

The Solution will be designed and implemented leveraging insights from industry experts who possess a deep understanding of the domain. This collaborative process will ensure that all necessary transactions between the actors in the mineral supply chain are meticulously defined, paving the way for a transparent, efficient, and ethical mining ecosystem.

3.3 General Requirements

3.3.1 Onboarding, architecture validation, testing and QA approach.

The Contractor will be onboarded by ICGLR and GIZ, to understand the context, goals, approach, and results of the analysis done already. This will happen in several workshops, possibly with the involvement of example users. At the start of the project, the contractor, GIZ and a representative of ICGLR will clarify the expectations for the cooperation arrangement, the technical platform for cooperation, the relevant responsibilities, and the project schedule. The first meeting also allows substantive questions to be clarified regarding the issues, objectives to be defined, requirements to be established and other contextual information to be presented. All parties will set up the necessary recurring meetings for planning events. In these workshops the vision for the project, a high-level product roadmap and corresponding assumptions dependencies etc. will be shared.

Also, the overall target architecture and resulting technical decision, especially regarding possible dependencies will be shared by the contractor in cooperation with ICGLR and GIZ. The Contractor is expected to lead these efforts and bring deep technical expertise, an independent outside view, and a focus on maintainable and sustainable operation.

The detailed testing approach for the user stories will be defined.

1. Report assessing target architecture, including proposed changes (pros, cons, etc)

2. Agreed upon final target architecture.

• Shared understanding and formalized product roadmap and vision

1. Formalized and agreed upon testing approach.

2. Well-groomed backlog with enough content for first sprints (items for sprint 2 can be detailed out in sprint 1, as they would normally).

3.3.2 Development Environment

The Contractor will set up at least the following three environments:

1. Development environment on their own IT infrastructure

2. Testing, integration, and staging environment on the ICGLR IT infrastructure.

• Production environment on the ICGLR IT infrastructure.

The contractor ensures that at least on the stage of the testing and integration environment installations are done through automated deployments where applicable including a set of automated tests that ensure at least that no broken build is deployed into the stage. The Contractor will help in automatic test data generation, if necessary, always following the guidance of ICGLR where applicable.

The Contractor will define and set up respective deployment and integration processes taking into consideration ICGLR processes. The deployment pipeline as well as environments need to be transferred or replicated to the ICGLR at the end of the project. The above environments shall have the same set up and configuration.

The implementation concept is drafted together with the contractor and other relevant stakeholders, and includes:

• Development methodology, schedule, and release plan

• Revised and prioritized functional requirements

• (Provisional) system architecture

• Depending on the methodology: description of the areas of application and system specifications or backlog, for instance with user stories

• Visualizations and outlines (e.g., mock-ups, user journeys, process outlines, ER and use case diagram)

• A documented “Definition of Done”

• A documented definition of production readiness

• Implementation concept

• Fully set up system environments

• Documentation about all environments

3.3.3 Code, Test, Deployment and Hand over

Testing requirements encompass a range of activities designed to validate that the system functions correctly and meets specified requirements. This includes unit testing, where individual components are tested for correct operation; integration testing, which ensures that combined components work together as intended; system testing, which validates the complete and integrated software system; and user acceptance testing (UAT), where actual users verify that the system meets their needs and is ready for production. Additionally, performance testing assesses the system’s responsiveness and stability under load, while security testing identifies potential vulnerabilities. System resilience testing as well as fault tolerance testing are further necessary tests. Comprehensive documentation of test plans, cases, and results is essential to provide a clear audit trail and support future maintenance and troubleshooting efforts.

Deployment requirements involve the processes and procedures necessary to move the tested system into the production environment. This includes creating deployment plans that outline the steps for installation, configuration, and integration of the system. Automation tools are often utilized to streamline deployment processes and reduce the risk of human error. Pre-deployment testing in a staging environment that closely mirrors the production environment is critical to identify any last-minute issues. Rollback procedures should be clearly defined to allow for the system to revert to its previous state in case of deployment failures. Post-deployment, monitoring tools should be in place to ensure the system is functioning as expected and to quickly identify any issues.

Handover requirements involve transferring the ownership of the project from the development team to the operations or maintenance team, ensuring a smooth transition. This process typically includes the delivery of all relevant documentation, such as user manuals, system architecture designs, and maintenance procedures. Adequate training for the end-users and support staff is also critical to ensure they can effectively use and maintain the system. Additionally, the handover phase should include the establishment of a support framework, detailing how issues will be managed post-deployment, including escalation procedures and support contact details. The final acceptance sign-off from the client or end-users signifies that the system meets all agreed-upon requirements and is ready for operational use, marking the official conclusion of the project development phase.

3.3.4 Documentation

The contractor must provide detailed documentation of the functionalities and the source code annotation in good time and an appropriate manner. The contractor is obligated to make the latest documentation available for inspection at any time.

Work results to be provided by the contractor:

Documentation preferably based on a conventional standard (e.g., arc42 – arc42 is an example of a documentation standard)

1. The documentation must include the following items in particular:

   1. Software stack and dependencies

   2. System requirements, system specifications and system architecture

   3. Diagrams and outlines (e.g., use case, ERD, process outlines, mock-ups)

   4. Other technical documentation (e.g., interfaces, (clearance of) faults)

Continuously provide technical documentations which will facilitate the ICGLR technical in operating and using it successfully on various phases of Solution implementation including the deployment, system administration and databases

Continuously provide user manuals which will facilitate the users in operating and using it successfully in various phases of the implementation.

2. Provide frequent technical knowledge sharing with the ICGLR technical team in various technical meetings during the implementation of the Solution.

3.3.5 Continuous user support and operation

While the Contractor will not be tasked with operating the IT Solution, the contractor will be in close contact with the ICGLR support and operations team, which will in turn be assisted by the consultant assisting ICGLR.

The following duties do not involve access to live systems and do not entail any tasks that could be interpreted as data processing of personally identifiable production data.

3.3.5.1 User-Support

The Contractor shall help resolve 2^nd and 3^rd level requests, where needed. Over time, the Contractor’s involvement should decrease, with ICGLR having the tools, resources, and knowledge in place to run this support without the Contractor involvement, at the end of the contract. Until that point, Contractor personal can also be asked to be part of incident response teams.

• 2nd Level Support: Classify and systematically process requests from 1st level support, contact users directly by phone or in writing, maintain a knowledge base on common problems or incidents, and forward/ re-classify unsolvable issues to 3rd level support.

• 3rd Level Support: Processing of inquiries regarding IT-administrative or operational errors or malfunctions, high specialization on respective software and hardware, no direct contact with end users

3.3.5.2 Operations

The Contractor will advise on the organizational and technical operation of the platform.

The Contractor will work together hand in hand with the ICGLR Technical Team on the operation of the platform.

This includes define processes and roles, as well as giving guidance on improving the technical set up (e.g., deployment pipelines, code repositories etc.) – this shall be done in sync with the respective capacity management.

3.4 Functional requirements and Epics

Epics describe aggregated overarching functionality which consists of features and user stories.

3.4.1 Epic 1: System Architecture Definition and Validation

3.4.1.1 Covered components

• National Minerals Database

  • Web Interface

  • Backend

3.4.1.2 Scope and Business Background

This epic encompasses a comprehensive study of the existing processes and defining the architectural framework for the system, creating low-fidelity prototypes and conducting experiments(A/B tests) to validate the proposed solutions. The proposed systems architecture, prototypes should meet the project requirements, objectives and get the stakeholder buy-in.

The scope of this epic covers the following objectives:

• Define the high-level architectural components, including infrastructure,user types, data flows, integrations points, and system interactions, to establish a solid foundation for development.

• Using design thinking approach, develop different low-fidelity interface designs (sketches, wireframes, mockups) to explore different architectures approaches and gather early feedback from all relevant stakeholders/users in the chain of custody. The prototypes should cover every level of data collection including tagging, approving, transporting and validating package information, considering every needed verification by different user types.

• Plan and execute experiments for the proposed interfaces aiming to assess their effectiveness and user preferences across all user types.

• Define and propose the technologies, frameworks and platforms to be utilized to meet the project requirements and get stakeholder buy-in.

• Compile all findings, including architectural decisions, A/B test results, and user feedback and any, into a comprehensive Product Requirements Document (PRD).

3.4.2 Epic 2: Implementation of the UI and Backend for the Digital Registry for the National Minerals Database

3.4.2.1 Covered components

• Natonal Minerals Database

  • Backend

  • Frontend

3.4.2.2 Scope and Business Background

This epic focuses on the implementation of the Digital Registry for the National Minerals Database following the digital registry building block specifications of Govstack found in Annex 2. The database should be designed to efficiently store and manage all entities and their attributes for minerals data, ensuring that each mineral data record is uniquely identifiable with the ability to create entities which are easily accessible within the system.

The scope of this epic covers the following activities

3.4.2.2.1 Front-end development

• Design intuitive and user-friendly interfaces for accessing the Digital registry, interactive dashboards, visualizations and easy navigations and experience across different devices and screen sizes.

3.4.2.2.2 Backend development

• Build the backend infrastructure to support the data storage, retrieval, processing and management for the Digital Registry within the National Minerals Database

3.4.2.2.3 Data management

• Create and implement standards for adding, updating and deleting data within the national minerals database. It will de used for the management of data such as the license managements, export certicates and minesite inspections.

3.4.2.2.4 Search and Filter functionality

• Develop search and flter features to enable users to query and retrieve specific information in the digital registry of the national minerals database based on criterias such as commodity type, export certificate, and more.

3.4.3 Epic 3: Data Management for license management

3.4.3.1 Covered components

• National Minerals Database

  • Web interface

  • Backend

3.4.3.2 Scope and Business Background

The License Management Epic focuses on enhancing the National Minerals Database to facilitate the application, approval, issuance, and management of mining licenses for companies. This epic aims to streamline the license application process, provide the ability to print licenses, generate QR codes for license verification, and efficiently manage the lifecycle of licenses within the system.

The scope of this epic covers the following activities

3.4.3.2.1 License application system

• Develop of the interface for companies to submit license applications through the national minerals database. This includes forms available to the companies for addition of required information.

3.4.3.2.2 License approval workflow

• Design workflows for the review and approval of license applications by regulatory authorities.

• Implement tracking workflow to monitor the progress of applications, assign review tasks, and streamline approval processes.

3.4.3.2.3 License insuance and printing

• Enable approved licenses to be issued within the database, allowing companies to download and print official license documents

• Develop templates for license certificates that can be customized with company specific details and regulatory information

3.4.3.2.4 QR Code generation for licenses verifications

• Implement a QR code generation feature for each issued license to allow convenient verification and validation of licenses

3.4.3.2.5 License management dashboard

• Create a centralized dashboard for monitoring and managing all issued licenses, displaying key information such as license status, validity, expiration dates, and compliance updates.

• Include search and filtering functionalities for efficient license tracking, renewal reminders, and reporting on license usage.

3.4.4 Epic 4: Data management for export certificates

3.4.4.1 Covered components

• National Minerals Database

  • Web Interface

  • Backend

3.4.4.2 Scope and Business Background

The Export Certificates Management Epic aims to streamline the process of applying for, issuing, managing, and verifying mineral export certificates within the National Minerals Database. This epic encompasses the online application submission, processing of export certificate requests, issuance and printing of export certificates.

The scope of this epic covers the following activities:

3.4.4.2.1 Export certification application

• Develop an interface for companies to apply for export certificates within the national minerals database. This includes forms available to the companies for addition of required information.

3.4.4.2.2 Certificate approval workflow

• Design workflows for the review and process export certificate applicates submitted trough the database.

• Implement tracking workflow to monitor the progress of applications, assign review tasks, and streamline approval processes.

3.4.4.2.3 Certificate issuance process

• Enable the issuance of approved export certificates directly from the database with unique identifiers and secure digital signatures.

• Generate printable versions of export certificates for companies to download and use for exporting mineral products.

3.4.5 Epic 5: Data management for minesite inspections

3.4.5.1 Covered components

• National Minerals Database

  • Web interface

  • Backend

3.4.5.2 Scope and Business Background

The Minesite Inspection Management Epic focuses on enhancing the National Minerals Database to facilitate the tracking, addition, and management of minesite inspections. This epic aims to streamline the process of conducting inspections, recording inspection findings, managing inspection data, and ensuring compliance with safety, environmental, and operational standards at mining sites.

The scope of this epic covers the following activities:

3.4.5.2.1 Inspection data collection

• Create user-friendly interfaces for inspectors to record inspection findings, observations, compliance status, and corrective actions during site visits.

• Include standardized inspection fields, checklist items, and photo upload features for documenting minesite conditions accurately.

3.4.5.2.2 Inspection tracking and reporting

• Establish a compliance tracking system to monitor and report on adherence to safety regulations, environmental guidelines, and operational standards based on inspection results.

• Generate compliance reports, trend analyses, and performance metrics to assess minesite compliance levels and identify areas for improvement.

3.4.6 Epic 6: User management

3.4.6.1 Covered components

• National Minerals Database

  • Web Interface

  • Backend

3.4.6.2 Scope and Business Background

This epic focuses on implementing the user role management for the regional minerals database where specific roles will have access to the data. This involves creating roles-based access controls to control user permissions, access levels, and capabilities.

The scope of this epic covers the following activities:

3.4.6.2.1 Identification, documentation validation of user roles and access levels

• Identification of roles and access levels: Conduct stakeholder workshops with the member states to identify all necessary roles and corresponding required access levels.

• Documentation of roles and access levels: Documenting all identified roles and access levels. This documentation will be presented to ICGLR for further validation with member states.

• Alignment and Approval with Member States: Seek alignment with the member states on the proposed user roles and access levels through presentations and discussions. Obtain formal approval from member states for the finalized roles and access levels.

3.4.6.2.2 Backend implementation

• Database schema design: Define the structure of the database to store information about user roles, permissions, and access control lists efficiently.

• API Endpoints: create endpoints to manage users, assign roles, permissions and access control lists efficiently.

• Business Logic for Access Control: Develop rules and logic to enforce role-based access control within the regional minerals database, determining what data each user role can interact with.

3.4.3 Epic 7: Integrations with the data sharing solution

3.4.3.1 Covered components

• National Minerals Database

  • Web interface

  • Backend

3.4.3.2 Scope and Business Background

This Epic should focuses on the integrations with the data sharing solution for the national minerals database to share information with the data sharing solution following the approval of the member states using the national minerals database.

The scope of this epic covers the following activities:

3.4.3.2.1 Integration architecture

• Improve the integration architecture from Epic 1 to outline the communication protocols, data mapping strategies, synchronization and authentication mechanism for data exchange.

• Specify APIs, endpoints, and data transfer protocols to facilitate the exchange of data between the national minerals database and data sharing solution.

3.4.3.2.2 Development and integration

• Develop the necessary API endpoints, data transformation scripts, middleware components, and data mapping logic to enable data sharing between the systems.

3.4.4 Epic 8: Knowledge Transfer

3.4.4.1 Covered components

• National Minerals Database

  • Web Interface

  • Backend

3.4.4.2 Scope and Business Background

The Contractor shall conduct technical trainings of the IT staff of ICGLR to build up the knowledge and capacities for sustainable operation.

Training will be formalized and well documented for major releases or when necessary due to new functionality etc. User trainings (except for admins) will not be part of the Contractor’s tasks.

Capacity development will be continuous and entail three main blocks:

• concrete tasks necessary to operate the platform via frequent exchange, alignment, and demonstrations.

• best practices and principles in managing a digital product / service and steering the respective implementation and delivery via workshops based on expressed needs and current capacities.

• guidance in setting up and implementing the necessary information security best practices via workshops and formal trainings sessions based on existing processes.

Respective activities shall be oriented towards the target group and be documented. Materials to be used here, shall be made available to ICGLR. The use of publicly available resources is encouraged. Concerning the knowledge transfer, the following services must be provided by the contractor to the concerned ICGLR staff through workshops and trainings on:

• Providing required technical knowledge and skills on the programming languages used in the development;

• Providing required technical knowledge and skills on databases;

• Providing required technical knowledge and skills on Solution API and integration with all required systems;

• Providing required technical knowledge and skills on the deployment and/or installation of the solution

• Providing required technical knowledge and skills on the solution management and/or administration;

• Providing required knowledge and skills on usage of the solution to the selected users.

3.5 Non-functional requirements

The following non-functional requirements must be considered by the contractor when implementing the service.The minimum baseline are as follows

• Portability:

• SOLUTION shall always be able to run on both Linux and/or windows platforms.

• SOLUTION should run on latest Windows and MacOS systems with similar UI experience.

• Security:

  • The implemented single-sign-on feature/module for SOLUTION external will continue to be considered in further development of the system to allow users to log in and be redirected seamlessly to any other applications provided in the future by ICGLR.

  • Develop SOLUTION with all the standard security such as Owasp 10 web application standards security which can be in-built features to ensure confidentiality, integrity, and availability of data.

  • Ensuring that SOLUTION have user access roles through which ICGLR technical team especially with administrator’s rights can assign or revoke rights of a specific user to a function, data, element, action, or activity.

  • implement measures to protect collected data from unauthorized access, manipulation, or disclosure. This includes encryption of data during transmission and storage, user authentication mechanisms, and adherence to relevant data privacy regulations such as the ICGLR data policy and the ICGLR Member states data protection and privacy law

• Maintainability: SOLUTION will easily be updated, modified, or maintained over its lifecycle. It should easily be adapted to changing requirements with minimal effort, reducing downtime and costs associated with updates and enhancements.

• Reliability: The SOLUTION system should consistently and accurately perform it’s intended functions without failures or errors. A monitoring system should be put in place to track errors in real time.

• Scalability: SOLUTION system should handle the increase in requests without significant loss of performance.

• Performance: SOLUTION system should have a fast response time that enables the user to complete tasks quickly.

• Reusability: SOLUTION developed modules should easily be reused in different part of the SOLUTION system or future modules.

• Flexibility: SOLUTION is developed with the mind of REST/JSON or any other API-based approach to enable future integration of SOLUTION with other systems

• Compatibility:

• SOLUTION Web Applications (front and backend) shall be cross-browser compatible and cover at least the following browses:

  • Chrome (>version 55.0)

  • Firefox (> version 50.1)

  • Edge Chromium (> version 2020)

  • Safari (> version 16.6)

• SOLUTION Mobile Application (to be developed) shall run on many versions of the mobile operating systems.

• Offline Data Collection: Provide functionality for data collectors to capture data even in offline or low-connectivity with mechanism to synchronize data with the national minerals databases once connectivity is restored.

3.6 Use of open-source software (OSS)

The SOLUTION, as a measure commissioned by ICGLR, must be available to the public free of charge. The following principles must be followed:

• Digital solutions must be built in such a way as to ensure handover to the partner organisation

• Solutions must lead to the strengthening of local economic power and digital resources

• The solution sets global technical standards; positioning ICGLR as an “early adopter” in the field of digital solutions

• Increasing efficiency through collaborative innovation processes

• Solutions have to be build to enable benefiting from international cooperation and alliances.

• Solutions shall be in compliance with the “Principles for Digital Development”

• Solutions shall be in compliance with the BMZ strategy “Digitalisation for Development”

The concept and infrastructure must therefore also be structured in such a way that they can be freely handed over to ICGLR and that ICGLR can also control support, operation and further development independently. This shall be achieved if the contractor only uses freely available open source components for the development of the application and makes it possible to hand over the infrastructure as an open source-licensed product.

3.7 Hosting

The contractor is responsible for furnishing a dedicated development environment to facilitate all development and testing activities. ICGLR will, in turn, supply staging and production environments to accommodate all deployment needs.

3.8 Further specifications/general conditions

Not applicable.

3.9 Other Requirements

The contractor’s staffing profile should be balanced in terms of gender and age. GIZ supports the empowerment for people with disabilities. It would be beneficial if the supplier can include this into the personal concept.

4 Responsibilities of the contractor

The contractor must deliver the following services and work packages (along with the corresponding milestones). The work packages have no chronological order and can also be implemented on an integrated basis, depending on the development methodology.

4.1 Use of Agile Methodology

This project will be developed, delivered, and sustained in a consulting contract. The target is to go along agile methodology elements using a framework orientating on the agile frameworks. The proposed methodology seems to be appropriate because:

• general scope is pre-defined, but the periodization of requirements is not stable over the whole development process.

• learning about user behaviour and preference should be incorporated quickly into the product design.

• incremental development with integrated testing limits risks associated with large IT implementations and allows to achieve value-add quickly.

• it is a well-known and well described practice framework.

As this is a new way of working for ICGLR, the Contractor, together with the GIZ project are expected to act along principles of agile development, while also paying attention to context and organization-specific needs.

Iterative development based on the values of inspection, adaption and transparency will remain key, however if needed there are deviations from pure agile development (e.g., with regards to the stronger need for documentation, or the naming of specific roles).

The following main artefacts/roles will be used.

4.1.1 Sprint

Each sprint is a time boxed development phase which will be used to deliver ready to use products. The intention is, to add small features and user stories in each sprint to deliver an incrementally improved product. Each sprint shall have a two-week time box. The duration of the standard sprints can be adjusted as part of the retrospective.

4.1.2 Iteration/Product Increments (PI)

Each iteration is a collection of sprints, usually timeboxed with 3-month cycles.

4.1.3 Feature/User Story

Features and user stories are the artefacts which define the deliverables inside a sprint. They need to be described and documented. The team must agree on the “definition of done” for an agreement of completion of the respective artefacts. The difference between “user story” and feature for ICGLR is mainly the distinction between deliverables with a concrete impact on users (resp. user stories) like implementation of a specific dashboard or workflow or deliverables with no specific impact on users (resp. features) like implementation of a core data model.

4.1.4 Backlog

The Backlog covers the list of all features and user stories which are in scope or will be in scope for implementation. It acts as the pipeline for to be implemented artefacts.

4.1.5 Daily Stand-ups

Daily stand-ups are a standard approach as part of the SCRM methodology. The technical working group (TWG) coordinated by the team leader meets at a dedicated fixed and short time slot (usually 15 minutes) and answers one by one the following questions:

• What did I do yesterday?

• What will I do today?

• What are obstacles on my way?

Based on experience we have the DO’s and DON’T DO’s:

DO’s

1. Create and support an open environment and atmosphere.

2. Schedule follow ups for identified obstacles.

3. Be firm, be brief, be open.

Don’t DO’s

3. Don’t use it for individual tracking.

4. Don’t expand the timeslot by going too much into the details (rather schedule follow up)

5. Don’t blame.

4.1.6 Retrospective, Review & Planning

As the iterations in ICGLR are quite short, best practice has been established to combine retrospective, review, and planning session. During this session the following activities are to be performed:

1. Review the result of the features planned for the current sprints based on the “definition of done”.

2. Accept or reject completion status.

3. Review the “definition of done”.

4. Review the preparation of features in the backlog.

5. Plan features or user stories for the current sprint

6. Adjust the approach if necessary.

4.1.7 Scrum team

The scrum team is the team which will deliver the final solution. As per the currently planned (to be revised setup) it consists of members of:

1. Implementation team of the consulting team

2. Implementation team of ICGLR and GoR

3. Member(s) of the Technical Working Group (TWG)

4.1.8 Product owner

The ICGLR project manager acts as the product owner for this project. He/she will provide priorities for project artefacts and finally accept or reject the implemented features or user stories.

4.1.9 PM-System and collaboration systems

The ICGLR and/or GoR uses “OpenProject” for project tracking and planning. This system shall be used for project planning and reporting by the contractor.

4.1.10 CI/CD Environment

The contractor shall use the ICGLR Data Cloud to share the source codes. However, depending on the assessment to be conducted prior to resuming the development of SOLUTION, the contractor should use the GoR Gitlab in addition for versioning and CI/CD.

4.1.11 Continuous tasks for each sprint (Definition of Done)

In the planning, the development team agrees on a goal together with GIZ and ICGLR. The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Development Team to work together rather than on separate initiatives. The sprint goal will be documented by the contractor as a user story or feature in the defined project management system and signed off for delivery as part of the sprint planning.

All the work necessary to achieve the product Goal happens within the sprint. In each sprint the following should be done (in addition to the delivery of the respective user stories for this sprint according to best practices):

4.1.11.1 Testing and quality assurance

For each user story there will be in-depth testing by the Contractor, but also by the proxy product owner (or deputy) provided by ICGLR. Final sign off will be given by the product owner based on the acceptance criteria and definition of done. While this process will evolve over time, it is expected that security and privacy by design and by default is key in this implementation and a focus of the respecting testing efforts.

4.1.11.2 Documentation

Detailed documentation of the functionalities and commentary of the source code is to be provided by the contractor for all delivered user stories.

Overarching documentation (functional and technical documentation, architecture diagrams) is incrementally updated with each sprint and will be reviewed as part of each sign-off of user stories. It shall always update to reflect current system status.

The client sets up a test environment and, during and after the development process, conducts the relevant recommended tests (e.g., unit, integration, load). Tests are also conducted regularly with future users of the IT solution.

Work results to be provided by the contractor:

• A usable increment deployed at least into the testing and integration environment.

• Test documentation

4.1.11.3 Knowledge Sharing

For each implemented feature the ICGLR staff confirms that the following knowledge was transferred:

• How to use the use the feature;

• How to do administration of feature;

• How to troubleshoot the feature;

• How to do further adjustments on the feature; and

• How to deploy the system.

4.1.11.4 Iteration Review

Within this review the contractor, ICGLR and GIZ will have a look on the status of the product and discuss about next steps and features which are expected from the contractor. In deviation to agile methods, the meeting does not constitute a formal acceptance or confirmation of performance. Nevertheless, results and agreements done within the meeting have to be documented by the contractor and will be assessed in following iteration reviews by the review attendances.

4.1.11.5 Time Reporting

The contractor is obliged to report the delivered hours against the defined user stories and features in the project management system of ICGLR. ICGLR will review these time sheets and forward them to GIZ for approval. ICGLR shall evaluate the performance of the contractor based on the deliverables set in the epics and iterations.

4.2 Continuous project management

The Contractor shall appoint an experienced project manager as a permanent contact person for the performance of the services over the term of the contract. The project manager who shall be responsible for project management on the part of the Contractor, including:

1. Regular progress reports, after each sprint (can be exports of project management tool)

2. Provide monthly report for the ongoing progress in line with the implementation of SOLUTION to the Technical Working Group (TWG) set by ICGLR and recommendation for future SOLUTION functionality improvements.

3. Input to high level product planning; feasibility assessments and high-level product design/ vision sessions that will be necessary before actual backlog items/ user stories are defined.

4. Mobilizing additional expertise from respective support roles as needed

4.3 Planned Iterations/Product Increments (PI)

Each iteration is timeboxed with a timeline which shall be agreed on with the contractor during the assessment. It is a best practice to aggregate 6 sprints (each 2 weeks) per iteration. As per project management methodology the user stories and features for each iteration will be prioritized at the beginning of each iteration. The following description describes the current plan for the focus in each iteration. This focus can be adjusted as part of the iteration planning.

4.3.1 Product Increments 1:

The following epics will be the key focus for Iteration 1:

• Epic 1: System architecture definition and validation

• Epic 2: Implementation of the UI and Backend for the Digital Registry for the National Minerals Database.

• Epic 3: Data Management for license management

4.3.2 Product Increments 2:

The following epics will be the key focus for Iteration 2:

• Epic 4: Data management for export certificates

• Epic 5: Data management for minesite inspections

• Epic 6: User management

4.3.3 Product Increments 3:

The following epics will be the key focus for Iteration 3:

• Epic 7: Integrations with the data sharing solution

• Epic 8: Knowledge Transfer

5 Granting of rights of use

<To be done:

GIZ procurement will formulate a paragraph based on above mentioned use of open source.

6 Data protection and information security

6.1 Data Protection

When the GIZ hires a contractor to build or upgrade a data processing system (platform, website, app etc.) on behalf of a local partner, who determines the purposes and means of the data processing activity, the GIZ does not bear ANY responsibility for such processing. Although the GIZ builds such systems in conformity with the highest data protection standards, however, its responsibilities end with the handing over of the systems to the partner. As a data controller, the partner must ALONE comply with all local and regional laws applicable to such processing (including the GDPR, where applicable). Consequently, the data protection principles such as lawfulness, data minimization, accuracy, purpose limitation, storage limitation, transparency, integrity and confidentiality, and accountability, as well as the numerous rights of the data subject should be paid due attention. We equally recommend the partner to conclude data protection agreements with the hosting service provider(s) and the maintenance service provider(s), where applicable. The GIZ would be available to support the partner whenever the need arises.

The contractor should comply with the data protection and privacy law according to the data protection offices of ICGLR Member states.

6.2 Information security

The following points must be considered by the contractor and if they are not within the

contractor’s responsibility or scope of work, they must at least be discussed with the partner’s

project team in order to close any existing security gaps.

The Contractor must inform the Client immediately and in an appropriate form about security

incidents that may affect the Client. If the Customer has appointed an IT security officer or

another person to receive such information, the information must be sent directly to this person.

A firewall must be installed upstream of the server (e.g., authorized IP addresses/GEO

blocking or address ranges for logging on to the system can be entered here or also excluded for this purpose).

Up-to-date anti-virus software must be used on the server and configured accordingly for

automatic updates.

Network communication between the components of the application should be encrypted.

Hard-coded keys (symmetric/asymmetric) should not be included in the application. If this is

unavoidable, the handling of the key must be described. The information security risks related to the storage of the key must be evaluated.

The transmission of authentication information (especially passwords) must be encrypted. The storage and transmission of sensitive and/or personal data must comply with current

encryption standards.

Session cookies used for logins must be deleted after logging out from the client.

Separation of application and data is to be provided, i.e. an application server and a separate

server for the database and file storage is provided, with communication through a firewall.

A system log is to be implemented in which at least logins and logouts of all users and actions such as updates, backups, uploads and downloads, changes to account data and

authorizations, as well as all security-relevant actions and events are to be logged and

documented. The inclusion of further log data is still to be discussed in detail with the project.

The system log is to be documented in the operating manual.

The error messages generated by the application (especially exception handling/exceptions)

must not provide any information that allows conclusions to be drawn about the architecture or software/software versions used.

When configuring the web server, you must pay attention to the following:

• Disable Trace HTTP Request

• Run as a separate User & Group

• Disable signature

• Disable banner

• Restrict access to a specific network or IP

• Use only TLS 1.2

• Disable Directory Listing

• Remove unnecessary DSO modules

• Disable Null and Weak Ciphers

• periodically updates of the system -> stay current!

• periodically checks of the system log files

The system must be hardened against SQL injection. In detail, this concerns the validation,

filtering and cleansing of user input. The inputs may only have expected properties and

characters and may not contain any unauthorized metacharacters that are passed to the SQL interpreter.

When implementing API interfaces, it is essential to harden them against malicious code

injection (SQL injection, etc.) via the URL.

The system must be protected against Cross Site Scripting (XXS) on the client side. The

server(s) must be protected against reflected or persistent cross site scripting by securing the

server source code. All data to be processed by the server must be validated befor execution.

Whitelists of permitted data can be used for this purpose. General conversion of certain script characters is also a popular method. It is to be prevented that executable metacharacters of the scripts are read by the server. Cookies should only be read by the server (HttpOnly) and not by JavaScript in the browser.

A password policy must be implemented, which should look like this:

• minimum number of digits e.g. 12

• latin capital letters (A-Z)

• lower case Latin letters (a-z)

• basic digits (0-9)

• non-alphanumeric characters (like !, $, #, -, &)

• your password must not contain the whole or parts of your login name!

• after 5 wrong entries the account should be locked for 3 minutes

• max. password age 90 days

• password history, at least 5 different passwords in before a previously used password is accepted again, new passwords that differ only by consecutive numbers should not be accepted.

Passwords must not be stored in plain text. Passwords may only be stored as hash values.

The hash algorithm must conform to the current recommendations of the BSI (technical guidelines).

Hard-coded passwords must not be included in the application. The transmission of authentication information (especially passwords) must be encrypted.

2-factor authentication is to be implemented; Google Authenticator is not to be used for this.

2FA is to be possible via multiple channels (app, SMS or e-mail).

A role and authorization concept must be implemented that includes at least the roles of system admin (full authorization to the entire system), CMS admin (+account management), editor and author (editing content/articles). The application to be developed must be operable with minimal system rights. Only the following user groups may have access to the backend:

Developers and administrators of the Contractor as well as employees for editorial maintenance of the Contractor.

Access to the backend at the operating system level may therefore only be granted to very limited user groups with the appropriate expertise.

There must be a documented authorization concept for each application (e.g. in the operating manual).

In order to minimize operating errors (human errors), the ergonomics of the application should be designed safely according to the need for protection.

Changes to account data that are required for registration may only be made by the administrators and are to be blocked for the user.

For the upload of files, appropriate file filters are to be provided so that no files with executable content (scripts, programs or SQL codes) can be uploaded and executed.

The regular backups of the complete system are to be carried out by the Contractor and checked accordingly for usability (restore). The backup can be stored on the server, but a copy must always be stored offline to prevent loss through hacker attacks. The intervals for the backups are to be coordinated with the project.

Important backups always belong offline on another system and must be validated!

The deletion procedure must be proven upon request. Legal retention obligations remain unaffected.

7. Language

In deviation from sections 1.2, 6.1 and 8.1 of the Supplementary Terms of Contract for IT Services – EVB-IT Standard Business Terms for IT Services (EVB-IT-Service-AGB), the services are to be provided in English.

8. Technical-methodological concept

In the conceptual design of the tender (technical-methodological approach, project management, if necessary other requirements), the tenderer is required to take specific objectives and requirements into consideration and describe them, as explained below.

8.1 Requirements for the technical-methodological concept (section 1 of the assessment grid)

In the tender, the tenderer is required to show how the services specified in section 3, where relevant taking account of other specific methodological requirements (section 2), are to be provided (technical, methodological concept).

8.1.1 Assessment of the requirements:

The tenderer must assess the objective and the requirements of the IT solution (see sections 1 and 2) in relation to feasibility and to what particular (non-)technical difficulties must be considered in the IT solution to be developed by the tenderer regarding the objective (section 1.1 of the assessment grid).

8.1.2 Project management and development methodology:

The tenderer should consider the design of the project management process and describe his or her methodology for development/implementation, considering the described requirements (section 2 and 3) and compliance with the milestones (section 3) (section 1.2 of the assessment grid).

8.1.3 Operational plan/personnel assignment plan:

The tenderer must create and explain an operational plan that also includes a personnel assignment plan for all the specialist staff that he or she offers. The operational plan must depict the assignment periods (time and expert days) and describe the necessary work steps and take account of and, where necessary, supplement section 3.3 (section 1.3 of the assessment grid).

8.1.4 Test and documentation concept:

The tenderer must describe the process for testing and documenting the IT solution and the IT security and documentation standards used (section 1.4 of the assessment grid).

9 Human resources

9.1 Human resources concept

The tenderer is required to provide staff for the positions (‘experts’) referred to and described here in terms of the scope of tasks and qualifications based on corresponding CVs (see section 7).

The qualifications specified below meet the requirements for achieving the highest score in the technical assessment.

Expert 1:Team Leader and Project Manager (Section 3.1 of the assessment grid)

Tasks of the Expert

• Overall responsibility for the advisory packages of the contractor (quality and deadlines and scope).

• Coordinating and ensuring communication with GIZ, ICGLR, partners and others involved in the project.

• Personnel management, identifying the need for short-term assignments within the available budget, as well as planning and steering assignments and supporting local and international short-term experts.

• IT Architecture for the solution

• Regular reporting in accordance with deadlines; and

• Making himself/herself available when needed by the GIZ and ICGLR as beneficiary.

Qualifications:

Education/training (section 3.1.1 of the assessment grid):	University qualification (Masters, Bachelor or equivalent) in computer science, Compuer engineering, or relevant field with skills in project management or having certificate from a recognized institution like PMI or Prince2, A is added advantages
Language (section 3.1.2 of the assessment grid):	Good business language skills in English (C1)
General professional experience (section 3.1.3 of the assessment grid):	7 years of professional experience in the IT sector
Specific professional experience (section 3.1.4 of the assessment grid):	At least 2 years of proven track record of the development of Complex systems (Front-end, Back-end, mobile app, integrations with minimum 5 other systems) with the use of open-source software as well as proven track record of experience in business analysis and product management
Leadership/management experience (section 3.1.5 of the assessment grid):	5 years of project management experience as IT project team leader in a company
Development cooperation and regional experience (section 3.1.6 of the assessment grid)	1 year of experience in projects in Africa (region) and 1 year experience working with development cooperation.

Expert pool 1 ‘Software Development Team’ with minimum of 1 to maximum 3 experts Section 3.5 of the assessment grid)

The experts can be exchanged during the contractual period in consultation with the officer responsible for the commission.

A CV for each expert must be added to the tender.

Exclusion criterion: If one of the marked exclusion criteria is not fulfilled the entire offer will be excluded.

Task of the Expert Pool

• Support team leader in the implementation of the defined tasks

Qualifications:

Education/training (section 3.5.1 of the assessment grid):	All experts with university qualification (Masters or Bachelor or equivalent) in computer science, Computer engineering, or relevant field
Language (section 3.5.2 of the assessment grid):	All experts with good business language skills in English (C1)
General professional experience (section 3.5.3 of the assessment grid):	Exclusion criterion: At least 3 experts with a minimum of 3 years of professional experience in software development using Lowcode/No code tools. Assessment criterion: Additional relevant experience in web-based software development will be assessed. 3 years is the baseline, and 7 years as scores the maximum.
Specific professional experience 1 (section 3.5.4 of the assessment grid):	Exclusion criterion : At least 1 expert with a proven track record of 2 years in the development of state of the art web-based workflow using Joget Lowcode tool Assessment criterion: Additional relevant experience in web-based workflow systems and joget lowcode/nocode development will be assessed. 2 years is the baseline, and 5 years as scores the maximum.
Specific professional experience 2 (section 3.5.5. of the assessment grid):	Exclusion criterion: At least 1 expert with a proven track record of 2 years in the development of state of the art devops implementation. Assessment criterion: Additional relevant experience in devops. 2 years is the baseline, and 4 years as scores the maximum.

The tenderer must provide a clear overview of all the proposed experts and their individual qualifications.

Soft skills of all team members

In addition to their specialist qualifications, the following qualifications are required of team members:

1. Team skills

2. Initiative

3. Communication skills

4. Socio-cultural competence

5. Efficient, partner- and client-focused working methods

6. Interdisciplinary thinking

7. Physical availability at the beneficiary site when required.

10. Costing requirements

10.1 Assignment of personnel and travel expenses

Per-diem and overnight accommodation allowances are reimbursed as a lump sum up to the maximum amounts permissible under tax law for each country as set out in the country table in the circular from the German Federal Ministry of Finance on travel expense remuneration (downloadable at https://www.bundesfinanzministerium.de).

Accommodation costs which exceed this up to a reasonable amount and the cost of flights and other main forms of transport can be reimbursed against evidence.

All business travel must be agreed in advance by the officer responsible for the project.

10.2 Sustainability aspects for travel

GIZ would like to reduce greenhouse gas emissions (CO₂ emissions) caused by travel. When preparing your tender, please incorporate options for reducing emissions, such as selecting the lowest emission booking class (economy) and using means of transport, airlines, and flight routes with a higher CO₂ efficiency. For short distances, travel by train (second class) or e-mobility should be the preferred option.

If they cannot be avoided, CO₂ emissions caused by air travel should be offset. GIZ specifies a budget for this, through which the carbon offsets can be settled against evidence.

There are many different providers in the market for emissions certificates, and they have different climate impact ambitions. The Development and Climate Alliance (German only) has published a list of standards (German only). GIZ recommends using the standards specified there.

10.3 Specification of assignment of experts and travel

Fee days	Number of experts	Number of days per expert	Total	Comments
Team leader	1	10	10
Expert pool 1	1-3	50

11. Requirements on the format of the tender

The structure of the tender must correspond to the structure of the ToR. It must be legible (font size 11 or larger) and clearly formulated. The language in which the tender must be written is English.

The technical-methodological concept of the tender (section 7 of the ToR) is not to exceed 12 pages (not including the cover page, list of abbreviations, table of contents and brief introduction).

The CVs of the staff proposed in accordance with section 0 of the ToR must be in the EU format and not exceed four pages in length. The CVs must clearly show what position the proposed person held, which tasks he or she performed and how many expert days he or she worked during which period in the specified references. The CVs should be submitted in English.

We strongly request that you do not exceed the number of pages specified.

12. Options

Not applicable.

12.1 Follow-on measure/extension of service-delivery period

Not applicable.

12.2 Expansion of the service content

Not applicable.

13 Annexes

13.1 Annex 1: Architecture Vision Minerals Flow Data Vault

./annex/Architecture Vision Minerals Flow Data Vault v27.3.2024.docx

13.2 Annex 2: Digital Registries building block specifications.

./annex/Digital Registries – 23Q4.pdf

13.3 Annex 3: RCM Manual

./annex/ 49111368 RCM.pdf

13.4 Annex 4: Data Protection standards

./annex/ Data-protection-standards-for-developing-digital-tools-meant-for-GIZ-s-partners.pdf

Annex / Attachments

Submission of offer: The Expression of Interest should contain the following:

Technical Proposal:

• A cover letter expressing your interest in this assignment

• Technical proposal with a brief description of why you would be considered as the most suitable for the assignment, relevant expertise, and a detailed, clear methodology, your approach to complete the assignment, template attached.

• Company registration certificate (RDB)

• VAT-Registration certificate

• Latest tax clearance certificate

• Proof of successful completion of related assignments.

Financial Proposal: The price per service category must contain all relevant costs supported by a breakdown of each cost. The costs must be in RWF and VAT

Please submit electronically your EoI (technical & Financial offer) in 2 separated emails and should be in PDF files to this email ONLY: RW_Quotation@giz.de until latest 17^th September 2024

Please you must write on each email subject this sentence:

83472480 Technical/financial offer, without this sentence, your offer may not be considered

Hard copies are not allowed this time

GIZ reserves all rights