Category Archives: IT project management

IT project management

Campus WU: Drei Jahre in drei Minuten

Drei Jahre intensive (Projekt-)Arbeit, oder physikalisch ausgedrückt: Große Masse mal hoher Geschwindigkeit mal viel Weg.

“Man muß ins Gelingen verliebt sein, nicht ins Scheitern.”
Ernst Bloch

Door Signs

Über 200 Stück am gesamten Campus verteilt: Starten und aktualisieren sich über Netzwerk, gehen nachts schlafen, lesen Blinden die Belegung vor und kosten dabei ein Viertel der ursprünglichen Planung.

hj
61 der über 200 Displays vor Ort. Die angezeigte MAC-Adresse diente als Key bei der Inbetriebnahme.

Blogs dazu:

Self Service Terminals

Zehn Selbstbedienungsautomaten vor dem Study Service Center: Eine technische Herausforderung, barrierefrei, verbesserte Usability und – nach wahnsinnig stressiger Inbetriebnahme – inzwischen stabil.

bsfdb
Zwischenzeitlich haben tausende Studierende die Self Service Terminals im Library Center genutzt. (Sechs Terminals im Bild mittig; © Mathias August 2013)

Blogs dazu:

Final-Teilnahme beim Niederösterreichischen Innovationspreis.

Rooms

Dezentrale Raumbuchung für knapp 30.000 Benutzer_innen: Inhaltlich ist es Logistik pur samt dynamischer Lagerhaltung, Simulation, Statistik und passenden Visualisierungen. Rein technisch eine Herausforderung in JavaScript.

fff
Screenshot: User Interface der Raumbuchung für Studierende.

Blogs dazu:

Byte Bar und Leitsystem Terminals

fgfg fg
Die ByteBar- und Leitsystem-Terminals vor der Montage am Campus WU; Codename “Super-Toblerone”.

Surfstationen mit Login mittels berührungsloser Karte; Touchschirm, barrierefrei. Das Schwesterprojekt “Leitsystemterminal” dient zur Orientierung am Campus.

Blogs dazu:

API

gsg
Digital Signage Screens, die prominentesten Kunden unserer Lehrveranstaltungs-Daten API.

Viele unserer Daten sind – auch öffentlich – über Programmierschnittstellen verfügbar. So greifen alle hier beschriebenen Services auf dieselben Daten zurück, überall liest dieselbe Stimme Blinden vor, überall läuft dieselbe Logik, das Design ist gleich: managing complexity eines übergroßen Projekts eben.

Identmedien RFID

Eine Studierende holt sich einen Ausweis, verschließt ihre Sachen in einem der 3.600 Spindkasteln, bezahlt anschließend bargeldlos in der Mensa und öffnet einen gebuchten Projektraum: Keine Selbstverständlichkeit, läuft aber (immer besser).

Campus GIS

Geo-Informationssystem des Campus WU: Verortung von Personen und Organisationen, Suche nach POIs, Modellierung eines Routingnetzwerks zur Navigation, Flug einer Drohne für hochauflösende Luftbilder. Tool live: gis.wu.ac.at

Detaillierte Pläne, Suche, Routing bis hin zum Buch
Im Screenshot: Detaillierte Pläne der Regale zum Auffinden von Büchern in der Universitätsbibliothek.

Thanx + Uff!

Gerne würde ich hier behaupten, ich hätte das Alles programmiert, habe aber dann doch oft nur E-Mails geschrieben oder bin in endlosen Meetings gesessen. Ich musste langweilige Ausschreibungstexte querlesen, extern erdachte Konzepte ertragen, Kostenschätzungen durchs Haus schicken, Ideen verteidigen und am Widerstand Dritter scheitern sehen… Vier Befestigungsschrauben meiner Terminals kosteten mich so ein halbes Jahr Abstimmungsaufwand.

Als im Feuer getaufter Planerschlossertischlerdesignerentwickler kann ich nun verorten, kollaudieren, ausschreiben, beschaffen, eintakten, einbringen, einkippen, und Katzen hüten. Ich habe am Weg viele beeindruckende Menschen kennengelernt und dafür bin ich dankbar.

Es war ein Heidenspaß, ein Riesenstress und manchmal auch ein Mordsärger, vor allem aber war’s einzigartig und großartig. Wann und wo wird also der nächste Campus gebaut?

IT project management

Kommerzielle Software, Open Source oder Eigenentwicklung?

Mit meiner Studierendengruppe an der FH-Wien habe ich Vor- und Nachteile unterschiedlicher Lösungswege bei der Softwareauswahl diskutiert. Wohl wissend, dass es Mischmodelle gibt, haben wir zunächst drei Extremfälle herausgearbeitet:

  • Kommerzielle und gleichzeitig proprietäre Software – also im Idealfall ein Standardprodukt, welches das betriebliche Problem abdeckt. Es wird lizenziert, dazu gibt es Wartungsverträge, der Anbieter kümmert sich um Installation, Roll-Out und Betrieb.
  • Nicht-kommerzielle, freie Software – also im Idealfall ein Open Source Projekt samt aktiver Community, welche ebenso an dem Problem arbeitet. Das Unternehmen kümmert sich selbst um Installation, Roll-Out und Betrieb.
  • Eine in-house oder externe (Eigen-)Entwicklung – also eine Software, die erst geschrieben werden muss. Noch lange vor der Installation gibt es also ein Softwareprojekt mit Anforderungsanalyse, Umsetzung, Tests, usw.

Sinn der Diskussion war zu zeigen, dass es keine universell beste Lösung gibt. Vielmehr konnten wir fünf Ziel-Kriterien definieren, die in Konkurrenz zueinand stehen:

  • Investitionskosten
  • Folgekosten
  • Geschwindigkeit (Projektdurchlaufzeit)
  • Risikominimierung (Wie “sehr” darf dieses Projekt nicht schief gehen?)
  • Flexibilität (Anpassungsfähigkeit, Weiterentwicklungen)

Lege ich meinen Fokus etwa auf maximale Flexibilität, so werde ich bei der Eigenentwicklung landen. Denn hier stehen mir sämtliche Freiheitsgrade offen, das Ganze allerdings zum Preis der Geschwindigkeit.

randbedingungen
Das Software-Fünfeck.

Im konkreten Einzelfall sind uU einige Kriterien gut miteinand zu vereinbaren, in anderen Situationen widersprechen sie sich total. Die fünf Punkte werden allerdings bei der Zielsetzung von Softwareprojekten hilfreich sein.

Parallel zu diesen Zielkriterien konnten wir drei Randbedingungen herausarbeiten, die den Entscheidungsprozess begleiten. Auch hier gilt, dass die Punkte an die konkrete Situation angepasst werden. IT-Sicherheit wiegt für eine Bank wohl deutlich höher, als für einen Sportverein. Die Randbedingungen sind:

  • Sicherheit
  • Zufriedenheit (Usability)
  • Bestehendes Ökosystem (Passt dieses neue Stück Software in meine IT-Landschaft?)
ddd
Die Randbedingungen.

Wer Interesse an einer Checklist für die Auswahl konkreter Software-Produkte hat, dazu gab’s bereits einen Blog-Beitrag.

IT project management

IT-Outsourcing – heilige Kuh des Managements

Auf meinem Flug nach Mumbai sehe ich eine Dokumentation über den Bau des Londoner Aquatics Centre, dem Landmark der Olympischen Spiele 2012. Selbe Architektin, noch größere Dimensionen spielen sich bekanntlich derzeit am Campus WU ab. Angesichts dieser ehrfurchtgebietenden Superlativa drängt sich eine Frage auf, die ich in den vergangenen Monaten immer wieder gehört habe: “Warum wird die Campus-Software von der WU selbst und nicht von professionellen Anbietern entwickelt?”

Eigentlich sind es zwei Fragen, die hier gestellt werden:

  1. Warum greifen wir nicht auf Standard-Software zurück?
  2. Warum wird Individualsoftware nicht durch Externe entwickelt?

Eins vorweg: Natürlich verwenden (und vor allem integrieren) wir Standardsoftware. Softwareentwicklung wird bei uns in den unterschiedlichsten Konstellationen und natürlich auch von Externen durchgeführt. Aber wir entwickeln etwa mit der Raumbuchung, dem automatisiertem Schließsystem oder den digitalen Hörsaalanzeigen viele Kernthemen der IT am Campus aus gutem Grund selbst.

Kabeltassen im Gebäude W1E - hier fließt schon bald unsere Software durch die Leitung.

Um bei einer Metapher des Bauprojekts zu bleiben wirkt es so, als ob wir unsere eigenen Maschinen, unseren eigenen Stahl und unseren eigenen Beton herstellten. Was bei klassisch-produzierenden Unternehmen sich wohl kaum rechnen würde, ist in der Softwareentwicklung allerdings Normalität. Durch den Wegfall von Fixkosten (keine Stahlwerke notwendig) und die de-facto nicht gegebene Standardisierung habe ich bei jedem Teilprojekt die Möglichkeit, eine individuelle make-or-buy Entscheidung zu treffen.

Make or buy?

Für eine Eigenerstellung sprechen jedenfalls die Kosten: Um Urlaubs- und Fehlzeiten bereinigte Stundensätze interner Entwickler betragen rund ein Drittel jener von Externen. Dass bei Dienstleistern und Softwarehäusern ständig die richtigen Experten abrufbereit säßen, ist ein leider allzu weit verbreiteter Irrglaube. Hüben wie drüben muss man Einarbeitungszeiten, Schulungen und Irrwege letztlich bezahlen.

Kommunikation unter Kollegen ist jedenfalls einfacher, als Projektmanagement zwischen Unternehmen. Mit Pflichten- und Lastenheften, die Sales oder Legal jedoch nicht den Entwicklern dienen, mit juristischen Prozessen rund um Beschaffung oder service level agreements, mit Excel-bewaffneten Consultants, die eine zusätzliche Abstraktionsschicht zwischen Anforderung und Umsetzung einziehen, entwickeln sich IT-Projekte sehr schnell zu bürokratischen Meeting-Marathons. Auf diesem Weg entstandene Software tut am Ende oft ganz anderes, als es die Prozessdokumentation sagt, und die Kosten stehen schließlich in zweifelhaftem Verhältnis zum Ergebnis. Ich habe mehrfach die paradoxe Situation erlebt, dass ein schneller, interner Hack bereits fertig war, bevor noch ein Kick-Off stattfand. (…)

Gleichzeitig gibt es allerdings eine Reihe an IT-nahen Dienstleistungen, die sehr gut ausgelagert werden können: Betrieb von Hardware, Grafik-Design oder Dateneingabe sind Beispiele, wo ich kaum überlegen würde.

Immer wenn die technischen Anforderungen entweder niedrig oder extrem hoch sind, jedenfalls  aber wirklich nur wenn die Anforderungen der Benutzer klar sind, dann zahlt sich Outsourcing aus.

Denn dann sind Leistungen überschaubar und somit Preise verhandelbar, und man profitiert vom Spezialwissen der Experten. (Das Stacey Diagramm lässt sich also womöglich auch für make-or-buy Entscheidungen vergewaltigen.)

Die Standarsoft-Mär

Wäre die Diskussion über die Vorteile interner und externer Individualentwicklung nicht ohnehin hinfällig, würde man von vornherein auf Standardsoftware setzen? Nun, vieles, was bei Individualentwicklung zum Einsatz kommt, ist ohnehin standardisierte Software in Form von Betriebssystemen, Datenbanken, Frameworks und Libraries. Software zu entwickeln bedeutet zu einem großen Teil, derartig generell-anwendbare Bausteine zu einem individuell-leistungsfähigen System zu kombinieren.

Gleichzeitig ist vieles, was Standardsoftware heißt, fernab von Standardisierung, wie man sich das etwa bei einem Auto vom Fließband vorstellt. Auch wenn Banken, Airlines oder eben Universitäten Software der Big Player einsetzen, so passiert bei der Integration ins Unternehmen zwangsweise immer wieder dasselbe: Früher oder später enden die Möglichkeiten des Customizing, und Berater, Sub-Firmen oder interne Entwickler schreiben spezialisierte Programme, um das Ding zum Laufen zu bringen. Das bedeutet aber auch, dass die Abhängigkeit von einzelnen Personen auch bei Standardsoftware nicht geringer ist.

Business-IT ohne Abhängigkeit von einzelnen Schlüsselpersonen ist eine Mär!

Mit steigender Komplexität der Anforderungen wird es also zunehmend unwahrscheinlich, dass ein Anbieter genau das erfüllt, was ein ein Unternehmen benötigt. Das Resultat heißt bei Standardsoftware dann erst wieder Individualentwicklung.

Indien - Land der IT-Hotlines und heiligen Kühe. Mathias, Mumbai 2012.

Und hier schließt sich der Kreis, zu den oben gestellten Fragen. Ich genieße jetzt mal meine Tage in Indien – übrigens ein Land, wo mein Job aus genannten Gründen doch nicht so schnell hinwandern wird…

IT project management

Checklist Softwareauswahl

Knappe eineinhalb Jahre vor Inbetriebnahme des Campus WU werden aktuell zahlreiche Softwareprodukte unterschiedlicher Größe beschafft. Software ist durch ihre nicht überschaubaren Anwendungsmöglichkeiten komplex, die Auswahl des richtigen Produkts daher keine triviale Aufgabe.

Im Zuge der Beschaffung eines Geoinformationssystems (GIS) fand allerdings ein Bilderbuchbeispiel für einen strukturierten Entscheidungsprozess seinen Weg bis zur Vertragsunterzeichnung; ein Beispiel, das ich in abstrakter Form hier gerne teile.

Ausgangspunkt

Wir kaufen also Unternehmens-Software: Diese ist im Jahr 2012 beinahe immer webbasiert, oder zumindest in einer three tier architecture umgesetzt. Das Unternehmen möchte die Gesamtkosten (total cost of ownership) minimieren, dabei aber dennoch eine ausreichend gute Software einführen.

Im Studium lernte ich die Nutzwertanalyse als Werkzeug bei derartigen Entscheidungsprozessen kennen. Als ich sie vor Jahren zum ersten Mal anwenden wollte, erlebte ich allerdings zahlreiche Probleme: Die Punktevergabe samt Gewichtung gaukelt ein genaueres, transparenteres Ergebnis vor, als es tatsächlich ist. Gewichtungen werden oft auch noch nachträglich verändert. Die Betriebswirtschaftslehre nennt das Sensitivitätsanalyse, in der Praxis ist das eher ein Hintricksen zum gewünschten Ergebnis.

Was ich an Methoden agilen Projektmanagements mag, ist weniger die Fähigkeit, Prozesse vielleicht besser steuern zu können, sondern die im Lieferumfang enthaltene Transparenz mit der Unsicherheit und Ungenauigkeit nach außen hin als solche deklariert werden.

Soll heißen: Ich präsentiere hier eine absichtlich zur Checklist verkommene Nutzwertanalyse, weil jedes mehr an Datenpunkten, lediglich mehr Zahlenspiel als sinnvolle Entscheidungsgrundlage bedeutet. Anstatt Punkten und Gewichtungen treten nur noch drei Zustände: KO, entscheidend, relevant. Während KO als Filter zu sehen ist, sind die beiden letzteren rein qualitative Aussagen: “Dieses Kriterium ist entscheidend und Anbieter A ist da wohl ein wenig besser” – mehr ist nicht möglich.

Nutzwertanalyse “light”

Zuerst zur Software selbst
  1. Erfüllt die Software alle meine mir jetzt bekannten Anforderungen? Gibt es zumutbare Workarounds für fehlende Anforderungen?
    (KO-Kriterium)
  2. Kann die Software deutlich mehr, als ich es will? Paradox: Je mehr unnötige Funktionalität geboten wird, desto schlechter!
    (siehe: Complexity kills!, entscheidend)
  3. Können alle künftigen Endanwender den Client verwenden oder gibt es Einschränkungen bei Browserversionen und/oder Betriebssystemen? Gilt dies auch noch künftig in meinem Unternehmen?
    (KO-Kriterium)
  4. Falls ein mobiles Szenario existiert: Ist der Service mobil nutzbar?
    (relevant)
  5. Ist eine zentrale Authentisierung (Login mit unternehmensweitem Passwort) möglich?
    (KO-Kriterium)
  6. Ist eine zentrale Autorisierung (Übernahme zentral gepflegter Berechtigungen) möglich?
    (relevant)
  7. Falls ein älteres System abgelöst wird: Können Daten übernommen werden?
    (entscheidend)
  8. Wie schätze ich die wirtschaftliche Situation des Anbieters ein? Wird es ihn in fünf Jahren noch geben? Ist sein angebotenes Produkt für ihn selbst wichtig oder wird mir ein Auslaufmodell angeboten? (Product Roadmap) Wie stark ist letztlich meine Abhängigkeit?
    (entscheidend)
    ODER
    Handelt es sich um Open-Source Software? Gibt es andere Anbieter, die auf Basis dieser Software Dienstleistungen anbieten?
    (relevant. Das bedeutet, dass dieser Punkt im Falle von OSS weniger Tragweite erhält.)
  9. Liegen die Daten in einem lesbaren Format vor, oder sind sie im System des Anbieters gefangen?
    (entscheidend)
  10. Kann ich das System (notfalls) selbst administrieren? Gibt es ausreichend Angebote für Dienstleistungen (Beratung, Support, Administration), wenn möglich auch von anderen Anbietern?
    (entscheidend)
  11. Gibt es Referenzen? Habe ich Erfahrung von anderen Installationen des Anbieters in meiner Branche? Welches Feedback ergibt eine Netz-Recherche?
    (relevant)
  12. Was sagen meine Endanwender? Hat Ihnen die Produktpräsentation gefallen? Gefällt ihnen die Software?
    (arrogant, aber: beinahe irrelevant)
  13. Bietet das System offene Schnittstellen für Daten und/oder Automatisierung?
    (entscheidend)
  14. Erfüllt das System meine Sicherheitsanforderungen hinsichtlich Architektur, Datenhaltung, Verschlüsselung, usw.? Ist das Angebot “in der Cloud” bzw. gebe ich unternehmenskritische oder datenschutzrechtlich sensible Daten in fremde Hände?
    (KO-Kriterium)
  15. Darf ich das System in dieser Form einsetzen, oder spricht geltendes Datenschutz-Recht dagegen? Besitze ich eine Meldung beim DVR oder ist gar mit einer Ablehnung zu rechnen?
    (realistischerweise lediglich relevant)
  16. Passt die vom Anbieter vorgeschlagene Vorgehensweise bei der Einführung zu Kultur und Ressourcen meines Unternehmens? Sind etwa Schulungen zeitlich möglich? Wissen alle Stakeholder überhaupt von ihren künftigen Rollen?
    (relevant)

Man sieht, in meiner Auflistung fehlen zentrale Punkte, die normalerweise (stärker) repräsentiert sind. Dazu zählen etwa die Zufriedenheit der Nutzer oder die technische Ausgereiftheit des Produkts.

Bei einer Produktpräsentation etwa bewerten Endanwender eher die sympathische Art des Beraters, nicht aber das Produkt selbst. Bewerten sie in Ausnahmesituationen doch die Software anstatt der Powerpoint-Präsentation, lassen sie sich vom GUI blenden und schaffen es de facto nie, das Gezeigte zu abstrahieren und in ihre Arbeitswelt zu überführen.

Doch auch IT-Spezialisten sind schlecht im Bewerten: In zehn Jahren IT habe ich festgestellt, dass in Systeme nicht hineingesehen werden kann. Die traurige Nachricht lautet, dass man alle Probleme am eigenen Leib erleben wird, bevor man sie mühsam lösen muss. Dabei gibt es kaum Unterschiede zwischen Open Source und kommerzieller Software: Bei ersterer ist tendenziell mehr Expertenwissen bei der Problemlösung vonnöten – bei höheren Erfolgsaussichten -, bei zweiterer sind zeitlicher Aufwand (Support-Hotline!) und monetärer Einsatz (Beratertage) weitaus größer.

Den Reifegrad einer Software anhand des Namedroppings von Programmiersprachen, Protokollen, Datenbanksystemen, Dateiformaten, usw. feststellen zu wollen, ist blanker Unsinn. Verwendete Technologie und Qualität korrelieren äußerst schwach. Die Eckpunkte von Softwarequalität lauten Entwicklungsprozess, automatisiertes Testen, Sourcecodemanagement, Erfahrung & Motivation, … – alles Dinge, die von außen gänzlich unsichtbar sind.

… und dann das Geld

Nun zu den Kosten: Diese sind bei Hardware und Lizenzen zwar noch vergleichbar, aber oft stellen Schulungen, Beratungsleistungen, Support u.ä. ein großes Problem dar. Veranschlagt ein Anbieter etwa das Doppelte für Beratungsleistung, kann es gleich mehrere Gründe dafür geben: Das System ist schwieriger einzuführen, die Berater sind teurer, der Anbieter ist vorsichtiger bezüglich des Projektfortschritts, usw.

Ein möglicher Ausweg ist die Aufschlüsselung der Kosten in angebotene Gesamtstunden und Stundensatz. Der Median der angebotenen Stunden (über alle Angebote hinweg) ist zunächst die beste Näherung für den Aufwand. Mit dem jeweiligem Stundensatz multipliziert kommt man so zu normierten Angeboten hinsichtlich der Dienstleistungen.

Diese so errechneten (fiktiven!) Angebote sollten Basis eines Preisvergleichs sein.

Eine Pattstellung zwischen zwei Anbietern ist aufgrund der bestehenden Unsicherheit nach wie vor äußerst wahrscheinlich. Möglicher Ausweg hier: Beauftragung beider Anbieter mit einer in maximal acht Wochen durchführbaren Pilotphase bei voller Transparenz des Modus und fairen Bedingungen.

Diese Vorgehensweise stellt die beiden Anbieter in direkten Wettbewerb. Man kann davon ausgehen, dass die “Motivation” auf beiden Seiten hoch sein wird. Auch im nachfolgenden (Groß-)Projekt – wenn dann die Auswahl letztlich getroffen ist – kann das Ergebnis der Pilotphase als Qualitätsreferenz dienen. (Der Anbieter legt sich selbst eine hohe Latte.)

Während die Methode bei kleineren Beauftragungen übertrieben scheint, stellt sie bei wichtigen Projekten eine probate Möglichkeit dar, Entscheidungsunsicherheit tatsächlich zu reduzieren.

IT project management

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!