Klassisches versus agiles Projektmanagement am Beispiel der Implementierung von IT-Projekten

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung und Relevanz der Arbeit
1.2 Zielsetzung und Gang der Arbeit

2 Grundlagen und Abgrenzung Projektmanagement
2.1 IT-Projektmanagement
2.2 Klassisches Projektmanagement
2.2.1 Grundlagen klassisches Projektmanagement
2.2.2 Klassisches Phasenmodell
2.3 Agiles Projektmanagement
2.3.1 Begriffsdefinition Agilität
2.3.2 Agiles Manifest
2.3.3 Scrum
2.3.3.1 Rollen in Scrum
2.4 Methodenübergreifende Maßnahmen zur Akzeptanzsteigerung
2.4.1 Stakeholderanalyse
2.4.2 Qualitätsmanagement
2.4.3 Einbindung von Key Usern
2.5 Kritische Bewertung der Vorgehensmodelle

3 Experteninterview
3.1 Auswahl der Methodik
3.2 Leitfaden der Befragung
3.3 Auswahl der Interviewpartner
3.4 Durchführung des Interviews
3.5 Auswertung der Experteninterviews
3.6 Ergebnisdarstellung

4 Fazit
4.1 Zusammenfassung
4.2 Empfehlung für die Praxis

Anhang

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Wasserfallmodell für IT-Projekte

Abbildung 2: Die Iterations-Wolken-Metapher

Abbildung 3: Der Scrum-Prozess

Abbildung 4: Aufgaben der Key User im Projektverlauf

Abbildung 5: Bewertung verschiedener Projektmanagementmethoden

Abbildung 6: Vorteile beim Einsatz agiler im Vergleich zu klassischen Methoden

Tabellenverzeichnis

Tabelle 1: Erfolgsquote von IT-Projekten zwischen 2004 und 2015

Tabelle 2: Auszug eines Qualitätsmanagement-Prüfplans

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Problemstellung und Relevanz der Arbeit

Wir befinden uns heute in der Arbeitswelt 4.0, die sich mit hoher Geschwindigkeit weiterentwickelt und sich durch Digitalisierung, weltweite Vernetzung und hohe Flexibilität auszeichnet.^[1] Diese Faktoren tragen für die Unternehmen dazu bei, einem ständigen Kosten- und Veränderungsdruck gegenüberzustehen und passende Maßnahmen ergreifen zu müssen, um Geschäftsprozesse effizienter zu gestalten. Die notwendigen Maßnahmen sind in diesem Zusammenhang meist neue Software und Systeme, die die manuellen Geschäftsprozesse automatisieren und dadurch schneller und weniger fehleranfällig gestalten können. Aufgrund der stetig steigenden Komplexität und hoher Kosten von Entwicklungsvorhaben in der IT-Branche, wird die Umsetzung zumeist in Form eines Projektes durchgeführt. Das Projektmanagement soll als Führungskonzept dabei helfen, die vielfältigen Aufgaben bei einer IT-Neuentwicklung durch einen Projektmanager koordiniert, funktions- und abteilungsübergreifend durchzuführen und dabei auch Kosten-, Termin- und Qualitätsparameter zu planen und zu kontrollieren. Durch die stetige Überprüfung der Entwicklungsvorgaben, des Durchführungszeitraumes und der Kosten soll sichergestellt werden, dass ein definiertes Projektende eingehalten werden kann und somit zu einem abgestimmten Zeitpunkt die gemäß den Vorgaben fertige Entwicklung vorliegt und in den laufenden Betrieb übergeben werden kann.^[2]

Der Einsatz von Projektmanagement für die Durchführung solcher Vorhaben ist allerdings kein Garant für die erfolgreiche Implementierung. Eine Studie der Standish Group hat ergeben, dass nur ca. 40 % aller IT-Projekte erfolgreich abgeschlossen werden.^[3] Die erste Frage, die sich dazu im Rahmen dieser Arbeit ergibt ist die, ob der Erfolg eines Projektes abhängig von der angewandten Projektmanagementmethode ist. In der Literatur wird der Projektabschluss oftmals nur oberflächlich behandelt oder gar vernachlässigt.^[4] In dieser Phase des Projektes wird aber das neue System oder die neue Software an die zukünftigen Anwender übergeben, deren Arbeitsweise davon direkt betroffen ist. An dieser Stelle im Projekt, erfolgt der formale Abschluss und die neue Technik geht in den laufenden Betrieb über. Hier entscheidet sich, ob sich der Aufwand und die Investition gelohnt haben und die Anwender die neue Technik auch nutzen. Ein erfolgreiches Projekt ist also eines, das sowohl die vereinbarten Qualitätsmerkmale erfüllt, als auch die Akzeptanz der Anwender erreicht hat.^[5] Hieraus ergibt sich die zweite Frage, die im Rahmen dieser Arbeit beantwortet werden soll: Wie kann die Akzeptanz der Anwender als wesentlicher Erfolgsfaktor eines IT-Projektes für die Implementierung der Neuentwicklung erhöht und sichergestellt werden.

Im IT-Umfeld, vor allem in der Softwareentwicklung, haben sich zwei Projektmanagementmethoden etabliert, die in dieser Arbeit für die Beantwortung der im folgenden Kapitel formulierten Forschungsfragen näher betrachtet werden. Es handelt sich dabei um das klassische Wasserfallmodell und den agilen Scrum-Ansatz.^[6]

Das Wasserfallmodell wurde in seinem Ursprung erstmals 1970 durch Winston W. Royce beschrieben und seitdem stetig weiterentwickelt. Der Name dieses Modells wurde erst 11 Jahre später durch den Software-Ingenieur Barry W. Boehm geprägt und basiert auf dem grafisch dargestellten Ablauf des Modells, da die Ergebnisse einer Phase wie bei einem Wasserfall in die darauffolgende Phase „fallen“ und ein Rücksprung in eine vorherige Phase nur in Ausnahmen möglich ist, wenn Resultate fehlerhaft sind und korrigiert werden müssen.^[7]

Für die immer komplexer gewordene Softwareentwicklung stieß dieses Modell allerdings irgendwann an seine Grenzen, wodurch neue Methoden entwickelt wurden, die die Schwächen des Wasserfallmodells ausräumen sollten. Eine dieser Methoden ist Scrum. Auf Basis ihres agilen Manifests, welches sie gemeinsam mit anderen IT-Projektleitern zur Arbeitsweise in IT-Projekten verfassten, haben Schwaber und Sutherland diese Methode zu Beginn der 1990er Jahre entwickelt. Ihr Ziel war es, Softwareentwicklungen schneller durchzuführen und Veränderungen gegenüber flexibler zu sein. Dabei legten sie, im Gegensatz zu den klassischen Methoden, besonderen Wert auf den Anwendernutzen.^[8]

Wie bereits erwähnt, ist ein Erfolgsfaktor für IT-Projekte die Akzeptanz der Anwender, die sich nur dann entwickelt, wenn die Anwender in dem Vorhaben den Mehrwert für ihre tägliche Arbeit erkennen. Dieser Aspekt ist vor allem in IT-Projekten aber eine große Herausforderung. Der Grund dafür ist die ureigene Branchenmentalität der Informationstechnologie. Gerade in Bezug auf die Anwender, deren Fokus in der Betriebswirtschaftslehre und nicht in der Informationstechnologie liegt, bilden vor allem die Sprachwelten eine große Kluft zwischen den Mitarbeitern der beiden Branchen. Denn die Beschreibung der notwendigen Funktionalitäten für die Geschäftsprozesse durch die Anwender deckt sich oftmals nicht mit den Fachbegriffen und Lösungsansätzen der Entwickler. Trotzdem muss am Ende des Projektes ein Ergebnis geschaffen worden sein, welches das betrieblich Notwendige mit dem technologisch Möglichen verbindet. Der Schmerzpunkt liegt dabei immer auf der Seite der Anwender, denn die Digitalisierung und Automatisierung der Prozesse greift geradewegs in deren Arbeitswelt ein. Dadurch wird die zwischenmenschliche Zusammenarbeit zu einem erheblichen Erfolgsfaktor in IT-Projekten, der in anderen Projekten, wie dem Bau einer Anlage oder einer Produktentwicklung, nicht besteht.

1.2 Zielsetzung und Gang der Arbeit

Das Ziel dieser Arbeit ist es daher, zu untersuchen, welche Möglichkeiten die weit verbreiteten und über Jahrzehnte gewachsenen klassischen Projektmanagementmethoden und im Vergleich dazu die vor allem in der IT-Branche immer populärer werdenden agilen Projektmanagementmethoden bieten, um ein Projekt nicht nur gemäß der Vorgaben abzuschließen, sondern auch dem Endanwender ein nutzensteigerndes und vor allem durch ihn akzeptiertes IT-Produkt zur Verfügung zu stellen und somit ein ganzheitlich erfolgreiches Projekt durchzuführen.

Die Literatur hat sich bereits umfänglich mit den diversen Methoden und Werkzeugen des Projektmanagements befasst.^[9] Ebenfalls wurden Studien zu der Erfolgsquote agil und klassisch durchgeführter IT-Projekte durchgeführt.^[10] Jedoch findet die Thematik des Projektabschlusses und der Implementierung von IT-Projekten in Bezug auf die Anwender, deren Arbeitswelt durch die Projekte verändert wird, nur wenig Berücksichtigung.

Ausgehend von der im vorherigen Kapitel skizzierten Problemstellung soll in der vorliegenden Arbeit die folgende Forschungsfrage beantwortet werden:

„Wie kann die Anwenderakzeptanz im Rahmen der Implementierung eines IT-Projektes durch Maßnahmen klassischer und agiler Projektmanagementmethoden gesteigert werden?“

Zur Beantwortung der Forschungsfrage werden im Verlauf dieser Arbeit verschiedene wissenschaftliche Methoden herangezogen.

Im zweiten Kapitel werden das klassische und agile Projektmanagement anhand einschlägiger Literatur beschrieben. Dazu wird im ersten Schritt das IT-Projektmanagement zu anderen Projektarten abgegrenzt und die Besonderheiten der IT-Umwelt für das Verhältnis zwischen Projektteam und Endanwendern herausgestellt. Anschließend erfolgt eine Beschreibung des klassischen Projektmanagements anhand des Wasserfall-/Phasenmodells und des agilen Projektmanagements anhand des Scrum-Modells. Darüber hinaus werden Maßnahmen zur Anwendereinbindung und Akzeptanzsteigerung vorgestellt, die methodenübergreifend angewandt werden können. Den Abschluss des Kapitels bildet eine kritische Bewertung der klassischen und agilen Methoden in Bezug auf die Forschungsfrage und die Aufstellung einer Hypothese, die mithilfe der Ergebnisse des dritten Kapitels validiert wird.

Das dritte Kapitel enthält die Prüfung der theoretischen Ergebnisse anhand von praktischen Erfahrungswerten aus Experteninterviews. Zuerst wird die Herangehensweise an die qualitativ empirische Forschung durch ein leitfadengestütztes Experteninterview beschrieben. Dies enthält die Beschreibung der Forschungsmethode sowie den Auswahlprozess und eine Kurzbeschreibung der befragten Experten. Daraufhin werden die Ergebnisse der Experteninterviews zusammengefasst und dabei die Erfahrungen, Vorgehensweisen und Lösungsansätze der Experten gegenübergestellt.

Abschließend werden die Ergebnisse aus Theorie und Praxis im fünften Kapitel dieser Arbeit zur Beantwortung der Forschungsfrage zusammengefasst und bewertet. Das Kapitel gibt zudem einen Ausblick auf die zukünftigen Handlungsfelder im Rahmen des klassischen und agilen Projektmanagements für die Praxis.

2 Grundlagen und Abgrenzung Projektmanagement

2.1 IT-Projektmanagement

Unter IT-Projekten lassen sich alle Vorhaben zusammenfassen, die die allgemeinen Eigenschaften eines Projektes erfüllen^[11] und sich mit der Entwicklung von Informations- und Kommunikationssystemen befassen. Zudem lassen sich IT-Projekte in verschiedene Arten unterteilen: Ungefähr die Hälfte aller IT-Projekte hat das Ziel, individuelle IT-Anwendungssysteme zu entwickeln. Die andere Hälfte entfällt auf die Implementierung von Standard-Anwendungssoftware und die Automatisierung von Geschäftsprozessen.^[12]

Die Standish Group International Inc. hat seit 1994 über 50.000 beendete Projekte analysiert und deren Resultate in die Kategorien „erfolgreich“, „gefährdet“ und „gescheitert“ unterteilt (s. Tabelle 1). Als erfolgreich gelten in dieser Studie alle Projekte, deren Eigenschaften gemäß ursprünglicher Spezifikation im vereinbarten Zeit- und Kostenrahmen umgesetzt wurden. Gefährdete Projekte sind solche, die mit einem funktionsfähigen Ergebnis beendet wurden, allerdings der Zeit- oder Kostenrahmen überschritten wurde oder die Funktionalitäten und Eigenschaften nicht der Spezifikation entsprechen. Gescheiterte Projekte wurden noch vor Erreichung der Projektziele abgebrochen. Die Ergebnisse der Studie werden seit 1994 regelmäßig im sogenannten Chaos Report veröffentlicht. Es wird deutlich, dass im Durchschnitt ca. 30 % der IT-Projekte erfolgreich abgeschlossen werden, ungefähr 50 % gefährdet sind, die Rahmenbedingungen nicht erfüllen zu können und ca. 20 % abgebrochen werden.^[13]

Tabelle 1: Erfolgsquote von IT-Projekten zwischen 2004 und 2015

Abbildung in dieser Leseprobe nicht enthalten

Quelle: entnommen aus The Standish Group (2013), S. 1 und Hastie, S; Wojewoda, S. (2015), o. S.

Hinsichtlich der Tatsache, dass ein Projekt für ein Unternehmen immer auch eine Investition bedeutet, muss sichergestellt werden, dass sich diese Investition rentiert. Die Rendite erfolgt bspw. in Form von Umsatzsteigerung oder erhöhter Effizienz der Geschäftsprozesse. Um letztere durch IT-Projekte zu erreichen, muss sichergestellt werden, dass das Projektergebnis den Anforderungen der zukünftigen Anwender entspricht und diese die neu entwickelte Software akzeptieren und nutzen.^[14]

Projekterfolg kann somit in der Formel „Erfolg = Qualität * Akzeptanz“ zusammengefasst werden. Denn ein gutes Projekt, welches seine Ziele in der vorgegebenen Qualität sowie Zeit- und Aufwandsplanung erreicht hat, ist nicht erfolgreich, wenn es von den Anwendern im täglichen Betrieb nicht eingesetzt wird.^[15]

Der Chaos Report 2014 der Standish Group International Inc. hat diesbezüglich ergeben, dass IT-Projekte erfolgreicher sind, wenn Anwender regelmäßig in den Entwicklungsprozess einbezogen werden, Erwartungen realistisch sind und kleinere aber dafür häufigere Meilensteine im Projekt geplant sind.^[16] Denn eine regelmäßige Einbindung und Information der Anwender über das Projektvorhaben fördert einerseits das Verständnis und andererseits kann die Interaktion sicherstellen, dass das Projekt auch die für die Anwender richtigen Funktionen hervorbringt. Dies kann letztendlich zu einer größeren Akzeptanz der Anwender und somit zum Erfolg des Projektes führen.

Ein Unterschied zwischen IT-Projekten und allen anders gearteten Projekten ist der, dass in IT-Projekten Kosten und Aufwand schwer zu schätzen sind, da das Ziel oftmals eine neue Software oder ein neues System ist, für welches keine Erfahrungswerte vorliegen. Diese Unsicherheit kann zwar zu Beginn des Projektes durch Hinzuziehen interner und externer Experten auf ein akzeptables Maß reduziert werden, doch kommt es in IT-Projekten häufig vor, dass sich die Kosten und der Aufwand im Laufe des Projektes bedingt durch neue oder veränderte Einflussfaktoren erheblich ändern. Die Neuartigkeit der Systeme und Tools ist gleichzeitig auch die Ursache für die Hauptherausforderung von IT-Projekten. Diese liegt darin, die Differenz zwischen der IT und den Anwendern zu überwinden. Die Differenz entsteht dadurch, dass mit der Digitalisierung von Geschäftsprozessen direkt in die Arbeitsweise der Anwender eingegriffen wird, für die der Grund für die Veränderung nicht nachvollziehbar ist, weil sie ihre Arbeit bisher auch erfolgreich durchgeführt haben und somit die Akzeptanz für die Neuentwicklung fehlt. Aufgrund der direkten Betroffenheit der Anwender ist es somit umso wichtiger, die Barrieren zwischen den beiden Welten auszuräumen.^[17]

Huber und Kuhnt (2007) sehen darüber hinaus den Umgang mit Informationen und Wissen sowie die Zusammenarbeit und Kooperation nicht nur innerhalb des Projektteams und mit den Anwendern, sondern auch mit den Stakeholdern der Bereiche Human Resources, Information Technology, Organisationsentwicklung und den allgemeinen Business Requirements als zentrale Erfolgsfaktoren für IT-Projekte an.^[18] Diese werden der Vollständigkeit halber ebenfalls erwähnt, stehen aber vordergründig nicht im Fokus dieser Arbeit.

Welche Möglichkeiten das klassische und agile Projektmanagement bieten, um das Erreichen einer möglichst hohen Akzeptanz sicherzustellen und welche Vorgehensweisen geeignet sind, um die Ergebnisse eines erfolgreichen Projektes in den Fachbereichen der Anwender zu implementieren, wird in den folgenden Kapiteln erörtert.

2.2 Klassisches Projektmanagement

2.2.1 Grundlagen klassisches Projektmanagement

Das klassische Projektmanagement zeichnet sich durch ein Vorgehen nach dem Phasenmodell aus. Eine Projektphase ist dabei ein zeitlich festgelegter Abschnitt, der sich sachlich von den Inhalten und Aufgaben der anderen Phasen unterscheidet, getrennt davon abläuft und mit einem Meilenstein beendet wird. Erst wenn ein Meilenstein abgenommen wurde, darf die nächste Phase begonnen werden. Ein Meilenstein bedeutet immer einen Einschnitt in das Projekt, zu dem vordefinierte Ergebnisse vorliegen müssen.^[19] Für die Entscheidung über die Abnahme eines Meilensteins wird der Lenkungskreis des Projektes einberufen. Der Lenkungskreis ist ein dem Projekt übergeordnetes Entscheidungs- und Eskalationsgremium. Er setzt sich aus Vertretern des Auftraggebers und des Auftragnehmers zusammen.^[20] Nach Vorstellung des Projektstatus zum Zeitpunkt der Erreichung des Meilensteins entscheidet der Lenkungskreis darüber, ob das Projekt mit der nächsten Phase fortgesetzt wird, Ergebnisse für die Abnahme des Meilensteins noch überarbeitet oder nachgeliefert werden müssen oder ob das Projekt abgebrochen wird.^[21] Durch diese Vorgehensweise des Prüfens und Rückkoppelns hat sich das wohl bekannteste Phasenmodell, das Wasserfallmodell, entwickelt. Grafisch dargestellt, ergibt sich nämlich eine wasserfallähnliche Projektstruktur (s. Abbildung 1).^[22]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Wasserfallmodell für IT-Projekte

Quelle: in Anlehnung an Jenny, B. (2009), S. 59, Zell, H. (2010), S. 23 und Olfert, K. (2012), S. 82.

Das Grobschema klassischer Phasenmodelle lässt sich auf die Phasen Initiierung, Konzeption, Realisierung, Einführung und Nachlauf/Nutzung herunterbrechen (s. Abbildung 1), die im folgenden Kapitel detailliert beschrieben werden.^[23]

2.2.2 Klassisches Phasenmodell

Initiierungsphase: Im klassischen Projektmanagement stellt die Initiierungsphase eine der wichtigsten Phasen dar, da die hier aufgenommenen Informationen und getroffenen Absprachen die Grundlage weiteren Projektverlaufs darstellen. Die Hauptaufgaben dieser Phase sind die Aufnahme und Analyse der Anforderungen des Auftraggebers für das neue Produkt in Form des Projektauftrages oder auch Scope genannt, die Entwicklung möglicher Lösungsalternativen^[24] sowie die Festlegung auf eine dieser Alternativen sowie die Durchführung des Projekt-Kickoffs^[25].

Die Anforderungen des Auftraggebers stellen dabei die Abweichung vom aktuellen Ist-Zustand zum gewünschten Soll-Zustand dar.^[26] Diese Anforderungen können in einem Anforderungskatalog dokumentiert werden, der durch oder gemeinsam mit dem Auftraggeber erstellt wird und grobe Eckdaten zum angestrebten Ziel enthält. In diesem Schritt sollten die Anforderungen bereits in Muss-, Soll- und Kann-Anforderungen unterteilt werden. Auf Basis dieses Kataloges wird anschließend ein Pflichtenheft erstellt. Es beschreibt erste fachliche Vorstellungen zum Projektziel. Bei einem IT-Projekt wären diese beispielsweise Angaben zu den Funktionalitäten der Software, zu den Datei-Inputs und -outputs, Schnittstellen zu anderen Systemen und zu benötigter Hard- und Betriebssoftware.^[27]

Auf Basis der initialen Informationszusammentragung bei der Erarbeitung des Anforderungskataloges und des Pflichtenheftes gilt es in einem nächsten Schritt den Projektauftrag zu definieren. Dieser enthält, über die Beschreibung der Ausgangs- und Problemlage sowie der groben Projektziele hinaus, Angaben über die Beschreibung des Kundennutzens bspw. in Form eines Business Cases, den Umsetzungszeitraum inklusive der wichtigsten Meilensteine, eine erste grobe Kostenschätzung auf Basis der bis dato vorliegenden Informationen sowie die Beschreibung der bekannten Risiken. Diese Eckdaten des Projektes werden in einem Projektauftrag oder Scope-Dokument (s. Anhang A) festgehalten und dem Auftraggeber zur Abnahme vorgelegt. Durch die Unterschrift des Auftraggebers kann der Projektleiter sicherstellen, dass eine Übereinstimmung bezüglich der wichtigsten Projekteckpfeiler vorliegt und somit der Rahmen des Vorhabens festgelegt ist.^[28]

Sollte also im weiteren Verlauf des Projektes durch den Projektauftraggeber oder den Projektleiter festgestellt werden, dass sich die zeitlichen, monetären oder sozialen Rahmenbedingungen des Projektes verschieben, muss ein entsprechender Change Request erstellt werden, um den Scope des Projektes dahingehend anzupassen. Ein solcher Change Request muss wiederum durch den Lenkungskreis freigegeben werden, sodass auch an dieser Stelle alle beteiligten Personen der Auftraggeber- und Auftragnehmerseite eingebunden und informiert sind und sich gemeinsam auf eine Neuvereinbarung des Projektauftrages einigen.^[29]

Der letzte Schritt in der Initiierungsphase eines Projektes stellt der Kickoff dar. An diesem nehmen die wichtigsten Stakeholder des Projektes teil. Neben dem Projektleiter, dem Auftraggeber und den Teilprojektleitern können je nach Projektziel auch Vertreter des Betriebsrates, zukünftige Anwender oder Datenschutzbeauftragte zum Kickoff-Meeting eingeladen werden.^[30] Grund für diesen Teilnehmerkreis ist der Informationszweck eines solchen Meetings: Präsentation der vorab ausgearbeiteten Projektziele, Vorstellung der Projektorganisation und Rolle der Projektteammitglieder, Grobplanung des Projektes mit den wichtigsten Meilensteine sowie Klärung der Erwartungshaltung der Stakeholder inklusive deren bekannter Rahmenbedingungen, Erfolgsfaktoren und Risiken.^[31]

Konzeptionsphase: Der unterschriebene Projektauftrag stellt den Meilenstein zum Abschluss der Initiierungs- und Beginn der Konzeptionsphase dar. Ziel dieser Phase ist es, eine finale Lösung für den Projektauftrag zu finden und diese detailliert zu beschreiben.^[32]

Die Basis für diese Phase bilden die Lasten- und Pflichtenhefte der Initiierungsphase des Projektes, die zu dieser frühen Phase lediglich grobe Anforderungen enthalten konnten und dementsprechend die grundlegenden Gesamtprojektziele enthielten.^[33] Nun geht es darum, gemeinsam mit Vertretern der relevanten Fachbereiche des Auftraggebers die genauen IST-Zustände zu ermitteln und das SOLL genau zu beschrieben. Dazu zählen Prozesse, Funktionen sowie In- und Outputs. Auf Basis dieser Angaben ist es zum ersten Mal im Projekt möglich, den Aufwand (Zeit und Kosten) genauer abzuschätzen.^[34]

Die möglichen Lösungen werden anschließend anhand einer Kosten-Nutzen-Analyse bewertet und eine dieser Lösungen als finales Konzept für die Realisierungsphase ausgewählt. Auf Basis dieses finalen Konzeptes werden zuletzt Arbeitspakete festgelegt sowie Feinpläne für Tests, Schulungen und die System-Integration erstellt.^[35]

Realisierungsphase: In der Realisierungsphase werden die detaillierten Fachkonzepte durch das Projektteam technisch umgesetzt. Dabei sind weder der Auftraggeber noch zukünftige Anwender aus den Fachbereichen involviert. Der Auftraggeber wird lediglich in regelmäßigen Abständen in einem Statusbericht oder –meeting über den Fertigstellungsgrad des Projektziels sowie Einschätzungen zu den Parametern Zeit und Kosten informiert.^[36]

Die Software an sich sieht der Anwender allerdings bis zum Ende der Realisierungsphase nicht. Denn erst dort ist, wenn das Produkt gemäß Feinkonzept nach Meinung des Projektteams fertig umgesetzt ist, im Wasserfallmodell ein sogenannter Akzeptanztest durch ausgewählte Anwender vorgesehen. Während der Durchführung des Tests wird ein Testprotokoll vorbereitet, welches die testenden Personen chronologisch abarbeiten und dabei Anmerkungen zu den Testergebnissen machen. Sollten während des Tests Fehler in den Funktionalitäten festgestellt werden, müssen diese detailliert dokumentiert und an das Entwicklungsteam gemeldet werden. Dieses analysiert den aufgetretenen Fehler und korrigiert die Entwicklung, bis der Fehler im Akzeptanztest nicht mehr auftritt.^[37]

Laut Szalvay, V. (2014) ist dieser Aspekt des klassischen Projektmanagements für IT-Projekte kritisch zu sehen, da eine abschließende Bestimmung der Anforderungen an eine neue Software vor der Realisierungsphase nicht möglich sei. Denn während der Entwicklung könnte durch regelmäßige Vorstellung der Funktionen durch die Anwender eingegriffen und Fehler sofort erkannt und ausgebessert oder Funktionalitäten angepasst werden. Anwender müssten die Entwicklungen regelmäßig sehen und selbst ausprobieren können, um einzuschätzen, welche Anforderungen sie im Detail an die Neuentwicklung haben.^[38]

Einführungsphase: Diese Phase ist die letzte, bevor das Projektergebnis in den produktiven Betrieb, also in die Nutzung durch die Anwender der Fachbereiche, übergeben wird. Dies ist das primäre Ziel dieser Phase. Hinzu kommen formale Aufgaben wie die Unterzeichnung des Projektabnahmeprotokolls durch den Auftraggeber, das Verfassen des Projektabschlussberichts sowie die Auflösung des Projektteams.^[39]

Um zu erreichen, dass das Projektergebnis sowie das während des Projekts aufgebaute Wissen an die Linie übergeben werden kann, dient ein Erhaltungsplan. In diesem Plan wird dokumentiert, wer in der Nutzungsphase identifizierte notwendige Optimierungen an der Software aufnimmt, wer die Pflege- und Weiterentwicklung verantwortet und wie die Anwenderunterstützung (Hyper Care) in den ersten Wochen der Nutzung der neuen Software ausgestaltet ist. Die Erarbeitung und Abnahme des Erhaltungsplans erfolgt zwischen Auftraggeber und Auftragnehmer.^[40] Darüber hinaus finden Anwenderschulungen statt, in denen das neue System an praxisnahen Beispielfällen inklusive aller Funktionen vorgestellt wird. Ziel der Schulungen ist es, die Anwender so tief in das neue System einzuführen, dass sie danach in der Lage sind, im Tagesgeschäft damit zu arbeiten. Deshalb sollten die Schulungen kurz vor dem Go Live terminiert werden, um das Wissen bis dahin zu sichern. Oftmals werden auch Handbücher erstellt, die den Anwendern nach der Schulung zur erneuten Orientierung im System in den ersten Wochen der Nutzung dienen sollen.^[41]

Nachlaufphase: Die Nutzung des Projektergebnisses durch die Fachbereiche im laufenden Betrieb wird als Nachlaufphase bezeichnet.^[42] An diesem Begriff wird deutlich, dass diese Phase nicht mehr zum Projekt gehört. Betrachtet man aber den Produktlebenszyklus, kann sich diese Phase für das Projektergebnis über Jahre erstrecken. Außerdem wird erst in dieser Phase, in der der Auftraggeber bzw. dessen Fachbereiche das Ergebnis für ihre täglichen Aufgaben nutzen deutlich, ob das Projekt bezüglich der funktionalen und psychologischen Seite erfolgreich ist. Der psychologische Erfolg des Projektes bezieht sich dabei auf die Emotionen der Anwender, die im Erfolgsfall durch die Neuerung entlastet werden, effizienter arbeiten können oder durch Automatisierungen weniger Fehler in der Prozessbearbeitung machen.^[43]

2.3 Agiles Projektmanagement

2.3.1 Begriffsdefinition Agilität

Wie bereits an einigen Stellen in Kapitel 2.2. festgestellt, ist es zu Beginn eines IT-Projektes, vor allem in der Softwareentwicklung, meist nicht möglich, das Projektziel in allen Details beschrieben zu können. Das agile Projektmanagement reagiert auf diese nebulöse Situation, die als Iterations-Wolken-Metapher (s. Abbildung 2) bezeichnet wird, mit einer schrittweisen Vorgehensweise, bei der sich das genaue Projektziel nach und nach ergibt und nicht zu Beginn festgelegt und entwickelt wird.^[44]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Die Iterations-Wolken-Metapher

Quelle: entnommen aus Osterreich, B. (2008), S. 20.

Agilität bedeutet in diesem Zusammenhang, tolerant und dynamisch auf sich verändernde Rahmenbedingungen bezüglich Qualität, Zeit, Umfang und Kosten zu reagieren, die es notwendig machen, von der Planung abzuweichen und die Entwicklung an die neuen Bedingungen anzupassen. In Abbildung 2 lässt sich die Planung an den grauen Pfeilen und Kreisen erkennen. Der tatsächliche Verlauf, der sich durch Veränderungen und Anpassungen ergibt, wird durch die roten Linien dargestellt. An den schwarzen Kreisen lässt sich erkennen, dass im agilen Projektmanagement in Iterationen entwickelt wird und die Teilergebnisse jeweils einen neuen Mehrwert zur vorherigen Entwicklung darstellen.

2.3.2 Agiles Manifest

Das agile Manifest wurde im Jahr 2001 durch 17 Personen verfasst und unterzeichnet, die in der Praxis verschiedene Methoden^[45] der agilen Softwareentwicklung anwenden. Es enthält vier Grundwerte und zwölf Prinzipien^[46], die sich aus den Beobachtungen und Erfahrungen der Autoren zusammensetzen. Das Manifest definiert somit Agilität übergreifend für alle agilen Praktiken und gilt als Leitsatz für agiles Arbeiten.^[47]

Im Hinblick auf die Forschungsfrage dieser Arbeit werden im Folgenden die dafür relevanten Grundwerte und Prinzipien näher erläutert.

Für die Implementierung eines neuen Softwareproduktes, das auch nach erfolgreichem Projektabschluss bei den zukünftigen Anwendern auf Akzeptanz stößt, sind vor allem zwei der vier Grundprinzipien relevant:

- Funktionierende Software wird mehr geschätzt als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden wird mehr geschätzt als Vertragsverhandlung^[48]

Bereits aus diesen zwei Grundsätzen wird deutlich, dass das Ziel des agilen Projektmanagements die Zufriedenstellung der Kundenwünsche ist und nicht das Festhalten an starren Techniken und aufwändigen Dokumentationen. Dies soll durch regelmäßige Einbindung und Rückmeldung des Kunden erreicht werden.

Durch einen Teil der zwölf Prinzipien werden diese Erkenntnisse weiter vertieft. Das erste Prinzip des agilen Manifests stellt heraus, dass die höchste Priorität die ist, den Kunden zufriedenzustellen. Dies soll durch ein Vorgehen nach Prinzip drei erreicht werden. Es gibt vor, dass dem Kunden in regelmäßigen Abständen Neuerungen an der zu entwickelnden Software vorgestellt und mit ihm abgestimmt werden sollen. Zudem muss gemäß Prinzip vier die Zusammenarbeit zwischen Fachexperten und Entwicklern täglich stattfinden, um notwendige Änderungen am Produkt zu besprechen und vorzunehmen. Dadurch kann sichergestellt werden, dass die Entwickler keinen unnötigen Aufwand und Zeit in Arbeiten investieren, die der Kunde bei der Einsicht in die Entwicklung nicht mehr oder in anderer Form benötigt.

Im nachfolgenden Kapitel 2.3.3 wird die agile Projektmanagementmethode „Scrum“ vorgestellt, um die Grundsätze und Prinzipien des agilen Manifestes anhand von Vorgehensweisen und Techniken vertiefend dazustellen.

2.3.3 Scrum

Um das agile Projektmanagement weiter zu veranschaulichen, wird im Folgenden die Projektmanagementmethode Scrum vorgestellt, da diese laut einer Studie der Deutschen Gesellschaft für Projektmanagement (GPM) für IT-Projekte die bedeutendste Methode ist.^[49]

Der Scrum Prozess ist iterativ. Das heißt, dass die Entwicklung in mehreren sich wiederholenden Zyklen durchgeführt wird. Wie in Abbildung 3 dargestellt, startet der Scrum-Prozess mit einer Projektidee des Product Owners, dessen Rolle im nächsten Kapitel näher erläutert wird. Um seine Idee zu konkretisieren, verfasst er ein Product Backlog, in dem die Anforderungen an das gewünschte Produkt dokumentiert werden. Entwickelt sich diese Vision zu einem umzusetzenden Projekt, startet die Sprint-Planung. An dieser Planung nehmen neben dem Product Owner zwei weitere Rollen teil, nämlich der Scrum Master und das Entwicklerteam. Das Ergebnis der Sprint-Planung ist das sogenannte Sprint Backlog, in dem detaillierte Aufgaben dokumentiert werden, die durch das Entwicklerteam in einem maximal 4 Wochen andauernden Sprint ausgeführt werden. Die Aufgaben für einen Sprint sind festgelegt und dürfen während des Sprints nicht angepasst werden.^[50]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Der Scrum-Prozess

Quelle: entnommen aus Rubin, K. S. (2014), S. 51.

Während eines Sprints werden täglich ca. 15-minütige Daily-Scrums durchgeführt. Dies sind tägliche Meetings des Projektteams, um zu besprechen, was seit dem letzten Daily-Scrum passiert ist, wer an diesem Tag welche Aufgaben umsetzt und ob Probleme, sogenannte Impediments, aufgetreten sind, die die Entwickler daran hindern, ihre Ziele zu erreichen.^[51]

Nach einem Sprint ist dann ein Produktinkrement entstanden, welches dem User im Rahmen des sogenannten Sprint Reviews vorgestellt wird. Dieses Meeting bietet den Anwendern die Möglichkeit, die neu entwickelten Funktionen zu bewerten und Feedback zu geben.^[52] Dieses Vorgehen ermöglicht es, den Anwendern in regelmäßigen Abständen die Entwicklung anhand harter Fakten und nicht anhand der Aussagen von Managern oder Projektleitern zu begutachten und den weiteren Weg aktiv mitzugestalten. Dadurch entsteht ein Dialog, der es den Entwicklern ermöglicht, genau das Produkt zu entwickeln, welches den Anwender unterstützt und die Anwender gestalten es selbst mit, sodass eine Ablehnung des später implementierten Systems nahezu unwahrscheinlich ist.^[53]

Die Sprints werden so lange in gleicher Länge und direkt aufeinander folgend wiederholt, bis das Produkt in Gänze entwickelt wurde.^[54]

2.3.3.1 Rollen in Scrum

Das Scrum-Team setzt sich aus dem Product Owner, dem Scrum Master und dem Entwicklerteam zusammen.

Der Product Owner ist dabei für den strategischen und wirtschaftlichen Erfolg des Projektes verantwortlich. Seine Aufgabe ist es, den Product Backlog in Abstimmung mit dem Kunden zu erstellen und zu pflegen.^[55] Änderungen am Product Backlog werden während des gesamten Projektes ausschließlich durch den Product Owner vorgenommen. Zudem arbeitet er täglich mit dem Entwicklerteam zusammen und priorisiert die Aufgaben der Produktentwicklung.^[56]

Der Scrum Master ist dafür verantwortlich, dass der Scrum Prozess eingehalten wird. Dafür unterstützt er das Team und den Product Owner bei Fragen zum Vorgehensmodell und hilft, Probleme (Impediments) zu lösen, die das Entwicklerteam bei der Arbeit einschränken oder die das Team allein nicht lösen kann. Außerdem wirbt er bei teamexternen Personen und Förderern für das Projekt, um für das Projektziel an den relevanten Stellen im Unternehmen Akzeptanz zu schaffen.^[57]

Das Entwicklerteam besteht aus sieben (plus/minus zwei) fach- und abteilungsübergreifenden Experten, die selbstorganisiert und eigenständig die Aufgaben und Funktionalitäten des jeweiligen Sprint Backlogs umsetzen. Dafür schätzt das Entwicklerteam in der Sprint-Planung ein, welche Aufgaben zu schaffen sind und gibt dem Product Owner regelmäßiges Feedback, welche Aufgaben des Product Backlogs geändert, zusätzlich aufgenommen oder entfernt werden sollten, um das bestmögliche Ergebnis für den Anwender zu erreichen.^[58]

2.4 Methodenübergreifende Maßnahmen zur Akzeptanzsteigerung

2.4.1 Stakeholderanalyse

Die Stakeholderanalyse dient dazu, die vom Projekt betroffenen Personengruppen zu identifizieren und zu beteiligende Anspruchsgruppen zu identifizieren. Aus Basis dieser Analyse werden die Erwartungshaltungen und Einstellungen gegenüber dem Projekt der Gruppen analysiert. Das Ergebnis der Stakeholderanalyse ist das Beteiligungskonzept, welches Anhaltspunkte darüber liefert, welche Gruppe wie in das Projekt einzubeziehen ist.^[59]

Im ersten Schritt der Stakeholderanalyse werden alle durch das Projekt mittelbar und unmittelbar betroffenen Personen aufgelistet. Anschließend wird pro Personengruppe analysiert, welche Betroffenheitsaspekte diese Gruppen beschäftigen, also worauf sich die Veränderungen beziehen und welche Sichtweise die Personengruppe darauf hat. Bei den Anwendern wäre dies wahrscheinlich in vielen Fällen, vor allem zu Beginn des Projektes, eine skeptische bis negative Haltung in Bezug auf ihre Arbeitsweise und Zufriedenheit. Die Einstellung gegenüber der Veränderung kann persönlich oder anonym bei den Betroffen abgefragt und anschließend in einer Betroffenheitsanalyse zusammengetragen werden.^[60]

Die Betroffenheitsanalyse zeigt dem Projektleiter, welche Aspekte besonders positiv oder negativ von den Betroffenen eingestuft werden. Dadurch werden sowohl möglicher Widerstand als auch potenzielle Promotoren und Multiplikatoren für das Projekt sichtbar. Personengruppen mit entweder stark positiver oder negativer Haltung zum Projekt sind demnach auf die eine oder andere Art stark durch das Projektvorhaben betroffen. Deshalb sollten diese Gruppen unbedingt aktiv als Mitwirkende in das Projekt mit einbezogen werden. Fachabteilungen und Anwender können entweder mit speziell auf ihre Ängste und Kritik aufbereitete Informationen erhalten oder aktiv als Berater oder Mitwirkende im Kernteam (s. Kapitel 2.4.3) am Projekt teilnehmen. Auf diese Weise können Widerstände vermieden und der Projekterfolg von Beginn an gesichert werden.^[61]

2.4.2 Qualitätsmanagement

In den vorherigen Kapiteln wurde bereits deutlich, dass der Projekterfolg von der Akzeptanz der Anwender abhängt, dass das beste Projektergebnis nichts nutzt, wenn die Anwender es nicht einsetzen. Deshalb muss sichergestellt werden, dass das Projektergebnis die Kundenbedürfnisse erfüllt und ihnen einen Mehrwert bringt. Dabei können Maßnahmen des Qualitätsmanagements unterstützen. In Projekten bezieht sich Qualität immer auf zwei Hauptbereiche: die Qualität des Projektabwicklungsprozesses und die Qualität des daraus entstehenden Produkts. Im weiteren Verlauf dieses Kapitels wird aufgrund des Schwerpunktes dieser Arbeit die Produktqualität näher betrachtet, da diese ausschlaggebend für den Kundennutzen und somit die Akzeptanz der Anwender ist und damit den Projekterfolg sichert.^[62]

Das Qualitätsmaß, das zu jeder Zeit des Projektverlaufs für einen Soll-Ist-Abgleich herangezogen wird, ist zu Beginn des Projektes festzulegen. Natürlich bestehet die Möglichkeit, das Qualitätsmaß nachträglich anzupassen, aber es sollte immer Einigkeit zwischen Auftraggeber und Projektleiter darüber herrschen, was gefordert wird. Denn es ist denkbar, dass der Auftraggeber ein modernes und gut designtes System mit den neuesten Funktionen haben möchte, es kann aber auch sein, dass ihm Grundfunktionalitäten in einem schlicht gestalteten System ausreichen. Diese klare Abstimmung ist notwendig, damit das Ergebnis nicht übererfüllt oder nicht erfüllt wird, sondern genau das zu liefern, was der Kunde anfordert. Die gemessenen Qualitätsmerkmale eines IT-Projektes können beispielsweise Effizienz, Funktionsabdeckung und Zuverlässigkeit einer Anwendung sein. Diese Parameter leiten sich somit allesamt aus den vorab erstellten Anforderungskatalogen und Fachkonzepten ab.^[63]

Die definierten Qualitätsmerkmale werden im Rahmen in einem Soll-Ist-Abgleich einer Qualitätsprüfung unterzogen. Die durchzuführenden Kontrolltechniken werden für jedes Lieferobjekt in einem Prüfplan (s. Tabelle 2) dokumentiert. In diesem können beispielsweise pro Projektphase Lieferobjekte mit einem Abschlussdatum, Status, der Kontrolltechnik und dem Kontrolldatum hinterlegt werden, sodass jederzeit für das Projektteam ersichtlich ist, was wann wie durch wen kontrolliert wird.

Tabelle 2: Auszug eines Qualitätsmanagement-Prüfplans

Abbildung in dieser Leseprobe nicht enthalten

Quelle: entnommen aus Jenny, B. (2009), S. 228.

Zur Unterstützung bei der Zielsetzung, Planung, Prüfung und Sicherung von Qualitätsanforderungen können Qualitätsmanagement-Modelle eingesetzt werden. Ein solches Modell wurde für Projekte von der International Project Management Association (IPMA) definiert. Es trägt den Namen „Project Excellence-Modell“ und fokussiert sich auf die Qualitätsanforderungen eines einzelnen Projektes. Das Modell teilt sich in die Bereiche Projektabwicklungsprozess und Projektergebnisse auf, die gemeinsam neun verschiedene Kriterien beinhalten, die ein exzellentes Projekt abdecken muss. Gemäß der Definition des Modells ist ein Projekt exzellent, also herausragend, wenn es mit professionellen und innovativen Projektmanagementmethoden durchgeführt wird, aus den genutzten Methoden und Ergebnissen lernt und die Projektergebnisse die Erwartungen der Interessengruppen mindestens erfüllen oder sogar übertreffen. Durch den Einsatz des Modells können Projektmanager ihre Projekte anhand quantitativer und qualitativer Kriterien bewerten und auf Basis dieser Auswertung Stärken und Schwächen des Projektmanagements und der Projektergebnisse aufdecken, um daraufhin Verbesserungsmaßnahmen für zukünftige Projekte zu identifizieren.^[64]

Die zwei für diese Arbeit relevanten Kriterien sind die Kundenzufriedenheit und die Zielerreichung, die dem Bereich der Projektergebnisse zugeordnet werden. In diesem Bereich stellen die beiden ausgewählten Kriterien aufgrund ihrer zugeordneten Punktwerte (jeweils 150/500) die wichtigsten Kriterien dieses Bereiches dar. Dies unterstreicht erneut die Wichtigkeit der Erfüllung der Anwenderbedürfnisse in Bezug auf den Projekterfolg und die Qualität.^[65]

Das Kriterium Kundenzufriedenheit wird in diesem Modell als Faktor für exzellente Projekte beschrieben, der über die reine Erfüllung der Anforderungen hinausgeht und bei dem Kunden, in IT-Projekten also dem Anwender, Emotionen auslöst. Diese können beispielsweise die Begeisterung für das Projekt oder die Zufriedenheit mit dem Projektergebnis in ihrem Arbeitsalltag sein. Die zu messenden Parameter beziehen sich dabei auf die Kundenwahrnehmung des Projektergebnisses und Leistungsindikatoren, die die Zufriedenheit anhand von Messwerten und Kennzahlen nachweisen, ohne dabei den Kunden direkt zu befragen.^[66] Mögliche Beurteilungskriterien für das Projektergebnis können Fehler- und Ausfallraten des Systems, die Anzahl und Abarbeitungsquote von Beschwerden und die Aufnahme von Erwartungen und Anforderungen der Anwender sein. Durch solche Kriterien ist es dem Projektleiter möglich, das Projektziel an die Wünsche der Anwender anzupassen und auch in der Nachlaufphase durch die Messung der Beschwerdequoten zu erkennen, ob die Entwicklung erfolgreich im laufenden Betrieb eingesetzt wird.^[67]

Das Kriterium Zielerreichung bezieht sich auf das Erreichen der Projektziele im Sinne des Ergebnisses als auch der Performance. Ersteres hat Einfluss auf die Anwenderakzeptanz und wird deshalb im Folgenden näher beschrieben. Für dieses Kriterium wird ermittelt, ob die Projektziele in Bezug auf das Ergebnis erreicht wurden und ob dies anhand objektiver Kriterien belegt werden kann.^[68] Dafür ist es notwendig, bereits zu Beginn des Projektes messbare Kriterien festzulegen, die während des Projektes und nach dem Projektabschluss durch den Abgleich von Soll- und Ist-Daten verglichen werden können. Messbare Kriterien können die abgestimmten Parameter des magischen Dreiecks, also Zeit, Kosten und Leitung/Qualität sein, um einen ersten Überblick zu erhalten. In Bezug auf das Ergebnis, in IT-Projekten demnach Software oder Systeme, können Daten verglichen werden, die zu Beginn des Projektziels in Bezug auf den Nutzen oder Mehrwert der Neuentwicklung bestimmt wurden. Die Reduzierung von Fehlerraten, die Durchlaufzeit und Kosten der Prozesse oder die Einsparung an Mitarbeiterkapazitäten durch den Einsatz der neuen Technik können dafür herangezogen werden.^[69]

2.4.3 Einbindung von Key Usern

Neben den Möglichkeiten, die die beiden Methoden in der Theorie für die Akzeptanzsteigerung und Einbindung der Anwender vorsehen, wird in der Literatur häufig auch die Rolle des Key Users als fester Bestandteil der Projektdurchführung beschrieben. Die Aufgabe der Key User ist es, die Kluft zwischen IT und Anwendern zu schließen. Denn diese ist, wie bereits in Kapitel 2.1 festgestellt, der kritischste Erfolgsfaktor in IT-Projekten, wenn es darum geht, Funktionalitäten so zu beschreiben, dass beide Seiten das gleiche Verständnis davon haben.

Um diese Aufgabe erfolgreich ausführen zu können, muss ein Key User bestimmte Grundvoraussetzungen erfüllen. Zu allererst ist ein Key User ein Mitarbeiter aus der zukünftigen Anwendergruppe, also auch ein zukünftig von der Änderung der Arbeitswelt betroffener Mitarbeiter und genießt somit im Optimalfall die höchste Glaubwürdigkeit seiner Kollegen. Deshalb hat er im Gegensatz zum Projektleiter oder Managern die Chance, die Endanwender durch die anders geartete Beziehung zueinander von den Gründen für das Projekt und dem Projektziel zu überzeugen, die Akzeptanz für das neue System zu schaffen und somit den Erfolg des Projektes zu sichern.^[70]

Darüber hinaus sollte ein Key User detaillierte Kenntnisse über die Aufgaben und Prozesse des Fachbereiches haben und gleichzeitig daran interessiert sein, diese im Rahmen des Projektes zu ändern und zu verbessern. Aufgrund seiner Vermittlungsfunktion zwischen IT und Fachbereich sollte er zudem auch grundsätzliche Kenntnisse aus dem EDV-/IT-Bereich haben und fähig sein zu kommunizieren, um die beiden Welten mit unterschiedliche Sprachen und Fokussierungen in Bezug auf das Projektziel zusammenzuführen. Weitere Kernkompetenzen sind ein freundliches Auftreten und eine deeskalierende Haltung einhergehend mit der Bereitschaft, mit Widerständen und Angriffen diplomatisch umzugehen und zuletzt auch der Wille und die Fähigkeit, Menschen zu motivieren und auf dem Weg mitzunehmen.^[71]

Die Rolle des Key Users kann sowohl in das klassische als auch in das agile Projektmanagement eingebaut werden. Im klassischen Projektmanagement kann die Rolle des Key Users vor allem in der Realisierungsphase einen Mehrwert für das Phasenmodell liefern, da in dieser Phase in der Theorie nicht vorgesehen ist, dass Anwender mit eingebunden sind oder die fortschreitenden Entwicklungen geprüft und durch entsprechendes Feedback justiert werden. Im agilen Projektmanagement hingegen, ist die Rückkopplung der Entwicklungsfortschritte zwar durch die Sprint Reviews fest vorgegeben, doch ist damit nicht automatisch für eine kontinuierliche Beteiligung der Endanwender gesorgt. Es kann nämlich sein, dass ein Process Owner statt eines Endanwenders an den Sprint Reviews teilnimmt, der nicht die nötige Nähe zum Fachbereich hat.^[72] Der Key User kann im agilen Projektmanagement somit als Unterstützer und Berater des Product Owners agieren.^[73]

Key User sind in beiden Projektmanagementmethoden über die gesamte Projektlaufzeit hinweg in die Projektaktivitäten eingebunden (s. Abbildung 4), um das Wissen über die Funktionen der Software schrittweise von den Entwicklern über die Key User an die Endanwender zu übertragen.^[74]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Aufgaben der Key User im Projektverlauf

Quelle: Eigene Darstellung

In der Konzeptionsphase fungieren die Key User das erste Mal als Schnittstelle zwischen Fachbereich und IT, indem sie die Anforderungen an das IT-Produkt in ihrem Team sammeln oder die Prozesse selbst im Detail kennen und in die Erstellung der Fachkonzepte einfließen lassen.^[75]

In der Realisierungsphase testen Key User entweder kontinuierlich, nach dem Erreichen festgelegter Meilensteine oder am Ende der Phase, die entwickelten Funktionalitäten. Die notwendigen Testszenarien definieren sie dafür selbst oder in Abstimmung mit dem Entwicklerteam. Zudem führen die Key User die Tests auch durch, da sie am besten wissen, an welchen Stellen im Prozess Fehler auftreten können und auf welchen Funktionalitäten das Hauptaugenmerk liegt. Im Rahmen der Tests ist ein großer Vorteil der Einbindung von Key Usern, dass sie direktes Feedback zur Entwicklung geben können, sodass Anpassungen noch frühzeitig durchgeführt werden können. Des Weiteren ist das Testen eine Train-the-Trainer-Maßnahme, durch die die Key User die Software im Detail ausprobieren und dadurch selbst zu Experten für die Nutzung werden.^[76] Ihr erlangtes Wissen können Sie dann in der Einführungsphase im Rahmen von Schulungen an ihre Kollegen weitergeben. Dieses Vorgehen hat zweierlei Nutzen: Die Schulungsunterlagen und Handbücher werden durch die Key User erstellt und haben somit den Fokus und die Fachsprache, die die Anwender verstehen und umsetzen können. Zum zweiten ist das Vertrauen und damit die Akzeptanz gegenüber der neuen Software größer, wenn ein Kollege aus den eigenen Reihen die Software in seiner eigenen Sprache erklärt und Auswirkungen sowie Vorteile transparent darstellt.^[77]

[...]

---

^[1] Vgl. Franken (2016), S. 4.

^[2] Vgl. Burghardt (2012), S. 12 f.

^[3] Vgl. The Standish Group (2014), S. 1.

^[4] Vgl. Bea et al. (2011), S. 2.

^[5] Vgl. Sterrer und Winkler (2010), S. 218.

^[6] Vgl. Komus und Kuberg (2017), S. 9.

^[7] Vgl. Berg et al. (2014), S. 29.

^[8] Vgl. Sutherland (2012), S. 6.

^[9] Vgl. Olfert (2012), Bea et al. (2011) und Kammerer et al. (2012).

^[10] Vgl. Komus und Kuberg (2017) und Toth et al. (2009).

^[11] Laut Definition der DIN 69901 ist ein Projekt ein „Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation.

^[12] Vgl. Wieczorrek und Mertens (2011), S.12.

^[13] Vgl. The Standish Group (2013), S. 1 und Hastie, S; Wojewoda, S. (2015), o. S.

^[14] Vgl. Wieczorrek und Mertens (2011), S.19.

^[15] Vgl. Sterrer und Winkler (2010), S. 218.

^[16] Vgl. The Standish Group (2014), S. 8.

^[17] Vgl. Feyhl (2013), S. 3 f.

^[18] Vgl. Huber und Kuhnt (2007), S. 19 f.

^[19] Vgl. Jenny (2009), S. 48 f.

^[20] Vgl. Timinger (2015), S. 112.

^[21] Vgl. Hobel und Schütte (2006), S. 177.

^[22] Vgl. Olfert (2012), S. 81.

^[23] Vgl. Meier (2009), S. 29, Jenny (2009), S. 49 und Zell (2010), S. 23.

^[24] Vgl. Wieczorrek und Mertens (2011), S. 57.

^[25] Vgl. Drees et al. (2014), S. 42.

^[26] Vgl. Jenny (2009), S. 158.

^[27] Vgl. Schels und Seidel (2015), S. 30.

^[28] Vgl. Bea et al. (2011), S. 99 f.

^[29] Vgl. Sterrer und Winkler (2010), S. 41 und Jenny (2009), S.167 und 254 f.

^[30] Vgl. Timinger (2015), S. 83.

^[31] Vgl. Drees et al. (2014), S. 42 und Timinger (2015), S. 84.

^[32] Vgl. Jenny (2009); Kuster et al. (2011), S. 60.

^[33] Vgl. Bea et al. (2011), S. 44 f.

^[34] Vgl. Jenny (2009), S. 168.

^[35] Vgl. Jenny (2009), S. 168.

^[36] Vgl. Kuster et al. (2011), S. 69.

^[37] Vgl. Kammerer et al. (2012), S. 99 und Schels und Seidel (2015), S. 250.

^[38] Vgl. Szalvay (2004), S. 2 f.

^[39] Vgl. Jenny (2009), S. 184.

^[40] Vgl. Bea et al. (2011), S. 313, 315.

^[41] Vgl. Kammerer et al. (2012), S. 468.

^[42] Vgl. Zimmermann et al. (2006), S. 4; Jenny (2009), S. 185 und Pautsch und Steininger (2014), S. 63.

^[43] Vgl. Jenny (2009), S. 185.

^[44] Vgl. Ostereich (2008), S. 3.

^[45] Die vertretenen Methoden waren u.a. Extreme Programming, Scrum, Crystal-Methoden und Adaptive Software Development (Vgl. Highsmith (2006), S. XVII).

^[46] S. Anhang A.

^[47] Vgl. Highsmith (2006), S. XVII.

^[48] Vgl. Beck et al. (2001), o. S.

^[49] Vgl. Komus und Kuberg (2017), S. 9.

^[50] Vgl. Rubin und Lichtenberg (2014), S. 50 f.

^[51] Vgl. Preußig (2015), S. 149 f.

^[52] Vgl. Pautsch und Steininger (2014), S. 179.

^[53] Vgl. Gloger (2014), S. 216.

^[54] Vgl. Preußig (2015), S. 147.

^[55] Vgl. Timinger (2017), S. 168.

^[56] Vgl. Jochmann et al. (2017), S. 9.

^[57] Vgl. Timinger (2017), S. 168.

^[58] Vgl. Sutherland (2012), S. 15.

^[59] Vgl. Hobel und Schütte (2006), S. 54.

^[60] Vgl. Meier (2009), S. 46.

^[61] Vgl. Hobel und Schütte (2006), S. 57 f.

^[62] Vgl. Jenny (2009), S. 223 f.

^[63] Vgl. Noé (2006), S. 59 und Jenny (2009), S. 225.

^[64] Vgl. Jenny (2009), S. 233 f. und GPM (2016), S. 2.

^[65] Vgl. GPM (2016), S. 3.

^[66] Vgl. GPM (2016), S. 8.

^[67] Vgl. Wehnes (2009), S. 38.

^[68] Vgl. GPM (2016), S. 9.

^[69] Vgl. Wehnes (2009), S. 42.

^[70] Vgl. Wagner (2016b), S. 1.

^[71] Vgl. Feyhl (2013), S. 78 und Abele et al. (2007), S. 245 f. und Wagner (2016b), S. 3.

^[72] Vgl. Wagner (2016b), S. 1.

^[73] Vgl. Hanschke (2017), S. 106.

^[74] Vgl. Drews und Hillebrand (2007), S. 168.

^[75] Vgl. Groß und Pfennig (2017), S. 326.

^[76] Vgl. Wagner (2016a), S. 4.

^[77] Vgl. Groß und Pfennig (2017), S. 326 und Wagner (2016a), S. 5.