ERNI Essentials - Projektmanagement

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


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


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).


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.


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


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


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.


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.


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.


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)


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.


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


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.


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.


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


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


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 auftraggeber

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.


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

auftraggeber

• 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


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.


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.


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.


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.


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-


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


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


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.


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.


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


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.


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.


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).


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.


enables & deliverswww.erni-consultants.com

Documents

ERNI Essentials - Projektmanagement