Die APAC-Checkliste für Engineering-Partner: 12 Fragen vor der Unterschrift

Unternehmen in APAC, die einen Software-Engineering-Partner evaluieren, sollten vor der Unterzeichnung einer Vereinbarung eine strukturierte Vorvertragsprüfung durchführen. Die richtige Checkliste deckt Liefer-, Kommerz- und Betriebsrisiken auf, bevor sie zu Ihrem Problem werden. Diese zwölf Fragen sollen Ihnen die Informationen liefern, die Sie für eine fundierte Entscheidung benötigen.

1. Wer wird tatsächlich für unser Konto zuständig sein?

Viele Engineering-Partner präsentieren in Angebotsgesprächen erfahrene Senior-Entwickler, setzen für aktive Kunden jedoch Mid-Level- oder Junior-Entwickler ein. Fordern Sie Namen und Profile der Teammitglieder an, die tatsächlich an Ihrem Produkt arbeiten werden. Bestätigen Sie, dass diese Personen aktuell verfügbar und keinem anderen Projekt zugeteilt sind. Führen Sie vor der Unterzeichnung ein direktes Interview mit mindestens einer dieser Personen.

2. Wie sieht Ihre Erfolgsbilanz bei Projekten unserer Größenordnung aus?

Allgemeine Referenzen aus dem Portfolio reichen nicht aus. Fordern Sie Fallstudien von Kunden mit ähnlicher Produktkomplexität, Teamgröße und Lieferzeit an. Verlangen Sie die ursprüngliche Schätzung im Vergleich zur tatsächlichen Lieferzeit für drei aktuelle Projekte. Partner mit einer konsistenten Erfolgsbilanz können diese Daten ohne Zögern bereitstellen.

3. Wie gehen Sie mit Scope-Änderungen während eines laufenden Projekts um?

Der Umgang mit Scope-Änderungen zeigt, wie ein Partner mit kommerziellem Druck umgeht. Bitten Sie um ein konkretes Beispiel, wie eine bedeutende Scope-Änderung in einem früheren Projekt gehandhabt wurde: wie sie dokumentiert, wie die kommerzielle Auswirkung bewertet und wie sie dem Kunden kommuniziert wurde. Vage Antworten an dieser Stelle deuten auf spätere Streitigkeiten hin.

4. Wie sieht Ihre Compliance- und Datensicherheitslage aus?

Prüfen Sie bei APAC-Projekten die Übereinstimmung mit den relevanten regulatorischen Rahmenwerken — den MAS-TRM-Richtlinien für Singapur, dem PDPA für personenbezogene Daten sowie allen branchenspezifischen Anforderungen Ihrer Branche. Fragen Sie, ob der Partner in den letzten zwölf Monaten ein Sicherheitsaudit durchgeführt hat und ob er die Zusammenfassung dafür teilen kann. Wenn Ihr Produkt sensible Daten verarbeitet, fordern Sie die Dokumentation zu Datenverarbeitung und Zugriffskontrollen an.

5. Wie ist Ihre Kommunikationsstruktur während der aktiven Projektumsetzung?

Klären Sie den Berichtsrhythmus, das Format der Sprint-Updates, den Eskalationsweg bei Produktionsvorfällen und die benannten Ansprechpartner auf beiden Seiten für dringende Anliegen. Ein Partner ohne definierte Kommunikationsstruktur greift standardmäßig auf Ad-hoc-Nachrichten zurück, was genau in den kritischsten Momenten zu Informationslücken führt.

6. Wie sieht Ihr Eskalationsweg aus, wenn etwas schiefläuft?

Fragen Sie, wen Sie kontaktieren, wenn um 23 Uhr Ihrer Zeit ein Produktionsvorfall auftritt. Klären Sie, ob der Partner Bereitschaftsdienst anbietet, wie hoch die Reaktions-SLA ist und ob diese SLA vertraglich festgehalten ist. Eskalationswege, die nur informell existieren, sind keine Eskalationswege — sie sind bloße Hoffnungen.

7. Wem gehört das geistige Eigentum, und wie wird das dokumentiert?

Das Eigentum an geistigem Eigentum sollte im Vertrag eindeutig geregelt sein. Bestätigen Sie, dass sämtlicher Code, sämtliche Dokumentation und alle im Rahmen des Projekts erstellten Ergebnisse nach Zahlung an Sie übergehen. Fragen Sie, wie der IP-Übergang am Ende des Projekts gehandhabt wird und ob es Ausnahmen für wiederverwendbare Bibliotheken oder interne Tools gibt, die der Partner bei mehreren Kunden einsetzt. Lassen Sie diese Klausel vor der Unterzeichnung von einem Anwalt prüfen.

8. Wie ist die Preisstruktur aufgebaut, und was sind die häufigsten Szenarien für Kostenüberschreitungen?

Klären Sie, ob das Projekt zum Festpreis, nach Aufwand (Time-and-Materials) oder als Retainer-Modell abgerechnet wird — und was ein kommerzielles Gespräch außerhalb des geplanten Umfangs auslöst. Bitten Sie den Partner, die zwei oder drei häufigsten Szenarien zu beschreiben, in denen frühere Kunden Kosten über der ursprünglichen Schätzung hinaus hatten. Transparenz an dieser Stelle signalisiert kommerzielle Reife.

9. Wie stabil ist Ihr Engineering-Team über einen Zeitraum von 12 Monaten?

Fluktuation bei Entwicklern ist ein Lieferrisiko, das Sie direkt betrifft. Fragen Sie nach der durchschnittlichen Betriebszugehörigkeit der Entwickler und der Fluktuationsrate im vergangenen Jahr. Wenn sich das für Ihr Konto zuständige Team während des Projekts erheblich verändert, tragen Sie die Kosten für die Einarbeitung. Partner mit stabilen Teams und geringer Fluktuation stellen bei längeren Projekten ein geringeres Lieferrisiko dar.

10. Wie sieht Ihr Onboarding-Zeitplan für ein Team unserer Größe aus?

Ein realistischer Onboarding-Zeitplan schützt Sie vor falschen Erwartungen im ersten Sprint. Fragen Sie nach dem Standard-Onboarding-Plan: Wie lange dauert es, bis das Team eingerichtet und produktiv ist, wie läuft die Vergabe von Zugriffsrechten ab, und wann wird typischerweise der erste eigenständige Sprint geliefert? Vergleichen Sie dies mit Ihrem eigenen Zeitplan und passen Sie ihn entsprechend an.

11. Wie stellen Sie die Wissenskontinuität sicher, wenn ein Schlüsselentwickler das Unternehmen verlässt?

Der Weggang von Entwicklern ist ein bekanntes Risiko bei jedem längerfristigen Projekt. Fragen Sie, wie der Partner Architekturentscheidungen dokumentiert, wie der Wissenstransfer innerhalb des Teams gehandhabt wird, wenn jemand das Unternehmen verlässt, und ob ein Vertretungsmodell für kritische Rollen besteht. Partner mit soliden internen Dokumentationspraktiken schaffen eine geringere Abhängigkeit von einzelnen Personen.

12. Wie sieht aus Ihrer Sicht ein erfolgreicher Start in den ersten 90 Tagen aus?

Diese Frage zeigt, wie der Partner über Erfolg denkt. Starke Partner beschreiben konkrete Lieferergebnisse: ausgelieferte Funktionen, stabilisierte Systeme, etablierte Prozesse. Partner, die sich auf Beziehungsaufbau ohne messbare Meilensteine konzentrieren, tun sich womöglich schwer, bei zunehmendem Lieferdruck Verantwortlichkeit aufrechtzuerhalten. Halten Sie vor Projektbeginn schriftlich fest, wie Erfolg aussieht.

Häufig gestellte Fragen

Worauf sollten APAC-Unternehmen bei der Bewertung eines Engineering-Partners besonders achten?

Liefertreue, Verfügbarkeit erfahrener Entwickler und Compliance-Status sind für APAC-Unternehmen die drei wichtigsten Faktoren. Kommerzielle Konditionen und Tagessätze spielen ebenfalls eine Rolle, sind jedoch diesen drei Faktoren nachgeordnet. Ein günstiger Partner mit inkonsistenter Lieferung und geringem Compliance-Wissen verursacht über ein zwölfmonatiges Projekt hinweg deutlich höhere Kosten als ein teurerer Partner, der zuverlässig liefert.

Wie lange sollte der Vorvertragsprüfungsprozess dauern?

Eine gründliche Prüfung eines Software-Engineering-Partners sollte zwei bis vier Wochen in Anspruch nehmen. Dazu gehören eine Angebotsprüfung, direkte technische Interviews, Referenzgespräche und eine rechtliche Prüfung der Vertragsbedingungen. Verkürzte Zeitpläne erhöhen das Risiko, wesentliche Informationen zu übersehen. Wenn ein Partner auf eine schnellere Entscheidung drängt, fragen Sie nach dem Grund.

Welche Warnsignale gibt es während der Bewertung eines Engineering-Partners?

Warnsignale sind unter anderem: die Unfähigkeit, die Entwickler zu benennen, die an Ihrem Konto arbeiten werden, vage Antworten zur Erfolgsbilanz, Zurückhaltung bei der Bereitstellung von Kundenreferenzen, IP-Klauseln, die den Partner bevorzugen, sowie informelle oder undokumentierte Kommunikationsstrukturen. Jedes dieser Signale rechtfertigt eine genauere Prüfung vor der Unterzeichnung.

Ist es üblich, Vertragsbedingungen mit einem Engineering-Partner zu verhandeln?

Ja. Die meisten Engineering-Partnerschaftsverträge sind verhandelbar, insbesondere bei IP-Übertragungsbedingungen, Zahlungsmeilensteinen, Eskalations-SLAs und Kündigungsbedingungen. Ziehen Sie für diese Prüfung einen Rechtsbeistand mit Erfahrung in Technologiedienstleistungsverträgen hinzu. Die Bedingungen, die Sie vor der Unterzeichnung aushandeln, bestimmen, unter welchen Voraussetzungen Sie einen Partner während des gesamten Projekts zur Verantwortung ziehen können.