Die Projektphasen im IT-Projekt: von der Analyse bis zum Betrieb

IT-Projekte scheitern selten an der Technik. Sie scheitern daran, dass eine Phase übersprungen, verkürzt oder mit der falschen Besetzung durchlaufen wird. Wer die Phasen kennt und weiß, welcher typische Fehler in welcher Phase lauert, erkennt Fehlentwicklungen früh — solange sie noch günstig zu korrigieren sind.

Warum eine Phasenstruktur hilft

Ein Projektmodell ist kein Selbstzweck und keine Bürokratie. Es beantwortet drei Fragen: Was ist gerade fertig? Was ist die Voraussetzung für den nächsten Schritt? Und woran erkennen wir, dass wir weitergehen dürfen? Ohne diese Struktur beginnt die Umsetzung, während die Anforderungen noch diskutiert werden, und Änderungen treffen auf Entscheidungen, die längst umgesetzt sind.

Die folgenden neun Phasen beschreiben ein Infrastruktur- oder Migrationsprojekt im Mittelstand. Bei kleinen Vorhaben laufen mehrere Phasen in einem Termin zusammen; entfallen sollte keine.

1. Analyse

Am Anfang steht die Bestandsaufnahme: Welche Systeme sind im Einsatz, wie hängen sie zusammen, welche Prozesse laufen darüber, wo drückt es tatsächlich? Ergebnis ist ein dokumentiertes Ist-Bild und eine Problembeschreibung, die ohne Lösungsvorschlag auskommt.

Typischer Fehler: Die Analyse beginnt mit einer bereits feststehenden Lösung. Dann wird nur noch gesucht, was diese Lösung rechtfertigt. Ein zweiter, häufiger Fehler ist, nur mit der IT zu sprechen und nicht mit den Menschen, die täglich mit den Systemen arbeiten. Die relevanten Umgehungslösungen kennen nur sie.

2. Konzept

Aus dem Ist-Bild entsteht ein Zielbild: Wie soll es aussehen, welche Anforderungen muss die Lösung erfüllen, welche Randbedingungen gelten — Budget, Zeit, Datenschutz, vorhandene Verträge, Fachanwendungen. Wichtig ist die Trennung zwischen Muss- und Kann-Anforderungen.

Typischer Fehler: Anforderungen werden als Produktnamen formuliert. „Wir brauchen Produkt X" ist keine Anforderung, sondern eine vorweggenommene Auswahlentscheidung. Formulieren Sie stattdessen, was das System leisten muss. Der zweite Fehler: Alles ist ein Muss. Wenn nichts priorisiert ist, entscheidet später der Zufall.

3. Auswahl

Jetzt werden Lösungen und Anbieter gegen die Anforderungen bewertet. Sinnvoll sind mindestens zwei ernsthafte Alternativen, eine nachvollziehbare Bewertungsmatrix und, wo möglich, ein Test mit echten Daten statt einer Vorführung mit vorbereiteten Beispielen.

Typischer Fehler: Die Auswahl erfolgt über den Angebotspreis statt über die Gesamtkosten aus Lizenzen, Betrieb, Migration und Ausstieg. Ebenso verbreitet: Der spätere Betreiber der Lösung sitzt bei der Auswahl nicht mit am Tisch und erbt eine Entscheidung, die er nicht mitgetragen hat. Wenn der auswählende Berater die Lösung anschließend selbst verkauft, sollte diese Doppelrolle offen benannt sein.

4. Planung

Hier entstehen Ablaufplan, Ressourcen, Zuständigkeiten, Termine und ein Rückfallplan. Zur Planung gehören Abhängigkeiten — Lieferzeiten, Wartungsfenster, Urlaubszeiten, Jahresabschluss, Saisonspitzen — und die Frage, was passiert, wenn der Umstellungstermin nicht hält.

Typischer Fehler: Kein Rückfallplan. Wer keinen definierten Weg zurück hat, ist am Umstellungswochenende gezwungen, jedes Problem vorwärts zu lösen, egal wie spät es wird. Zweitens: Die Belastung der eigenen Mitarbeiter wird nicht eingeplant. Ein Projekt kostet interne Zeit, und die fehlt im Tagesgeschäft.

5. Umsetzung

Aufbau, Konfiguration, Anpassung, Datenübernahme. Diese Phase ist die sichtbarste und in der Regel die am besten beherrschte, weil sie technisch ist. Wichtig ist, dass Änderungen am Umfang hier nicht formlos einfließen, sondern bewusst entschieden werden.

Typischer Fehler: Schleichende Erweiterung. Jede einzelne Zusatzanforderung wirkt klein, in Summe verschieben sie den Termin. Zweitens: Die Dokumentation wird auf später verschoben. Später heißt in der Praxis nie.

6. Test

Getestet wird gegen die Anforderungen aus dem Konzept, nicht gegen das Gefühl der Beteiligten. Dazu gehören Funktionstests, ein Lasttest bei relevanten Systemen, ein Test der Datensicherung mit tatsächlicher Wiederherstellung und Tests durch Anwender aus den Fachbereichen.

Typischer Fehler: Es testen nur die, die gebaut haben. Sie testen den vorgesehenen Weg. Anwender machen andere Dinge, und genau die brechen. Zweiter Fehler: Die Wiederherstellung aus der Sicherung wird nicht geprüft. Eine Sicherung, die nie zurückgespielt wurde, ist eine Annahme.

7. Rollout

Die Einführung in der Fläche. Bewährt hat sich ein stufenweises Vorgehen: eine Pilotgruppe, dann Abteilungen, dann alle. Dazu gehören Anwenderinformation vorab, Schulung wo nötig und eine erhöhte Betreuungsdichte in den ersten Tagen.

Typischer Fehler: Umstellung aller Bereiche an einem Tag ohne Pilot. Was im Test nicht auffiel, trifft dann alle gleichzeitig. Zweitens: keine Kommunikation. Anwender, die am Montag vor einer veränderten Oberfläche sitzen, ohne vorgewarnt zu sein, erzeugen Widerstand, der lange nachwirkt.

8. Übergabe in den Betrieb

Dies ist die am häufigsten unterschätzte Phase. Der Grund ist psychologisch: Nach dem Rollout fühlt sich das Projekt fertig an. Die Technik läuft, die Rechnung ist gestellt, das Team wendet sich dem nächsten Vorhaben zu. Tatsächlich beginnt hier erst der Zeitraum, in dem die Lösung ihren Wert liefern muss — über Jahre, mit anderen Menschen, unter Alltagsbedingungen.

Zur Übergabe gehören: vollständige Dokumentation der Konfiguration, Zugangsdaten in einem geordneten Verfahren, Betriebshandbuch mit den wiederkehrenden Aufgaben, definierte Zuständigkeiten für Störungen, Einbindung in Überwachung und Datensicherung, Lizenzübersicht sowie eine Liste der bekannten offenen Punkte. Sinnvoll ist ein formales Übergabeprotokoll, das beide Seiten unterschreiben.

Typischer Fehler: Es gibt keine definierte Übergabe, sondern einen fließenden Übergang. Das Projektteam bleibt informell zuständig, weil nur es die Lösung kennt. Sechs Monate später ist die Person nicht mehr im Haus, und niemand weiß, warum eine bestimmte Einstellung so gesetzt wurde. Zweiter Fehler: Der Betrieb erbt Systeme, für die keine Wartungs- oder Supportverträge abgeschlossen wurden — das fällt erst beim ersten Ausfall auf. Wer den Betrieb an einen externen Partner übergibt, sollte diese Anforderungen bereits in der Planungsphase mit ihm abstimmen.

9. Nachbetreuung

Vier bis acht Wochen nach dem Rollout ein Rückblick: Was funktioniert, was nicht, welche Anforderung wurde erfüllt und welche nicht, was hat mehr gekostet als geplant und warum. Diese Auswertung ist unangenehm und der einzige Weg, beim nächsten Projekt besser zu werden.

Typischer Fehler: Der Rückblick entfällt, weil das Projekt abgeschlossen ist. Damit wiederholt sich derselbe Fehler beim nächsten Vorhaben.

Phasen im Überblick

Phase	Ergebnis	Häufigster Fehler
Analyse	Dokumentiertes Ist-Bild	Lösung steht vorher fest
Konzept	Priorisierte Anforderungen	Produktnamen statt Anforderungen
Auswahl	Begründete Entscheidung	Preis statt Gesamtkosten
Planung	Ablaufplan mit Rückfallweg	Kein Plan B
Umsetzung	Lauffähige Lösung	Schleichende Erweiterung
Test	Nachweis gegen Anforderungen	Nur Erbauer testen
Rollout	Produktivsetzung	Alles auf einmal, ohne Pilot
Übergabe	Dokumentation und Zuständigkeit	Fließender Übergang ohne Protokoll
Nachbetreuung	Auswertung und Nachbesserung	Findet nicht statt

Was ein Projekt tragfähig macht

Drei Dinge unterscheiden erfahrungsgemäß gelungene von mühsamen Projekten. Erstens ein Auftraggeber im Unternehmen, der entscheiden darf und erreichbar ist — nicht ein Gremium, das alle drei Wochen tagt. Zweitens eine schriftliche Abnahme je Phase, auch wenn sie nur aus einer halben Seite besteht. Drittens die Bereitschaft, ein Projekt anzuhalten, wenn sich die Grundlage geändert hat. Ein gestopptes Projekt ist unangenehm, ein zu Ende geführtes Projekt am Bedarf vorbei ist teurer. Wenn Ihnen intern die Kapazität für die Steuerung fehlt, ist eine externe Projektbegleitung ohne Lieferinteresse eine sinnvolle Ergänzung.

• Projekte scheitern an übersprungenen Phasen, nicht an Technik.
• Anforderungen gehören ins Konzept, Produktnamen erst in die Auswahl.
• Ohne Rückfallplan gibt es am Umstellungswochenende nur noch den Weg nach vorn.
• Die Übergabe in den Betrieb ist die am häufigsten unterschätzte Phase — sie entscheidet über die nächsten Jahre.
• Ein Rückblick nach vier bis acht Wochen ist der einzige Weg, beim nächsten Projekt besser zu werden.