Wenn ein IT-Projekt aus dem Ruder läuft, wird meist die Technik verantwortlich gemacht. In der Rückschau erweisen sich jedoch fast immer dieselben organisatorischen Muster als Ursache – und sie sind sämtlich vermeidbar.
Zahlen zur Quote gescheiterter Projekte kursieren viele. Sie beruhen allerdings auf sehr unterschiedlichen Vorstellungen davon, was Scheitern bedeutet: überschrittenes Budget, verfehlter Termin, reduzierter Umfang oder ein Ergebnis, das niemand nutzt. Als Maßstab für das eigene Vorhaben taugen sie deshalb wenig. Nützlicher ist die Frage, an welchen Stellen Projekte typischerweise kippen – und was sich dagegen tun lässt, bevor das erste Geld ausgegeben ist.
Fünf Muster und ihre Gegenmittel
- Kein messbares Ziel: „Wir wollen digitaler werden“ lässt sich nicht abschließen, „Auftragsdurchlauf von fünf auf zwei Tage“ schon. Gegenmittel: ein bis drei Zielgrößen mit heutigem Ausgangswert, schriftlich festgehalten, bevor Anbieter angefragt werden.
- Niemand entscheidet: Ohne benannte Person mit Entscheidungsbefugnis wird jede Detailfrage zur Hängepartie, und das Projekt verliert Woche um Woche. Gegenmittel: ein Auftraggeber aus der Geschäftsführung oder dem Fachbereich, der Budget und Prioritäten verantwortet und offene Fragen innerhalb vereinbarter Fristen klärt.
- Anwender kommen zuletzt: Wer die künftigen Nutzer erst zur Schulung einbindet, kauft Widerstand statt Akzeptanz – und erfährt zu spät, dass ein alltäglicher Sonderfall nicht abgebildet ist. Gegenmittel: Personen aus der täglichen Praxis arbeiten von der Anforderungsliste bis zum Test mit und haben dafür ausdrücklich Zeit.
- Alles auf einmal: Große Umstellungen mit einem einzigen Stichtag maximieren das Risiko, weil jeder Fehler alle Bereiche zugleich trifft. Gegenmittel: Etappen mit sichtbarem Zwischenergebnis, etwa zuerst ein Standort, eine Abteilung oder ein Prozess, und ein vorab festgelegter Rückweg, falls eine Etappe nicht trägt.
- Kein Betrieb mitgedacht: Nach dem Projekt beginnt der Alltag – mit Aktualisierungen, neuen Mitarbeitenden, Fragen und Störungen. Gegenmittel: Zuständigkeit, Pflege, Unterstützung der Anwender und das dafür nötige jährliche Budget werden festgelegt, bevor der Vertrag unterschrieben ist, nicht danach.
Auffällig ist, dass keines dieser Muster mit der gewählten Software zu tun hat. Sie lassen sich deshalb auch nicht durch einen Anbieterwechsel beheben: Ein Vorhaben, das an fehlenden Entscheidungen gescheitert ist, gerät mit dem nächsten System aus demselben Grund ins Stocken. Wer nach einem missglückten Projekt neu beginnt, sollte zuerst die Organisation des Vorhabens prüfen und erst danach das Produkt.
Was erfolgreiche Projekte gemeinsam haben
Sie haben einen klaren Auftraggeber aus dem Fachbereich, ein Ziel in Zahlen, einen Zuschnitt in überschaubare Etappen mit sichtbarem Zwischenergebnis – und mindestens eine Person aus der täglichen Praxis, die von Anfang an mitarbeitet und mitentscheidet. Technisch anspruchsvolle Vorhaben gelingen unter diesen Bedingungen häufig besser als technisch einfache, die organisatorisch naiv angegangen werden.
Ein Punkt verdient im Mittelstand besondere Aufmerksamkeit: die Projektleitung „nebenbei“. Wer ein Einführungsprojekt zusätzlich zum vollen Tagesgeschäft steuern soll, wird im Zweifel immer dem Tagesgeschäft den Vorrang geben. Eine ehrliche Planung weist deshalb aus, wie viele Stunden pro Woche Projektleitung und Fachanwender tatsächlich freigestellt sind – und wer ihre übrigen Aufgaben in dieser Zeit übernimmt.
Hilfreich ist außerdem ein schlichtes Entscheidungsprotokoll. Jede offene Frage erhält einen Eintrag mit der Person, die entscheidet, und einem Datum. Das beschleunigt nicht nur das Projekt, sondern beantwortet später auch die Frage, warum etwas so gebaut wurde, wie es gebaut ist.
Fünf Fragen der Geschäftsführung vor dem Start
- Woran erkennen wir in zwölf Monaten, ob sich das Projekt gelohnt hat – und wie hoch ist der Ausgangswert heute?
- Wer entscheidet, wenn Fachbereich, IT und Dienstleister unterschiedlicher Meinung sind?
- Wie viel Arbeitszeit ist für Projektleitung und Fachanwender verbindlich eingeplant?
- Was ist die erste Etappe, und wann ist ihr Ergebnis im Alltag sichtbar?
- Was tun wir, wenn eine Etappe scheitert – gibt es einen Rückweg zum bisherigen Verfahren?
Keine dieser Fragen verlangt technisches Wissen. Sie verlangen aber Antworten, bevor Verträge unterschrieben werden. Ein Projekt, für das sie sich nicht beantworten lassen, ist noch nicht startbereit – ganz gleich, wie ausgereift die gewählte Software ist.
Die ehrliche Abnahme
Ein letzter Punkt, der oft fehlt: die ehrliche Abnahme. Ein Projekt ist nicht fertig, wenn die Software läuft, sondern wenn der Prozess im Alltag messbar besser funktioniert als vorher. Diese Prüfung sollte terminiert und dokumentiert sein – sonst bleibt offen, ob sich der Aufwand gelohnt hat. Bewährt hat sich ein zweiter Termin einige Monate nach dem Start, an dem die Zielgrößen vom Projektbeginn erneut gemessen werden.
Die Abnahme hat zudem eine rechtliche Seite. Soweit die Einführung als Werkvertrag vereinbart ist, wird mit der Abnahme in der Regel die Vergütung fällig (§ 641 BGB), und die Verjährung der Mängelansprüche beginnt (§ 634a Abs. 2 BGB). Nach § 640 Abs. 2 BGB kann ein Werk sogar als abgenommen gelten, wenn der Auftraggeber eine ihm gesetzte angemessene Frist verstreichen lässt, ohne mindestens einen Mangel zu benennen. Eine Abnahme im Vorbeigehen ist deshalb auch aus diesem Grund keine gute Idee.
Wer technische und fachliche Abnahme bewusst trennt – erst funktioniert das System, dann erreicht der Prozess sein Ziel –, hat am Ende beides: die Rechtssicherheit gegenüber dem Dienstleister und die Gewissheit, dass das Vorhaben seinen Zweck erfüllt.
Verwandte Themen: Wer hier weiterdenkt, liest bei Cloud-Migration, E-Rechnung Versandpflicht und Schnittstelle weiter.
