Gescheitert heißt nicht immer, dass ein Projekt abgebrochen wird. Oft läuft die Software am Ende, aber niemand benutzt sie gern. Die Mitarbeiter führen ihre Excel-Liste weiter, die Hälfte der Funktionen bleibt ungenutzt, und das Budget ist trotzdem aufgebraucht.

Dieser Beitrag beschreibt die Gründe, die wir aus Sicht des Auftraggebers immer wieder sehen, und was Sie jeweils dagegen tun können. Nicht jeder Grund liegt beim Auftraggeber. Aber bei jedem kann der Auftraggeber etwas tun.

Der Ablauf war nicht verstanden

Am Anfang steht ein Wunsch: „Wir brauchen eine Auftragsverwaltung.“ Entwickelt wird dann, was der Anbieter unter einer Auftragsverwaltung versteht. Die Sonderwege des Betriebs, die Ausnahmen, die Regeln, die nur im Kopf einer Kollegin stehen, fallen erst auf, wenn die Software fertig ist. Dann passt sie nicht, und das Nachbessern ist teuer.

Was hilft: Den Prozess aufschreiben, bevor entwickelt wird, und zwar so, wie er wirklich läuft, nicht wie er im Handbuch steht. Wie das geht, beschreibt der Beitrag Prozesse dokumentieren.

Alles sollte auf einmal kommen

Das neue System soll Angebote, Aufträge, Lager, Rechnungen und den Außendienst abdecken, alles zum selben Starttermin. Damit wächst jede Unsicherheit gleichzeitig. Bis die erste Funktion im Alltag benutzt wird, sind viele Entscheidungen gefallen, die nie jemand überprüfen konnte.

Was hilft: Grob über das Ganze, genau über den ersten Bereich. Ein Grobkonzept zeigt die Richtung, und der erste Bereich wird so gewählt, dass er für sich allein schon nützt. Mehr dazu im Beitrag Grobkonzept und Feinkonzept.

Die eigenen Fachleute hatten keine Zeit

Die Leute, die den Ablauf am besten kennen, sind auch die, die im Tagesgeschäft unverzichtbar sind. Also wird das Projekt „nebenbei“ begleitet. Rückfragen bleiben liegen, Entwürfe werden nicht angesehen, und der Anbieter entscheidet, was eigentlich der Betrieb entscheiden müsste.

Was hilft: Planen Sie die Zeit Ihrer Fachleute so ein wie das Budget. Benennen Sie eine Person, die den Prozess kennt, Fragen zügig beantwortet und dafür im Tagesgeschäft entlastet wird.

Niemand hat entschieden

Soll der Außendienst Rabatte selbst vergeben dürfen? Gilt die neue Regel auch für Bestandskunden? Solche Fragen tauchen in jedem Projekt auf. Wenn niemand sie entscheidet, werden sie vertagt, oder jeder entscheidet sie anders. „Klären wir später“ ist ein häufiger Grund für Mehraufwand.

Was hilft: Legen Sie fest, wer im Betrieb entscheidet, und geben Sie dieser Person die Befugnis dazu. Offene Fragen gehören auf eine Liste mit Namen und Termin, nicht in die nächste Besprechung.

Die Ansprechpartner wechselten

Beim ersten Gespräch sitzt jemand mit Erfahrung am Tisch, die Umsetzung übernimmt ein anderes Team, und später ist wieder jemand Neues zuständig. Mit jedem Wechsel geht Wissen verloren, das nirgends aufgeschrieben stand. Dasselbe gilt auf Ihrer Seite, wenn der Projektverantwortliche den Betrieb verlässt.

Was hilft: Fragen Sie vorher, wer Ihr Ansprechpartner ist, und ob diese Person bis zum Betrieb dabei bleibt. Welche Fragen Sie einem Anbieter außerdem stellen sollten, zeigt der Beitrag Einen Softwareanbieter auswählen.

Alles wurde an einem Tag umgestellt

Am Stichtag wird das alte System abgeschaltet und das neue gestartet. Läuft an diesem Tag etwas nicht, steht der Betrieb still, und der Weg zurück ist verbaut. Unter diesem Druck werden Fehler hektisch behoben, und das Vertrauen der Mitarbeiter ist schnell verspielt.

Was hilft: Wo es möglich ist, Bereich für Bereich umstellen, während das alte System noch läuft. Beide Wege vergleicht der Beitrag Umstellung mit Stichtag oder schrittweise.

Getestet wurde mit ausgedachten Beispielen

Die Software funktioniert mit „Mustermann GmbH“ und einer Bestellung über drei Artikel. Im Betrieb kommt dann der Kunde mit vier Lieferadressen, die Bestellung mit hundert Positionen und die Rechnung mit Sonderrabatt. Das hat vorher niemand ausprobiert.

Was hilft: Eine Testfassung, getrennt vom Echtbetrieb, und eine Abnahme mit echten Beispielen aus Ihrem Alltag, durch die Leute, die später damit arbeiten. Wie das praktisch abläuft, beschreibt der Beitrag Abnahme und Testfassung.

Die Mitarbeiter wurden spät gefragt

Die Software wird im Büro der Geschäftsführung geplant und am Ende vorgestellt. Die Mitarbeiter sehen sie zum ersten Mal, wenn sie damit arbeiten sollen, und finden sofort, was nicht passt. Dann ist die Ablehnung groß, auch wenn die Software gut ist.

Was hilft: Die Leute, die täglich damit arbeiten, von Anfang an einbeziehen: bei der Aufnahme des Ablaufs, bei den ersten Entwürfen und beim Test. Wer mitreden konnte, arbeitet mit dem Ergebnis.

Der Betrieb nach dem Start war nicht geklärt

Die Software ist fertig, das Projekt abgeschlossen. Dann kommt das erste Update des Betriebssystems, der erste Fehler, der erste Änderungswunsch. Wer kümmert sich darum? Wenn das niemand vorher geklärt hat, veraltet die Software, bevor sie sich bezahlt gemacht hat.

Was hilft: Betrieb, Pflege und Weiterentwicklung gehören vor dem Start vereinbart, nicht danach. Was dazugehört, steht im Beitrag Software nach dem Start.

Alles hing an einer Person

Ein freier Entwickler, der als Einziger den Quellcode kennt. Eine Kollegin, die als Einzige weiß, wie die Schnittstelle eingerichtet ist. Solange diese Person da ist, fällt das nicht auf. Wenn sie geht, steht die Software still.

Was hilft: Quellcode, Zugänge und Dokumentation liegen bei Ihnen, und mehr als eine Person kennt die Software. Was Ihnen an bezahlter Software gehört, beschreibt der Beitrag Wem gehört die Software?, und was zu tun ist, wenn es schon passiert ist, der Beitrag Software ohne Entwickler übernehmen.

Was die Gründe gemeinsam haben

Kaum einer dieser Gründe ist technisch. Fast alle entstehen am Anfang, lange bevor jemand eine Zeile Code schreibt, und fast alle sind im ersten Gespräch schon zu erkennen. Deshalb lohnt es sich, dort genauer hinzusehen als bei der Frage, mit welcher Technik entwickelt wird.

Checkliste vor dem Start

  • Ist der Ablauf so aufgeschrieben, dass die Mitarbeiter ihn wiedererkennen?
  • Ist klar, welcher Bereich zuerst kommt, und nützt er für sich allein?
  • Hat die Person, die den Prozess kennt, im Tagesgeschäft Zeit für das Projekt?
  • Wer entscheidet offene Fragen, und darf er das auch?
  • Bleibt Ihr Ansprechpartner beim Anbieter bis in den Betrieb derselbe?
  • Wird mit echten Beispielen aus Ihrem Alltag getestet?
  • Ist geklärt, wer sich nach dem Start um die Software kümmert?
  • Liegen Quellcode und Zugänge bei Ihnen?