ERNI Essentials - Projektmanagement

of 34/34
ERNI ESSENTIALS PROJECT MANAGEMENT
  • date post

    10-Mar-2016
  • Category

    Documents

  • view

    219
  • download

    2

Embed Size (px)

description

 

Transcript of ERNI Essentials - Projektmanagement

  • Project ManageMent 1ernI eSSentIaLSPROJECT MANAGEMENT

  • Project ManageMent 3

    EiNfhRuNG 2

    1. EiNlEiTuNG 5

    2. PROJEkT-STARTuP 11

    2.1 Das Projekthandbuch:

    die checkliste fr 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. AufwANdSChTZuNG 39

    6.1 Schtzmethodik 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 Bndeln und Umsetzen der relevanten

    Stakeholderbedrfnisse.

    Ein entscheidender Erfolgsfaktor ist die

    Projektfhrung. Vieles hngt von der

    Arbeitsweise, der Voraussicht und der

    Erfahrung des Projektleiters ab. Genauso

    wichtig sind seine Kommunikationsfhig-

    keit sowie die Sozialkompetenz, ein Team

    zu fhren 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 tglichen

    Arbeit untersttzen und zu einem erfolg-

    reichen Projektabschluss fhren.

    ernI Innovation in Process and technology

    EiNfhRuNG

    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 hngt weitgehend von der Fhigkeit des Projektleiters ab, zwangslufig 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 hngt davon ab, ob er seine Rolle richtig versteht.

    Abb. 1: Der ProjektLeIter aLS koMMunIkatIonSDrehScheIbe

    Project Manager

    externe Lieferanten

    Projekt-mitarbeitende

    auftraggeber

    geschftsleitung

    Zulassungsstelle

    It controller

    benutzer

    tester

  • Project ManageMent 7

    Die Ttigkeiten 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 frh zu erkennen.

    Planen ist mehr, als nur ein Gantt-Chart (Balkendiagramm) zu zeichnen. Es geht um das Antizipieren der Zukunft. Dazu verfei-

    Abb. 2: hauPtttIgkeIten DeS ProjektLeIterS

    analysierenStrukturieren

    Problemelsen

    PriorisierenPlanen

    berwachen

    kommunizieren

    nert man die Ziele des Projekts und verteilt sie auf verschiedene Schlsselmomente (Meilensteine) auf der Zeitachse des Projekts. Anschliessend wird definiert, welche Schritte unternommen werden mssen, um diese Einzelziele zu erreichen. Daraus lassen sich die anstehenden Massnahmen ableiten. Als Nchstes nimmt man die Risikoanalyse vor, um weitere Massnahmen zu identifizieren. Daraus entsteht eine vollstndige Planung, die auch die Randbedingungen und die Schnittstellen zu anderen Organisationen bercksichtigt.

    Die Planung muss allen Beteiligten kommuniziert werden. Es lohnt sich auch, zu prfen, 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 geknpft sein. Inwieweit Ttigkeiten und Massnahmen erfllt sind, sollte man auch inhaltlich pr-fen. Statusmeldungen sind zu hinterfragen. Auf diese Weise wird die Fortschrittskontrolle zu einem Fhrungsinstrument 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 lsst sich dagegen oft eine Lsung finden (siehe Kasten Problemlsungs-strategie).

  • Project ManageMent 9

    Fragen Zur SItuatIonSanaLySe

    Welche Informationen ber den Status des Projekts stehen zur Verfgung?

    Was haben wir bisher erreicht? Was sollten wir gemss Plan bis heute erreicht haben? Was sind die Grnde fr festgestellte Planabweichungen? Welches sind momentan die grssten Risiken?

    ProbLeMLSungSStrategIe

    Ursachen des Problems analysieren. Einfache Massnahmen im eigenen Verantwortungsbereich

    sofort umsetzen. Ursachen bei projektexternen Stellen mit den Verantwortli-

    chen besprechen. Lngerfristige Massnahmen planen. Alternativen planen, falls die Massnahmen das Problem

    nicht lsen (Contingency Planning). Risikoanalyse anpassen unter Bercksichtigung des

    bestehenden Problems.

  • Project ManageMent 11

    2. PROJEkT-STARTuP

    2.1 dAS PROJEkThANdbuCh: diE ChECkliSTE fR dEN PROJEkTlEiTER

    Die grssten Belastungen des Projektleiters finden, wie Abbil-dung 3 zeigt, jeweils am Anfang und am Ende des Projekts statt oder bei grsseren 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 fr eine Kon-solidierung des Projektstatus in seinem Portfolio.

    2.2 vORGEhEN

    Wie bei einer Checkliste blich, fngt 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 kLrt FoL-genDe theMen ab:

    Projektziele. Die Absicht des Auftraggebers ist massgebend. Projektrisiken. Der Projektleiter identifiziert und beurteilt die

    wichtigsten risiken. Lsungsansatz. Im team und in Absprache mit dem Auftragge-

    ber wird die Vorgehensweise mit dem grssten erfolgspotenzial, welche die randbedingungen einhlt, 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 fllt die notwendigen Entscheide. Die Resultate werden im PHB fest-gehalten. So entsteht ein Regelwerk fr das Projektteam und an-dere Beteiligte, das alle Vorgaben im Projekt dokumentiert. Das PHB ist ein Dokument-Template, das Textvorgaben und Beispiel-lsungen zur Verfgung stellt. Damit wird der Projektleiter ge-fhrt und durch Kommentare angeleitet.

    FhrungSInStruMent Fr Den auFtraggeber Der Auftraggeber erhlt 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 Lsungsstrategie Erwartete Ergebnisse und Meilensteine Projektorganisation Kommunikationswege Aufgaben und Verantwortlichkeiten Planung change Management

  • Project ManageMent 15

    VernDerbarkeIt Der ergebnISSe IM ProjektabLauFBei den Entscheidungen sollte man sich immer berlegen, ob eine einfachere Regelung mglich ist und ob die Betroffenen die-se Regel als Untersttzung oder als Behinderung empfinden. Die Kunst besteht darin, nicht alles regeln zu mssen, sondern nur das Wichtigste.

    REVIEW UnD ABnAhMEWenn die erste Version des PHB geschrieben ist, empfiehlt sich ein Review durch den Qualittsmanager (QM) des Projekts. Da-nach sollte die abschliessende Abnahme durch den Auftragge-ber, der ja auch schon mitgearbeitet hat, eingeholt werden. Im

    Abb. 4: VernDerbarkeIt 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 Gefss, 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 fr das Kickoff.

    DetaILS abkLrenDas PHB enthlt an den wichtigen Orten Kommentare und Bei-spiele, um das Verstndnis zu frdern. 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 Gesprche mit den Beteiligten gefunden und nicht aus-schliesslich durch intensives Denken. Folgendes darf nicht ver-gessen werden: Definierte Regelungen und getroffene Entschei-dungen ntzen nur etwas, wenn man sie kommuniziert. Das heisst konkret: raus aus dem Bro und mit Stakeholdern, Liefe-ranten, Projektmitarbeitenden und Know-how-Trgern 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. untersttzt.

    Zum Abschluss wird das PHB im Post-Project Review hinterfragt, und die getroffenen Regelungen werden auf ihre Tauglichkeit geprft. Somit erhlt man neue Ideen fr das PHB im nchsten 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 knnen sich alle Projektbeteiligten leicht merken.

    ZIeLharMonISIerungOft wird die Zielvereinbarung vernachlssigt, weil man denkt, dass die Ziele jedem klar seien. Erfahrungsgemss 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 besttigen lassen.

    DaS ZIeL beSchreIbt eInen ...

    ... gedanklich vorweggenommenen, zuknftigen Zustand, der bewusst ausgewhlt und gewnscht und durch aktives handeln erreicht wird.

  • Project ManageMent 21

    InhaLte Der ZIeLhIerarchIe

    Mit wenigen Zielen auf den hheren Ebenen kann die riesige Menge von Detailanforderungen gebndelt 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 pltzlich neue Anforderun-gen (feature creeps), gibt es ein Mittel, sie zu sieben. jede anforderung muss den bergeordneten Zielen gengen. jedes bergeordnete Ziel muss durch konkrete anforderungen abgedeckt sein.

    checkLISte Fr ZIeLVereInbarungen

    schriftlich fixiert klar und nachvollziehbar messbar vollstndig widerspruchsfrei realisierbar allen beteiligten bekannt akzeptiert

    ZIELVEREInBARUnGS-WoRKShoPDie Durchfhrung eines halbtgigen Zielvereinbarungs-Work-shops ist ein bewhrtes 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 Entscheidungstrger an den Tisch zu bekommen. Man soll sich auch nicht wundern, wenn man unter Umstnden whrend 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, mssen 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, geschftsidee

    Produktbeschreibung: eine Liste von Merkmalen

    Stakeholder: kunden-wnsche, 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 gewhlte Zie-le stellen Erfolgsfaktoren fr 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-tten fr 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 Ttigkeiten in Bezug auf ihren Start und ihr Ende sowie auf die Abhngigkeiten untereinander.

    Dazu kommen noch Parameter wie eingesetzte Ressourcen, Mei-lensteine und die Gruppierung von Ttigkeiten.

    koMMunIkatIonSMItteLDer Projektplan ist ein hervorragendes Kommunikationsmittel. Aus ihm ersehen alle Projektmitarbeitenden den Zeitpunkt und die vorgesehene Dauer ihrer Ttigkeiten. Zudem sehen sie, mit wem sie sich koordinieren mssen. Deshalb sollte der Projekt-plan breit verteilt und diskutiert werden.

    baSIS Fr anPaSSungenWhrend der Planung machen sich der Projektleiter und sein Team Gedanken ber unbekannte Gefahren und Risi-ken. Treten whrend des Projekts grosse unerwartete Schwie-rigkeiten auf, so hilft der Plan beim Abschtzen von Konse-quenzen. Man kann Abhngigkeiten zwischen Aktivitten 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

    Fr jeDe PhaSe Legt Man FoLgenDeS FeSt:

    Beschreibung der Phase und ihrer Ziele Anzahl der Iterationen Start- und Endtermine der Phasen und Iterationen

    Fr jeDe IteratIon Legt Man FoLgenDeS FeSt:

    Anzugehende Risiken Zu implementierende Arbeitspakete beziehungsweise Use cases

    kann Szenarien darstellen und einen Entscheid fr die wei-tere Arbeit treffen. Der Projektplan verndert sich im Pro-jektverlauf.

    4.2 vORGEhEN

    StrukturIerenWer ein grosses Vorhaben anpacken will, muss es in Teilpa-kete herunterbrechen. Diese knnen einzeln geplant, organi-siert und bewltigt werden. Es hat sich bewhrt, 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, Aufwandschtzung).

    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 bewhrt sich, am Ende einer Phase die Detailplanung der nchsten 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 Realitt 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 Kommandobrcke. Drei Bereiche mssen 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 frhzeitig 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 Einschtzung noch bentigte Arbeitszeit bis zur Fertigstellung. Ebenfalls melden sie Probleme oder Schwierig-keiten, die aufgetaucht sind. In einem festen Intervall werden berwachungsdiagramme und Berichte zu Ttigkeiten und Ressourcen aktualisiert und kommuniziert. Mit dieser Ge-samtsicht knnen dann korrigierende Massnahmen eingelei-tet werden.

    Besondere Beachtung bentigen alle Vorgnge, die auf dem kri-tischen Pfad liegen. Das heisst all jene Vorgnge, die vom Start bis zum Ende des Projekts mit minimalen Pufferzeiten in einer Kette liegen. Verzgerungen an einem dieser Vorgnge 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), mssen 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 Grnen. Der Statusre-port gibt einen fr alle Projekte standardisierten Zustandsbericht.

    tEAMWoRKDen grSSten ProjekterFoLg bILDet DaS teaM.Projektarbeit ist Teamarbeit. Teams mssen aktiv durch den Pro-jektleiter entwickelt, motiviert und gefrdert werden. Motivierte Teams erbringen Hchstleistungen.

    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 tatschlich anfallenden Aufwnde und die bentigte Zeitdauer werden mit der Schtzung verglichen.

    Die Projektmitarbeitenden melden zu den ihnen zugeteilten Vorgngen 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 lsst zum Beispiel das Fehlen von Testfl-len in der Startphase des Projekts die Ampel Qualitt nicht auf Rot wechseln, was in der Konstruktionsphase jedoch der Fall wre. Die Ausarbeitung der Fragen, wie im Beispiel in Abbildung 8, ist Aufgabe einer Kontrollstelle wie des Qualittsmanage-ments oder des Project Office. Die Fragen zu den Kriterien sind von der Geschftsdomne und vom verwendeten Entwick-lungsprozess abhngig.

    5.4 TEAMwORk

    Zu den wichtigsten Hilfsmitteln fr die Kommunikation im Team zhlen die Meetings. Neben einer gut strukturierten Einla-

    Abb. 7: StatuSberSIcht

    kategorie

    rechtlich auftrag- geber

    Qualitt 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 fr 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 erlutert, und gemeinsam werden bei etwaigen Problemen Massnahmen definiert und eingeplant. Als ideales Hilfsmittel dienen hier die Excel-Reports aus der Pro-jektdatenbank.

    StatuSMeetIngSPeriodisch prsentiert der Projektleiter dem Auftraggeber den Projektstatus. Hier wird das Vertrauen, das der Auftraggeber dem Projektteam schenkt, bestrkt 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 Schtz-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 Vertrge mit unterlieferanten (J/N)? ...

    j

    j

    25

    20

    auftrag- geber

    Sind die resultate schriftlich ausgehandelt (J/N)? ...

    gibt es beanstandungen: (1) mndlich, (2) schriftlich? ...

    n

    0

    20

    50

    Qualitt anzahl der besetzten rollen von PM, PL, QM ...

    Fertigstellungsgrad Software Development Plan (%) ...

    3

    100

    0

    0

    termin Sind die ttigkeiten den Mitarbeitenden zugeordnet (J/N)? ...

    Wird der Grad der Erfllug ttigkeiten verfolgt (J/N)? ...

    j

    j

    30

    30

    aufwand Ist die aufwandschtzung realistisch (J/N)? ...

    Ist die aufwandplanung aktuell (J/N)? ...

    j

    j

    25

    30

  • Project ManageMent 39

    6. AufwANdSChTZuNG

    6.1 SChTZMEThOdik

    Als Basis fr die Planung und die Budgetierung muss der Auf-wand des Projekts geschtzt werden. ERNI verwendet eine em-pirische Methode, die Min-Max-Methode. Diese basiert auf der Erfahrung der Schtzer und verwendet eine Systematik, um grobe Fehleinschtzungen zu vermeiden. Zu bedenken ist, dass es keine richtige oder falsche Schtzung gibt, da der spte-re, tatschliche Aufwand von vielen Faktoren beeinflusst wird. Schtzen ist somit nicht mit Messen zu vergleichen. Es geht nur darum, mglichst vernnftige Annahmen fr die Planung zu erhalten.

  • Project ManageMent 41

    6.2 vORGEhEN

    VERWEnDUnGSZWEcK BEStIMMEnDie Aufwandschtzung dient als Basis fr verschiedene Pla-nungsaufgaben wie Budget-, Ressourcen- und Iterationspla-nung. Fr diese Planungsaufgaben braucht es, je nach Zeitpunkt, einen unterschiedlichen Detaillierungsgrad. Deshalb muss vor dem Schtzen 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 schtzen und handhaben lassen. Das Ergebnis dieser Arbeit ist ein Projektstrukturplan (PSP). Auf der untersten Ebene sind da-mit alle notwendigen Arbeiten (Arbeitspakete) aufgefhrt, die zur Erreichung des Projektziels ntig sind. Auf dieser Ebene knnen jetzt die Aufwnde sinnvoll geschtzt 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 ttigkeiten oder Arbeitspakete geglie-dert. Das fhrt zu einem besseren Verstndnis der Projektauf-gabe.

    Die Schtzung wird von mehreren Beteiligten durchgefhrt. Dadurch werden krasse Fehlschtzungen fr einzelne aufga-ben verhindert, weil es statistisch unwahrscheinlich ist, dass mehrere Leute denselben Fehler machen.

    Die Schtzungen werden vom Projektteam gemacht. Daraus entsteht ein commitment zum geschtzten aufwand.

    Die Einzelresultate werden im team besprochen. Dadurch werden die klaren Flle und die kritischen Schtzun-gen identifiziert. Letztere werden genauer unter die Lupe genommen und neu geschtzt. Das Verstndnis fr die Projektaufgabe steigt weiter.

    Es wird nicht nur der best case geschtzt. Unsicherheit und risiko werden in der Schtzung separat bercksichtigt. aus den Zahlen kann interpretiert werden, wie genau die Schtzung ist.

    Die Methode liefert Angaben ber Planungsreserven. Der Projektleiter kann spter bei einzelnen aufwandberschrei-tungen reagieren.

    Die Methode verwendet das Expertenwissen der Projekt-mitarbeiter. Die erfahrungen aus frheren Projekten knnen formlos bernommen werden.

  • Project ManageMent 43

    Abb. 9: ProjektStrukturPLne unterSchIeDLIch StrukturIert

    Auszug aus PSP, strukturiert nach Ttigkeitsbereichen

    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 liefergegenstnden

    Auszug aus PSP, strukturiert nach Phasen

    Phase 1

    Requirements Eng.

    Projekt

    Phase 2

    client

    arbeitspaket 1

    Server

    Projektmanagement

    ...

    teaMSchtZenDie Schtzer sollten Teammitglieder sein, die an der Erarbeitung der Projektziele beteiligt sind. Jeder Schtzer erhlt das Schtz-Template, das der Projektleiter vorgngig mit der gewhlten Struktur ausgefllt hat.

    Jeder Schtzer schtzt fr sich jede Position als Vorbereitung fr den Workshop. Absprachen sind nicht erlaubt. Im Workshop wird Position fr Position durchgegangen, und das Team einigt sich auf einen Schtzwert. Wo die Abweichungen der einzelnen Schtzungen hoch sind, werden die Ursachen erforscht. Eventu-ell mssen dann detaillierte Abklrungen geplant werden. Im Workshop wird nach der ersten Konsensfindung das Resultat auf Plausibilitt getestet. Das geschieht, indem die Teilresultate un-tereinander und mit frheren Schtzungen verglichen werden.

  • Project ManageMent 45

    SchtZen Von unSIcherheIten unD rISIkenFr jede zu schtzende Aufgabe der Struktur wird ein Bereich ange-geben. Wir schtzen fr die Aufgabe a zwischen x und y Tage an Aufwand. Der Wert x gibt das Minimum, der Wert y das Maximum des geschtzten Aufwands fr den Normalfall an, falls keine uner-warteten Probleme auftauchen. Die Angabe von zwei Werten statt nur einem gibt dem Schtzer die Mglichkeit, seine Unsicherheit auszudrcken. Damit kann dann auch fr das Projekt eine Auf-wandschtzung 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 zustzlich als Risiko geschtzt. Diese

    beISPIeLe Fr PLauSIbILIttSteStS

    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 1015 % Elaboration 1520 % construction 4050 % transition 1525 %

    Unterscheidung zwischen Unsicherheit und Risiko soll helfen, einen mglichst plausiblen Wert zu erhalten, auch wenn die Un-terscheidung im Einzelfall nicht genau begrndet werden kann. Es ist dem Schtzer berlassen, was er als Unsicherheit und was er als Risiko betrachtet. Bei der spteren Planung wird nur der mittlere Aufwand ohne Risiko fr 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 bercksichtigt 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 fr das Projekt mglichst klein zu halten und den Aufwand fr die Risikomini-mierung angemessen anzusetzen.

    7.1 vORGEhEN

    teaM ZuSaMMenSteLLenDie Identifikation von Risiken ist ein kreativer Prozess, der im Team einfacher zu bewltigen ist. Die Aufgabe verlangt von den Akteuren eine bersicht ber mglichst viele Belange des Pro-jekts. Mgliche Teilnehmende sind deshalb der Projektleiter, der Teilprojektleiter, der Softwarearchitekt und eventuell auch ein Vertreter des Auftraggebers.

    RISIKoWoRKShoP oRGAnISIEREnIn einem Workshop werden mittels Brainstorming mgliche Risiken identifiziert und aufgelistet. Die Teilnehmenden ent-

  • Project ManageMent 49

    nur im Ansatz lsen. Der Projektleiter bernimmt anschliessend die Ausarbeitung von Detailmassnahmen zu allen Risiken.

    MaSSnahMen PLanenDie Massnahmen zur Risikominimierung mssen in die ordent-liche Projektplanung aufgenommen und einzeln an einen Ver-antwortlichen delegiert werden. Der Aufwand fr die Umset-zung der Massnahmen wird sinnvollerweise der Projektleitung zugeordnet.

    WIRKSAMKEIt Von MASSnAhMEn In StAtUSMEEtInGS PRFEnDie Wirksamkeit der Massnahmen, das heisst die Verminderung des Risikos, wird im Statusmeeting berprft. Dazu werden die Risiken wie im Workshop klassifiziert. Die Vernderung 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 berprft meist nur die Entwicklung der Risi-ken und der dazugehrenden Massnahmen. Bei lngeren 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 fr 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 Untersttzung bietet die untenstehende Tabelle Anregungen fr die Identifikation von Risiken.

    MaSSnahMen Zu Den rISIken auSarbeIten Fr die zehn wichtigsten Risiken werden Massnahmen ausgear-beitet. Diese Aufgabe ist komplex und lsst sich im Workshop

    kLaSSISche rISIkotyPen

    Anforderungen, Projektrahmen Projektziele unklar oder nderung der Projektziele

    im Projektverlauf Unklare, ungengende oder mehrdeutige Anforderungen nderungen in Projektrahmen oder Systemabgrenzung

    lsungsstrategie teile der Strategie lassen sich nicht realisieren Lieferanten oder Schlsselmitarbeitende fallen aus Abhngigkeiten

    Projektorganisation Mitarbeitende und ihre Fhigkeiten Unklare, ungengende 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 vernnf-tigen Aufwand fr die Risikominimierung.

    Das Risiko setzt sich zusammen aus dem mglichen Schaden und der Wahrscheinlichkeit des Eintretens des Ereignisses. Da es meist schwierig ist, das Risiko direkt einzuschtzen, werden die Wahrscheinlichkeit und der mgliche Schaden separat ge-schtzt. Beides wird in einer Zahl (Skala 15) ausgedrckt. Durch Multiplikation wird ein Wert fr das Risiko berechnet. Die Risi-ken knnen anhand dieses Wertes geordnet werden.

    7.3 RiSikObEhANdluNG

    Fr DIe rISIkobehanDLung knnen 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 fr 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 knnen geplant werden (immediate action).

    Abb. 10: rISIkoMatrIx

    reaktiveMassnahmen

    Sofortmassnahmenplanen

    risiko akzeptieren

    Prventive Massnahmen

    wahrscheinlichkeit

    Sch

    aden

    saus

    mas

    s

  • Project ManageMent 53

    8. ChANGE REquEST MANAGEMENT

    In jedem Projekt gibt es nderungen! Der Projekterfolg hngt vom richtigen Umgang mit ihnen ab. Change Request Manage-ment ist die Kunst, mit nderungen richtig umzugehen. Nicht jede nderung stellt prinzipiell ein Risiko fr das Projekt dar. Oft handelt es sich dabei um eine normale Begleiterscheinung. Mit nderungen sind Fehler, neue oder genderte Anforderungen sowie notwendige Designnderungen 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 mssen erfasst, wie normale Projektanforde-rungen analysiert und in der Planung bercksichtigt 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 Anforderungsnderungen 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. regelmssige change Management Meetings ansetzen.2. nderungsantrge sammeln und auf Vollstndigkeit prfen.3. Liste der nderungsantrge mit den neuen nderungsantrgen

    ergnzen und mit der einladung zum change Management Meeting verschicken.

    4. Fr jeden nderungsantrag den aufwand pro team respektive Subsystem abschtzen (Architekt resp. Entwickler).

    5. Priorisierung der nderungsantrge an einem gemeinsamen Meeting.

    6. entscheiden, welche nderungsantrge mit den verfgbaren ressourcen in der nchsten Iteration behandelt werden knnen. ergnzung der Planung durch den Projektleiter.

    7. Fr nicht beurteilbare nderungsantrge wird eine verant-wortliche Person bestimmt, die bis zum nchsten Meeting das notwendige abklrt.

    rISIkoabSchtZung

    WoRKFLoW BEFoLGEnDer Projektleiter sorgt dafr, 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 Fr 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 durchgefhrt.

  • 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, Gesprchsrunden entste-hen ad hoc und lsen Probleme, die latent vorhanden sind. Wie kann nun ein Projektleiter diesen Informationsaustausch frdern?

    Mglichkeiten, die informelle Kommunikation zu gestalten, sind ein guter Teamgeist oder Kaffeepausen. Gut bewhrt ha-ben sich auch Stellwnde mit Skizzen und Dokumenten in den Arbeitsrumen.

    Project coLLaboratIonDie geforderten Projektziele knnen 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 zustzliche 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 fr welchen Einsatz verwendet und ge-nutzt werden sollen. Sollen Dokumente zentral abgelegt oder per Mail verschickt werden? Eine kurze Evaluation der verfgba-ren elektronischen Medien aufgrund der Anforderungen fr die Projektzusammenarbeit hilft, Ineffizienzen von Beginn an zu minimieren. Auch fr die anschliessende Nutzung der Plattform

  • Project ManageMent 59

    Sinnvollerweise wird der Teambildungsprozess schon vor Be-ginn der fachlichen Arbeit gestartet.

    Project coLLaboratIon

    Prsenztreffen zum Strken des Wir-Gefhls Auswhlen 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 Prsenztreffen zum Aufbau eines Wir-Gefhls. An-sonsten bleiben die Teammitglieder ihrem eigenen Arbeitsum-feld verbunden und betrachten die virtuelle Teamarbeit mit ei-ner gewissen inneren Distanz. Das Prsenztreffen 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 persnlichen Gesprchen auf Schwie-rigkeiten oder Fehler anderer aufmerksam gemacht wird und nicht per E-Mail, da diese Form der Kommunikation sehr anfl-lig fr Missverstndnisse ist.

    Besonders gefhrdet ist die Zusammenarbeit, wenn projektfer-ne Verpflichtungen zu Loyalittskonflikten fhren. 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 knnen.

    In heterogenen Projektteams entstehen auch schnell Missver-stndnisse 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 Qualittsmerkmale) 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 berprfung der Vollstndigkeit eines Vorgehens verwendet wird.

  • Project ManageMent 63

    PoSt-PRojEct REVIEWReview nach Abschluss des Projekts. Dient als Gefss, um lessons learned zu erfassen.

    ProjektLeIterFhrungsrolle 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-lungsverhltnisse, ihrer Beziehung zueinander und ihrer personel-len Besetzung.

    QuaLIttSManagerRolle im Projekt. Der Qualittsmanager ist Teil der Projektorgani-sation, aber nicht dem Projektleiter unterstellt. Seine Aufgabe ist es, die Einhaltung der Anforderungen aus dem Qualittssystem sicherzustellen.

    reSSourceBezeichnet die notwendigen Mittel fr die Durchfhrung einer Aufgabe oder eines Projekts. Meist werden personelle Ressourcen und Sachmittel unterschieden.

    REVIEWberprfung eines Zwischenresultats aus dem Projekt durch andere als den Autor. Die Form und das Vorgehen knnen stark variieren.

    conFIguratIon ManageMent tooLWerkzeug zur Untersttzung des Configuration Managements.

    gantt-chartDetaillierte grafische Darstellung der Ttigkeiten im Projekt. Zeigt den zeitlichen Ablauf sowie eventuell Abhngigkeiten und die Ver-antwortlichkeiten.

    InkreMenteLLBedeutet: anwachsend, sich evolutionr entwickelnd. Damit drckt man aus, dass am Schluss jeder Iteration eine lauffhige Version vorliegt, die vollstndiger ist (mehr Anforderungen abdeckt) als die vorhergehende Version.

    IteratIVBedeutet: wiederholt, immer gleich ablaufend (Prozessschritte). Damit drckt 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.

    PLanungTtigkeit bzw. Resultat, das ein Modell der Zukunft darstellt. Be-zieht sich auf jede vorausschauende Ttigkeit, nicht nur auf die Modellierung des zeitlichen Ablaufs (Projektplanung).

  • Project ManageMent 65

    rISIkoEin Risiko ist ein mgliches, knftiges, ungeplantes, unerwartetes, negatives Ereignis, dessen Eintreten zu unerwnschten Folgen fhrt. 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 Nachtrge.

    StakehoLDerInteressensvertreter, allgemein. Jeder, der ein Interesse am Gelin-gen des Projekts hat oder von dessen Auswirkungen betroffen ist.

    teMPLateVorlage fr ein Dokument, das nebst formalen Vorgaben auch in-haltliche Anhaltspunkte gibt.

    uSe caSeEin Use Case, auch Anwendungsfall genannt, bezeichnet eine zu-sammengehrende Anzahl von Schritten, die ein User mit einem System ausfhrt, um zu einem fr ihn wertvollen Resultat zu kom-men. Use Cases stellen im modernen Software-Entwicklungspro-zess unteilbare Anforderungen dar, die sich unabhngig 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