Upload
dci-ag
View
237
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Â
Citation preview
Project ManageMent 1ernI eSSentIaLSPROJECT MANAGEMENT
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
enables & delivers
Ein Projekt charakterisiert sich durch ein
definiertes Ziel, gegebene Rahmenbedin-
gungen (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ähig-
keit sowie die Sozialkompetenz, ein Team
zu führen und zu motivieren. Durch ein
standardisiertes und methodisches Vorge-
hen 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 erfolg-
reichen Projektabschluss führen.
ernI – Innovation in Process and technology
EiNfühRuNG
oLIVIer [email protected]
Senior consultant und Projektsteurer bei Swiss engineering Institute
Project ManageMent 5
1. EiNlEiTuNG
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 erken-nen und angemessen darauf zu reagieren. Der Projektleiter muss sich, wie in Abbildung 1, als Drehscheibe und Kommunikations-knoten im Projekt sehen. Sein Erfolg hängt davon ab, ob er seine Rolle richtig versteht.
Abb. 1: Der ProjektLeIter aLS koMMunIkatIonSDrehScheIbe
Project Manager
externe Lieferanten
Projekt-mitarbeitende
auftraggeber
geschäftsleitung
Zulassungsstelle
It controller
benutzer
tester
Project ManageMent 7
Die Tätigkeiten des Projektleiters lassen sich weiter, wie in Abbil-dung 2 zu sehen, in vier Hauptkategorien aufteilen. Er ist dann am erfolgreichsten, wenn es ihm gelingt, die richtigen Informa-tionen zu erhalten und die Resultate geeignet weiterzugeben.
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-
Abb. 2: hauPttätIgkeIten DeS ProjektLeIterS
analysierenStrukturieren
Problemelösen
PriorisierenPlanen
Überwachen
kommunizieren
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 vergli-chen werden (siehe Kasten zur Situationsanalyse). Dabei darf diese Aufgabe nicht zur Protokollierung von Terminverschiebungen verkommen. Anpassungen an der Planung sollten immer an be-gleitende 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 Pro-jektleiters.
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ösungs-strategie).
Project ManageMent 9
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 Verantwortli-
chen 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 11
2. PROJEkT-STARTuP
2.1 dAS PROJEkThANdbuCh: diE ChECkliSTE füR dEN PROJEkTlEiTER
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 Pha-senende. 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 ab-arbeitet.
Abb. 3: beLaStung DeS ProjektLeIterS
Startphase
Zeitachse
bela
stun
g
Projektverlauf endphase
Project ManageMent 13
ters nachvollziehen kann. Indem er dieses Werkzeug in allen Projekten ähnlich einsetzt, legt er den Grundstein für eine Kon-solidierung des Projektstatus in seinem Portfolio.
2.2 vORGEhEN
Wie bei einer Checkliste üblich, fängt man am Anfang des Doku-ments 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 FoL-genDe 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 Auftragge-
ber 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.
Das ERNI Projekthandbuch (PHB) ist eine solche Checkliste. Da-mit werden alle wichtigen Entscheide der Startphase angespro-chen. Der Projektleiter bearbeitet die Fragestellungen und fällt die notwendigen Entscheide. Die Resultate werden im PHB fest-gehalten. So entsteht ein Regelwerk für das Projektteam und an-dere Beteiligte, das alle Vorgaben im Projekt dokumentiert. Das PHB ist ein Dokument-Template, das Textvorgaben und Beispiel-lösungen zur Verfügung stellt. Damit wird der Projektleiter ge-führt und durch Kommentare angeleitet.
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-
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
Project ManageMent 15
VeränDerbarkeIt Der ergebnISSe IM ProjektabLauFBei den Entscheidungen sollte man sich immer überlegen, ob eine einfachere Regelung möglich ist und ob die Betroffenen die-se Regel als Unterstützung oder als Behinderung empfinden. Die Kunst besteht darin, nicht alles regeln zu müssen, sondern nur das Wichtigste.
REVIEW UnD ABnAhMEWenn die erste Version des PHB geschrieben ist, empfiehlt sich ein Review durch den Qualitätsmanager (QM) des Projekts. Da-nach sollte die abschliessende Abnahme durch den Auftragge-ber, der ja auch schon mitgearbeitet hat, eingeholt werden. Im
Abb. 4: VeränDerbarkeIt Der ergebnISSe IM ProjektabLauF
Projektumfang
ausgangs- punkt (100%)
Projektstart Phase 1 Phase 2 Phase 3 Projektende
erarbeitete resultate aufgelaufene kosten
Sichtbarkeit ergebnisse
beeinflussbarkeit
aus
brec
hen
kIckoFF-MeetIngDas Kickoff-Meeting ist das ideale Gefäss, um den Auftraggeber und das Team mit den Fragestellungen aus dem PHB zu konfron-tieren. Die wichtigsten Abmachungen werden dort getroffen. Das Inhaltsverzeichnis des PHB gibt dem Projektleiter die Trak-tandenliste für das Kickoff.
DetaILS abkLärenDas PHB enthält an den wichtigen Orten Kommentare und Bei-spiele, 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 aus-schliesslich durch intensives Denken. Folgendes darf nicht ver-gessen werden: Definierte Regelungen und getroffene Entschei-dungen nützen nur etwas, wenn man sie kommuniziert. Das heisst konkret: raus aus dem Büro und mit Stakeholdern, Liefe-ranten, Projektmitarbeitenden und Know-how-Trägern reden!
Wichtig zu diesem Zeitpunkt ist auch, dass die erhaltenen Ant-worten hinterfragt werden, damit eine fundierte, stabile Projekt-definition entsteht. Anpassungen zum Zeitpunkt des Projekt-starts sind ohne grosse Mehrkosten umsetzbar. Je weiter das Projekt dann fortschreitet, desto schwieriger werden Änderun-gen an den grundlegenden Zielsetzungen.
Project ManageMent 17
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 19
3. ZiElvEREiNbARuNGZIeLForMuLIerungWas versteht man im Rahmen eines Projekts unter einem Ziel?
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.
ZIeLharMonISIerungOft wird die Zielvereinbarung vernachlässigt, weil man denkt, dass die Ziele jedem klar seien. Erfahrungsgemäss ist das ein gros-ser Irrtum. Die Vorstellungen der Stakeholder über die Projekt-ziele divergieren oft. Deshalb ist es wichtig, die Ziele in der An-fangsphase eines Projekts zu harmonisieren. Am besten erreicht man dies, indem man die Stakeholder einzeln nach ihren Erwar-tungen, Visionen und Zielen befragt. Alle Ergebnisse sollte man schriftlich festhalten und bestätigen lassen.
DaS ZIeL beSchreIbt eInen ...
... gedanklich vorweggenommenen, zukünftigen Zustand,• der bewusst ausgewählt und gewünscht• und durch aktives handeln erreicht wird.
Project ManageMent 21
InhaLte Der ZIeLhIerarchIe
• 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 de-monstrierbar.
• Kommen im Lauf des Projekts plötzlich neue Anforderun-gen («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
ZIELVEREInBARUnGS-WoRKShoPDie Durchführung eines halbtägigen Zielvereinbarungs-Work-shops ist ein bewährtes Vorgehen, um die Differenzen und den Konsens klar zum Vorschein zu bringen. Die entscheidende Auf-gabe 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.
ZIeLhIerarchIeWie in Abbildung 5 dargestellt, müssen Ziele auf verschiedenen Abstraktionsniveaus und in unterschiedlichen Detaillierungs-graden definiert werden.
Abb. 5: ZIeLhIerarchIe
vision
feature
Requirements
Zielvereinbarung: ein Satz auf einer Folie
Auftraggeber: business needs, geschäftsidee
Produktbeschreibung: eine Liste von Merkmalen
Stakeholder: kunden-wünsche, Produktmerk-male
Spezifikation: detaillierte beschreibung der einzelhei-ten des Verhaltens
Entwickler: Requirements Specifications (Use Case, Suppl. Specification)
Project ManageMent 23
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 verstan-den werden.
5. Ziele in geeigneter Form (Plakat, Projektweb, Statusmeeting) nach aussen und innen kommunizieren. Gut gewählte Zie-le stellen Erfolgsfaktoren für das Projekt dar. Eine der wich-tigsten 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 Priori-täten für die Massnahmen nach ihnen ausrichtet.
Project ManageMent 25
4. PlANuNG
4.1 PROJEkTPlAN
MoDeLLIeren Der ZukunFtWas 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 Mo-dellierung der Tätigkeiten in Bezug auf ihren Start und ihr Ende sowie auf die Abhängigkeiten untereinander.
Dazu kommen noch Parameter wie eingesetzte Ressourcen, Mei-lensteine und die Gruppierung von Tätigkeiten.
koMMunIkatIonSMItteLDer 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 Projekt-plan breit verteilt und diskutiert werden.
baSIS FÜr anPaSSungenWährend der Planung machen sich der Projektleiter und sein Team Gedanken über unbekannte Gefahren und Risi-ken. Treten während des Projekts grosse unerwartete Schwie-rigkeiten auf, so hilft der Plan beim Abschätzen von Konse-quenzen. Man kann Abhängigkeiten zwischen Aktivitäten und ihre Konsequenzen auf Zeit und Kosten aufzeigen. Man
Project ManageMent 27
Abb. 6: ProjektPhaSenPLan
Phase 1
Iterationen
ZeitachseMeilensteine
Phase 2
Iterationen
Phase 3
Iterationen
Phase 4
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:
• Anzugehende Risiken• Zu implementierende Arbeitspakete beziehungsweise Use cases
kann Szenarien darstellen und einen Entscheid für die wei-tere Arbeit treffen. Der Projektplan verändert sich im Pro-jektverlauf.
4.2 vORGEhEN
StrukturIerenWer ein grosses Vorhaben anpacken will, muss es in Teilpa-kete herunterbrechen. Diese können einzeln geplant, organi-siert 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 zwei-ten Schritt macht man sich ans Planen der einzelnen Phasen und verteilt die Arbeiten auf die Iterationen (siehe dazu Kapitel 6, Aufwandschätzung).
grobPLanung, ProjektPhaSenPLanBeim Projektphasenplan planen wir grob das gesamte Vorha-ben 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.
Project ManageMent 29
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 Wel-lenbrechers am Strand. Damit staut sich der Erfolgsdruck nicht bis zum Projektabschluss an.
DetaILPLanung, IteratIonSPLanEs 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 Detailpla-nung wird mit einem klassischen Gantt-Chart gemacht.
Project ManageMent 31
5. PROJEkTSTEuERuNG
5.1 NAviGATiONSiNSTRuMENTE
Damit das Projekt auf Kurs bleibt, braucht es gute Instrumente auf der Kommandobrücke. Drei Bereiche müssen besonders be-achtet werden:
AUFWAnD, tERMInE UnD RESSoURcEn
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 Pro-jektleiter frühzeitig steuernd eingreifen kann.
Status Workflows
SW-Modul-test SW-Entwurf SW-Dokumentation SW-codierung
2000
1800
1600
1400
1200
1000
800
600
400
200
0
Project ManageMent 33
nach ihrer Einschätzung noch benötigte Arbeitszeit bis zur Fertigstellung. Ebenfalls melden sie Probleme oder Schwierig-keiten, die aufgetaucht sind. In einem festen Intervall werden Überwachungsdiagramme und Berichte zu Tätigkeiten und Ressourcen aktualisiert und kommuniziert. Mit dieser Ge-samtsicht können dann korrigierende Massnahmen eingelei-tet werden.
Besondere Beachtung benötigen alle Vorgänge, die auf dem kri-tischen 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 Aus-wirkungen 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.
ProjektStatuS
AUF EInEn BLIcK SEhEn, WIE ES UM DAS PRojEKt StEht. Immer wieder ist es notwendig, das Projekt auf einen einzigen Sta-tus zu reduzieren: roter Bereich oder alles im Grünen. Der Statusre-port gibt einen für alle Projekte standardisierten Zustandsbericht.
tEAMWoRKDen gröSSten ProjekterFoLg bILDet DaS teaM.Projektarbeit ist Teamarbeit. Teams müssen aktiv durch den Pro-jektleiter 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 ge-planten 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
G Y R
Project ManageMent 35
StatuSraPPortIerungDer Projektleiter gibt zu jeder Kategorie Antworten auf gezielte Fragen. Die Gewichtung der Antworten variiert von Projektpha-se zu Projektphase. So lässt zum Beispiel das Fehlen von Testfäl-len 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ätsmanage-ments oder des Project Office. Die Fragen zu den Kriterien sind von der Geschäftsdomäne und vom verwendeten Entwick-lungsprozess abhängig.
5.4 TEAMwORk
Zu den wichtigsten Hilfsmitteln für die Kommunikation im Team zählen die Meetings. Neben einer gut strukturierten Einla-
Abb. 7: StatuSÜberSIcht
kategorie
rechtlich auftrag- geber
Qualität termin aufwand gesamt
Ampel R Y R G G R
Status 45 50 40 90 90 21
dung mit Traktanden tragen standardisierte Meeting-Protokolle dazu bei, dass Resultate erzielt und auch festgehalten werden.
kIckoFF-MeetIngDer Startschuss für die Projektmannschaft. Alle Beteiligten be-finden sich im Boot und kennen die Vision, die es zu verwirkli-chen gilt (siehe Kapitel 1).
ProjektMeetIngSSie dienen dem Projektleiter dazu, die Anstrengungen der Mitar-beitenden 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 Pro-jektdatenbank.
StatuSMeetIngSPeriodisch 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 die-nen als Grundlage.
WoRKShoPSSollen ganz bestimmte Resultate gemeinsam erarbeitet werden, bilden Workshops eine ideale Plattform. Sei es, um die Schätz-genauigkeit zu steigern oder um Anforderungen aufzunehmen: Gut vorbereitete Wokshops mit kompetenter Moderation erzeu-gen grosse Wirkung.
Project ManageMent 37
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)? ...
j
j
25
20
auftrag- geber
• Sind die resultate schriftlich ausgehandelt (J/N)? ...
• gibt es beanstandungen: (1) mündlich, (2) schriftlich? ...
n
0
20
50
Qualität • anzahl der besetzten rollen von PM, PL, QM ...
• Fertigstellungsgrad Software Development Plan (%) ...
3
100
0
0
termin • Sind die tätigkeiten den Mitarbeitenden zugeordnet (J/N)? ...
• Wird der Grad der Erfüllug tätigkeiten verfolgt (J/N)? ...
j
j
30
30
aufwand • Ist die aufwandschätzung realistisch (J/N)? ...
• Ist die aufwandplanung aktuell (J/N)? ...
j
j
25
30
Project ManageMent 39
6. AufwANdSChäTZuNG
6.1 SChäTZMEThOdik
Als Basis für die Planung und die Budgetierung muss der Auf-wand des Projekts geschätzt werden. ERNI verwendet eine em-pirische 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äte-re, 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.
Project ManageMent 41
6.2 vORGEhEN
VERWEnDUnGSZWEcK BEStIMMEnDie Aufwandschätzung dient als Basis für verschiedene Pla-nungsaufgaben wie Budget-, Ressourcen- und Iterationspla-nung. Für diese Planungsaufgaben braucht es, je nach Zeitpunkt, einen unterschiedlichen Detaillierungsgrad. Deshalb muss vor dem Schätzen der Verwendungszweck klar sein.
StrukturIerenZuerst 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 Pro-jekts 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 da-mit 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 Pro-jekts zum Beispiel nach Lieferbestandteilen, organisatorischen Bereichen (Teilprojekte) oder fachlichen Bereichen erfolgen.
DIe MethoDe baut auF FoLgenDe MerkMaLe:
• Das Projekt wird in tätigkeiten oder Arbeitspakete geglie-dert. Das führt zu einem besseren Verständnis der Projektauf-gabe.
• Die Schätzung wird von mehreren Beteiligten durchgeführt. Dadurch werden krasse Fehlschätzungen für einzelne aufga-ben 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ätzun-gen 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überschrei-tungen reagieren.
• Die Methode verwendet das Expertenwissen der Projekt-mitarbeiter. Die erfahrungen aus früheren Projekten können formlos übernommen werden.
Project ManageMent 43
Abb. 9: ProjektStrukturPLäne unterSchIeDLIch StrukturIert
Auszug aus PSP, strukturiert nach Tätigkeitsbereichen
Projekt
Projekt- management
Requirement-engineering
Software engineering ….
arbeitspaket
… client Server …
Projekt
client Server Projekt- management
arbeitspaket 1
Requirements-engineering
Softwareengineering … …
Auszug aus PSP, strukturiert nach liefergegenständen
Auszug aus PSP, strukturiert nach Phasen
Phase 1
Requirements Eng.
Projekt
Phase 2
client
arbeitspaket 1
Server
…
Projektmanagement
...
teaMSchätZenDie 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. Eventu-ell 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 un-tereinander und mit früheren Schätzungen verglichen werden.
Project ManageMent 45
SchätZen Von unSIcherheIten unD rISIkenFür jede zu schätzende Aufgabe der Struktur wird ein Bereich ange-geben. 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 uner-warteten 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 Auf-wandschätzung mit einer Bandbreite abgegeben werden. Je unkla-rer 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
beISPIeLe 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 %
Unterscheidung zwischen Unsicherheit und Risiko soll helfen, einen möglichst plausiblen Wert zu erhalten, auch wenn die Un-terscheidung 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 einge-plant und der Risikowert als Reserve gehalten.
Project ManageMent 47
7. RiSikOMANAGEMENT
Was ist ein Risiko? Ein Risiko ist ein mehr oder weniger unwahr-scheinliches Ereignis, dessen Eintreten den geplanten Projekt-verlauf entscheidend behindern kann. Wahrscheinliche Ereig-nisse sollten nicht als Risiko betrachtet werden, sondern in der Planung von Anfang an berücksichtigt werden.
Das Risikomanagement wird an den Anfang des Projektmanage-ments gesetzt und ist ein kontinuierlicher Prozess, der sich über den gesamten Verlauf des Projekts hinwegzieht. Ziel ist es, recht-zeitig Massnahmen zu treffen, um den Schaden für das Projekt möglichst klein zu halten und den Aufwand für die Risikomini-mierung angemessen anzusetzen.
7.1 vORGEhEN
teaM ZuSaMMenSteLLenDie 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 Pro-jekts. Mögliche Teilnehmende sind deshalb der Projektleiter, der Teilprojektleiter, der Softwarearchitekt und eventuell auch ein Vertreter des Auftraggebers.
RISIKoWoRKShoP oRGAnISIEREnIn einem Workshop werden mittels Brainstorming mögliche Risiken identifiziert und aufgelistet. Die Teilnehmenden ent-
Project ManageMent 49
nur im Ansatz lösen. Der Projektleiter übernimmt anschliessend die Ausarbeitung von Detailmassnahmen zu allen Risiken.
MaSSnahMen PLanenDie Massnahmen zur Risikominimierung müssen in die ordent-liche Projektplanung aufgenommen und einzeln an einen Ver-antwortlichen delegiert werden. Der Aufwand für die Umset-zung der Massnahmen wird sinnvollerweise der Projektleitung zugeordnet.
WIRKSAMKEIt Von MASSnAhMEn In StAtUSMEEtInGS PRüFEnDie 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 Risi-kopotenzials wird betrachtet, um die Wirksamkeit der Massnah-men zu beurteilen. Anpassungen der Massnahmen werden ent-sprechend beschlossen und neu geplant.
RISIKoWoRKShoP PERIoDISch WIEDERhoLEnDas Statusmeeting überprüft meist nur die Entwicklung der Risi-ken und der dazugehörenden Massnahmen. Bei längeren Projek-ten 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,
fernen die unwahrscheinlichen Risiken und die Risiken mit kleinem Einfluss aus der Liste. Maximal 20 Risiken werden klas-sifiziert. Zur Unterstützung bietet die untenstehende Tabelle Anregungen für die Identifikation von Risiken.
MaSSnahMen Zu Den rISIken auSarbeIten Für die zehn wichtigsten Risiken werden Massnahmen ausgear-beitet. Diese Aufgabe ist komplex und lässt sich im Workshop
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
Project ManageMent 51
um das Eintreffen von Risiken vorherzusagen. Die Risikoklasse bestimmt die Dringlichkeit der Massnahmen und den vernünf-tigen 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 ge-schätzt. Beides wird in einer Zahl (Skala 1–5) ausgedrückt. Durch Multiplikation wird ein Wert für das Risiko berechnet. Die Risi-ken 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 Pro-jektleiter 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.
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
reaktiveMassnahmen
Sofortmassnahmenplanen
risiko akzeptieren
Präventive Massnahmen
wahrscheinlichkeit
Sch
aden
saus
mas
s
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 Manage-ment 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 Herausforde-rung besteht in der Analyse der Konsequenzen und in der Ablei-tung der notwendigen Massnahmen.
Erkannte Änderungen müssen erfasst, wie normale Projektanforde-rungen analysiert und in der Planung berücksichtigt werden. Wich-tig ist dabei auch das Feedback an die Stakeholder und die Anpas-sung an die Erwartungshaltung in Bezug auf Aufwand und Termin.
8.1 vORGEhEN
ProjektkuLtur ISt änDerungSSenSItIVZu diesem Zweck muss der Projektleiter proaktiv Massnahmen ergreifen, die den Umgang mit Anforderungsänderungen erlau-ben. Er muss unter den Projektmitarbeitenden eine Kultur auf-bauen, die änderungssensitiv ist. Sie sollen Änderungen recht-zeitig als solche erkennen und richtig damit umgehen.
Project ManageMent 55
MaSSnahMen
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 verant-wortliche Person bestimmt, die bis zum nächsten Meeting das notwendige abklärt.
rISIkoabSchätZung
WoRKFLoW BEFoLGEnDer Projektleiter sorgt dafür, dass Änderungen mit dem Formu-lar «Ä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.
entScheIDenDer Ort, wo Änderungen behandelt werden und über die Auswir-kungen 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.
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.
Project ManageMent 57
9. kOMMuNikATiONSfORuM
In einem erfolgreichen Projekt wird intensiv und effizient über die verschiedensten Aspekte des Projekts kommuniziert. Dokumente und Meinungen werden ausgetauscht, Gesprächsrunden entste-hen 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 ha-ben sich auch Stellwände mit Skizzen und Dokumenten in den Arbeitsräumen.
Project coLLaboratIonDie geforderten Projektziele können nur mit einer guten Zusam-menarbeit im Projektteam erreicht werden. Projektteams beste-hen meist aus Personen verschiedener Abteilungen und Firmen an verschiedenen Standorten. Diese virtuellen Teams erfordern zusätzliche Aufmerksamkeit, damit eine gute und schnelle Pro-jektzusammenarbeit 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 ge-nutzt werden sollen. Sollen Dokumente zentral abgelegt oder per Mail verschickt werden? Eine kurze Evaluation der verfügba-ren elektronischen Medien aufgrund der Anforderungen für die Projektzusammenarbeit hilft, Ineffizienzen von Beginn an zu minimieren. Auch für die anschliessende Nutzung der Plattform
Project ManageMent 59
Sinnvollerweise wird der Teambildungsprozess schon vor Be-ginn 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 Zusammen-
arbeit• Definieren von Versionierungsmethodik, Ablagestruktur usw.• Definieren gemeinsamer Verhaltensweisen• Verwenden eines Glossars
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. An-sonsten bleiben die Teammitglieder ihrem eigenen Arbeitsum-feld verbunden und betrachten die virtuelle Teamarbeit mit ei-ner gewissen inneren Distanz. Das Präsenztreffen hilft, die Dis-tanz zu verringern.
Gemeinsame Verhaltensregeln helfen, das Vertrauen in der Zu-sammenarbeit aufrechtzuerhalten. So kann zum Beispiel verein-bart werden, dass nur in persönlichen Gesprächen auf Schwie-rigkeiten oder Fehler anderer aufmerksam gemacht wird und nicht per E-Mail, da diese Form der Kommunikation sehr anfäl-lig für Missverständnisse ist.
Besonders gefährdet ist die Zusammenarbeit, wenn projektfer-ne Verpflichtungen zu Loyalitätskonflikten führen. Eine Rege-lung, 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 Missver-ständnisse aufgrund unterschiedlicher Interpretation von Fach-begriffen. Ein Glossar hilft, hier Klarheit zu schaffen.
Project ManageMent 61
10. GlOSSAR
anForDerungenDie Anforderungen bestimmen im Detail, was als Endergebnis ei-nes Projekts vorliegen muss. Anforderungen an ein zu entwickeln-des System werden oft in funktionale (benutzerorientierte, techni-sche) und nichtfunktionale (Leistungs- und Qualitätsmerkmale) Anforderungen gegliedert.
arteFaktBeliebiges Projektdokument oder Teil eines Dokuments. Bezeich-net das Resultat (z.B. Use Case Model) und nicht das eigentliche Dokument.
auFtraggeberRolle im Projekt. Der Auftraggeber ist die oberste Instanz im Pro-jekt. Meist ist er auch der Sponsor.
AUFWAnDBezeichnet sowohl Zeit wie auch Geld.
change reQueSt ManageMentProzess, der die Änderung der Anforderungen und die daraus resul-tierenden Konsequenzen regelt.
checkLISteAufgabenliste, die einer einfachen Anleitung entspricht und zur Überprüfung der Vollständigkeit eines Vorgehens verwendet wird.
Project ManageMent 63
PoSt-PRojEct REVIEWReview nach Abschluss des Projekts. Dient als Gefäss, um «lessons learned» zu erfassen.
ProjektLeIterFührungsrolle im Projekt. Je nach Projektorganisation sind die Aufgaben und Kompetenzen unterschiedlich weit gefasst. Ein Pro-jekt kann auch die Hierarchie der Projektleiter definieren.
ProjektorganISatIonDarstellung der verschiedenen Rollen im Projekt, ihrer Unterstel-lungsverhältnisse, ihrer Beziehung zueinander und ihrer personel-len Besetzung.
QuaLItätSManagerRolle im Projekt. Der Qualitätsmanager ist Teil der Projektorgani-sation, aber nicht dem Projektleiter unterstellt. Seine Aufgabe ist es, die Einhaltung der Anforderungen aus dem Qualitätssystem sicherzustellen.
reSSourceBezeichnet 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.
conFIguratIon ManageMent tooLWerkzeug zur Unterstützung des Configuration Managements.
gantt-chartDetaillierte grafische Darstellung der Tätigkeiten im Projekt. Zeigt den zeitlichen Ablauf sowie eventuell Abhängigkeiten und die Ver-antwortlichkeiten.
InkreMenteLLBedeutet: 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.
IteratIVBedeutet: wiederholt, immer gleich ablaufend (Prozessschritte). Damit drückt man aus, dass ein Prozessablauf mehrfach durchlau-fen wird.
kIckoFF-MeetIngWichtiges 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.
PLanungTätigkeit bzw. Resultat, das ein Modell der Zukunft darstellt. Be-zieht sich auf jede vorausschauende Tätigkeit, nicht nur auf die Modellierung des zeitlichen Ablaufs (Projektplanung).
Project ManageMent 65
rISIkoEin 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 Wahrscheinlich-keit des Eintreffens und dem potenziellen Schadensausmass.
SPonSorRolle im Projekt. Der Sponsor kann Teil der Projektorganisation sein. Er bestimmt über das Budget und über eventuelle Nachträge.
StakehoLDerInteressensvertreter, allgemein. Jeder, der ein Interesse am Gelin-gen des Projekts hat oder von dessen Auswirkungen betroffen ist.
teMPLateVorlage für ein Dokument, das nebst formalen Vorgaben auch in-haltliche Anhaltspunkte gibt.
uSe caSeEin Use Case, auch Anwendungsfall genannt, bezeichnet eine zu-sammengehörende Anzahl von Schritten, die ein User mit einem System ausführt, um zu einem für ihn wertvollen Resultat zu kom-men. Use Cases stellen im modernen Software-Entwicklungspro-zess unteilbare Anforderungen dar, die sich unabhängig voneinan-der planen, spezifizieren, implementieren und testen lassen.
WoRKShoPMeeting, in dem die Teilnehmenden gemeinsam ein Resultat erar-beiten.
Project ManageMent 66
enables & deliverswww.erni-consultants.com