Über mich





  • Beiträge über




  • Erstellung von IT-Anforderungen bei der SBB – Trial and Error?

    Portraitfoto von Martin Sturzenegger, Rhätische Bahn RhB, vormals SBB 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…

     

    Share

    Allenfalls interessieren Sie auch folgende Artikel:

    1. Management von ändernden Anforderungen in IT-Grossprojekten per Scrum
      Vortrag von Andreas Führer, SBB, am Swiss Requirements Day. Die Zuwachsraten im öffentlichen Verkehr sind enorm und das im bereits...
    2. Ringier in der Datenwolke – MS Office vs. Google Cloud Apps
      Vortrag von Samuel Hügli, CFO, Leiter Corporate Center: Ringier löst schrittweise Microsoft Office ab und setzt auf internetbasierte Software von...
    3. Anforderungen priorisieren
      Die Fragen drehen sich um geschäftsstrategische Entscheide im Umfeld von Grosssystemen wie SAP oder Avaloq. Kauft man ein Produkt oder...
    4. Strategie & Konzeption bei Online- und Offline-Kommunikation in der Unternehmenskommunikation
      Im Rahmen von Xing Zürich und learningZ wurde von den “Medien-Machern” zum Thema referiert “Mehr Leser mit wenig Mehraufwand –...
    5. Relaunch von ZHweb – Website des Kantons Zürich
      User Centered Design – der anfängliche Wunsch nach Prosa und Schnell wechselnde Bilder Vortrag von Andreas Jufer, Stabsstelle E-Government, Projekt...




    Zurück nach oben   |   oder zur Homepage


    Was ist Ihre Erfahrung?


    Suchen und Finden

    Neuste Artikel


  • Dem Blog per E-Mail folgen

    E-Mail ist jederzeit abbestellbar


    RSS Feed oder RSS-Feed abonnieren
  • Blog-Hosting

    Empfehlung: Im Hosting von Hostpoint sind verschiedene Applikationen inbegriffen, u.a. Wordpress als Blog CMS.

  • E-Byz.ch auf Facebook

  • E-Business Tag Cloud