Tag Archives: Scrum

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…

ideas

Gegenseitige Personalevaluierung

Im Rahmen der Vertiefung IT-Systeme des Studiengangs Personal- und Wissensmanagement der FH-Wien durften sich “meine” Studierenden Gedanken zu einer fiktiven Software zur Personalbeurteilung machen. Das Tool wurde agil nach Scrum “entwickelt”.

Die Storyline dazu: In einer Welt mit immer weniger Fließband- aber immer mehr “Wissensarbeitern” ist die Evaluierung der Arbeitsleistung deutlich schwieriger geworden. Ein gegenseitiges Evaluieren unter KollegInnen könnte hier einen Beitrag leisten…

Spielregeln des Tools leicht verständlich visualisiert

“Mitarbeiter können sich über das Bewertungsschema anhand einer leicht verständlichen Grafik informieren.”


KollegInnen bewerten KollegInnen

“Wir befinden uns in der Beurteilungsmaske für einen Kollegen – der entsprechend zutreffende Satz (= eine Kompetenz) wird ausgewählt, im Hintergrund findet die Zuordnung zu Sozial-, Fach- und Methodenkompetenz statt. Unter dem Button „Rules&Regulations“ sind der Ablauf der Bewertung dargestellt sowie die Regeln des Systems abgebildet.”


Auswertung pro Mitarbeiter nach Kompetenzfeldern

“In dieser Maske sind die Beurteilungen, die für einen selbst abgegeben wurden, zu sehen. Bei Mouseover erscheint der, der jeweiligen Kompetenz zugeordnete, Satz. Der Mitarbeiter hat hier die Möglichkeit, via Button zurück zu seiner persönlichen Startseite („Zum eigenen Cockpit“) oder zur Beurteilung eines Kollegen („Beurteilung Kolleg/innen“) zu gelangen.”


Die gegenseitigen Bewertungen werden für Führungskräfte nach Kompetenzen gegliedert ersichtlich

“Führungskräfte haben Zugriff auf die Netzwerkanalyse. Die unterschiedlichen Farben stellen die Ausprägung der jeweiligen Kompetenzen pro Mitarbeiter dar, die Pfeile zeigen, wer wen und welche Kompetenz der Person beurteilt hat. Je dicker die Linie des Pfeils, desto häufiger wurde diese Kompetenz gewählt.”


Aggregation auf das gesamte Unternehmen

“Die Unternehmensleitung hat die Möglichkeit, auf die Netzwerkanalyse der gesamten Organisation zuzugreifen.”


Vielen Dank an:

  • Veronika Fritzsche
  • Alfred Hribar
  • Erika Reisenegger (Scrum Master)
  • Katja
  • Marianne Wagner
  • Marlies Zisser
ideas

Usability Redesign von HR Systemen

HR-Systeme waren mitunter der Raketentreibstoff im Siegeszug der elektronischen Datenverarbeitung. Aber das ist nun auch schon eine Weile her. Dieses Alter gepaart mit der Komplexität der Materie resultiert in inzwischen nicht mehr ganz so guten User Interfaces.

“Meine” Studierenden der FH-Wien sind daher angetreten, die Welt vor allzu schlimmen UIs zu retten:

Probleme beim aktuellen System

Eine dieser Rettungsaktionen befasste sich mit einem Management Information System (MIS) einer österreichischen Großbank. Führungskräfte haben hier aktuellen Überblick über 30+ MitarbeiterInnen. Dass das Ding nicht besonders übersichtlich ist, muss man wohl nicht noch anführen…


Auf Papier entsteht ein neuer Vorschlag

Auf Papier wurde begonnen an einer verbesserten Version zu arbeiten. Vergleiche zwischen den MitarbeiterInnen oder auch mehrerer Indikatoren gleichzeitig sollten auf einen Blick möglich sein. Die wertvollen Grundstückspreise am Bildschirm sollten optimal genutzt werden.


Die fertige Version 2.0

Der Vorschlag wurde in einen Powerpoint-Mockup überführt, wo man nun viele kleine Features wie Sortierungen, Mouseover-Informationen, etc. erahnen kann.


In SAP werden anscheinend 12 Masken für den Eintritt eines MA benötigt...

Ein anderes Team beschäftigte sich mit den Usability-Wehwehchen typischer Personalabteilungen. Der offensichtlich nicht unübliche Geschäftsfall des Eintritts eines neuen Mitarbeiters bedingt beim Marktführer das Ausfüllen von 12 Masken. Hoher Zeitaufwand und Eingabefehler sind somit garantiert… Der grundlegende Fehler: HR-Systeme orientieren sich an den Tabellen, die im Hintergrund liegen und nicht an den Bedürfnissen jener, die im Vordergrund an den Tastaturen sitzen.


Aus 12 mach' 1!

Die persönlichen Erfahrungen, ein paar Diskussionen und ein, zwei Artikel über Usability später: Die wirklich wichtigen Daten passen in eine Maske. Das Programm muss sich um das Speichern in den Tabellen im Backend kümmern, nicht der User. Detailinformationen lassen sich zusätzlich hinter Overlays oder Slides verstecken.


Ein grafischer Kalender samt Drag & Drop erleichtern die Arbeit

Das Eintippen von Datumsangaben ist besonders bei der Abwesenheitsverwaltung mühsam. Da sich innovative Peripheriegeräte wie PC-Mäuse im Jahr 2011 inzwischen langsam durchsetzen, ist auch hier dringend Abhilfe zu leisten.


Vielen Dank an:

  • Gerda Hartwagner
  • Iris Mechtler
  • Renate Milewski
  • Claudia Retzl (Scrum Master)
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!