erni essentials PROJECT MANAGEMENT - erni-consultants.com

Project ManageMent 1
ernI eSSentIaLS
PROJECT MANAGEMENT

enables & delivers
oLIVIer gut
olivier.gut@erni.ch
Senior consultant und
Projektsteurer bei
Swiss engineering Institute
EiNfühRuNG
Ein Projekt charakterisiert sich durch ein
definiertes Ziel, gegebene Rahmenbedingungen
(Termine, Budget, Ressourcen) und
seine Einmaligkeit. Der Projekterfolg liegt
im Bündeln und Umsetzen der relevanten
Stakeholderbedürfnisse.
Ein entscheidender Erfolgsfaktor ist die
Projektführung. Vieles hängt von der
Arbeitsweise, der Voraussicht und der
Erfahrung des Projektleiters ab. Genauso
wichtig sind seine Kommunikationsfähigkeit
sowie die Sozialkompetenz, ein Team
zu führen und zu motivieren. Durch ein
standardisiertes und methodisches Vorgehen
kann den Gefahren und Risiken, die
jedes Projekt mit sich bringt, wirkungsvoll
begegnet werden.
Das ERNI Essential Project management
dokumentiert grundlegende Werkzeuge,
die einen Projektleiter in seiner täglichen
Arbeit unterstützen und zu einem erfolgreichen
Projektabschluss führen.
ernI – Innovation in Process and technology
Project ManageMent 3
EiNfühRuNG 2
1. EiNlEiTuNG 5
2. PROJEkT-STARTuP 11
2.1 Das Projekthandbuch:
die checkliste für den Projektleiter 11
2.2 Vorgehen 13
3. ZiElvEREiNbARuNG 19
3.1 Vorgehen 22
4. PlANuNG 25
4.1 Projektplan 25
4.2 Vorgehen 26
5. PROJEkTSTEuERuNG 31
5.1 navigationsinstrumente 31
5.2 aufwand, termine und ressourcen 32
5.3 Projektstatus 33
5.4 teamworking 34
6. AufwANdSChäTZuNG 39
6.1 Schätzmethodik 39
6.2 Vorgehen 41
7. RiSikOMANAGEMENT 47
7.1 Vorgehen 47
7.2 risikoklassifizierung 49
7.3 risikobehandlung 50
8. ChANGE REquEST MANAGEMENT 53
8.1 Vorgehen 53
9. kOMMuNikATiONSfORuM 57
10. GlOSSAR 61

1. EiNlEiTuNG
Project ManageMent 5
Die Auseinandersetzung mit dem Thema Projekt ist immer auch
eine Auseinandersetzung mit der Aufgabe des Projektleiters (PL).
Der Erfolg des Projekts hängt weitgehend von der Fähigkeit des
Projektleiters ab, zwangsläufig auftauchende Probleme zu erkennen
und angemessen darauf zu reagieren. Der Projektleiter muss
sich, wie in Abbildung 1, als Drehscheibe und Kommunikationsknoten
im Projekt sehen. Sein Erfolg hängt davon ab, ob er seine
Rolle richtig versteht.
Abb. 1: Der ProjektLeIter aLS koMMunIkatIonSDrehScheIbe
Zulassungsstelle
It
controller
benutzer
geschäftsleitung
Project
Manager
tester
auftraggeber
externe
Lieferanten
Projektmitarbeitende

Die Tätigkeiten des Projektleiters lassen sich weiter, wie in Abbildung
2 zu sehen, in vier Hauptkategorien aufteilen. Er ist dann
am erfolgreichsten, wenn es ihm gelingt, die richtigen Informationen
zu erhalten und die Resultate geeignet weiterzugeben.
Abb. 2: hauPttätIgkeIten DeS ProjektLeIterS
analysieren
Strukturieren
Probleme
lösen
kommunizieren
Priorisieren
Planen
Überwachen
Analysieren und Strukturieren bilden den Anfang eines jeden
Schrittes. Die erste Aufgabe des Projektleiters besteht darin,
Schwierigkeiten früh zu erkennen.
Planen ist mehr, als nur ein Gantt-Chart (Balkendiagramm) zu
zeichnen. Es geht um das Antizipieren der Zukunft. Dazu verfei-
Project ManageMent 7
nert man die Ziele des Projekts und verteilt sie auf verschiedene
Schlüsselmomente (Meilensteine) auf der Zeitachse des Projekts.
Anschliessend wird definiert, welche Schritte unternommen
werden müssen, um diese Einzelziele zu erreichen. Daraus lassen
sich die anstehenden Massnahmen ableiten. Als Nächstes
nimmt man die Risikoanalyse vor, um weitere Massnahmen zu
identifizieren. Daraus entsteht eine vollständige Planung, die
auch die Randbedingungen und die Schnittstellen zu anderen
Organisationen berücksichtigt.
Die Planung muss allen Beteiligten kommuniziert werden. Es
lohnt sich auch, zu prüfen, ob sie von allen gleich interpretiert
wird.
Der Projektfortschritt sollte periodisch mit der Planung verglichen
werden (siehe Kasten zur Situationsanalyse). Dabei darf diese
Aufgabe nicht zur Protokollierung von Terminverschiebungen
verkommen. Anpassungen an der Planung sollten immer an begleitende
Massnahmen geknüpft sein. Inwieweit Tätigkeiten
und Massnahmen erfüllt sind, sollte man auch inhaltlich prüfen.
Statusmeldungen sind zu hinterfragen. Auf diese Weise wird
die Fortschrittskontrolle zu einem Führungsinstrument des Projektleiters.
Trotz aller Planung und Voraussicht tauchen Probleme auf, die
rasches Handeln verlangen. Abwarten ist meistens keine gute
Alternative. Durch Kommunikation mit allen Beteiligten lässt
sich dagegen oft eine Lösung finden (siehe Kasten Problemlösungsstrategie).

Fragen Zur SItuatIonSanaLySe
• Welche Informationen über den Status des Projekts stehen
zur Verfügung?
• Was haben wir bisher erreicht?
• Was sollten wir gemäss Plan bis heute erreicht haben?
• Was sind die Gründe für festgestellte Planabweichungen?
• Welches sind momentan die grössten Risiken?
ProbLeMLöSungSStrategIe
• Ursachen des Problems analysieren.
• Einfache Massnahmen im eigenen Verantwortungsbereich
sofort umsetzen.
• Ursachen bei projektexternen Stellen mit den Verantwortlichen
besprechen.
• Längerfristige Massnahmen planen.
• Alternativen planen, falls die Massnahmen das Problem
nicht lösen (Contingency Planning).
• Risikoanalyse anpassen unter Berücksichtigung des
bestehenden Problems.
Project ManageMent 9

2. PROJEkT-STARTuP
2.1 dAS PROJEkThANdbuCh:
Project ManageMent 11
diE ChECkliSTE füR dEN PROJEkTlEiTER
Abb. 3: beLaStung DeS ProjektLeIterS
belastung
Startphase
Zeitachse
Projektverlauf endphase
Die grössten Belastungen des Projektleiters finden, wie Abbil-
dung 3 zeigt, jeweils am Anfang und am Ende des Projekts statt
oder bei grösseren Projekten jeweils bei Phasenstart und bei Phasenende.
Mit der Belastung steigt das Fehlerrisiko. So gesehen ist
die Situation vergleichbar mit derjenigen eines Linienpiloten.
Dieser verwendet bei Start und Landung Checklisten, die er abarbeitet.

Das ERNI Projekthandbuch (PHB) ist eine solche Checkliste. Damit
werden alle wichtigen Entscheide der Startphase angesprochen.
Der Projektleiter bearbeitet die Fragestellungen und fällt
die notwendigen Entscheide. Die Resultate werden im PHB festgehalten.
So entsteht ein Regelwerk für das Projektteam und andere
Beteiligte, das alle Vorgaben im Projekt dokumentiert. Das
PHB ist ein Dokument-Template, das Textvorgaben und Beispiellösungen
zur Verfügung stellt. Damit wird der Projektleiter geführt
und durch Kommentare angeleitet.
WIchtIGE EntSchEIDE DER StARtPhASE
• Projektvision, Ziele, Anforderungen
• Risiken und Massnahmen
• Abgrenzungen, Projektrahmen
• Lösungsstrategie
• Erwartete Ergebnisse und Meilensteine
• Projektorganisation
• Kommunikationswege
• Aufgaben und Verantwortlichkeiten
• Planung
• change Management
FÜhrungSInStruMent FÜr Den auFtraggeber
Der Auftraggeber erhält mit dem PHB eine standardisierte Doku-
mentation des Projekts, mit der er die Entscheide des Projektlei-
Project ManageMent 13
ters nachvollziehen kann. Indem er dieses Werkzeug in allen
Projekten ähnlich einsetzt, legt er den Grundstein für eine Konsolidierung
des Projektstatus in seinem Portfolio.
2.2 vORGEhEN
Wie bei einer Checkliste üblich, fängt man am Anfang des Dokuments
an und arbeitet sich Frage um Frage durch.
StrategISche ÜberLegungen
In EInER ERStEn PhASE ISt ES WIchtIG, SIch StRAtEGISchE
ÜberLegungen ZuM Projekt Zu Machen. Man kLärt FoLgenDe
theMen ab:
• Projektziele. Die Absicht des Auftraggebers ist massgebend.
• Projektrisiken. Der Projektleiter identifiziert und beurteilt die
wichtigsten risiken.
• Lösungsansatz. Im team und in Absprache mit dem Auftraggeber
wird die Vorgehensweise mit dem grössten erfolgspotenzial,
welche die randbedingungen einhält, definiert.
• Projektphasenplan und Meilensteine.
• Projektresultate. Abgeleitet von den Projektzielen und dem
Vorgehen werden die Projektresultate genau aufgelistet.

kIckoFF-MeetIng
Das Kickoff-Meeting ist das ideale Gefäss, um den Auftraggeber
und das Team mit den Fragestellungen aus dem PHB zu konfrontieren.
Die wichtigsten Abmachungen werden dort getroffen.
Das Inhaltsverzeichnis des PHB gibt dem Projektleiter die Traktandenliste
für das Kickoff.
DetaILS abkLären
Das PHB enthält an den wichtigen Orten Kommentare und Beispiele,
um das Verständnis zu fördern. Beim PHB geht es nicht in
erster Linie darum, ein Dokument zu schreiben, sondern sich
mit organisatorischen Entscheiden auseinanderzusetzen. Man
sollte offene Punkte notieren und sich überlegen, wie man zu
entsprechenden Antworten kommt. Meistens werden diese
durch Gespräche mit den Beteiligten gefunden und nicht ausschliesslich
durch intensives Denken. Folgendes darf nicht vergessen
werden: Definierte Regelungen und getroffene Entscheidungen
nützen nur etwas, wenn man sie kommuniziert. Das
heisst konkret: raus aus dem Büro und mit Stakeholdern, Lieferanten,
Projektmitarbeitenden und Know-how-Trägern reden!
Wichtig zu diesem Zeitpunkt ist auch, dass die erhaltenen Antworten
hinterfragt werden, damit eine fundierte, stabile Projektdefinition
entsteht. Anpassungen zum Zeitpunkt des Projektstarts
sind ohne grosse Mehrkosten umsetzbar. Je weiter das
Projekt dann fortschreitet, desto schwieriger werden Änderungen
an den grundlegenden Zielsetzungen.
Project ManageMent 15
Abb. 4: VeränDerbarkeIt Der ergebnISSe IM ProjektabLauF
Projektumfang
ausgangs-
punkt (100%)
ausbrechen
erarbeitete resultate
aufgelaufene kosten
Sichtbarkeit ergebnisse
Projektstart Phase 1 Phase 2 Phase 3 Projektende
VeränDerbarkeIt Der ergebnISSe IM ProjektabLauF
beeinflussbarkeit
Bei den Entscheidungen sollte man sich immer überlegen, ob
eine einfachere Regelung möglich ist und ob die Betroffenen diese
Regel als Unterstützung oder als Behinderung empfinden. Die
Kunst besteht darin, nicht alles regeln zu müssen, sondern nur
das Wichtigste.
REVIEW UnD ABnAhME
Wenn die erste Version des PHB geschrieben ist, empfiehlt sich
ein Review durch den Qualitätsmanager (QM) des Projekts. Danach
sollte die abschliessende Abnahme durch den Auftraggeber,
der ja auch schon mitgearbeitet hat, eingeholt werden. Im

Projektverlauf ist das PHB periodisch zu überarbeiten und an den
Projektfortschritt anzupassen. Dies wird am besten mit dem QM
koordiniert, der als «Gewissen» des Projekts agiert. Das PHB
dient nun allen neu am Projekt Interessierten als Einstieg, um
das Projekt kennen zu lernen. Das wird durch Verweise im PHB
auf andere Dokumente wie Detailplanung oder Risikobewertung
etc. unterstützt.
Zum Abschluss wird das PHB im Post-Project Review hinterfragt,
und die getroffenen Regelungen werden auf ihre Tauglichkeit
geprüft. Somit erhält man neue Ideen für das PHB im nächsten
Projekt.
Project ManageMent 17

3. ZiElvEREiNbARuNG
ZIeLForMuLIerung
Project ManageMent 19
Was versteht man im Rahmen eines Projekts unter einem Ziel?
DaS ZIeL beSchreIbt eInen ...
... gedanklich vorweggenommenen, zukünftigen Zustand,
• der bewusst ausgewählt und gewünscht
• und durch aktives handeln erreicht wird.
Ziele sollten nicht die Probleme auf dem Weg zum Ziel auflisten,
sondern den anzustrebenden Endzustand, den Idealzustand in
«weiter» Zukunft. Gute Zielformulierungen können sich alle
Projektbeteiligten leicht merken.
ZIeLharMonISIerung
Oft wird die Zielvereinbarung vernachlässigt, weil man denkt,
dass die Ziele jedem klar seien. Erfahrungsgemäss ist das ein grosser
Irrtum. Die Vorstellungen der Stakeholder über die Projektziele
divergieren oft. Deshalb ist es wichtig, die Ziele in der Anfangsphase
eines Projekts zu harmonisieren. Am besten erreicht
man dies, indem man die Stakeholder einzeln nach ihren Erwartungen,
Visionen und Zielen befragt. Alle Ergebnisse sollte man
schriftlich festhalten und bestätigen lassen.

ZIELVEREInBARUnGS-WoRKShoP
Die Durchführung eines halbtägigen Zielvereinbarungs-Workshops
ist ein bewährtes Vorgehen, um die Differenzen und den
Konsens klar zum Vorschein zu bringen. Die entscheidende Aufgabe
beim Aufsetzen eines solchen Workshops besteht darin, die
wichtigsten und hochrangigsten Entscheidungsträger an den
Tisch zu bekommen. Man soll sich auch nicht wundern, wenn
man unter Umständen während dieses halben Tages nicht mehr
zustande bringt als einen einzigen Satz, der die Zielsetzung auf
einer einzigen Folie schriftlich fixiert.
ZIeLhIerarchIe
Wie in Abbildung 5 dargestellt, müssen Ziele auf verschiedenen
Abstraktionsniveaus und in unterschiedlichen Detaillierungsgraden
definiert werden.
Abb. 5: ZIeLhIerarchIe
Zielvereinbarung:
ein Satz auf einer Folie
Produktbeschreibung:
eine Liste von Merkmalen
Spezifikation: detaillierte
beschreibung der einzelheiten
des Verhaltens
vision
feature
Requirements
Auftraggeber: business
needs, geschäftsidee
Stakeholder: kundenwünsche,Produktmerkmale
Entwickler: Requirements
Specifications (Use Case,
Suppl. Specification)
InhaLte Der ZIeLhIerarchIe
Project ManageMent 21
• Mit wenigen Zielen auf den höheren Ebenen kann die riesige
Menge von Detailanforderungen gebündelt werden.
• 1 Vision, 10 Features, 100 Requirements.
• Ändert sich im Lauf des Projekts etwas an der Vision oder den
Features, sind die auswirkungen auf die anforderungen demonstrierbar.
• Kommen im Lauf des Projekts plötzlich neue Anforderungen
(«feature creeps»), gibt es ein Mittel, sie zu sieben. jede
anforderung muss den übergeordneten Zielen genügen.
jedes übergeordnete Ziel muss durch konkrete anforderungen
abgedeckt sein.
checkLISte FÜr ZIeLVereInbarungen
• schriftlich fixiert
• klar und nachvollziehbar
• messbar
• vollständig
• widerspruchsfrei
• realisierbar
• allen beteiligten bekannt
• akzeptiert

3.1 vORGEhEN
1. Akteure auf den verschiedenen Niveaus der Zielhierarchie
(Auftraggeber, Stakeholder, Entwickler) identifizieren.
2. Ziele der Akteure einzeln erfragen (Interview/Meeting).
3. Ziele harmonisieren, Win-win-Situation schaffen, meistens
in Workshops.
4. Ziele klar, einfach und verbindlich formulieren und so do-
kumentieren, dass sie von allen Projektbeteiligten verstanden
werden.
5. Ziele in geeigneter Form (Plakat, Projektweb, Statusmeeting)
nach aussen und innen kommunizieren. Gut gewählte Ziele
stellen Erfolgsfaktoren für das Projekt dar. Eine der wichtigsten
Aufgaben des Projektleiters ist es, alle Beteiligten auf
das gemeinsame Ziel auszurichten.
6. Wie leicht verliert man das eigentliche Ziel aus den Augen!
Deshalb ist es zwingend, dass man an jedem Statusmeeting
den Status mit den Zielsetzungen vergleicht und die Prioritäten
für die Massnahmen nach ihnen ausrichtet.
Project ManageMent 23

4. PlANuNG
4.1 PROJEkTPlAN
MoDeLLIeren Der ZukunFt
Project ManageMent 25
Was ist «planen»? Planen heisst, ein Modell der Zukunft zu er-
stellen. Das Modell beschreibt die zeitliche Entwicklung gewisser
modellierter Parameter. Zum Beispiel ist ein Projektplan die Modellierung
der Tätigkeiten in Bezug auf ihren Start und ihr Ende
sowie auf die Abhängigkeiten untereinander.
Dazu kommen noch Parameter wie eingesetzte Ressourcen, Meilensteine
und die Gruppierung von Tätigkeiten.
koMMunIkatIonSMItteL
Der Projektplan ist ein hervorragendes Kommunikationsmittel.
Aus ihm ersehen alle Projektmitarbeitenden den Zeitpunkt und
die vorgesehene Dauer ihrer Tätigkeiten. Zudem sehen sie, mit
wem sie sich koordinieren müssen. Deshalb sollte der Projektplan
breit verteilt und diskutiert werden.
baSIS FÜr anPaSSungen
Während der Planung machen sich der Projektleiter und
sein Team Gedanken über unbekannte Gefahren und Risiken.
Treten während des Projekts grosse unerwartete Schwierigkeiten
auf, so hilft der Plan beim Abschätzen von Konsequenzen.
Man kann Abhängigkeiten zwischen Aktivitäten
und ihre Konsequenzen auf Zeit und Kosten aufzeigen. Man

kann Szenarien darstellen und einen Entscheid für die weitere
Arbeit treffen. Der Projektplan verändert sich im Projektverlauf.
4.2 vORGEhEN
StrukturIeren
Wer ein grosses Vorhaben anpacken will, muss es in Teilpakete
herunterbrechen. Diese können einzeln geplant, organisiert
und bewältigt werden. Es hat sich bewährt, zuerst eine
grobe Planung zu erstellen, in der das Vorhaben in zeitlich
aufeinanderfolgende Phasen gegliedert wird. In einem zweiten
Schritt macht man sich ans Planen der einzelnen Phasen
und verteilt die Arbeiten auf die Iterationen (siehe dazu Kapitel
6, Aufwandschätzung).
grobPLanung, ProjektPhaSenPLan
Beim Projektphasenplan planen wir grob das gesamte Vorhaben
vom Start- bis zum Endtermin (siehe Abbildung 6). Wichtig
ist, dass man sich über die Zielsetzungen der einzelnen Phasen
und den Inhalt der Hauptmeilensteine am Phasenende («exit
criteria») klar wird.
Abb. 6: ProjektPhaSenPLan
Phase 1
Iterationen
Zeitachse
Meilensteine
Phase 2
Iterationen
Phase 3
Iterationen
FÜr jeDe PhaSe Legt Man FoLgenDeS FeSt:
• Beschreibung der Phase und ihrer Ziele
• Anzahl der Iterationen
• Start- und Endtermine der Phasen und Iterationen
FÜr jeDe IteratIon Legt Man FoLgenDeS FeSt:
Project ManageMent 27
Phase 4
Iterationen
• Anzugehende Risiken
• Zu implementierende Arbeitspakete beziehungsweise Use cases

Durch die Aufteilung des Projekts in Phasen mit Meilensteinen
kann sichergestellt werden, dass der Druck auf das Projektteam
gezielt aufgeteilt wird – die Funktion ist ähnlich wie die des Wellenbrechers
am Strand. Damit staut sich der Erfolgsdruck nicht
bis zum Projektabschluss an.
DetaILPLanung, IteratIonSPLan
Es bewährt sich, am Ende einer Phase die Detailplanung der
nächsten Phase vorzunehmen. Bei dieser rollenden Planung kann
man das Gesamtziel stets vor Augen halten. Im Detail wird nur
geplant, was innerhalb des Planungshorizonts liegt. Nach jeder
Phase muss der Plan der Realität angepasst werden. Die Detailplanung
wird mit einem klassischen Gantt-Chart gemacht.
Project ManageMent 29

5. PROJEkTSTEuERuNG
5.1 NAviGATiONSiNSTRuMENTE
Project ManageMent 31
Damit das Projekt auf Kurs bleibt, braucht es gute Instrumente
auf der Kommandobrücke. Drei Bereiche müssen besonders beachtet
werden:
AUFWAnD, tERMInE UnD RESSoURcEn
2000
1800
1600
1400
1200
1000
800
600
400
200
0
Status Workflows
SW-Modul-test SW-Entwurf SW-Dokumentation SW-codierung
StetS auF DeM LauFenDen SeIn.
Jeder Projektleiter muss wissen, wer in seinem Team wie viel an
welchem Teilpaket gearbeitet hat und ob der geplante Aufwand
ausreicht. Projektreportingtools liefern die Facts, damit der Projektleiter
frühzeitig steuernd eingreifen kann.

ProjektStatuS
G Y R
AUF EInEn BLIcK SEhEn, WIE ES UM DAS PRojEKt StEht.
Immer wieder ist es notwendig, das Projekt auf einen einzigen Status
zu reduzieren: roter Bereich oder alles im Grünen. Der Statusreport
gibt einen für alle Projekte standardisierten Zustandsbericht.
tEAMWoRK
Den gröSSten ProjekterFoLg bILDet DaS teaM.
Projektarbeit ist Teamarbeit. Teams müssen aktiv durch den Projektleiter
entwickelt, motiviert und gefördert werden. Motivierte
Teams erbringen Höchstleistungen.
5.2 AufwANd, TERMiNE uNd RESSOuRCEN
Nach Abschluss der Planungsarbeiten wird der Stand genehmigt
und als Sollvorgabe abgelegt. Jetzt erfolgt die Umsetzung der geplanten
Arbeiten. Die tatsächlich anfallenden Aufwände und die
benötigte Zeitdauer werden mit der Schätzung verglichen.
Die Projektmitarbeitenden melden zu den ihnen zugeteilten
Vorgängen periodisch die geleisteten Arbeitsstunden und die
Project ManageMent 33
nach ihrer Einschätzung noch benötigte Arbeitszeit bis zur
Fertigstellung. Ebenfalls melden sie Probleme oder Schwierigkeiten,
die aufgetaucht sind. In einem festen Intervall werden
Überwachungsdiagramme und Berichte zu Tätigkeiten und
Ressourcen aktualisiert und kommuniziert. Mit dieser Gesamtsicht
können dann korrigierende Massnahmen eingeleitet
werden.
Besondere Beachtung benötigen alle Vorgänge, die auf dem kritischen
Pfad liegen. Das heisst all jene Vorgänge, die vom Start
bis zum Ende des Projekts mit minimalen Pufferzeiten in einer
Kette liegen. Verzögerungen an einem dieser Vorgänge verzögern
auch das ganze Projekt.
Massnahmen erfolgen immer im sogenannten magischen
Dreieck von Aufwand, Zeit und Inhalt. Das heisst, eine Veränderung
in einem der drei Elemente hat immer auch Auswirkungen
auf mindestens ein anderes Element. Soll zum
Beispiel eine neue Anforderung umgesetzt werden (mehr
Inhalt), müssen dazu mehr Ressourcen eingesetzt werden
(Aufwand steigt), damit der Zieltermin gehalten werden kann
(Zeit stabil).
5.3 PROJEkTSTATuS
Der Statusreport bietet vergleichbare Informationen über alle
Projekte hinweg. Grundlage ist eine standardisierte Erfassung
und Darstellung der Statuskriterien wie in Abbildung 7.

Abb. 7: StatuSÜberSIcht
kategorie
StatuSraPPortIerung
Der Projektleiter gibt zu jeder Kategorie Antworten auf gezielte
Fragen. Die Gewichtung der Antworten variiert von Projektphase
zu Projektphase. So lässt zum Beispiel das Fehlen von Testfällen
in der Startphase des Projekts die Ampel «Qualität» nicht auf
Rot wechseln, was in der Konstruktionsphase jedoch der Fall
wäre. Die Ausarbeitung der Fragen, wie im Beispiel in Abbildung
8, ist Aufgabe einer Kontrollstelle wie des Qualitätsmanagements
oder des Project Office. Die Fragen zu den Kriterien sind
von der Geschäftsdomäne und vom verwendeten Entwicklungsprozess
abhängig.
5.4 TEAMwORk
rechtlich auftrag-
geber
Qualität termin aufwand gesamt
Ampel R Y R G G R
Status 45 50 40 90 90 21
Zu den wichtigsten Hilfsmitteln für die Kommunikation im
Team zählen die Meetings. Neben einer gut strukturierten Einla-
Project ManageMent 35
dung mit Traktanden tragen standardisierte Meeting-Protokolle
dazu bei, dass Resultate erzielt und auch festgehalten werden.
kIckoFF-MeetIng
Der Startschuss für die Projektmannschaft. Alle Beteiligten befinden
sich im Boot und kennen die Vision, die es zu verwirklichen
gilt (siehe Kapitel 1).
ProjektMeetIngS
Sie dienen dem Projektleiter dazu, die Anstrengungen der Mitarbeitenden
periodisch auf das gemeinsame Ziel hin auszurichten.
Der Stand der Teilpakete wird erläutert, und gemeinsam werden
bei etwaigen Problemen Massnahmen definiert und eingeplant.
Als ideales Hilfsmittel dienen hier die Excel-Reports aus der Projektdatenbank.
StatuSMeetIngS
Periodisch präsentiert der Projektleiter dem Auftraggeber den
Projektstatus. Hier wird das Vertrauen, das der Auftraggeber dem
Projektteam schenkt, bestärkt und ausgebaut. Die Statusreporte
und die umgesetzten Massnahmen aus den Project Reviews dienen
als Grundlage.
WoRKShoPS
Sollen ganz bestimmte Resultate gemeinsam erarbeitet werden,
bilden Workshops eine ideale Plattform. Sei es, um die Schätzgenauigkeit
zu steigern oder um Anforderungen aufzunehmen:
Gut vorbereitete Wokshops mit kompetenter Moderation erzeugen
grosse Wirkung.

Abb. 8: auSZug StanDarDISIerter FragenkataLog (1)
kategorie kriterium Antwort Punkte
rechtlich • Ist der change-Management-
Prozess definiert (J/N)? ...
• bestehen Verträge mit
unterlieferanten (J/N)? ...
auftrag-
geber
• Sind die resultate schriftlich
ausgehandelt (J/N)? ...
• gibt es beanstandungen:
(1) mündlich, (2) schriftlich? ...
Qualität • anzahl der besetzten rollen
von PM, PL, QM ...
• Fertigstellungsgrad Software
Development Plan (%) ...
termin • Sind die tätigkeiten den
Mitarbeitenden zugeordnet
(J/N)? ...
• Wird der Grad der Erfüllug
tätigkeiten verfolgt (J/N)? ...
aufwand • Ist die aufwandschätzung
realistisch (J/N)? ...
• Ist die aufwandplanung
aktuell (J/N)? ...
j
j
n
0
3
100
j
j
j
j
25
20
20
50
0
0
30
30
25
30
Project ManageMent 37

6. AufwANdSChäTZuNG
6.1 SChäTZMEThOdik
Project ManageMent 39
Als Basis für die Planung und die Budgetierung muss der Aufwand
des Projekts geschätzt werden. ERNI verwendet eine empirische
Methode, die «Min-Max-Methode». Diese basiert auf
der Erfahrung der Schätzer und verwendet eine Systematik, um
grobe Fehleinschätzungen zu vermeiden. Zu bedenken ist,
dass es keine richtige oder falsche Schätzung gibt, da der spätere,
tatsächliche Aufwand von vielen Faktoren beeinflusst wird.
Schätzen ist somit nicht mit Messen zu vergleichen. Es geht
nur darum, möglichst vernünftige Annahmen für die Planung
zu erhalten.

DIe MethoDe baut auF FoLgenDe MerkMaLe:
• Das Projekt wird in tätigkeiten oder Arbeitspakete gegliedert.
Das führt zu einem besseren Verständnis der Projektaufgabe.
• Die Schätzung wird von mehreren Beteiligten durchgeführt.
Dadurch werden krasse Fehlschätzungen für einzelne aufgaben
verhindert, weil es statistisch unwahrscheinlich ist, dass
mehrere Leute denselben Fehler machen.
• Die Schätzungen werden vom Projektteam gemacht. Daraus
entsteht ein commitment zum geschätzten aufwand.
• Die Einzelresultate werden im team besprochen. Dadurch
werden die «klaren Fälle» und die kritischen Schätzungen
identifiziert. Letztere werden genauer unter die Lupe
genommen und neu geschätzt. Das Verständnis für die
Projektaufgabe steigt weiter.
• Es wird nicht nur der «best case» geschätzt. Unsicherheit
und risiko werden in der Schätzung separat berücksichtigt.
aus den Zahlen kann interpretiert werden, wie genau die
Schätzung ist.
• Die Methode liefert Angaben über Planungsreserven. Der
Projektleiter kann später bei einzelnen aufwandüberschreitungen
reagieren.
• Die Methode verwendet das Expertenwissen der Projektmitarbeiter.
Die erfahrungen aus früheren Projekten können
formlos übernommen werden.
6.2 vORGEhEN
VERWEnDUnGSZWEcK BEStIMMEn
Project ManageMent 41
Die Aufwandschätzung dient als Basis für verschiedene Planungsaufgaben
wie Budget-, Ressourcen- und Iterationsplanung.
Für diese Planungsaufgaben braucht es, je nach Zeitpunkt,
einen unterschiedlichen Detaillierungsgrad. Deshalb muss vor
dem Schätzen der Verwendungszweck klar sein.
StrukturIeren
Zuerst geht es darum, das Projekt zu verstehen. Worum geht es
und was muss getan werden, um das Ziel zu erreichen? Dazu
werden die geforderten Lieferergebnisse und Arbeiten des Projekts
hierarchisch in kleinere Einheiten zerteilt, die sich besser
schätzen und handhaben lassen. Das Ergebnis dieser Arbeit ist
ein Projektstrukturplan (PSP). Auf der untersten Ebene sind damit
alle notwendigen Arbeiten (Arbeitspakete) aufgeführt, die zur
Erreichung des Projektziels nötig sind. Auf dieser Ebene können
jetzt die Aufwände sinnvoll geschätzt werden.
Die erste Stufe der Strukturierung kann je nach Bedarf des Projekts
zum Beispiel nach Lieferbestandteilen, organisatorischen
Bereichen (Teilprojekte) oder fachlichen Bereichen erfolgen.

Abb. 9: ProjektStrukturPLäne unterSchIeDLIch
StrukturIert
Projekt-
management
Requirementengineering
arbeitspaket
Projekt
Software
engineering
… client Server …
Auszug aus PSP, strukturiert nach Tätigkeitsbereichen
Requirementsengineering
Projekt
client Server
arbeitspaket 1
Software
engineering
….
Projekt-
management
… …
Auszug aus PSP, strukturiert nach liefergegenständen
Phase 1
Requirements Eng.
client
Server
Projekt
Phase 2
…
arbeitspaket 1
Auszug aus PSP, strukturiert nach Phasen
Projektmanagement
...
teaMSchätZen
Project ManageMent 43
Die Schätzer sollten Teammitglieder sein, die an der Erarbeitung
der Projektziele beteiligt sind. Jeder Schätzer erhält das Schätz-
Template, das der Projektleiter vorgängig mit der gewählten
Struktur ausgefüllt hat.
Jeder Schätzer schätzt für sich jede Position als Vorbereitung für
den Workshop. Absprachen sind nicht erlaubt. Im Workshop
wird Position für Position durchgegangen, und das Team einigt
sich auf einen Schätzwert. Wo die Abweichungen der einzelnen
Schätzungen hoch sind, werden die Ursachen erforscht. Eventuell
müssen dann detaillierte Abklärungen geplant werden. Im
Workshop wird nach der ersten Konsensfindung das Resultat auf
Plausibilität getestet. Das geschieht, indem die Teilresultate untereinander
und mit früheren Schätzungen verglichen werden.

eISPIeLe FÜr PLauSIbILItätSteStS
• Projektleitungsaufwand:
• 10%–Basis
• + 3% pro Mitarbeitenden
• + 10% pro beteiligte organisation oder Abteilung
• + 0,8 bis 1,5% je nach Erfahrung des Projektleiters und je
nach Projektrisiko
• Aufteilung der Phasen:
• Inception 10–15 %
• Elaboration 15–20 %
• construction 40–50 %
• transition 15–25 %
SchätZen Von unSIcherheIten unD rISIken
Für jede zu schätzende Aufgabe der Struktur wird ein Bereich angegeben.
Wir schätzen für die Aufgabe a zwischen x und y Tage an
Aufwand. Der Wert x gibt das Minimum, der Wert y das Maximum
des geschätzten Aufwands für den Normalfall an, falls keine unerwarteten
Probleme auftauchen. Die Angabe von zwei Werten statt
nur einem gibt dem Schätzer die Möglichkeit, seine Unsicherheit
auszudrücken. Damit kann dann auch für das Projekt eine Aufwandschätzung
mit einer Bandbreite abgegeben werden. Je unklarer
die Aufgabe ist, desto weiter liegen die Werte auseinander.
In der realen Projektwelt kommen oft unerwartete Situationen
dazu. Diese werden nun zusätzlich als Risiko geschätzt. Diese
Project ManageMent 45
Unterscheidung zwischen Unsicherheit und Risiko soll helfen,
einen möglichst plausiblen Wert zu erhalten, auch wenn die Unterscheidung
im Einzelfall nicht genau begründet werden kann.
Es ist dem Schätzer überlassen, was er als Unsicherheit und was
er als Risiko betrachtet. Bei der späteren Planung wird nur der
mittlere Aufwand ohne Risiko für die einzelne Aufgabe eingeplant
und der Risikowert als Reserve gehalten.

7. RiSikOMANAGEMENT
Project ManageMent 47
Was ist ein Risiko? Ein Risiko ist ein mehr oder weniger unwahrscheinliches
Ereignis, dessen Eintreten den geplanten Projektverlauf
entscheidend behindern kann. Wahrscheinliche Ereignisse
sollten nicht als Risiko betrachtet werden, sondern in der
Planung von Anfang an berücksichtigt werden.
Das Risikomanagement wird an den Anfang des Projektmanagements
gesetzt und ist ein kontinuierlicher Prozess, der sich über
den gesamten Verlauf des Projekts hinwegzieht. Ziel ist es, rechtzeitig
Massnahmen zu treffen, um den Schaden für das Projekt
möglichst klein zu halten und den Aufwand für die Risikominimierung
angemessen anzusetzen.
7.1 vORGEhEN
teaM ZuSaMMenSteLLen
Die Identifikation von Risiken ist ein kreativer Prozess, der im
Team einfacher zu bewältigen ist. Die Aufgabe verlangt von den
Akteuren eine Übersicht über möglichst viele Belange des Projekts.
Mögliche Teilnehmende sind deshalb der Projektleiter, der
Teilprojektleiter, der Softwarearchitekt und eventuell auch ein
Vertreter des Auftraggebers.
RISIKoWoRKShoP oRGAnISIEREn
In einem Workshop werden mittels Brainstorming mögliche
Risiken identifiziert und aufgelistet. Die Teilnehmenden ent-

fernen die unwahrscheinlichen Risiken und die Risiken mit
kleinem Einfluss aus der Liste. Maximal 20 Risiken werden klassifiziert.
Zur Unterstützung bietet die untenstehende Tabelle
Anregungen für die Identifikation von Risiken.
kLaSSISche rISIkotyPen
Anforderungen, Projektrahmen
• Projektziele unklar oder Änderung der Projektziele
im Projektverlauf
• Unklare, ungenügende oder mehrdeutige Anforderungen
• änderungen in Projektrahmen oder Systemabgrenzung
lösungsstrategie
• teile der Strategie lassen sich nicht realisieren
• Lieferanten oder Schlüsselmitarbeitende fallen aus
• Abhängigkeiten
Projektorganisation
• Mitarbeitende und ihre Fähigkeiten
• Unklare, ungenügende oder mehrdeutige
Verantwortlichkeiten
Ressourcen
• Finanzen, Mitarbeitende, technologien
MaSSnahMen Zu Den rISIken auSarbeIten
Für die zehn wichtigsten Risiken werden Massnahmen ausgearbeitet.
Diese Aufgabe ist komplex und lässt sich im Workshop
Project ManageMent 49
nur im Ansatz lösen. Der Projektleiter übernimmt anschliessend
die Ausarbeitung von Detailmassnahmen zu allen Risiken.
MaSSnahMen PLanen
Die Massnahmen zur Risikominimierung müssen in die ordentliche
Projektplanung aufgenommen und einzeln an einen Verantwortlichen
delegiert werden. Der Aufwand für die Umsetzung
der Massnahmen wird sinnvollerweise der Projektleitung
zugeordnet.
WIRKSAMKEIt Von MASSnAhMEn In StAtUSMEEtInGS PRüFEn
Die Wirksamkeit der Massnahmen, das heisst die Verminderung
des Risikos, wird im Statusmeeting überprüft. Dazu werden die
Risiken wie im Workshop klassifiziert. Die Veränderung des Risikopotenzials
wird betrachtet, um die Wirksamkeit der Massnahmen
zu beurteilen. Anpassungen der Massnahmen werden entsprechend
beschlossen und neu geplant.
RISIKoWoRKShoP PERIoDISch WIEDERhoLEn
Das Statusmeeting überprüft meist nur die Entwicklung der Risiken
und der dazugehörenden Massnahmen. Bei längeren Projekten
ist es jedoch sinnvoll, den Risikoworkshop zu wiederholen, um
sicherzugehen, dass neu aufgetretene Risiken identifiziert werden.
7.2 RiSikOklASSifiZiERuNG
Die Klassifizierung der Risiken geschieht mit dem Ziel, Prioritäten
für das Handeln zu setzen. Sie kann nicht verwendet werden,

um das Eintreffen von Risiken vorherzusagen. Die Risikoklasse
bestimmt die Dringlichkeit der Massnahmen und den vernünftigen
Aufwand für die Risikominimierung.
Das Risiko setzt sich zusammen aus dem möglichen Schaden
und der Wahrscheinlichkeit des Eintretens des Ereignisses. Da es
meist schwierig ist, das Risiko direkt einzuschätzen, werden die
Wahrscheinlichkeit und der mögliche Schaden separat geschätzt.
Beides wird in einer Zahl (Skala 1–5) ausgedrückt. Durch
Multiplikation wird ein Wert für das Risiko berechnet. Die Risiken
können anhand dieses Wertes geordnet werden.
7.3 RiSikObEhANdluNG
FÜr DIe rISIkobehanDLung können FoLgenDe DreI
StRAtEGIEn AnGEWAnDt WERDEn:
1. Minderung von Risiken mit hohem Schadensausmass
bzw. mit grosser Eintretenswahrscheinlichkeit: Der Projektleiter
definiert proaktiv Massnahmen.
2. übertragung von extern bedingten Risiken: Die risiken
werden vertraglich an jemanden mit direktem einfluss
delegiert, zum beispiel an den auftraggeber, den Lieferanten
oder an eine Versicherung.
3. Akzeptierung von vertretbaren Risiken: Der Projektleiter
wird erst beim eintreten des risikos aktiv.
Project ManageMent 51
In der Regel wird man sich für einen Mix dieser drei Strategien
entscheiden. Die Risikomatrix in Abbildung 10 gibt Hinweise
auf die anzuwendende Strategie. Im Quadrant rechts oben (hohe
Wahrscheinlichkeit und hoher Schaden) kann das Risiko wie eine
Tatsache behandelt werden. Sofortmassnahmen können geplant
werden («immediate action»).
Abb. 10: rISIkoMatrIx
Schadensausmass
reaktive
Massnahmen
risiko
akzeptieren
wahrscheinlichkeit
Sofortmassnahmen
planen
Präventive
Massnahmen

Project ManageMent 53
8. ChANGE REquEST MANAGEMENT
In jedem Projekt gibt es Änderungen! Der Projekterfolg hängt
vom richtigen Umgang mit ihnen ab. Change Request Management
ist die Kunst, mit Änderungen richtig umzugehen. Nicht
jede Änderung stellt prinzipiell ein Risiko für das Projekt dar. Oft
handelt es sich dabei um eine normale Begleiterscheinung. Mit
Änderungen sind Fehler, neue oder geänderte Anforderungen
sowie notwendige Designänderungen gemeint.
Die erste Schwierigkeit liegt im Erkennen von Änderungen, da
sich diese oft schleichend einstellen. Die zweite Herausforderung
besteht in der Analyse der Konsequenzen und in der Ableitung
der notwendigen Massnahmen.
Erkannte Änderungen müssen erfasst, wie normale Projektanforderungen
analysiert und in der Planung berücksichtigt werden. Wichtig
ist dabei auch das Feedback an die Stakeholder und die Anpassung
an die Erwartungshaltung in Bezug auf Aufwand und Termin.
8.1 vORGEhEN
ProjektkuLtur ISt änDerungSSenSItIV
Zu diesem Zweck muss der Projektleiter proaktiv Massnahmen
ergreifen, die den Umgang mit Anforderungsänderungen erlauben.
Er muss unter den Projektmitarbeitenden eine Kultur aufbauen,
die änderungssensitiv ist. Sie sollen Änderungen rechtzeitig
als solche erkennen und richtig damit umgehen.

ISIkoabSchätZung
DIe reIhenFoLge FÜr eInen rISIkogerechten uMgang
MIt änDerungen Lautet:
1. es wird untersucht, welche funktionalen anforderungen von
der änderung betroffen sind.
2. alle damit verbundenen nichtfunktionalen anforderungen sowie
die testanforderungen und -spezifikationen werden ermittelt.
3. In Form einer Impact-analyse wird erarbeitet, wie sich der
änderungswunsch auf den Projektverlauf auswirkt.
4. Parallel dazu wird eine risikobetrachtung im hinblick auf die
umsetzung durchgeführt.
WoRKFLoW BEFoLGEn
Der Projektleiter sorgt dafür, dass Änderungen mit dem Formular
«Änderungsantrag» erfasst werden. Das Änderungsformular
besteht aus mehreren Abschnitten und schreibt einen Workflow
vor. Damit wird sichergestellt, dass die Änderung erfasst wird,
ihre Auswirkungen quantifiziert sowie die Freigabe/Ablehnung
und die Umsetzung dokumentiert werden.
entScheIDen
Der Ort, wo Änderungen behandelt werden und über die Auswirkungen
auf das Projekt sowie den Projektplan entschieden wird,
ist das Change Management Meeting. Teilnehmende sind der
Projektleiter, der Architekt und eventuell weitere Entwickler
oder ein Vertreter des Auftraggebers.
MaSSnahMen
Project ManageMent 55
1. regelmässige change Management Meetings ansetzen.
2. änderungsanträge sammeln und auf Vollständigkeit prüfen.
3. Liste der änderungsanträge mit den neuen änderungsanträgen
ergänzen und mit der einladung zum change Management
Meeting verschicken.
4. Für jeden änderungsantrag den aufwand pro team respektive
Subsystem abschätzen (Architekt resp. Entwickler).
5. Priorisierung der änderungsanträge an einem gemeinsamen
Meeting.
6. entscheiden, welche änderungsanträge mit den verfügbaren
ressourcen in der nächsten Iteration behandelt werden können.
ergänzung der Planung durch den Projektleiter.
7. Für nicht beurteilbare änderungsanträge wird eine verantwortliche
Person bestimmt, die bis zum nächsten Meeting das
notwendige abklärt.

9. kOMMuNikATiONSfORuM
Project ManageMent 57
In einem erfolgreichen Projekt wird intensiv und effizient über die
verschiedensten Aspekte des Projekts kommuniziert. Dokumente
und Meinungen werden ausgetauscht, Gesprächsrunden entstehen
ad hoc und lösen Probleme, die latent vorhanden sind. Wie
kann nun ein Projektleiter diesen Informationsaustausch fördern?
Möglichkeiten, die informelle Kommunikation zu gestalten,
sind ein guter Teamgeist oder Kaffeepausen. Gut bewährt haben
sich auch Stellwände mit Skizzen und Dokumenten in den
Arbeitsräumen.
Project coLLaboratIon
Die geforderten Projektziele können nur mit einer guten Zusammenarbeit
im Projektteam erreicht werden. Projektteams bestehen
meist aus Personen verschiedener Abteilungen und Firmen
an verschiedenen Standorten. Diese virtuellen Teams erfordern
zusätzliche Aufmerksamkeit, damit eine gute und schnelle Projektzusammenarbeit
entstehen kann.
Elektronische Medien verhelfen geografisch verteilten Teams zu
einer einfachen Zusammenarbeit. Wichtig ist, dass definiert
wird, welche Medien für welchen Einsatz verwendet und genutzt
werden sollen. Sollen Dokumente zentral abgelegt oder
per Mail verschickt werden? Eine kurze Evaluation der verfügbaren
elektronischen Medien aufgrund der Anforderungen für die
Projektzusammenarbeit hilft, Ineffizienzen von Beginn an zu
minimieren. Auch für die anschliessende Nutzung der Plattform

sind Regeln hilfreich. Wie wird zum Beispiel versioniert, oder
welche Ablagestruktur wird verwendet?
Gerade weil in virtuellen Projektteams die Kommunikation
sinnvollerweise über elektronische Medien erfolgt, braucht das
Projekt ein Präsenztreffen zum Aufbau eines Wir-Gefühls. Ansonsten
bleiben die Teammitglieder ihrem eigenen Arbeitsumfeld
verbunden und betrachten die virtuelle Teamarbeit mit einer
gewissen inneren Distanz. Das Präsenztreffen hilft, die Distanz
zu verringern.
Gemeinsame Verhaltensregeln helfen, das Vertrauen in der Zusammenarbeit
aufrechtzuerhalten. So kann zum Beispiel vereinbart
werden, dass nur in persönlichen Gesprächen auf Schwierigkeiten
oder Fehler anderer aufmerksam gemacht wird und
nicht per E-Mail, da diese Form der Kommunikation sehr anfällig
für Missverständnisse ist.
Besonders gefährdet ist die Zusammenarbeit, wenn projektferne
Verpflichtungen zu Loyalitätskonflikten führen. Eine Regelung,
wie der Projektmitarbeiter sich verhalten soll, wenn er
Verpflichtungen nicht einhalten kann (z.B. Kommunikation an
den Projektleiter schon beim Abzeichnen von Terminverschiebungen),
hilft, rechtzeitig Gegenmassnahmen einleiten zu können.
In heterogenen Projektteams entstehen auch schnell Missverständnisse
aufgrund unterschiedlicher Interpretation von Fachbegriffen.
Ein Glossar hilft, hier Klarheit zu schaffen.
Project ManageMent 59
Sinnvollerweise wird der Teambildungsprozess schon vor Beginn
der fachlichen Arbeit gestartet.
Project coLLaboratIon
• Präsenztreffen zum Stärken des Wir-Gefühls
• Auswählen und Aufsetzen einer elektronischen collaboration-
Plattform
• Definieren und Schulen der Art der elektronischen Zusammenarbeit
• Definieren von Versionierungsmethodik, Ablagestruktur usw.
• Definieren gemeinsamer Verhaltensweisen
• Verwenden eines Glossars

10. GlOSSAR
anForDerungen
Project ManageMent 61
Die Anforderungen bestimmen im Detail, was als Endergebnis eines
Projekts vorliegen muss. Anforderungen an ein zu entwickelndes
System werden oft in funktionale (benutzerorientierte, technische)
und nichtfunktionale (Leistungs- und Qualitätsmerkmale)
Anforderungen gegliedert.
arteFakt
Beliebiges Projektdokument oder Teil eines Dokuments. Bezeichnet
das Resultat (z.B. Use Case Model) und nicht das eigentliche
Dokument.
auFtraggeber
Rolle im Projekt. Der Auftraggeber ist die oberste Instanz im Projekt.
Meist ist er auch der Sponsor.
AUFWAnD
Bezeichnet sowohl Zeit wie auch Geld.
change reQueSt ManageMent
Prozess, der die Änderung der Anforderungen und die daraus resultierenden
Konsequenzen regelt.
checkLISte
Aufgabenliste, die einer einfachen Anleitung entspricht und zur
Überprüfung der Vollständigkeit eines Vorgehens verwendet wird.

conFIguratIon ManageMent tooL
Werkzeug zur Unterstützung des Configuration Managements.
gantt-chart
Detaillierte grafische Darstellung der Tätigkeiten im Projekt. Zeigt
den zeitlichen Ablauf sowie eventuell Abhängigkeiten und die Verantwortlichkeiten.
InkreMenteLL
Bedeutet: anwachsend, sich evolutionär entwickelnd. Damit
drückt man aus, dass am Schluss jeder Iteration eine lauffähige
Version vorliegt, die vollständiger ist (mehr Anforderungen abdeckt)
als die vorhergehende Version.
IteratIV
Bedeutet: wiederholt, immer gleich ablaufend (Prozessschritte).
Damit drückt man aus, dass ein Prozessablauf mehrfach durchlaufen
wird.
kIckoFF-MeetIng
Wichtiges erstes Meeting zum Auftakt des Projekts. Der Anlass ist
einerseits als Event zu gestalten mit der Botschaft «Wir legen los».
Andererseits werden die wichtigsten Abmachungen getroffen.
PLanung
Tätigkeit bzw. Resultat, das ein Modell der Zukunft darstellt. Bezieht
sich auf jede vorausschauende Tätigkeit, nicht nur auf die
Modellierung des zeitlichen Ablaufs (Projektplanung).
PoSt-PRojEct REVIEW
Project ManageMent 63
Review nach Abschluss des Projekts. Dient als Gefäss, um «lessons
learned» zu erfassen.
ProjektLeIter
Führungsrolle im Projekt. Je nach Projektorganisation sind die
Aufgaben und Kompetenzen unterschiedlich weit gefasst. Ein Projekt
kann auch die Hierarchie der Projektleiter definieren.
ProjektorganISatIon
Darstellung der verschiedenen Rollen im Projekt, ihrer Unterstellungsverhältnisse,
ihrer Beziehung zueinander und ihrer personellen
Besetzung.
QuaLItätSManager
Rolle im Projekt. Der Qualitätsmanager ist Teil der Projektorganisation,
aber nicht dem Projektleiter unterstellt. Seine Aufgabe ist
es, die Einhaltung der Anforderungen aus dem Qualitätssystem
sicherzustellen.
reSSource
Bezeichnet die notwendigen Mittel für die Durchführung einer
Aufgabe oder eines Projekts. Meist werden personelle Ressourcen
und Sachmittel unterschieden.
REVIEW
Überprüfung eines Zwischenresultats aus dem Projekt durch andere
als den Autor. Die Form und das Vorgehen können stark variieren.

ISIko
Ein Risiko ist ein mögliches, künftiges, ungeplantes, unerwartetes,
«negatives» Ereignis, dessen Eintreten zu unerwünschten Folgen
führt. Ein Risiko kann klassifiziert werden mit der Wahrscheinlichkeit
des Eintreffens und dem potenziellen Schadensausmass.
SPonSor
Rolle im Projekt. Der Sponsor kann Teil der Projektorganisation
sein. Er bestimmt über das Budget und über eventuelle Nachträge.
StakehoLDer
Interessensvertreter, allgemein. Jeder, der ein Interesse am Gelingen
des Projekts hat oder von dessen Auswirkungen betroffen ist.
teMPLate
Vorlage für ein Dokument, das nebst formalen Vorgaben auch inhaltliche
Anhaltspunkte gibt.
uSe caSe
Ein Use Case, auch Anwendungsfall genannt, bezeichnet eine zusammengehörende
Anzahl von Schritten, die ein User mit einem
System ausführt, um zu einem für ihn wertvollen Resultat zu kommen.
Use Cases stellen im modernen Software-Entwicklungsprozess
unteilbare Anforderungen dar, die sich unabhängig voneinander
planen, spezifizieren, implementieren und testen lassen.
WoRKShoP
Meeting, in dem die Teilnehmenden gemeinsam ein Resultat erarbeiten.
Project ManageMent 65

enables & delivers
www.erni-consultants.com