Leitfaden
IT-Projektmanagement: was wirklich anders ist
IT-Projekte scheitern seltener an der Technik als an drei Eigenheiten des Geländes: einem unsichtbaren Produkt, geteilten Teams und einem Bestand, der weiterlaufen muss.
IT-Projektmanagement folgt denselben Grundlagen wie jedes andere Projekt — Umfang, Termin, Kosten, Risiko. Nicht die Methode ändert sich, sondern das Gelände, und drei Eigenschaften dieses Geländes erklären den größten Teil der Schwierigkeit: Was gebaut wird, ist nicht sichtbar; wer es baut, ist mit anderen Projekten geteilt; und das bestehende System muss die ganze Zeit weiterlaufen.
Fortschritt ist nicht beobachtbar
Auf einer Baustelle sehen alle die Stockwerke wachsen. In einem IT-Projekt ist das einzig sichtbare Signal das, was jemand meldet. Deshalb driftet der gemeldete Fortschritt bei Software auf eine bequeme Zahl und bleibt dort — die berühmten letzten 10 %, die drei Monate dauern. Das Gegenmittel ist, Fortschritt beobachtbar zu machen: lauffähige Software in festem Takt, laufende statt abschließender Integration, und Abnahmekriterien, die vor der Entwicklung geschrieben und nicht danach verhandelt werden.
Das Team ist nie dediziert
IT-Fachleute sind geteilt: Derselbe Architekt bedient vier Projekte, derselbe DBA liegt auf jedermanns kritischem Pfad, und der Produktionssupport geht vor, sobald ein Vorfall aufgeht. Ein Plan auf Basis nominaler Verfügbarkeit ist deshalb von Anfang an falsch. Zu planen ist auf der Kapazität nach Abzug von Support, Urlaub und den übrigen Projekten — eine Portfolio- und keine Projektfrage, und der Hauptgrund, weshalb IT-Termine rutschen, ohne dass ein einzelnes Projekt etwas falsch gemacht hätte.
Der Bestand gehört zum Umfang
Sehr wenige IT-Projekte beginnen auf weißem Papier. Schnittstellen zu vorhandenen Systemen, Datenmigration, das Nebeneinander zweier Stände während der Umstellung und die Rückabwicklung, falls der Start misslingt, werden in der Rahmenphase selten ernsthaft geschätzt — und wiegen regelmäßig schwerer als die neue Funktionalität. Ein Lastenheft, das nur das Ziel beschreibt und zur Umstellung schweigt, hat das halbe Projekt ausgelassen.
Agilität und Planung stehen sich nicht entgegen
Die meisten IT-Bereiche arbeiten hybrid, ob sie es zugeben oder nicht: agil in den Teams, zugesagte Termine und Budgets nach außen. Das Gegenteil zu behaupten erzeugt zwei entkoppelte Wahrheiten — ein Backlog, das eines sagt, und einen Lenkungsausschuss, der etwas anderes hört. Gangbar ist: Budget und Meilensteine planen, darin iterieren, und den Umfang neu entscheiden, statt den Termin still zu verschieben.
IT-Projekte mit FoxPlan steuern
FoxPlan hält beide Ebenen zugleich: ein geplantes Gantt mit Meilensteinen und Budget für die Zusagen, agile Boards und Sprints für die Arbeit selbst, und eine über alle Projekte konsolidierte Ressourcenkapazität — sodass ein geteilter Architekt als eine Person erscheint und nicht als vier. Die von den Teams erfasste Zeit speist Fortschritt und Kosten zugleich, was Bericht über ein IT-Portfolio ohne parallele Tabelle erst möglich macht.
