IT trifft auf Beton!

Ich bin seit nunmehr einem knappen Jahr in das Neubauprojekt der WU Wirtschaftsuniversität Wien eingebunden. Man würde auf den ersten Blick vielleicht nicht vermuten, wieviel IT in einem modernen Gebäude steckt, aber der Campus WU ist voll davon.

Was mich im Bereich des Bau- und Einrichtungsprojekts immer wieder beeindruckt, sind Professionalität und Detailgrad der Planungen. Schon jetzt – zwei Jahre vor Montage – stehen beispielsweise Spezifikation und Position jeder einzelnen Leitung fest. In CAD-Plänen werden diese genauestens visualisiert, in zugehörigen Excel-Sheets aggregieren sich Kosten noch so kleiner Einzelteile zu einer konkreten Gesamtsumme.

Bei “meinen” Softwareprojekten ist das ganz anders, zum Beispiel: Am Campus soll es elektronische Gegensprechanlagen vor Departments und Dienstleistungseinrichtungen geben. Die grundsätzliche Anforderung, vor einer Tür stehend jemand dahinter anzurufen, klingt zunächst wenig komplex.

Bei genauerer Betrachtung ergeben sich allerdings viele Probleme im Detail, von denen ich nur ein paar aufzählen möchte:

  • Zahlreiche Eingänge liegen in Außenbereichen, wodurch die Hardware kalten Wintern, Feuchtigkeit, tief stehender Sonne und vor allem auch Vandalismus standhalten muss. Was innen vielleicht mit üblicher Hardware funktioniert, benötigt außen die “Military”-Variante mit Kosten, die drei- bis fünffach höher sind.
  • Für die Suche nach Personen werden lange Namenslisten benötigt. Spätestens seit dem iPhone will jede/r Benutzer/in nur noch mit Multitouch-Gestures scrollen. Kapazitive Touchscreens und die darunter-liegende Softwareschicht sind 2011 aber weit von Standardisierung entfernt. (emerging hardware)
  • Ein ambitionierter Wunsch nach Behindertengerechtigkeit stellt zusätzliche Anforderungen an das User Interface; Audioausgabe kann Blinden bei der Suche helfen. Rollstuhlfahrer/innen benötigen Screens weiter unten, usw. (compliance)
  • “Leute anrufen, die hinter dieser Tür sitzen” klingt trivial. Jede/r, die/der mit der Welt von Datenhaltung und Sonderfällen in Berührung ist, weiß, welche Probleme sich spätestens bei Umzügen, Einstellung externer Mitarbeiter/innen, Karenzierungen usw. ergeben. (Es ist alles sehr komplziert. Fred Sinowatz)
  • Ein zu erstellendes Sicherheitskonzept schreibt unter Umständen Videotelefonie als zusätzliches Sicherheitsmerkmal vor. Mit einer eingebauten Kamera multipliziert sich das Problem in den Bereichen Hard- und Software. Zusätzlich benötigen alle rund 1200 Mitarbeiter/innen die Möglichkeit, Videotelefonie am Rechner empfangen zu können, anstatt eines herkömmlichen Telefonapparats daneben. (die versteckte Killer-Anforderung)

Im Rahmen des Gesamtprojekts soll nun – verständlicherweise – eine Kostenschätzung her. Und da Universitäten Hard- und Software in derartigen Größenordnungen über Ausschreibung beschaffen, muss außerdem ein Ausschreibungs-taugliches Lastenheft erstellt werden.

Ich denke, mein Problem mit der Geschichte wird inzwischen klar. (Und wer nun denkt, man könne zumindest den Hardware-Teil leicht lösen, der soll sich einfach mal hinter Mail und Telefon klemmen und Europas Hersteller derartiger Devices kontaktieren…)

Während an einer Universität die Frage “An welchem Tag und mit exakt wieviel Aufwand an Reise- und Literaturkosten schafft Forscher/inneteam X mit Theorie Y den Durchbruch?” absurd klingt, tauchen ähnliche Fragen – wieder verständlicherweise – im Kontext der Softwareentwicklung auf.

Ich behaupte aber, das oben beschriebene Projekt ist näher an der Forschungsmetapher dran, als etwa am Betonieren der Gebäude.

Der Unterschied zwischen Betonieren und Programmieren

Im Certified Scrum Product Owner (CSPO) Training von Objectbay wurde das Stacey Diagram vorgestellt, das die Komplexität von Software-Projekten verdeutlicht. Ich habe es an dieser Stelle nachgezeichnet.

The Stacey Diagram

Die dargestellte Matrix zeigt Technologie und Anforderungen auf der x- und y-Achse. Sind etwa sowohl die Requirements als auch die eingesetzte Technologie klar, handelt es sich um ein simples Problem; ein Problem, das mit ausreichender Planung erschlagen werden kann. Auch tricky (im Original complicated) stellt noch kein besonderes Hindernis dar. Vielleicht steigt der Planungs- und Abstimmungsaufwand, aber die Aufgabe bleibt planbar.

Nun betreten wir die Welt komplexer oder gar chaotischer (im Original Anarchy) Projekte. Unklare Anforderungen gepaart mit technologischem Neuland eröffnen eine Welt voller Unsicherheit.

Wissenschaftliche Forschung bewegt sich rechts oben; aber auch Software-Projekte sind nur selten im linken, unteren Eck beheimatet. Das oben genannte Projekt jedenfalls nicht.

Das Planbar-Machen derartiger Umgebungen ist Thema zahlreicher, sogenannter agiler Projektmanagement-Methoden. Obwohl ich ein überzeugter Verfechter dieser Modelle bin, gibt es in meinem konkreten Arbeitsumfeld doch einige Einschränkungen wie etwa rechtlichen Hürden bei Beschaffungsvorgängen, etc.

Jedenfalls werde ich in Zukunft das Stacey Diagram gebetsmühlenartig vorstellen. Das hilft mir zwar kein bisschen bei meinem akuten Planungs-Dilemma, aber es entschuldigt vielleicht mein Scheitern auf transparente Weise…

Das CSPO-Training beim hervorragend dozierenden Andreas Wintersteiger von Objectbay kann ich übrigens nur empfehlen!

Leave a Reply

Your email address will not be published. Required fields are marked *