Konzeptentwicklung von IT-Systemen

Burkhard Kresser
Projektmanagement zur Konzeptentwicklung von IT-Systemen für
Kollaboration am Beispiel eines Extranets
Master Thesis
Zur Erlangung des akademischen Grades
Master of Science
Universitätslehrgang Management in Information and Business Technologies
Begutachter: Ao.-Univ.-Prof. Mag. Dr. Gernot Mödritscher
Vorbegutachter: Dr. Michael Amann-Langeder
05/2017

II
Ehrenwörtliche Erklärung:
Ich versichere an Eides statt, dass ich
- die eingereichte wissenschaftliche Arbeit selbstständig verfasst und andere als
die angegebenen Hilfsmittel nicht benutzt habe;
- die während des Arbeitsvorganges von dritter Seite erfahrene Unterstützung,
einschließlich signifikanter Betreuungshinweise, vollständig offengelegt habe;
- die Inhalte, die ich aus Werken Dritter oder eigenen Werken wortwörtlich oder
sinngemäß übernommen habe, in geeigneter Form gekennzeichnet und den
Ursprung der Information durch möglichst exakte Quellenangaben (z.B. in Fuß-
noten) ersichtlich gemacht habe;
- die Arbeit bisher weder im Inland noch im Ausland einer Prüfungsbehörde vor-
gelegt habe und dass
- die zur Plagiatskontrolle eingereichte digitale Version der Arbeit mit der ge-
druckten Version übereinstimmt.
Ich bin mir bewusst, dass eine tatsachenwidrige Erklärung rechtliche Folgen haben
wird.
(Unterschrift) (Ort, Datum)

III
Inhaltsverzeichnis
Einleitung..............................................................................................................1
1.1 Problemstellung ............................................................................................1
1.2 Zielsetzung....................................................................................................2
1.3 Vorgehensweise und Aufbau der Arbeit........................................................3
Terminologische Grundlagen................................................................................4
2.1 Begriffsabgrenzung Daten, Informationen und Wissen.................................4
2.2 Definition von Internet, Intranet und Extranet................................................6
2.2.1 Internet ......................................................................................................6
2.2.2 Intranet ......................................................................................................7
2.2.3 Extranet .....................................................................................................8
2.2.4 Unterschiede .............................................................................................9
2.3 Begriffsdefinition Kollaborationsplattform......................................................9
2.4 Begriffsdefinition Projekt .............................................................................10
Projektmanagement für die IT Systementwicklung .............................................13
3.1 Beschreibung der Phasen des Projektmanagements .................................13
Exkurs E1: Iterative Vorgehensmodelle..............................................................15
3.1.1 Initiierung.................................................................................................18
3.1.2 Konzeption ..............................................................................................20
Exkurs E2: Der Projektstrukturplan.....................................................................22
3.1.3 Umsetzung und Steuerung......................................................................23
3.1.4 Einführung ...............................................................................................23
3.1.5 Abschluss ................................................................................................25
3.2 Methoden-Tailoring für IT-Systementwicklung ............................................26
Projektabgrenzung..............................................................................................27
4.1 Projektumfeld und sachlicher Kontext.........................................................27
4.2 Projektumfeldanalyse..................................................................................28
Exkurs E3: Die Crawford Slip Technik ...................................................................29
4.3 Stakeholderanalyse.....................................................................................31

IV
4.3.1 Ermittlung von Auftrag und Zielsetzungen der Stakeholder.....................32
Exkurs E4: Befragungs- bzw. Erhebungstechniken ............................................32
4.3.2 Bewertung von Interesse und Einfluss der Stakeholder ..........................36
4.3.3 Chancen und Risiken ..............................................................................37
4.3.4 Ableitung von Maßnahmen......................................................................38
4.4 Risikoidentifikation und -analyse.................................................................42
4.4.1 Risikoidentifikation...................................................................................42
Exkurs E5: Der Betrachtungsobjekteplan ...........................................................43
4.4.2 Risikoanalyse ..........................................................................................43
Anforderungsanalyse..........................................................................................46
5.1 Einordnung und Aufbau eines Lastenhefts .................................................46
5.2 Anforderungen ............................................................................................47
5.2.1 Nichtfunktionale Anforderungen ..............................................................48
5.2.2 Rahmenbedingungen ..............................................................................49
5.2.3 Funktionale Anforderungen .....................................................................49
Exkurs E6: Welcome to MoSCOW .....................................................................50
5.3 Anforderungsanalyse als Teil des IT-System Entwicklungsprozess ...........51
5.4 Methoden der Anforderungserhebung ........................................................51
5.4.1 Kreative Techniken..................................................................................52
Exkurs E7: Wechsel der Perspektive..................................................................52
5.4.2 Beobachtungstechniken ..........................................................................53
5.4.3 Befragungstechniken...............................................................................53
5.4.4 Artefaktbasierte Techniken......................................................................54
5.4.5 Hilfsmittel und unterstützende Techniken................................................54
5.5 Definition und Erstellung von Use-Cases....................................................56
5.6 Dokumentation von Anforderungen im Lastenheft ......................................60
Dokumentation von Lösungen ............................................................................63
6.1 Beschreibung der Lösung mittels Pflichtenheft ...........................................63

V
Exkurs E5: Compliance und Governance ..............................................................64
Praktische Anwendung für die Extranet Systementwicklung ..............................65
7.1 Erarbeitung eines angepassten Vorgehensmodells....................................65
7.2 Erarbeitung des Projektauftrags..................................................................67
7.2.1 Projektumfeldanalyse ..............................................................................67
7.2.2 Stakeholderanalyse.................................................................................69
7.2.3 Risikoanalyse ..........................................................................................70
7.2.4 Projektauftrag ..........................................................................................73
7.3 Dokumentation der Anforderungen an das Extranet ...................................73
7.3.1 Anforderungserhebung............................................................................73
7.3.2 Erstellung des Lastenhefts ......................................................................74
7.3.2.1 Ausgangssituation................................................................................................... 74
7.3.2.2 Zielsetzung.............................................................................................................. 75
7.3.2.3 Rahmenbedingungen und Anforderungen............................................................. 76
7.3.2.4 Umfang ................................................................................................................... 79
7.3.2.5 Projektphasen und Meilensteine............................................................................ 79
7.3.2.6 Offene Punkte......................................................................................................... 80
7.3.2.7 Abnahmekriterien und Qualitätsanforderungen.................................................... 80
7.4 Erarbeitung und Dokumentation von Lösungen für das Extranet................81
7.4.1 Pflichtenheft - Beschreibung systemtechnischer Lösungen ....................81
7.4.1.1 Design von Infrastruktur und IT-System................................................................. 81
Exkurs E8: Cloud Computing ..................................................................................................... 82
7.4.1.2 Netzwerkkonzeption............................................................................................... 84
7.4.1.3 Hochverfügbarkeit (HA) durch Virtualisierung ....................................................... 85
7.4.1.4 HA-Hardware .......................................................................................................... 86
7.4.1.5 HA-Software............................................................................................................ 87
7.4.1.6 Serverbetriebssystem und -konfiguration.............................................................. 88
7.4.1.7 Active Directory und DNS Konzept ......................................................................... 89
7.4.1.8 Sicherheit durch Updates und Antivirus................................................................. 91
7.4.1.9 SharePoint Installations- und Konfigurationskonzept............................................ 92
7.4.1.10 Office Web Apps Server.......................................................................................... 95
7.4.2 Pflichtenheft – Beschreibung von Organisationsprozessen.....................96

VI
7.4.2.1 Vorüberlegungen zum organisatorischen Konzept ................................................ 96
7.4.2.2 Workspacetopologie............................................................................................... 96
Exkurs E9: Compliancefaktor Benutzerverwaltung................................................................... 97
7.4.2.3 Zugriffskonzept ....................................................................................................... 98
7.4.2.4 Relink ...................................................................................................................... 99
7.4.2.5 Datenverwaltung .................................................................................................. 100
7.4.2.6 Workspace Management...................................................................................... 100
7.4.2.7 Benutzerverwaltung ............................................................................................. 102
7.4.2.8 Berechtigungskonzept .......................................................................................... 102
7.4.2.9 Active Directory Federation Services.................................................................... 105
Resümee und Ausblick .....................................................................................106
Literaturverzeichnis...........................................................................................111
Appendix...........................................................................................................119
A1 Angepasstes Vorgehensmodell zur IT-Systementwicklung................................120
A2 Projekt Auftrag (Muster).....................................................................................121
A3 Stakeholder Analyse Liste (Muster) ...................................................................123
A4 Stakeholder Analyse Kategorien und Maßnahmen (Muster)..............................124
A5 Konfiguration der Berechtigungsvergabe...........................................................125
A6 Script für Berechtigungsvergabe........................................................................129
A7 Prozesse für das Workspace Management .......................................................137
A8 Scripts für das Workspace Management ...........................................................140

VII
Tabellenverzeichnis
Tabelle 1: Typische Aufgaben der Projekt Initiierung ................................................19
Tabelle 2: Typische Aufgaben der Konzeptionsphase ..............................................21
Tabelle 3: Typische Aufgaben der Umsetzungsphase ..............................................23
Tabelle 4: Typische Aufgaben der Einführung...........................................................24
Tabelle 5: Typische Aufgaben des Projektabschlusses ............................................25
Tabelle 6: Maßnahmen des Projektmarketings .........................................................39
Tabelle 7: Beispiel einer Stakeholdertabelle..............................................................41
Tabelle 8: Risikoanalyse und risikopolitische Maßnahmen .......................................45
Tabelle 9: Granularität von Use-Cases .....................................................................57
Tabelle 10: Beispiel für eine Use-Case Beschreibung ..............................................59
Tabelle 11: Extranet Anforderungstabelle .................................................................78
Tabelle 12: Meilensteinplan.......................................................................................80
Tabelle 13: Workspace Typen...................................................................................97
Tabelle 14: Gegenüberstellung Workspace Funktionalitäten ..................................100

VIII
Abbildungsverzeichnis
Abbildung 1: Zusammenhang macht aus Daten Informationen 4
Abbildung 2: Wissenstreppe nach North 5
Abbildung 3: Statistik der weltweiten Internetnutzung 7
Abbildung 4: Intranet, Extranet und Internet 9
Abbildung 5: Übersicht "Kompetenzen des IT-Projektmanagers" 11
Abbildung 6: Gegenüberstellung von Projektphasen und Bezeichnungen 14
Abbildung 7: Beispiel für ein Spiralmodell 16
Abbildung 8: Das V-Modell 17
Abbildung 9: Beispiel für einen prozessorientierten Projektstrukturplan 22
Abbildung 10: Projektumfeld und sachlicher Kontext 27
Abbildung 11: Beispiel für grafische Darstellung des Projektumfeldes 29
Abbildung 12: Einfluss-Interessen-Matrix 37
Abbildung 13: Hierarchische Gliederung von Anforderungen 49
Abbildung 14: Beispiel für eine Mindmap 55
Abbildung 15: Elemente eines einfachen Use-Case Diagramms 57
Abbildung 16: Beispiel für eine Eigenschaftsschablone 61
Abbildung 17: Beispiel für eine Prozessschablone 61
Abbildung 18: Beispiel für eine Umgebungsschablone 62
Abbildung 19: Vorgehensmodell für die Extranet Entwicklung 66
Abbildung 20: Extranet Projektumfeldanalyse 67
Abbildung 21: Projektauftrag Extranet Systementwicklung 73
Abbildung 22: Extranet Use-Case Diagramm 79
Abbildung 23: Cloud Organisationsformen 84
Abbildung 24: Schematische Darstellung einer DMZ 85
Abbildung 25: Schematische Darstellung einer hochverfügbaren Infrastruktur 87
Abbildung 26: Übersetzung von Hostnamen in IP-Adressen 90
Abbildung 27: Konzept Serverinfrastruktur 95
Abbildung 28: Zusammenspiel der Workspace Typen 98
Abbildung 29: Konzept für "Workspace-Relink" 99
Abbildung 30: Prozess des Berechtigungs-Self-Service 103
Abbildung 31: Technische Umsetzung: Permission Self Service 104
Abbildung 32: Prozess der manuellen Berechtigungsvergabe 104
Abbildung 33; ALPLA Prozess Modell 108

IX
Abbildung 34: Workspace Konzept für Bilanzkonsolidierung 109
Abbildung 35: Event Viewer Task "Add Users to tenants on event" 127
Abbildung 36: Trigger des Event Viewer Tasks 128
Abbildung 37: Partner Workspace Anforderungsprozess 137
Abbildung 38: Project Workspace Anforderungsprozess 138
Abbildung 39: Prozess Workspace Link 139

X
Abkürzungsverzeichnis
ANSI American National Standards Institute
ALPLA Alpenplastik Lehner Alwin
AP Arbeitspaket
ASAP as soon as possible (so schnell wie möglich)
AS-IS Istsituation
B2B Business to Business
B2C Business to Consumer
B2E Business to Employee
BA Business Analyst
BI Business Intelligence
BSA Business Software Alliance
BSC Balanced Scorecard
CFO Chief Financial Officer
CMS Content Management System
CPU Central Processing Unit
CRM Customer Relationship Management
CSF Critical Success Factors
DBMS Datenbankmanagementsystem
DIN Deutsche Institut für Normung
DSS Decision Support System
DWH Data Warehouse
EAI Enterprise Application Integration
EBITDA Earnings before Interest, Taxes, Depreciation, and Amortisation
EIP Enterprise-Information-Portal
EIS Executive Information System
ERM Entity-Relationship-Modell
ERP Enterprise Resource Planning
ETL Extraction, Transformation, Loading
EU Europäische Union
EuGH Europäischer Gerichtshof
EULA End User License
EWG Europäische Wirtschaftsgemeinschaft
FA Funktionale Anforderung
FR Functional Requirement
FTP File Transfer Protocol
GmbH Gesellschaft mit beschränkter Haftung
HERMES Handbuch der Elektronischen Rechenzentren des Bundes,
eine Methode zur Entwicklung von Systemen
HR Human Ressource
IaaS Infrasctructure-as-a-Service
IBM International Business Machines Corporation
ID Identifyer
IDV Individuelle Datenverarbeitung

XI
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
IPMA International Project Management Association
IS Informationssystem/Information System
ISO International Organization for Standardization
IT Informationstechnologie
LDAP Lightweight Directory Access Protocol
MIS Management Information System
MIT Massachusetts Institute of Technology
MS Microsoft
NFA Nicht-Funktionale Anforderung
NFA Non-Functional Requirement
ODS Operational Data Store
OEM Original Equipment Manufacturer
OLAP Online Analytical Processing
OLTP Online Transaction Processing
OMG Object Management Group
PaaS Platform-as-a-Service
PAG Projektauftraggeber
PatG Patentgesetz
PDF Portable Document Format
PHB Projekthandbuch
PL Projektleiter
PLA Projektlenkungsausschuss
PM Projektmanagement
PM Projektmanager
PMA Projektmitarbeiter
PMBOK Project Management Body of Knowledge
PMI Project Management Institite
PMO Projektmanagementbüro
PoC Proof of Concept
PSP Projektstrukturplan
PTM Projektteammitglied
RUP Rational Unified Process
SA Solution Architect
SaaS Software-as-a-Service
SCM Supply Chain Management
SP SharePoint
SQL Structured Query Language
SWOT Strengths, Weaknesses, Opportunities, Threats
TO-BE Sollsituation
UC Use Case
UML Unified Modeling Language
USA United States of America
VPN Virtual Private Network

XII
WBS Work Breakdown Structure (Projektstrukturplan)
WS Workshop
WTO World Trade Organization
WWW World Wide Web
XMI XML Metadata Interchange
XML Extensible Markup Language
XPS Expert System

1
„Wir sind zur Zusammenarbeit geboren.“
Marc Aurel (121 - 180), römischer Kaiser und Philosoph
Einleitung
1.1 Problemstellung
Durch globale Zusammenarbeit stehen Unternehmen vor großen Herausforderungen
im Bereich des Wissensmanagements und der asynchronen Kollaboration. Es müssen
größte Anstrengungen unternommen werden, um Wissen, Erfahrung und individuelle
Informationen, die jeder Mitarbeiter innerhalb des eigenen Unternehmens als auch bei
Partnerfirmen einbringt, zu sichern. Häufig findet Zusammenarbeit zwischen Mitarbei-
tern von Partnerfirmen nur informell durch Email, Telefonate oder Instant Messaging
statt. Durch Personalfluktuation, ist später die Nachvollziehbarkeit von Entscheidun-
gen, genauso wie die Wiederholbarkeit von Prozessen, schwierig.
Immaterielle Vermögenswerte wie Humankapital, Datenbanken und Informationssys-
teme, effiziente Prozesse, Kundenbeziehungen, Marke, Innovationskraft und Unter-
nehmenskultur machen auch nach zerplatzen der dot.com-Blase 75% des
Unternehmenswertes aus.1 Trotzdem wandern derart hochsensible Informationen,
Wissen und somit wichtige Vermögenswerte häufig direkt zu Mitbewerbern. Schuld
sind hierfür in erster Linie nicht Hackerangriffe oder Werkspionage. Die Gründe hierfür
sind meistens wesentlich profaner:
 Trotz Aufkündigung des Dienstverhältnisses verfügen ehemalige Mitarbeiter
oftmals weiterhin über umfangreiche Zugriffsmöglichkeiten auf hochsensible In-
formationen und Daten. Dies kann ehemalige Mitarbeiter des eigenen Unter-
nehmens in gleichem Maße wie Mitarbeiter von Partnerunternehmen betreffen.
 Informationen und Daten werden nicht systematisch und wiederauffindbar ab-
gespeichert.
 Geschäftsprozesse werden nicht oder nur ungenügend dokumentiert.
Soll ein Informatiksystem zur Unterstützung und besseren Strukturierung der Zusam-
menarbeit zwischen Unternehmen zum Einsatz kommen, wirkt sich das auf das ein-
zelne Unternehmen nicht ausschließlich im Bereich der jeweiligen
1 Vgl. Kaplan et al. (2004), 3f

2
Informationssysteme aus, sondern hat Auswirkungen auf Prozesse und Geschäfts-
strategie der zusammenarbeitenden Unternehmen.2
In Frage kommt hierfür Kollaborations-Software, die eine Mischung aus Kommunika-
tion, Arbeitsprozessen und Dokumentenmanagement in unterschiedlichen Zusam-
mensetzungen darstellt.3 Im unternehmerischen Kontext ist die Motivation für
Kollaboration heute oftmals ausdrücklich immaterieller Natur: Information. Wenn diese
nicht oder nur unzureichend zur Verfügung steht, lassen sich Prozesse nur schwer
effizient gestalten. Nur wenn die Abläufe genau analysiert werden, lassen sich Unter-
nehmensprozesse durch Einsatz von Software unterstützen, so dass eine deutliche
Effizienzsteigerung möglich wird.4
Synchrone Kollaboration beinhaltet alle Ausprägungen von Zusammenarbeit in Echt-
zeit. Videokonferenzsysteme und alle Varianten von Telefonie sind hier zu nennen.
„Die asynchrone Kommunikation beschreibt das zeitlich versetzte Senden und Emp-
fangen von Informationen wie die E-Mail-Kommunikation, das Senden und Empfangen
von SMS und MMS oder die Kommunikation in Newsgroups und Mailingslists.“5 Intra-
net- sowie Extranet-Portale zählen zu Lösungen für asynchrone Kommunikation und
stellen beispielsweise zentrale Foren im Intranet dar, an denen Nachrichten und Hilfe-
gesuche hinterlassen und beantwortet werden können.6 Asynchrone Kollaboration be-
inhaltet per Definition E-Mail, Instant Messaging und Kollaborationsplattformen.
1.2 Zielsetzung
Ziel dieser Arbeit ist ein detailliertes Konzept für eine Kollaborationsplattform für asyn-
chrones Informationsmanagement voneinander unabhängiger Unternehmen. Der Le-
ser soll in der Lage sein, mit Hilfe dieser Arbeit selbst eine solche
Kollaborationsplattform nach Anforderungen und Bedürfnissen seiner Stakeholder zu
konzipieren. Die wissenschaftliche Fragestellung, die in dieser Arbeit beantwortet wird,
lautet: „Welche organisatorischen und technischen Aspekte müssen erfüllt sein, um
eine sichere Kollaborationsplattform für voneinander unabhängige Unternehmen unter
2 Vgl. Amann (2008), S. 7.
3 Vgl. Angermeier, G. Hrsg. v. Projekt Magazin: Collaboration. URL: https://www.projektmaga-
zin.de/glossarterm/collaboration (22.11.2015)
4 Vgl. Galuschka: Collaboration schafft Nähe in der Distanz 2009. URL: http://www.computer-
woche.de/a/collaboration-schafft-naehe-in-der-distanz (22.11.2015)
5 Beuth Hochschule für Technik Berlin, URL: http://www.wissensstrukturplan.de/wissensstruktur-
plan/glossar/a_asynchrone_kom.php (22.11.2015)
6 Vgl. Wohlwender (2014), S. 40.

3
Berücksichtigung der Anforderungen relevanter interner und externer Stakeholder zu
implementieren?“ Der Fokus der Arbeit liegt in der Konzeption einer Lösung laut Rah-
menbedingungen und Anforderungen interner und externer Stakeholder. Realisierung
und Einführung der Lösung werden nicht vertieft ausgearbeitet. Auch IT-System Stan-
dardfunktionalitäten werden nicht detailliert behandelt. Das Zielsystem soll Kollabora-
tion und Kommunikation mehrerer, rechtlich nicht mit einander verbundener
Unternehmen zulassen und Funktionalitäten zur Unterstützung bilateraler und multila-
teraler Projekte und Prozesse bieten. Nicht Teil der Arbeit ist die Erarbeitung von
Schnittstellen zu anderen Informationssystemen. Mit Hilfe eines maßgeschneiderten
Vorgehensmodells und geeigneter Projektmanagement Werkzeuge können die not-
wendigen Schritte unternommen werden, um ein sicheres IT-System für unterneh-
mensübergreifende Zusammenarbeit aufzubauen. Ziel eines konkreten Projekts7,
welches aus dieser Arbeit hervorgeht, ist nicht nur die Konzeptentwicklung, sondern
auch dessen Umsetzung. Aus diesem Grund werden im Rahmen dieser Arbeit auch
die wichtigsten Aufgaben bei der Umsetzung und für den Projektabschluss theoretisch
erläutert.
1.3 Vorgehensweise und Aufbau der Arbeit
Nach der Beschreibung der Problemstellung und Zielsetzung werden im zweiten Ka-
pitel notwendige Begriffe definiert und im anschließenden Kapitel werden die grundle-
genden Phasen des Projektmanagements beschrieben. Vertieft beschrieben werden
in Kapitel vier bis sechs Methoden der IT-Systementwicklung. Stakeholder und Risiken
werden in Abschnitt vier aus einer Projektumfeldanalyse abgeleitet, in Kapitel fünf wer-
den Anforderungen analysiert, deren Lösung mittels Pflichtenheft in Teil sechs be-
schrieben wird. Das Kapitel 7 zeigt die praktische Anwendung zuerst mit der
Erarbeitung eines maßgeschneiderten Projektmanagement Vorgehensmodells und
dem Lastenheft. In Form eines Pflichtenhefts werden dann Lösungen zu den doku-
mentierten Anforderungen beschrieben. Abschließend wird ein Resümee gezogen und
ein Ausblick gegeben.
Der „rote Faden“ der sich durch die Arbeit zieht soll folgende Frage beantworten:
„WER benötigt WAS und WIE wird es umgesetzt?“
7 Implementierung eines Extranets bei einem internationalen Verpackungsmittelkonzern; Details ab
Kapitel 7.

4
„Zu wissen, was man weiß,
und zu wissen, was man tut, das ist Wissen.“
Konfuzius (551 - 479 v. Chr.), chinesischer Philosoph
Terminologische Grundlagen
2.1 Begriffsabgrenzung Daten, Informationen und Wissen
Die Verwendung der Begriffe Daten und Informationen, die im alltäglichen Sprachge-
brauch synonym verwendet werden, müssen in einem professionellen Kontext deutlich
unterschieden werden.8 Daten alleine stellen keine Informationen dar, sie sind viel-
mehr Informationselemente oder Fakten die aus Zahlen, Buchstaben oder Buchsta-
benfolgen, Sonderzeichen aber auch akustischen oder visuellen Signalen bestehen
können. Werden diese Daten durch Menschen zweckbestimmt interpretiert, im Zusam-
menhang betrachtet, erhält man Informationen.9 Steht die Zahl 20 alleine stellt noch
keine Information dar, im Zusammenhang mit einem Briefkasten lautet die Information
„Das ist Hausnummer 20“. Die Zahl 20 auf einer Torte lässt die Interpretation zu, dass
es sich einen zwanzigsten Geburtstag handeln muss.10
Abbildung 1: Zusammenhang macht aus Daten Informationen11
8 Vgl. Deutschmann (2011), S. 7.
9 Vgl. Badertscher/Scheuring (2006), S. 31.
10 Vgl. Badertscher/Scheuring (2006), S. 32.
11 Quelle: Badertscher/Scheuring (2006), S. 32.

5
Die Betrachtung, was als IT-System definiert und wie es bezeichnet wird hat sich im
Lauf der Zeit verändert.12 Zuerst war die Bezeichnung Datenverarbeitungssysteme ge-
bräuchlich, mit zunehmender Bedeutung von Texten, Bildern und anderen Formate
dann der Begriff Informationsverarbeitung. Da die Bedeutung des Austausches von
Informationen zugenommen hat, ist die Bezeichnung Informations- und Kommunikati-
onstechnologie (IKT) gebräuchlich.13
North beschreibt in seiner Wissenstreppe die Abhängigkeiten, beginnend mit dem
kleinsten Datenelement, dem Zeichen. Durch Zuordnung von Syntax entstehen Daten
die wiederum durch Interpretation zu Informationen werden.
Abbildung 2: Wissenstreppe nach North14
Wie im Einleitungskapitel nach Kaplan / Norton dargelegt, bilden diese Informationen
im unternehmerischen Kontext, durch wirksamen Einsatz, einen nachhaltigem Wert in
Unternehmen. Wissen entsteht durch Einsatz und Kombination Daten und Informatio-
nen und ist handlungsorientiert.15 Wissen sollte als Ressource begriffen werden, um
die Effektivität zu steigern und zur Unterstützung um Unternehmensziele planmäßig
zu erreichen.16
12 Vgl. Gluchowski et al. (2008), S. 27–28.
13 Vgl. Deutschmann (2011), S. 7.
14 Quelle: North (2005), S. 37 (leicht modifiziert)
15 Vgl. North (2005), S. 29ff.
16 Vgl. Zimmermann (2009), S. 80.

6
„Die Wissenslogistik fokussiert auf die zielgerichtete Bereitstellung von Wissen und
Erfahrung im Unternehmenskontext und betont dabei vor allem drei Aspekte:
 die Kernaufgabe der Bereitstellung von Wissen unter Gesichtspunkten der Ziel-
orientierung und der Leistungssteigerung
 den Prozessbezug
 das Prinzip der Effizienz im Umgang mit Wissen.“17
Sie stellt somit eine Querschnittsfunktion dar und findet überall in Unternehmen statt.18
2.2 Definition von Internet, Intranet und Extranet
Das Internet ist das bekannteste, weitest verbreitete und meist verwendete Computer-
netzwerk, aber nicht der einzige Typ von Computernetzwerken um Information digital
zu teilen. Das Internet, Intranets und Extranets sind sehr ähnliche aber trotzdem ver-
schiedene Typen von Netzwerken. Während das Internet grundsätzlich für jede Person
frei zugänglich ist, sind Extranets und Intranets für kleinere Gruppen von Personen
ausgerichtet.
2.2.1 Internet
Der Begriff Internet besteht aus zwei Teilen, und zwar "Inter" was so viel wie "zwi-
schen" bedeutet und "Net" was im Englischen "Netz" bedeutet. Daraus lässt sich
schließen, dass es sich beim Internet um ein Netzwerk für den Austausch von Daten
zwischen Computern handelt.19 Grundsätzlich handelt es sich um ein Netzwerk, dass
weltweit jeder Person mit einem internetfähigen Gerät zur Verfügung steht und über
das sogenannte Transmission Control Protocol / Internet Protocol (TCP/IP) betrieben
wird. Dabei handelt sich um einen Verbund vieler Millionen Rechner mit einer enormen
Sammlung von Webseiten, auf denen ein schier unbegrenztes Angebot von Inhalten
publiziert wird. Jeder Mensch, der eine Verbindung zum Internet hat, kann auf Dienste
oder Daten anderer Rechner zugreifen. Wenn man Server-Dienste implementiert,
kann man sehr einfach Informationen und Daten für andere Internetnutzer zur Verfü-
gung stellen.20 Ein häufig gebrauchtes Synonym für Internet ist „World Wide Web“.
Daher stammt auch das Präfix „www“ vor Webseiten. Internet Seiten werden per URL
17 Hein (2008), S. 416.
18 Vgl. Hartlieb (2013), S. 14.
19 Vgl. Springer Gabler Verlag (Hrsg.): Internet - Gabler Wirtschaftslexikon 2015a.
URL: http://wirtschaftslexikon.gabler.de/Definition/internet.html (22.11.2015)
20 Vgl. Horn (1999), S. 11.

7
aufgerufen und verweisen immer auf eine eindeutige Web-Serveradresse. Die welt-
weite Verbreitung und der Vormarsch des Internets können aus der nachfolgenden
Grafik abgelesen werden. So sind für das Jahr 2016 knapp 3,5 Milliarden Internetnut-
zer verzeichnet, was fast der Hälfte der Weltbevölkerung entspricht.
Abbildung 3: Statistik der weltweiten Internetnutzung21
2.2.2 Intranet
Bei einem sogenannten Intranet handelt es sich um ein unternehmens- bzw. organi-
sationsinternes Computernetzwerk. Ein Intranet dient zur Unterstützung unterneh-
mensinterner Prozesse, der Zusammenarbeit und Information von Mitarbeitern.
Datentransfer zwischen Intranet und Internet ist nicht möglich und wird durch eine Fire-
wall reguliert.22 In Unternehmen stehen Informationen des Intranets ausschließlich Mit-
arbeitern zur Verfügung. Intranets helfen dabei ein Problem vieler Unternehmen zu
lösen: Informationen sind zwar in digitaler Form gespeichert, es ist aber ohne das Wis-
sen über deren Existenz und Zugriffspfad schwer, an diese Informationen heranzu-
kommen. Mit Hilfe von Intranets kann ein firmeninternes Kommunikationsnetzwerk als
Diskussions- und Arbeitsforum aufgebaut werden. Die gesamten Geschäftsprozesse
21 Quelle: Statista Inc. Hrsg. v. Statista Inc. URL: https://de.statista.com/statis-
tik/daten/studie/186370/umfrage/anzahl-der-internetnutzer-weltweit-zeitreihe/ (21.04.2017)
22 Vgl. Springer Gabler Verlag (Hrsg.): Intranet. Gabler Wirtschaftslexikon 2015b. URL: http://wirt-
schaftslexikon.gabler.de/Archiv/76679/intranet-v10.html (22.11.2015)

8
von der Produkt- oder Dienstleistungsentwicklung, von der Konzeption über das Mar-
keting, dem Design, der Produktion bis zum Vertrieb und Service hängen von einwand-
frei funktionierender Information und Kommunikation ab. Häufig resultieren
innerbetriebliche Fehlentscheidungen, Irrtümer oder Rückfragen daraus, dass ent-
scheidende Informationen nicht zur Verfügung stehen. Das Intranet stellt die Informa-
tionen jedem Mitarbeiter für seine tägliche Arbeit zur Verfügung. Auch bekommen die
Mitarbeiter die Möglichkeit, dort selber Informationen anzubieten.23
2.2.3 Extranet
Öffnet man ein Intranet für den kontrollierten Zugriff durch externe Partner oder koppelt
es mit deren Intranet, spricht man von einem Extranet. Somit ist die Zusammenarbeit
mit Kunden, Lieferanten und Geschäftspartnern in Firmenbeteiligungen und Joint Ven-
tures möglich.24 Extranets lassen sich technisch mit denselben Funktionalitäten betrei-
ben wie Intranets. Information steht hier sowohl firmenintern als auch ausgewählten
Mitarbeitern von Partnerunternehmen zur Verfügung. Mit Hilfe von Extranets können
Informationen gezielt und zeitgerecht verteilt werden. Preislisten, Rabattstaffeln, Pro-
duktkataloge, Marketingunterlagen, Protokolle usw. können Extranetbenutzern - an-
wenderfreundlich aufbereitet - zur Verfügung gestellt werden. Auch die
Veröffentlichung von News, gemeinsam genutzte Terminkalender, Pinwände, Diskus-
sionsforen und der Dokumentenaustausch sind wesentliche Funktionalitäten von
Extranetsystemen.25 Es ist also Business-to-Business-Kommunikation der Haupt-
zweck von Extranet Netzwerken. Entscheidender Unterschied zum Internet ist, dass
eine Anmeldung nötig ist. Der Zugriff erfolgt typischerweise per Web-Browser mittels
Authentifizierung durch Benutzername und Passwort. Eine zweite Möglichkeit stellt
Anbindung von Partnerunternehmen über abgesicherte Internetverbindungen dar, was
in der Regel durch VPNs (Virtual Private Networks) realisiert wird.26 Im Rahmen dieser
Arbeit werden browserbasierende Extranet Systeme behandelt.
23 Vgl. Block (1999), 211ff
24 Vgl. Block (1999)
25 Vgl. Block (1999), 265ff
26 Vgl. Horn (1999), 265f

9
2.2.4 Unterschiede
Der Hauptunterschied zwischen den Netzwerktypen sind die Zugangsmöglichkeiten.
Das Internet ist öffentlich während Intranet und Extranet nur begrenzen Personenkrei-
sen zur Verfügung stehen. Sicherheitsmaßnahmen wie Passwortschutz, Protokollie-
rung, Verschlüsselung, Firewalls und Anti-Virus Software sollen bei Intranets und
Extranets für ein Höchstmaß an Sicherheit sorgen.
Abbildung 4: Intranet, Extranet und Internet27
2.3 Begriffsdefinition Kollaborationsplattform
Bei einer Kollaborationsplattform handelt es sich um Software, welche eine Sammlung
von Werkzeugen zur Unterstützung des Geschäftslebens zur Verfügung stellt. Diese
Plattform wird möglichst zentral betrieben und hat die Steigerung von Effizienz, Re-
duktion von Fehlern und die Unterstützung von Geschäftsprozessen und bessere und
einfachere Zusammenarbeit von Personen zum Ziel. „Collaboration-Konzepte werden
erst spürbare positive Effekte auf die Unternehmensabläufe haben, wenn sie auch den
Mitarbeitern vermittelt werden.“28 Ein reines Extranet stellt Informationen zentral zur
27 Quelle: Verfasser
28 Christian Galuschka: Collaboration schafft Nähe in der Distanz 2009. URL: http://www.computerwo-
che.de/a/collaboration-schafft-naehe-in-der-distanz (22.11.2015)

10
Verfügung, bei einer Kollaborationsplattform wird den Benutzern ermöglicht, Informa-
tionen jederzeit selbst bereit zu stellen. Das reine Zurverfügungstellen einer Kollabo-
rationsplattform ohne begleitende Analyse der Geschäftsprozesse,
Schulungsmaßnahmen und Marketing ist nach Meinung des Autors von vornherein
zum Scheitern verurteilt. Im Rahmen der Konzeption eines Informatiksystems zur Un-
terstützung unternehmensübergreifender Kollaboration ist vorab die Klärung unter-
schiedlicher Fragen nötig. Es müssen die zu erreichenden Ziele für das System
dargelegt werden, notwendige genauso wie ausgeschlossene Funktionen müssen de-
finiert werden, sowie Rahmenbedingen zur Einhaltung von Governance geklärt wer-
den. Hier ist besonderes Augenmerk auf die Einhaltung rechtlicher
Rahmenbedingungen zu legen. Es ist auch zu klären wie und wo Daten gespeichert
und wie Informationen geschützt werden müssen. Prozesse zur Administration des
Informatiksystems als Ganzes und insbesondere die Verwaltung von Systembenut-
zern und Berechtigungsmanagement sind weitere Betrachtungsobjekte.
2.4 Begriffsdefinition Projekt
Projekte haben einen individuellen Charakter und unterscheiden sich von Routinear-
beiten. Sie sind von zentraler Bedeutung, einzigartig und komplex.29 Oftmals sind sie
gekennzeichnet durch hoch gesteckte Ziele, knappe Ressourcen und eine dynamische
Umwelt. 30 In der Informationstechnologie wird die Entwicklung einer IT-Standard- oder
Individualanwendung, Produktentwicklung oder Anpassungen der Geschäftsorganisa-
tion meist mit Hilfe von Projektmanagement durchgeführt.31 Dazu zählen beispiels-
weise die Entwicklung einer Software, die Einführung oder Weiterentwicklung einer
Lösung für Enterprise Ressource Management, die Umstellung von Anwendungen, die
Migration von Applikationen in die Cloud, die Konzeption und Implementierung einer
komplexen Netzwerktopologie, der Aufbau und die Entwicklung von Internet-, Extra-
net- und Intranet-Portalen, bis zum Bau ganzer Rechenzentren.32 Projektmanagement
ist für viele Unternehmen eine große Hoffnung zur Steigerung von Effizienz und Effek-
tivität. IT-Projektmanager brauchen zwar einen fachlichen Überblick, nicht aber detail-
liertes Fachwissen. Ein guter Projektmanager bewältigt umfangreiche, komplexe
29 Vgl. Kowalski (2007), S. 9.
30 Vgl. Gassmann (2006), S. 6.
31 Vgl. Mourgue d‘Algue et al. (2013), S. 3.
32 Vgl. Tiemeyer (2014), S. 1.

11
Aufgabenstellungen durch Kompetenzen in vier Bereichen. Häufig wachsen Projekt-
manager aus der Rolle als IT-Experte in die Rolle hinein. Somit stellt Fachkompetenz
nicht die große Herausforderung dar, vielmehr sind die drei weiteren, wichtigen Kom-
petenzen des IT-Projektmanagers gefragt: Methodenkompetenz, Sozialkompetenz
und unternehmerische Kompetenz. Methoden, wie Projektplanung, Projektorganisa-
tion, Risikomanagement, Changemanagement oder Controlling lassen sich relativ
schnell erwerben. Die Ausrichtung von Projekten am Unternehmen und seinen Wer-
ten, Kundenorientierung, Kommunikation sowie die Fähigkeit strategisch zu Denken
sind erlernbare Fähigkeiten unternehmerischen Denkens. Projektteamführung, Moti-
vation und Konfliktmanagement stellen neben guter Kommunikation mit Team und Sta-
keholdern die Herausforderungen an die soziale Kompetenz des IT-Projektmanagers,
in den unterschiedlichen Projektphasen, dar.33
Abbildung 5: Übersicht "Kompetenzen des IT-Projektmanagers"34
Nach dem Deutschen Institut für Normung kann ein Projekt wie folgt definiert werden:
„Projekte sind Vorhaben, die im Wesentlichen durch Einmaligkeit der Bedingungen in
33 Vgl. Geipel (2003), 11ff
34 Quelle: Geipel (2003), S. 14. (leicht modifiziert)

12
ihrer Gesamtheit gekennzeichnet sind, wie z. B.: Zielvorgabe, zeitliche, finanzielle, per-
sonelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und
projektspezifische Organisation.“35
Projekte zeichnen sich somit durch folgende Eigenschaften aus:
 Sind von Bedeutung  Klare Zielvorgaben  Komplexität
 Umfang  Bereichsübergreifend  Einmaligkeit
 Zeitlich befristet  Unsicherheit  Ressourcenbegren-
zung
 Projektspezifische
Organisation
 Neuartigkeit  Risiko.36
35 DIN 69901 (69901), zitiert nach Aichele (2006), S. 29.
36 Vgl. Aichele (2006), S. 30.

13
„Je größer das Projekt,
desto stiller wird es begraben.“
Hans-Jürgen Quadbeck-Seeger (*1939), deutscher Chemiker
Projektmanagement für die IT Systementwicklung
3.1 Beschreibung der Phasen des Projektmanagements
„Für IT-Projektmanagement gibt es keine Kochbücher mit Rezepten für die unter-
schiedlichen Situationen.“37 Und doch kann Kochen als Metapher für Projektmanage-
ment herangezogen werden. So sind Überlegungen zu Einladung und Menü
äquivalent mit Aufgaben bei der Projektinitiierung, Planung von Ablauf und Vorberei-
tung können mit Projektplanung verglichen werden. Das Kochen selbst stellt die Rea-
lisierung und die Überlegungen was beim nächsten Mal verbessert werden kann die
Nachbetrachtung dar.38 Projektphasen bilden das Rückgrat von Projekten und schaf-
fen die Voraussetzung für das gemeinsame Verständnis der Projektbeteiligten betref-
fend den Projektablauf. Dies ist eine wichtige Voraussetzung für eine erfolgreiche
organisationsübergreifende Abwicklung. Projekte werden in Projektmanagement-Pha-
sen abgewickelt, wobei die Bezeichnung und Anzahl der Phasen je nach angewandten
Modell unterschiedlich sein können.39 Vielfach wird, in Anlehnung an das Framework
des Project Management Institute (kurz PMI®), von Prozessgruppen oder Prozessab-
läufen gesprochen.40 Diese Arbeit orientiert sich an der Schweizer HERMES 5.1 Pro-
jektmanagementmethode und an der Österreichischen Projekt pm baseline 3.0 und
verwendet deshalb primär den Begriff „Phase“. Zu Beginn und am Ende der Phasen
stehen meist Meilensteine, entscheidende Etappenziele auf dem Weg zu einem klar
definierten Projektziel. Sie zeigen den Fortschritt eines Projektes auf und kennzeich-
nen das Ende einer Abfolge von Arbeitspaketen.41 Entsprechend sollte ihr Erreichen
zumindest in Form eines Projektteam-Meetings zelebriert werden.42 Ein Projekt be-
ginnt somit mit der Phase Initiierung, einem Meilenstein Projektauftrag und endet mit
37 Geipel (2003), S. 15.
38 Vgl. Schellander et al. (2010), 15ff
39 Vgl. Gubelmann/Romano (2011), S. 24.
40 Vgl. Haller/Nägele (2013), 322f
42 Vgl. Meilenstein — Projektmanagement: Definitionen, Einführungen und Vorlagen,
URL: http://www.computerwoche.de/a/collaboration-schafft-naehe-in-der-distanz (21.02.2017)

14
dem Projektabschluss, wobei die Anzahl der Meilensteine je nach Szenario sehr un-
terschiedlich ist.43 Im folgenden Beispiel sind die Bezeichnung von Phasen eines IT-
Systementwicklungsprozesses dem des klassischen Wasserfall Vorgehensmodell und
dem in dieser Arbeit angewandten HERMES Modell gegenübergestellt:
Abbildung 6: Gegenüberstellung von Projektphasen und Bezeichnungen44
Es wird deutlich, dass die Anzahl, Methoden und Granularität von Phasen unterschied-
lich sein können. Projektmanagementphasen beziehungsweise Prozessgruppen kön-
nen sich innerhalb der Lebenszeit des Projektes wiederholen. Bei komplexen
Projekten können Prozesse innerhalb einer Prozessgruppe auch parallel laufen oder
sich überschneiden. So ist es sehr wahrscheinlich, dass innerhalb der Planungs- bzw.
Konzeptionsphase etliche Schritte aus Initiierung, Planung, Durchführung und Ab-
schluss durchlaufen werden. Andere Prozesse können auch weggelassen werden,
wenn sie nicht benötigt werden.45 Vorgehensmodelle bieten eine Zusammenstellung
von aufeinander abgestimmten Prozessen, Methoden, Tools und Techniken um ein
Projektziel strukturiert zu erreichen. Je nach Projektart stehen verschiedene Vorge-
hensmodelle zur Verfügung. Beim Wasserfallmodell handelt es sich um ein sequenti-
elles Modell. Dabei werden die Teilprozesse nacheinander abgearbeitet, d.h. dass
eine neue Phase erst begonnen wird, nachdem die vorhergehende Phase beendet
43 Vgl. Mourgue d‘Algue et al. (2013), 3f
44 Quelle: In Anlehnung an Gubelmann/Romano (2011), S. 24.
45 Vgl. Wagner/Grau (2014), 48f

15
wurde. Auch sollten am Ende einer Phase alle Problemstellungen erkannt und gelöst
sein.46 Nachteil dieser Vorgehensweise ist, dass Änderungen von Anforderungen wäh-
rend des Projektverlaufs, streng betrachtet, kaum vorgesehen sind. Die Abgrenzung
der Phasen ist der Praxis auch schwierig, da sie oftmals ineinanderfließen.47 Die fol-
gende Beschreibung der Phasen des Projektmanagements bezieht sich auf den Pro-
jektlebenszyklus nach dem HERMES Vorgehensmodell. HERMES, ein frei
zugänglicher Standard, wurde von der schweizerischen Bundesverwaltung für die Ab-
wicklung von Projekten im Bereich der Informations- und Kommunikationstechnik ge-
schaffen. Da HERMES für dieses formale Umfeld entwickelt wurde, verfügt das Modell
neben den aus Wasserfall Vorgehensmodellen bekannten Phasen - Initiierung und
Projektabschluss - für das Szenario der IT-Individualanwendung die Phasen Konzep-
tion und Realisierung.48
Exkurs E1: Iterative Vorgehensmodelle
Bei Anwendung iterativer Vorgehensmodelle wird ein Zielsystem Schritt für Schritt
beziehungsweise Modul für Modul entwickelt. Innerhalb dieser Zyklen können sich
Methoden und Entwicklungsschritte wiederholen. Den späteren Systembenutzern
werden Prototypen oder erste Betaversionen des Zielsystems für Tests zur Verfü-
gung gestellt. So können schon recht früh erste Ergebnisse präsentiert werden.49
Spiralmodell
Beim Spiralmodell handelt es sich um ein Vorgehensmodell, dass es erlaubt die Me-
thoden des Wasserfall Modells zu mischen. Über die jeweils angewandten Metho-
den wird bei jedem Durchgang neu entschieden. Ausschlaggebend für die
Entscheidung, welche Methoden im nächsten Iterationszyklus angewandt werden,
sind Ergebnisse von Prototypen, früheren Versionen, neue Technologien, Risikoein-
schränkungen und finanzielle Gesichtspunkte.50 So wird das System (oder Produkt)
stetig zu einem definierten Zustand weiterentwickelt. Durch das kontinuierliche Be-
reitstellen von Prototypen können mögliche Risiken früher erkannt werden. Andere
Vorteile dem klassischen Wasserfallmodell gegenüber sind eine höhere Flexibilität
46 Vgl. Litke (2007), S. 265.
47 Vgl. Gubelmann/Romano (2011), 26ff
48 Vgl. Gubelmann/Romano (2011), 31f
49 Vgl. Kemper et al. (2006), S. 142.
50 Vgl. Goll (2011), 124f

16
und die Möglichkeit schneller auf geänderte Ziele oder Anforderungen zu reagieren.
Da bei jeder Iteration die eingesetzten Methoden neu definiert werden, verbessern
sich die Prozesse stetig. Die Projektbeteiligten benötigen aber eine höhere Metho-
denkompetenz.51
Abbildung 7: Beispiel für ein Spiralmodell52
V-Modell
Ein besonderes Augenmerk auf Qualitätssicherung bei der Softwareentwicklung legt
das sogenannte V-Modell. Es gliedert sich zum einen in konstruktive, analytische
Aktivitäten und zum anderen in prüfende Aktivitäten. In der analytischen Phase wird
der Detaillierungsgrad der Spezifikationen immer höher, bis zur Erreichung des de-
finierten Zieles. Die prüfenden Aktivitäten befassen sich mit dem systematischen
Zusammenbau des Systems, von einzelnen Komponenten bis zum Gesamtsystem.
So wird der Zusammenhang von dokumentierter Spezifikation und Test hergestellt.53
52 Quelle: Gubelmann/Romano (2011), S. 30.(leicht modifiziert)
53 Vgl. Schatten et al. (2010), S. 68.

17
Abbildung 8: Das V-Modell54
Der Zusammenhang von Arbeiten der Planungsphase mit den durchzuführenden
Tests ist anhand dieser Grafik gut ersichtlich. Die zeitliche Abfolge ist ebenfalls er-
kennbar. So wird neuer Code auch gleich getestet und erst am Schluss (nach der
Einführung) wird das System auf seine Akzeptanz bei den Benutzern überprüft.
Rational Unified Process (RUP)
Die in der vorliegenden Arbeit später erwähnten Grady Booch, James Rumbaugh
und Ivar Jacobson entwickelten in den 1990er Jahren den Rational Unified Process.
Die drei Amigos, wie sie auch genannt werden, orientieren sich für ihr Vorgehens-
modell wesentlich an Use-Cases. Ähnlich wie beim Spiralmodell wird das Projektziel
schrittweise, iterativ erreicht. Über das gesamte Projekt hinweg gibt es vier Phasen:
die Konzeptualisierungsphase, die Entwurfsphase, die Konstruktionsphase und ab-
schließend die Übergangsphase. Sogenannte Workflows erstrecken sich aber in un-
terschiedlicher Ausprägung phasenübergreifend. Zu den Haupt-Workflows zählen
die Geschäftsprozessmodellierung, das Anforderungsmanagement, Analyse und
Design, Implementierung, Test und Verteilung.55
54 Quelle: In Anlehnung an ESI International 2012, S. 42.
55 Vgl. Versteegen (2000), 51ff

18
Agile Vorgehensmodelle
Aus dem Manifest für agile Softwareentwicklung gehen etliche Vorgehensmodelle
hervor und agieren nach Prinzipien und Werten die in diesem Manifest niederge-
schrieben sind.56 Folgende Prinzipien wurden entwickelt für flexibles und dynami-
sches Projektmanagement:
– „Individuen und Interaktionen mehr als Prozesse und Werkzeuge
– Funktionierende Software mehr als umfassende Dokumentation
– Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
– Reagieren auf Veränderung mehr als das Befolgen eines Plans“57
Agile Vorgehensmodelle zeichnen sich dadurch aus, dass sie keine Projektphasen
beinhalten, wie sie aus sequentiellen Modellen bekannt sind. Sie werden iterativ ab-
gewickelt, aber im Gegensatz zu klassischen iterativen Modellen sie die Zyklen we-
sentlich kürzer. Über die Anforderungen, die in der nächsten Iteration (Sprint
genannt) umgesetzt werden, wird von den Softwareentwicklern bei jeder Iteration
neu entschieden. Das wohl bekannteste agile Vorgehensmodell ist SCRUM, andere
bekannte Vorgehensmodelle sind Extreme Programming, Feature Driven Develop-
ment oder das Microsoft Solutions Framework.58
3.1.1 Initiierung
Vor dem eigentlichen Projektstart steht die Initiierungsphase. Sie stellt sicher, dass die
Ziele und Strategien des Projektes mit denen der Organisation abgestimmt sind. Der
Projektauftraggeber erteilt dem Projektmanager den Auftrag zur Durchführung der
Phase Initiierung und gibt die dafür nötigen Ressourcen frei.59 Standardisieren lässt
sich diese Phase nicht, ein Grundsatz muss aber unbedingt beachtet werden: "Kein
Projekt ohne Auftrag." In diesem Projektauftrag sollten gewisse Punkte Niederschlag
finden. Ausgehend von der Definition der Problemstellung (AS-IS Situation) sollte das
Ziel definiert werden (AS-IS Situation). Man würde meinen, nur die Zieldefinition sei
schwierig zu formulieren, es zeigt sich häufig, dass die Beschreibung des eigentlichen
Problems mindestens so komplex ist. Oft hilft es, das Problem zu zerlegen, in anderen
56 Vgl. Pröpper (2012), S. 45.
57 Manifest für Agile Softwareentwicklung (2016)

19
Worten oder grafisch zu beschreiben. Sogar Rollenspiele oder der Vergleich des Prob-
lems mit Problemen in völlig anderen Bereichen können bei der Problemdefinition hel-
fen.60 Neben der Formulierung von Zielen ist eine klare Abgrenzung durch Nicht-
Projektziele notwendig, genauso wie der Zusammenhang zu anderen Projekten oder
Programmen. Projektauftraggeber, Projektmanager, Start- und geplanter Endtermin
für das Projekt und relevante Projektumwelten sind auch im Projektauftrag beinhaltet.
Er wird in schriftlicher Form erstellt und dient der Dokumentation der Projekt-Initiie-
rungsphase.61 Die Ergebnisse dieser Phase sind Basis für die Entscheidung, ob ein
Projekt gestartet wird. Es kann durchaus sein, dass auf Grund von Erkenntnissen aus
dieser Phase keine Beauftragung erfolgt.62 Erfolgt die Freigabe, sollte der Projektauf-
trag vom Projektauftraggeber unterschrieben werden. Anschließend werden detail-
lierte Anforderungen an das Zielsystem erhoben und strukturiert in einem sogenannten
Lastenheft dokumentiert.63
Wie bereits erwähnt, gibt es keine Standardisierung für die Aufgaben der Initiierungs-
phase. Eine Übersicht über typische Aufgaben dieser Phase ist aus der folgenden Ta-
belle ersichtlich:
Typische Aufgaben der Projektinitiierung
Projekt Initialisierung leiten Fragen zu Datensicherheit
und Datenschutz erheben
Projektmanagementplan
erstellen
Ziele erarbeiten Stakeholderliste erstellen Projektauftrag erstellen
Nicht-Ziele erarbeiten Aufwands- und Kostenschät-
zung erstellen
Lastenheft erstellen
Zielkonflikte erkennen Rechtsgrundlagen erheben
Projektumfeldanalyse erstellen Anforderungen erheben
Tabelle 1: Typische Aufgaben der Projekt Initiierung64
60 Vgl. Hölzle (2007), 45ff
61 Vgl. Gareis (2006), 283ff
63 Vgl. Hölzle (2007), 81ff
64 Quelle: In Anlehnung an Mourgue d‘Algue et al. (2013), 13ff, 76, 114, 117, und Gubelmann/Romano
(2011), S. 25. sowie Gareis (2006), S. 283.

20
3.1.2 Konzeption
Bei der IT-Systementwicklung werden in der Konzeptionsphase Lösungen für das Ziel-
system65 entwickelt. Eine methodische und systematische Vorgangsweise führt zu den
besten Ergebnissen. Grundlage für die Konzeption ist ein definiertes Ziel und die Be-
schreibung der funktionalen und nicht-funktionalen Anforderungen an das IT-System
in einem Lastenheft.66 In dieser Phase ist ein Projekt maßgeblich beeinflussbar und
gerade deshalb sollte auf eine sorgfältige Projektplanung nicht verzichtet werden. Häu-
fig heißt es: "Wir haben keine Zeit für die Planung, wir müssen gleich loslegen zu ar-
beiten."67 Als Ergebnis aus der Stakeholderanalyse ist bereits bekannt, wer befragt
werden soll, um Anforderungen an die Lösung zu erheben. In dieser Phase finden
verschiedene Projektbeteiligte unterschiedliche Aufgaben vor. Die Projektleitung führt
das Projekt, indem sie die Kommunikation mit den Stakeholdern leitet, Risiken lenkt,
Probleme behandelt und das Änderungsmanagement führt. Lösungsarchitekten erar-
beiten in dieser Phase das Systemkonzept, erarbeiten erste Mockups68 und/oder Pro-
totypen. Auch Testkonzepte, mögliche Migrationspläne und Sicherheitskonzepte
werden in dieser Phase erstellt.69 Ein Ergebnis aus dem Konzeptionsprozesses ist das
Pflichtenheft, in dem das Zielsystem das zur Umsetzung kommen soll genau beschrie-
ben wird. Das Pflichtenheft wird in Kapitel 6 genauer beschrieben. Die Aufgabe der
Pflichtenhefterstellung wir in dieser Phase von einem oder einem Team von Solution-
Architekten erledigt. HERMES spricht von der Rolle IT-System. Die Lösungen aus dem
Pflichtenheft sind Basis für die Erstellung notwendiger Pläne für das Management des
Projektes. So werden Projektstrukturplan, Aufwandsplan, Meilensteinplan, Kosten-
und Ressourcenplan und ein Plan für die Kommunikation erstellt.70
65 Oftmals auch Produkt genannt
66 Vgl. Engeln (2006), 74f
67 Vgl. Kraus/Westermann (2010), S. 187.
68 Der englische Betriff Mockup bezeichnet eine Skizze bzw. ein nicht funktionales Modell zur Veran-
schaulichung einer möglichen Lösung. Für eine schnelle Darstellung einer Benutzeroberfläche eignen
sich Mockups beispielsweise hervorragend. Bei der Konzeption eines Extranet Systems können
Mockups auch relevanten externen Stakeholdern zur Verfügung gestellt werden.
69 Vgl. Mourgue d‘Algue et al. (2013), 13ff

21
Bei HERMES wird in dieser Konzeptionsphase die Aufbau- und Ablauforganisation für
die Geschäftsabwicklung entwickelt.71 Dies bedeutet, dass unter Einbeziehung der
Stakeholder aus der Linienorganisation das mögliche Projektteam zusammengestellt
wird.
Typische Aufgaben der Konzeption
Pflichtenheft erstellen Kosten- und Ressourcenplan
erstellen
Einführungskonzept er-
stellen
Aufwandsplan erstellen Testkonzept erstellen Projektteam zusammen-
stellen
Termin- und Meilensteinplan er-
stellen
System Architekturkonzept
erstellen
Kommunikationsplan
erstellen
Tabelle 2: Typische Aufgaben der Konzeptionsphase72
72 Quelle: In Anlehnung an Mourgue d‘Algue et al. (2013), S. 94. u. Gubelmann/Romano (2011), S. 25.

22
Exkurs E2: Der Projektstrukturplan
Beim Projektstrukturplan (PSP) handelt es sich um ein hierarchisch aufgebautes
Baumdiagramm. Die Darstellung kann dabei prozessorientiert oder objektorientiert
erfolgen. Ziel ist eine möglichst vollständige Gliederung des Projektumfanges für
eine gemeinsame Sichtweise der Mitglieder der Projektorganisation auf das Projekt.
Im Projektstrukturplan werden Arbeitspakete definiert, deren Abarbeitung von den
Mitgliedern des Projektteams verantwortet werden.73
An oberster Stelle, auf der ersten Gliederungsebene steht das Projekt. Auf der zwei-
ten Ebene werden die Phasen beziehungsweise Teilprozesse des Gesamtprojekts
dargestellt. Darunter, ab der dritten Gliederungsebene, erfolgt die Darstellung der
Arbeitspakete.74
Abbildung 9: Beispiel für einen prozessorientierten Projektstrukturplan75
Ein Projektstrukturplan schafft einen systematischen Überblick über die zu erledi-
genden Aufgaben und hilft somit bei der Projektplanung.76
73 Vgl. Gareis (2006), 238f
74 Vgl. Birnstingl et al., S. 29.
75 Quelle: Verfasser
76 Vgl. Kraus/Westermann (2010), S. 23.
Extranet System
Projektmanagem
ent
Projektstart
Projektkoordinati
on
Projektadminstrat
ion
Projektcontrolling
Projektabschluss
Konzeption
Systemanforderu
ngen analysieren
Anforderungsanal
yse
Detailstudie
Systemarchitektur
erarbeiten
Prototyp erstellen
Umsetzung
Infrastruktur
bereitstellen
Betriebssystem
implementieren
Softwarelösungen
entwickeln
Lösungen testen
Verträge
ausarbeiten
Einführung
Dokumentaion
erstellen
Datenmigration
durdchführen
Schulungen
durrchführen
Lösung
präsentieren

23
3.1.3 Umsetzung und Steuerung
In der Umsetzungsphase werden Aufgaben zur Erarbeitung der geplanten Arbeitspa-
kete durchgeführt. Diese Phase wird häufig in Teilprozesse gegliedert.77 Bei HERMES
wird diese Phase Realisierung genannt. Es bietet sich an, diese Phase in einzelne
Schritte zu unterteilen. Bei der Umsetzung eines Webportals beispielsweise wäre ein
Teilprozess die Infrastrukturbereitstellung, ein weiterer die Softwareentwicklung. Auch
das Testen der Lösung und die Einführung bieten sich als Unterphasen an. Die Pro-
jektleitung hat in dieser Phase vornehmlich die Aufgabe das Projekt zu steuern. Dies
geschieht durch Stakeholdermanagement und Führung der Kommunikation und Ma-
nagement der per Risikoanalyse eruierten Risiken. Mögliche Änderungen - in den An-
forderungen oder auf Grund von Nichtrealisierbarkeit - werden auch vom Projektleiter
gesteuert. Eine wesentliche Aufgabe ist das Behandeln von Problemen innerhalb des
Projektteams und im Projektumfeld.78
Typische Aufgaben der Umsetzung und Steuerung
Projekt führen Projektberichte erstellen
Projektkommunikation und Pro-
jektmarketing planen
Testkonzept erstellen
Projektcontrolling durchführen Einführungskonzept erstellen
Tabelle 3: Typische Aufgaben der Umsetzungsphase79
3.1.4 Einführung
Die Einführung eines Systems in den Regelbetrieb stellt eine Phase des Systement-
wicklungsprozesses dar, der häufig unterschätzt und vernachlässigt wird. Für die End-
anwender, die das neue System verwenden sollen, kann die Systemeinführung eine
Veränderung ihrer gewohnten Arbeitsweise darstellen. Das Projektteam wiederum,
beschäftigt sich schon seit geraumer Zeit mit dem System und realisiert möglicher-
weise gar nicht, dass es Schwierigkeiten in der Akzeptanz gibt. Der Transfer von
Knowhow von der Projektorganisation zur Linienorganisation sollte gewissenhaft und
79 Quelle: In Anlehnung an Gubelmann/Romano (2011), S. 25. u. Mourgue d‘Algue et al. (2013), S. 13.

24
bei der Übergabe stattfinden. Geeignete Maßnahmen sind Präsentationen, Schulun-
gen und intensive Begleitung am Arbeitsplatz der Benutzer.80 Auch gut gemachte Hilfs-
mittel können maßgeblich zum Erfolg der Einführung eines Systems beitragen. Bei
einem Webportal bietet es sich beispielsweise an, spezifische Hilfeseiten als Teil des
Portals einzurichten. Dort können häufig gestellte Fragen beantwortet werden und
Schritt-für-Schritt-Anleitungen zur Verfügung gestellt werden. Auch Schulungsvideos
sind ein sehr gut geeignetes Mittel zur einfachen und schnellen Vermittlung von Wis-
sen.81 Selbstverständlich eignet sich ein Betriebshandbuch nach wie vor sehr gut,
heutzutage wird dieses meist in digitaler Form erstellt und zur Verfügung gestellt. Es
ist aber durchaus möglich auf herkömmliche Medien innerhalb eines Unternehmens
zurückzugreifen um die Einführungsphase zu unterstützen. Werbeprospekte, die Un-
ternehmenszeitung, Newsletter, Mailings, Intranet-Beiträge oder sogar kleine Werbe-
artikel82 können hier eingesetzt werden. Wichtig ist dabei, diese Phase genauso
gewissenhaft zu planen und durchzuführen wie die vorangegangenen. Im schlimmsten
Fall liegt ein hervorragendes neues System vor das von nicht akzeptiert wird oder ge-
gen das es sogar massiven Widerstand83 gibt. Bei ganz großen Veränderungen, die
durch ein Projekt hervorgerufen werden, sollten Methoden des Changemanagements
angewandt werden. Dabei handelt es sich um gezielte Maßnahmen um die betroffenen
Organisationen zu befähigen, die durch das Projekt bewirkten Veränderungen in kür-
zester Zeit zu adaptieren und zu leben.84 Das HERMES Modell sieht in der Einfüh-
rungsphase auch die Tätigkeiten des Projektabschlusses vor. In der vorliegenden
Arbeit wird diese Phase nachfolgend getrennt betrachtet.
Typische Aufgaben der Einführung eines Systems
Knowhow-Transfer in die Linien-
organisation durchführen
Öffentlichkeitsarbeit planen
und durchführen
Betriebshandbuch erstel-
len und publizieren
Schulungen planen und durchfüh-
ren
Tabelle 4: Typische Aufgaben der Einführung85
80 Vgl. Kuster (2011), S. 23.
81 Katrin Yonga bei ihrem Webinar zum Thema Video-Trends im Intranet – Inspirationen und Erfol-
gsgeschichten am 04.04.2017.
82 Ein ausgezeichnetes Werbemittel sind sogenannte Stressbälle mit Logo des neuen Systems.
83 Das Projektmarketing sollte bereits während dem Projektverlauf diesbezüglich geeignete Maßnah-
men ergreifen.
84 Vgl. Jenny (2014), S. 685.
85 Quelle: In Anlehnung an Vgl. Kuster (2011), S. 23.

25
3.1.5 Abschluss
Wie schon die Einführungsphase wird auch der Projektabschluss häufig stiefmütterlich
behandelt. Auch abgebrochene oder gescheiterte Projekte benötigen einen Ab-
schluss. Wird diese Phase weggelassen, ist den meisten Stakeholdern nicht bekannt,
ob das Projekt noch im Gange oder bereits abgeschlossen ist.86 Häufig schieben Pro-
jektteam und Projektleiter das Projektende hinaus, es müssen aber alle Tätigkeiten
unternommen werden um das Projekt formell zu beenden.87 Diese Phase beginnt nach
der Abnahme der Projektergebnisse und endet mit der Auflösung des Projektteams.88
„Ziele des Projektabschlussprozesses sind der inhaltliche und emotionale Abschluss
eines Projekts.“89 Dies wird erreicht durch symbolische Handlungen wie beispielsweise
dem Versand von Dankesbriefen oder durch Geschenke an die Projektbeteiligten.
Ganz wichtig ist die Durchführung der Restarbeiten, wie dem Abschließen der Projekt-
dokumentation, Erstellen eines Projektabschlussberichtes und Durchführen eines Pro-
jektabschlussworkshops. Wesentlich ist auch die gemeinsame Beurteilung des
Projekterfolges und Reflexion mit der Frage nach Verbesserungsmöglichkeiten und
daraus resultierende Maßnahmen für nächste Projekte.90 Bei der Beurteilung des Pro-
jekterfolgs sind die Einhaltung von Scope91, Time92 und Budget93 geeignete Kenngrö-
ßen für die Abschließende Erstellung einer Projektabnahme.
Typische Aufgaben des Projektabschlusses
Erstellen der Projektauswertung Erstellen eines Projektab-
schlussberichtes
Erstellen einer Kosten-
Nutzen-Analyse
Planen und durchführen eines Pro-
jektabschlussworkshops
Erstellen und versenden eines
Dankesschreibens
Erarbeiten der „Lessons
Learned“ in Form einer
Leistungsbeurteilung
Erstellen einer Projektabnahme Entlastung und Auflösung der
Projektorganisation
Tabelle 5: Typische Aufgaben des Projektabschlusses94
86 Vgl. Kuster (2011), S. 23.
87 Vgl. Litke (2007), 241f
89 Gareis (2006), S. 386.
90 Vgl. Gareis (2006), 386ff
91 Englische Bezeichnung für Projektumfang
92 Englische Bezeichnung für Zeitrahmen des Projekts
93 Englische Bezeichnung für Budgetrahmen des Projekts
94 Quelle: In Anlehnung an Gareis (2006), 386ff u. Gubelmann/Romano (2011), S. 26.

26
3.2 Methoden-Tailoring für IT-Systementwicklung
Die Zuordnung der Aufgaben in die Projektphasen variieren zwischen den Vorgehens-
modellen.95 Einige Aufgaben wiederholen sich, Konzepte werden im Projetverlauf ver-
ändert. „Generell sind Vorgehensmodelle out of the box nur selten direkt anwendbar,
sondern müssen an spezifische Gegebenheiten einer Organisation oder eines Projekts
angepasst werden.“96 Die Anpassung und Standardisierung von Vorgehensmodellen
wird als Tailoring bezeichnet. Es ist durchaus sinnvoll für ähnliche Projekte ein stan-
dardisiertes Vorgehensmodell zu entwickeln, das dem konkreten Anwendungsbereich
angepasst ist. Die Anpassung des Vorgehensmodells sollte vor Projektstart erfolgen
und für alle Projektmitarbeiter dokumentiert werden.97 Dieses Prozess-Tailoring ist
eine Aufgabe des Projektmanagements und wird im Rahmen der Planungsphase des
klassischen Wasserfallmodells durchgeführt. Es ist möglich, einzelne Schritte zusam-
men zu legen und Werkzeuge und Methoden aus den einzelnen Phasen, je nach An-
forderung, resultierend aus der Projektart und dem Projektziel, auszuwählen und
anzuwenden.98 Häufig stützt sich die Anpassung des Vorgehensmodells auf firmenin-
terne Vorgaben, die sich wiederum meistens auf bekannte Modelle stützen. Auch die
Erfahrungen von Projektmitarbeitern und Projektleitern fließen in den Tailoring-Pro-
zess ein.99
In der Praxis stellt sich häufig heraus, dass sich Anforderungen während des Projekt-
verlaufs ändern und nicht nach der Anforderungsanalyse unverändert bleiben. Nicht
nur Anforderungen können sich ändern, bei Projekten wie der Entwicklung eines kom-
plexen IT-System ist es auch für die Solutions Architekten nicht möglich, alle Lösungs-
möglichkeiten gleich zu erkennen. Vielmehr ergeben sich häufig im Projektverlauf
interessante Lösungsansätze, die wiederum mit dem Kunden beziehungsweise dem
Auftraggeber abgeklärt werden müssen. Dementsprechend sollte auch das Vorge-
hensmodell diesem Umstand angepasst werden. Durch Reflexion und Erfahrungsge-
winn kann das Vorgehensmodell für nächste Projekte weiter verbessert und ergänzt
werden.100
95 Siehe Abbildung 6.
96 Schatten et al. (2010), S. 65.
97 Vgl. Trepper (2012), 11f
98 Vgl. Schatten et al. (2010), 65ff
99 Vgl. Huber et al. (2011), 40f
100 Vgl. Trepper (2012), S. 12.

27
„Wenn ich meine Kunden nach ihren Wünschen gefragt hätte, dann hätten
sie mir gesagt, dass sie gern stärkere Pferde für ihre Kutschen hätten.“
Henry Ford (1863 – 1947), Autopionier
Projektabgrenzung
4.1 Projektumfeld und sachlicher Kontext
Ein Projekt wird in zeitlicher, sachlicher und sozialer Hinsicht abgegrenzt. Über die
zeitliche Abgrenzung durch den Projektstarttermin und den Projektendtermin ergibt
sich mit der Vor- bzw. Nachprojektphase der zeitliche Kontext101 und es wird in sach-
liche und soziale Umfeldfaktoren aufgeteilt. Zu den sachlichen Faktoren zählen das
ökologische, ökonomische, organisatorische, gesellschaftliche, technische und recht-
liche Umfeld.102 Aus den sachlichen Faktoren können die Projektrisiken abgeleitet wer-
den. Identifizierte Stakeholder bilden das soziale Umfeld auf dessen Basis leicht eine
Stakeholderanalyse durchgeführt werden kann.
Abbildung 10: Projektumfeld und sachlicher Kontext103
102 Vgl. Seidl, J.: Jedes Projekt hat auch ein Umfeld 2014. URL: http://gpm-blog.de/jedes-projekt-hat-
auch-ein-umfeld/ (25.03.2017)
103 Quelle: In Anlehnung an Seidl, J.: Jedes Projekt hat auch ein Umfeld, 2014. URL: http://gpm-
blog.de/jedes-projekt-hat-auch-ein-umfeld (25.03.2017)

28
4.2 Projektumfeldanalyse
Vor Beginn der Projektplanung sollte die Projektumfeldanalyse (häufig auch Projekt-
umweltanalyse genannt) vorgenommen werden, um Rahmenbedingungen des Projek-
tes zu erkennen, Stakeholder zu identifizieren und mittels Stakeholderanalyse deren
Einfluss auf und Interesse am Projekt zu beurteilen. „Als Stakeholder werden An-
spruchsgruppen und -personen bezeichnet, die unmittelbaren Einfluss auf den Pro-
jektfortschritt haben und/oder von den Projektzielen direkt oder indirekt betroffen
sind.“104 Der Autor ergänzt die Definition um Personen und Gruppen, die von sich nur
glauben vom Projekt in irgendeiner Weise betroffen zu sein. Projektrisiken können so-
mit leichter erkannt und Maßnahmen abgeleitet werden.105 Es werden interne und ex-
terne Beziehungen eines Projektes betrachtet, die einen maßgeblichen Einfluss auf
den Projekterfolg haben können. Projektteam und Projektmanager werden, weil sie
einen wesentlichen Anteil an Erfolg oder Misserfolg eines Projektes haben, immer als
interne Projekt-Umwelten betrachtet.106 Projektexterne Umwelten sind z.B. Kunden,
Lieferanten, Banken, Behörden, Anrainer, aber auch Bereiche und Abteilungen des
projektdurchführenden Unternehmens. Im Interesse von externen Projektumwelten
liegt in erster Linie liegt das Endergebnis, im Gegensatz zu projektinternen Umwelten,
die einen aktiven Beitrag zu Erfolg oder Misserfolg des Projektes liefern.107 Entschei-
dend ist, dass die relevanten internen und externen Umwelten (Stakeholder) über-
haupt erst erkannt werden, um dann deren positiven oder negativen Einfluss auf das
Projekt zu analysieren und gegebenenfalls Gegenmaßnahmen abzuleiten. Bewährte
Methoden zur Erfassung von Projektumwelten sind Brainstormings oder die Crawford
Slip Technik. Jedenfalls sollten möglichst mehrere Personen in diesem Prozess invol-
viert sein, um ein breites Spektrum an Ideen zu generieren. Dokumentiert wird die
Projektumfeldanalyse zur Erfassung von Stakeholdern grafisch am Computer oder
durchaus auch per Hand, dargestellt als Wolken- oder Segment-Grafik.108
104 Vgl. Tiemeyer (2011), S. 228.
105 Vgl. Badertscher (2004), S. 109.
106 Vgl. Gareis (2006), 276f
108 Vgl. Gareis (2006), 277f

29
Eine Einschätzung darüber wie sich die derzeitige Beziehung der jeweiligen Umwelten
gegenüber dem Projekt darstellen kann durch Smileys bildlich dargestellt werden.
Abbildung 11: Beispiel für grafische Darstellung des Projektumfeldes109
Ein Erfolgskonzept bei der Systementwicklung ist, den Menschen in den Mittelpunkt
zu stellen. Die IT-Systementwicklung verfolgt das Ziel, meist völlig unterschiedliche,
teilweise widersprüchliche, Bedürfnisse von verschiedensten Personengruppen zu be-
friedigen. In einem Projekt kann eine große Anzahl an Stakeholdern auftauchen. Eine
bewähre Methode neue Stakeholder zu finden ist, bereits identifizierte Stakeholder
nach weiteren wichtigen Ansprechpartnern zu fragen.110 Neben den Eigentümern gel-
ten u.a. Manager, Mitarbeiter, Kunden, Lieferanten, Kreditgeber, Parteien, Verbände,
Kirchen, Medien, NGOs und einzelne Bürger als Stakeholder. Auch die Natur muss
gegebenenfalls als Rohstofflieferant und Aufnahmemedium für Abfall als Stakeholder
betrachtet werden.111
Exkurs E3: Die Crawford Slip Technik
Geschichte:
Entwickelt im Jahre 1925 von Dr. Charles C Crawford an der University of Southern
California. Es werden einzelne Zettel verwendet, um möglichst viele Ideen zu gene-
rieren und zu organisieren.
109 Quelle: In Anlehnung an Gareis (2006), S. 277 und Vgl. Birnstingl et al., S. 17.
110 Vgl. Rupp (2014), 79f
111 Vgl. Mödritscher/Mussnig (2013), S. 581.

30
Konzept:
Die Teilnehmer generieren Ideen individuell und diskutieren diese dann, um sie zu
organisieren. Auch Ideen aus externen Quellen können aufgenommen werden.
Methode:
1. Erörterung von Aufgabe und Problem
2. Verteilung von Post-its – ohne Obergrenze
3. Fordern einer Mindestanzahl von Ideen (vielleicht 5 um zu beginnen) – Eine
Idee pro Slip, in der Stille geschrieben
4. Dann fordern von noch mehr Ideen, zumindest eine mehr – pushen der Teil-
nehmer kreativ zu sein
5. Wenn auch externe Ideen eingeführt werden, ist es jetzt an der Zeit, dies zu
tun
6. Das Team sortiert die Ideen in Kategorien (die nicht am Anfang vorgegeben
werden) - Interaktion wird an dieser Stelle gefördert
7. Gruppieren in breitere Themen – Beschriftung mit einem größeren oder far-
bigen Slip
8. Gruppendiskussion: „Was sagt uns das?“
Vorteile:
Enthält alle Persönlichkeitstypen in der Erzeugung von Ideen durch die Schaffung
einer druckfreien Umgebung zur Ideengenerierung. Eine ausgezeichnete Methode
zur Kategorisierung und Organisation von Daten aus verschiedenen Quellen.
Nachteile:
Einige Ideen können sehr ähnlich sein. Es gibt keine Diskussion während der Erzeu-
gungsphase, so dass die Kreativität, aus den Ideen anderer zu ziehen, verloren geht.
Variationen:
Brainstorming-Sitzung zwischen den Schritten 4 und 5.
Beispiel:
Schaffung eines Risikomanagementplans. Eine Gruppe von Experten wird versam-
melt - acht in einem Raum und zwei per Videokonferenz. Alle Risiken müssen eruiert
werden. Jede Person im Raum erhält 20 Zettel Papier, und die entfernten Experten

31
wurden gebeten, 20 Risiken über den Internet-Chat einzureichen (die vom Modera-
tor transkribiert werden). Die Gruppe im Raum wird dann gebeten, die Slips zu ka-
tegorisieren, und die Gruppierungen werden mit den zwei entfernten Teilnehmern
diskutiert. Der Moderator leitet eine Diskussion deren Ergebnisse als Input zum Ri-
sikomanagementplan verwendet werden.112
4.3 Stakeholderanalyse
Die Ausgangssituation erschließt sich nach erfolgter Identifikation der Stakeholder per
Umfeldanalyse, nun müssen weitere Prozessschritte durchlaufen werden. Beginnend
mit der Sammlung von Informationen zu den identifizierten Stakeholdern mit anschlie-
ßender Analyse und Bewertung ergeben sich die Ziele, gefolgt von der Planung von
Maßnahmen. Während des gesamten Projektverlaufs müssen diese Maßnahmen auf
ihre Wirkung überprüft werden.113 Eine systematische Erfassung und Dokumentation
von relevanten Informationen über Stakeholder ist empfehlenswert. Eine bewährte Me-
thode ist die tabellarische Erfassung der Stakeholder in Excel, sie kann aber auch aus
Karteikarten je Stakeholder bestehen oder bei großen Projekten sogar über ein Daten-
bankerfassungssystem erfolgen.114 Ein Beispiel für eine Stakeholdertabelle am Ende
dieses Kapitels zu finden. Jedenfalls sind die folgenden Informationen je Stakeholder
zu eruieren und systematisch zu dokumentieren:115
 Name
 Funktion (Rolle)
 weitere Personen- und Kontaktdaten
 zeitliche und räumliche Verfügbarkeit während der Projektlaufzeit116
 Auftrag/Zielsetzungen117
 Bewertung von Interesse (Motivation) und Einfluss der Stakeholder
o Wie groß ist der Wille der Stakeholder, ihre Anforderungen und Erwartun-
gen an das Projekt durchzusetzen?
112 Neil Shorney in seinem Vortrag „Problem/Opportunity Identification and Analysis“, gehalten am
21.03.2017 anlässlich einer Konferenz zu „Critical Thinking and Problemsolfing“ in London, Mitschrift
des des Verfassers.
113 Vgl. Tiemeyer (2014), S. 620.
114 Vgl. Rupp (2014), S. 81.
115 Vgl. Tiemeyer (2011), S. 229.
116 Vgl. Rupp (2014), 81
117 Vgl. Tiemeyer (2011), 229f

32
o Wie groß ist die Macht der Stakeholder, ihre Anforderungen und Erwartun-
gen an das Projekt durchzusetzen?118
 Chancen, Interessen, Anforderungen
 Risiken, Konfliktpotentiale119
Wenn noch zusätzliche Informationen zur Verfügung stehen, sollen diese ergänzt wer-
den.
Beispiele:
 Entscheidungsbefugnis
 Bevorzugte Kommunikationsmittel (Email, Telefon, Medien, Social Media120, Post)
 Beziehungen und Abgrenzung verschiedener Stakeholder
 Begründung der Stakeholderauswahl für bestimmte Rolle im Projekt121
Stakeholder die die gleichen Interessen verfolgen, können anhand festgelegter Krite-
rien zu einer Gruppe zusammengefasst werden.122
4.3.1 Ermittlung von Auftrag und Zielsetzungen der Stakeholder
Jeder ermittelte Stakeholder hat eine Rolle oder einen Auftrag in Bezug auf das Pro-
jekt, die es zu ermitteln gibt. Das ist eine wichtige und zugleich schwierige Aufgabe.123
Hierzu können unterschiedliche Methoden und Tools herangezogen werden. Inter-
views mit Betroffenen, Umfragen und Prozessanalysen gilt es hier als bewährte Mittel
zu nennen.124 Abhängig von Rolle und Auftrag, verfolgen Stakeholder unterschiedliche
persönliche Ziele in Bezug auf das Projekt.
Exkurs E4: Befragungs- bzw. Erhebungstechniken
Übersicht:
Populäre Techniken zur Erhebung von Anforderungen sind Interviews und Umfra-
gen. Damit lassen sich schnell eine große Menge an Informationen sammeln.
118 Vgl. Badertscher (2004), S. 112.
120 Beispielsweise sind auch betroffene Bürger Stakeholder mit denen kommuniziert werden soll.
121 Vgl. Rupp (2014), S. 82.
122 Vgl. Hanschke et al. (2016), S. 323.
123 Vgl. Tiemeyer (2011), 110fVgl. Tiemeyer (2014), S. 229.
124 Vgl. Tiemeyer (2014), S. 229.

33
Interviews:
Interviews sind eine der am häufigsten angewandten Techniken für die Erhebung
von Anfordernissen. Grundsätzlich gibt es zwei wesentliche Arten von Interviews:
Informationsgespräche und Fragebogen.
Die Art und Reihenfolge der Fragen kann einen wesentlichen Einflussfaktor auf den
Erfolg eines Interviews haben. Für Informationsgespräche sind folgende vier Fra-
genkategorien zu beachten:
 Offene Fragen: Lässt eine ausführliche Antwort erwarten und ermutigt den
Interviewten Informationen zu teilen, Ideen zu erläutern oder bei Themen ins
Detail zu gehen. Bei sehr redseligen Gesprächspartnern ist diese Fragen-
technik sparsam einzusetzen. Viele Fragen starten mit „was, weshalb, wie,
erzählen Sie mir“.
 Geschlossene Fragen: Lässt eine einfache, auf den Punkt gebrachte Antwort
erwarten. Idealerweise folgt auf sie sie ein ja oder nein. Werden verwendet
um klare Antworten zu erhalten, gleiches Verständnis abzufragen oder ein
bestimmtes Detail zu erfahren. Viele Fragen beinhalten die Fragewörter „wel-
ches, wer, wo, wie viele, wie oft“. Bei schüchternen Gesprächspartnern für
diese Fragetechnik oft zu wenig informationsgewinn.
 Klärungsfragen: Diese Fragen werden verwendet um weitere Details oder Ab-
klärungen vom Interviewten zu erfahren. Sie stellen sicher, dass der Intervie-
wer das Gesagte richtig verstanden hat und demonstrieren auch Respekt
gegenüber der interviewten Person. Diese Fragen sind insbesondere bei lin-
guistischen oder kulturellen Unterschieden wichtig. Oftmals starten diese Fra-
gen mit „Können Sie mir ein Beispiel …“
 Bestätigungsfragen: Diese Fragen werden gestellt um eine Bestätigung zu
erhalten, die Essenz des Gesagten auch verstanden zu haben. Eine gute Me-
thode ist das gehörte in anderen Worten zu paraphrasieren. Diese Fragen
helfen dabei, ein Bewusstsein für Konsens oder Dissens zu schaffen.

34
Bei der Durchführung von Interviews ist eine allgemeine Strategie, mit offenen Fra-
gen zu beginnen und die Antworten mit geschlossenen Fragen einzugrenzen. An-
schließen helfen klärende Fragen um Beispiele, Definitionen und Ausnahmen zu
erfahren. Und schließlich, um das gegenseitige Verstehen zu bestätigen, werden
Klärungs- und Bestätigungsfragen verwendet. Falls Probleme erkannt werden, kann
einfach ein Schritt in der Fragetechnik zurückgegangen werden.
Einige allgemeine Richtlinien für die Befragung sind:
 Vereinbarung des Interviews vorab und pünktliches Erscheinen
 Schriftliche Vorbereitung der Fragen
 Nicht unterbrechen
 Kontrolle über Situation bleibt beim Interviewer um Abschweifen zu verhin-
dern
 Interviewer soll bestimmt aber nicht anmaßend auftreten
 Bedanken für die Zeit nach Beendigung des Interviews
Erfolgreiche Interviews hängen von guter Vorbereitung, Flexibilität, Fragenqualität
und Strategie ab. Aber auch Umweltfaktoren, die rasche Dokumentation der Resul-
tate und die Verwendung von Bestätigungsfragen stellen wesentliche Erfolgsfakto-
ren dar.
Fragebogen:
Fragebogen stellen eine weniger persönliche Möglichkeit zur Informationssammlung
als Interviews dar und sind besser geeignet um Probleme systematisch zu eruieren
und Meinungen und bevorzugte Optionen von großen Mengen an Personen zu er-
heben. Bei der Entwicklung von Fragebögen sollte das Analyseteam folgende
Schritte durchführen:
 Klar definiertes Ziel, um Umfragedesign auf dem richtigen Weg zu halten.
 Nur Fragen, die direkt auf die Umfrageziele eingehen. Vermeidung von Fra-
gen über Dinge, die nur "interessant zu wissen" wären.
 Planung der Ergebnisanalyse für den Fragebogen. Wenn es nicht planbar ist,
wie eine Frage analysiert wird oder wie die Informationen nutzbar sind, sollte
die Frage verworfen werden.

35
 Lange Fragebögen bekommen weniger Antworten als kurze. Der effektivste
Weg zur Erhöhung der Antwortrate zu erhöhen ist, den Fragebogen kurz zu
halten.
 Erstellung einer gut geschriebenen Einleitung oder Anschreibens. Das schafft
Vertrauen in die Sinnhaftigkeit der Umfrage und erhöht die Chance einer Ant-
wort. Formulierung von klaren Anweisungen zum Ausfüllen und Retournieren
des Fragebogens.
 Für die Vollendung des Fragebogens danken.
 Einen sinnvollen Anreiz für die Vollendung des Fragebogens geben.
 Verwenden einer Terminologie, die dem Benutzer vertraut ist.
 Positive Fragen verwenden; Vermeidung von Negativen.
 Fragen zu sensiblen Themen sorgfältig planen (ggf. Anonymität oder Vertrau-
lichkeit für den Befragten).
 Vermeiden von Vorurteilen.
 Vermeiden von führenden Fragen.
 Von einfachen zu komplexeren Fragen fortschreiten.
 Wenn Kommentare angemessen sind, sollte genügend Platz dafür gelassen
werden.
Die Art der gestellten Fragen hat einen wesentlichen Einfluss auf den Erfolg einer
Umfrage. Folgende sechs Antworttypen gelten als wesentlich:
 Entscheidung - Befragte können zwischen zwei Antwortmöglichkeiten wäh-
len.
 Auswahl - Dieser Fragetyp ermöglicht es Befragten, aus einer vordefinierten
Liste von Auswahlmöglichkeiten auszuwählen.
 Bewertungsskala - Dieser Fragetyp bietet eine Zusammenfassungsfrage mit
detaillierten Fragen und Antworten, die auf einer Skala bewertet werden. Sie
können den Bereich der Skala definieren, z. B. 1 bis 5 oder 1 bis 10, und Text
zum Erklären der Bedeutung der Skala bereitstellen.
 Paarweise Assoziationen – Befragte können aus zwei spezifischen Alternati-
ven die geeignetste wählen. Dies ist eine sehr effektive Methode, wenn Alter-
nativen in verschiedenen Varianten gepaart werden.

36
Beispiel: Welches der folgenden Wortpaare beschreibt Ihr Restaurant am
besten?
 _____ laut _____ lebendig
 _____ überfüllt _____ populär
 _____ lebendig _____ spannend
 Sortieren – Die Befragten sortieren nach einem bestimmten Kriterium.
 Offene Frage – Die Befragten werden aufgefordert Kommentare in Textform
abzugeben. Diese Frageform zieht einen großen Aufwand bei der Analyse
nach sich.
Fragebögen gibt es entweder in gedruckter Form oder webbasiert. Webbasierte Be-
fragungen bieten die Möglichkeit, eine breite Anzahl von Befragten schnell zu errei-
chen und sie können mit automatischen Scoring-Tools jederzeit, auch
zwischenzeitlich, ausgewertet werden. Papier-Umfragen können wiederum jederzeit
und überall, ohne spezielle Ausrüstung ausgefüllt werden.125
4.3.2 Bewertung von Interesse und Einfluss der Stakeholder
Je nach Interesse und Einfluss eines Stakeholders, seine Erwartungen und Anforde-
rungen an das Projekt durchzusetzen, müssen unterschiedliche Maßnahmen und In-
strumente des Projektmarketings eingesetzt werden.126 Ein adäquates Mittel zur
Klassifizierung von Stakeholdern ist eine Einfluss-Interessen-Matrix. Hier werden die
Stakeholder je nach Höhe von Interesse und Einfluss auf das Projekt in einen von vier
Quadranten eingetragen. Dieses Modell hilft dabei, die richtigen Maßnahmen zur Sta-
keholderpflege zu treffen, anstatt nach dem Gießkannenprinzip vorzugehen.127
125 Vgl. ESI International 2013b, 77ff
126 Vgl. Rupp (2014), S. 112.
127 Vgl. Rupp (2014), S. 82.

37
Abbildung 12: Einfluss-Interessen-Matrix128
Werden alle Stakeholder, entsprechend ihrer Einstellung und Einflussstärke, in die Ein-
fluss-Interessen-Matrix eingezeichnet, erhält man eine Stakeholder-Portfolio-Darstel-
lung. Diese stellt den IST-Zustand dar. Zusammen mit dem SOLL-Zustand bildet diese
die Grundlage für die Ableitung von Maßnahmen.129
4.3.3 Chancen und Risiken
Bei der Untersuchung, welche Chancen und Risiken die einzelnen Beteiligten in dem
Projekt sehen, geht es in erster Linie um die Frage ob sie das Projekt unterstützen. Im
Extremfall können Stakeholder deren Interessen zu wenig Augenmerk geschenkt wird
sogar massiv gegen das Projekt vorgehen.130 Werden Stakeholder vergessen oder
Bedürfnisse von Personen oder Gruppen die ein Interesse an einem Projekt haben
ignoriert, kann das zu teuren Change-Requests oder im Extremfall sogar zu geschei-
terten Projekten führen.131
128 Quelle: Vgl. Führer/Züger (2010), S. 51. (leicht modifiziert)
130 Vgl. Tiemeyer (2011), S. 229.
131 Vgl. Rupp (2014), 79f

38
4.3.4 Ableitung von Maßnahmen
Die Auswahl, welche Instrumente und Maßnahmen zur Behandlung von Stakeholdern
nötig sind, hängt von deren Einfluss und Interesse ab.132 Bei der Ableitung von Maß-
nahmen und Strategien aus der Stakeholderanalyse wird zwischen Sofortmaßnahmen
und Vorsorgeplänen unterschieden. Vorsorgepläne treten nur bei Eintritt eines defi-
nierten Ereignisses in Kraft. Hier muss nicht nur der richtige Zeitpunkt für deren Akti-
vierung beachtet werden, sondern auch alle notwendigen Vorarbeiten geleistet
wurden. Grundsätzlich werden drei unterschiedliche Strategien beim Umgang mit Sta-
keholdern angewandt:
 Partizipatives Vorgehen durch Einbinden in Entscheidungsfindungsprozesse.
 Diskursives Vorgehen durch Diskussion möglicher Lösungen und Austragen von
Konflikten.
 Repressives Vorgehen durch Stellen vor vollendete Tatsachen.133
Wie in Kapitel 4.3.2 „Bewertung von Interessen und Einfluss der Stakeholder“ be-
schrieben, werden Stakeholder entsprechend kategorisiert.
132 Vgl. Führer/Züger (2010), 53
133 Vgl. Tiemeyer (2014), 618ff

39
Daraus lassen sich sehr einfach Instrumente für adäquate Maßnahmen des Projekt-
marketings ableiten:
Zufriedenstellen
Beschreibung Stakeholder
 Interesse schwer einzuschätzen
 Passives Verhalten
 Geringes Interesse an Details zum
Projekt
 Haben die Macht, entscheidend auf
das Projekt einzuwirken
 Typische Vertreter: Auftraggeber,
Projektkunden
Maßnahmen
 Einbinden in wichtige Planungen
und Entscheidungen
 Systematisch in den Informations-
fluss einbeziehen
 Regelmäßiger persönlicher Kontakt
Kooperation
 Hohes Interesse an Verlauf und Er-
gebnissen des Projekts
 Verfügen über großen Einfluss auf
Erfolg oder Misserfolg des Projektes
 Typische Vertreter: Projektkunden,
Lieferanten
Maßnahmen
 Einbinden in Planung und Entschei-
dungen
fluss einbeziehen
 Einen tiefen Einblick in das Projekt
geben
 Regelmäßiger persönlicher Kontakt
Keine besonderen Aktivitäten
 Geringes Interesse am Projekt
 Verfügen über geringen Einfluss auf
 Typische Vertreter: Personen aus
der Öffentlichkeit oder von anderen
Unternehmen
Maßnahmen
 Allgemein informieren
 Präsentationen, Veranstaltungen
Regelmäßig informieren
 Hohes Interesse an Verlauf und Er-
gebnissen des Projekts
 Verfügen über geringen Einfluss auf
 Typische Vertreter: Medien, Koope-
rationspartner, Verkaufspersonal
Maßnahmen
fluss einbeziehen
Tabelle 6: Maßnahmen des Projektmarketings134
Die Pflege der Beziehungen zu den einzelnen Stakeholdern wird durch Einsatz von
Projektmarketinginstrumenten gestaltet. Hier wird unterschieden zwischen Geschrie-
benem und Gesprochenem. Interne Stakeholder werden informiert durch ein Projekt-
handbuch mit Projektnamen, -logo und bei größeren Projekten eigenem Briefpapier.
134 Quelle: Eigene Darstellung in Anlehnung an Badertscher (2004), S. 112. und Rupp (2014), 82f

40
Bei kleineren Projekten reichen Präsentationen, Informationen am Schwarzen Brett,
Intranet, Rundschreiben oder Newsletter aus. Projektmeetings, Workshops aber auch
Feste, Events und Ausflüge sind übliche Mittel des internen Projektmarketings.
Für die Information von externen Stakeholdern bieten sich Presseberichte, Präsenta-
tionen, Postwurfsendungen, ein Tag der offenen Tür, Umfragen, aber auch persönliche
Gespräche an. Die Verteilung von Merchandisingartikeln, Sponsoring von Veranstal-
tungen oder Lobbying sind gängige Methoden des Projektmarketings und tragen zur
Erreichung des SOLL-Zustandes bei. Persönliches Feedback, Umfrageergebnisse o-
der Rücklaufquoten lassen Rückschlüsse auf die Wirksamkeit der Maßnahmen zu.135
Die gesammelten Informationen aus Projektumfeldanalyse (Finden der relevanten
Stakeholder) und anschließender Stakeholderanalyse (Betrachtung und Behandlung
der Stakeholder) werden abschließend beispielsweise mittels Stakeholdertabelle do-
kumentiert.
135 Vgl. Führer/Züger (2010), 53f

41
Die ermittelten Informationen können in eine Stakeholdertabelle, wie folgt übertragen werden:
Stakeholder Name Stellung/Funktion Auftrag, Rolle Ziele
Chancen/Risiken,
Interessen, Kon-
fliktpotentiale, Er-
wartungen,
Anforderungen
Einfluss/Inte-
resse, Bewertung
von Stärke (Kate-
gorie)
Maßnahmen
Auftraggeber Max Muster-
mann
CFO Mitglied Steuerungs-
ausschuss,
Projektbudget über-
wachen,
Projektfortschritt
überwachen,
Projektbudget
einhalten,
persönlichen Auf-
wand geringhal-
ten,
Projektziel errei-
chen,
hohe Erwartungs-
haltung,
möchte jederzeit
über Kosten im
Bilde sein,
Keine Involvierung
in Details,
Hoher Einfluss /
Geringes Inte-
resse = Kategorie
B
(zufriedenstellen)
jede Woche Bericht
zu Projektfinanzen
per Mail,
in alle wichtigen Pla-
nungs- und Entschei-
dungs-prozesse
einbeziehen,
Betroffene
Sachbearbeiter
Claudia Mül-
ler
Angestellte Benutzerin hervorragende
Arbeitsleistung
erbringen,
Entwicklungs-mög-
lichkeit durch
neues System,
Geringer Einfluss
/ Hohes Interesse
= Kategorie C
(regelmäßig infor-
mieren)
Systematisch in den
Informationsfluss mit
einbeziehen durch
Projektstatusbe-
richte,
Tabelle 7: Beispiel einer Stakeholdertabelle136
136 Quelle: In Anlehnung an Vgl. Badertscher (2004), 110ff und Vgl. Tiemeyer (2011), S. 230.

42
4.4 Risikoidentifikation und -analyse
4.4.1 Risikoidentifikation
Wie aus Abbildung 10 „Projektumfeld und sachlicher Kontext“ ersichtlich, können aus
dem sachlichen Kontext eines Projektes Maßnahmen zur Vermeidung von Risiken o-
der zur Verminderung von Risikoauswirkungen abgeleitet werden.137 Ein Risiko wird
definiert als Möglichkeit einer negativen oder positiven Projektabweichung. Dadurch,
dass positive Risiken nicht als solche erkannt werden, gehen oftmals wesentliche Po-
tentiale in Projekten verloren. Wegen ihrer Einmaligkeit, Komplexität und Dynamik ha-
ben Projekte viele Risiken.138 Jedes aktive Handeln beinhaltet ein Risiko, d.h. die
Gefahr eines Versagens oder Verlustes. Das Risiko entsteht aus der Abweichung von
Erwartungen zu Realität, sowohl bei Handlungen als auch bei deren Randbedingun-
gen. Diese Erwartungen sind im Allgemeinen unsicher, sei es, weil sie ungeklärt sind,
sei es, weil die erforderlichen Informationen nicht vorliegen. Das Risiko ist ein Ereignis,
das mit einer gewissen Wahrscheinlichkeit (W) eintritt und im Projekt bei Eintritt einen
Schaden mit definierter Tragweite (T) verursachen würde. Der erwartete Schaden lässt
sich also als W*T darstellen. Risikomanagement ist ein integrierter Bestandteil der Pla-
nung, Überwachung und Steuerung von Projekten. Aufgabe des Risikomanagements
ist es, die Risikokosten des Projektes zu minimieren.139 Nicht nur das Erkennen von
Risiken ist wichtig, sondern auch deren Bewertung und Behandlung.140 Die Identifika-
tion von Risiken sollte im Team durchgeführt werden, sehr gut geeignet ist hierfür ei-
nen Workshop durchzuführen.141
137 Vgl. Risikomanagement – Chancen zum proaktiven Handeln nutzen. URL: http://gpm-
blog.de/risikomanagement-projektmanagement, (26.03.2017)
138 Vgl. Gareis (2006), S. 301.
139 Vgl. Gassmann (2006), 77ff
141 Vgl. Jenny (2014)

43
Ziele des Risikomanagements sind die Vermeidung von erkennbaren negativen Risi-
ken, Absicherung gegen unvermeidbare Risiken und die Abschätzung des Projektge-
samtrisikos.142 Der Prozess des Risikomanagements erfolgt in folgenden Schritten:
1. Risikoidentifikation
2. Risikoanalyse mit Bewertung
3. Risikobehandlung mit Suche und Einleitung von Maßnahmen
Die Überprüfung der ergriffenen Maßnahmen nach deren Wirkung und Neubeurteilung
der Situation stellen ergänzende Tätigkeiten dar.143 Neben der Identifikation anhand
der Ergebnisse aus der Projektumfeldanalyse, können Risiken auch durch Betrach-
tung von Arbeitspaketen144 oder der Projektbetrachtungsobjekte eruiert werden.145 Für
eine Risikoanalyse sind nur Phasen und Arbeitspakete heranzuziehen, für die Risiken
möglich sind.146
Exkurs E5: Der Betrachtungsobjekteplan
Der Betrachtungsobjekteplan ist eine strukturierte, grafische oder tabellarische Darstellung
von Objekten die während eines Projektes berücksichtigt werden müssen. Ziel ist Schaffung
eines gemeinsamen Bildes für Stakeholder. Betrachtet werden materielle (Hardware, Mate-
rial, Unterlagen) sowie immaterielle Objekte, wie beispielsweise Software, Kundenbezie-
hung, (fehlende) fachliche Fähigkeiten oder Finanzierung. Eine vielfach bewährte Methode
für die Dokumentation von Betrachtungsobjekten ist Mindmapping.147
4.4.2 Risikoanalyse
Die Risikoanalyse wird gerne in tabellarischer Form analog zur Stakeholdertabelle dar-
gestellt. Neben der Bezeichnung des Arbeitspakets wird das Risiko beschrieben. Wei-
terer Bestandteil der Tabelle ist die Beschreibung der Abweichung. Eine Bewertung
möglicher Folgen kann mittels einer Skala (-2 für positive Abweichungen bis +2 für
142 Vgl. Führer/Züger (2010), S. 134.
143 Vgl. Rohrschneider (2006), 26f
144 Aufgabenstellung innerhalb eines Projektes für das es einen Verantwortlichen gibt.
145 Vgl. Gareis (2006), S. 305.
146 Vgl. Gareis (2006), S. 307.

44
negative Risiken) oder in Kosten in € erfolgen. Ein weiterer Gesichtspunkt der erfasst
wird, ist die Eintrittswahrscheinlichkeit. Diese kann in Prozent oder mit niedrig, mittel
und hoch angegeben werden.148 Die so erfassten Informationen erfassen zwar alle
identifizierten Risiken, deren Folgen und die Eintrittswahrscheinlichkeit. Um aber ge-
eignete Maßnahmen auch zu priorisieren, müssen die möglichen Kosten bei Eintritt
des Risikos im Verhältnis zur Eintrittswahrscheinlichkeit betrachtet werden. Dies wird
folgendermaßen gemacht:
1. Aus der Multiplikation von Kosten in € mit der Eintrittswahrscheinlichkeit in Prozent
ergibt sich die Risikokennzahl.
2. Risiken anhand der Risikokennzahl absteigend sortieren. Somit stehen die rele-
vantesten Risiken ganz oben.
3. Festlegung eines Schwellenwertes zur Feststellung für welche Risiken Maßnah-
men ergriffen werden müssen. Beispielsweise kann beschlossen werden, dass alle
Risiken mit einer Risikokennzahl die höher als 100 ist, behandelt werden müs-
sen.149
Ein Beispiel für eine Risikoanalyse mit Priorisierung durch Ermittlung der Risikokenn-
zahl zeigt die folgende Tabelle. Diese Kennzahl stellt eine statistische Größe dar, nicht
die verursachten Kosten.
148 Vgl. Gareis (2006), 307ff
149 Vgl. Tiemeyer (2014), S. 227.

45
Tabelle 8: Risikoanalyse und risikopolitische Maßnahmen150
Diese Tabelle zeigt auf, dass beispielsweise das Risiko ein System nicht in der Cloud
implementieren zu können, höhere Kosten verursachen würde, als das Risiko auf
Grund von Kündigungen externe Ressourcen zukaufen zu müssen. Trotzdem weist
dieses Risiko eine höhere Kennzahl auf. Diese höhere Kennzahl ergibt sich aus hö-
heren Eintrittswahrscheinlichkeit.
150 Quelle: In Anlehnung an Vgl. Gareis (2006), 308ff
Bezeichnung Risiko
Beschreibung
Abweichung
Kosten in
€ 1000
Eintrittswahr-
scheinlichkeit
in Prozent
Risiko-
kennzahl
Datensicherung Datensicherung ist
inkompatibel
Neue Software für
Datensicherung müsse
beeschafft werden
500 40 200
Business Analyse Ressourcen stehen
nicht rechtzeitig
zur Verfügung
Externe Ressourcen müssten
zugekauft werden 150 60 90
Systementwicklung Softwareentwickler
kündigen
Externe Ressourcen müssten
zugekauft werden 120 60 72
Implementierung
Cloud
Neue Betriebs-
vereinbarung wird
vereinbart
System kann nicht in Cloud
implementiert werden 150 40 60
Datensicherheit Anti Virus ist
inkompatibel
Neue Software für Virenschutz
müsste beschafft werden
20 60 12

46
„Will ich ein Blatt beschreiben, steht schon was drauf.“
Manfred Hinrich (1926 - 2015), deutscher Philosoph
Anforderungsanalyse
5.1 Einordnung und Aufbau eines Lastenhefts
Kapitel vier hat sich hauptsächlich mit dem Projektumfeld, der Frage nach dem
„WER?“ befasst. Im Fokus dieses Kapitels wird hauptsächlich die Frage nach dem
„WAS?“ stehen, den Anforderungen der vorher erhobenen und analysierten Stakehol-
der. Als Methode für deren Erhebung kommt die Anforderungsanalyse zum Einsatz.
Die Dokumentation erfolgt in einem Lastenheft. Die Qualität einer Lösung hängt we-
sentlich von der Qualität von Lasten- und Pflichtenheft ab.151 Die beiden Dokumente
können als zeitlich aufeinander folgende Versionen des gleichen Dokuments gesehen
werden: erst das Lastenheft mit den Anforderungen, und in Folge strukturgleich das
Pflichtenheft als Basis für Entwicklung und Implementierung. Häufig ist ein wesentli-
cher Unterschied der Verfasser des Dokuments. Das Lastenheft wird meist vom Auf-
traggeber verfasst, das Pflichtenheft vom Kunden.152 In größeren Unternehmen ist die
Erstellung der Dokumente auch unterschiedlichen Personen zugeordnet. Die Anforde-
rungen an ein System werden von Requirements Engineer erhoben und im Lastenheft
dokumentiert, das Pflichtenheft wird von Lösungs-Architekten (engl. Solution Architect)
erstellt. Im Lastenheft werden die Anforderungen des Auftraggebers sowie alle Rah-
menbedingungen spezifiziert und dokumentiert.153 Aufbau und Inhalt des Lastenhefts
sind:
1. Ausgangssituation
2. Zielsetzung
3. Rahmenbedingungen
4. Funktionale und nichtfunktionale Anforderungen
5. Umfang
6. Projektphasen und Meilensteine
7. Offene Punkte
8. Abnahmekriterien und Qualitätsanforderungen154
151 Vgl. Teich et al. (2008), S. 55.
153 Vgl. Schwinn (2011), S. 165.
154 Vgl. Karavul, B. Hrsg. v. TRUECARE® GmbH: Projektmanagement Handbuch 2015. URL:
http://www.projektmanagementhandbuch.de/projektplanung/lastenheft/, (11.03.2017)

Konzeptentwicklung von IT-Systemen

Konzeptentwicklung von IT-Systemen

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Konzeptentwicklung von IT-Systemen

Ähnlich wie Konzeptentwicklung von IT-Systemen (9)

Konzeptentwicklung von IT-Systemen