Systematische Initialplanung eines Softwareprojekts an einem praktischen Beispiel

Inhalt

1 Motivation

2 Projektbeschreibung
2.1 Projektsteckbrief
2.1.1 Allgemein
2.1.2 DOP-Projektsteckbrief
2.2 Zielbeschreibung und Zielhierarchie
2.2.1 Allgemein
2.2.2 Ziele im Projekt DOP
2.3 Zielbeziehungen und Zielkonflikte
2.3.1 Allgemein
2.3.2 Zielbeziehungen und Zielkonflikte in DOP

3 Projektumfeld- und Stakeholderanalyse
3.1 Projektumfeld
3.1.1 Allgemein
3.1.2 DOP-Projektumfeld
3.2 Stakeholder
3.2.1 Allgemein
3.2.2 Stakeholder im Projekt DOP
3.3 Stakeholderportfolio
3.3.1 Allgemein
3.3.2 DOP-Stakeholderportfolio

4 Risikoanalyse
4.1 Risiken erfassen und klassifizieren
4.1.1 Allgemein
4.1.2 Risiken in DOP
4.2 Risiken bewerten
4.2.1 Allgemein
4.2.2 Risikobewertung in DOP
4.3 Maßnahmen zur Risikobegegnung
4.3.1 Allgemein
4.3.2 Maßnahmen zur Risikobegegnung in DOP

5 Projektorganisation
5.1 Allgemein
5.2 Formen der Projektorganisation
5.3 Projektorganisation in DOP

6 Phasenplanung
6.1 Allgemein
6.2 Beschreibung der Projektphasen
6.3 Meilensteinliste
6.4 Grafischer Phasenplan

7 Projektstrukturplan
7.1 Allgemein
7.2 Der Projektstrukturplan in DOP
7.3 Eine Arbeitspaketbeschreibung aus DOP

8 Ablauf- und Terminplanung
8.1 Allgemein
8.2 DOP Vorgangsliste
8.3 Vernetzter Balkenplan des Projekts DOP
8.4 Beispiele für Anordnungsbeziehungen in DOP
8.4.1 Normalfolge
8.4.2 Anfangsfolge
8.4.3 Endfolge

9 Einsatzmittel- / Kostenplanung
9.1 Allgemein
9.2 Einsatzmittelbedarf / Einsatzmittelplanung
9.3 Auslastungsprofil für kritische Einsatzmittel
9.4 Projektkosten

10 Teambildung, Kommunikation und Führung
10.1 Allgemein
10.2 Das DOP-Team
10.3 Kommunikation im Projekt DOP
10.4 Führung im Projekt DOP

11 Wissensmanagement im Projekt
11.1 Allgemein
11.2 Wissensmanagement in DOP

12 Integrierte Projektsteuerung
12.1 Allgemein
12.2 Integrierte Projektsteuerung in DOP
12.2.1 Earned-Value-Analyse
12.2.2 Meilensteintrendanalyse

13 Fazit
Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Anhang 1: DOP-Risikoliste
Anhang 2: Der DOP-Projektstrukturplan
Anhang 3: DOP Ressourcenbedarf (tabellarisch)
Anhang 4: DOP Ablauf- und Terminplanung
Glossar
Literatur
Index

1 Motivation

Zumindest in der Anfangsphase laufen viele Projekte relativ ähnlich ab. Es gilt das Projektumfeld kennenzulernen, Termine und Aufgaben abzuschätzen und Ressourcen zu planen. Während bei kleineren Projekten der Projektleiter meist alle Schritte intuitiv richtig macht, zeigt die Erfahrung, dass mit zunehmender Projektgröße, eventuell begleitet von der Bildung von Teilprojekten, notwendige Aktivitäten schnell aus dem Blickfeld geraten. Ziel dieser Arbeit ist es, an einem Beispiel die Schritte der anfänglichen Planung zu beschreiben. Der Leser kann nach der Lektüre Aktivitäten und Begriffe einordnen und im Kontext eigener Projekte anwenden.

Jedes Kapitel der Arbeit beschreibt eine Aktivität im Rahmen der Projektinitiierung. Dabei wird zunächst allgemein der Inhalt jeder Tätigkeit beschrieben, um im Anschluss daran im Kontext eines durchgängigen Beispielprojekts deren Umsetzung zu veranschaulichen. Die beschriebenen Tätigkeiten spiegeln die Erfahrungen des Autors aus der Mitarbeit und Leitung mehrerer Projekte wieder und stellen einen Versuch dar, die über die Zeit hinweg gesammelten optimalen Vorgehensweisen in sachlogischer Reihenfolge aufzubereiten.

Als durchgängiges Beispielprojekt wird mit dem „Dealer Objectives Planning (DOP)“ ein Software Entwicklungsprojekt aus der Automobilindustrie skizziert. Kapitel zwei (Projektbeschreibung) gibt im Rahmen des Projektsteckbriefs eine Einführung in die Thematik, soweit dies für die folgenden Managementaktivitäten erforderlich ist. Das Projekt wurde in abgewandelter Form real durchgeführt.

Die in dieser Arbeit beschriebene „systematische Initialplanung“ ist abzugrenzen von der tatsächlichen Beauftragung durch den Kunden. Die Initialplanung beinhaltet alle Schritte, die notwendig sind, damit ein Team die Projektarbeit tatsächlich aufnehmen kann. Im optimalen Fall werden diese Schritte vorab in einem vom Kunden beauftragten Miniprojekt durchgeführt mit dem Ziel, die Grundlage für eine fundierte Zeit- und Kostenaussage des tatsächlichen Projektumfangs zu schaffen.

Gerade bei größeren Projekten ist es jedoch im Rahmen von Ausschreibungen durchaus üblich, als Lieferant in Vorleistung zu gehen und die Initialplanung ganz oder in weiten Teilen auf eigene Kosten durchzuführen. Die erarbeiteten Ergebnisse sind dann die Grundlage für eine fundierte Angebotspräsentation mit der Strategie, Mitbewerber durch Professionalität aus dem Rennen zu werfen. Bei dieser Herangehensweise wird die Initialplanung als Projekt „Angebotserstellung“ intern abgewickelt, wobei stets auf ein angemessenes Kosten-/Nutzenverhältnis zu achten ist – schließlich besteht ja das nicht unerhebliche Risiko, die Ausschreibung nicht zu gewinnen.

2 Projektbeschreibung

Dieses Kapitel zeigt zunächst, wie eine steckbriefartige Projektbeschreibunggestaltet werden kann. Im Anschluss daran werden die Projektziele formuliert und kategorisiert nach Terminzielen, Leistungszielen und monetären Zielen. Schließlich werden Konflikte zwischen den identifizierten Zielen aufgezeigt und beispielhaft die Lösung eines Konflikts beschrieben.

2.1 Projektsteckbrief

2.1.1 Allgemein

„Ausschnitt aus einer Wissenslandkarte“ (Hunger, 2004) gibt den Zweck des Projektsteckbriefs sehr gut wieder. Wie bei einer Landkarte geht es darum, nicht jedes Detail zu zeigen, sondern das Projekt bewusst aus der Vogelperspektive zu betrachten: Welchen großen Nutzen erfüllt es aus Kundensicht und wie können die wesentlichen Eckpunkte greifbar formuliert werden. Erfahrungsgemäß wird schnell klar, dass einem trotz dieser Vogelperspektive noch vieles unklar ist. Dies kann und muss konkret hinterfragt werden.

Manche Eckwerte wie Projektbeginn oder Ressourcen stehen zu diesem Zeitpunkt wahrscheinlich noch nicht exakt fest – hier kann durchaus mit sehr groben Schätzwerten gearbeitet werden, um zumindest Richtwerte fixiert zu haben. Nach Erstellung der Einsatzmittel- und Kostenplanung werden die ersten Schätzwerte im Steckbrief entsprechend ersetzt.

Eine knappe Projektbeschreibung wie im Steckbrief des Beispielprojekts (Tab. 1) zusammen mit einer etwa einseitigen näheren Erläuterung ist auch sehr gut als Handout verwendbar, falls nach den Eckdaten des Projekts gefragt wird.

2.1.2 DOP-Projektsteckbrief

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: DOP-Steckbrief

Es erfolgt zunächst eine Beschreibung des Auftraggebers und der Faktoren, die zu dem Entschluss geführt haben, Umfänge der bestehenden Software Dealer Objectives Planning (DOP) neu aufzusetzen.

Auftraggeber

Die BMW AG ist Hersteller von PKW und Motorrädern im Premium-Segment. Auftraggeber für das Projekt ist die Abteilung VP, zuständig für die IT-Systeme zur Unterstützung der Vertriebsprozesse.

Auftragnehmer:

Auftragnehmer ist die msg systems ag, ein deutsches Software- und Beratungshaus mit über 2000 Mitarbeitern. Das Unternehmen mit Fokus auf Entwicklung von komplexen, individuell gestalteten Anwendungssystemen und Standardsoftware ist langjähriger strategischer Partner der BMW AG.

Motivation

Das Anwendungssystem DOP unterstützt den Prozess zur fortlaufenden Quotenplanung. Es übernimmt außerdem die an die Planung anschließende Steuerung der BMW-Händler über die laufende Quotenbelegung bei Neuwagenbestellungen. In der Automobilindustrie ist es üblich, zwischen dem Automobilhersteller und den einzelnen Händlern konkrete Abnahmevereinbarungen in Form von Quoten zu treffen. Ein Händler kann nur dann ein Fahrzeug bestellen, wenn er eine passende Quote besitzt. Die Gesamtmenge über alle Quoten spiegelt somit die Produktionskapazität des Automobilherstellers wieder – um diese konkurrieren die Händler während des Planungsprozesses.

DOP ist also ein essenzieller Bestandteil des Fahrzeug-Bestellprozesses. Jede Bestellung weltweit wird unmittelbar gegen die Händlerquoten geprüft und im Falle eines erschöpften Quotenkontingents abgelehnt. DOP besitzt aufgrund dieser Tatsache einen sehr hohen Stellenwert für den Auftraggeber in dessen operativem Tagesgeschäft.

Aufgrund eines Anbieterwechsels und der damit verbundenen Abschaltung der Infrastrukturkomponente SAS V8 zum 30.09.2008 wird die technische Basis des Systems weitgehend neu definiert und eine Migration auf die neue Plattform geplant. Den Anbieterwechsel nutzt BMW über eine reine Migration hinaus zur fachlichen und technischen Überarbeitung der betroffenen Kernkomponenten. Die im Rahmen dieses Projektes beauftragte Überarbeitung umfasst den Neuentwurf der bisher unter SAS-V8 laufenden Komponenten „DOP-Auswertungen“ und „DOP-Kalkulation“.

Projektinhalt

Die wesentlichen fachlichen und technischen Leistungsmerkmale des Projektauftrags umfassen:

- Realisierung und Einführung einer angepassten Komponente zur Erstellung von Auswertungen über Quotenzahlen
- unter Berücksichtigung aktueller und geplanter Fahrzeugbestellungen,
- über die Vertriebsstufen Zentrale, Länder, Regionen, Gebiete und Händler,
- für alle BMW Produktarten (Pkw, Motorrad, Mini) und Modelltypen (3er, 5er, usw.),
- auf Basis der technologischen Plattform Bea Weblogic statt SAS-V8.
- Realisierung und Einführung einer überarbeiteten Komponente zur Kalkulation der Quotenvorgaben für Händler bestehend aus:
- Errechnen eines Quotenvorschlags für jeden Händler unter Berücksichtigung der Vorjahresergebnisse (Top-Down-Planung).
- Errechnen der optimalen Quotenverteilung nach Rückmeldung des Quotenbedarfs durch die Händler (Bottom-Up-Planung).
- Bereitstellen von Kalkulationsparametern und Rückstellungsmöglichkeiten (sog. Quotenpools) über die die Kalkulation beeinflusst werden kann.
- Berechnung von Quotenvorschlägen über alle Vertriebsstufen: Zentrale, Länder, Regionen, Gebiete und Händler.
- Einmaliges Ausrollen eines Gesamtrelease im Rahmen eines Zeitfensters, das vom Gesamtprogramm „International Vehicle System Online-Ordering“ vorgegeben wird.

Eigene Rolle

Der Autor ist Projektleiter für dieses Projekt. Dies beinhaltet folgende Verantwortlichkeiten:

- Einhaltung der Projektziele, insbesondere Termine und Qualität. Nach Absprache mit dem Auftraggeber erhält das Projektziel Budgeteinhaltung die niedrigste Priorität, ein begründetes Aufstocken ist möglich. Unbedingt einzuhalten ist der festgelegte Go-Live Termin.
- Laufende Abstimmung mit dem Kunden, Änderungs- /Risikomanagement.
- Projektplanung, -steuerung und –kontrolle.

2.2 Zielbeschreibung und Zielhierarchie

2.2.1 Allgemein

Die Projektzielebilden die Grundlage des Projekts, daher ist es essenziell, ihrer Formulierung große Aufmerksamkeit zu widmen. Hierzu haben sich einige Grundregeln zur Zielformulierungetabliert (Lent & Bogdan, 2003) (Straube, Leuschner, & Müller, 2007, S. 175 ff.) (Kuster, Huber, & Lippmann, 2006, S. 340), nach denen ein Ziel:

- Klar und verständlich formuliert werden muss.
- Tatsächlich erreichbar sein muss.
- Positiv formuliert sein muss („was wollen wir erreichen“ statt „was wollen wir vermeiden“).
- Objektiv messbar sein muss.
- Keine Lösungswege vorwegnehmen darf.
- Terminiert sein muss.

Die Exaktheit der Zielformulierung ist gegebenenfalls vom Kunden einzufordern und nicht immer einfach zu finden. Beispielsweise sind Attribute wie „benutzerfreundlich“, „wartbar“ oder „flexibel“ subjektiv und müssen auf ihre Messbarkeit hin genauer spezifiziert werden. Im Falle der Benutzerfreundlichkeit könnte das möglicherweise durch Festlegen der maximalen Wartezeit nach einem Klick geschehen. Generell ist eine gemeinsame Erarbeitung der Zielformulierungen mit dem Auftraggeber zweckmäßig, da sich so alle Beteiligten mit den Ergebnissen identifizieren können und Ziele gemeinsam priorisiert werden. Geschieht das zu Beginn des Projekts, so können alle Beteiligten von der noch entspannten Atmosphäre profitieren. Dieser Vorteil geht in aller Regel verloren, wenn später im Projektverlauf die Ziele nachgeschärft werden müssen.

Ziele selbst können nach verschiedenen Kriterien kategorisiert werden. Ein verbreiteter und gut handhabbarer Ansatz ist die Untergliederung in Kosten-, Leistungs- und Terminziele(Schelle, Ottmann, & Pfeiffer, 2005, S. 140 f.), wobei bei Kostenzielen das Budget, bei Leistungszielen die zu erbringende Leitung bzw. Qualität und bei Terminzielen die zeitlichen Aspekte adressiert werden.

2.2.2 Ziele im Projekt DOP

Die folgenden weiter unten aufgeführten Leistungsziele (Tab. 2), Terminziele (Tab. 3) und monetären Ziele (Tab. 4) werden gemeinsam zwischen BMW und dem Auftragnehmer zu Projektbeginn festgelegt und bezogen auf ihre Priorität bewertet. Für diese Bewertung wurden gemeinsam Prioritätsstufen definiert. Auch wurde auf die Messbarkeit der einzelnen Ziele geachtet.

1. hoch: Das Ziel ist vollständig zu erfüllen, da bei Nicht-Erreichung das Gesamtprojektziel gefährdet ist. Bei Abweichungen werden sofort Maßnahmen eingeleitet.
2. mittel: Das Ziel ist in Hinblick auf die Umsetzung der Geschäftsprozesse, die für einen erfolgreichen Produktivgang erforderlich sind, in vollem Umfang umzusetzen. Abweichungen in Bereichen, die das operative Geschäft nicht wesentlich beeinflussen, können akzeptiert werden. Maßnahmen sind einzuleiten, um vor dem Ende des Projekts den vollen Zielumfang umzusetzen.
3. niedrig: Ziele mit dieser Einstufung gefährden bei Nicht-Erreichung nicht das Projektgesamtziel. Das Ziel ist im Rahmen des Projekts umzusetzen, Umfang und Termin können aber nach Absprache angepasst werden.

Mit dem Kunden wird vereinbart, dass bei Zielkonflikten bzw. Gefährdung einzelner Zielerreichungen an erster Stelle die Priorität entscheidet, welches Ziel vorrangig zu erreichen ist. Bei gleicher Priorität sind vorrangig Terminziele, dann die Leistungsziele und an dritter Stelle die Kostenziele zu erreichen. Bei Zielkonflikten oder Gefährdungen der Zielerreichung ist umgehend der Auftraggeber zu informieren.

Terminziele

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2: Terminziele in DOP

Leistungsziele

Zur Einordnung von Softwarefehlern und Sicherheitsreview-Ergebnissen wurde während der Startphase zwischen Kunde und Auftragnehmer folgende Kategorisierung festgelegt:

„Kritisch“ Der Fehler / das Ergebnis verhindert die Durchführung essenzieller Geschäftsprozesse. Die Software ist nicht einsetzbar.

„Hoch“ Der Fehler / das Ergebnis behindert die Arbeit massiv und gefährdet den Softwareeinsatz.

„Mittel“ Der Fehler / das Ergebnis behindert die Arbeit in gewissem Maße.

„Niedrig“ Der Fehler / das Ergebnis betrifft nicht die Funktionalität oder kann bis zur Behebung umgangen werden.

Mithilfe der Kategorisierung können im Folgenden Messbarkeitskriterien für die Leistungsziele formuliert werden.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 3: Leistungsziele in DOP

Abbildung in dieser Leseprobe nicht enthalten

Tab. 4: Kostenziele in DOP

Zielhierarchie

Die unten dargestellte Abbildung (Abb. 1) veranschaulicht die Ziele in grafischer Form als Baumstruktur und wird als Ausdruck auf die DOP-Projektpinnwand geheftet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: DOP-Zielhierarchie

2.3 Zielbeziehungen und Zielkonflikte

2.3.1 Allgemein

Zeit, Kosten und die Qualität der Ergebnisse stehen zueinander in Beziehung und beeinflussen sich gegenseitig (Kuster, Huber, & Lippmann, 2006, S. 105). Dieses in der Literatur als „magisches Dreieck“ bezeichnetes Phänomen (Abb. 2) lässt sich auch auf die im vorangegangenen Kapitel definierten Ziele anwenden. Der Faktor Zeit, ausgedrückt durch einen knappen Termin hat beispielsweise negative Auswirkungen auf die Qualität der Leistung da unter Termindruck nicht alle Qualitätsmaßnahmen in der erforderlichen Sorgfalt eingesetzt werden können. Selbiges gilt für die Beziehung zwischen Kosten und Qualität. Beispielsweise erfordert Qualität anfangs eine Investition (in Qualitätssicherungsmaßnahmen), die sich oft erst im späteren Verlauf während der Wartung und Weiterentwicklung spürbar bezahlt machen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: magisches Dreieck Leistung-Zeit-Kosten

Konträre Beziehungen zwischen Zielen beschränken sich allerdings nicht nur auf die drei Kategorien Zeit, Kosten und Leistung, sondern können auch innerhalb der jeweiligen Kategorie auftreten. Beispielsweise steht ein Leistungsziel „Komplexe Auswertung XY wird umgesetzt“ in klarem Konflikt zu „Keine Aktion darf länger als drei Sekunden dauern“. Wichtig zu Projektbeginn ist es, die konträren Zielbeziehungen zu erkennen und sich über Gegenmaßnahmen und den angestrebten Grad der Zielerreichung Gedanken zu machen. Es macht keinen Sinn, jedes Leistungsziel prinzipiell konträr zu Termin-/Kostenzielen zu sehen, auch wenn sie sich genau genommen stets negativ beeinflussen. Vielmehr ist eine Konzentration auf die Beziehungen gefordert, die erheblich zueinander in Konflikt stehen oder sich unter Umständen sogar gegenseitig ausschließen.

2.3.2 Zielbeziehungen und Zielkonflikte in DOP

In DOP werden in einer Matrixdarstellung die Beziehungen zwischen den Zielen geprüft und bewertet. Folgende Tabelle (Tab. 5) zeigt exemplarisch einige Zielbeziehungen/-konflikte aus Sicht der Terminziele. Identifiziert wurde, dass die Ziele zur Abnahme der beiden Module Kalkulation und Auswertungen konträr zu den engen Terminzielen zu sehen sind, da die Abnahmeprozeduren zum einen langwierig sind, zum anderen durch eine hohe Anzahl eventuell gefundener Fehler zu Verzögerungen führen können. Auch wird die Erreichung der Kennzahlen zur Softwarequalität konträr zu den Terminen gesehen, da aufgrund des Zeitdrucks die definierten Qualitätsziele nur schwer erreichbar sind.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 5: Zielkonflikt in DOP

Der Zielkonflikt in DOP zwischen Softwarequalität und dem Termin zum Integrationstest wird im Folgenden detailliert betrachtet. Zur „Konfliktlösung“ wird der Kunde mit ins Boot genommen, indem vorab geklärt und schriftlich fixiert wird, wie im Konfliktfall umgegangen wird. Dies entschärft im Ernstfall die Kommunikation (Tab. 6).

Abbildung in dieser Leseprobe nicht enthalten

Tab. 6: Beispiel für einen Zielkonflikt in DOP

3 Projektumfeld- und Stakeholderanalyse

Nachdem das Projekt selbst und dessen Ziele nun verstanden sind, ist es an der Zeit, das Projektumfeld des Projektes genauer in Augenschein zu nehmen. Das folgende Kapitel beleuchtet das Umfeld und geht dabei insbesondere auf die Stakeholder ein.

3.1 Projektumfeld

3.1.1 Allgemein

In der DIN 69904 wird das Projektumfelddefiniert als das „Umfeld, indem ein Projekt entsteht und durchgeführt wird, das das Projekt beeinflusst und von dem es beeinflusst wird.“ (Deutsche Gesellschaft für Projektmanagement, 2000). Hierzu gehören demnach nicht nur die unmittelbar betroffenen Personen (-gruppen), sondern auch Vorgaben, Strategien, ökologische, ökonomische, gesellschaftliche und kulturelle Einflüsse – also schlichtweg alle Elemente, die das Projekt spürbar beeinflussen. Um keine wesentlichen Elemente zu übersehen, ist es sinnvoll, diese mit Hilfe von Kreativmethoden im Projektteam zu ermitteln. Die Technik des Brainstormings kann hier gute Dienste leisten.

Externe Einflussfaktorenwie etwa die Gesetzgebung von Ländern oder kulturelle Besonderheiten können üblicherweise nicht beeinflusst werden, haben unter Umständen aber große Auswirkung auf das Projekt und müssen deshalb auch auf der Liste erscheinen. Auf interne Einflussfaktorenkann man in gewissem Rahmen einwirken. Sie gehören zum unmittelbaren Umfeld des Auftraggebers oder Auftragnehmers.

3.1.2 DOP-Projektumfeld

Für das Projekt DOP wurden die Einflüsse des Umfelds in Form einer Mindmapim Projektteam erarbeitet (Abb. 3). Die Mindmap zeigt neben den Stakeholdern auch technische, organisatorische, strategische, gesellschaftliche und rechtlich-politische Einflussfaktoren.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: DOP-Projektumfeld

Die identifizierten Einflussfaktoren gilt es nun, aus Sicht des Projektes zu bewerten. Die Bewertung ist natürlich subjektiv und wird sich im Laufe der Zeit ändern. Es handelt sich um eine erste Momentaufnahme, die regelmäßig zu aktualisieren ist. Eine Überprüfung im Monatstakt ist für DOP ein geeigneter Rhythmus. Aus Übersichtsgründen werden hier nur auszugsweise einige der Einflussfaktoren genannt (Tab. 7, Tab. 8).

Projektumfeld – interne Einflussfaktoren

Abbildung in dieser Leseprobe nicht enthalten

Tab. 7: interne Einflussfaktoren des Projektumfelds in DOP

Projektumfeld – externe Einflussfaktoren

Abbildung in dieser Leseprobe nicht enthalten

Tab. 8: externe Einflussfaktoren des Projektumfelds in DOP

3.2 Stakeholder

3.2.1 Allgemein

Stakeholdersind Personen oder Personengruppen aus dem Projektumfeld, die das Projekt auf verschiedene Art und Weise und mit unterschiedlicher Intensität beeinflussen, sowohl in positiver als auch in negativer Hinsicht. Um selbst einen Überblick zu bekommen, ist es sinnvoll, die im internen Projektumfeld identifizierten Stakeholder bezüglich ihrer Beziehung zum Projekt (positiv, negativ, neutral) und ihrer Macht zu bewerten – also eine Stakeholderanalyse durchzuführen. Fatal kann es sein, wenn ein wesentlicher Stakeholder nicht als solcher erkannt wird. Diese Person kann sich bei Nichtbeachtung übergangen oder herabgesetzt fühlen und aus verletztem Stolz verdeckt gegen das Projekt arbeiten (Straube, Leuschner, & Müller, 2007).

3.2.2 Stakeholder im Projekt DOP

Zunächst werden mittels einer Stakeholderanalyse während der Projektstartphase von DOP die Stakeholder identifiziert und bezüglich ihres Einflusses bewertet (Tab. 9). Darauf aufbauend wird ein Stakeholderportfolioerstellt (siehe Kapitel 3.3). Mit der abschließenden Definition von Maßnahmen werden einerseits die Risiken aufgrund negativ eingestellter Stakeholder adressiert, andererseits auch die Chancen, die sich durch positiv eingestellte Stakeholder ergeben, gezielt gefördert. Die Stakeholderanalyse wird künftig zyklisch wiederholt, da auch sie genau wie das Projektumfeld lediglich eine Momentaufnahme darstellt.

Für DOP wurden die Stakeholder während der Betrachtung des Projektumfelds identifiziert (siehe Kapitel 3.1.2). Sie werden nun hinsichtlich ihrer Interessen betrachtet und bewertet. Dabei wird die aktuell wahrgenommene Grundstimmung der Stakeholder zum Projekt (positiv, negativ oder neutral) festgehalten und die Stärke des Einflusses, den die Stakeholder auf das Projekt ausüben können, bewertet.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 9: Stakeholder, Erwartungen und Stimmung

3.3 Stakeholderportfolio

3.3.1 Allgemein

Die Ergebnisse der Stakeholderanalyse können übersichtlich in einer Portfoliodarstellung veranschaulicht werden. Hierzu werden passend zu den Achsen „Konfliktpotenzial“ und „Einfluss“ die zu der Stakeholderbewertung passenden Punkte im Portfolio eingetragen. Die Einordnung der Stakeholder in das Portfolio ist kein mathematisch exakter Vorgang sondern eine subjektive Abbildung, welches das Verständnis der an der Erstellung des Portfolios Beteiligten widerspiegelt. Mit einer Unterteilung des Portfolios in vier Quadranten kann man unmittelbar diejenigen Stakeholder erkennen, die laut Analyse ein hohes Konfliktpotenzial kombiniert mit hohem Einfluss auf das Projekt besitzen (Abb. 4). Diese Stakeholder müssen ständig im Blickfeld des Projektleiters sein.

Für diejenigen Stakeholder, für die laut Analyse Aktivitäten erforderlich sind, müssen nun gezielte Maßnahmen formuliert werden. Wie geht man als Projektleiter mit ihnen um? Wie kommuniziert man mit ihnen? Wie kann man das Konfliktpotenzial senken? Natürlich darf man dabei die übrigen Stakeholder nicht vollständig vernachlässigen. Es geht lediglich um das Setzen richtiger Schwerpunkte und darum, sich als Projektleiter nicht nur auf die Personen zu konzentrieren, zu denen man „einen guten Draht“ hat.

Stakeholder haben nicht nur zum Projekt eine Beziehung, sondern auch und insbesondere untereinander. Existieren Konflikte oder gegensätzliche Ansichten zwischen Stakeholdern, ist es nützlich, diese zu kennen und als Projektleiter angemessen zu berücksichtigen. Andernfalls könnten diese Konflikte unerwartet auch negativen Einfluss auf das eigene Projekt haben.

3.3.2 DOP-Stakeholderportfolio

Die vorher ermittelten Informationen der DOP-Stakeholderanalyse (siehe Kapitel 3.2.2) werden grafisch in einem Portfolio (Abb. 4) visualisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: DOP-Stakeholderportfolio

Für die Stakeholder, die im Portfolio rechts oben im ersten Quadranten zu finden sind, ist aus DOP-Sicht dringend Handlungsbedarf erforderlich. Dies sind SH6 und SH1. Zusätzlich werden Maßnahmen für ausgewählte Stakeholder in den Quadranten zwei und drei in Betracht gezogen, um auch deren Einfluss in eine für das Projekt günstige Richtung zu lenken. Folgende Maßnahmen wurden in DOP formuliert (Tab. 10):

Abbildung in dieser Leseprobe nicht enthalten

Tab. 10: Maßnahmen zur Stakeholderkommunikation

Auch die Beziehungen zwischen Stakeholdern können für DOP eine Rolle spielen. Eine Betrachtung möglicher Konflikte ergibt folgende Bewertung (Tab. 11).

Abbildung in dieser Leseprobe nicht enthalten

Tab. 11: Beziehungen zwischen DOP-Stakeholder

Mithilfe der oben genannten Maßnahmen wird folgendes Ziel-Stakeholderportfolio angestrebt (Abb. 5). Die Position der hellblau markierten Stakeholder wurde gegenüber dem Ausgangs-Portfolio verändert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: angestrebtes Stakeholderportfolio

4 Risikoanalyse

Ein Risikodrückt eine Unsicherheit in Bezug auf einen künftigen Sachverhalt oder Ereignis aus (Schelle, Ottmann, & Pfeiffer, 2005, S. 149). Im Kontext eines Projektes ist damit die Möglichkeit gemeint, dass ein Ereignis eintritt, welches sich (üblicherweise negativ) auf die Ziele des Projekts auswirkt. Aktives Risikomanagementunterstützt den Projektleiter dabei, Risiken besser einzuschätzen, Entscheidungen fundierter zu treffen und diese Entscheidungen nicht zuletzt auch nachvollziehbar zu rechtfertigen. Insgesamt sollen Risiken und negative Überraschungen während des Projektverlaufs minimiert und somit der Gesamterfolg des Projekts verbessert werden.

4.1 Risiken erfassen und klassifizieren

4.1.1 Allgemein

Die systematische Identifikation von Risiken ist der erste Schritt hin zu einem gezielten Risikomanagement. Als Ausgangspunkt für eine erste Systematisierung bietet es sich an, auf Fragebogentechniken zurückzugreifen. Viele Unternehmen gerade im Bereich Softwareentwicklung haben selbst solche Fragebögen entwickelt, die bereits während der Angebotsphase eines Projektes abzuarbeiten sind. Die Fragen dienen dabei als Denkstütze, um sicherzustellen, dass über alle wesentlichen Bereiche nachgedacht wurde. Da Projekte im Unterschied zu Routinetätigkeiten einmalig sind, gibt es häufig auch projektindividuelle Risiken. Brainstorming, eine Nachbetrachtung ähnlicher Projekte oder die Analyse möglicher zukünftiger Szenarien sind geeignete Werkzeuge um diese projektindividuellen Risiken aufzudecken.

4.1.2 Risiken in DOP

In einem ersten Schritt werden zu Projektbeginn die Risiken mittels einer Fragenliste für IT-Projekte erfasst. Diese - verbindlich zu nutzende - Liste ist Teil des PROFI-Vorgehensmodells innerhalb der msg systems AG und steht als Excel-Datei im firmeneigenen Intranet zur Verfügung.

Folgende Kategorien werden im Rahmen der Risikoanalyse abgefragt:

- Anforderungen
- Mitarbeiter
- Projektleitung
- Technologie
- Kunde
- Risikomanagement

Alle Fragen der Liste sind so formuliert, dass eine Beantwortung mit „Nein“ auf ein Risiko hindeutet. In den Bereichen, in denen zusätzlich DOP-spezifische Risiken erkannt werden, wird der Fragenkatalog entsprechend erweitert und anschließend im DOP-Dokumentenmanage-mentsystem abgelegt. Die in nachfolgender Tabelle (Tab. 12) dargestellte Auflistung ist ein Ausschnitt mit den Fragen aus dem Bereich „Anforderungen“. Die vollständige Liste ist als Anlage beigelegt (siehe Anhang 1, S. 85).

Abbildung in dieser Leseprobe nicht enthalten

Tab. 12: DOP-Risikoliste (Ausschnitt)

4.2 Risiken bewerten

4.2.1 Allgemein

Tritt ein Risiko ein, so entsteht ein Schadensfall, dessen Kosten vorab abgeschätzt werden können. Ebenso kann die Wahrscheinlichkeit abgeschätzt werden, mit der dieser Schadensfall eintritt. Multipliziert man die Kosten mit der Wahrscheinlichkeit, so erhält man den Risikowert. Der Risikowertist die Größe mit dessen Hilfe die optimale Risikovorsorge gestaltet werden kann. Je höher der Risikowert umso wichtiger ist es, das dahinter liegende Risiko im Auge zu behalten (Junginger, 2005, S. 256).

4.2.2 Risikobewertung in DOP

Die im Folgenden dargestellte Risikobewertungin DOP (Tab. 13) bezieht sich beispielhaft auf zehn Risiken, den beiden oben ermittelten (siehe Kapitel 4.1.2) sowie den verbleibenden Risiken aus Anhang 1 (siehe Anhang 1, S. 85).

Die subjektive Bewertung der Schadenshöhe und der Eintrittswahrscheinlichkeit nimmt in DOP der Projektleiter vor, wobei er sich bei einigen Fragestellungen – vor allem aus dem Bereich „Technologie“ Expertenmeinungen des Projektteams einholt.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 13: Bewertete Risiken in DOP

[...]