Zeix-Vortrag von Martin Sturzenegger, vormals Programmleiter bei der SBB, heute Leiter Vertrieb & Marketing & Mitglied der Geschäftsleitung der Rhätischen Bahn.
In einem internationalen Bahn-IT-Projekt der SBB in Kooperation mit der Deutschen Bahn, den französischen SNCF und TrenItalia betrug die Schlussrechnung das Dreifache der ursprünglichen Kosteneinschätzung.
Was war passiert, was waren die Lessons Learned?
IT-Anforderungen haben mit Visionen, Personen, Business-Cases, unterschiedlichen Wünschen, etc. tun. Also praktisch allen Bereichen eines Unternehmens. Das zeigt schon, dass es ein komplexes Thema sein kann.
Die grobe Idee ist meistens schnell klar, doch zu welchem Preis, mit welchen Ausprägungen soll das Projekt realisiert werden?
Auch in IT-Projekten muss eine Story rüberkommen: In grossen Projekten wechseln oft die Stakeholder oder die Bedürnisse. Trotzdem muss die Story weitergehen…
Der Kernnutzen muss in einem überzeugenden Business-Case dokumentiert sein, monetär oder qualitativ.
Auch die Grenzen des Projektes müssen scharf umrissen werden. Auch das Zielbild sollte stabil bleiben, ein moving Target ist schwierig zu treffen…
Requirements Engineering sollte in Releases aufgeteilt werden. Dadurch sammelt man Erfahrungen und erarbeitet die weiteren Releases unterschiedlich. Dadurch kann auch schnell Business-Nutzen gestiftet werden.
Änderungen müssen laufend explizit bewirtschaftet werden (Change Board). Die „Projektsprache“ sollte festgelegt werden: Benutzt man z.B. UML Use Cases? Prototypen sind wichtige Ãœberprüfungsmittel.
Die Earned Value Methode eignet sich gut für die Projektsteuerung. Das Feeling erfahrener Projektleiter ist aber auch ein guter Indikator, Gantt-Charts oder eine Work-Breakdown-Structure sind praktische Hilfsmittel.
Im Stakeholder Management ist die aktive Pflege des Netzwerks ebenso wichtig wie die adressatengerechte Kommunikation. Der Projektleiter ist die Galionsfigur des Vorhabens und beeinflusst das Vertrauen der Stakeholder in die Projektarbeit massgeblich. Zu Handen der Stakeholder ist die Visualisierung von Zwischenschritten sehr wichtig: Welche Zwischenresultate wurden mit den eingesetzten Mitteln erreicht?
People Management: Eine enge Zeitplanung und hohe Identifikation mit dem Projekt sind für den Arbeitgeber zwar positiv, sollten aber nicht in einem Burn-Out von Mitarbeitenden enden. Auch die Wiedereingliederung von Projektmitgliedern nach Ablauf des Projektes in die Linie sollte gut geplant werden.
User-Centered-Design stellt sicher, dass man Anforderungen für die Kundensicht erstellt. Aber auch der „Kunde“ hat verschiedene Facetten: End-User, Administrator, Management, interner Kunde, etc. können verschiedene Use-Cases mit unterschiedlicher Ausprägung bedeuten.
Trotz Strukturen sollte man genügend Raum für Kreativität bereitstellen. Optimal ist es, wenn das Projekt mit „Start-up Spirit“ innerhalb des Unternehmens stattfinden kann. Nicht zu vergessen ist, dass das Projekt von Menschen lebt, von Profis, das Projektteam UND das Management.
Oft ist es erfolgreicher, nach Grobspezifikationen erste Prototypen zu bauen und Erfahrungen zu sammeln und erst dann weitere Detailspezifikationen zu erarbeiten. Basierend auf den gemachten ersten Schritten wird man wahrscheinlich die nächsten Releases anders konzipieren als ursprünglich gedacht.
Und genau dies war beim Projekt der SBB mit den umliegenden Bahngesellschaften das Problem: Die ursprüngliche Aufwandschätzung erfolgte, bevor die nötigen Projektunterlagen bekannt waren. In diesem Sinne wurde wie in manchen IT-Projekten die Komplexität unterschätzt: SBB, Deutsche Bahn, SNCF und TrenItalia arbeiten sehr unterschiedlich und eine Integration ihrer Prozesse ist eine grosse Herausforderung.
Erschwerend kommt dazu, dass Requirements bei der Aufwandschätzung praktisch nie vollständig vorliegen. Einmal abgesehen davon, dass Requirements per Definition kaum vollständig sein können, denn dann wäre es ja die fertige Software…
