1. Contracting Authority

Institut Bauen und Umwelt e.V. (IBU)
Hegelplatz 1
10117 Berlin

Represented by the Managing Director: Florian Pronold
Primary Contact Person: Amar Salcinovic
Email: salcinovic@ibu-epd.com

2. Objectives and Scope of the Tender

The contracting authority intends to commission the rebuild/renewal of the application currently operated at epd-online.com. The existing solution will be technically replaced (“Replacement”) and functionally enhanced.

  • Agile Agile software development (Scrum or Kanban) with iterative collaboration. Requirements may be refined and adjusted during the project (change management, see Section 6).
  • Migration Data migration is part of the contract (see Section 7). No 1:1 migration of all data – only business-critical data will be transferred, particularly taking into account the links to IBU.data.
  • Flexible No obligation to develop 100% from scratch: existing, functionally similar systems may be contributed or forked and adapted, provided all requirements are met (see Section 10).

The current application at epd-online.com serves as the functional reference. The requirements specification and the implementation specification to be created within the project are decisive.

3. Scope of Services

  1. Requirements analysis in line with the requirements specification; initialization of the product backlog.
  2. Implementation specification (Phase 1) as the functional and technical specification including architecture and data model outlines.
  3. Agile implementation based on the implementation specification (sprints/iterations).
  4. Quality assurance & testing: unit, integration, system, and acceptance tests; test data; test reports.
  5. Data migration including mapping, ETL processes, test migrations, validation, and cutover (details in Section 7).
  6. Technical documentation & program description, operations/administration manual, user documentation.
  7. Delivery of the complete source code in a private GitLab repository owned by the contracting authority (see Section 9).
  8. Training for administrators and key users.
  9. Bug fixing until successful acceptance (see Section 8).
  10. Maintenance & support after acceptance (mandatory, see Section 11).

Optional services (to be specified in the proposal): hosting/operations, monitoring, CI/CD setup, performance/load testing, accessibility audit.

4. Project Phases and Milestones

  1. Phase 0 – Kick-off & Setup: team, tools, repo, CI/CD, definition of ready/done.
  2. Phase 1 – Implementation specification: agreed final version as the foundation for delivery and acceptance.
  3. Phase 2 – Agile development: sprint-based delivery with review/demo, continuous backlog refinement.
  4. Phase 3 – Testing & acceptance: system/UAT testing, defect log, acceptance according to criteria (Section 8).
  5. Phase 4 – Rollout & data migration: cutover plan, go-live, hypercare.
  6. Phase 5 – Maintenance & support: SLA-based service.

5. Project Organization & Communication

  • Approach: Scrum or Kanban; sprints (typically 2–3 weeks), backlog, sprint planning, daily, review/demo, retrospective.
  • Roles: product owner (IBU), project lead/delivery lead (contractor), developer(s), QA/tester(s), architect, optionally DevOps.
  • Tools: collaboration (e.g., MS Teams/Jira/Confluence), code management GitLab (private), CI/CD.
  • Communication: regular meetings (jour fixe), minutes, decision log.
  • Transparency: burn-down/up, velocity, risk/issue log, regular status reports.

5a. Public GitLab Repository for Requirements Specification, Questions & Changes

To increase transparency, the contracting authority provides a public GitLab repository (requirements specification documents only, no source code).

Purpose & Usage

  • Single source of truth for the requirements specification: docs/Lastenheft.md (source) and docs/Lastenheft.pdf (output).
  • Questions exclusively as GitLab issues until the question deadline (see Section 18). Answers/additions will be documented publicly there.
  • Change history via commits, tags/releases (e.g., v0.9, v1.0);
  • Bidders subscribe to the repo (watch/release notifications) to stay informed about changes.

Repo Structure

  • /README.md – short description, participation notes, deadlines, link to the PDF.
  • /docs/Lastenheft.md – source; /docs/Lastenheft.pdf – output.

Governance & Ground Rules

  • No proposal submissions via GitLab. Proposals are to be submitted as described in Section 18.
  • Do not post confidential information in issues.
  • Clarifications are issued by the contracting authority via commit/release and referenced in the CHANGELOG.md.
  • After contract award, source code development takes place in a private GitLab repository owned by the contracting authority (see Section 9).

6. Agile Collaboration & Change Management

  • Scope changes are introduced into the product backlog in a controlled manner, prioritized, and scheduled via sprint planning.
  • Significant scope changes require an assessment of impacts on time/cost (change request).
  • Acceptance criteria are defined in advance for each user story/function and serve as the basis for reviews/acceptance.

7. Data Migration (Part of the Contract)

  • Objective: transfer of the business-relevant legacy data while maintaining existing links with IBU.data.
  • Scope of services: data inventory and classification, mapping concept, ETL processes, test migrations, data quality checks, reports, defect lists, cutover plan (incl. downtime window), fallback strategy.
  • No 1:1 migration: only the necessary data will be migrated; reduction/transformation in line with the implementation specification.
  • Data protection: compliance with GDPR/FDPA; pseudonymization/anonymization where possible; data processing agreement prior to production launch (see Section 14).
  • Acceptance: formal confirmation of data quality based on defined validation rules/samples.

8. Acceptance, Quality Assurance & Warranty

  • Quality standards: clean code, code reviews, automated tests, awareness of the OWASP Top 10, logging/monitoring hooks.
  • Acceptance criteria: fulfilment of the implementation specification and agreed acceptance criteria, successful execution of test cases, remediation of critical defects (severity definitions in the implementation specification).
  • Acceptance process: UAT with report; partial acceptances per sprint if applicable.
  • Warranty: defect resolution within a warranty period (to be stated in the proposal; minimum suggestion: 12 months from acceptance).

9. Source Code, Repository & Documentation

  • Repository: complete source code in a private GitLab repository owned by the contracting authority. The contractor receives project-specific access.
  • Licence & confidentiality: code is strictly confidential and not public. Disclosure to third parties or use for third parties without prior written approval is prohibited.
  • Documentation: architecture, API specifications, operations manual (runbook), user manual, migration and test documentation versioned in the repo.
  • CI/CD & quality: pipeline configurations, IaC (if commissioned), linter/formatter rules, test reports.

Transfer of Rights

  • Unless stated otherwise in the proposal, all usage and exploitation rights to all work results newly created in the project (including source code) pass to the contracting authority after full payment.
  • Pre-existing components of the contractor (including a contributed fork) remain the property of the contractor; the contractor grants the contracting authority an unlimited, transferable, and sublicensable licence to use them within this solution, including access to source code, modification, and operation.
  • The contractor warrants that no third-party rights are infringed and that open-source licences (including copyleft) are compatible and documented (SBOM/third-party notice). Copyleft licences that trigger publication obligations require prior written approval.

10. Permitted Reuse / Forks

  • Bidders may introduce existing systems and create a fork to meet the requirements of the specification.
  • The fork may not be shared with third parties, published, or used for third-party projects without written approval from the contracting authority where project-specific components are concerned.
  • The contractor ensures that all contributed components are legally compliant and that the usage rights outlined in Section 9 are granted.

11. Maintenance & Support (Mandatory Component)

  • Scope: bug fixing, security updates, minor enhancements, performance tuning.
  • Suggested SLA: response times per priority (P1 critical – e.g., 4h; P2 high – 1 business day; P3 normal – 3 business days), service times (business days xx:xx–xx:xx, time zone Europe/Berlin), communication channels, escalation.
  • Release management: versioning, change log, planned maintenance windows.

12. Proposal Content (Mandatory Components)

Company Information

  • Company profile
  • Evidence of qualifications and expertise
  • References for comparable agile software projects (including contact persons)
  • Availability/team (roles, capacity, qualifications)

Project-related Information

  • Description of the planned agile approach (framework, sprint length, artefacts)
  • Schedule & milestones (including buffers, critical path)
  • Project organization & communication structure
  • Technical concept including architecture, technology stack, security concept, CI/CD
  • Migration concept (scope, mapping, ETL, validation, cutover, risks)
  • Quality assurance measures & test strategy
  • Optional: hosting/operations concept

Pricing Information

  • Complete and transparent pricing details (e.g., fixed-price components, time & materials per sprint, daily rates)
  • Explanation of pricing and assumptions
  • Costs for maintenance, support, and further development (mandatory, SLA-based)
  • Optional services to be itemized separately (e.g., hosting, load testing)

Legal

  • Description of licence/rights granting in line with Sections 9–10
  • Statement on third-party software/OSS including licence list/SBOM
  • Sample data processing agreement or declaration of willingness to conclude one

13. Award Criteria

  • Quality and suitability of the technical concept (including security & scalability)
  • Agile delivery capability (team, process maturity, references)
  • Migration approach and risk management
  • Plausibility and feasibility of the schedule
  • Price and transparency of the calculation
  • Quality and scope of maintenance/support (SLA)
  • References & previous project experience

(Bidders may optionally be invited to bidder presentations/demos.)

14. Data Protection (GDPR) & Information Security

  • Compliance with EU GDPR and the German Federal Data Protection Act (BDSG).
  • Conclusion of a data processing agreement prior to production launch.
  • Privacy by design/default, data minimization, authorization concepts, logging.
  • Information security following best practices (e.g., OWASP, hardening, protection of confidential information).

15. Confidentiality (NDA)

All information provided during the proposal and project phase is confidential. Disclosure to third parties is prohibited. This obligation continues beyond the end of the contract.

16. Contract and Framework Conditions

  • The contract is based on the implementation specification confirmed jointly after contract award and this tender.
  • Supplementary agreements require written form.
  • Transfer of rights and repository rules as per Sections 9–10.
  • Billing and payment terms in accordance with the proposal.

17. Procedure

  1. Publication/distribution of the tender documents including link to the public GitLab repository
  2. Question deadline: questions exclusively via GitLab issues in the public repo; answers/clarifications will be published there.
  3. Proposal submission (not via GitLab)
  4. Review and evaluation of proposals
  5. Follow-up questions/bidder presentations (optional)
  6. Award decision
  7. Contract award and project start

No entitlement to an award exists.

18. Deadlines

  • Question deadline for bidders: 01.12.2025, 18:00
  • Proposal deadline: 30.12.2025, 18:00
  • Desired project start: 01.02.2026

Please interpret all deadlines in the Europe/Berlin time zone.

19. Communication

Public GitLab Repository (Q&A & changes):
Questions about the requirements specification and clarifications are handled exclusively via issues in the public repository. The link is provided with the tender. Answers are visible to all bidders there.

Formal/administrative communication:
Amar Salcinovic
Email: salcinovic@ibu-epd.com
Please do not submit proposal documents or confidential content via GitLab.

20. Appendices

© Institut Bauen und Umwelt e.V. – All rights reserved.

Back to top ↑