IT-Projektmanagement zwischen Technik, Kunde und Wirtschaftlichkeit

IT-Projektmanagement ist mehr als Planung

Ein Projektplan ist wichtig. Aber ein sauber gepflegter Zeitplan macht noch kein gutes IT-Projekt.

Gerade in Infrastrukturprojekten ändern sich Rahmenbedingungen schnell: Hardware kommt später, eine Anwendung hat unerwartete Abhängigkeiten, ein Hersteller ändert Lizenzbedingungen oder während der Umsetzung zeigt sich, dass eine Annahme aus der Planungsphase nicht stimmt.

Für mich besteht gutes IT-Projektmanagement deshalb vor allem darin, Entscheidungen strukturiert zu treffen und transparent zu machen. Technik, Ziel, Kosten, Risiko und Betrieb müssen zusammen betrachtet werden.

Microsoft formuliert einen ähnlichen Gedanken im Cloud Adoption Framework: Technologieentscheidungen sollen an messbare Geschäftsziele gekoppelt werden, und Investitionsentscheidungen müssen zu diesen Zielen passen.^[1]

Kundenwunsch und tatsächlicher Bedarf sind nicht immer dasselbe

Ein Kunde kommt oft mit einer konkreten Vorstellung: „Wir wollen Proxmox“, „wir brauchen Cloud“, „wir möchten immutable Backups“ oder „dieses System soll ersetzt werden“.

Das ist ein Ausgangspunkt – aber noch keine belastbare Anforderung.

Die entscheidende Frage ist nicht: „Welche Technologie wollen wir?“ Sondern: „Welches Problem soll damit gelöst werden?“

Bei einer Virtualisierungs-Migration kann das beispielsweise Kostenreduktion sein. Vielleicht geht es aber genauso um Herstellerabhängigkeit, auslaufende Hardware, fehlenden Support oder den Wunsch nach einem einfacheren Betriebsmodell.

Erst wenn dieses Ziel klar ist, lässt sich bewerten, ob die gewünschte Technologie wirklich passt. Sonst besteht die Gefahr, dass ein Projekt technisch erfolgreich abgeschlossen wird, ohne das eigentliche Problem gelöst zu haben.

Technik, Aufwand und Wirtschaftlichkeit müssen zusammenpassen

Technisch lässt sich fast immer noch eine robustere, schnellere oder redundant ausgelegte Variante bauen. Die Frage ist nur, ob der zusätzliche Aufwand im Verhältnis zum Nutzen steht.

Ich versuche deshalb, Entscheidungen nicht isoliert über Features zu treffen. Für mich gehören mindestens vier Dimensionen zusammen:

• Technik: Funktioniert die Lösung zuverlässig und erfüllt sie die Anforderungen?
• Aufwand: Wie hoch sind Migration, Implementierung und laufende Pflege?
• Wirtschaftlichkeit: Welche Lizenz-, Hardware-, Cloud- und Betriebskosten entstehen?
• Betrieb: Kann das Team die Lösung später sinnvoll betreiben und supporten?

Das zeigt sich beispielsweise bei Virtualisierung sehr deutlich. Eine Plattform kann auf dem Papier günstiger sein, aber zusätzliche Migration, Schulung, Monitoring und Betriebsaufwand erzeugen. Umgekehrt kann eine vorhandene Lizenzierung eine Plattform wirtschaftlich interessanter machen, obwohl sie beim reinen Feature-Vergleich zunächst unspektakulärer wirkt.

Genau darum ging es auch in meinem Beitrag „VMware, Proxmox oder Hyper-V? Wie ich die passende Virtualisierungsplattform auswähle“: Nicht ein einzelnes Produktmerkmal entscheidet, sondern das Gesamtmodell.

Risiken früh sichtbar machen

Risiken verschwinden nicht dadurch, dass man sie im Projektplan nicht erwähnt.

Wenn beispielsweise für eine Migration zu wenig Backup-Speicher vorhanden ist, eine Downtime nicht exakt vorhersehbar ist oder eine Anwendung nach Herstellerangabe nur eingeschränkt unterstützt wird, gehört das früh auf den Tisch.

Für mich ist das kein Zeichen schlechter Planung, sondern genau das Gegenteil. Gute Projektsteuerung macht Unsicherheit sichtbar und schafft eine Entscheidungsgrundlage.

Dazu gehört auch, Alternativen zu benennen: zusätzlichen Speicher temporär bereitstellen, eine Migration in Phasen durchführen, einen Fallback definieren oder bewusst ein höheres Risiko akzeptieren.

Wichtig ist, dass solche Entscheidungen nachvollziehbar getroffen werden. Microsoft empfiehlt ebenfalls, Ziele, Constraints und Erfolgskriterien früh zwischen technischen und fachlichen Stakeholdern abzustimmen, um spätere Missverständnisse und teure Nacharbeiten zu vermeiden.^[2]

Der spätere Betrieb gehört schon ins Projekt

Ein klassischer Fehler ist für mich, eine Lösung nur bis zum Go-live zu planen.

Nach der Migration beginnt aber der eigentliche Lebenszyklus. Systeme müssen überwacht, gesichert, aktualisiert und dokumentiert werden. Zuständigkeiten müssen klar sein. Lizenz- und Cloud-Kosten laufen weiter.

Deshalb frage ich schon während des Projekts:

• Wie wird die Plattform später überwacht?
• Wie sieht das Backup- und Restore-Konzept aus?
• Wer übernimmt Updates und Changes?
• Welche laufenden Kosten entstehen?
• Welche Fähigkeiten benötigt der interne oder externe Support?

Dieser Gedanke knüpft direkt an meinen Beitrag „Vom IT-Projekt zum Managed Service: Was sich im Denken verändert“ an. Ein technisch erfolgreiches Projekt kann langfristig trotzdem schlecht funktionieren, wenn der Betrieb nicht mitgedacht wurde.

Technik verständlich übersetzen

Ein großer Teil von IT-Projektmanagement besteht für mich darin, zwischen unterschiedlichen Perspektiven zu übersetzen.

Ein Administrator möchte wissen, wie die Architektur aufgebaut ist. Ein Geschäftsführer interessiert sich eher für Kosten, Ausfallrisiko und Nutzen. Ein Anwender möchte wissen, was sich für ihn konkret ändert.

Alle drei brauchen Informationen – aber nicht dieselben Details.

Projektkommunikation funktioniert deshalb nicht gut, wenn technische Fakten nur weitergereicht werden. Sie müssen in eine Entscheidung übersetzt werden.

Statt „wir brauchen ein zusätzliches Repository“ ist beispielsweise die wichtigere Information: Ohne zusätzlichen Speicher kann während der Migration keine unabhängige neue Backup-Kette aufgebaut werden; dadurch steigt das Recovery-Risiko. Mit dieser Einordnung kann ein Entscheider Kosten und Risiko gegeneinander abwägen.

Dokumentation und Übergabe sind Teil des Ergebnisses

Ein Projekt ist für mich nicht fertig, nur weil die Technik funktioniert.

Die neue Umgebung muss nachvollziehbar dokumentiert sein. Offene Punkte müssen sichtbar bleiben. Zugang, Architektur, Backup, Besonderheiten und Zuständigkeiten müssen so beschrieben werden, dass nicht nur die Person weiterarbeiten kann, die das Projekt umgesetzt hat.

Gerade dieser letzte Teil entscheidet häufig darüber, ob aus einem erfolgreichen Go-live auch ein dauerhaft guter Betrieb wird.