Ein festgefahrenes Projekt übernehmen: was wir immer wieder vorfinden

Was wir meinen, wenn ein Projekt festgefahren ist

Manche Softwareprojekte kommen nicht zu uns, weil jemand etwas Neues bauen will, sondern weil etwas Bestehendes stecken geblieben ist. Der ursprüngliche Entwickler ist weg, die Agentur meldet sich nicht mehr, oder es wird seit Monaten gebaut und nichts läuft. Wir haben eine Reihe solcher Projekte übernommen, und was auffällt: Die Geschichten klingen verschieden, aber unter der Oberfläche kehren dieselben Muster wieder.

Dieser Bericht ist deshalb kein einzelner Fall mit dramatischer Wendung, sondern das, was wir immer wieder vorfinden, wenn wir ein festgefahrenes Projekt übernehmen. Wer gerade selbst in so einer Lage steckt, erkennt sich vielleicht wieder, und das ist der Punkt.

Der erste Blick, und was fast immer fehlt

Wenn wir ein solches Projekt anschauen, fehlen fast immer dieselben drei Dinge. Zuerst der Zugang: Niemand im Unternehmen hat den vollständigen Zugriff auf den Code, die Server oder die Konten. Das Wissen liegt bei einer Person ausserhalb, und wenn die nicht mehr will oder kann, steht alles. Wem der Code und die Zugänge gehören, ist eine Frage, die man am Anfang klärt und fast nie am Anfang klärt, wie wir im Text zur Übergabe von Code beschreiben.

Zweitens fehlt Dokumentation. Es gibt keine Notiz, warum etwas so gebaut wurde, wie es gebaut wurde. Man muss sich alles aus dem Code selbst erschliessen, und das dauert. Drittens fehlt Vertrauen. Der Auftraggeber ist gebrannt, hat schon einmal Geld ohne Ergebnis ausgegeben und erwartet insgeheim, dass es wieder schiefgeht. Diese Stimmung ist Teil des Problems, das man lösen muss.

Woran es meistens nicht liegt

Hier eine Beobachtung, die viele überrascht. Der Grund für das Scheitern ist selten die Technik. Fast nie sagen wir, dieses Projekt sei gescheitert, weil jemand die falsche Programmiersprache oder das falsche Werkzeug gewählt hat. Technik lässt sich reparieren, umbauen, ersetzen.

Was die Projekte tatsächlich zum Stehen bringt, sind Erwartung und Führung. Es wurde nie geklärt, was zuerst fertig sein muss und was warten kann. Es gab keinen, der beim Bauen die harten Entscheidungen getroffen hat, also wuchs der Umfang, bis nichts mehr fertig wurde. Das deckt sich mit dem, was wir generell sehen, warum Software-Projekte scheitern: fast immer an fehlender Steuerung, kaum je an der Wahl des Frameworks.

Was zuerst passiert, wenn wir übernehmen

Der erste Schritt ist unspektakulär: eine nüchterne Bestandsaufnahme. Was ist da, was läuft, was ist nur halb gebaut, wo liegen die Zugänge. Bevor irgendjemand eine Zeile ändert, sichern wir den Zugriff auf alles, den Code, die Server, die Domains, die Konten. Solange das bei einer fremden Person hängt, ist jeder weitere Schritt riskant.

Dann kommt der Teil, der am meisten bewirkt und am wenigsten spektakulär ist: einen kleinen, sichtbaren Nutzen zuerst liefern. Nicht das ganze System auf einmal richten, sondern eine Sache, die vorher nicht ging, zum Laufen bringen. Das beweist dem Auftraggeber, dass es vorangeht, und es gibt uns ein ungeschöntes Bild vom Zustand des Codes, das keine Bestandsaufnahme auf dem Papier liefert. Oft zeigt sich dabei, dass weniger kaputt ist als befürchtet, manchmal auch das Gegenteil.

Was ein Projekt tatsächlich rettet

Gerettet wird ein festgefahrenes Projekt selten durch einen grossen technischen Wurf. Es wird gerettet, indem drei Dinge zusammenkommen. Die Erwartung wird neu gesetzt, also klar benannt, was in welcher Reihenfolge realistisch ist. Es kommen kleine, sichtbare Schritte statt eines grossen Versprechens. Und es entsteht wieder Vertrauen, weil jemand tut, was er angekündigt hat.

Das klingt weich, ist aber der Kern. Ein Auftraggeber, der monatelang im Dunkeln sass, braucht zuerst das Gefühl, wieder Boden unter den Füssen zu haben. Der aufgestaute Berg an technischen Schulden wird dann Stück für Stück abgebaut, nicht in einer grossen Aktion, sondern entlang der Dinge, die ohnehin gerade anstehen.

Wann sich die Übernahme nicht lohnt

Wir raten nicht in jedem Fall zur Rettung. Manchmal ist das Bestehende in einem Zustand, in dem jede Änderung mehr kostet als ein sauberer Neuanfang. Wenn der Code niemandem mehr verständlich ist, keine Absicherung existiert und die ursprüngliche Idee ohnehin nicht mehr passt, ist der Neubau der günstigere Weg, auch wenn er sich zuerst teurer anfühlt.

Diese Einschätzung geben wir offen, auch wenn sie gegen den eigenen Auftrag spricht. Wer eine unabhängige zweite Meinung zu einem Software-Vorhaben sucht, bekommt von uns eher eine nüchterne Lagebeurteilung als ein Verkaufsgespräch. Genau diese Art von Projekten, das Bauen und Betreiben von Individualsoftware für KMU, machen wir regelmässig. Wenn bei dir etwas feststeckt und du nicht mehr weiterweisst, sprich mit uns, und wir schauen es uns ohne Beschönigung an.