Um die zentrale Frage dieser Arbeit — wie wesentliche Anforderungen an die IS im Rahmen von Innovationsprojekten angemessen berücksichtigt werden können — zu beantworten, werden zunächst im zweiten Kapitel maßgebliche Grundlagen, Theorien und Termini vorgestellt.
Anschließend werden im dritten Kapitel entscheidende Methoden des Projektmanagements vorgestellt und basierend auf den gewonnenen Erkenntnissen ein standardisiertes Phasenmodell von Innovationsprojekten der IT formuliert. Dieses Vorgehen soll dazu beitragen, dass die im Rahmen dieser Arbeit entwickelten Ergebnisse sich auf alle gängigen Projektmanagement (PM)-Vorgehensmodelle abbilden lassen, ohne eine wesentliche Anpassung bestehender Prozesse nach sich zu ziehen.
Anschließend wird im vierten Kapitel untersucht, was Angemessenheit im Kontext der IS bedeutet und durch welche Faktoren diese beeinflusst wird. Das Fehlen einer solchen Begriffsdefinition führt in der Praxis immer wieder dazu, dass die an einem Projekt beteiligten Parteien keine allgemein akzeptierte Handlungsbasis finden. In der Folge wird meist ein binärer Ansatz verfolgt. Entweder werden keinerlei Sicherheitsaspekte betrachtet oder aber die Umsetzung aller denkbaren Maßnahmen erzwungen. Beide Varianten sind kaum dazu geeignet, zu einem positiven Ergebnis zu führen.
Im nächsten Schritt gilt es, die in den vorangegangenen Kapiteln gewonnenen Erkenntnisse zu einer Methode zu integrieren, die sich zum einen auf alle gängigen PM-Standards abbilden lässt und zum anderen eine Umsetzung der Mindestanforderungen aus der IS gewährleistet. Ein entsprechender Versuch wird in Kapitel 5 durch die Entwicklung eines Modells zur phasenorientierten Absicherung von Innovationsprojekten unternommen. Darauf basierend wird in Kapitel 6 ein Prüfschema entwickelt, das als Grundlage für die Durchführung strukturierter Audits dient. Das Vorgehensmodell wird im weiteren Verlauf in Kapitel 7 validiert. Den Abschluss bildet das Fazit in Kapitel 8.
Inhaltsverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Lösungsansatz und Methodik
1.2 Forschungsstand
1.3 Abgrenzung
2 Grundlagen und Terminologie
2.1 Produktinnovation in der IT
2.2 Methoden des Projektmanagements
2.2.1 Klassisches Projektmanagement
2.2.1.1 PRINCE
2.2.1.2 Sequenzielle Modelle
2.2.1.3 Project Management Body of Knowledge
2.2.1.4 Individual Competence Baseline
2.2.2 Agile Methoden
2.2.2.1 Scrum
2.2.2.2 (Rapid) Prototyping
2.2.2.3 Lean (Startup)
2.2.2.4 Design Thinking
2.2.2.5 DevOps
2.2.3 Hybride/Selektive Modelle
2.2.4 Weitere PM-Methoden
2.3 Informationssicherheit und deren Ziele
2.4 Stand der Technik
2.5 Angemessenheit
3 Standardisiertes Phasenmodell von Innovationsprojekten der IT
3.1 Phasen- und Aktivitätsanalyse maßgeblicher PM-Methoden
3.1.1 PRINCE
3.1.2 V-Modell
3.1.3 PMBOK
3.1.4 Scrum
3.1.5 Lean Startup
3.1.6 Design Thinking
3.2 Definition des Phasenmodells
4 Einflussfaktoren angemessener Informationssicherheit
4.1 Regulatorische Anforderungen
4.1.1 EU-DSGVO & BDSG (neu)
4.1.2 BSIG & BSI-Kritisverordnung
4.1.3 Weitere Gesetze und Verordnungen
4.1.3.1 Grundsätzlich gültige Regularien
4.1.3.2 Funktionsabhängige Regularien
4.2 Rahmenwerke der Informationssicherheit
4.2.1 Management der Informationssicherheit
4.2.2 Kontext- und funktionsbezogene Anforderungen
4.2.3 Technologiespezifische Best Practices
4.3 Security & Privacy by Design & by Default
4.4 Schutzbedarf der verarbeiteten Daten
4.5 Risikobereitschaft der Organisation
4.6 Weitere interne und externe Rahmenbedingungen
4.7 DevSecOps: Sicherheit in der Softwareentwicklung
4.8 Grundsätze angemessener Informationssicherheit
5 Phasenorientierte Absicherung von Innovationsprojekten der IT 78
5.1 Phase 1: Anforderungsdefinition
5.1.1 Informationssicherheitsrichtlinien
5.1.2 Verwaltung der Werte
5.1.3 Zugangssteuerung
5.1.4 Physische und umgebungsbezogene Sicherheit
5.1.5 Anschaffung, Entwicklung und Instanthaltung von Syste-men
5.1.6 Compliance
5.2 Phase 2: Entwicklungszyklus
5.2.1 Verwaltung der Werte
5.2.2 Betriebssicherheit
5.2.3 Kommunikationssicherheit
5.2.4 Anschaffung, Entwicklung und Instandhaltung von Syste-men
5.2.5 Compliance
5.3 Phase 3: Kontrolle und Steuerung
5.3.1 Informationssicherheitsleitlinien
5.3.2 Organisation der Informationssicherheit
5.3.3 Anschaffung, Entwicklung und Instandhaltung von Syste-men
5.3.4 Handhabung von Informationssicherheitsvorfällen
5.4 Phase 4: Produktveröffentlichung
5.4.1 Organisation der Informationssicherheit
5.4.2 Verwaltung der Werte
5.4.3 Physische und umgebungsbezogene Sicherheit
5.4.4 Kommunikationssicherheit
5.4.5 Anschaffung, Entwicklung und Instandhaltung von Syste-men
5.4.6 Handhabung von Informationssicherheitsvorfällen
5.4.7 Compliance
6 Prüfschema
6.1 Phase 1: Anforderungsdefinition
6.2 Phase 2: Entwicklungszyklus
6.3 Phase 3: Kontrolle und Steuerung
6.4 Phase 4: Produktveröffentlichung
7 Validierung
7.1 Kick-off und Parameteranalyse
7.2 Prüfergebnisse
7.2.1 Findings
7.2.2 Zusammenfassung
7.3 Zufriedenheitsbefragung
8 Fazit
9 Appendix A: Prüfergebnisse Validierungsverfahren
10 Appendix B: Fragebögen Ergebnisvalidierung
Literaturverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
In einer Zeit, in der die Informationstechnik (IT) sich auf Grund fortschrei- tenden Wandels und internationaler Konkurrenz in einem kontinuierlichen Um- bruch befindet, ist die Fähigkeit zur Veränderung wesentlich für den Erfolg oder Untergang einer jeden Organisation. Für die Entwickler von Hard- und Softwa- relösungen — sei es zum Einsatz im eigenen Unternehmen oder zur Monetarisie- rung jedweder Art — stellt die Fähigkeit zur Entwicklung innovativer Produkte eine Kernkompetenz dar. Dabei müssen neue Entwicklungen schnell, effizient und unter Berücksichtigung sowohl selbst auferlegter, als auch extern geforder- ter Qualitätsstandards vorangetrieben werden. Letztgenannte umfassen neben dem Einsatz aktueller Entwicklungsmethoden und moderner Technologien auch die Erfüllung von Anforderungen an die Sicherheitseigenschaften einer Lösung.
Dies wird nicht nur von potenziellen Kunden gefordert.1 Auch der Gesetzgeber hat in den letzten Jahren damit begonnen, vermehrt in die Sicherheit infor- mationsverarbeitender Verfahren einzugreifen. Während in der Vergangenheit üblicherweise die Erschließung neuer Einsatzszenarien und Realisierung innova- tiver Funktionen im Mittelpunkt aller Bestrebungen stand, müssen heute schon im Rahmen der Produktentwicklung Sicherheitsanforderungen betrachtet wer- den, die — blieben sie unberücksichtigt — zu einem späteren Zeitpunkt nicht mehr oder nur unter Einsatz erheblicher finanzieller und personeller Ressourcen realisiert werden könnten. Mangelhafte Sicherheitsfunktionen können dazu füh- ren, dass ein eigentlich revolutionäres Produkt nicht vom Markt angenommen wird, da dessen Einsatz mit unannehmbaren Risiken verbunden wäre.
Auf Grund dieser Entwicklung kommt es immer wieder zu Zwistigkeiten zwi- schen den Mitarbeitern in Kreativprozessen und den Sicherheitsverantwortli- chen. Während die einen ins Feld führen, dass Kreativität frei von externen Vorgaben bleiben müsse, um zu relevanten Innovationen führen zu können, zei- gen die anderen die Gefahren einer Missachtung grundlegender Sicherheitsanfor- derungen auf. Dabei haben beide Positionen eine gewisse Daseinsberechtigung. Damit es zu einer Annäherung kommen kann, müssen Wege und Methoden er- schlossen werden, die freie Entwicklungen möglichst wenig einschränken, gleich- zeitig aber Mindestanforderungen der Informationssicherheit (IS) angemessen berücksichtigen. Die Auflösung dieses scheinbaren Widerspruchs steht im Mit- telpunkt dieser Arbeit.
1.1 Lösungsansatz und Methodik
Um die zentrale Frage dieser Arbeit — wie wesentliche Anforderungen an die IS im Rahmen von Innovationsprojekten angemessen berücksichtigt werden kön- nen — zu beantworten, werden zunächst in Kapitel 2 maßgebliche Grundla- gen, Theorien und Termini vorgestellt. Anschließend werden in Kapitel 3 ent- scheidende Methoden des Projektmanagements vorgestellt und basierend auf den gewonnenen Erkenntnissen ein standardisiertes Phasenmodell von Inno- vationsprojekten der IT formuliert. Dieses Vorgehen soll dazu beitragen, dass die im Rahmen dieser Arbeit entwickelten Ergebnisse sich auf alle gängigen Projektmanagement (PM)-Vorgehensmodelle abbilden lassen, ohne eine wesent- liche Anpassung bestehender Prozesse nach sich zu ziehen.
Anschließend wird in Kapitel 4 untersucht, was Angemessenheit im Kontext der IS bedeutet und durch welche Faktoren diese beeinflusst wird. Das Fehlen einer solchen Begriffsdefinition führt in der Praxis immer wieder dazu, dass die an einem Projekt beteiligten Parteien keine allgemein akzeptierte Handlungsbasis finden. In der Folge wird meist ein binärer Ansatz verfolgt. Entweder werden keinerlei Sicherheitsaspekte betrachtet oder aber die Umsetzung aller denkbaren Maßnahmen erzwungen. Beide Varianten sind kaum dazu geeignet, zu einem positiven Ergebnis zu führen.
Im nächsten Schritt gilt es, die in den vorangegangenen Kapiteln gewonnenen Erkenntnisse zu einer Methode zu integrieren, die sich zum einen auf alle gän- gigen PM-Standards abbilden lässt und zum anderen eine Umsetzung der Min- destanforderungen aus der IS gewährleistet. Ein entsprechender Versuch wird in Kapitel 5 durch die Entwicklung eines Modells zur phasenorientierten Ab- sicherung von Innovationsprojekten unternommen. Darauf basierend wird in Kapitel 6 ein Prüfschema entwickelt, das als Grundlage für die Durchführung strukturierter Audits dient. Das Vorgehensmodell wird im weiteren Verlauf in Kapitel 7 validiert. Den Abschluss bildet das Fazit in Kapitel 8.
1.2 Forschungsstand
Die Frage nach dem Forschungsstand im Themenfeld der Absicherung von Inno- vationsprojekten der IT bzw. der Angemessenheit eines zu realisierenden Sicher- heitsniveaus in diesen kann nur themenspezifisch, nicht aber global beantwortet werden. Zunächst sind hier die gängigen Rahmenwerke der Informationssicher- heit, wie die ISO 27001 und der daran angelehnte IT-Grundschutz des BSI zu nennen.2 Diese werden sowohl — im Falle der ISO — international als auch national zum Aufbau von Managementsystemen der IS eingesetzt. Sie bilden Frameworks, um das Sicherheitsniveau unternehmensweit zu planen, umzuset- zen, zu steuern und kontinuierlich weiterzuentwickeln.
Neben diesen existiert eine Vielzahl von Standards zum Management von Pro- jekten, wie z. B. SCRUM, die Individual Competence Baseline (ICB), Projects in Controlled Environments (PRINCE2) und das V-Modell (XT).3 Die Vorgehens- modelle beschreiben, wie komplexe Projekte in mehr oder weniger vordefinierten Kontexten geplant und bestenfalls erfolgreich durchgeführt werden können. Die- se Ansätze wurden in der Vergangenheit wiederholt auf ihre Verbreitung und möglichen Einsatzgebiete hin untersucht. Studien wie der Status Quo Agile des Koblenzer Professors Komus zeigen zudem einen verstärkten Trend zum Einsatz agiler Methoden und zu sogenannten hybriden oder selektiven Modellen. [56, o. S.] Hier werden Mischformen unterschiedlicher Rahmenwerke eingesetzt, um den Ansprüchen von Organisationen gerecht zu werden.
Darüber hinaus findet sich definierende Literatur zum Umfang und Eigenschaf- ten von Innovationen und entsprechenden Projekten. Eine Integration von Si- cherheitsmaßnahmen erfolgt hier bislang Implizit, d. h. sofern diese direkt als Anforderungen in den Entwicklungsprozess mit einbezogen werden. Eine Aus- nahme bildet das durch das Open Web Application Security Project (OWASP) entwickelte DevSecOps-Vorgehensmodell, in dessen Rahmen neben Mitarbeitern der Entwicklungs- und Betriebsabteilungen zusätzlich Sicherheitsspezialisten in die Prozesse mit eingebunden werden, um frühzeitig wesentliche Sicherheitsan- forderungen zu erkennen.4
Abschließend ist die Bandbreite der gesetzlichen Regelungen zu nennen die — abhängig von einem gegebenen Kontext — unter Umständen Einfluss auf das zu realisierende Sicherheitsniveau nehmen. Diese reichen vom Grundgesetz für die Bundesrepublik Deutschland (GG) über das Strafgesetzbuch (StGB) bis hin zu spezifischen Regelungen, wie beispielsweise dem Gesetz über Urheberrecht und verwandte Schutzrechte (Urheberrechtsgesetz) (UrhG).5
1.3 Abgrenzung
Um die gegebene Fragestellung hinreichend exakt beantworten zu können, ist die Untersuchung einer großen Bandbreite relevanter Theorien und Einflussfak- toren notwendig. Im Folgenden wird aufgezeigt, welche Aspekte explizit nicht weiterverfolgt werden. Dies dient dazu, den Fokus auf wesentliche Kernthemen zu richten.
Im Zuge der Themenentwicklung werden Anforderungen an ein angemessenes Niveau der IS im Rahmen von Innovationsprojekten formuliert. Hier werden aus- schließlich nicht funktionale Anforderungen betrachtet. Dazu gehören sämtliche Facetten, die keinen direkten Einfluss auf die fachliche Funktion eines Produktes haben. Vielmehr beschreiben sie grundsätzliche Funktionalitäten zur Wahrung von Vertraulichkeit, Integrität und Verfügbarkeit der verarbeiteten Daten.
Sowohl im internationalen, als auch im nationalen Kontext existiert ein breites Methodenspektrum zum IS-Management. In dieser Arbeit werden ausschließlich solche Rahmenwerke betrachtet, die in Deutschland besonders verbreitet sind.6 Abgeleitete Vorgehensweisen, wie beispielsweise das Informationssicherheitsma- nagementsystem in 12 Schritten (ISIS12) oder die Informations-Sicherheits- Analyse (ISA+) für Kleine und mittlere Unternehmen (KMU) werden nicht weiter untersucht, da sie lediglich bereits etablierte Prozesse für einen bestimm- ten Kontext konkretisieren. Darüber hinaus werden keine Maßnahmen zur Eta- blierung von Managementsystemen (wie z. B. einem Informationssicherheitsma- nagementsystem (ISMS) oder einem Datenschutz-Managementsystem (DSMS)) betrachtet. Diese sollten im Gesamtkontext der Organisation definiert werden.
Im Rahmen der Anforderungsanalyse werden bewusst keine Empfehlungen zur Umsetzung von Maßnahmen gemäß einzelner technischer Spezifikationen formu- liert. Da sich diese — entsprechend dem jeweils geltenden Stand der Technik — kontinuierlich weiterentwickeln, würde ein solches Vorgehen dazu führen, dass die hier entwickelte Methodik bereits nach kurzer Zeit veraltet wäre. Zu die- sen technischen Spezifikationen zählen unter anderem auch die Vorgaben, die bei einer Produktzertifizierung — wie z. B. der nach den sogenannten Common Criteria — gefordert sind. Aktuelle technische Vorgaben können von speziali- sierten Organisationen, wie beispielsweise dem Bundesamt für Sicherheit in der Informationstechnik (BSI) oder dem OWASP bezogen werden.
Innovationsprojekte im Sinne dieser Arbeit sind Projekte zur Entwicklung neuer Produkte. Während nach geltender Lehre auch die Einführung bereits am Markt verfügbarer Produkte oder die Weiterentwicklung von Lösungen als Innovation betrachtet werden, unterliegen solche Projekte unter Umständen anderen Rah- menbedingungen als die der Produktentwicklung. Weitere Ausprägungen von In- novationsprojekten werden daher nur implizit betrachtet, sofern sie den gleichen Rahmenbedingungen unterliegen wie die Entwicklung innovativer Lösungen.
2 Grundlagen und Terminologie
Zur Beantwortung der Fragestellung, wie eine Methodik zur Realisierung eines angemessenen Sicherheitsniveaus von Projekten zur Produktinnovation in der IT beschaffen sein muss, werden im Folgenden zunächst wesentliche Grundlagen, Termini und Theorien erläutert.
Einleitend wird in Kapitel 2.1 aufgezeigt, welche Charakteristika ein Produkt aufweisen muss, um als Innovation zu gelten. Anschließend wird in Kapitel 2.2 dargestellt, welche PM-Modelle und -Methoden sich im Verlauf der vergange- nen Jahrzehnte entwickelt und am Markt etabliert haben. Neben Varianten des klassischen PM wird in besonderem Maße auf die sogenannten agilen Methoden eingegangen, da sich deren Einsatz im Rahmen von IT-Projekten als besonders zielfördernd erwiesen hat. Aufgrund einer steigenden Tendenz zum Vermischen von PM-Methoden werden in Kapitel 2.2.3 hybride bzw. selektive Modelle un- tersucht.
Im Folgenden beschreibt Kapitel 2.3 die Grundlagen der IS und die hier verfolg- ten Ziele. Das Thema Stand der Technik ist in diesem Kontext von zentraler Bedeutung, da hier das zu einem gegebenen Zeitpunkt anzustrebende Absiche- rungsniveau beschrieben wird. Daher wird das Konzept in Kapitel 2.4 elaboriert. Abschließend wird in Kapitel 2.5 erläutert, was der Begriff Angemessenheit im Allgemeinen und im Kontext der IS bedeutet bzw. welche Voraussetzungen er- füllt sein müssen, damit ein Vorgehen als „angemessen“ bezeichnet werden kann.
2.1 Produktinnovation in der IT
Um verstehen zu können, welche Ziele Innovationsprojekte verfolgen und welche Faktoren Einfluss auf das anzustrebende Sicherheitsniveau nehmen können, ist zunächst zu klären, welche Eigenschaften Innovationen ausmachen, in welchen Formen sie auftreten können und wie sich deren Entwicklung von der anderer Lösungen unterscheidet. Grundsätzlich wird unter einer Innovation eine „mit technischem, sozialem und wirtschaftlichem Wandel einhergehende [. . . ] (kom- plexe) Neuerung [. . . ]“ verstanden. [65, o. S.] Der Innovationsbegriff leitet sich von dem lateinischen Wort novus ab, welches soviel wie„neu“ oder „frisch“ be- deutet. [73, o. S.]
Damit ein Produkt als Innovation gilt, muss es (neben der Eigenschaft der Neu- heit) mindestens die folgenden beiden Voraussetzungen erfüllen:
Relevanz/Zweck: Eine Entwicklung muss in einem gegebenen Kontext relevant sein, um als Innovation zu gelten. Darüber hinaus muss sie einem definier- ten Zweck folgen. Sind diese Aspekte nicht gegeben, spricht man von einer Neuerung, nicht aber von einer Innovation.7
Umsetzung: Damit aus einer Idee eine Innovation wird, muss diese umgesetzt werden. Anderenfalls verbleibt die potenzielle Innovation im Ideenstadi- um. [62, S. 4 ff.]
Abhängig von der gewählten Quelle umfasst die Begriffsdefinition weitere Eigen- schaften. Dabei handelt es sich allerdings lediglich um Präzisierungen der oder Ableitungen von den oben genannten Anforderungen. Daher wird im Rahmen dieser Arbeit der Begriff Innovation im Kontext von Projekten der IT wie folgt definiert:
„Eine Produktinnovation in der Informationstechnik ist ein komple- xe Neuerung, die in einem gegebenen Kontext relevant ist und ei- nem definierte Zweck folgt. Eine Lösung gilt ab dem Zeitpunkt als Innovation, an dem sie vollständig umgesetzt ist und in den Produk- tivbetrieb überführt werden kann.“
Die thematische Eingrenzung auf Produktinnovationen bietet sich an, da sich In- novationsprojekte der IT fast ausschließlich mit der (Weiter-)Entwicklung oder Einführung neuer technische Lösungen befassen. Obwohl Service- oder Prozess- innovationen ebenfalls denkbar sind, unterliegen diese eher betriebswirtschaftli- chen und organisatorischen als technischen Einflussfaktoren. Daher werden diese im Rahmen dieser Arbeit nicht weiter vertieft. Im IT-Kontext wiederum sind verschiedene Projektziele denkbar, die sich folgendermaßen rubrizieren lassen:
Entwicklung neuer Produkte: Entwicklung einer vollkommen neuen Lösung, die entweder in der eigenen Organisation eingesetzt oder als Produkt vertrie- ben werden soll.
Weiterentwicklung bereits existierender Produkte: Funktionale Weiterentwicklung oder technische Modernisierung einer existierenden Lösung.
Einführung neuer Produkte: Einführung eines bereits am Markt verfügbaren, bislang allerdings nicht verwendeten Produktes.
Sowohl die Weiterentwicklung existierender Produkte, als auch die Einführung neuer Lösungen werden in der Regel innerhalb einer bestehenden Infrastruktur vollzogen. Hier gelten die Sicherheitsvorgaben der Organisation. Die Produkte werden in die bestehende IT-Infrastruktur eingebunden und verfügen daher un- mittelbar über ein der Risikobereitschaft der Organisation entsprechendes ange- messenes Sicherheitsniveau. Obwohl auch hier Sicherheitserwägungen eine Rolle spielen sollten, sind entsprechende Projekte im Rahmen eines gesamtheitlichen Sicherheitsmanagements zu betrachten.
Hingegen erfolgt die Entwicklung neuer Produkte vielfach entweder in eigens für diesen Zweck gegründeten Unternehmungen oder in auf Innovationsprojekte spezialisierten Abteilungen. Da sie im Rahmen ihres Innovationsauftrages viel- fach darauf angewiesen sind, neue und bislang in der Organisationssicherheit nicht berücksichtige Werkzeuge und Methoden einzusetzen, gestaltet sich die Sicherheitsfrage hier als besonders schwierig. Es gilt, ein Gleichgewicht zwischen kreativem Freiraum und einem dem Projekt- bzw. Produktkontext angemesse- nen Sicherheitsniveau zu finden. Der Abbau dieser zentralen Hürde steht im Mittelpunkt dieser Arbeit.
2.2 Methoden des Projektmanagements
Die Erbringung von Leistungen in privatwirtschaftlichen und öffentlichen Or- ganisationen erfolgte in der Vergangenheit meist im sogenannten Tages- oder operativen Geschäft. Mitarbeitern wurden einzelne Aufgaben oder Aufgaben- gebiete zugewiesen, die sie in wiederkehrenden Intervallen abarbeiteten. Das Vorgehen wurde zum einen durch starre Hierarchien und damit einhergehen- den autoritären Führungsstilen und zum anderen durch sich kaum veränderte Marktanforderungen begünstigt. Einmal geplante Aufgaben konnten über Jahre hinweg in immer gleicher Art und Weise ausgeführt werden. Gleichzeitig führte diese Monotonie nicht selten zu Frustration, mangelhaftem Engagement und der Unfähigkeit von Organisationen, sich selbst und ihre Produkte weiterzuentwi- ckeln.
Dieses Bild hat sich in den letzten Jahrzehnten verändert. Während in den 70er und 80er Jahren des 20. Jahrhunderts Aufgaben nur punktuell im Rahmen von Projekten gelöst wurden, ist es heute undenkbar, auf diese Art des Arbeitens zu verzichten. Doch was macht ein Projekt eigentlich aus? Das Gablers Wirt- schaftslexikon definiert den Projektbegriff als eine „zeitlich befristete, relativ in- novative und risikobehaftete Aufgabe von erheblicher Komplexität, die aufgrund ihrer Schwierigkeit und Bedeutung meist ein gesondertes Projektmanagement erfordert.“ [81, o. S.]
Im Dunstkreis des Projektmanagements haben sich in der Vergangenheit diverse Standards etabliert. Da es sich bei allen Varianten um Management-Disziplinen handelt, umfassen sie — wenn auch in unterschiedlicher Ausprägung — mindes- tens die folgenden grundlegenden Aktivitäten: Planung, Durchführung, Über- prüfung und Standardisierung. Diese Schritte werden im sogenannten Plan, Do, Check, Act (PDCA) - oder nach ihrem Verfasser benannten Deming-Zyklus dar- gestellt.8 [28, o. S.] Die gängigen Methoden werden im Folgenden vorgestellt.
Diese Analyse dient dazu, in Kapitel 3 ein Modell der Phasen zu entwickeln, das sich auf die gängigen PM-Methoden abbilden lässt bzw. komplementär zu diesen eingesetzt werden kann. Dabei werden die betrachteten Standards hinsichtlich der folgenden Fragen untersucht:
1. Welches Alleinstellungsmerkmal weist der Standard auf ?
2. Für welche Art von Projekten ist der Standard besonders geeignet und für welche nicht?
3. Werden implizit oder explizit Projektphasen oder Aktivitäten definiert?
2.2.1 Klassisches Projektmanagement
In der Geschichte des Projektmanagements entwickelten sich zunächst die heute als klassischen Ansätze bezeichneten Methoden. Sie wurden und werden auch heute noch meist durch spezialisierte Organisationen, wie z. B. die International Project Management Association (IPMA) formalisiert und kontinuierlich wei- terentwickelt. [51, o. S.] Ein wesentliches Merkmal all dieser Vorgehensweisen ist die Fähigkeit, im Vorfeld planbare, große Projekte über eine lange Laufzeit zu einem eingangs definierten Ziel zu führen. Projektergebnisse werden in der Regel erst zum Abschluss des Projektes geliefert. Gleichzeitig eignen sich die Methoden meist kaum für Vorhaben, die sich durch sich stetig verändernde An- forderungen auszeichnen, wie dies bei Entwicklungs- und Innovationsvorhaben vielfach der Fall ist. Veränderungen der Projektziele führen fast zwangsläufig zu Leistungseinbußen, da eine Anpassung der gesamten Projektplanung notwendig wird. Durch die zusätzlich benötigten zeitlichen und finanziellen Ressourcen be- dingt kommt es nicht selten zu einer Verzögerung des Projektabschlusses und einer dadurch bedingten Steigerung der Kosten. [57, S. 14]
Die durch die oben genannten Risiken bedingte abnehmende Tendenz zum klas- sischen Projektmanagement zeigt sich in der Praxis, wurde aber auch im Rah- men wissenschaftlicher Studien untersucht. In der Publikation Studie über Er- folg und Anwendungsformen von agilen Methoden aus dem Jahr 2017 stellte Prof. Dr. A. Komus von der Hochschule Koblenz fest, dass lediglich 12 % der über 1000 befragten Organisationen und Einzelpersonen aus 30 Nationen rein klas- sische PM-Methoden einsetzten. Gleichzeitig wurde eine deutliche Tendenz zu agilen Methoden oder hybriden Modellen erkennbar (siehe hierzu Kapitel 2.2.3). Auch zeigten die Ergebnisse, dass IT- oder IT-nahe Projekte in besonderem Ma- ße dazu tendieren, agile Methoden vorzuziehen. [56, S. 15]
Obwohl heute vermehrt agile Methoden im Rahmen von IT-Projekten eingesetzt werden, existiert besonders im öffentlichen Sektor noch eine Vielzahl von Orga- nisationen, die weiterhin klassische Methoden vorziehen. Daher werden diese im Rahmen dieser Arbeit ebenfalls betrachtet. Die Eigenschaften dieser Standards werden im Folgenden hinsichtlich der in Kapitel 2.2 aufgezeigten Fragen — stell- vertretend für die Methoden des klassischen Projektmanagements — analysiert.
2.2.1.1 PRINCE2
Der PRINCE2-Standard beschreibt eine strukturierte Methode zum Manage- ment komplexer Projekte. Heute wird er in mehr als 150 Ländern und 20.000 Organisationen eingesetzt. [5, o. S.] Aufgrund dieser Verbreitung zählt er zu den renommiertesten Rahmenwerken des klassischen Projektmanagements. Ur- sprünglich wurde er durch die Central Computer and Telecommunications Agen- cy (CCTA) und das Office of Government Commerce (OGC) zum Einsatz in britischen Regierungsorganisationen entwickelt. Ziel war es, eine Terminologie und Vorgehensweise zu etablieren, die es Organisationen ermöglichen sollte, ge- meinsame Projektziele zu verfolgen. Beide Organisationen waren bis zum Jahr 2010 für die Weiterentwicklung der Methode verantwortlich. Heute obliegt diese Aufgabe dem UK Cabinet Office. [9, o. S.]
Um Projekte erfolgreich steuern zu können, formuliert das Rahmenwerk sechs Dimensionen, die zu berücksichtigen sind:
1. Kosten: Projekte müssen einen Mehrwert schaffen. Das bedeutet, dass sie einen größeren finanziellen Nutzen erwirtschaften sollten, als Kosten generiert werden.
2. Zeitrahmen: Neben den finanziellen müssen auch zeitliche Ressourcen be- rücksichtigt werden. Jegliche Aktionen sollten darauf ausgerichtet sein, ein Vorhaben unter Einhaltung der vereinbarten zeitlichen Parameter ab- schließen zu können.
3. Qualität: Während Kosten und Zeit sich in erster Linie auf das Projekt selbst beziehen, formulieren Qualitätsanforderungen Eigenschaften an das Ergebnis. Ein Projekt, das ein minderwertiges Ergebnis liefert, gilt als nicht erfolgreich.
4. Umfang: Im Rahmen der Umfangsbeschreibung werden alle Anforderun- gen an das Projektergebnis formuliert. Im Fall eines Projektes der IT kann dies beispielsweise heißen, dass bestimmte Funktionen mindestens umgesetzt werden müssen. Darüber hinaus gehören zum Projektumfang Nebenleistungen wie Dokumentation, Qualitätssicherung und Benutzer- schulungen.
5. Risiko: Jegliche unternehmerische Tätigkeit unterliegt gewissen Risiken.
Diese müssen analysiert und zentral gesteuert werden. Anderenfalls kann es dazu kommen, dass unvorhergesehene Ereignisse zu einem Projektab- bruch oder zu anderweitigen Problemen führen.
6. Nutzen: Im Kontext der Nutzensanalyse steht die zentrale Frage: Warum tun wir das? Es reicht nicht aus, ein Projekt termin- und budgetgerecht in der geforderten Qualität abzuschließen, wenn das Ergebnis von geringem oder gar keinem Nutzen ist. [5, S. 5 f.]
Die in PRINCE2 beschriebenen Prozesse und Themen dienen dazu, diese sechs Dimensionen zu steuern. Ergänzend dazu werden sieben sogenannte Grundprin- zipien formuliert. Sie zeichnen sich unter anderem dadurch aus, dass sie uni- versell sind (also auf jedes Projekt anwendbar) und Anwender dazu befähigen sollen, Projekte erfolgreich abzuschließen. Diese Grundsätze lassen sich wie folgt zusammenfassen:
1. Fortlaufende geschäftliche Rechtfertigung: Zu jedem Zeitpunkt im Projekt muss ein berechtigter Grund für die Fortführung der Tätigkeiten gege- ben sein. Die Rechtfertigung wird während der gesamten Projektlaufzeit fortwährend überprüft. Sie muss dokumentiert und genehmigt werden.
2. Lernen aus Erfahrung: Aufgrund der befristeten Zusammensetzung von Projektteams und der Komplexität der jeweiligen Aufgabe ist es notwen- dig, dass jedes Mitglied eines Teams für sich und die Gruppe als Ganzes kontinuierlich aus den gemachten Erfahrungen lernt.
3. Definierte Rollen und Verantwortlichkeiten: Die Formulierung von Team- strukturen dient dazu, effektive Kommunikationswege zu schaffen und ge- meinsam ein gegebenes Ziel zu verfolgen. Wird dies versäumt, werden Auf- gaben wahrscheinlich nicht oder nicht in der geforderten Qualität oder außerhalb des gesetzten Zeit- oder Kostenhorizontes abgeschlossen.
4. Steuern über Managementphasen: PRINCE2 formuliert Projektphasen und bietet so die Möglichkeit, während der Laufzeit eines Projektes an Kon- trollpunkten zu überprüfen, ob weiterhin eine Rechtfertigung für zusätz- liche Investitionen gegeben ist. So kann auch das Unternehmensmanage- ment je nach Priorität, Risiko und Komplexität in Entscheidungsprozesse mit einbezogen werden.
5. Steuern nach dem Ausnahmeprinzip: In jedem Projekt werden sogenannte Toleranzen definiert, die den Handlungsrahmen für delegierte Befugnisse festlegen. Für alle oben genannten Dimensionen werden Schwellenwerte definiert, in deren Rahmen die Projektleitung eigenständige Entscheidun- gen treffen kann, ohne die nächsthöhere Leitungsebene einzubeziehen.
6. Produktorientierung: Jedes Vorhaben ist auf die Lieferung eines oder meh- rerer Produkte ausgerichtet. Der Fokus aller Tätigkeiten liegt darauf, das Ergebnis im vereinbarten Nutzen- und Qualitätsrahmen zeit- und kosten- gerecht zu liefern.
7. Anpassen an die Projektumgebung: Bei dem vorliegenden Standard han- delt es sich um eine Rahmenwerk. Das bedeutet, dass jegliche Prozesse an das Projektumfeld angepasst werden müssen. Eine Formulierung allge- mein gültiger Prozesse und Strukturen ist nicht sinnvoll, da sich Methoden an den Anforderungen der Organisation orientieren sollten und nicht an- dersherum. [5, S. 12 ff.]
Ergänzend zu den Dimensionen und den Grundprinzipien formuliert PRINCE2 sieben zentrale Themen, die Einfluss auf den Verlauf eines Projektes und dessen Erfolg nehmen.
1. Business Case: Der Business Case beschreibt den angestrebten Nutzen eines Vorhabens und wird regelmäßig hinterfragt. Wird er obsolet, endet das Projekt, da die Investitionen nicht mehr als lohnend betrachtet werden können.
2. Organisation: Das Thema beschreibt die wesentlichen Rollen und Ver- antwortlichkeit in dem Team, das befristetes für das Management eines Projektes eingerichtet wird.
3. Qualität: Hier werden die angestrebten Qualitätskriterien formuliert, die ein zu lieferndes Produkt erfüllen muss und die Methoden, um die Zieler- reichung zu gewährleisten.
4. Pläne: Alle PRINCE2-Projekte verlaufen auf Basis genehmigter Pläne.
Ergänzend zu den Aspekten des Themas Qualität werden hier Schritte und Techniken zur Entwicklung von Plänen aufgezeigt.
5. Risiken: Das Thema befasst sich mit dem Umgang mit Unsicherheiten in
Plänen und der sonstigen Projektumgebung.
6. Änderungen: Das Thema beschreibt, wie offene Punkte bewertet und be- handelt werden müssen. Da diese zu allgemeinen Problemen, Änderungs- anträgen oder Qualitätseinbußen führen können, ist das Thema ein we- sentlicher Kernaspekt des Rahmenwerkes.
7. Fortschritt: In diesem Zusammenhang wird die fortlaufende Kontrolle der Durchführbarkeit von Plänen betrachtet. An zentralen Punkten im Pro- jektmanagementprozess wird entschieden, ob und wie Vorhaben fortge- führt werden sollen bzw. können. [5, S. 19 f.]
Aufgrund der Komplexität des Rahmenwerkes und der vergleichsweise stati- schen Strukturen bietet sich PRINCE2 — ähnlich wie die anderen Methoden des klassischen Projektmanagements — in der Regel eher zur Steuerung solcher Projekte an, die zu Beginn ein fest definiertes Ziel formulieren können und nur geringen Änderungsanforderungen unterliegen. Das ist auch der Grund dafür, dass die Methode, obwohl sie sich im internationalen Kontext großer Beliebt- heit erfreut, immer seltener im Rahmen von IT-bezogenen Projekten eingesetzt wird. [5, S. 19 f.]
Da der Standard jedoch grundsätzlich die Formulierung von Projektphasen und entsprechenden Aktivitäten vorsieht, wird er im weiteren Vorgehen mit in die Formulierung eines allgemeingültigen Phasenmodells von Projekten mit einbe- zogen. Die entsprechenden Prozesse werden in Kapitel 3.1.1 erläutert. Für dieses Vorgehen spricht ebenfalls, dass das Rahmenwerk auch heute noch vielfach in staatlichen Organisationen eingesetzt wird.
2.2.1.2 Sequenzielle Modelle
Sequenzielle Modelle zeichnen sich dadurch aus, dass sie — basierend auf einem Plan fest definierter Phasen — zu einem eindeutigen Ergebnis führen (sollen). Dabei müssen alle Aufgaben einer Phase erfolgreich abgeschlossen worden sein, bevor mit der nächsten Phase fortgefahren werden darf. Einmal abgeschlossene Phasen werden grundsätzlich nicht wiederholt, sofern dies nicht im ursprüng- lichen Projektplan vorgesehen war. Treten Abweichungen hinsichtlich der ver- einbarten Qualitäts- oder Funktionsanforderungen auf, müssen diese nachgear- beitet werden. Bei Ereignissen, die eine sinnvolle Projektfortsetzung unmöglich erscheinen lassen, wird das Projekt gestoppt, eingestellt oder unter Berücksich- tigung der veränderten Parameter neu geplant. [55, o. S.]
Das gängigste sequenzielle Modelle ist das sogenannte Wasserfallmodell. Es stammt ursprünglich aus der Produktionswirtschaft, etablierte sich aber schnell in der Softwareentwicklung. Als rein lineares Modell eignet es sich dafür, Ak- tivitäten und Meilensteine zu steuern und zu kontrollieren. Die im Folgenden aufgezeigten weiteren sequenziellen Modelle basieren alle mehr oder minder auf diesem Modell. Projekte, die nach dem Wasserfallmodell geplant sind, werden üblicherweise in aufeinander folgende Phasen unterteilt. Da das Ende einer Pha- se den Beginn einer neuen Phase definiert und ein Abschluss erst nach Fertig- stellung aller Anforderungen erfolgt, ist eine genaue Planung essenziell für den Erfolg eines nach diesem Vorgehen geplanten Vorhabens. Wurde eine Aktivität nicht abgeschlossen, kann nicht mit dem Projekt fortgefahren werden. [3, o. S.]
Für den Einsatz dieser Vorgehensweise spricht, dass die einzelnen Phasen ex- plizit voneinander abgegrenzt sind und die Zielerreichung zu jedem Zeitpunkt vergleichsweise genau ermittelt werden kann. Darüber hinaus ist es möglich, Kos- ten und Umfang des Projektes im Vorfeld zu ermitteln und zu definieren. Dies gilt zumindest in der Theorie. Praktisch ist es kaum möglich, jegliche Einfluss- faktoren auf ein Projekt im Vorfeld abzuschätzen. Besonders in Entwicklungs- projekten kommt es regelmäßig zu veränderten Anforderungen, die die gesamte Projektplanung beeinflussen, wodurch der Planungsprozess wiederholt werden muss. [84, o. S.]
Ähnlich wie beim Wasserfallmodell beschreibt das V-Modell einen linearen Pro- zess zur Entwicklung von Software. Die Methode kann sowohl für die Entwick- lung von Standalone-, als auch von Zusatzmodulen bzw. -funktionen bestehender Lösungen eingesetzt werden. Der zentrale Unterschied zwischen den Modellen besteht darin, dass — anders als beim Wasserfallmodell — bei Einsatz des V- Modells im Verlaufe jeder Phase Tests konzipiert werden, um die Ergebnisse der jeweiligen Aktivitäten zu validieren. Dies soll dazu beitragen, dass Konzeptions- fehler frühzeitig erkannt werden. Eine wesentliche Schwierigkeit besteht darin, dass bei unzureichender Zusammenarbeit mit dem Qualitätsmanagement einer Organisation die Qualität der festgelegten Tests variieren kann. Dies führt unter Umständen dazu, dass der Aufwand der Verifikation erhöht wird oder entspre- chende Tätigkeiten nur unvollständig durchgeführt werden. [52, o. S.]
In Deutschland hat sich neben dem Wasserfallmodell und dem V-Modell das durch die Bundeswehr im Jahr 1992 veröffentlichte V-Modell XT etabliert. Da- bei steht das Suffix XT für eXtreme Tailoring. Dies bedeutet soviel wie die flexible Anpassbarbeit der Vorgehensweise an jedwede Organisationsform und Projektumgebung. Dazu werden sieben mögliche Projektvarianten definiert:
1. AG – Projekt mit einem Auftragnehmer
2. AG – Projekt mit mehreren Auftragnehmern
3. AN – Projekt mit Entwicklung, Weiterentwicklung oder Migration
4. AG – Projekt mit Wartung und Pflege
5. AG/AN – Projekt mit Entwicklung, Weiterentwicklung oder Migration
6. AN – Projekt mit Wartung und Pflege
7. Einführung und Pflege eines organisationsspezifischen Vorgehensmodells
Die Varianten bestimmen die Rahmenbedingungen und Abläufe eines Projek- tes. Abhängig von der gewählten Ausprägung werden Phasen und Aktivitäten durchgeführt oder gestrichen. Dies soll dazu beitragen, den Fokus auf die Fer- tigstellung wesentlicher Tätigkeiten zu legen. Neben den Varianten werden vier Projekttypen formuliert:
1. Systementwicklungsprojekt (AG)
2. Systementwicklungsprojekt (AN)
3. Systementwicklungsprojekt (AG/AN)
4. Einführung und Pflege eines organisationsspezifischen Vorgehensmodells
Eine gegebene Projektklassifizierung führt dazu, dass bestimmte — in soge- nannten Bausteinen festgelegte — Anforderungen erfüllt werden müssen. Ziel der Erstellung von Bausteinen ist es, den Anwendern grundlegende Analyse- aufgaben abzunehmen. Da diese allerdings im Wesentlichen für den Einsatz in Behörden formuliert wurden, kann eine Anpassung an die Rahmenparameter privatwirtschaftlicher Unternehmen zu einem Mehraufwand führen. Beispiels- weise unterliegt die Durchführung von Ausschreibungen im öffentlichen Sektor gesetzlichen Vorgaben, die sich nur bedingt auf andere Organisationen übertra- gen lassen. Daher sollte fallbezogen geprüft werden, ob der Einsatz des V-Modell XT in einem gegebenen Kontext sinnvoll ist. [64, o. S.]
Unabhängig von der Ausprägung des gewählten sequenziellen Vorgehens weisen alle Varianten ähnliche Phasen und Aktivitäten auf. Da das V-Modell XT einen thematischen Schwerpunkt auf den Einsatz in Behörden legt und das Wasser- fallmodell „nur“der Vorgänger des V-Modells ist, wird letztgenanntes in Kapi- tel 3.1.2 stellvertretend für die sequentiellen Modelle tiefer gehend analysiert und in die Formulierung eines standardisierten Phasenmodells mit einbezogen.
2.2.1.3 Project Management Body of Knowledge
Der erstmals im Jahr 1987 durch das Project Management Institute (PMI) ver- öffentlichte Project Management Body of Knowledge (PMBOK) ist der einzige Standard zum Projektmanagement, der auf Grund seiner Anerkennung durch das Institute of Electrical and Electronics Engineers (IEEE) und das American National Standards Institute (ANSI) im Jahr 2012 als Teil der International Organization for Standardization (ISO)-Normenreihe unter der Nummer 21500 veröffentlicht wurde. [47, o. S.] Im Jahr 2017 wurde Version 6 des Rahmenwerkes publiziert. Der Guide beschreibt drei Dimensionen, die den Anwender bei der erfolgreichen Umsetzung von Projekten unterstützten sollen:
1. PM-Rahmen
2. 5 PM-Prozessgruppen
3. 10 PM-Wissensgebiete9
Die Prozessgruppen subsumieren alle durch den Standard berücksichtigten Pro- zesse in folgenden Kategorien:
1. Initiierung: Formale Autorisierung einer Aktion (z. B. eines Projektes oder einer Phase).
2. Planung: Definition des Projektziels und Planung der Vorgehensweise.
3. Ausführung: Umsetzung der Pläne; Lenken und Managen der Projektar- beit.
4. Überwachung und Steuerung: Überprüfung des Fortschrittes und Einlei- tung von Korrekturmaßnahmen.
5. Abschluss: Formaler Abschluss einer Phase oder eines Projektes.10
Zur Durchführung der in den Prozessgruppen beschriebenen Prozesse werden zudem Wissensgebiete definiert, die ein Team beherrschen muss, um ein Projekt zu einem erfolgreichen Abschluss führen zu können. Dazu gehören:
1. Integrationsmanagement: Zusammenfassung der Einzelteile (wie Projekt- elemente, -phasen oder -ergebnisse) eines Projektes zu einem Ganzen.
2. Inhalts- und Umfangsmanagement: Beschreibung des zu erstellenden Ge- samtprodukts und der Nebenleistungen.
3. Terminmanagement: Zeit- und Ablaufplanung des Projektes, um einen termingerechten Abschuss zu gewährleisten.
4. Kostenmanagement: Schätzung der Projektaufwände und Budgetierung der einzelnen Aktivitäten.
5. Qualitätsmanagement: Formulierung der Qualitätsanforderungen an ein Projektergebnis und fortwährende Überprüfung der Einhaltung dieser Vor- gaben.
6. Ressourcenmanagement: Erkennen, Zusammenstellen und Steuern der für ein Projekt benötigten Ressourcen.
7. Kommunikationsmanagement: Aufbau und Aufrechterhaltung eines In- formations- und Berichtswesens zum aktuellen Status Quo und zum Fort- schritt eines Projekts.
8. Stakeholder-Management: Identifikation und Steuerung aller an einem ei- nem Projekt beteiligten Interessensparteien.
9. Risikomanagement: Identifizierung, Analyse und Bewertung von Risiken, sowie Risikobehandlung und –verfolgung.
10. Beschaffungsmanagement: Angebotsbeschaffung, Lieferantenauswahl und Vertragsgestaltung mit externen Lieferanten.11
Die Prozessgruppen und Wissensgebiete werden (in der Version aus dem Jahr 2017) über insgesamt 47 Prozesse verknüpft. So entsteht eine Matrix, die jeden Prozess einer Prozessgruppe und einem Wissensgebiet zuordnet. Die Anpass- barkeit und große Bandbreite der Prozesse in Verbindung mit den allgemein gehaltenen Wissensgebieten führen dazu, dass der PMBOK für Projekte aller Größen und Branchen eingesetzt werden kann. Auf Grund seiner Prozessfokus- sierung wird der Standard in Kapitel 3.1.3 weiterführend analysiert und in die Formulierung des allgemein gültigen Prozessmodells aufgenommen.
2.2.1.4 Individual Competence Baseline
Die ICB in der Version 4 ist ein Standard für Projektmanagement, der von der IPMA entwickelt wurde und im deutschsprachigen Raum durch die Gesellschaft für Projektmanagement e. V. (GPM) betreut und fortgeschrieben wird. Anders als bei anderen Rahmenwerken liegt der Fokus nicht auf der Bereitstellung von Good-Practice-Ansätzen, sondern vielmehr auf den individuellen Kompetenzen aller beteiligten Personen. Diese werden in drei Domänen zusammengefasst: Projekt-, Programm- und Portfoliomanagement. Die Themen Programm- und Portfoliomanagement werden an dieser Stelle nicht weiter erläutert, da sie auf Grund ihrer inhaltlichen Ausrichtung keinen wesentlichen Einfluss auf das Er- gebnis der hier durchgeführten Analyse nehmen.
Mit der Veröffentlichung der ICB verfolgt die IPMA das Ziel, durch die Be- reicherung und Verbesserung der individuellen Kompetenzen die erfolgreiche Durchführung von Projekten zu ermöglichen. [42, S. 13] Das Spektrum zu ent- wickelnder Kompetenzen umfasst folgende Facetten:
1. Wissen: Die Gesamtheit an Informationen und Erfahrungen, die einem Individuum zur Verfügung stehen.
2. Fertigkeiten: Spezielle technische Fähigkeiten, die ein Individuum zur Aus- führung einer Aufgabe benötigt.
3. Fähigkeiten: Effektive Umsetzung von Wissen und Fertigkeiten in einem Projektkontext. [42, S. 17]
Die Dimension Erfahrung wird in diesem Kontext nur indirekt einbezogen. Ein- zig im Zusammenhang mit Personenzertifizierungen wird sie berücksichtigt, da zur Erlangung fortgeschrittener Zertifikate ein Mindestmaß an relevanter Be- rufserfahrung nachzuweisen ist. Im Mittelpunkt des Rahmenwerkes steht das sogenannte Eye of Compentence. Es stellt ein komplettes Inventar der Kompe- tenzen dar, über das Inhaber bestimmter Rollen verfügen sollten. Diese werden in drei Themenfelder segmentiert:
1. Kontextkompetenzen (Perspective): Alle Methoden, Werkzeuge und Tech- niken, durch die eine Person mit seinem Umfeld interagieren kann, sowie all jene Grundüberlegungen, durch die Projekte motiviert werden.
2. Persönliche und soziale Kompetenzen (People): Summe der Attribute, die ein Einzelner benötigt, um erfolgreich an einem Projekt mitzuarbeiten oder dieses zu leiten.
3. Technische Kompetenzen (Practice): Spezifische Methoden, Werkzeuge und Techniken, die im Rahmen von Projekten zur Zielerreichung eingesetzt werden. [42, S. 28]
Zur Messung und Quantifizierung des durch einen Mitarbeiter erreichten Kom- petenzlevels existieren für jeden Kompetenzbereich sogenannten Kompetenzindikatoren (KCI). Damit eignet sich der Standard in besonderem Maße dafür, Mitarbeiter für eine gegebene Aufgabe bzw. Aktivität zu qualifizieren und den Entwicklungs- fortschritt kontinuierlich zu messen. Zur Planung und Durchführung einzelner Projekte eignet sich der Standard hingegen wenig, da — abgesehen von der Beschreibung der notwendigen Kompetenzen zur Realisierung bestimmter Ak- tivitäten — keinerlei Prozesse oder Vorgehensweisen etabliert werden. Daher wird die ICB hier nicht weitergehend betrachtet.
2.2.2 Agile Methoden
Der Wandel zu agilen Methoden wurden als Antwort auf sich stetig wandelnde Anforderungen in IT-Projekten entwickelt. Agiles — also flexibles und reakti- onsschnelles — Management von Projekten wird heute in einer Vielzahl von Frameworks wie beispielsweise SCRUM behandelt. Um diese Methoden einem gemeinsamen Qualitätsanspruch zu unterwerfen, wurde im Jahr 2001 das Ma- nifesto for Agile Software Development verfasst und von 17 Bündnispartnern unterzeichnet. [61, o. S.] Das Dokument umfasst zwölf zentrale Prinzipien, de- nen jedes agile Vorgehen folgen soll.
Im Laufe der Jahre veränderte sich der Kreis der Partner kontinuierlich und auch die Struktur des Manifestes wurde überarbeitet. Heute umfasst das Manifest zwölf Prinzipien, denen agile Arbeit grundsätzlich folgen sollte:
1. Den Kunden zufrieden stellen
2. Änderungen willkommen heißen
3. Regelmäßige Lieferung funktionierender Software
4. Bereichsübergreifende Zusammenarbeit
5. Unterstützung und Vertrauen
6. Konversation von Angesicht zu Angesicht
7. Funktionierende Software
8. Gleichmäßiges Tempo
9. Technische Exzellenz
10. Einfachheit
11. Selbstorganisierte Teams
12. Inspektion und Adaption12
Die Einhaltung dieser Prinzipien soll dazu beitragen, schnellst möglich auf Kunden- und Marktanforderungen reagieren zu können und jegliches Handeln im Pro- jektkontext einem gemeinsamen Qualitätsanspruch zu unterwerfen. Ziel ist es, in regelmäßigen Zyklen funktionierende Versionen eines Produktes bereitzustel- len, die einen zuvor definierten Nutzen für den Endkunden bereitstellen. Die gängigen agilen Methoden und Rahmenwerke werden in diesem Kapitel vorge- stellt.
2.2.2.1 Scrum
Im Jahr 1986 veröffentlichten die Professoren Hirotaka Takeuchi und Ikujiro Nonaka im Harvard Business Review einen Artikel mit dem Titel The new new product development game. [87, o. S.] Sie hatten über Jahre hinweg Unternehmen wie Honda und Fujitsu begleitet und die Einflüsse selbstorganisierter Teams auf die Leistungsfähigkeit und Innovationsfähigkeit von Organisationen untersucht. Die Ergebnisse der Untersuchungen zeigten, dass die Produktivität von Teams stieg, wenn sie sich selbst steuerten und innerhalb zeitlich begrenzter Phasen gemeinsam beschlossene Ziele verfolgten. Basierend auf diesen Erkenntnissen schufen Jeff Sutherland und Ken Schwaber in den 1990er Jahren den heute weltweit in Entwicklungsprojekten eingesetzten Scrum-Standard. [82, o. S.]
Das Scrum Handbuch formuliert Rollen, Ereignisse und Artefakte, die benötigt werden, um auf Basis regelmäßig wiederkehrender Zyklen zu jedem Zeitpunkt in einem Projekt über eine Produktversion zu verfügen, die potentiell veröffentlicht werden kann. Ziel ist es, durch eine frühzeitige Einbeziehung der Benutzer einen möglichst großen Mehrwert zu generieren und alle Bestrebungen auf die Be- reitstellung wesentlicher Funktionen zu fokussieren. Während es innerhalb eines selbst organisierten Teams keine definierten Rollen gibt, da das Entwicklungs- team als Ganzes für die Zielerreichung verantwortlich ist, definiert der Standard die folgenden Funktionen, die die Einhaltung der Methodik steuern und ermög- lichen:
1. Product Owner: Der Product Owner ist für die Wertmaximierung des Pro- duktes und das Management des sogenannten Product Backlogs verant- wortlich. In diesem Dokument werden alle Anforderungen an das Produkt zusammengefasst und nach Wertigkeit sortiert. Der Wert eines Eintrags bestimmt sich aus dem Maß der Einflussnahme auf das Ziel und die Missi- on des Produktes. Die Rolle wird grundsätzlich nur durch eine Person ausgefüllt, die für dieses zentrale Register verantwortlich ist.
2. Scrum Master: Der Scrum Master ist die Rolle, die das Team bei der Umsetzung der Scrum-Methodik unterstützt. Neben methodischem Coa- ching übernimmt er die Aufgaben desjenigen, der die Kommunikation von Externen mit dem Team ermöglicht und begleitet. Er optimiert die Zu- sammenarbeit in einer Weise, dass der generierte Wert maximiert wird.
3. Scrum Team: Das Scrum Team besteht aus dem Product Owner, dem Ent- wicklungsteam und dem Scrum Master. Teams sind grundsätzlich selbst organisiert und interdisziplinär. Sie entscheiden selbst, wie die Arbeit am besten getan werden kann und verfügen über alle Kompetenzen, die erfor- derlich sind, um eine Aufgabe abzuschließen.13
Den Kern der Methodik bilden die Ereignisse, durch die ein Projekt bestimmt wird. Grundsätzlich wird ein iteratives Vorgehen verfolgt, in dem relativ kur- ze Entwicklungsphasen einander unverzüglich folgen. Damit unterscheidet sich Scrum von Standards des klassischen PM insofern, dass keine Zeiträume (Pha- sen), sondern Zeitpunkte (Ereignisse) definiert werden. Diese dienen dazu, Un- sicherheiten in einem Projekt durch fortwährenden Austausch abzubauen. Das Thema der Unwägbarkeiten im Projektalltag wird im sogenannten Cone of Un- certainty beschrieben. Das Konzept besagt, dass der Grad der Unwissenheit immer weiter abnehmen sollte, je weiter ein Projekt voranschreitet. Da dem Projektteam zu Beginn wenige oder keine Informationen über das geplante Vor- haben zur Verfügung stehen, sollten folgenschwere Entscheidungen erst mög- lichst spät getroffen werden. Das führt bestenfalls dazu, dass möglichst wenige Ressourcen in die Korrektur von Fehlentscheidungen investiert werden müssen, die erst zu einem fortgeschrittenen Zeitpunkt offensichtlich werden. [59, o. S.]
Bereits in der Einleitung formuliert der Scrum-Guide den Grundsatz, dass Scrum leicht zu verstehen, aber schwer zu meistern ist. [82, S. 4] Diese in der Scrum- Gemeinde gängige Phrase meint, dass die Elemente des Rahmenwerkes an sich wenig komplex oder kompliziert sind. Die Um- und Durchsetzung des Stan- dards wiederum führt unter Umständen zu Schwierigkeiten, wenn Kernaspekte nicht beachtet werden. In diesen Fällen kommt es immer wieder zu sogenannten ScrumButs, also PM-Methoden, die zwar wie Scrum aussehen, allerdings we- sentliche Aspekte vernachlässigen. Der Begriff wurde aus dem — häufig in wenig erfolgreichen Scrum-Projekten formulierten — Satz „We do Scrum, BUT“ ab- geleitet. [83, o. S.] Die schiere Existenz eines solchen Begriffes zeigt, dass die Methode vollumfänglich umgesetzt werden sollte, um einen Mehrwert generie- ren zu können. Damit eignet sie sich nur bedingt als Grundlage für hybride PM-Modelle, die in Kapitel 2.2.3 näher erläutert werden.
Obgleich Scrum keine Phasen im klassischen Sinne, sondern vielmehr Ereignisse definiert, beschreiben diese Rahmenbedingungen für Prozessaktivitäten. Darum und auf Grund seiner Eigenschaft als weltweit anerkannter Best-Practice zur Steuerung von Projekten der Softwareentwicklung wird er in Kapitel 2.2.2.1 in die Prozessentwicklung mit aufgenommen.
2.2.2.2 (Rapid) Prototyping
Unter dem Begriff Prototyping versteht man eine Methode, bei der nicht sofort ein endgültiges System, sondern zunächst ein oder mehrere Prototypen, also Vorabversionen erstellt werden. [58, o. S.] Entwickler versuchen, schon zu einem frühen Zeitpunkt logische oder funktionale Fehler zu erkennen, indem sie Pro- totypen einem Kreis ausgewählter potentieller Benutzer zur Verfügung stellen. Diese testen das Produkt und geben dem Entwicklerteam Rückmeldungen zu Verbesserungspotenzialen. Auf dieser Basis werden Anforderungsspezifikationen angepasst und Entwicklungstätigkeiten geplant. Im Verlauf eines nachfolgenden Entwicklungszyklus wird dann ein neuer Prototyp erstellt. Die alten Prototypen werden in der Regel entsorgt, sofern sie keinen sentimentalen Wert für das Team haben (Wegwerfprototypen). [92, S. 83]
Anders als Scrum steht den Entwicklern nach Abschluss einer Phase kein einsatz- fähiges Inkrement zur Verfügung. Vielmehr wird die bestehende Version immer wieder getestet und verfeinert. Diese Methodik erfreut sich heute wachsender Beliebtheit, da aufgrund neuer Technologien, wie z. B. dem 3D-Druck und vir- tueller Modellierung, die Erstellung von Prototypen zunehmend billiger wird. In der Folge hat sich in den letzten Jahren eine Unterform des Prototypings, das Rapid Prototyping (sinngemäß: Schnelle Erstellung von Prototypen) etabliert. Die Grundlage zur Produktion dreidimensionaler Prototypen bilden sogenannte CAD-Daten. Dabei handelt es sich um am Computer erstellte Entwürfe, die in einer Rapid-Prototyping-Maschine eingelesen und zu einem Druckplan konver- tiert werden. Anschließend wird — ausgehend vom Querschnitt des Produktes — Schicht für Schicht ein 3D-Modell gedruckt. Dieses Verfahren ist sowohl schnell als auch kostengünstig. [91, o. S.]
Da es sich beim (Rapid) Prototyping um eine Methode zur Entwicklung von Produktvariationen handelt, die unabhängig von dem gewählten PM-Ansatz eingesetzt werden kann, wird im Folgenden nicht weiter auf diesen Ansatz ein- gegangen.
2.2.2.3 Lean (Startup)
Die Idee des Lean Managements (aus dem Japanischen: schlank) stammt aus den 60er Jahren des 20. Jahrhunderts und wurde beim japanischen Autobauer Toyota entwickelt. Ziel war es, durch stetige Optimierung und effiziente Pro- duktionsverfahren die eigene Fertigung so schlank wie möglich zu gestalten. [8, o. S.] Inspiriert wurde der Ansatz unter anderem durch Henry Ford, der 1908 begonnen hatte, Fahrzeuge am Fließband zu produzieren und so für jedermann erschwinglich zu machen. [6, o. S.] Das Lean Management wurde in den folgen- den Jahren kontinuierlich weiterentwickelt. Aus den gewonnenen Erkenntnissen kristallisierten sich die noch heute geltenden fünf Grundprinzipien heraus:
1. Kundenzentriert: Grundlage allen Handelns sind die Wünsche und Anfor- derungen des Kunden.
2. Identifikation des Wertstroms: Zerlegung der Abläufe in Aktivitäten, die durchdacht und analysiert werden. Alle Tätigkeiten werden letztendlich auf den Wertstrom hin ausgerichtet.
3. Flussprinzip: Produktion möglichst ohne Unterbrechung und Verzögerung.
4. Pull-Prinzip: Die Produktionskette läuft rückwärts gerichtet ab, da jede Aktivität vom Startpunkt Kunde ausgeht. Im Idealfall gibt es keine Lage- rung, keine Wartezeiten etc.
5. Kontinuierlicher Verbesserungsprozess: Fortwährende Realisierung von Ver- besserungspotenzialen durch Einsatz neuer Methoden, Ideen und Lernpro- zessen.14
Diese Grundannahmen liegen einer Vielzahl von Methoden des Projektmana- gements zugrunde, wie dem in Kapitel 2.2.2.1 vorgestellten Scrum. Darüber hinaus ist das Lean Management Namensgeber des sogenannten LeanStartups. Die von Eric Ries im Jahr 2008 erstmals in seinem Blog und im Jahr 2011 im gleichnamigen Buch veröffentlichte Methode zielt darauf ab, kontinuierliche und zielgerichtete Anpassungen an einem Produkt vorzunehmen und schnell auf Veränderungen des Marktes zu reagieren. [93, o. S.] Dazu wird, nach einer mög- lichst kurzen Konzipierungs- und Entwicklungsphase, ein Prototyp oder eine Betaversion („Minimum Viable Product“) an den Markt gebracht. Im Rahmen kurzer Entwicklungszyklen wird mithilfe der Rückmeldungen von Kunden („Va- lidated Learning“) das Produkt so weiterentwickelt, dass es den Marktansprü- chen gerecht wird. Nach der Datensammlung wird entschieden, ob das Produkt weiterentwickelt oder eine neue Idee verfolgt wird. Es werden minimale Ressour- cen investiert, um potenzielle Geschäftsmodelle zu testen. Erfolgreiche Modelle werden solange weiterverfolgt, bis sie sich nicht mehr verkaufen. Dieser Ansatz eignet sich insbesondere dazu, neue Unternehmungen zu begründen oder neue Ideen zu testen, ohne auf größere finanzielle und zeitliche Ressourcen zugreifen zu müssen.
Obwohl Lean Startup immer wieder im Zusammenhang mit agilen Methoden genannt wird, handelt es sich dabei nicht in erster Linie um einen PM-Ansatz, sondern vielmehr um ein Vorgehensmodell zur Existenzgründung. Dennoch ist es ratsam, Erwägungen zur Umsetzung eines angemessenen Sicherheitsniveaus zu Beginn jeder einzelnen Iteration zu treffen. Daher und weil Innovationen vielfach in diesem Rahmen entwickelt werden, wird der Ansatz im Folgenden in die Modellentwicklung mit einbezogen.
2.2.2.4 Design Thinking
Ähnlich wie die in den vorangegangenen Kapiteln vorgestellten agilen Methoden Scrum und Lean Startup ist Design Thinking ein benutzerorientierter Ansatz zur Entwicklung neuer Ideen und Problemlösungen. Die von den Gründern der Design- und Innovationsagentur IDEO im Jahr 1991 entwickelte Methode ba- siert auf der Annahme, dass die Zusammenarbeit von Menschen unterschied- licher Disziplinen in einem die Kreativität fördernden Umfeld dazu führt, die Bedürfnisse und Motivationen potenzieller Kunden zu verstehen und auf diesen Erkenntnissen beruhende Ideen generieren zu können. [45, o. S.]
Dazu wird ein aus sechs Schritten bestehender, iterativer Prozess durchlebt, der die Bedürfnisse eines prototypischen Benutzers in den Mittelpunkt der Analy- sebestrebungen stellt. Dieser wird durch ein — aus Experten unterschiedlicher Disziplinen bestehendes — Team beobachtet oder befragt, um bewusste oder unbewusste Bedürfnisse zu erkennen und auf dieser Basis potenzielle Lösungs- möglichkeiten für diese zu entwickeln. Solche Prototypen werden Testnutzern zur Verfügung gestellt. Basierend auf den Rückmeldungen der Testgruppe wird das Produkt anschließend entweder weiterentwickelt oder verworfen, um eine bessere Lösung für das erkannte Problem zu suchen.
Anders als der Lean Startup-Ansatz lässt sich Design Thinking im Kontext jeg- licher Projekte einsetzen, deren Ziel in der Entwicklung neuer Ideen oder der Lösung bestehender Probleme liegt. Um maßgebliche Sicherheitsanforderungen nicht unberücksichtigt zu lassen, sollten diese im Rahmen eines allgemeingülti- gen Vorgehensmodells zum PM zu einem zu definierenden Zeitpunkt analysiert werden. Daher wird auch diese Methode in Kapitel 3.1.5 weitergehend betrach- tet und in die Modellentwicklung mit aufgenommen.
2.2.2.5 DevOps
DevOps ist ein aus den englischen Begriffen Development und Operations beste- hender Kunstbegriff. Der Ansatz kombiniert Denkweisen, Praktiken und Tools, damit Unternehmen ihren Kunden Anwendungen und Services schnell und ein- fach zur Verfügung stellen können. Dazu arbeiten die Bereiche Entwicklung und Betrieb — anders als bislang üblich — Hand in Hand. Mitglieder der Abteilun- gen werden zu interdisziplinären Teams zusammengefasst, die über alle Kom- petenzen verfügen, um einen Anwendungslebenszyklus von der Entwicklungs- phase bis zur Außerbetriebnahme begleiten zu können. Darüber hinaus werden zunehmend Mitarbeiter aus der Qualitätssicherung und Informationssicherheit einbezogen, um diese Kernthemen zu steuern. [1, o. S.]
Neben dem Einsatz bereichsübergreifender Teams hat die Prozessautomatisie- rung einen hohen Stellenwert. Sie führt zu einer teils drastischen Reduzierung der Time-to-Market-Zeitspanne, da die meisten Anfragen nicht mehr manuell beantwortet werden müssen. Durch eine automatisierte Bereitstellung können mehrere Teams gleichzeitig an unterschiedlichen Funktionen arbeiten und so un- ter Umständen mehrere Versionen pro Tag veröffentlichen. [44, S. 158] Das der Automatisierung zugrunde liegende Prinzip ist unter dem Akronym Continuous Integration/Continuous Delivery (CI/CD) bekannt. Bei der Continuous Inte- gration werden regelmäßig Codeänderungen entwickelt, geprüft und in einem gemeinsamen Repository aggregiert. Im Rahmen der Continuous Delivery wer- den Softwareänderungen automatisch auf Fehler getestet und in ein Repository hochgeladen. [76, o. S.] Neben einer gesteigerten Produktivität und der damit einhergehenden schnellen Bereitstellung neuer Dienste kann DevOps, sofern es angenommen wird, darüber hinaus dazu beitragen, dass das Vertrauen innerhalb einer Organisation und damit die Zufriedenheit der beteiligten Mitarbeiter ver- bessert wird. Vertrauen entsteht dadurch, dass die involvierten Personen durch fortwährende Zusammenarbeit ein Gefühl dafür bekommen, welche Ziele clgen. [43, S. 1110]
Damit solch positive Effekte eintreten können, bedarf es eines grundlegenden kulturellen Wandels. Statt abteilungs- und problemorientiert zu denken, müssen Mitarbeiter dazu motiviert werden, sich selbst und das Unternehmen global und lösungsorientiert auszurichten. Dazu bedarf es einer positiven Feedbackkultur. Eine offene Kommunikation innerhalb der und zwischen den Teams führt dazu, dass Schwierigkeiten bereits kurz nach ihrem Auftreten erkannt und beseitigt werden können. [26, S. 13 f.]
Trotz der oben genannten Vorteile handelt es sich bei DevOps um keine PM- Methode im eigentlichen Sinne. Vielmehr stellt der Ansatz eine Philosophie dar, um Organisationen flexibel aufzustellen. Da darüber hinaus kein Phasenmodell oder explizite Aktivitäten formuliert werden, wird bei der Entwicklung des all- gemein gültigen Phasenmodells auf eine tiefer gehende Analyse des Konzeptes verzichtet. Da DevOps allerdings eine wesentliche und zeitgemäße Methode zur Softwareentwicklung darstellt, wird in Kapitel 4.7 aufgezeigt, wie eine Absiche- rung dieses Entwicklungsprozesses erfolgen kann.
2.2.3 Hybride/Selektive Modelle
Wie die vorangegangenen Kapitel zeigen, existiert eine breite Methodenvielfalt im Kontext des Projektmanagements. Unabhängig davon, ob ein Ansatz dem klassischem oder agilen PM zuzuordnen ist, haben sie gemein, dass Benutzer dabei unterstützt werden sollen, in einem definierten Zeitraum ein gegebenes Ziel zu erreichen. Dazu können potenziell alle Mittel eingesetzt werden, die die Natur und Funktionsweise einer Organisation unterstützen.
Die bereits zitierte Studie Status Quo Agile von Prof. Komus der Hochschu- le Koblenz ergab, dass heute ein Trend zum Einsatz agiler Methoden in IT- oder IT-nahen Projekten erkennbar ist. 34 % der befragten Teilnehmer setz- ten bereits entsprechende Vorgehensweisen und Prozesse ein. Bemerkenswert dabei ist, dass lediglich 20 % der Befragten durchgängig agil arbeiteten. 12 % nutzten durchgängig klassische Methoden. Das wirft die Frage auf, welche Me- thoden die übrigen 68 % der Unternehmen einsetzen. Die Studie ergab, dass über zwei Drittel der Grundgesamtheit auf sogenannte hybride bzw. selektive Modelle setzten. [56, S. 8 ff.]
Bei diesem Ansatz werden diejenigen Methoden, Prozesse und Tools ausgewählt, die zu der eigenen Organisationen passen und deren Zielerreichung unterstützen. Dieses Vorgehen entspricht dem Grundsatz, dass Methoden dem Unternehmen und nicht Unternehmen Methoden angepasst werden sollten. Auch andere Ex- perten kommen — basierend auf ihren in der Praxis gewonnenen Erfahrungen — zu ähnlichen Schlüssen und untermauern so die Erkenntnisse von Prof. Ko- mus. [86, o. S.]
Der aufgezeigte Trend veranschaulicht, dass das hier gewählte Vorgehen — näm- lich die Formulierung eines allgemeingültigen Phasenmodells für Projekte — in der Praxis anwendbar ist und bereits vielfach genutzt wird. Schlussendlich kommt es darauf an, dass eine Methode zu den durch den Benutzer beabsich- tigten Ergebnis führt und nicht darauf, ein ausgewähltes Rahmenwerk in seiner gesamten Breite und Tiefe einzusetzen.
2.2.4 Weitere PM-Methoden
Neben den bereits vorgestellten Standards zum PM gibt es eine Vielzahl wei- terer Methoden, die in diesem Zusammenhang eingesetzt werden können. Dazu zählen unter anderem Vorgehensweisen, um nicht nur einzelne Projekte, sondern mehrere Vorhaben parallel zu steuern. Hier werden folgende Varianten unter- schieden:
1. Multiprojektmanagement: Gleichzeitige Steuerung mehrerer Projekte. Hier gilt es, Interdependenzen zu erkennen und Aufgaben und Ressourcen so zu verteilen, dass alle Unterfangen erfolgreich abgeschlossen werden können. Ein maßgeblicher Standard dazu ist die DIN 69909 - Multiprojektmana- gement - Management von Projektportfolios, Programmen und Projekten, die Anwendern in vier Teilen Prozesse, Methoden und Rollen zur Durch- führung der wesentlichen Aufgaben an die Hand gibt.15
2. Programmmanagement: Zeitlich begrenzte, inhaltliche Zusammenfassung zusammengehörender Projekte. Anders als im PM wird hier allerdings nicht nur ein einzelnes, spezifisches Projektziel verfolgt. Vielmehr geht es darum, über einen längeren (aber zeitlich begrenzten) Zeitraum einen um- fangreichen Mehrwert für eine Organisation zu schaffen. Als maßgeblicher Standard hat sich die ISO 21504 Project, programme and portfolio manage- ment – Guidance on portfolio management durchgesetzt. Diese beschreibt nicht nur Methoden zum Programmmanagement, sondern fasst Best Prac- tices zum Projekt-, Programm und Portfoliomanagement in einem Werk zusammen.16
3. Projektportfoliomanagement: Verwaltung aller Projekte einer Organisati- on. Hier werden global definierte Kennzahlen aller Projekte konsolidiert und ausgewertet. Dieses Vorgehen dient in erster Linie dazu, der Leitungs- ebene eine Möglichkeit zur Steuerung aller Vorhaben zur Verfügung zu stellen. In diesem Kontext haben sich ebenfalls die bereits genannte Norm ISO 21504, sowie der durch die Firma AXELOS veröffentlichte Standard Management of Portfolios (MoP) etabliert.17
Doch nicht nur die Steuerung großer, zusammenhängender Vorhaben steht im Mittelpunkt der Bestrebungen, einheitliche Methoden zu entwickeln. Auch die Durchführung einzelner Projektaktivitäten wurde im Verlauf der letzten Jahr- zehnte zunehmend durch die Verbreitung allgemein anerkannter Werkzeuge zur Problemlösung unterstützt. Ein Beispiel dafür ist die S.M.A.R.T-Methode, die beschreibt, wie Ziele formuliert werden sollten. Das Akronym steht für die Ei- genschaften spezifisch, messbar, anspruchsvoll (oder akzeptiert), realistisch und terminiert. [94, o. S.]
Durch die branchenübergreifende Anerkennung dieses Werkzeuges wurde ein gemeinsames Verständnis für Qualitätsanforderungen an Zielformulierungen ge- schaffen. Ein weiteres, vielfach eingesetztes Werkzeug ist das Kanban, was soviel wie Karte bedeutet. Das Instrument stammt aus Japan und wurde 1947 erst- mals durch Taiichi Ohno bei Toyota eingeführt. Es dient der Transparenz offener Aufgaben, der Visualisierung des aktuellen Projektfortschrittes mit Hilfe farbi- ger Karten, der Aufdeckung von Flaschenhälsen und der Motivation. Besonders im agilen Umfeld ist das Werkzeug heute nicht mehr wegzudenken. [95, o. S.]
Diese beiden höchst unterschiedlichen Methoden deuten die thematische Band- breite potenzieller Hilfsmittel an, die sich im Zusammenhang mit dem Mana- gement von Projekten in der Vergangenheit bewährt hat. Durch den vielfachen Einsatz solcher Werkzeuge werden diese in der Praxis immer wieder getestet, verfeinert und an aktuelle Anforderungen der Märkte und der Arbeitswelt an- gepasst.
2.3 Informationssicherheit und deren Ziele
Die Absicherung geschäftskritischer Informationen ist eine Notwendigkeit, die eigentlich intuitiv verfolgt werden sollte. Dies wurde in der Vergangenheit aller- dings immer wieder versäumt. Dabei verfügt jede Organisation über Informa- tionen, die — in Abhängigkeit von ihrem Geschäftszweck — mehr oder weniger deren Lebensader darstellen. Unabhängig davon, ob es sich um Kundendaten, Baupläne, Mitarbeiterinformationen oder sonstige Firmengeheimnisse handelt, gilt: Werden vertrauliche Informationen unbefugten Dritten zugänglich gemacht, kann ein erheblicher Schaden entstehen.
Während diese Verantwortung bislang meist der Unternehmenssicherheit (phy- sische Absicherung von Gelände, Gebäuden und Räumen) und IT (alle tech- nologiebezogenen Schutzmaßnahmen) überantwortet wurde, zeigt sich heute ein zunehmender Trend zur zentralen Steuerung aller relevanter Sicherheitsmaßnah- men im Rahmen eines ISMS für die gesamte Organisation. Abhängig von der Branche und Unternehmensgröße wird dies auch von Seiten des Gesetzgebers gefordert. Betreiber kritischer Infrastrukturen beispielsweise müssen mindestens alle zwei Jahre nachweisen, dass sie ein angemessenes Sicherheitsniveau aufrecht- erhalten. [32, S. 9] Durch die Umsetzung entsprechender Maßnahmen werden die folgenden Schutzziele der IS verfolgt:
1. Vertraulichkeit: Informationen dürfen nur denjenigen zugänglich gemacht werden, die zur Nutzung oder Einsichtnahme berechtigt sind.
2. Integrität: Informationen sind vollständig und unverändert.
3. Verfügbarkeit: Dem Benutzer stehen alle Dienstleistungen, Funktionen und Informationen zum geforderten Zeitpunkt in der geforderten Qualität zur Verfügung.18
Neben diesen drei Hauptschutzzielen werden — abhängig von der jeweils ge- wählten Quelle — weitere Ziele verfolgt. Beispielsweise formuliert das Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG) in § 8 a Anforderungen an die Authentizität von Informationen. [32, S. 9] Damit ist die überprüfbare Glaubwürdigkeit und Echtheit von Informationen gemeint. [79, o. S.] Unabhängig von explizit betrachteten Schutzzielen ist die IS kritisch für den Fortbestand von Organisationen, da ohne die zentralen Geschäftsinforma- tionen eine Leistungserbringung in der Regel kaum möglich ist.
2.4 Stand der Technik
Die Phrase Standder Technik wird heute vielfach im Rahmen der Anforderungs- definition technischer Lösungen verwendet. Gleichzeitig zeigt die Praxis, dass deren inhaltliche Bedeutung meist nur unzureichend bekannt ist. Eine belastba- re Definition des Begriffs findet sich in dem — zuletzt im Jahr 2008 durch das Bundesministerium der Justiz (BMJ) aktualisierten — Handbuch der Rechts- förmlichkeit. [23, o. S.] Das Dokument umfasst Empfehlungen zu Form und Ge- staltung von Gesetzen und Rechtsverordnungen. Hier werden in Kapitel 4.5.1 als Generalklauseln für die Bezugnahme auf technische Regeln die folgenden Termini beschrieben, wobei sich die „Auswahl der angemessenen Formulierung von Gefährdungspotenzial der Materie, die geregelt werden soll, und nach der technischen Beherrschbarkeit dieses Gefährdungspotenzials“ richtet. [23, S. 84] Dabei werden die folgenden Absicherungsvarianten unterschieden:
Allgemein anerkannte Regeln der Technik: Bei geringem Gefährdungspotential oder dann anwendbar, wenn die Materie auf Grund gesicherter Erfahrun- gen technisch beherrschbar ist. Entsprechende Regeln können schriftlich fixiert oder mündlich überliefert sein.
Stand der Technik: Das Anforderungsniveau liegt zwischen dem anerkannter Regeln und dem Stand von Wissenschaft und Technik. „Stand der Technik ist der Entwicklungsstand [..], der nach herrschender Auffassung führen- der Fachleute das Erreichen des gesetzlich vorgegebenen Zieles gesichert erscheinen lässt“. [23, S. 85] Alle eingesetzten Methoden müssen bereits in der Praxis genutzt werden oder alternativ hinlänglich getestet worden sein.
Stand von Wissenschaft und Technik: Gilt für das höchste Anforderungsniveau bzw. in Fällen mit einem sehr hohen Gefährdungspotential. Anders als beim Stand der Technik werden solche Lösungen berücksichtigt, die bis- lang nicht in der Praxis eingesetzt oder ausführlich getestet wurden. Das setzt voraus, dass Experten aus Wissenschaft und Technik zu der Auffas- sung gelangen, dass dies zum Erfolg führen wird.
Sowohl der Stand der Technik, als auch der von Wissenschaft und Technik ba- sieren auf den Einschätzungen von Experten. Sie können allenfalls für einen gegebenen Zeitpunkt x definiert werden. Der Versuch, eine Technologie grund- sätzlich entsprechend auszurichten setzt voraus, dass dieser Zeitpunkt definiert und bei der Planung von Entwicklungszyklen berücksichtigt wird. Anstelle der gängigen Formulierung: „Das Produkt entspricht dem Stand der Technik“ sollte daher besser folgende Variante verwendet werden: „Das Produkt entspricht dem Stand der Technik zum 01. März 2019.“
Daraus folgt, dass eine Lösung, um fortwährend dem Stand der Technik zu ent- sprechen, kontinuierlich weiterentwickelt werden muss. Da grundlegende Ver- änderungen üblicherweise ressourcenintensiv sind, muss jede Organisation ent- scheiden, welche Zeitspanne zwischen den Veröffentlichungen zweier Versionen liegen darf, wie lange also ein gegebener Stand der Technik eingesetzt wird. Diese Dauer hängt von der jeweiligen Branche und Technologie ab und wird maßgeblich von der durchschnittlichen Länge üblicher Entwicklungs- und Pro- duktlebenszyklen beeinflusst.
Da sich entsprechende Zyklen in der Vergangenheit durch die Einführung neuer Technologien und Methoden zur Effizienzsteigerung stetig verkürzt haben, ist davon auszugehen, dass auch ein stichtagsbezogener Stand der Technik künf- tig in sich verkürzenden Zyklen zu hinterfragen ist. Der Produktlebenszyklus eines VW Golf beispielsweise verkürzte sich seit der Veröffentlichung des Golf I im Jahr 1974 bis zum Golf V im Jahr 2008 von 6,8 auf 2,6 Jahre. [60, o. S.] Ähnliche Entwicklungen lassen sich auf vielen Märkten beobachten. Dies gilt in besonderem Maße im Technologieumfeld. Laut dem nach seinem Verfasser Gor- don Moore benannten mooreschen Gesetz aus dem Jahr 1965 verdoppelt sich die Komplexität integrierter Schaltkreise und damit die zur Verfügung stehende Rechenkapazität auf gleicher Fläche alle 18-24 Monate. Die Produktlebenszy- klen haben sich diesem Rhythmus weitgehend angepasst, auch wenn das Gesetz im Jahr 2016 erstmals falsifiziert wurde.19 [96, o. S.]
Als Richtwert im deutschen Behörden- und Kritische Infrastrukturen (KRITIS)- Umfeld bietet sich zur Formulierung einer zeitlichen Gültigkeit eines gegebenen Standes der Technik eine Forderungen aus dem KRITIS-Kontext an. Das BSIG formuliert, wie bereits erwähnt, in § 8a (3), dass KRITIS-Betreiber alle zwei Jahre nachzuweisen haben, dass die eingesetzten Sicherheitsmaßnahmen dem Stand der Technik entsprechen (siehe Kapitel 4.1.2). [32, S. 9] Daraus abge- leitet kann davon ausgegangen werden, dass diese Zeitspanne als angemessen betrachtet werden darf. Die übliche Dauer von Entwicklungszyklen und eine Analyse rechtlicher Rahmenbedingungen sollten Grundlage jeder Methodik zur Gültigskeitsdefinition eines gegebenen Standes der Technik sein.
2.5 Angemessenheit
Der Angemessenheitsbegriff stammt aus dem Strafrecht und stellt ein Kriteri- um des Grundsatzes der Verhältnismäßigkeit dar (Verhältnismäßigkeitsprinzip). Nach diesem Prinzip ist eine Maßnahme dann verhältnismäßig, wenn sie einem „legitimen (öffentlichen) Zweck dient und überdies geeignet, erforderlich und an- gemessen ist“. [54, o. S.] Eine Vorgehensweise in einem gewissen Kontext ist nur dann angemessen, wenn die Nachteile, die mit ihr verbunden sind, im Verhält- nis zu den Vorteilen stehen, die sie bewirkt. Im Rahmen der Angemessenheit wird also eine genaue Abwägung sämtlicher Vor- und Nachteile der Maßnahme vorgenommen. [25, o. S.]
Diese — durch das Bundesverfassungsgericht formulierte — Definition lässt dar- auf schließen, dass die Eigenschaft der Angemessenheit immer dann vorliegt, wenn die Kosten dem potenziellen Nutzen einer Maßnahme entsprechen bzw. der Nutzen die Kosten übersteigt. Dabei ist es nicht notwendig, alle grundsätz- lich denkbaren Alternativen umzusetzen. Im Kontext der IS bedeutet diese An- nahme, dass die in einem gewissen Zusammenhang wirkenden Risiken analysiert und quantifiziert werden müssen. Anschließend ist basierend auf den gewonne- nen Erkenntnissen abzuwägen, welche Schutzmaßnahmen umzusetzen sind, um die Eintrittswahrscheinlichkeit der erkannten Gefährdungen so zu reduzieren, dass sie dem Risiko-Appetit einer Organisation entspricht.
Zusammenfassend müssen also — um ein angemessenes Sicherheitsniveau rea- lisieren zu können — grundsätzlich der Kontext, die Kosten und die Wirksam- keit potenzieller Maßnahmen untersucht werden. Dieser Ansatz wird im Folgen- den insofern verfolgt, als die im Rahmen von Innovationsvorhaben mindestens umzusetzenden Maßnahmen aus der inhaltlichen Ausrichtung eines gegebenen Projektes und aus den in diesem Kontext wirkenden Einflussfaktoren abgeleitet werden. Die gängigen Faktoren werden in Kapitel 4 untersucht.
3 Standardisiertes Phasenmodell von Innovationsprojekten der IT
Um evaluieren zu können, wie ein Phasenmodell des Projektmanagements be- schaffen sein muss, um dem Anspruch der Allgemeingültigkeit genügen zu kön- nen, werden im Folgenden in Kapitel 3.1 diejenigen PM-Methoden tiefergehend analysiert, die im Rahmen der Voranalyse in Kapitel 2.2 als wesentlich für die Modellformulierung definiert wurden. Dabei liegt der Fokus auf der Beantwor- tung der folgenden Kernfragen:
1. In welche Schritte, Phasen oder Aktivitäten werden Projekte gegliedert?
2. Mit welchem Ereignis beginnt eine Phase und womit endet sie?
3. Welches Ergebnis liegt nach Abschluss einer Phase vor?
Basierend auf den Erkenntnissen aus Kapitel 3.1 wird anschließend der Ver- such unternommen, ein Phasenmodell zu formulieren, das sich ohne erheblichen Mehraufwand bzw. ohne Anpassung eines bereits verwendeten Vorgehensmo- dells auf die gängigen PM-Methoden abbilden lässt.
3.1 Phasen- und Aktivitätsanalyse maßgeblicher PM-Methoden
Die in Kapitel 2.2 durchgeführte Voranalyse hat gezeigt, dass bei weitem nicht alle Methoden, die im Zusammenhang mit dem Management von Projekten eingesetzt werden, eine Formulierung spezifischer Aktivitäten oder Phasen vor- sehen. Vielmehr legt jedes Rahmenwerk einen speziellen Fokus auf die Anfor- derungen und Besonderheiten spezifischer Zielgruppen. Lediglich fünf der im Vorfeld untersuchten Methoden beschreiben Vorgehensweisen, die spezifische Abläufe vorsehen. Diese werden im folgenden Kapitel hinsichtlich der oben ge- nannten Fragestellungen untersucht. Bei den anderen Modellen handelt es sich eher um grundlegende Philosophien oder Werkzeuge, die unabhängig vom ge- wählten Rahmenwerk die Produktivität und Qualität innerhalb von Projekten steigern sollen. Letztgenannte werden — wie bereits erwähnt — nicht weiterge- hend vertieft.
3.1.1 PRINCE2
Das prozessorientierte Rahmenwerk PRINCE2, das dem klassischen Projektma- nagement zuzuordnen ist, stellt einen der maßgeblichen Standards dieses The- menfeldes dar. Die sieben durch das Handbuch vorgesehenen Prozesse werden in die Kategorien Liefern, Managen und Lenken von Projekten rubriziert. Ei- nige der Prozesse, wie beispielsweise die Vorbereitung eines Projektes, werden einmalig im Projekt durchlaufen. Andere, wie z. B. die Projektlenkung, werden fortlaufend oder regelmäßig durchgeführt, um den Projekterfolg sicherzustellen. Dabei ist zu berücksichtigen, dass die Methoden an die Rahmenbedingungen der Organisation anzupassen sind. Dies soll sicherstellen, dass nur diejenigen Aktionen durchgeführt werden, die zur erfolgreichen Erstellung eines Produktes benötigt werden. Der Standard umfasst folgende Prozesse:
1. Vorbereiten eines Projektes: Ziel der Projektvorbereitung ist die Beantwor- tung der Frage, ob es sich bei dem geplanten Vorhaben um ein durchführ- bares und lohnendes Projekt handelt. Die positive Beantwortung dieses Sachverhalts ist die Voraussetzung für die Projektinitiierung. Ausschlag- gebendes Kriterium dafür, dass es sich um ein lohnendes Projekt handelt, ist die wirtschaftliche Rechtfertigung, die im Business Case-Entwurf eva- luiert wird. Darüber hinaus ist zu eruieren, ob alle für die Initiierung eines Vorhabens notwendigen Verantwortlichkeiten und Befugnisse vorhanden sind.20
2. Lenken eines Projektes: Im Rahmen der Lenkung eines Projektes soll ein eingesetzter Lenkungsausschuss in die Lage versetzt werden, seiner Verant- wortung für den Projekterfolg nachzukommen. Dazu fällt er wesentliche Entscheidungen und steuert den allgemeinen Projektverlauf. Die Abwick- lung im Tagesgeschäft überlässt er dem Projektmanager.21
3. Initiieren eines Projektes: Zweck des Prozesses ist die Formulierung ei- ner Beschreibung für das Projekt, die der Organisation vermittelt, welche Ressourcen benötigt werden, bevor Entscheidungen getroffen werden. Im Zentrum aller Bestrebungen steht die Formulierung eines gemeinsamen Verständnisses zu den erwarteten Chancen und Risiken des Projektes und den damit verbundenen Kosten. Darüber hinaus werden Qualitätskriterien formuliert, an denen der Projekterfolg gemessen werden soll.22
4. Steuern einer Phase: Hier werden die anfallenden Arbeiten erbracht und verfolgt, offene Punkte gesteuert und erzielte Fortschritte an den Len- kungsausschuss kommuniziert. Darüber hinaus werden — sofern dies nö- tig ist — Korrekturmaßnahmen eingeleitet, damit die Phase innerhalb der vorgegebenen Toleranzen verbleibt.23
5. Managen eines Phasenübergangs: Bei der Steuerung von Phasenübergän- gen ist zu gewährleisten, dass der Lenkungsausschuss hinreichend spezifi- sche Informationen erhält, um den bisher erreichten Projekterfolg beurtei- len zu können, die nächste Phase freizugeben und sicherzustellen, dass das Projekt weiterhin wirtschaftlich ist und die damit verbundenen Risiken im Rahmen der Akzeptanzgrenzen liegen.24
6. Managen der Produktlieferung: Im Rahmen dieses Prozesses wird die Be- ziehung zwischen dem Projektmanager und den Teammanagern gesteuert und kontrolliert, indem formelle Anforderungen an die Abnahme, Ausfüh- rung und Lieferung der Projektergebnisse formuliert werden. Letztgenann- te fällt die Aufgabe zu, Teilprojekte so zu steuern, dass ein oder mehrere Teilprodukte geliefert werden können.25
7. Abschließen des Projektes: Die abschließende Projektphase dient dazu, das Projektendprodukt abzunehmen und zu evaluieren, ob die eingangs definierten Ziele — bzw. diejenigen, die im Rahmen des Änderungsmana- gements in die Projektleitdokumentation aufgenommen wurden — hinrei- chend erfüllt wurden. Das Produkt wird an den Kunden übergeben und in den Produktivbetrieb überführt.26
Für sämtliche Prozesse werden Kriterien definiert, durch die eine Phase ausgelöst und beendet wird. Darüber hinaus definiert der Standard explizite Erwartun- gen an die Ergebnisse jedes Entwicklungsabschnitts. Tabelle 1 beschreibt diese Parameter.
Tabelle 1: Phasenübersicht PRINCE2
Abbildung in dieser Leseprobe nicht enthalten
3.1.2 V-Modell
Ähnlich wie das Wasserfallmodell beschreibt das V-Modell eine sequenzielle Ab- folge von Projektphasen, die im Rahmen der Produktentwicklung durchlaufen werden. Der wesentliche Unterschied der Modelle besteht darin, dass bei einem Einsatz des V-Modells nicht nur Primärprodukte entwickelt werden, sondern zusätzlich in jeder Phase Tests formuliert werden, die dazu geeignet sind, die Qualität des Endproduktes zu überprüfen und so zu gewährleisten. Dazu wer- den — abhängig von der gewählten Quelle — mindestens die folgenden Phasen durchlaufen:
1. Anforderungsdefinition: Formulierung aller Anforderungen, die das zu ent- wickelnde Produkt erfüllen soll. Dazu werden die maßgeblichen Interessens- parteien (Stakeholder) befragt. Darüber hinaus können bekannte Markt- anforderungen in die Anforderungsdokumentation mit aufgenommen wer- den.
2. Funktionaler Systementwurf: Formulierung der fachlichen Funktionen, die das Endprodukt bereitstellen soll.
3. Technischer Systementwurf: Formulierung der technischen (nicht-funktion- alen) Anforderungen, denen das Endprodukt genügen soll.
4. Komponentenspezifikation: Beschreibung der Funktionen aller Komponen- ten hinsichtlich der zu generierenden Ausgabewerte bei Eingabe spezifi- scher Eingabewerte und Formulierung von Anforderungen an nicht funk- tionales Verhalten (z. B. Ressourcenmanagement).
[...]
1 Im Folgenden ist bei der Verwendung von Rollen- und Funktionsbezeichnungen stets so- wohl die weibliche als auch die männliche Form gemeint. Von einer geschlechtsneutralen Ausdrucksweise wird daher abgesehen.
2 [49, o. S.]; [18, o. S.]
3 [82, o. S.]; [42, o. S.]; [9, o. S.]; [64, o. S.]
4 [80, o. S.]; [69, o. S.]
5 [71, o. S.]; [38, o. S.]; [34, o. S.]
6 Die Einschätzung, welche Methoden besonders verbreitet sind, beruht auf durch den Autor im Rahmen vielfältiger Projekte im Themenfeld der Informationssicherheit gewonnenen Erfahrungen.
7 [65, o. S.] & [85, S. 2]
8 Benannt nach Walter Edward Deming, geboren am 14. Oktober 1900 in Sioux City, Iowa; gestorben am 20. Dezember 1993 in Washington, D.C. [89, o. S.]
9 [63, o. S.]
10 10 Ebd.
11 [63, o. S.]
12 [74, o. S.]
13 [82, S. 5 ff.]
14 [8, o. S.]
15 [2, o. S.]
16 [48, o. S.]
17 [4, o. S.]
18 [19, S. 14]
19 Anmerkung des Autors: Die mooreschen Gesetze werden — abhängig von der gewählten Quelle — immer wieder als sich selbst erfüllende Prophezeiung bezeichnet. Es stellt sich die Frage, ob die Formulierung des Gesetzes und dessen Bekanntheit zu seiner Erfüllung beigetragen haben.
20 [5, S. 137 f.]
21 [5, S. 153]
22 [5, S. 167]
23 [5, S. 187]
24 [5, S. 215]
25 [5, S. 207]
26 [5, S. 229]
-
-
-
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.