View
3
Download
0
Category
Preview:
Citation preview
Programmierung verteilter Systeme LabInstitut für InformatikUniversität AugsburgUniversitätsstraße 14, 86159 AugsburgTel.: (+49) 821/598-2174, Fax: -2175URL: http://www.informatik.uni-augsburg.de/vs
Bernhard Bauer
Projektmanagement: Einführung
2
Ziele der Vorlesung
Lernziele: Die Studierendensind in der Lage, sich in einem Projekt zu orientierenkönnen konstruktiv in einem Projekt mitarbeitenhaben das theoretische Wissen, eine Projektleitung auszuüben
Ziel der Vorlesung ist die Einführung in die grundlegenden Aufgaben und Techniken
des IT-Projektmanagements. Der Fokus der Übungen liegt auf der praktischen Anwendung und Umsetzung von Projektmanagement-Inhalten.Projektmanagement ist zu großen Teilen eine praktische Fertigkeit.
Projektmanagement M1 -
Einführung
3
Übersicht
EinführungProjektvorbereitungProjektplanungProjektkontrolle und –steuerungQualitätsmanagement und ProzessverbesserungEthische Leitlinien im Software Engineering
Projektmanagement M1 -
Einführung
4
Literatur
H. Balzert: Lehrbuch der Software-Technik, Band 2, Spektrum Akademischer Verlag, 2002I. Sommerville: Software Engineering. Pearson, 2006.U. Witschi, A. Erb, R. Biagini, Projekt-Management: Der BWI-Leitfaden zu Teamführung und Methodik. Verlag Industrielle Organisation Zürich, 1996T. DeMarco, T. Lister: Wien wartet auf Dich. Der Faktor Mensch im DV-Management.Tom DeMarco. Peopleware: Productive Projects and Teams. B&T, 1999. Tom DeMarco. Der Termin. Hanser Wirtschaft, 2005.
Projektmanagement M1 -
Einführung
5
Folien und Skripte
Bernhard Schätz: Vorlesung Projektorganisation und Management, Leopold-Franzens Universität Innsbruck, Sommersemester 2003Bernhard Bauer: Vorlesungsfolien Projektmanagement. 2006Gerhard Pews: Vorlesung Projektmanagement, Universität Kaiserslautern, Wintersemester 2005/06 Martin Wirsing: Vorlesung Projektmanagement 2007
Projektmanagement M1 -
Einführung
6
Wo sind wir: Welt der Softwaretechnik
Technik-Katastrophen:September 1999: Verlust der Sonde "Mars Climate Orbiter" wegen
falscher Einheitenumrechnung1985-1987 Therac 25 (Strahlengerät zur Krebsbehandlung): Fehlerhafte Programmierung führt zu Verbrennungen und Todesfällen
Finanzielle Katastrophen:1990 AT&T Telefonverbindung zwischen Ost- und Westküste der USA
wg eines SW-Fehlers für mehr als 24 Std unterbrochen: ca. 1 Mia US-$1992: Integration des Reservierungssystems SABRE mit anderen Reservierungssystemen abgebrochen: 165 Mio. US-$1996 Dtsche Telecom: “1. Januar 1996 ist kein Feiertag”: >50 Mio DM
Terminkatastrophen:1994: Eröffnung des Denver International Airport um 9 Monate verzögert
wegen Softwareproblemen im Gepäcktransport-System2003: Einführung des LKW-Mautsystems in Deutschland verzögert sich um 18 Monate
Projektmanagement M1 -
Einführung
7
Erfolgreiche und gescheiterte IT-Projekte
Erfolgreiche Projekte
Projekte mit Abweichungen
Gescheiterte Projekte
1994 16 % 53 % 31 %
2000 28 % 49 % 23 %
2004 29 % 53 % 18 %
Projektmanagement M1 -
Einführung
Quelle: Standish Group: Chaos Report
8
Aktuelle Fehlschläge
CW 29.12.06 Probleme mit Hartz-IV-Software„Eine Bearbeitung von Erst- und Fortzahlungsanträgen für das Arbeitslosengeld 2 (ALG2) ist seit dem 27. 12. nicht mehr möglich. Deshalb Verzögerungen bei der Auszahlung des ALG2 kommen. Schuld an dem Dilemma seien Probleme mit der zentralen Computersoftware A2LL, die die Bundesagentur für Arbeit für die Leistungsgewährung verwendet.“
CW 30.03.2007 Bayern kippt Polizeisystem DiplazNach jahrelangen Querelen rund um das neue Dienstplanungs- und Zeitwirtschaftssystem (Diplaz) hat das bayerische Innenministerium das Projekt gestoppt.„2003 ausgeschrieben sollte die Software für Dienstplanung und Zeitwirtschaft ursprünglich schon seit Mitte 2005 laufen. Aufgrund von funktionalen Mängeln musste der Start allerdings immer wieder verschoben werden. Nachdem sich die Fehler und Probleme auch im Modell- und Flächenpiloten vergangenes Jahr nicht beheben ließen, setzte das Innenministerium das Projekt Anfang Dezember 2006auf Eis. … Da es dem Softwarehersteller (auch im März ) nicht gelungen war, fristgerecht ein fehlerfreies System abzuliefern, zogen die politisch Verantwortlichen nun die Konsequenzen.“
Süddeutsche Zeitung Januar 2007Während des Januar-Orkans fielen die elektronischen Anzeigen des MVV aus bzw. mussten wegen Fehlangaben abgeschaltet werden. Ursache waren Fehler in der zugrunde liegenden Software.
Projektmanagement M1 -
Einführung
9
Ziele dieser Vorlesungseinheit
Begriffe „Projekt“ und „Projektmanagement“ definierenSchwierigkeiten des Projektmanagement diskutierenAufgaben des Projektmanagement kennen lernenTätigkeiten während des Projektverlaufs kennen lernen und im V-Modell wiederfinden
Projektmanagement M1 -
Einführung
Was sind Projekte?
10
Begriff Projekt
Projektmanagement M1 -
Einführung
Routine- aufgaben
Veränderungs- aufgaben
Projekte
Linien-Organisation
alte Wege neue Wege
neue Ziele
alte Ziele
Sicherheit
FestigkeitStandardisierung
Genaues Regelsystem
ExperimentierfreudeInnovativ
KreativRisiko
Konflikte
11
Begriff Projekt
Ein Projekt ist ein Vorhaben, das im wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.B.
Zielvorgabezeitliche, finanzielle, personelle und andere BegrenzungenAbgrenzung gegenüber anderen Vorhabenprojektspezifische Organisation.
(DIN 69 901)Ein Projekt ist eine zeitlich beschränkte Anstrengung zur Erzeugung eines einmaligen Produktes oder Dienstes
(Project Management Institute, PM Body of Knowledge)
Was heißt es, ein Projekt zu "machen"?Schaffen einer stabilen, akzeptierten und funktionierenden "temporären Organisation„Abgrenzungen gegenüber Umgebung nötig
Projektmanagement M1 -
Einführung
12
Abgrenzung eines Projekts
Zeitliche AbgrenzungZeitplan, Termine,Vor- und Nachprojekt-Phase
Sachliche AbgrenzungZiele, Hauptaufgaben, Nicht-Zielezu anderen Projekten, Tätigkeiten
Soziale AbgrenzungProjektleiter, Projektauftraggeber, ProjektteamUmwelt-/Umgebungsanalyse
Projektmanagement M1 -
Einführung
13
Begriff Projektmanagement
"Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes„
(DIN 69901)
"Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements." "Project management includes
identifying requirements, establishing clear objectives, balancing the competing demands for time, quality, and cost, adapting the specifications, plans, and approach to the different concerns and expectations of the various stakeholders.„
(Project Management Institute, pmi.org)
Projektmanagement M1 -
Einführung
14
Projektmanagement
Projektmanagement umfasst alle Aufgaben bei der Durchführung von Projekten hinsichtlich
Vorbereitung (Struktur und Personal)PlanungKontrolleSteuerung
Dazu gehören auch projektübergreifende Aufgaben:Projektabschluss und ErgebnisdokumentationProzessverbesserungPersonalführungInteraktion mit dem Kunden und Koordination von Zulieferern.
Projektmanagement M1 -
Einführung
15
Projektmanagement
Projektmanagement ist einfach zu begreifen, aber schwer zu tunProjektmanagement ist ein wenig, wie sich das Rauchen abzugewöhnen: leicht zu begreifen, schwer zu tun.Man ist schon dann ein guter Projektleiter, wenn man dafür sorgt, dass alle die Dinge auch tatsächlich passieren, die eigentlich selbstverständlich sind.
Warum ist Projektmanagement wichtig für Sie? Als Projektleiter: Selber machen Als Projektmitarbeiter: Zusammenhänge kennen
Projektmanagement M1 -
Einführung
Projektmanagement ist die Kunst mit 10 Fingern 11 Korken unter Wasser zu halten
Quelle: G..Pews sd&m
16
Projektmanagement (und Humor)
Projekte sind oftmals nicht erfolgreich,deshalb gibt es viele Aussprüche über das Projektmanagement.
Hier ein paar nicht ganz ernst zu nehmende Zitate:Persönlichkeit: "If you're 6 months late on a milestone due next week but reallybelieve you can make it, you're a project manager."Zeitschätzung: "The first 90% of a project takes 90% of the time; the last 10% takes the other 90%."Straffung von Zeitplänen: "Even the nine most competent women can not have a baby in only one month."Rolle von Planung: "The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."
Projektmanagement M1 -
Einführung
17
(Unerwünschter) Projektablauf
1.
Enthusiasmus
2.
Desillusionierung
3.
Panik
4.
Suche nach den Schuldigen
5.
Bestrafung der Unschuldigen
6.
Ruhm & Ehre für die Unbeteiligten
Projektmanagement M1 -
Einführung
18
Schwierigkeiten im IT-Projektmanagement
Effizienz vs. Flexibilität:Effizienz: Einsatz bewährter Methoden zur Kostenreduktion:
StandardanwendungsdomäneStandardentwicklungsplattformStandardentwicklungsprozessStandardentwicklungsumgebung
Flexibilität: Das Unvorhersehbare planen:Änderung der Anforderungen durch den KundenÄnderung der Entwicklungsplattform durch das ManagementMitarbeiterfluktuationÄnderung des Ausliefertermins durch das ManagementVerzögerungen durch die Zulieferer
Projektmanagement M1 -
Einführung
19
Schwierigkeiten im IT-Projektmanagement
Immaterialität des Produkts: Software ist unsichtbar und damitFür den Kunden schwer erlebbar (Kostenbewusstsein)Bzgl. des Fertigungsgrades schwer messbarRisiko: Umfang, Kosten und Laufzeit
Innovativität des Produkts: Software ist i.a. „Null“-Serie und damitMit dem Einsatz neuester Technologie verbundenMit der Realisierung umfassender neuer Funktionen verbundenRisiko: Stabilität (Qualität) und Laufzeit
Mangelnde Prozessreife: SE ist eine junge Disziplin und damitfehlen standardisierte und etablierte EntwicklungsprozesseVerständnis für die ingenieurmäßige SE (Kunst vs. Handwerk)Risiko: Qualität und Laufzeit
Projektmanagement M1 -
Einführung
Magisches Projektmanagement-Dreieck (Triple Constraints)
©
Bernhard Bauer, all rights reserved 2007 20
Projektziel
ZeitraumAufwand
21
Projektmanagement Teufelsquadrat nach Harry Sneed
Projektmanagement M1 -
Einführung
Zielgrößen auf den Diagonalen:Zeit: ProjektlaufzeitKosten: BudgetQualität: z.B. Funktionalität, Nutzbarkeit, WartbarkeitLeistungsumfang: Anzahl ausgelieferter Funktionen
Je weiter außen, desto besser das Ergebnis:
„Mehr“ Qualität und Leistung führen zu besserem Ergebnis (daher „plus“ außen)Kürzere Entwicklungsdauer und geringere Kosten führen zu besserem Ergebnis (daher „minus“ außen)
Die von den Zielgrößen gebildete Fläche beschreibt die Produktivität des Projekts.
22
Projektmanagement Teufelsquadrat nach Sneed
Die Fläche (Produktivität) eines Projekts ist invariant
Wenn ein Projekt z. B. in weniger Zeit und zu geringeren Kosten abgeschlossen werden soll, verringern sich auch Leistungsumfang und Qualität.
„Chinesenprinzip“Idee: Ein Projekt wird beschleunigt, indem massiv Personen in das Projekt entsandt werden. Funktioniert nur bei stark parallelisierbaren, voneinander unabhängigen Tätigkeiten, die keine größere Einarbeitung erfordern.
Projektmanagement M1 -
Einführung
23
Projektmanagement Zielgrößen
Kosten Das Projekt wird mit einem festen Budget gestartet. Dieses Budget wird nachträglich nicht mehr gekürzt. Auch bei Anbietern von Festpreisprojekten wird in der Regel nicht während der Projektlaufzeit das für das Projekt verfügbare Budget gekürzt, um einen höheren Gewinn zu erzielen. Das Budget wird nicht ohne Grund erhöht.
Zeit Das Projekt wird mit einem festen Zeitrahmen gestartet. Oft gibt es einen fixen Zieltermin. Oft kommt es zu einer faktischen Kürzung der Projektlaufzeit, wenn sich der Projektstart verzögert, z. B. aus organisatorischen Gründen wie fehlenden Ressourcen oder nicht freigegebenen Budgets.
Projektmanagement M1 -
Einführung
24
Projektmanagement Zielgrößen
Qualität Ist der am schwierigsten zu messende Faktor und sind nicht so klar vorgegeben wie Budget und ZeitQualitätskriterien müssen im Projekt konkretisiert werden. Über einzelne, konkrete Punkte kann dann ggf. gesprochen werden, ob dieses Qualitätskriterium gehalten werden muss.
Leistung Der Leistungsumfang tendiert während eines Projekts dazu, immer größer zu werden. Ursache dafür sind zu Projektbeginn zwangsläufig unscharfe Anforderungen, bei deren Konkretisierung immer neue Implementierungsaspekte entstehen können. In konkreten Punkten lässt sich der Leistungsumfang auch im Projektverlauf kürzen. Dabei verschwimmt die Abgrenzung zu den Qualitätsmerkmalen.
Projektmanagement M1 -
Einführung
25
Aufgabenfelder Projektmanagement
Laut Project Management Institute besteht PM aus den folgenden 9Aufgabenfeldern:
Integrierende Aufgaben (integration management)Umfangsmanagement (scope management)Zeitmanagement (time management)Kostenmanagement (cost management)Qualitätsmanagement (quality management)Personalmanagement (human resource management)Kommunikationsmgmt. (communication management)Risikomanagement (risk management)Beschaffungsmanagement.(procurement management)
Es folgt eine Kurzübersicht über deren Themen
Projektmanagement M1 -
Einführung
26
Vorbemerkung: Wann wie viel?
Viele der nachfolgend beschriebenen Aufgaben sind nur für Großprojekte im vollen Umfang sinnvollBei mittelgroßen Projekten sollten viele davon vereinfacht werden
aber welche und wie stark hängt vom Einzelfall abBei kleinen Projekten sollten evtl. sogar manche ganz entfallen
aber ob und welche hängt vom Einzelfall ab
Übertriebenes Projektmanagement ist schädlich!Zu wenig Projektmanagement ist auch schädlich!
Augenmaß ist gefragt!Das ist allerdings ohne Erfahrung ziemlich viel verlangt…
Projektmanagement M1 -
Einführung
27
Integrierende Aufgaben (integration management)
Diese Tätigkeiten verbinden die Tätigkeiten der restlichen Felder miteinander:Entwickeln des umfassenden Projektplans
enthält Teilpläne aus den anderen AufgabenfeldernAnmerkung: Ein solcher Plan existiert immer (evtl. nicht detailliert, evtl. nicht einmal schriftlich)
Projektleitungkonkrete Anweisungen geben, Entscheidungen fällen etc.
Projektüberwachungkontinuierlich den Ablauf gegenüber den Plänen verfolgen,bei Abweichungen geeignete Maßnahmen ergreifen
Planänderungs-Überwachung und -SteuerungÄnderungen am Plan auf Wirkungen abklopfen und entweder zurückweisen oder komplett ins Projekt einfädeln
Projektmanagement M1 -
Einführung
28
Umfangsmanagement (scope mgmt)
UmfangsdefinitionWas ist Aufgabe des Projekts? Was nicht?Bei SW: Anforderungsbestimmung
Erarbeiten einer Produktzerlegung (WBS: Work Breakdown Structure)In welche handhabbaren Teile sollte man das Gesamtprodukt (genauer eigentlich: den konkreten Prozess) zerlegen?Wie fügen sich diese Teile zum Ganzen zusammen?Bei SW hauptsächlich: Entwurf + Prozessmodell
Umfangsverwaltung (bei SW: Anforderungsverwaltung)Änderungen am Umfang (durch externe Einflüsse, z.B. Kundenwunsch) werden nicht einfach zugelassen, sondern die Auswirkungen überprüft.Akzeptierte Änderungen werden sorgfältig in die Umfangsbeschreibung eingearbeitet
und Beteiligte geeignet benachrichtigt
Projektmanagement M1 -
Einführung
29
Zeitmanagement (time management)
Entwickeln einer AktivitätenlisteZu jedem Teilprodukt laut WBS gehören eine oder mehrere Aufgaben (Aktivitäten, also Prozesse)
(Zeit-) Aufwandsschätzung für die AktivitätenWie hoch ist der Aufwand (z.B. Personentage)?Wie lange dauert die Erledigung (Kalendertage)?
Aufstellung eines Zeit- und Arbeitsplans (schedule)Wie hängen die Aufgaben von einander ab?Wer erledigt von wann bis wann welche Aktivität?
Zeitplanüberwachung (schedule control)Wird der Plan eingehalten?Kontinuierliche Fortschreibung des Zeitplans
Projektmanagement M1 -
Einführung
30
Kostenmanagement (cost management)
KostenschätzungBudgetaufstellungKostenüberwachung
Bei SW-Projekten sind außer den Personalkosten meistens nur ganz wenige Posten relevant (meist SW-Lizenzen, Reisekosten, …)Dadurch hängen die Kosten so eng an den Zeitaufwänden, dass diese Aufgabe kaum separat gelöst werden muss
Projektmanagement M1 -
Einführung
31
Qualitätsmanagement (quality management)
Qualitätsplanung (quality planning)Aufstellen von Qualitätsanforderungen (bei SW: Anforderungsbestimmung)
Planen, wie man sie erfüllt (bei SW ungefähr: Qualitätsmanagement)
Qualitätssicherung (quality assurance)
Qualitätssteuerung (quality control)wenn die Qualität nicht stimmt, geeignete Maßnahmen ergreifenz.B. korrigieren, Teil wegwerfen und neu bauen, Aufgabe an andere Person übergeben, Entwicklungsprozess ändern, etc.
Projektmanagement M1 -
Einführung
32
Personalmanagement (human resource management)
PersonalplanungDefinition von Rollen, Verantwortlichkeiten, Weisungsbefugnisse(Prozessmodell & Organisationsplanung)
Aufstellung eines PersonalzeitplansWie viele Leute mit welcher Qualifikation brauchen wir von wann bis wann?
z.B. Analysten überwiegend am Anfang des Projekts, Programmierer jedoch nicht von Anfang an
Team einwerben, TeamformungTeilnahme an einem Projekt sollte freiwillig seinMitglieder müssen ein Gemeinschaftsgefühl entwickeln
TeamführungLeistung der Mitglieder verfolgen, Feedback geben, Konflikte auflösen, Arbeit bei Änderungen neu koordinieren
Projektmanagement M1 -
Einführung
33
Kommunikationsmanagement (communication management)
KommunikationsplanungWelche Beteiligten brauchen regelmäßig welche Information?
InformationsverteilungDen Betroffenen relevante Information stets zügig zukommen lassen
FortschrittsberichteStatusberichte und Planfortschreibung regelmäßig erarbeiten und allen Betroffenen zuleiten
Interaktion mit BeteiligtenBesprechungen und Schriftverkehr mit allen Beteiligten (z.B. Projektteam, Auftraggeber, Anwender, Interessierte), um deren Bedürfnisse zu erfüllen und Angelegenheiten aller Art zu klären
Projektmanagement M1 -
Einführung
34
Risikomanagement (risk management)
Risiken identifizierenWelche Ereignisse könnten die plangerechte Durchführung bedrohen?
RisikoeinschätzungRisikogrößen abschätzen, Risikobehandlung priorisieren
Vorbeugung planenWas wird getan, um welchem Risiko vorzubeugen?
Gegenmaßnahmen planenWas wird getan, wenn welches Risiko eintritt?
Risikomanagement-ÜberwachungKontinuierlich nach neuen oder veränderten Risiken Ausschau haltenFortführung und Wirkung eingeleiteter Vorbeugungen und Gegenmaßnahmen überwachen. Ggf. korrigierend eingreifen
Projektmanagement M1 -
Einführung
35
Beschaffungsmanagement (procurement management)
Planung und Durchführung der Beschaffung aller Dinge, die das Projekt braucht, aber nicht selbst herstellt
Betrifft bei SW-Projekten gelegentlich Möbel u.ä., manchmal Hardware und oft SW-LizenzenIst aber meist nicht sehr kompliziert
Projektmanagement M1 -
Einführung
36
Projektverlauf
•
Projektvorbereitung–
Festlegung der Projektziele–
Zusammenstellung der groben Projektplanung...in Koordination mit dem Auftraggeber!
–
Zusammenstellung und Nutzen von Know-How aus früheren Tätigkeiten und Projekten
–
Möglichst Durchführung eines Start-Workshops gemeinsam mit Auftraggeber und Projektteam
•
Projektabschluss–
Zusammenstellung und Präsentation der Projektergebnisse–
Gemeinsamer inhaltlicher und emotionaler(!) Abschluss des Projektes–
Sicherung des Know-Hows und der "learned lessons" für nachfolgende Projekte
–
Prozessverbesserung
Projektmanagement M1 -
Einführung
Projekt-vorbereitung
Projekt-durchführung
Projekt-abschluss
37
Projektverlauf
Projektmanagement M1 -
Einführung
•
Projektdurchführung–
Projektkontrolle
–
Feststellung des Projektstatus–
Feststellung von Planabweichungen–
Techniken:
–
Fortschrittsanalyse–
Risikoanalyse
–
Qualitätssicherungs -Maßnahmen
–
Projektsteuerung–
Durchführungsentscheidungen–
Korrektivmaßnahmen–
Techniken:
–
Risikomanagement–
Qualitätsmanageme
nt-Maßnahmen–
Konfigurationsmana
gement
Projekt-vorbereitung
Projekt-durchführung
Projekt-abschluss
38
Projektverlauf Prozesse im Submodell PM des VM‘97
Projektmanagement M1 -
Einführung
PM1: ProjektinitialisierungPM2: Vergabe/BeschaffungPM3: Auftragnehmer-ManagementPM4: FeinplanungPM5: Kosten-/NutzenanalysePM6: DurchführungsentscheidungPM7: Risikomanagement
PM8: Projektkontrolle und –steuerungPM9: Informationsdienst/BerichtswesenPM10: Schulung/EinarbeitungPM11: Bereitstellung der RessourcenPM12: Vergabe von ArbeitsaufträgenPM13: Einweisung der MitarbeiterPM14: Projektabschluss
Prozesse nach VM’97 (Submodell PM)
Projekt
Kunde
Zulieferer
Projekt-vorbereitung
Projekt-durchführung
Projekt-abschluss
41
Zusammenfassung (1)
Ein Projekt ist eine zeitlich beschränkte Anstrengung zur Erzeugung eines einmaligen Produktes oder DienstesProjektmanagement bezeichnet Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines ProjektesDas Teufelsquadrat von Sneed beschreibt den Zusammenhang von Zeit, Kosten, Leistungsumfang und Qualität eines Projekts
Projektmanagement M1 -
Einführung
42
Zusammenfassung (2)
Laut Project Management Institute besteht PM aus den folgenden 9 Aufgabenfeldern:
Integrierende Aufgaben (integration management)Umfangsmanagement (scope management)Zeitmanagement (time management)Kostenmanagement (cost management)Qualitätsmanagement (quality management)Personalmanagement (human resource management)Kommunikationsmgmt. (communication management)Risikomanagement (risk management)Beschaffungsmanagement.(procurement management)
Ein Projektverlauf besteht ausProjektvorbereitungProjektdurchführung mit Projektkontrolle und -SteuerungProjektabschluss
Projektmanagement M1 -
Einführung
44
Ziele
Wichtige Paradigmen und Vorgehensmodelle der SW-Entwicklung wiederholen und in Zusammenhang mit Projekten stellen:
Sequentiell („Wasserfall“, „V-Modell“),iterativ („spiralförmig“), leichtgewichtig („agil“).
ProjektorganisationUnternehmenss- und Projektstrukturen kennenlernenEinbinden des Projekts in die Unternehmensorganisation bewertenRollen und Verantwortlichkeiten in Projekten verstehen
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Prozessmodell
Funktion: Beschreibung und Strukturierung des Prozesses zur Abwicklung eines Projekts
Elemente:Phasen Aktivitäten der Phasen(Teil-)Produkte der PhasenProjektrollen (Kompetenzen, Verantwortlichkeiten, Qualifikationen)Richtlinen, Standards, Methoden, Werkzeuge
©
Bernhard Bauer, all rights reserved 2007 45
46
Paradigmen der SW-Entwicklung
Einordnung der anfallenden TätigkeitenAnforderungsanalyse & Fachliche KonzeptionTechnische Konzeption (Design, Entwurf)RealisierungIntegration & Test
in Vorgehensmodelle
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
47
Das sequentielle Paradigma
Das sequentielle Paradigma bezeichnet ein sequentielles Vorgehen mit klar definierten Phasen und Ergebnissen
Bekannteste Vorgehensmodelle:Wasserfall-ModellV-Modell
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
•
48
Sequentiell: Wasserfallmodell (schematisch)
• Eingeführt von Walker Royce 1970, Weiterentwicklung der „stufenweisen Entwicklung“
(„stagewise development“) von
Benington 1956.• Ansatz:
•
Top-down Stufenmodell mit eingeschränkter Rückkopplung•
Phasensynchronisation durch (Zwischen-) Produkte
•
Geringer Managementaufwand
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Charakteristika:- Jede Aktivität muss beendet sein,
bevor die nächste beginnt. - Jede Aktivität ist in der richtigen
Reihenfolge und in voller Breite vollständig durchzuführen.
- Am Ende jeder Aktivität steht ein fertiggestelltes Dokument.
Fach.
Konzeption
Tech.
Konzeption
Realisierung
Test & Integration
Projektstart Ziel
Sequentiell: V-Modell
Entwicklungsstandard für IT-Systeme des BundesEingeführt 1991/1997, Bundesamt für Wehrtechnik und BeschaffungEinsatz
Bei allen Beschaffungen für IT-Systeme des BundesReferenzmodell in vielen Unternehmen der Privatwirtschaft (nominell)
Module:ProjektmanagementSystementwicklungQualitätssicherungKonfigurationsmanagement
©
Bernhard Bauer, all rights reserved 2007 49
50
Das sequentielle Paradigma: Vor-
und Nachteile
Vorteileeinfach durchzuführenschränkt Freiheitsgrade stark ein, daher auch für sehr große Projekte anwendbar Komplexitätsbeherrschungsehr effizient bei bekannten und konstanten Anforderungenist gut zu vermessen (notwendig z.B. für Prozessverbesserung) Erhöhte Transparenz
NachteileRisiken gesammelt am Schluss („Big Bang“)starr während des Ablaufs
Gut anwendbar bei klarer, relativ fixer Funktionalität:System- und Basissoftware wie OS, DB, Web-Server;Branchen-Software wie SAP R/3.
Notwendig bei hohen Qualitäts- und Zuverlässigkeitsanforderungen:eingebettete Systeme,rechtliche Anforderungen wie Revisionssicherheit oder Nachvollziehbarkeit.
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
51
Das iterative Paradigma
Iterativ
heißt, dass der Entwicklungsprozess mehrfach iteriert wird: statt den „Wasserfall“
einmal zu durchlaufen, werden kleine Wasserfälle
hintereinander gesetzt.
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
52
Das iterative Paradigma
Das iterative Paradigma ist eine Weiterentwicklung des sequentiellen Paradigmas aus der Erkenntnis, dass Software länger lebt als erwartet und auch vom Funktionsumfang her gepflegt werden muss.
Das iterative Paradigma unterstützt inkrementelle Entwicklung, d.h. dass das zu erstellende System nicht in einem Rutsch freigegeben wird, sondern in mehreren Stufen.
Bekannteste Modelle:Spiral-Modell (ein Meta-Vorgehensmodell)Unified Process (RUP)
Das agile Paradigma ist eine Form des iterativen Paradigmas in Verbindung mit frühem Prototyping, bei der nicht alle Tätigkeiten iteriert werden.
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
53
Rational Unified Process (RUP)
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
PropjektmanagementInfrastruktur
Geschäftsmodellierung
ImplementierungTest
Analyse & Entwurf
Preliminary Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
#n+
1
Iter.
#n+
2
Iter.
#m
Iter.
#m+
1
Auslieferung
Konfigurations-Mgmt
Anforderungen
Entwurf ÜbergangKonzeption KonstruktionZeitliche Phasen
IterationenArbeitsschritte
RUP ist eine Weiterentwicklung von Jacobsons Objectory
RUP hat UML als Sprache voreingestellt
RUP wird von Rational/IBM bezeichnet als• inkrementell & iterativ,• architektur-zentriert, und•
anwendungsfall-
getrieben.
54
Das iterative Paradigma: Vor-
und Nachteile
VorteileRisiken können früher erkannt werdenvolatile Anforderungen können besser berücksichtigt werdeninkrementelle Auslieferung wird erleichtert
NachteileMehrarbeitkomplexeres Projektmanagementschwerer messbar
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
55
Das adaptive Paradigma
Unter einem adaptiven SW-Prozess versteht man eine Weiterentwicklung des iterativen Paradigmas, bei der
die Planung der Iterationen dynamisch erfolgt undvon Anfang an Prototypen erstellt werden
Charakteristikum:kontinuierliche Anpassung an Änderungen
Prinzipien:Individuum und Interaktion (geht) vor Prozess und Werkzeugausführbare SW vor vollständiger DokumentationZusammenarbeit mit Kunden vor VertragsverhandlungBerücksichtigung von Änderungen vor Beharren auf Plan
Bekannte Vorgehensweisen:XPSCRUM, ...
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
56
XP (Extreme Programming)
MerkmaleXP arbeitet mit kleinen Releases, unterteilt in Iterationen und Arbeitspakete.Anforderungsanalyse
Aufgaben und Anforderungen in Form von StoriesBeschränkung auf wenige Anforderungen pro Iteration
Pair ProgrammingZwei Personen vor einem Rechner, einer programmiert, der andere ist Sparringspartner.
Enthält Elemente des Prototyping, allerdings ohne Wegwerfen.Auftraggeber wird besser eingebunden, kann konkrete Ergebnisse sehen.
Prozess: Test-first: Zuerst Tests (Spezifikation) schreiben, dann programmieren. Kontinuierliches Refactoring zur Verbesserung der Code-Qualität.
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
57
Das adaptive Paradigma: Vor-
und Nachteile
VorteileGut einsetzbar bei unklaren Zielen und sich ändernden Anforderungen/UmgebungVerspricht besseres Kosten/Nutzen-VerhältnisVermutlich durchschnittliche Code-Qualität besser
NachteileErgebnis ist nicht vorhersagbar
Qualitätseigenschaften können nicht garantiert werdenOft nicht nachvollziehbar, wie eine Funktion zustande kommt
80-90% aller Software läuft auf eingebetteten Systemen.Das bezieht sich z.B. auf Maschinen und Anlagen jeder Art und Größe, Verkehrsmittel, Militärische Anwendungen, Medizinische Geräte.Hier sind Fehler fatal - ein „agiler“ Prozess kommt nicht (oft) in Frage.
Refactoring geht nicht bei Nicht-oo-Sprachen.Aber ein Großteil (ca. 90%) der bestehenden Applikationen weltweit ist in Cobol, PL1, Assembler und C, und OO-Sprachen sind nicht immer optimal.
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
58
Wasserfallmodell versus Inkrementelle Software-Entwicklung
Was ist besser?
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
59
Wasserfallmodell versus Inkrementelle Software-Entwicklung
WasserfallHohe Sicherheit für Software-AnbieterGesamtblick (aber: zu viele Details)Unüberschaubare KonzeptpapiereGeringere Flexibilität, aber Change-Request-VerfahrenNutzen erst bei Einführung„Deckel drauf bekommen“Einfache Struktur, Qualitätssicherung zwischen PhasenEntspricht Denkweise: Geld für definierte Leistung
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Iteratives VorgehenFrüher Nutzen für KundenBesseres, qualifizierteres FeedbackKosten für ÜbergangslösungenSchwieriger zu managenGeringeres Einführungsrisiko
60
Verbesserung: Gestuftes Vorgehen
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Wasserfall als Vorgehen stößt an Grenzen
Große Projekte werden handhabbar
Verringern des RisikosFachliches RisikoTechnisches Risiko
Die elegante Art, „nein“ zu sagen: Stufen bedeuten, dass Anforderungen nicht oder erst später erfüllt werden
Widerstände müssen überwunden werden: Management-Aufgabe
61
Gestuftes Vorgehen
Bei Aufsetzen des ProjektsImmer den Umfang des Projekts im Auge behaltenBei größerem Umfang Stufung versuchen
Umfang niemals unterschätzen!
Nach Fachkonzeption oder StudieZusätzlicher Schnittpunkt für Stufenbildung (fachlich)
Indizien für zu großen ProjektumfangUmfang der Konzeptpapiere: größer als 200 Seiten?Feedback der Reviewer/externen Beteiligten: wirken sie noch mit, lesen sie die Papiere?
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
62
Beispiele für gestuftes Vorgehen im Projekt
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
63
Projektorganisation
Projektorganisation: Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projektes
[nach DIN 69 901]Einrichten einer projektspezifischen Organisation:
Aufbauorganisation:Einbinden des Projekts in die UnternehmensorganisationEinrichten von Rollen und Verantwortlichkeiten
Ablauforganisation:Abwickeln des Projekts entsprechend des EntwicklungsprozessFestlegen von Aktivitäten und Abläufen
In der Projektorganisation wird folgendes festgelegt:Arbeitsteilung zwischen Personen und TeamsAKV: Aufgaben, Kompetenzen, VerantwortlichkeitenWeisungsbefugnisse, Kontrollrechte und AufsichtspflichtenKoordinationsinstrumente (z. B. Abstimmungszirkel)
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
64
Unternehmensstrukturen
Grundstruktur:Organisationsleitung:
Funktion: Strategische FührungBeispiel: Geschäftsführung
Mittellinie:Funktion: Operative FührungBeispiel: Mittleres Management, Gruppenleiter
Betrieblicher Kern:Funktion: Operative AusführungBeispiel: Entwickler
Stab:Funktion: Unterstützende AusführungBeispiel: Rechtsabteilung,Telefonzentrale, Methodenberatung
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
65Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Varianten von Organisationsformen
Formen der Unternehmensorganisation:Bereichsstruktur:
Untergliederung nach GeschäftsfunktionBereiche: z.B. Marketing, Entwicklung, Vertrieb, Buchhaltung, ForschungBeispiel: BMW, Microsoft
Marktstruktur:Untergliederung nach ProduktgemeinsamkeitenMärkte: z.B. BIS (ERP, CRM, etc.), Medizintechnik, TelekomBeispiel: Siemens
Spezielle Varianten:Nach NiederlassungenNach Kunden
66
Bereichsstruktur
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Schwerpunkte: Know-How-Transfer, Ressourcenflexibilität
67
Marktstruktur
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Schwerpunkte: Effizienz, Produktidentifikation, minimierte Kommunikation
68
Vor-
und Nachteile der Organisationsformen
Bereichsstrukturierte Organisation:Vorteile:
Standardisierung der Abläufe, erhöhte WirtschaftlichkeitSpezialisierung, Fachhierarchien, Wissenstransfer
Nachteile:Aufwändige Koordination funktionsübergreifender TätigkeitenMangelnde Flexibilität
Ausrichtung: Fertigung von StandardproduktenMarktorientierte Gruppierung:
Vorteile:Flexibilität (neue Marktsegmente)I.A. geringerer bürokratischer Aufwand
Nachteile:Schwacher Wissenstransfer durch fehlende SpezialisierungMangelnde Effizienz durch mangelnde Standardisierung
Ausrichtung: Fertigung von Individualprodukten
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
69
Projektformen
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Wesentliches Element: VerantwortungFachliche Verantwortung („Was wird wann gemacht“)Führungsverantwortung(Personalverantwortung) („Wer macht es wann mit welchem Aufwand“)
Problem:Mitarbeiter sind in langfristige Organisationshierarchien eingebundenProjekte konkurrieren kurzfristig mit diesen HierarchienResultat: Konflikt zwischen Interessen der Linienhierarchie und der Projekthierarchie (i.E. Linienverantwortung vs Projektverantwortung)
Projektstrukturen:Projektorganisation als Linien-OrganisationStab-Linien-OrganisationMatrixorganisation
70
Projektorganisation als Linienorganisation
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
• Eignung: Kritische Projekte mit hoher Priorität
71
Projektorganisation als Linienorganisation
Prinzip:Eigenständige Organisationseinheit für ProjektProjektmitarbeiter werden aus Bereichen freigestellt
Verantwortung Projektleiter:Fachliche Verantwortung UNDFührungsverantwortung
Vorteile:Klare Kompetenzen und VerantwortlichkeitenHohe ProjektidentifikationKurze Kommunikationswege
Nachteile:Umstellungsaufwände durch Aus- und WiedereingliederungSchwächung der Bereiche, ev. Konkurrenzsituation mit BereichenProblem der ungleichmäßigen Projektbelastung
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
72Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Projektorganisation als Linienorganisation
Extremfall: Projektstruktur als Unternehmensform
73
Beispiel: sd&m
Sonderfall: IT-ProjekthäuserFür IT-Projekthäuser ist der Sonderfall „Projekt“ die Regel
können ihre Linienorganisation nach der Projektorganisation aufstellen.Dies betrifft aber nur den IT-Teil eines Projekts. Der Kontakt zum fachlichen Treiber des Projekts (Business-Case-Owner) und den Fachspezialisten des Unternehmens überschreitet die Projektgrenze
Das Unternehmen, das den Auftrag gibt, stellt in der Regel ein spiegelbildlich kleineres Projekt mit Ansprechpartnern für das externe IT-Projekt auf. Dabei muss der Konflikt zwischen Linien- und Projektorganisation gelöst werden.
©
Bernhard Bauer, all rights reserved 2007 73
74Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Stab-Linien-Organisation
Eignung: Niedrigpriore Projekte oder Konsensprojekte
75Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Stab-Linien-Organisation
Prinzip:Keine Leitungsinstanz/Organisationseinheit für ProjektProjektmitarbeiter verbleiben vollständig in Bereichen
Verantwortung Projektleiter (hier typischerweise „Koordinator“):Keine fachliche VerantwortungKeine FührungsverantwortungStabsfunktion (berichtend, koordinierend)
Vorteile:Schneller Know-How-TransferFlexible KapazitätsauslastungKeine Umstellungsaufwände
Nachteile:Aufwändige Koordinations- und AbstimmungsprozesseKeine ProjektidentifikationKeine Instanz mit Weisungsbefugnis
76
Matrixorganisation
Prinzip:Zeitlich befristetes MehrliniensystemProjektmitarbeiter verbleiben vollständig in Bereichen
Verantwortung Projektleiter:Fachliche VerantwortungKeine Führungsverantwortung
Vorteile:Schneller Know-How-TransferOptimale KapazitätsauslastungGeringe Umstellungsaufwände
Nachteile:Konfliktpotential durch DoppelunterstellungHohe Anforderungen an Selbstdisziplin und EigenständigkeitHohe Anforderung an Teamfähigkeit und Sozialkompetenz von Mitarbeitern und Leitungskräften
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
77
Matrixorganisation
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Eignung: Flexible Projektabwicklung in dynamischem Umfeld (Markt und Technologiedynamik)
78
Interne Projektstruktur
Festlegung der Projektstruktur:Bereitstellung von Mitarbeitern: Einbettung in die UnternehmensorganisationEinrichten einer internen Projektstruktur: Definition von Rollen und Verantwortlichkeiten
Projektstruktur: ähnlich Unternehmensstruktur:Leitung: ProjektleiterKern: ProjektmitarbeiterStab: Übergreifende Tätigkeiten (z.B. QM, KM)
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
79
Ablauf-
vs. Produktorganisation von Projekten
Projektorganisation ähnlich ProduktstrukturMehrere Teams mit der Verantwortung für jeweils eine Produktkomponente, ein fachliches Thema, z. B.: Stammdatenverarbeitung, Versandfunktionen, …Koordination der erarbeiteten Ergebnisse durch fachlichen und technischen Architekten
Projektorganisation nach Phasen/Rollen im EntwicklungsprozessTeams für die Phasen des Entwicklungsprozesses:
Fachteam für fachliche SpezifikationTechnisches Team für technische Konstruktion, ImplementierungTest-Team
tech./fach. Architekten arbeiten in den Teams mit.
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
80Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Produkt-
vs. Ablauforganisation
Produkt-Organisation:
Ablauf-Organisation:
81
Vergleich der Organisationsformen
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
Produktorganisation
Kontinuität, Wissenstransfer während der Phasen des Software-Entwicklungsprozesses besser.Fachliche Spezifikation entsteht im Bewusstsein, dass diese Spezifikation durch die gleichen Personen umgesetzt werden muss.Erfordert Generalisten, die gleich gut spezifizieren wie programmieren können.
AblauforganisationSpezialisten für einzelne Tätigkeiten können ihre Aufgabe besser durchführen.
Koordination und Wissensweitergabe zwischen Spezifikation und Umsetzung nur auf dem Papier.
Spezialisten sind im „Leerlauf“, wenn sie im SE-Prozess nicht benötigt werden.
82
Rollen
Rollenstruktur: Beeinflusst von:Prozessstruktur (z.B. Analyse, Design, Implementierung, Integration)Produktstruktur (z.B. Präsentation, Logik, Datenhaltung)
Projektrollen:ProjektausschussAuftraggeberAnwenderProjektleiterProjektmitarbeiter
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
83
Rolle: Projektleiter
Aufgaben:Erstellung Projekt-, Termin- und KostenplanOrganisation und Koordination ProjektteamDurchführung FortschrittskontrolleSteuerung und Festlegung von Entscheidungen (fachlich)Evtl.: Personelle Betreuung Projektmitarbeiter
Kompetenzen:Mitwirkung bei der ProjektzieldefinitionMitspracherecht bei der Bestimmung der Fachverantwortlichenprojektbezogenes Informations-, Weisungs- und Entscheidungsrecht
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
84
Rolle: Mitarbeiter
Aufgaben:Mitwirkung an ProjektplanungDurchführung der zugewiesenen ArbeitspaketeDokumentation der zugewiesenen Arbeitsergebnisse
Kompetenzen:Vorbereitung/Herbeiführung von EntscheidungenUmsetzung von VorgabenEinsatz von Ressourcen
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
85
Weitere Mitarbeiter-Rollen
Software Engineering-spezifische Team-Rollen:SystemanalytikerSystementwicklerTester
Software Engineering-spezifische Stabs-Rollen:Qualitätsmanager, QualitätsbeauftragterKonfigurationsmanagerIT-SicherheitsbeauftragterProjekt-Controller
Generelle Prinzipien:Personifizierte VerantwortungKlare Aufgaben und Kompetenzen
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
86
Zusammenfassung (1)
Das sequentielle Prozessparadigma (Wasserfall, klassisches V-Modell)ist
einfach durchzuführenauch für sehr große Projekte anwendbarsehr effizient bei bekannten und konstanten Anforderungen
ABER Risiken gesammelt am Schluss („Big Bang“) und starr während des Ablaufs
Das iterative Paradigma (RUP, Spiralmodell) erleichtertfrühe Erkennung von RisikenBerücksichtigung sich ändernder Anforderungen inkrementelle Auslieferung
ABER es erfordert Mehrarbeit, komplexeres Projektmanagement und istschwerer messbar
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
87
Zusammenfassung (2)
Das agile Prozessparadigma (XP) istGut einsetzbar bei unklaren Zielen und sich ändernden Anforderungen/UmgebungVerspricht besseres Kosten/Nutzen-VerhältnisVermutlich durchschnittliche Code-Qualität besser
ABER das Ergebnis ist nicht vorhersagbarQualitätseigenschaften können nicht garantiert werden
Ein gestuftes Vorgehen verbindet die Vorteile von sequentiellem und iterativem Vorgehen und vermeidet Nachteile wie „Big-Bang“ und hohem Mehraufwand.
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
88
Zusammenfassung (3)
Als Projektorganisation bezeichnet man die Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten ProjektesDie Grundstruktur eines Unternehmens besteht aus :
Organisationsleitung, Mittellinie, Betrieblichem Kern und StabMan unterscheidet Markt- und Bereichsstruktur
Mögliche Projektstrukturen sindStab-Linien-OrganisationProjektorganisation als Linien-OrganisationMatrixorganisation
Typische Projektrollen sind ProjektausschussAuftraggeberAnwenderProjektleiterProjektmitarbeiter
Projektmanagement M2 –
Prozessmodelle und Projektorganisation
90
Ziele
Tätigkeiten der Projektvorbereitung kennen lernen:Projekt-Idee und StudieBeauftragung mit Ausschreibung, Angebot und AuftragProjektinitialisierung undKick-Off-Meeting
Tätigkeiten am Projektende kennen lernen:ProjektabschlussTouch Down Meeting
Projektmanagement M3 -
Projektvorbereitung
9191
Grundparameter Projektmanagement
verdeutlicht Abfolge in Projektgeschehen
Einsatz von Aufwänden (Geld, Personal, Maschinen,...) und Verbrauch an Zeitsoll bestimmtes Ergebniserzielt werden
PM hat zentrale AufgabeErbringung geforderte Leistungim optimalen Verhältnis zu Zeit und Einsatzmitteln
Parameterausrichtungkostenfixierte Parameterausrichtungterminfixierte Parameterausrichtungleistungsfixierte Parameterausrichtung
93
Auslöser von Projekten
Beispiele für Auslöser von ProjektenIn Großunternehmen
Auslöser in Großunternehmen:In einem Großunternehmen wird eine neue Unternehmensstrategie festgelegt, bzw. neue Aspekte eingebracht.Eine neue IT-Strategie wird festgelegt.Ein Programm zur Kostensenkung/Effizienzsteigerung wird aufgelegt.Ein neuer Markt soll erschlossen werden.
Ein Business Case wird erstellt: Warum lohnt sich eine Investition, was ist der erwartete Nutzen, was sind die erwarteten Kosten? Ab wann überwiegt der Nutzen (gespartes/eingenommenes Geld) die Kosten der Investition? (ROI – Return On Investment)In der IT muss etwas gemacht werden: neue Software, umfangreiche Umstellung existierender Software – ein Projekt!
In der ForschungAuslöser
In einer Technologiestudie der EU wird Forschungsbedarf auf bestimmten Gebieten postulier; Projektideen werden in Workshops vorgestellt.
Ein neues Forschungsprogramm mit „Calls for Proposals“ wird beschlossen.Aufgrund von Projektideen formieren sich Forschungskonsortia, die Projektanträge einreichen.
Projektmanagement M3 -
Projektvorbereitung
94
Studie
Eine Studie dient dem Nachweis von Machbarkeit und Nutzen eines Software-Projekts. Sie enthält i.a.
Grobdefinition der Ziele des ProjektsGrobabschätzung des NutzensGrobabschätzung der Kosten und benötigten EinsatzmittelErstvorschlag zur Projektorganisation
Eine Studie im Vorfeld gibt es z. B. in folgenden Fällenbei größeren Vorhabenwenn die Aufgabenstellung noch nicht ganz klar istwenn genauer nachvollzogen werden soll, ob sich die Investition lohnt.
Unterschiedliche Arten von StudienAuftragsprojekt: AnforderungskatalogInnovationsprojekt: Marktstudie/TechnologiestudiePflege/Änderungsprojekt: Verbesserungsvorgaben
Wichtig:Festlegung ProjekterfolgskriterienMessbare Kriterien
Projektmanagement M3 -
Projektvorbereitung
95
Durchführungsentscheidung
Ziel: Annahme/Ablehnung ProjektVerfahren:
Ermittlung Kosten: Auf Basis Studie/GrobplanPersonalkosten (inkl. Personalvorbereitung)BetriebsmittelkostenOrganisationskosten
Ermittlung Nutzen:Monetärer Gewinn: Marktanalyse, EffizienzanalyseInvestitionsgewinn
Risikoanalyse:Wirtschaftliche RisikenFachliche RisikenEvtl: Alternativen erstellen und beurteilen
Ergebnis: Annahme oder Ablehnung des Projekts
Projektmanagement M3 -
Projektvorbereitung
97
Ein Projekt braucht einen Auftrag
Das neue Projektmanagement kommt ins Spiel: ein Auftrag für das Projekt wird erteilt, aber manchmal:
Leider nur mündlichZusätzliche AbsprachenUnvollständig
Im Projekt wird der Projektauftrag vervollständigt bzw. geschrieben.Zweck:
Ziele und Aufgabenstellung für das Projekt glasklar festlegenEin Auftrag muss schriftlich fixiert seinBei Gesprächen ist vieles „klar“, richtig klar ist es erst, wenn es schriftlich festgehalten ist.Verbindlichkeit schaffen: der Auftraggeber unterschreibt den Auftrag.
Projektmanagement M3 -
Projektvorbereitung
98
Inhalte eines Projektauftrags
Projektleiter: Verantwortlicher für das ProjektAuftraggeber: Wer will das Projekt eigentlich? Derjenige, der bezahlt, bestimmt auch – bzw. – wer bestimmen will, muss auch zahlen.Kurzbeschreibung des ProjektsZiele, ggf. hierarchisch verfeinertZu erbringende Leistungen und Ergebnisse, häufig als „Technischer Anhang“ mit
Beschreibung des Grobkonzepts (Systemspezifikation)Umfasst: Beschreibung des Leistungsumfang (Pflichtenheft)Umfasst: Beschreibung des Anwendungsgebietes (Lastenheft)
Projektgrobplan: Termine und AufwändeProjekthandbuch: Entwicklungsprozess
RahmenbedingungenAbhängigkeiten von anderen Projekten und Personen, ZulieferungenStart, Ende, Meilensteine
Projektmanagement M3 -
Projektvorbereitung
99
Wenn der Projektauftrag nicht fertig werden will…
Beispielhafte Gründe, warum man anfangen will, obwohl der Auftrag nicht fertig ist:
Geld ist schon da, verfällt sonstProjektmitarbeiter sind schon freigestellt, müssen beschäftigt werdenFormulierung scheitert an vermeintlich unwichtigen DetailsDas Schreiben ist lästig, der Kopf ist voller Ideen und man möchte lieber loslegen.
Dann kann/sollte man trotzdem……nicht anfangen!das Problem klar an die Leute eskalieren, die im Management die Verantwortung tragen
Projektmanagement M3 -
Projektvorbereitung
101
Projektinitialisierung
Ziel: Die Arbeit kann beginnen, das Team kann loslegen, alle Rahmenbedingungen sind geschaffen.Wichtig: Kernteam muss in der Projektinitialisierung besetzt sein
ProjektleiterQualitätssichererMitarbeiter, der inhaltlich für Kontinuität sorgt: Aus Angebot oder Vorstudie.
Der Auftraggeber muss auch ein Gegenstück/Ansprechpartner zum Projekt organisieren
Projektmanagement M3 -
Projektvorbereitung
102
Besetzung des Projektleiters
Häufiges Problem: Projektleiter kommt erst spät in das ProjektGute Projektleiter sind ein rares Gut und müssen oft erst aus anderen Projekten herausgelöst werden.Viele Mitarbeiter scheuen die Verantwortung, deswegen sind Projektleiter schwer zu finden.
Mögliche Konsequenzen:Die Initialisierung findet erst während des Projekts statt: ZeitverlustDer Projektleiter kann ein Projekt erst nach einer Einarbeitung sinnvoll leiten: Das Projekt ist zunächst führungslosDie Initialisierung wird nur halbherzig vorgenommen, weil derjenige, der die Konsequenzen einer mangelhaften Initialisierung ausbaden muss, noch nicht da ist.
Ein Projekt in einer bestimmten Richtung aufzusetzen und anzuschieben ist relativ einfach. Ein laufendes Projekt in eine andere Richtung zu lenken ist sehr aufwändig.Auch als designierter Projektleiter haben Sie die Möglichkeit darauf hinzuwirken, dass Sie nicht zu spät ins Projekt kommen.
Projektmanagement M3 -
Projektvorbereitung
103
Tätigkeiten während der Projektinitialisierung
Ziele klären Qualitätskriterien klärenOrganisation des Projekts festlegen, einschließlich Ansprechpartner des AuftraggebersProjektstruktur im Projektstrukturplan festlegen (falls nicht schon im Auftrag fixiert)Schätzung validierenPlanung: Grob- und Feinplanung für die ersten SchritteInfrastruktur etablierenStruktur für das Controlling aufsetzenIm Projekthandbuch festhalten
Projektmanagement M3 -
Projektvorbereitung
104
Initialisierung: Warum braucht ein Projekt Ziele?
Projektmanagement M3 -
Projektvorbereitung
Quelle: G. Pews sd&m
105
Ziele
Ziele sind elementar wichtig in einem ProjektErzeugen ein gemeinsames Bild, eine gemeinsame AusrichtungSind einfach kommunizierbar
Ziele sollte man für alle wichtigen Tätigkeiten definierenz. B.: Meetings (Schlechtes Ziel: „Wir haben darüber gesprochen“)z. B.: Dokumente: wozu ist das Dokument gut, was macht man damit?
Was ist ihr Ziel in dieser Vorlesung?
Projektmanagement M3 -
Projektvorbereitung
106
Ziele formulieren
AusgangsbasisAuftrag, Vertrag, Briefing, etc.
Was tun, wenn keine klare Aussage vom Auftraggeber vorhanden?Nicht einfach loslegen und die Versäumnisse anderer kompensieren wollen. Aber: einfach blockieren ist nicht hilfreich.Formulieren von Zielen als ArbeitshypothesenArbeitshypothesen dem Auftraggeber mitteilenDiese Technik funktioniert generell an vielen Stellen des Projekts.
Ziele SMART festhalten
Projektmanagement M3 -
Projektvorbereitung
107
SMARTe Ziele
S pezifisch Knackig, verständlich, eindeutig, stimmig mit anderen Zielen.
M easurable Messbar. Es muss klar sein, wann das Ziel erreicht ist.A chievable Erreichbar. Unerreichbare Ziele führen zu Demotivation.R elevant Die wichtigen Dinge als Ziel formulieren, nicht jeden
Kleinkram.T ime-based Es gibt einen Zeitpunkt, an dem das Ziel erreicht sein soll
(ist im Projektkontext automatisch gegeben)
Ziele müssen von ihrer Formulierung her attraktiv sein!
Projektmanagement M3 -
Projektvorbereitung
108Projektmanagement M3 -
Projektvorbereitung
Antoine de Saint Exupéry:„Wenn du mit anderen ein Schiff bauen willst,so beginne nicht, mit ihnen Holz zusammeln, sondern wecke in ihnen dieSehnsucht nach dem großen, weiten Meer.“
109
Ziele formulieren
Ein Ziel aktiv formulieren:Nicht: Man wird mir das Rauchen abgewöhnenSondern: Ich werde nicht mehr rauchen.
Ein Ziel so formulieren, als ob es schon erreicht ist (Gegenwart statt Zukunft):
Nicht: Ich werde nicht mehr rauchenSondern: Ich rauche nicht mehr.
Ein Ziel positiv formulieren:Nicht: Ich rauche nicht mehr.Sondern: Ich kann frei atmen, ich bin gesund
Sinn: Den Zielzustand heute schon im Kopf erleben, damit man diesen Zustand anstrebt.
Projektmanagement M3 -
Projektvorbereitung
110
Qualitätskriterien festlegen
Vom Auftraggeber die Qualitätskriterien erfragen, nach denen er seine Zufriedenheit misst.Beispiele
Know-how beim Auftraggeber aufbauenSich pro-aktiv um alles kümmern (Auftraggeber-Sorglos-Paket)Qualifizierte Mitarbeiter ins Projekt steckenSchnelle Resultate, schnell ein vorzeigbares Ergebnisallg.: Herausfinden, an welchen Ecken des Teufelsquadrats gezogen werden kann
Tipps: Nicht mit einer Auswahlliste arbeiten, sondern frei formulieren lassen.Nur bei Bedarf mit Beispielen aushelfen
Vom Auftraggeber nicht genannte Kriterien sind für ihn entweder selbstverständlich oder weniger wichtig.
Projektmanagement M3 -
Projektvorbereitung
111
Projektstrukturplan
ZielZerteilung des Projekts in kleinere Einheiten, die man besser managen kann.
Grundsätzliche Struktur, die sich im gesamten Projekt wiederfindet.Strukturierungsmerkmale:
Orientierung an der Produktstruktur der SoftwareOrientierung am ProjektablablaufOrientierung an den Funktionen im Projekt
Mischformen sind üblichMuss (wie jeder Plan) bei Bedarf angepasst werden.
Projektmanagement M3 -
Projektvorbereitung
112
Projektinfrastruktur (1/2)
Die Projektinfrastruktur umfasst alle Hilfsmittel, die das Team zum Arbeiten benötigtInfrastruktur
Räume, Arbeitsmittel (Rechner, Drucker, Telefone, Videokonferenz…). Gemeinsame Räume sind wichtig für Informationsfluss und Teamgeist.
Software-Umgebungen (Entwicklung, Test, Qualitätssicherung)Projektkommunikation/Projektablage
Konform zu Organisation und Projektstrukturplanz. B. gemeinsames Wiki (mit Sicherung!) für verteilte Teams und Teams unterschiedlicher Firmen
Projektmanagement M3 -
Projektvorbereitung
113
Projektinfrastruktur
Werkzeuge bereitstellenOffice-Tools, Druckstückerzeugung/PDF, Konfig-Mgmt, Software-Entwicklung, Test, Anforderungsmanagement, Zeichentools, Modellierungstools, Projektplanungstool, DB-Tool
Wenn schon bekannt: Aufbau der Software-Infrastruktur planen bzw. veranlassen: z. B.:
Middleware wie CORBA, MQ-Series,Application Server,Datenbank,
Kommunikationstools wie Wiki, NetMeeting, etc.E-Mail Verteiler, etc.Nutzungskonzepte: Ein Werkzeug allein reicht oft nicht, es muss auch festgelegt sein, wie es im Projekt eingesetzt werden soll.
Projektmanagement M3 -
Projektvorbereitung
114
Infrastruktur etablieren
Etablieren der Infrastruktur hört sich trivial an, aberist zeitaufwändig und daher nicht zu unterschätzennicht vorhandene Infrastruktur behindert das Team massiv.
Tipp: Aufbau der Infrastruktur früh planen und initiieren, Anschaffungen haben oft langen Vorlauf.
Projektmanagement M3 -
Projektvorbereitung
115
Strukturen für Projektcontrolling aufsetzen
Verfolgung der Aufwände und des Budgets erfolgt i. d. R. über spezielle Zeiterfassungs-Tools oder manuell in tabellarischer Form.
Dabei vermerken die Projektmitarbeiter, an welchen Aufgaben sie wann und wie lange gearbeitet haben.Diese Informationen lassen sich im Nachhinein kaum noch rekonstruieren, sind aber die Grundlage für die Abrechung und die Aufwandsverfolgung.
Gerade in gemischten Teams mit Mitarbeitern verschiedener Firmen und Freelancern wichtig.In der Regel benötigt man zwei Sichten:
Die Projektinnensicht, auf der detailliert festgehalten ist, wer an welcher Aufgabe wie lange gearbeitet hat.Die Außensicht, die einem Auftraggeber gegenüber als Abrechnungsgrundlage dient.
Solche Sichten können sich unterscheiden:Die Granularität der Aufgaben, die ausgewiesen werden. Manchmal ist es auch nötig, nach außen andere Aufgaben auszuweisen als tatsächlich durchgeführt werden. Z. B.: Ausweisen von Reisekosten und -zeiten.Die Maßeinheiten der Abrechnung: Tage, Wochen oder Stunden. Festlegung, mit wie vielen Stunden ein Tag angesetzt wird: 7,7h (38,5h-Woche), 8h (40h-Woche), 9h oder 10h.
Projektmanagement M3 -
Projektvorbereitung
116
Tipps für das Projektcontrolling
Gerade wenn noch weitere Firmen (z. B. Freelancer, etc.) am Projekt teilnehmen, ist man verleitet, neue Sichten zu definieren. Auch wenn sich die Umrechnungsregeln einfach anhören mögen, bringt man leicht unnötige Komplexität in das Projekt.Im Controlling nicht zu fein erfassen wollen. Die Aufwände sollten sich noch in Tagen erfassen lassen, nicht in Stunden.Die Kontenstruktur orientiert sich an den Arbeitspaketen im Projektplan.
Projektmanagement M3 -
Projektvorbereitung
117
Kick-Off Meeting
Ziele des Kick-OffsDas Team auf ein gemeinsames Ziel einschwören.Bewussten Startpunkt für die Projektarbeit setzen: „Jetzt geht‘s los!“Teambuilding: es ist wichtig, dass sich Projektmitarbeiter als Team verstehenTeam über die wichtigsten Inhalte der Projektinitialisierung informieren, auf Stand zum Arbeiten bringen.
Inhalte des Kick-OffsProjektziele, Inhalt des ProjektauftragsProjektstrukturProjektvorgehen und Planung kommunizieren: wichtige MeilensteineWichtige Standards festlegenVerantwortlichkeiten, Rollen kommunizieren, OrganigrammVerhaltens- und Kommunikationsregeln des Teams, ggf. erarbeiten.
Projektmanagement M3 -
Projektvorbereitung
118
Durchführung des Kick-Offs
Dauer des Kick-Offs: ca. ½ - 1 TagModeration durch ProjektleiterTipps:
Früh genug darum kümmern, dass alle am Kick-Off teilnehmen könnenGut vorbereitet sein: Präsentation vorbereiten, nicht darauf verlassen, dass man die Inhalte aus der Initialisierung immer noch präsent hatBei Teams mit unterschiedlichem Erfahrungshintergrund die grundlegende Begriffe klarstellen
z. B. Begrifflichkeiten für elementare Tätigkeiten (Fachkonzept, Pflichtenheft, etc...)Spezialbegriffe des Projektmanagements: CR, QM-Plan, Projektstrukturplan, etc.
Das Meeting mit einem informellen Teil zu verbinden, z. B.:anschließendes, gemeinsames EssenBeieinandersein an Stehtischen im FoyerGute Gelegenheit, einen persönlichen Draht zu entwickeln und Meinungen zu hören, die die Leute in größerer Runde nicht äußern wollen
Meeting extern durchführen, z. B. in Tagungshotel
Projektmanagement M3 -
Projektvorbereitung
119
Nachbereitung des Kick-Offs
Zumindest ein Protokoll machen und Ergebnisse des Kick-Offs konservierenEin Protokoll ist ein gutes Symbol: Protokolle werden auch im weiteren Projekt benötigt, also gleich mit gutem Vorbild voran gehen. Protokolle erstellt und verschickt man zeitnah.Mit Folien zusammen per Email an die Teilnehmer verschicken odergleich die vorhergesehene Stelle auf der Teamablage nutzen
Projektmanagement M3 -
Projektvorbereitung
121
Projektabschluss und Touch Down
Formaler Projektabschluss: Definierte Beendigung eines ProjektsErreichen des ProjektzielsAbbruch eines Projekts
Prozessabschluss hat unterschiedliche Dimensionen:Produktdimension:
Sicherung der Produkte und ErgebnisseVorbereitung Softwarepflege und ÄnderungVorbereitung der Wiederverwendung/Verbreitung der Ergebnisse
Projektdimension:Freigeben von Ressourcen und PersonalRechenschaftsberichte erstellenProjekt auflösen
Projektabschluss umfasst Abnahme durch Auftraggeber und (internen) Touch Down
Projektmanagement M3 -
Projektvorbereitung
122
Projektabschluss: Abnahme
Formale Abnahme durch AuftraggeberAbnahme ist Hauptpflicht des AuftraggebersAbnahmekriterien und Vorgehensweise für die Abnahme sind bereits zu Beginn des Projekts definiert worden (wenn nicht, wird‘s jetzt schwierig...)Abnahme ist Basis für die Übergabe an die übernehmende Organisation/AbteilungHat ggf. auch rechtliche Auswirkungen (bei Zusammenarbeit mit externen Partnern)Achtung: Abnahme erfolgt i.d.R. vor einer endgültigen Bestätigung des Business Cases (mit allen Konsequenzen)
Projektmanagement M3 -
Projektvorbereitung
123
Projektabschluss: Abnahme
Zweigliedriger Abnahmebegriffkörperliche Entgegennahme und Billigung der Leistung
2 mögliche VorgehensweisenProjektbegleitende Abnahme (dringend empfohlen)„Big bang“ (manchmal nicht anders machbar)
Verfahren und Detailvorgehensweise muss vor der Abnahme bekannt sein (auch Testdaten etc.)
Projektmanagement M3 -
Projektvorbereitung
124
Projektabschluss: Abnahmekriterien
AbnahmekriterienFür die Abnahme wird die Übereinstimmung mit den sog. Annahmekriterien geprüftEinhaltung von Planungs- und ManagementprozessenDefinition der VerifikationsmethodenDefinition der Zeitdauer der AbnahmeVereinbarung von FehlerklassenZeitdauer für die Behebung von Problemen
Wichtig:Allen Beteiligten muss klar sein, was Abnahme heißt und was die Regeln sind!
Projektmanagement M3 -
Projektvorbereitung
125
Projektabschluss: Abnahmephasen
Abnahmephasen:Überprüfung und Vollständigkeitskontrolle des vom Auftragnehmer gelieferten Programms einschl. DokumentationInstallation und anschl. Test in TestumgebungPerformancetests auf Basis vereinbarter MengenprofileTest des störungsfreien Wiederanlaufs nach Abbruch oder Stromausfall
Auftraggeber trägt:Verantwortung für Aufbau und Betrieb TestumgebungVerantwortung für Testfälle und -daten
Projektmanagement M3 -
Projektvorbereitung
126
Projektabschluss: Rechtliche Auswirkungen
Rechtliche AuswirkungenVermutung der vollständigen LieferungMangelausschluss (§ 640 II BGB)Untersuchungs- und Rügepflichten (§ 377, 381 II HGB)Mängelbeseitigungs- statt ErfüllungsanspruchBeweislastumkehrGefahrenübergangNutzungsrechtseinräumungVerschuldensunabhängiger Zinsanspruch (§ 641 II BGB)Fälligkeit des Vergütungsanspruchs (§ 641 BGB)Verjährungsbeginn (§ 638 BGB)
Projektmanagement M3 -
Projektvorbereitung
127
Projektabschluss: Bemerkungen
SomitHauptproblem bei der Abnahme ist i.d.R. kein rechtliches sondern ein psychologisches beim AuftraggeberFormaler Teil muss sein, aber dabei partnerschaftliches Verhältnis zwischen Projekt und Auftraggeber beachtenGutes Änderungsmanagement zahlt sich (spätestens) hier ausKriterien und Verfahren möglichst früh klären und festlegen (Abnahmephase ist Stress...)Bestmögliche Betreuung der zur Abnahme berechtigten Mitarbeiter des Auftraggebers sicherstellenSchnelle Reaktion auf auftretende Probleme
Projektmanagement M3 -
Projektvorbereitung
128
Touch-Down
Ziele des Touch-Downs: Nach abgeschlossenem Projekt ein Resümee ziehen und für das nächste Mal lernen.Vorbereitung des Touch-Down-Meetings
Besondere Erfahrungen des Projektteams werden konsolidiert und festgehalten
Nachkalkulation: Die tatsächlichen Aufwände mit den geschätzten Aufwänden aus der Angebotsphase verglichenArchivierung der Projektergebnisse: nicht einfach auf einem Laufwerk liegen lassen, irgendwann sind sie weg.
Projektmanagement M3 -
Projektvorbereitung
129
Touch-Down Meeting
Gegenstück zum Kick-Off: Das offizielle Ende der ProjektdurchführungTeilnehmer:
alle ProjektbeteiligtenBei Auftraggeber/Auftragnehmer-Situation: gern auch beteiligte Mitarbeiter des Auftraggebers, dann aber noch einen Auftragnehmer-internen Touch-Down machen
In einem Rückblick werden Stärken und Schwächen des Projekts und Probleme einzelner diskutiert.Im Projektrückblick werden die Leistungen in der Projektdurchführung kritisch betrachtet.Unangenehm? Trotzdem machen!
Projektmanagement M3 -
Projektvorbereitung
130
Exkurs: Werkleistungen und Dienstleistungen
Projektmanagement M3 -
Projektvorbereitung
Werkvertrag für Gewerkegeschuldet ist ein Werk, der ProjekterfolgGeld gibt‘s für den ErfolgDas Risiko liegt beim AuftragnehmerAber: der Auftragnehmer hat die Freiheit zu entscheiden, wie er den Erfolg erzielt.
Dienstvertrag für Dienstleistungen
Geschuldet ist die TätigkeitGeld gibt es, wenn man arbeitet, auch wenn der Projekterfolg nicht eintritt.Das Risiko liegt beim AuftraggeberAuftraggeber kann Vorgehensweise, Arbeitsort und -zeiten bestimmen. Abwertende Bezeichnung: BodyLeasing
131
Exkurs: Werkleistungen
Abnahme für das GewerkÜblich: Abnahme dadurch, dass ein System produktiv genutzt wird „konkludente Abnahme“Nach der Abnahme: Gewährleistung (2 Jahre nach Abnahme)Abschlagszahlungen auf Zwischenergebnisse (als Vorschuss auf dieGesamtvergütung)Oft: Werkvertrag zum Festpreis, Dienstvertrag nach Aufwand
muss aber nicht zwingend so sein.
Projektmanagement M3 -
Projektvorbereitung
132
Zusammenfassung (1)
Die Projektvorbereitung umfasst Projekt-Idee und StudieBeauftragung mit Ausschreibung, Angebot und AuftragProjektinitialisierung undKick-Off-Meeting
Eine Studie dient dem Nachweis von Machbarkeit und Nutzen eines Software-Projekts.Ein Auftrag sollte enthalten
Projektleiter, Auftraggeber Kurzbeschreibung und Ziele des Projekts Zu erbringende Leistungen und Ergebnisse, häufig als „Technischer Anhang“RahmenbedingungenAbhängigkeiten von anderen Projekten und Personen, ZulieferungenStart, Ende, Meilensteine
Projektmanagement M3 -
Projektvorbereitung
133
Zusammenfassung (2)
Tätigkeiten während der Projektinitialisierung umfassenKlärung der Ziele und QualitätskriterienFestlegung der Organisation des Projekts und der Projektstruktur (im Projektstrukturplan) Validierung der Schätzung Grob- und Feinplanung für die ersten SchritteEtablierung der Infrastruktur und der Struktur für das Controlling
Ein Kick-Off-Meeting ist wichtig umdas Team auf ein gemeinsames Ziel einschwören undwichtige Ziele, Verantwortlichkeiten, Standards etc zu kommunizieren
Das Projektende tritt ein bei Erreichen des ProjektzielsAbbruch eines Projekts
Der Projektabschluss umfasst Abnahme durch Auftraggeber und (internen) Touch Down, um ein Resümee ziehen und für das nächste Mal zu lernen
Projektmanagement M3 -
Projektvorbereitung
135
Ziele
Generelles Vorgehen bei Schätzungen kennen lernenGrundlegende Schätzmuster und Maße zur Systemkomplexität kennen lernenSchätzverfahren für den Aufwand eines Software-Projekts kennen lernen und beurteilen
Delphi-MethodeFunction PointsCoCoMo
Projektmanagement M4 -
Schätzung
136
Schätzverfahren
„Was man nicht misst, das kann man nicht steuern.“[Tom de Marco, Controlling Software Projects, 1982.]
Messung von Softwaresystemen:Zu Projektbeginn: Projektplanung (Schätzung)Bei Durchführung: Projektstatus/Projektsteuerung
Ziel des Schätzens:Bestimmung des Entwicklungsaufwands
RealisierungsaufwandRealisierungszeit
Abhängig von Systemkomplexität und ProduktivitätMöglichst vor Systemrealisierung
Prinzipielle Strategie beim Schätzen: per AnalogieSchätzungen sind „unfair“:
Passieren zu einem sehr frühen ZeitpunktMan weiß wenig über die AufgabeAuf die Zahlen wird man später festgenagelt
Projektmanagement M4 -
Schätzung
137
Herangehensweisen
Von den Arbeitspaketen zur AufwandszahlSchätzung der einzelnen ArbeitspaketeSumme ergibt GesamtaufwandSchätzung als Grundlage für Aufwand
Vom fixierten Aufwand zu den ArbeitspaketenFrage: Was darf es denn insgesamt kosten?Projekt so aussteuern, dass es im Kostenrahmen bleibtAufgaben werden nur so „gut“ erledigt, wie Geld da istSchätzung zur Prüfung der Machbarkeit
Faustregeln:Hochinnovative Projekte kann man nicht schätzenNur normales Vorgehen lässt sich schätzen, radikales nichtProjekte mit fließenden Anforderungen kann man nicht verlässlich schätzen
Projektmanagement M4 -
Schätzung
138
Auswirkungen einer „falschen“
Schätzung
Zu hohe SchätzungIst kaum festzustellen. Jedes Projekt schöpft den Kostenrahmen voll aus.Gefahr: Business Case rechnet sich nicht, bzw. Projekt wird an Mitbewerber verloren.
Zu geringe SchätzungGeld reicht nicht, Projekt kann im Budget nicht durchgeführt werden
Das Projektmanagement hat extrem großen Einfluss auf die verbrauchten Aufwände eines Projekts. Im Nachhinein ist schwer festzustellen, ob der geschätzte Kostenrahmen realistisch war.
Projektmanagement M4 -
Schätzung
139
Motivation für eine Schätzung
Wenn eine Schätzung so fehlerbehaftet und schwierig ist, warum schätzt man dann überhaupt?
Auch eine „falsche“Schätzung ist besser als ein kompletter BlindflugAuch Schätzen ist ein Prozess: sobald erste Erfahrungen und ermittelte Aufwände im Projekt vorliegen, wird nachgeschätzt und die Schätzung korrigiertDie Schätzung wird im Laufe des Projekts immer genauer.
Projektmanagement M4 -
Schätzung
140
Einflussfaktoren auf den Aufwand (wichtigste Faktoren)
Projektmanagement M4 -
Schätzung
Umzusetzende Fachlichkeit (funktional)
MaskenDruckstückeBerechnungenzu berücksichtigende FehlersituationenMigrationen aus AltsystemenAbhängigkeit von anderen Systemen
Technologische Umsetzung, nicht-funktionale Anforderungen
Performance, AntwortzeitverhaltenArchitekturSystemplattform, Basis-Technologien
Projektmanagement-FaktorenTeam
MitarbeiterqualifikationErfahrungEingespieltes Team
ProjektorganisationProjektvorgehen, MethodikUnterstützung durch Tools
Sonstige FaktorenAuftraggeberAufwände steigen mit Größe der Aufgabe
141
Generelles Vorgehen bei der Schätzung
Eine gute Vorbereitung ist elementar für die SchätzungKomplettieren und Strukturieren der Schätzgrundlage
(osintots – oh shit, I never thought of this)
Sammeln aller Faktoren
Nachschätzen und aus Projekterfahrungen lernen ist ein stetiger Kreislauf während des Projekts
Projektmanagement M4 -
Schätzung
142
Schätzmuster
Schätzungen werden fast immer aus einer Kombinationen der folgenden grundlegenden Schätzmuster hergeleitetInsbesondere beruhen auch ausgefeilte Schätzmethoden wie Function Points, CoCoMo oder Delphi auf diesen Mustern, meist ergänzt um konkrete Zahlenwerte für Schätzformeln.
Schätzmuster:Schätzen durch VergleichSchätzen durch Zerlegung
Anforderungendes Entwurfs
Schätzen durch ExpertenSchätzen mit KorrekturfaktorenSchätzen mit Stellvertretergröße
Projektmanagement M4 -
Schätzung
Schema für Schätzmuster:Problem/KontextVorgehensideeVorteile, Nachteileevtl. Varianten, Anmerkungen
143
Schätzen durch Vergleich
Problem/Kontext:Wenn keine bessere Schätzmethode verfügbar ist, aber Erfahrungen mit Entwicklung ähnlicher Dinge und deren Aufwände noch
bekannt sind
Vorgehensidee:Wähle aus dem Erfahrungsschatz das ähnlichste Ding aus und benutze dessen Aufwand als Schätzung
VorteileEinfach, schnell
NachteileEvtl. zu wenig Erfahrung; Ähnlichkeitsmaß
unklar
Variante:Wähle mehrere Ähnlichste und mittele die Schätzung
Anmerkung:Alle anderen Schätzverfahren basieren letzten Endes auf Vergleich (explizit oder intuitiv)
Projektmanagement M4 -
Schätzung
144
Schätzen durch Zerlegung (Anforderungen)
Problem/Kontext:Wenn Anforderungen wenig voneinander abhängen, d.h. das System nur einen kleinen Kern aufweist
Vorgehensidee:Schätze Aufwand pro Anforderung einzeln; summiere
Vorteile: Starke Reduktion der Komplexität
Nachteile:Nur in wenigen Anwendungsgebieten sinnvoll,Meist ist der Kern für den Aufwand sehr relevant,Aufwandsmessungen liegen selten in dieser Form vor.
Anmerkung:Das „Function Point" Schätzverfahren beruht auf diesem Muster und ist für einfache Informationssysteme sehr bewährt.
Projektmanagement M4 -
Schätzung
145
Schätzen durch Zerlegung (Entwurf)
Problem/Kontext:Wenn die Architektur des Systems bereits erkennbar ist
Vorgehensidee:Schätze den Aufwand für die Subsysteme und addiere
Vorteile:Im Prinzip ist eine sehr genaue Zerlegung und Schätzung möglich
Nachteile:Irrtümer über Architektur möglich (insbes. Teile übersehen)Vernachlässigt Aufwand für Integration und nichtfunktionale Anforderungen
Anmerkung:Zumindest grobe Zerlegung wird in der Praxis fast immer eingesetzt.Oft läuft ein großer Teil der Zerlegung auf bloße Zählung hinaus, z.B. Anzahl "Dialoge" (Bildschirmmasken)
Projektmanagement M4 -
Schätzung
146
Schätzen durch Experten
Problem/Kontext:Wenn es Erfahrungen und Aufwandsdaten nicht schriftlich, wohl aber im Kopf von Experten gibt
Vorgehensidee:Bitte jede/n Experten/in separat um eine SchätzungLasse die Experten Ihre Schätzungen und Begründungen diskutieren und modifizierenResultat: Konsens über einen geschätzten Aufwandsbereich
Vorteile: Sehr breitbandig, bezieht enorm viele Faktoren einUnsicherheit der Schätzung wird ggf. klar sichtbar
Nachteile:Kann bei "Group think" zu dramatisch falschen Ergebnissen führen, die scheinbar vertrauenswürdig sind
Variante:Black Box Schätzung nur eines/r Experten/in
Anmerkung:Das „Delphi"
Schätzverfahren beruht auf diesem Muster. Projektmanagement M4 -
Schätzung
147
Schätzen durch Experten (mit Kombination von Schätzungen)
Problem/Kontext:Wenn mehrere Schätzungen verfügbar sind, deren Qualität aber unklar ist
Vorgehensidee:Kombiniere die Schätzungen zu einer (durch Bereichsbildung, Mittelung, Zurückweisung von Ausreißern etc.)
Vorteile:Erhöht die Robustheit der Schätzung
Nachteile:Gibt es systematische Fehler in vielen der Schätzungen, dann führt das Kombinieren in die Irre
Anmerkung:Das „Delphi"
Schätzverfahren wendet meist die Kombination von Schätzungen an.
Projektmanagement M4 -
Schätzung
148
Schätzen mit Korrekturfaktoren
Problem/Kontext:Wenn ein ähnliches Ding zum Vergleich verfügbar ist, es aber zum jetzigen Ding (identifizierbare) Unterschiede gibt
Vorgehensidee:Benutze den Aufwand des ähnlichen Dings und korrigiere ihn für jeden Unterschied um einen prozentualen Faktor herauf/herunter.Die einzelnen Faktoren werden wiederum geschätzt oder aus Erfahrungen entnommen.
Vorteile: Recht flexibel
Nachteile:Bei zu vielen Korrekturen wird das Ergebnis dubios.Bei zu wenig Erfahrung über einzelnen Korrekturfaktor ebenfalls.
Anmerkung:Das „CoCoMo" Schätzverfahren beruht hauptsächlich auf diesem Muster
Projektmanagement M4 -
Schätzung
149
Schätzen mit Stellvertretergrößen
Problem/Kontext:Wir besitzen Aufwandsdaten nur über andere Erfahrungsgrößen als die, die wir schätzen wollen, z.B. Produktivität in Anzahl an Zeilen von Code (Lines of Code, LoC) pro Personenmonat, aber diese Erfahrungsgröße (oder etwas Verwandtes) lässt sich schätzen
Vorgehensidee:Schätze nicht den Aufwand, sondern die schätzbare Größe und rechne dann um.
Vorteile: Evtl. ist Stellvertretergröße anschaulicher und besser zu schätzen
Nachteile:Evtl. wird Kontextabhängigkeit übersehen, z.B. Abhängigkeit der Produktivität an Zeilen von Code von der Programmiersprache
Anmerkung:Das „CoCoMo" Schätzverfahren verwendet die „Anzahl der Zeilen von Code" als Ausgangspunkt
Projektmanagement M4 -
Schätzung
150
Schätzverfahren: Delphi-Methode
Charakteristikum: Systematische Befragung von mindestens zwei Experten, die aus Erfahrung Voraussagen über den Zeit/Ressourcen-Bedarf einzelner Projektaktivitäten machen.
Varianten: Standard Delphi-Verfahren:
Befragung anonymBreitband Delphi-Verfahren:
Schätzergebnisse werden gegenseitig bekanntgegeben, damit Resultate diskutiert und ggf. korrigiert werden könnenHäufig Schätzung im Rahmen einer Schätzklausur
Projektmanagement M4 -
Schätzung
151
Schätzklausur
Phase 1: AuftragsdefinitionAuftraggeber, Kunde, Verantwortliche und Durchführende festlegen Ziel definierenAufgaben analysieren (Prozesszerlegung)
Phase 2: SchätzungsvorbereitungGeeignete Leute einladenFachleute, Verantwortliche, Durchführende2 Stunden ansetzenExcel-Sheet vorbereiten
Phase 3: SchätzungProjekt und Projektplan vorstellen, Aufwands- und Zeitplan austeilen, ggf. korrigieren (lassen)Jeder schreibt seine Schätzungen auf Ansage aufJeder sagt seine Schätzungen auf Ansage anExtrema diskutieren, ggf. entfernenMittelwerte bildenSumme bilden
Projektmanagement M4 -
Schätzung
152
Schätzklausur
Projektmanagement M4 -
Schätzung
Meistens gibt es anschließend noch eine Phase 4, in der die Schätzung interessengeleitet verändert wird.
153
Zwischenfazit
Projektmanagement M4 -
Schätzung
Sind Schätzungen notorisch ungenau –
wieso?
In wohlgeordneten Prozessen sind Schätzungen von einem zum nächsten Mal vergleichbar.
Man kann also aus Fehlern lernen.
Nicht so bei ungeordneten Prozessen.
Hier werden Fehler versteckt oder verdeckt.
154
Schätzverfahren: Funktionspunkte (Function Points -
FP)
Historie:Eingeführt 1979 von Alan Albrecht (IBM). Seit 1986 verwaltet und normiert durch die International Function Point User Group (IFPUG); Gegenstand der ISO-Standards 10926 und 14143-1:1998.
Idee:Schätzung des Arbeitsaufwands in Mann-Stunden anhand der vom Kunden gewünschten Funktionen
Vorgehen:Zähle und klassifiziere (als einfach, mittel, komplex) wenige Arten von Anforderungen, vergebe dafür jeweils Funktionspunkte (FP), summiere diese und bestimme Aufwand daraus per empirischem Umrechnungsfaktor (unangepasste FP)FP ist also ein StellvertreterverfahrenAnschließend kann man noch Projektumstände berücksichtigen, um die Schätzung anzupassen (angepasste FP)Hinzu kommt also ein Korrekturfaktorverfahren
Projektmanagement M4 -
Schätzung
155
Unangepasste FP (UFP)
Messverfahren: Klassifiziere Anforderungen in Eingaben Eingabemasken, für die Datensätze eingegeben werden könnenAusgaben Datenpräsentationsdarstellung ("Report")Abfragen Eingabe eines Suchkriteriums plus Anzeige des GefundenenDatenbestände Intern verwalteter Datenbestand (z.B. DB-Tabelle)Referenzdaten Schnittstelle/Datenformat zur Anbindung an anderes System
Bewerte jedes Element als einfach, mittel oder komplex und bilde die gewichtete Summe nach folgender Tabelle:
Item
einfach mittel komplexEingaben 3 4 6Ausgaben 4 5 7Interaktionen 3 4 6Datenbestände 7 10 15Referenzdaten 5 7 10
Projektmanagement M4 -
Schätzung
156
Angepasste FP
FP = UFP * TKwobei der Korrekturfaktor Technische Komplexität (TK)
gebildet wird durch
TK
= 0.65+0,01 Σi=1..14 Fi (d.h. 0.65 <= TK <= 1.35)
und Fi Korrekturwerte gemäß dem Schwierigkeitsgrad gewisser nichtfunktionaler Anforderungen darstellen:
F1
Reliable back-up and recovery
F2
Data communicationsF3
Distributed functions
F4
PerformanceF5
Heavily used configuration
F6
Online data entryF7
Operational ease
F8
Online updateF9
Complex interface
F10
Complex processingF11
Reusability
F12
Installation easeF13
Multiple sites
F14
Facilitate changehaben je einen Wert zwischen 0 und 5 (für nicht
bzw. sehr stark vorhanden).
Projektmanagement M4 -
Schätzung
157
Technische Korrekturfaktoren Übersetzung und Erläuterung
Projektmanagement M4 -
Schätzung
Faktor
Originalname
Erläuterung
F1
Reliable back-up & recov.
Anforderungen an die DatenintegritätF2
Data communications
Datenaustausch mit UmsystemenF3
Distributed functions
Applikationen auf mehr als einem RechnerF4
Performance
Leistungsanforderungen
F5
Heavily used config.
Starke KonfigurationsabhängigkeitenF6
Online data entry
Interaktive BenutzungF7
Operational ease
InteraktionsqualitätF8
Online update
unmittelbare Aktualisierung (WYSIWYG)
F9
Complex interface
komplexe BenutzerschnittstelleF10
Complex processing
algorithmisch komplexe VerarbeitungF11
Reusability
geplante Wiederverwendung/WartungF12
Installation ease
Installationskomfort
F13
Multiple sites
mehrere (unterschiedliche) InstallationenF14
Facilitate change
Unterstützung der Anpassung in der Wartung
158
Berechnung am Beispiel „Ausleihmaske“
Projektmanagement M4 -
Schätzung
Lesernummer
Name
Vorname
Geburtsdatum
Stammdaten
OK Neu
Kontodaten
Titel Signatur Frist
Stammdaten Kontodaten Bestand
AusleihsystemMögliche Interaktionen:1) Ausweis scannen2) Konto-
und Stammdaten
abfragen durch Eingabe der Lesernummer 3) Stammdaten eingeben
159Projektmanagement M4 -
Schätzung
Berechnung am Beispiel „Ausleihmaske“
1.) Elemente zählen
(1)
(2)
(3)
Eingaben
1x einfach -
1x mittel
Ausgaben
-
1x mittel -Abfragen
-
-
-
Referenzdaten
1x einfachDatenbestände
3x einfach
160Projektmanagement M4 -
Schätzung
Berechnung am Beispiel „Ausleihmaske“
2.) UFP berechnen
(1)
(2)
(3)
Eingaben
1x 3
-
1x 4Ausgaben
-
1x 5 -
Abfragen
-
-
-
Referenzdaten
1x 5Datenbestände
3x 7
UFP = 3 + 4 +5 + 5 +21 = 38
161
Berechnung am Beispiel „Ausleihmaske“
Projektmanagement M4 -
Schätzung
3.) Technische Faktoren schätzen2 F1
Reliable back-up & recovery1 F2
Data communications2 F3
Distributed functions1 F4
Performance0 F5
Heavily used configuration3 F6
Online data entry5 F7
Operational ease3 F8
Online update2 F9
Complex interface0 F10
Complex processing1 F11
Reusability1 F12
Installation ease4 F13
Multiple sites1 F14
Facilitate change
Technische Komplexität TK = 0,65+0,01 Σi=1..14 Fi
hier alsoTK
= 0,65 + 0,01 * 26= 0,91
FP = TK * UFP Also im Beispiel
FP = 0,91 * 38 = 34,58
Falls in einer Firma 1 FP 2,1 PT entspricht, erhält man ca. 72 PT;
d.h. bei 18 PT pro Monat (220 PT pro Jahr) einen Entwicklungsaufwand von etwa 4 PM
162
Ist das Produktivitätsparadoxon behoben?
Projektmanagement M4 -
Schätzung
Sprache
LoC / FP
Komplexität
niedrig
mittel
hoch
Assembler 200
320
450
C
60
128
170Fortran
75
107
160
Cobol
65
107
150C++
30 53 125
Smalltalk
15 21 40
LoC / Mannmonat relativ konstant.
=> In einer höheren Programmiersprache schafft ein Programmierer mehr Funktionalität pro Zeiteinheit.
=> Es gibt Produktivitätsunter- schiede zwischen
Programmiersprachen.
Damit ist ein Teil des Produktivitätsparadoxons behoben, aber es gibt noch andere Einflussgrößen: Das Verhältnis LoC/FP hängt z.B. auch von der System-komplexität insgesamt ab. Aber FPs sind schon deutlich besser als LoC.
Erfahrungswert: Die Erstellung eines Function Points kostet etwa
1.500 €.
163
Schätzverfahren: CoCoMo (Constructive Cost Modeling)
Entwickler: Barry Boehm1981 CoCoMo I, ab 1995 CoCoMo II
Idee:Schätzung der Projektgröße Size in LOC (Lines of Code) bzw. KDSI (Kilo Delivered Software Instructions), d. h. ohne Kommentare.Gleichungen:
Aufwand: PMDEV
= a * Sizeb
* mLaufzeit: TDEV = 2,5 * PMDEV
d
PMDEV Entwicklungsaufwand in PM und TDEV Projektlaufzeita, b, d, m unternehmensspezifisch zu kalibrierende Faktorenb beschreibt überproportionale Auswirkung großer Projekte m dient zur Berücksichtigung von Korrekturfaktoren für Produkt, Vorgehen und die Qualität von Entwicklern
Projektmanagement M4 -
Schätzung
Barry Boehm*1935PhD UCLA,Prof. USC,Erfinder vonV-
und
Spiralmodell,CoCoMo
164
CoCoMo I
Differenzierung in Projekt-KlassenEinfach (Organic Mode)
einfache Anwendungssoftware, Größe <50 KDSIeingespieltes Team, bekannte Umgebung, wenig NeulandPMDEV = 2,4 * (KDSI) 1,05 * mTDEV = 2,5 * PMDEV
0,32
Mittelschwer (Semi-detached Mode)mittelschwere Projekte, Größe typischerweise <300 KDSIPMDEV = 3,0 * (KDSI) 1,12 * mTDEV = 2,5 * PMDEV
0,35
Eingebettete Systeme (Embedded Mode)schwierige Projekte, beliebige Größestarker Kosten-, Termindruck, viel NeulandPMDEV = 3,6 * (KDSI) 1,2 * mTDEV = 2,5 * PMDEV
0,38
Projektmanagement M4 -
Schätzung
166
Einflussfaktoren, Kostentreiber
ProduktRELY: geforderte Zuverlässigkeit der SoftwareDATA: Größe der DatenbasisCPLX: Komplexität des Produktes
ComputerTIME: benötigte RechenzeitSTOR: Nutzung verfügbarer SpeicherplatzVIRT: Änderungshäufigkeit der SystembasisTURN: Bearbeitungszyklus
ProjektMODP: Verwendung moderner EntwicklungsmethodenTOOL: Verwendung von ToolsSCED: Anforderungen an die Entwicklungszeit
PersonalACAP: Analysefähigkeit der ProjektmitarbeiterAEXP: Erfahrung der Mitarbeiter im ArbeitsgebietPCAP: Programmierfähigkeit der MitarbeiterVEXP: Erfahrung der Mitarbeiter in der SystemumgebungLEXP: Erfahrung der Mitarbeiter in der Programmiersprache
Projektmanagement M4 -
Schätzung
Der Korrekturfaktor m dient zur Berücksichtigung unternehmensspezifischer und projektspezifischer Kostenfaktoren (cost drivers):m = m1 * m2 * …
* m15
MMDEV
= a * KDSIb
* m
168
CoCoMo II
COCOMO II (Boehm et al. 2000) ist eine Weiterentwicklung von COCOMO zu einem 3-Stufen Modell, das bei Entwicklungsfortschritt immer genauere Schätzungen ermöglicht.
COCOMO II unterscheidet:Frühe Entwicklungsphasen (Early prototyping level)
Schätzung für Projekte mit Prototyperstellung und hoher Wiederverwendungbasierend auf Anwendungspunkten (application points) und einfacher Formel für die Aufwandsschätzung
Frühe Entwurfsphase (Early design level)Schätzung nach abgeschlossenen Festlegung der Systemanforderungen und einem ersten Entwurf basierend auf Funktionspunkten, die in LOC übersetzt werden.
Nach-Architektur-Phase (Post-architecture level)Schätzung nach Erstellung der Architektur basierend auf LOC
Projektmanagement M4 -
Schätzung
169
Nach-Architektur-Phase (Post-architecture level)
Wir betrachten hier nur die Post-Architektur-Phase (für eine kurze Beschreibung der anderen Phasen siehe Anhang). Neue universelle Grundgleichungen
Aufwand PM = 2,45 * KSLOCB * MEntwicklungszeit T = 2,66 * PM 0,33 + 0,2·(B - 1,01)
wobeiKSLOC: Kilo Source Lines of CodeWachstumsfaktor B = 1,01 + 0,01 Σ SFi
SFi sind insgesamt fünf Skalierungsfaktoren (scaling factors)M ist das Produkt der insgesamt 17 Kostenfaktoren (effort multipliers)
Projektmanagement M4 -
Schätzung
170
COCOMO II: Skalierungsfaktoren (scaling factors)
Faktor Sehrgering
Gering Nominal Hoch Sehrhoch
Extrahoch
Erfahrung 4,05 3,24 2,43 1,62 0,81 0Flexibilität 6,07 4,86 3,64 2,43 1,21 0Risikoumgang 4,22 3,38 2,53 1,69 0,84 0Zusammen-
arbeit4,94 3,95 2,97 1,98 0,99 0
Prozessreife 4,54 3,64 2,73 1,82 0,91 0
Projektmanagement M4 -
Schätzung
Erfahrung: Vertrautheit des Entwicklungsteams mit dem ProduktFlexibilität bezüglich der Einhaltung von Anforderungen / VorgabenRisiko-Umgang: Qualität des RisikomanagementsGüte der Zusammenarbeit zwischen allen ProjektbeteiligtenReife des Entwicklungsprozesses
171
Beispiel
Eine Firma will ein Projekt in einem neuen Gebiet durchführen. Der Kunde hat keinen speziellen Entwicklungsprozess gefordert und keine Zeit für die Risikoanalyse eingeplant. Die Firma besitzt eine Prozessreife der Stufe 1 (nach CMM – siehe später).
Skalierungsfaktoren:Erfahrung: neues Projekt S. gering (4,05)Prozessflexibilität Kunde lässt Freiheit S. hoch (1,21)Architecture/risk resolution Keine Risikoanalyse S. gering (4,22)Teamzusammenhalt Neues Team Nominal (2,97)Prozessreife CMM Level 1 Gering (3,64)Summe 16,19
Der Wachstumsfaktor ist also 1,01 + 0,16 = 1.17
Projektmanagement M4 -
Schätzung
174
Schätzverfahren in der Praxis
Oft sind Schätzungen gefragt, noch bevor man auch nur halbwegs den Projektinhalt versteht
und dennoch werden die Schätzergebnisse anschließend verbindlichViele Firmen sammeln Aufwandsdaten nicht
Dann hat man sie nur in den Köpfen der Entwickler/ProjektleiterDas ist sehr ungenau!
Oft wird das Ergebnis der Schätzung nicht akzeptiertsondern es gibt politischen Druck, die Schätzung zu verringern,aber die künstlich verminderte Schätzung wird trotzdem zur verbindlichen Vorgabe an das Projektteam.Dramatischste Ausprägung: "Todesmarsch-Projekte„
Schätzung liegt 50% oder mehr unterhalb "vernünftiger" Werte
Projektmanagement M4 -
Schätzung
175
Zusammenfassung (1)
Ziel des Schätzens ist die Bestimmung des Entwicklungsaufwands abhängig von Systemkomplexität und Produktivität und zwar möglichst vor SystemrealisierungTypische Maße zur Systemkomplexität sind Lines-Of-Code (LoC) und Non-Comment-Source-Statements. Weitere Komplexitätsmaße sind Zyklomatische Zahl, Kopplung/Kohäsion, Vererbungstiefe.Schätzungen werden fast immer aus einer Kombinationen der grundlegenden Schätzmuster hergeleitet
Schätzen durch VergleichSchätzen durch Zerlegung (Anforderungen oder Entwurf)ExpertenschätzungSchätzen mit KorrekturfaktorenSchätzen mit Stellvertretergröße
Projektmanagement M4 -
Schätzung
176
Zusammenfassung (2)
Wichtige Schätzverfahren sind das Delphi-Verfahren, Function Points und CoCoMo
Das Delphi-Schätzverfahren ist eine Expertenschätzung, bei der Experten aus Erfahrung Voraussagen über den Zeit/Ressourcen-Bedarf einzelner Projektaktivitäten machen.Mit Function Points schätzt man den Arbeitsaufwand in Personenstunden anhand der vom Kunden gewünschten Funktionen; dieses Verfahren ist bei einfachen (Informations-) Systemen gut anwendbar.CoCoMo dient zur Schätzung der Projektgröße Size in LOC (Lines of Code) bzw. KDSI (Kilo Delivered Software Instructions),
CoCoMo I beruht auf der Schätzgleichung PMDEV
= a * Sizeb
* mCOCOMO II ist ein 3-Stufen Modell, das bei Entwicklungsfortschritt immer genauere Schätzungen ermöglicht
Projektmanagement M4 -
Schätzung
178
Ziele
Kennenlernen der wichtigsten Planungstätigkeiten und Arten von ProjektplänenLernen Netzpläne und Balkendiagramme zu erstellenLernen Grundzüge der Risikoplanung zu verstehenAufgaben der Personalplanung kennenlernen
©
Bernhard Bauer, all rights reserved 2007 178
179
Warum denn überhaupt planen?
Auch ein „falscher“ Plan ist besser als kein PlanAlternative: totaler BlindflugEin Plan zeigt einen Weg, wie man das Ziel erreichen kann. Er weist die Machbarkeit nach.Ein Plan ist die Grundlage, um ein Projekt zu steuern
Ohne Steuerung und Plan erkennt man erst zu Projektende, ob sich der Projekterfolg einstellt.Mit Steuerung: Gefährdungen sind früh erkennbar, man kann darauf reagieren
Ein Plan wird im Projektverlauf ständig besser und erhöht die Sicherheit, das Projekt zum Erfolg zu führen.
©
Bernhard Bauer, all rights reserved 2007 179
181
4 Schätzverfahren und Projektplanung 4.2 Projektplanung
Planungstechniken Ziele:
Überblick über den ProjektablaufVorbereitung der ProjektdurchführungZeitschätzung und TerminbestimmungPlanung der Vergabe von Ressourcen
Resultate dienen als:Entscheidungs-, Steuerungs- und Kontrollunterlagen;Inhalte:
Definition Aufgabe: Was ist zu tun?Definition Vorgaben/Hilfsmittel: Wie ist es zu tun?Definition Termine: (Bis) Wann ist es zu tun?Definition Verantwortung: Wer hat es zu tun?
181
182
Planung ist ein Prozess
Zitat aus der Praxis: „Damals haben wir mit viel Aufwand den Plan gemacht und nach zwei Wochen hat er schon nicht mehr gestimmt.“Eine Planung wird zu Projektbeginn erstellt und dann ständig verfeinert und angepasst.Eine Planung veraltet, sobald sie fertig ist. (Und manchmal auch schon, während sie erstellt wird)Eine Planung ist keine Vorhersage. Ein Projekt kann man nicht ausrechnen.Die Planung ist ein Werkzeug. Sie ist das wichtigste Arbeitswerkzeug des Projektleiters
©
Bernhard Bauer, all rights reserved 2007 182
184
„Designregeln“
für eine gute Planung
Teile und herrsche –Eine Planung hat eine Top-Down-Zerteilung.In ihr finden sich Stufen und Phasen des SE-Prozesses wieder. Sie sind durch Meilensteine getrennt.Geringe Abhängigkeiten –Bilde Arbeitspakete so, dass deren Abhängigkeiten voneinander gering sind.Wenig Nebenläufigkeit –Vermeide gleichzeitiges Arbeiten einer Person an verschiedenen Aufgaben.Klare Aufgaben –Die Ergebnisse der geplanten Aufgaben müssen klar sein, es muss klar sein, was das Erreichungskriterium ist.Wichtiges und Lücken zuerst –Fokussiere in der Planung zunächst auf die wichtigen und dann auf die unbekannten Aufgaben.
©
Bernhard Bauer, all rights reserved 2007 184
185
Ein guter Plan hat eine „Story“und muss „erzählt“werden
Wie jedes gut verstandene Konzept lässt sich auch ein Projektplan in wenigen Sätzen zusammenfassen. Wenn man das nicht kann, ist die Planung noch nicht klar genug.
„Erst machen wir A, dann B, dann C“. Ein zweites Team kümmert sich um D.„Meier bearbeitet Thema 1 und lernt dabei Schulze an. Dann übernimmt Schulze Thema 2 und Meier lernt Müller in Thema 3 an.“
Die Planung muss ständig kommuniziert werdenDie Planung gibt es im Detail und in der Übersicht
Detail z. B.: Excel, MS ProjectÜbersicht z. B.: PowerPoint
Die Planung kommunizierenIn den Teamräumen aushängenBei jedem Teammeeting wiederholenProjektstatus im Rahmen der Planung darstellen
©
Bernhard Bauer, all rights reserved 2007 185
186
Das Team muss hinter der Planung stehen
Einzelne Planinhalte mit den vorgesehenen Bearbeitern durchsprechen.Die Teammitglieder müssen die Planung als realistisch und machbar ansehen –das heißt nicht, dass sie bequem sein muss.
Bei Feedback: „Das schaffen wir nie“Kritik aus dem Team ernst nehmen!Nicht aus der Position des Projektleiters „überstimmen“Commitment zur Planung erzielen: Planung ändern oder Bedenken ausräumen.
Eine Planung, an die alle Teammitglieder glauben, gibt Sicherheit
©
Bernhard Bauer, all rights reserved 2007 186
187
Beispiel
ProjektkontextEin mittleres Softwareprojekt soll durchgeführt werden.Der Aufwand wurde vorab geschätzt.Es gibt im Jahr nur zwei Termine (Januar und Juli), zu dem das System eingeführt werden kann.Das zu erstellende System löst ein bestehendes System ab, eine Datenmigration ist notwendig.
FragestellungIst eine Einführung im Januar 2009 oder erst im Juli 2009 möglich?
©
Bernhard Bauer, all rights reserved 2007 187
188
Grobplanung
Ausgehend von der Aufwandsdimensionierung von 9 -10 PJ kann man nach dem Schlüssel (30-15-40-15) eine ungefähre Verteilung auf die Projektphasen vornehmen
fachliche Konzeption (30%) ca. 35 PMtechnische Konzeption (15%) ca. 15 PMImplementierung (40%) ca. 45 PMIntegration & Test (15%) ca. 15 PM
Bei einem Einführungstermin zum Juli 2009 und Beginn Oktober 2007: Teamstärke von 5 –6 Personen.
Einschätzung: bequem machbarBei einem frühesten Einführungstermin zum Januar 2009, Beginn Oktober 2007: Teamstärke von im Schnitt ca. 9 Personen, Teamstärke im Projektverlauf ca. zwischen 5 und 14 Personen.
Einschätzung: sportlicher Terminplan, aber noch machbar
©
Bernhard Bauer, all rights reserved 2007 188
189
Projektplan
Funktion: beschreibt aktuellen Planungsstand (Soll-Werte)Vorbereitung RessourcenbereitstellungVorbereitung Kontrolle/Steuerung
Bestandteile von ProjektplänenZusammenfassung mehrerer Vorgänge zu einer PhaseFestlegung von Meilensteinen als Abschluss von Phasen oder Vorgangsgruppen:
Null-DauerÜberprüfbarkeit: Teilprodukt ist fertiggestelltKurzfristigkeit: kurze Zeitdauer zwischen MeilensteinenGleichverteilung: kontinuierliche und gleiche Verteilung
Abhängigkeiten zwischen Meilensteinen und Vorgängen:fachlicheterminliche Integration in Netzplänenpersonelle
Elemente (Planung):ProjektstrukturplanTerminplanPersonalplanRessourcenplan
Zusätzlich: Ist-Werte Projekt189
190190
Projektplan
Funktion: beschreibt aktuellen Planungsstand (Soll-Werte)Vorbereitung RessourcenbereitstellungVorbereitung Kontrolle/Steuerung
Bestandteile von ProjektplänenZusammenfassung mehrerer Vorgänge zu einer PhaseFestlegung von Meilensteinen als Abschluss von Phasen oder Vorgangsgruppen:
Null-DauerÜberprüfbarkeit: Teilprodukt ist fertiggestelltKurzfristigkeit: kurze Zeitdauer zwischen MeilensteinenGleichverteilung: kontinuierliche und gleiche Verteilung
Abhängigkeiten zwischen Meilensteinen und Vorgängen:fachlicheterminliche Integration in Netzplänenpersonelle
Elemente (Planung):ProjektstrukturplanTerminplanPersonalplanRessourcenplan
Zusätzlich: Ist-Werte Projekt
191191
Projektstrukturplan
Projektstrukturplan oder Work Breakdown StructureZiel:
Erfassen der Abhängigkeiten im ProjektverlaufVorbereiten der Aufwands- und Zeitplan
Idee:Zerlegung des Projekts solange in Teilaufgaben, bis diese umsetzbar sindDie einzelnen umsetzbaren Teilaufgaben werden mit Meilensteinen für Beginn und Ende versehen (und deren Erreichung überprüft)
Istein Mittel, ein Projekt graphisch in Teile zu zerlegen und darzustellenkein Terminplankeine Abbildung der Projektorganisation
193
Typen von Projektstrukturplan
Objektorientierter ProjektstrukturplanDefinition der Aufgabenpakete nach der technischen Struktur des Projektesz.B.: Objekte/Blöcke - FunktionenHausbau: Keller, Erdgeschoss, Dachgeschoss
Funktionsorientierter ProjektstrukturplanDefinition nach Entwicklungsfunktionen (Bereichen)z.B.: Funktionsblöcke - Teilfunktionen - EinzelaufgabenHausbau: Rohbau, Ausbau
Ablauforientierter ProjektstrukturplanDefinition gemäß Entwicklungsprozeßz.B.: Phasen - Fachgebiete - VerantwortlichkeitenHausbau: Planung, Umsetzung
Meist werden Mischformen verwendet(z.B.: erste Ebene phasenorientiert, ab zweiter Ebene funktionsorientiert)
193
194194
Projektstrukturplan
ProjektprozessauswahlAuswahl von Phasenkonzept oder Vorgehensmodellz. B. IT-Projekt im öffentlichen Bereich nach V-ModellTailoring: projektspezifische Anpassung und Detaillierung
Erstellung: Instantiierung ProzessmodellProduktstruktur: Erfassen/Festlegen der Teilprodukte und ihrer AbhängigkeitenAblaufstruktur: Festlegen der Vorgänge abhängig von der Produktstruktur
Elemente:Phasen (entsprechen Prozessphasen)hierarchische Strukturierung der AufgabenVorgänge (konkretisieren Prozessaktivitäten)Meilensteine (entsprechen Prozessereignissen)
195
Meilensteine
Ziel: Ermöglichen die ProjektkontrolleGezieltes Erkennen der ProjektverzögerungRechtzeitiges Erkennen der Projektverzögerung
Entsprechen synchronisierenden ProjektereignissenProjektstart, Projektende,Vorgangsende
Daher: Geknüpft an Erstellung eines (Teil)ProduktsDichte: Relativ zur Gesamtlaufzeit: Abstände bis zu vier WochenGleichverteilung: ungefähr gleiche AbständeEigenschaften:
Überprüfbarkeit: Objektive Kriterien„Systemarchitektur liegt vor“Testdrehbuch mit 10 Testfällen liegtNicht: „Implementierung zu 80% abgeschlossen“
195
197
Projektablaufplan
Ein Projektablaufplan dient zur Darstellung des zeitlichen Verlaufs und der Abhängigkeiten von Projektaufgaben und –Ergebnissen:Abhängigkeiten
zwingende Folgeempfehlende Folgefreie Folge
Verschiedene Ablaufplänen mit unterschiedlichem InformationsgehaltLinearpläne Netzpläne
197
198198
Projektablaufplan
DarstellungstechnikenListungstechnik
nur bei kleinen (Linear-)Plänen sinnvoll einsetzbarTerminlisten:
Workpackages (Vorgangslisten), von außen vorgegebene TermineNetzplantechnik,
zusätzlich technologische Abhängigkeitenz. B.
Vorgangspfeilnetzplan (CPM)VorgangsknotennetzplanEreignisknotennetzplan
Balkendiagrammtechnikzusätzlich je Teilaufgabe Start- und Endtermin bzw. Dauerz. B.
Gantt-DiagrammPLANNET-Diagramm
Vernetzte Balkenplänezusätzlich einfache Abhängigkeiten zwischen Vorgängen
199199
Terminlisten
Enthält Liste der Aktivitäten
bzw. VorgängeZu jedem Vorgang wird die Liste der beteiligten oder verantwortlichen Personen angegebenWeiter wird (meist) eine Deadline für jeden Vorgang definiertZusätzlich kann eine Liste der Meilensteine existieren bzw. eine separate Liste von außen vorgegebener wichtiger Termine (Deadlines)
200200
Netzplantechnik
NetzplantechnikenZiel
Terminplanung für Vorgänge/EreignisseBerücksichtigung der Abhängigkeiten (evtl. Varianten)
Kennzeichenumfassendes Planungsinstrument für komplexe Projektebietet übersichtlichen Überblick über den Projektablauf, inklusive der eindeutigen Darstellung derAbhängigkeiten einzelner Vorgänge im Ablaufermöglicht genaue Zeitschätzung bzw. Terminfestlegung für den Gesamtablauf sowie für einzelne VorgängeErkennen der zeitintensivsten Ablauffolge: “kritischer Weg”ermöglicht relativen Vergleich der Konsequenzen von Terminen, Kosten und Einsatzmitteln verschiedener Planungsvariantenfördert rechtzeitige Entscheidungen, da mögliche Konsequenzen im Netzplan ersichtlich sind. Netzpläne bieten, dank komplexer Methoden um Abhängigkeiten zwischen Vorgängen darzustellen, die umfangreichste Information über Projekte.Diese Information muss allerdings auch zuverlässig und vollständig erhoben werden können.
201201
Netzplantechnik
NetzplantechnikenNetzplantechnik ist geeignet für:- Strukturplanung- Zeitplanung- Einsatzmittelplanung- Kostenplanungbewährte Arten von Netzplänen:- CPM: Critical Path Method- PERT: Program Evaluation and Review Technic- MPM: Metra-Potential-Methodzahlreiche Softwareprodukte unterstützen den Einsatz der Netzplantechnik; oft: Zusammenfassung verschiedener Arten von Netzplänen; daher: Vorsicht auf Konsistenz!
202202
Netzplantechnik –
CPM
Erstellen der Tätigkeitsliste als Grundlage jedes Netzplans:entsprechend der Projektstruktur werden alle Teilprojekte in Einzeltätigkeiten zerlegt;für jede Tätigkeit : Definition der
erforderlichen Vorbedingungen (Abschluß anderer Tätigkeiten)voraussichtlichen Dauerggf. der direkten Nachfolgetätigkeiten
Erstellung der Tätigkeitsliste (auch “Vorgangsliste”)Beispiel siehe nächste Folie
204204
Netzplantechnik
NetzplantechnikenNetzplanvarianten:
Vorgangsknotennetzplan (z.B. MPM)-
Knoten (meist Rechtecke) sind Vorgänge (Ereignisse)-
Kanten sind benötigte Ressourcen/Produkte (Abhängigkeiten, Beziehungen)
Vorgangskantennetzplan (z.B. CPM), auch Vorgangspfeildarstellung-
Knoten (meist Kreise) sind Ereignisse-
Kanten/Pfeile sind Vorgänge -
Schwerpunkt: Vorgang ( = Tätigkeit) mit Dauer
Ereignisknotennetzplan (z.B. PERT)-
Knoten (meist Kreis) sind Ereignisse-
Kanten/Pfeile sind Abhängigkeiten, Beziehungen -
Schwerpunkt: Ereignis: beschreibt Projektzustand, Zustandsübergang kann mehrere Vorgänge umfassen, die nicht näher beschrieben werden.
205205
Netzplantechnik
Vorgangsknoten Netzpläne -
Activity on Node (AoN)Knoten: enthalten Vorgänge, Vorgangsnummern und DauernKanten: beschreiben die Anordnungsbeziehungen zwischen den Vorgängen
Vier Anordnungsbeziehungen zwischen VorgängenNormalfolge (Ende-Anfang Beziehung)Anfangsfolge (Anfang-Anfang Beziehung)Endfolge (Ende-Ende Beziehung)Sprungfolge (Anfang-Ende Beziehung)
207207
Netzplantechnik -
Vorgangsknotennetzplan
VorgangsknotennetzplanVorgangsknotennetzplan KNP = (A,R,a,A,e,E)
A = {a1,...,am} Menge der Aktivitäten im Projekt mit-
Dauer einer Aktivität d(a)-
Frühest/spätest möglicher Beginn b(a)/B(a)-
Frühest/spätest mögliches Ende e(a)/E(a)-
p(a) Pufferzeit
R = { r1,...,rn } ⊆ A × A Menge der Abhängigkeitena/A frühester/spätester Starttermin Projekte/E frühester/spätester Endtermin Projekt
Begriffe:Pfad (a1,...,am): Menge von Aktivitäten mit (ai, ai+1) ∈ RVorgänger V(a): { a‘ | (a‘, a) ∈ R }Nachfolger N(a): { a‘ | (a, a‘) ∈ R }
208208
Netzplantechnik -
Vorgangsknotennetzplan
VorgangsknotennetzplanEin Netzknoten ist i.a. wie folgt aufgebaut:
FA - frühester Anfang FE - frühestes EndeSA - spätester Anfang SE - spätestes Ende
Subnetze: komplexe Netzknoten können aus Gründen der Übersichtlichkeit in Subnetze zerlegt werden
209209
Netzplantechnik -
Vorgangsknotennetzplan
VorgangsknotennetzplanNormalfolge
Das Ende von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (EA: Ende-Anfang)
AnfangsfolgeDer Beginn von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (AA: Anfang -Anfang)
210210
Netzplantechnik -
Vorgangsknotennetzplan
VorgangsknotennetzplanEndfolge
Das Ende von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (EE: Ende -Ende)
SprungfolgeDer Beginn von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (AE: Anfang -Ende)
211211
Netzplantechnik -
Vorgangsknotennetzplan
TerminberechnungBerechnung frühester Projektende e:
Für Aktivitäten:-
Für initiale Aktivitäten: Frühster Anfang ist Projektanfang-
Für Zwischenaktivitäten: Frühester Anfang ist frühestes Ende aller Vorgänger-
Frühestes Ende ist frühester Anfang zuzüglich Dauer
Frühestes Projektende e ist frühestes Ende aller FinalaktivitätenBerechnung spätester Projektanfang A:
Für Aktivitäten:-
Für finale Aktivitäten: Spätestes Ende ist Projektende-
Für Zwischenaktivitäten: Spätestes Ende ist spätester Anfang aller Nachfolger-
Spätester Anfang ist spätestes Ende abzüglich Dauer
Spätester Projektanfang A ist spätester Anfang aller InitialaktivitätenBerechnung Pufferzeiten p(a):
Zeit zwischen frühestem und spätestem AnfangZeit zwischen frühestem und spätestem Ende
Kritischer Pfad:Eine Aktivität mit Pufferzeit 0 ist eine zeitkritische AktivitätAll zeitkritischen Aktivitäten auf einem Pfad bilden einen kritischen PfadVerzögerung kritischer Aktivitäten führen zu Gesamtprojektverzögerungen
212212
Netzplantechnik -
Vorgangsknotennetzplan
VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen
214214
Netzplantechnik -
Vorgangsknotennetzplan
VorgangsknotennetzplanBeispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen
216216
Netzplantechnik
Netzplantechnik umfasst folgende Schritte:Erstellen der Tätigkeitsliste aufgrund des ProjektstrukturplansErstellen des NetzplansBerechnen der VorgangszeitpunkteErmitteln der PufferzeitenErrechnen des kritischen WegesVerwendung des Netzplans als Basis von
Balkendiagrammen, z.B. Belegungsplan, EinsatzplanEinsatzmittel-Auslastungsdiagrammen, z.B. zwecks Bedarfsglättung
217217
Netzplantechnik –
CPM
CPM: Vorgangskantennetzplan
/ VorgangspfeilplanKnoten:
symbolisiert ein Ereignis, welches einen Zustand beschreibt; z.B.: Programm erstellt, Start für den Test;Darstellung: als Kreis oder Rechteck
Ereignisknoten enthält folgende Bestimmungsstücke:
Ereignisnummer
Zeitwert der Vorwärtsrechnung
Zeitwert der Rückwärtsrechnung
2
12 18
218218
Netzplantechnik –
CPM
CPM: Vorgangskantennetzplanoft werden Ereignisknoten auch folgendermaßen dargestellt
219219
Netzplantechnik –
CPM
CPM: Vorgangskantennetzplangerichtete Kante:
symbolisiert Vorgang oder Tätigkeit innerhalb eines Projektes; kein Zusammenhang zwischen der Länge des Pfeils und der Dauer des Vorgangs
Vorgangsbeschreibung: verbal oder Indexeintrag oberhalb des Pfeils; Vorgangsdauer: num. Eintrag unter dem Pfeil
220220
Netzplantechnik –
CPM
Regel 1:Ein Vorgang kann erst beginnen, wenn alle vorangehenden Vorgänge abgeschlossen sind. Dabei fällt, mit Ausnahme des ersten Vorgangs, das Anfangsereignis mit dem Endereignis des vorangehenden Vorgangs zusammen.
221221
Netzplantechnik –
CPM
Regel 2:Müssen mehrere Vorgänge beendet sein, bevor ein weiterer Vorgang beginnen kann, so enden sie im Anfangsereignis des nachfolgenden Vorgangs.
Regel 3:Können mehrere Vorgänge beginnen, nachdem ein vorangehender Vorgang beendet ist, so beginnen sie im Endereignis des vorangehenden Vorgangs.
222222
Netzplantechnik –
CPM
Regel 4: Haben zwei oder mehr Vorgänge gemeinsame Anfangs- und Endereignisse, so ist ihre eindeutige Kennzeichnung durch Einfügen von Scheinvorgängen zu gewährleisten.
223223
Netzplantechnik –
CPM
Regel 5: Beginnen und enden in einem Ereignis mehrere Vorgänge, die nicht alle voneinander abhängig sind, so ist der richtige Ablauf durch Auflösung der Unabhängigkeiten mittels Scheinvorgängen darzustellen.
Regel 6:Innerhalb einer Folge von Vorgängen können beliebig viele Scheinvorgänge eingefügt werden. Sie dienen neben der logischen Verknüpfung auch der besseren Übersicht.
224224
Netzplantechnik –
CPM
Regel 7: Kann ein Vorgang beginnen, bevor der vorangehende vollständig beendet ist, so ist der vorangehende weiter zu unterteilen, damit ein "Zwischen-Ereignis" definiert werden kann.
Regel 8:Jeder Vorgang kann nur einmal ablaufen. Daher dürfen im CPM-Netzplan keine Schleifen auftreten.
225225
Netzplantechnik –
CPM
Beispiel: CPM NetzwerkTätigkeiten mit Zeitangaben und Vorgängerrelationen
230230
Netzplantechnik –
CPM
Erstellen des Netzplans: Eintragen der logischen Abhängigkeiten zwischen TätigkeitenEintragen der geschätzten Dauer zu einzelnen Tätigkeiten
Errechnen der Zeitwerte und Bestimmung des kritischen Weges:Zeitwert der Vorwärtsrechnung: Beginn bei 0;dann: addieren der Zeiteinheiten nach der logischen Reihenfolge undEintrag in das linke untere Feld des Ereigniskreises;Bedeutung: Bestimmung der frühesten Ereigniszeitpunkte;
Zeitwert der Rückwärtsrechnung: vom Endereignis und dessen Zeitwert aus der Vorwärtsrechnung ausgehend:
Bestimmung der spätesten Ereigniszeitpunkte durch Subtraktion der Zeitwerte;Eintrag in den rechten unteren Teil des Ereignisknotens;
Der kritische Weg umfasst alle Ereignisse, deren früheste und späteste Ereigniszeitpunkte gleich sind
Bedeutung: der kritische Weg enthält alle Tätigkeiten, die keine Pufferzeiten erlauben, d.h. zwischen dem geplanten Ende einer Tätigkeit und dem Start der Folgetätigkeit gibt es keine zeitliche Verschiebungsmöglichkeit, wenn das Ende des gesamten Vorhabens unbeeinflußt bleiben soll.
232232
Netzplantechnik –
CPM
Berechnen der Vorgangszeitpunkte (“Tätigkeitszeitpunkte”):frühester Anfangszeitpunkt des Ereignisses: FAspätester Endzeitpunkt eines Vorganges: SEfrühester Endzeitpunkt eines Ereignisses: FEspätester Anfangszeitpunkt eines Vorganges: SA
Zweck: Berechnung der Pufferzeiten und Erstellen des Einsatz-Auslastungsdiagramms, z.B. zwecks Bedarfsglättung
234234
Netzplantechnik –
CPM
Aufgrund der Vorwärts- und Rückwärtsrechnung sind bekannt: FA (FZ) und SE (SZ)
FE(V1) = FA(V1) + D(V1) SA(V1) = SE(V1) - D(V1)
Pufferzeiten:Gesamte Pufferzeit (GP): GP = SE(j) - FA(i) - Doder GP = SZ(j) - FZ(i) - DBedeutung: GP gibt an, wie lange ein Vorgang höchstens verlängert/verzögert werden kann, ohne daß der Endtermin beeinträchtigt wird.
235235
Netzplantechnik –
CPM
Freie Pufferzeit
(FP):FP = FE(j) - FA(i) - Doder FP = FZ(j) - FZ(i) - DFreie Pufferzeit entsteht, wenn mehrere Vorgänge, die nicht alle zeitbestimmend sind, in einem Ereignis münden.Die freie Pufferzeit gibt den Zeitunterschied zwischen der zeitbestimmenden und der auf einem anderen Weg berechneten frühesten Lage eines Ereignisses an.Bedeutung: FP gibt an, wie lange ein Vorgang höchstens ausgedehnt/verzögert werden kann, ohne den Anfangszeitpunkt der Folgevorgänge zu beeinflussen.
236236
Netzplantechnik –
CPM
Unabhängige Pufferzeit (UP):UP = FE(j) - SA(i) - DBedeutung:UP gibt die Dauer an, die der Vorgang mit den Folgevorgaben ausgedehnt oder verschoben werden kann:a) das Startereignis muß zum spätesterlaubten Zeitpunkt beginnen undb) der Vorgang muß den frühestmöglichen Endzeitpunkt einhalten können.weitere Kenngröße:Schlupf im Zustand i: SL(i) = SZ(i) - FZ(i)
238238
Netzplantechnik
ZusammenfassungNetzplantechnik
Eingabe:-
Projektstrukturplan-
Terminvorgaben-
Aufwandsschätzung (Zeitaufwände)
Ergebnis:-
Meilensteinplan-
Terminplan
Einschränkende AnnahmenAnnahme: Vorgangsdauer genau abschätzbarAnnahme: Ressourcen frei planbar
Konsequenz: Termin- und Ressourcenplanung verschränkt durchführen
239239
Balkendiagramm
Balkendiagramm (GANTT-Diagramm)Entwickelt von Henry L. Gantt, 1861–1919Graphische Darstellung der Terminlisten unter Einbeziehung der Dauer der einzelnen Vorgänge
Gute Visualisierung der einzelnen Phasen und des ProjektfortschrittsAktivitäten werden in Balkenform aufgetragen
Die Länge des Balkens entspricht der Länge der AktivitätGraue Teile der Balken entsprechen der Pufferzeit (i.e. jene Zeit, um die sich eine Aktivität verschieben darf, ohne Einfluss auf die Gesamtprojektdauer zu nehmen)Aktivitäten ohne Pufferzeit stellen den “kritischen Pfad” darAus Gantt-Diagrammen sind die Zusammenhänge der einzelnen Aktivitäten nicht ersichtlich
240240
Balkendiagramm
Balkendiagramm (GANTT-Diagramm)Balkendiagramme:
vielseitige Verwendung;horizontale Achse: Zeitvertikale Achse: z.B.
-
Sachmittel: “Belegungsplan”-
Aufgaben: “Tätigkeitsplan”, “Projektfortschrittsplan”-
Aufgabenträger: “Einsatzplan”
Erweiterungen:Balken können mit Wert beschriftet werden
z.B. Mitarbeiternameje ein Balken für Soll- und Ist-Wert zwecks Vergleich
241241
Balkendiagramm
Balkendiagramm
Arbeitsschritte Meilensteine Jahr
Quartal 2 3 4 1 2 3 4 1 2 3 Insges. MID (Dipl.Ing
AP 1 Entwicklung Vorgehensmodell „BP2WS-Prozess“ 41,4 12,3 AP 1.1 Stand der Technik 0,7 2,1 0 AP 1.2 Vorgehensmodell „BP2WS“ 1,4 1,1 1,3 1,3 0,9 0,9 0,6 22,5 5 MS 1.1 BP2WS V1 MS 1.2 BP2WS V2 AP 1.3 Dokumentation 0,7 0,6 1 1,3 10,8 3 AP 1.4 UML Profile 0,5 0,5 0,3 0,7 6 2AP 2 Modelltransformation und Codegenerierung 43,8 10,8 AP 2.1 Stand der Technik 0,7 2,1 0 AP 2.2 Transformationssprache 0,9 0,8 0,8 0,8 0,4 11,1 MS 2.1 Transformationssprache V1 MS 2.2 Transformationssprache V2 AP 2.3 Regeln 1 1,1 2,2 1,5 1,3 1,4 1,1 0,6 30,6 7 MS 2.3 RegelbibliothekAP 3 Prototyp 48,3 42,6 AP 3.1 Anforderungen 0,5 0,3 2,4 1 AP 3.2 Modellierung 0,5 1,2 0,2 0,3 0,2 0,1 0,1 7,8 5 MS 3.1 Modellierung in Innovator AP 3.3 Tranformationen / Codegenerierung 3,1 3,5 3,1 2 1 38,1 3 MS 3.2 Transformations / Codegen. In InnovatorAP 4 Fallstudie 59,1 9,3 AP 4.1 Anforderungen Fallstudie 1,5 1,6 9,3 1 AP 4.2 Anforderungen an BP2WS 0,9 0,4 3,9 1 AP 4.3 Fallstudie 1 und Evaluation 3,6 2,4 18 2 MS 4.1 Fallstudie 1 und Eval AP 4.4 Fallstudie 2 und Evaluation 3,3 3,3 2,7 27,9 4 MS 4.2 Fallstudie 2 und EvalAP 5 Projektmanagement 0,8 0,2 0,3 0,35 0,25 0,1 0,3 0,25 0,25 0,8 10,8 2,1
Summen 4,6 6 4,8 4,95 5,05 8,6 7,8 10,25 8,65 7,1 203,4 77,1
Durchschnittliche Zahl von Personen pro Monat über Projektlaufzeit: 6,78
2006 2007
Einteilung nach Vergütungsg
bei Wirtschafts-Unternehmeo.ä.
Gesamtpersonalplan Alle Projektpartner kumuliert Zeitplan - Angaben als 'Personen pro Monat'
Balkendiagramm Meilensteine
PersonaleinsatQuartale berücksich0,2*3=0,6
2005
242242
Balkendiagramm
Vernetzte BalkenpläneIn das Balkendiagramm werden zusätzlich Informationen über einfache Abhängigkeiten zwischen den einzelnen Vorgängen eingefügtDarstellung: Pfeile vom Vorgänger-Balken zum jeweiligen NachfolgerDadurch gute Darstellung der direkten Abhängigkeiten, i.e. welche weiteren Vorgänge werden aufgrund einer Verzögerung ebenfalls verspätet ausgeführt und mit welchen Vorgängen kann im Zeitplan weiter wie geplant vorgegangen werden.Vernetzte Balkenpläne zählen zu den einfachsten und wichtigsten Kommunikationsinstrumenten im Projektmanagement
244244
Balkendiagramm
17 19 21 23 25 27 29 313rd Quarter 1st Quarter 3rd Quart
Phase 1 Phase 2
ID ID Task Name1 WP1 WP1 Project Management & Coordination
2 T1.1 Selection of tools
3 T1.2 Management of CVS-server, Web-site, …
4 T1.3 Project Co-ordination
5 T1.4 Co-ordination with standards
6 D11 Selection of Tools
7 D12 Inter-working with other projects
8 D13 Impact on Standards
9 D14 Impact on Standards
10 D15 Project summary and exploitation plan
11 D16 Annual Report Review 2000
12 D17 Annual Report Review 2001
13 WP2 WP2 Field Trials
14 T2.1 Requirements of Field Trials
15 T2.2 Specifications of Field Trials
16 T2.3 Preparation of Field Trials
17 T2.4 Carry out Field Trials
18 T2.5 Evaluation of Field Trials
19 D21 Requirements of Field Trials
20 D22 Specifications of Field Trials
21 D23 Evaluation of Field Trials
22 WP3 WP3 Light. Ext. Agent Platform
23 T3.1 Set-up of the environment
24 T3.2 System Design, Architecture, API
25 T3.3 Implementation
26 T3.4 Integration
27 T3.5 Maintenance
28 D31 Specification of the LEAP Architecture
29 D32 Specification of LEAP API + profile
30 D33 LEAP Version 1.0
31 D34 LEAP Version 2.0
32 WP4 WP4 Agent Services & Applications
33 T4.1 Design
34 T4.2 Implementation
35 T4.2 Integration
36 T4.4 Maintenance
37 D41 Agent Services Design
38 D42 Lab Trial
39 D43 LEAP Application Implementations
40
31/03
31/03
31/03
30/05
30/06
31/12
31/12
30/04
30/08
30/06
31/05
31/07
31/12
30/08
30/08
31/12
28/09
-2 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 311st Quarter 3rd Quarter 1st Quarter 3rd Quarter 1st Quarter 3rd Quart
245245
Arbeitspaketbeschreibung
PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining
1)
Beschreibung des Arbeitspaketes
Vorbereitung, Durchführung und Nachbereitung von zwei je zweitägigen Trainings für Vertriebsmitarbeiter und ausgewählte Mitarbeiter über die neue Technologie und Funktionalität des Mobile-Odors-Telefons. Ergänzende Informationen:
Intensivtraining mit max. 4 TeilnehmernÜberwiegend folienbasiertes Training inkl. Übungen (ca. 80 Folien pro Tag)Es gibt bereits Unterlagen einer älteren Schulung, die für das Training benutzt/angepasst werden dürfen.Teilnehmerunterlagen werden durch Druckerei erstellt & geliefert. →Vorher Übergabe elektronisch in pdf-
Format.Nachbereitung: Teilnehmerzertifikate und im Kurs erarbeitete Unterlagen (elektronische Bilder via E-Mail)
2
)
Durchführende Personen oder Rollen
Chefdesigner
3
)
Notwendige Fähigkeiten des/der Durchführungen
Gute technische und funktionale Kenntnisse Mobile Odors, Trainerausbildung
246246
Arbeitspaketbeschreibung
PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining
4
)
Dauer und AufwandSchulungsdauer: 2 Tage (à
8 Stunden), Aufwand noch zu bestimmen
5
)
Liefergegenstände
Trainerfolien, Trainingsorganisation, durchgeführte Trainings, Teilnehmerunterlagen
6)
Vorraussetzungen für die Durch-führung
Ausreichend zeitlicher Vorlauf bei der Planung, damit alle Teilnehmer mit den 2 Trainings erreicht werden.
7)
Vorraussetzungen für eine erfolg-reiche Abnahme
Teilnehmer kennen die Technologie und fühlen sich in der Lage, auch mit technisch versierten Kunden ein Vertriebsgespräch zu führen.
8
)
Kennzahlen zur Überprüfung der korrekten Durchführung
keine
247247
Arbeitspaketbeschreibung
PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining
4
)
Dauer und AufwandSchulungsdauer: 2 Tage (à
8 Stunden), Aufwand noch zu bestimmen
5
)
Liefergegenstände
Trainerfolien, Trainingsorganisation, durchgeführte Trainings, Teilnehmerunterlagen
6)
Vorraussetzungen für die Durch-führung
Ausreichend zeitlicher Vorlauf bei der Planung, damit alle Teilnehmer mit den 2 Trainings erreicht werden.
7)
Vorraussetzungen für eine erfolg-reiche Abnahme
Teilnehmer kennen die Technologie und fühlen sich in der Lage, auch mit technisch versierten Kunden ein Vertriebsgespräch zu führen.
8
)
Kennzahlen zur Überprüfung der korrekten Durchführung
keine
248248
Personalplanung
PersonalplanungAufgaben der projektbezogenen Personalplanung
Sicherstellung der MitarbeiterverfügbarkeitOptimaler Einsatz der Mitarbeiter
-
Vermeidung von Mitarbeiterüberlastung-
Vermeidung von mangelnder Mitarbeiterauslastung
249249
Personalplanung
Ermittlung PersonalaufwandPrinzipieller Ansatz:
Eingaben: Aufwand Aktivität, Dauer AktivitätAusgabe: Anzahl benötigter MitarbeiterVerfahren:Zusätzlich: Benötigte Qualifikation
Rechenbeispiel: 10 PMDauer 10 KM : 1 MADauer 2 KM : 5 MA
Bemerkungen:Annahme der normierten Leistung (1 MA leitet 1 PM pro Monat)Annahme der unabhängigen Multiplizität von MitarbeiternBerücksichtigung Brutto/Netto-Leistung
250250
Personalplanung
PersonalplanungPrinzipieller Ansatz:
Ermittlung Personalaufwand (Projektstrukturplan, Aufwandsschätzung, Terminplan)Ermittlung PersonalressourcenPersonalzuordnung und Optimierung der Auslastung
Varianten der Zuordnung/Optimierung:Terminorientiert: Aufwände in Abhängigkeit vorgegebener TermineAufwandsorientiert: Termin in Abhängigkeit vorgegebener (Maximal-)AufwändeRealistisch: Mischverfahren
251251
Personalplanung
Optimierung
Varianten der Zuordnung/Optimierung:Terminorientiert:
-
Einhaltung vorgegebener Termine-
Erhöhung der Personalzuordnung
Aufwandsorientiert:-
Einhaltung vorgegebener (Maximal-)Aufwände-
Verschiebung des Termins
252252
Personalplanung
Organisatorische RandbedinungenQualifikation der Mitarbeiter:
Qualifizierte Mitarbeiter einsetzenMitarbeiter qualifizieren (Zeiten/Kosten einplanen)
Zeitliche/räumliche Verfügbarkeit:Zeitlich: Persönliche Planung berücksichtigen (Urlaub/Ausfall)Räumlich: Koordinationsverluste einplanen
Organisatorische Einbettung:Projektstruktur: Mitarbeiter nach Auslastung einplanenMatrixstruktur: Linenvorgesetzten in Planung einbeziehen
Generell: Mitarbeiter rechtzeitig in Planung einbeziehen
253253
Personalplanung
Humane RandbedingungenProduktivitätsvarianzen:
Starke Produktivitätsschwankungen zwischen MitarbeiternSchwache Produktivitätsschwankungen im Team
TeamkohäsionTeamidentifikation mittels gemeinsamer Normen„Never change a winning team“Ausrichtung auf ein gemeinsames Ziel
ProjektidentifikationIdentifikation erhöht ProduktivitätMultiprojekteinsatz reduziert Produktivität
Generell: Humane Faktoren sind primäre Produktivitätstreiber
254254
Personalplanung
Produktivität
Produktivitätsvarianzen:Beste Mitarbeiter um Faktor 10 besser als schlechtesteBeste Mitarbeiter um Faktor 2,5 besser als DurchschnittÜberdurchschnittliche Mitarbeiter um Faktor 2 besser als unterdurchschnittlicheUnabhängig von Leistungsmetrik:
-
Anzahl der Fehler-
Kalenderzeit bis Meilenstein-
Funktionspunkte pro Zeiteinheit
255255
Personalplanung
RessourcenplanungVerfahren:
Im wesentlichen analog PersonalplanungÄhnliche Probleme
-
Qualifikation: Vorbereitung-
Multiprojekteinsatz: Umrüstung
UnterscheidungNichtverbrauchbare RessourcenVerbrauchbare Ressourcen (eingebettete SW)
257
Ziele
Massnahmen zum Controlling eines Projekts kennen lernenAspekte der Teamführung diskutieren
Projektmanagement M6 –
Controlling und Steuerung
258
Projektkontrolle (Controlling)
Controlling umfasst Fortschrittskontrolle Budget-/ZeitkontrolleÜberprüfen von Risiken im Rahmen des RisikomanagementMitarbeiterkontrolleÜberprüfen der Qualitätsstands im Rahmen des QualitätsmanagementKonfigurationsmanagement...
Ziele der Fortschrittskontrolle Bestandsaufnahme: Wo steht das Projekt aktuell (regelmäßig)?
Feststellung Projekt/Produktstatus und AbweichungenUnterstützung Steuerung
Basis für weitere PlanungenProduktivitätsentwicklung (Soll/Ist)ZeitplanungKapazitätsplanung
Identifikation von ProblembereichenReaktion auf Probleme, Definition und Durchführung von Gegenmaßnahmen
Projektmanagement M6 –
Controlling und Steuerung
260
Zusammenhang zwischen Planung und Steuerung: Das Projekt wird entlang des Plans gesteuert. Abweichungen zwischen Planung und Projektverlauf führen zu Maßnahmen oder Planungsänderungen.
Wichtige Regel für den Projektleiter: Immer eine aktuelle Planung haben! Die Restaufwände kennen!
Projektmanagement M6 –
Controlling und Steuerung
261
Prinzip des Controlling: Soll-Ist-Vergleich Beispiel: Was sagt diese Kurve aus?
Projektmanagement M6 –
Controlling und Steuerung
262
Ist-Soll-Vergleich: Meilensteintrendanalyse
Verfahren:Regelmäßige Erfassung StatusErfassung pro MeilensteinKeine rückwirkende Änderungen
Projektmanagement M6 –
Controlling und Steuerung
263
Meilensteintrendanalyse
Ziel:Prognostizierung TermineErhöhung Planungssicherheit: Erkennen Schätzfehler
Verfahren:Status: Regelmäßige Erfassung geplanter TerminePrognostizierung: Interpolation ÄnderungenPropagierung: Änderung abhängiger TermineVerifizierung: Berücksichtigung Streuung
Erkennbare Planungsfehler: IndikatorenUnrealistische Schätzung:
(Super)lineare VerschiebungenStarke Schwankungen
Späte Neuschätzung: Terminasymptoten
Projektmanagement M6 –
Controlling und Steuerung
264
Meilensteintrendanalyse
Projektmanagement M6 –
Controlling und Steuerung
Berichtszeitpunkte
Meilenstein-
Termine
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
IVIIIIII
200x
200x
200x
2
00x
200x
200x 200x 200x 200x 200xI II III IV I II III IV I II III IV I II III IV I II III IV
Projekt: xxxProjektleiter: xxx
265
Meilensteintrendanalyse
Projektmanagement M6 –
Controlling und Steuerung
2
BerichtszeitpunkteBerichtszeitpunkte
Berichtszeitpunkte BerichtszeitpunkteM
eile
nste
in-T
erm
ine
1
3 4
Ausgangssituation nach Planung
Erste Projektbesprechung mit Terminkontrolle nach einem Monat
Zweite Projektbesprechung mit Terminkontrolle nach zwei Monaten
Dritte Projektbesprechung mit Terminkontrolle nach drei Monaten
1
2
3
4
Mei
lens
tein
-Ter
min
e
Mei
lens
tein
-Ter
min
eM
eile
nste
in-T
erm
ine
266266
Meilensteintrendanalyse
Meilensteintrendanalyse
Erkennbare Fehler:Unterschätzung M1: Wiederholte Verschiebung (Messfehler)Überschätzung M2: Überhöhte Verschiebung (Planungsfehler)Fehlende Schätzung M3: Späte Verschiebung (Planungsfehler)
267
Wann wird das IST bestimmt?
Controlling so eng vornehmen, wie es der Projektsituation entspricht:Kritischer Zeitplan, hohes Terminrisiko
enges Controlling„Sicheres“ Projekt, erfahrene, selbständige Mitarbeiter
Weites Controlling
Mögliche Zeitpunkte für Bestimmung des Ist:Zu den MeilensteinenWöchentliche (oder mehr wöchentliche) Planungsmeetings, StatusmeetingsIn kritischen Phasen sogar täglich
Projektmanagement M6 –
Controlling und Steuerung
268
Wie wird das IST bestimmt?
Möglichkeiten:Persönliches Gespräch:
Projektleiter geht herum, spricht mit Mitarbeitern die Aktivitäten durch. Ggf. feste Agenda, auf die sich MA vorbereitet.
Regelmäßige Statusberichte der Mitarbeiter: In Team-Meetings, Per Email
Bei Methode zu bedenken:Erfahrenheit der Mitarbeiter: Erfahrene Mitarbeiter können sich selbst besser einschätzen und wissen besser, welche Punkte wichtig sind.Statusberichte dienen zur Messung des aktuellen Status
Planung: Budgetbericht, Terminbericht, Aufwandsbericht, RisikoberichtQualitätssicherung: FehlerberichtStatusberichte haben einen formalen Rahmen, stellen sicher, dass alle Punkte beleuchtet werden
Projektmanagement M6 –
Controlling und Steuerung
269
Preisfrage (Abfrage des IST in der Realisierung)
Wann ist ein Stück Software fertig entwickelt?„Wie weit bist du?“
„Fast fertig…“„Ich muss nur noch…“„Fertig, ich muss nur noch einchecken…“
Projektmanagement M6 –
Controlling und Steuerung
270
Antwort
Erst fertig ist fertig.Erinnerung: ein Arbeitspaket/eine Aktivität hat definierte Ergebnisse und QualitätskriterienInsbesondere bei der Programmierung:
Code ist erst dann fertig, wenn der Entwicklertest erfolgreich stattgefunden hatNIEMALS auf die Antwort „Fast fertig“ einen Fertigstellungsgrad von mehr als 50% annehmen.
Projektmanagement M6 –
Controlling und Steuerung
271Projektmanagement M6 –
Controlling und Steuerung
Technische Umsetzung des Controlling
Spalte für Restaufwände ab aktueller WocheIm Beispiel hier: bei wöchentlicher Statusabfrage werden Fertigstellungsgrad und Restaufwände ermittelt
272
Controlling der Restaufwände LOP –
Die Liste offener Punkte
Problemstellung:Selbstverständliche Dinge im Projekt geschehen nicht von selbst.Das Durchführen von Maßnahmen müssen überwacht werden.Wichtige Punkte gehen verloren, weil sich aktuell niemand darum kümmern kann.
Idee:Führen einer Liste der Offenen Punkte (LOP)
Projektmanagement M6 –
Controlling und Steuerung
273
Controlling der Restaufwände LOP-
Umsetzung
Inhalte der LOPName des PunktsBeschreibungWer hat ihn eingestellt (wg. Nachfragen)?Wer kümmert sich um die Klärung?Bis wann?Statusbei großen Listen ggf.:
PrioriätOrdnungskriterium, z. B. Projektphase („Fachkonzept“ „Technisches Konzept“, etc.)
Umsetzung mit Tabellenkalkulation
Projektmanagement M6 –
Controlling und Steuerung
274
Controlling der Restaufwände Vorgehen LOP
Verantwortlichen für die LOP benennen, Aufgaben:AktualisierungÜbersicht behaltenNachhalten von Terminen
Befüllen der LOPi. d. R.: jeder darf eintragen und sammeln.
Regelmäßig (z. B. zu den wöchentlichen Team-Meetings)Vorbereitung: Punkte durchgehen und bewertenIm Meeting Status erheben, Aufgaben verteilen
Projektmanagement M6 –
Controlling und Steuerung
275
Typische Inhalte eines Statusreports
Ist-Zustand und aktuelle PlanungWo laufen Ist und Soll auseinander? Welche Maßnahmen wurden ergriffen?Sind Meilensteine gefährdet?
Aktuelle Risikoliste des ProjektsWelche Projektrisiken bestehen, welche Maßnahmen wurden ergriffen?
Nächste Schritte, Vorgehen bis zum nächsten TerminEntscheidungsbedarfReduktion auf Status-Ampel
grün: alles okgelb: Projekterfolg wahrscheinlich gefährdetrot: Projekterfolg gefährdet, Handlungsbedarf
Projektmanagement M6 –
Controlling und Steuerung
277
Statusreports auf höheren Organisationsebenen
Typische ReportingzyklenTeam an (Teil-)Projektleiter: wöchentlichTeilprojektleiter an Gesamtprojektleiter: wöchentlich bis 2-wöchentlich.Gesamtprojektleiter an Lenkungsgremium: 1 x im Monat oder seltener.
Bei Projektleitungsmeetings: StatusreportsNutzen entsteht bereits dadurch, dass der Berichtende sich selbst über den Status seines Teams bewusst werden muss.
Projektmanagement M6 –
Controlling und Steuerung
279
Die Einladungsmail
From: michael@firma.deTo: frank@firma.de; andreas@firma.de; anna@firma.de; martin@firma.de; thomas@firma.de; rudi@firma.de; sonja@firma.de; renate@firma.de; michael@firma.de; heike@firma.de; dirk@firma.de; gerd@firma.de
Subject: Einladung
Hallo Kollegen,am 12.01.2007 findet um 14:15 in Raum 1.31 das Meeting
zum Thema „Integration von Web Services“
statt.
Mit freundlichen GrüßenMichael
Projektmanagement M6 –
Controlling und Steuerung
280
Professionelle Meetings
Ziel festlegen – und aufschreiben!Verantwortlichen festlegenVerantwortlicher verschickt Einladung
Termin, Ort, ZeitrahmenTeilnehmer – Wer muss denn wirklich dabei sein?ZielAgenda
Wer moderiert, wer führt Protokoll?Technik vorher organisieren: Beamer, Flipchart, Getränke, …
Projektmanagement M6 –
Controlling und Steuerung
281
Spielregeln für Meetings
Handy aus!Protokoll führen, wenn das Meeting wichtig ist.Die anderen ausreden lassen.Sich selbst kurz fassen.Für sich selbst reden.Zur Sache reden, nicht zur Person.Bei Telefonkonferenzen: Unbedingt ausführlich vorbereiten, straff moderieren.
[sd&m AG]
Projektmanagement M6 –
Controlling und Steuerung
282
Das Protokoll
Protokoll vom 12.01.2007Anwesend: Hr. Meier, Fr. Müller, Hr. Schulze, Fr. SchmidtTOP* 1: WebServices
Herr Müller stellt das Konzept zur Integration von WebServices vor.Es muss geprüft werden, ob das auch mit MQ Series zusammen funktioniert.Das XML-Schema muss angepasst werden. => Müller/SchulzeHr. Schmidt klärt, ob die Services auch unter Windows genutzt werden sollen.
TOP 2: SecurityHerr Müller stellt das Security-Konzept vor.
Anlagen:Präsentation WebServicesPräsentation Security
*TOP = Tagesordnungspunkt
Projektmanagement M6 –
Controlling und Steuerung
283
Was gehört ins Protokoll?
DatumTeilnehmerVerteiler (nicht teilgenommen, aber offiziell informiert)Vorgehen
Gleich nach dem Meeting aufschreiben, an Verteiler verschicken,ggf. Feedback einarbeiten.
TagesordnungspunkteInformation, Feststellung, Beschluss, AufgabeAufgaben immer mit Termin und einem Verantwortlichen
Projektmanagement M6 –
Controlling und Steuerung
284
Protokoll Lenkungskreis Projekt XY
Protokoll vom 12.01.2007Anwesend: Hr. Meier, Fr. Müller, Hr. Schulze, Fr. Schmidt.Verteiler: Teilnehmer, Fr. WagnerTOP 1: Teilprojekt Dialoge
Information: Herr Müller stellt den Status des Teilprojekts vor.Festellung: Die Teilnehmer halten das Erreichen des Meilensteins 6 („Auslieferung Basis“) für unrealistisch
Beschluss: Die Dialoge zum erweiterten Suche werden aus dem Lieferumfang von Meilenstein 6 genommen und Meilenstein 8 zugeschlagen.Aufgabe: Hr. Müller stellt die Auswirkungen dieser Änderung und die aktualisierte Planung vor => Müller, bis 28.1.06Anlage:
Präsentation Teilprojekt Dialoge
Projektmanagement M6 –
Controlling und Steuerung
285
Umgang mit Problemen -
Projektbeispiel
PL: Wir liefern am 4. Juli aus.Mitarbeiter: Das schaffen wir nicht.PL: Das ist mir egal. Wenn ich sage, wir liefern aus, dann liefern wir aus. Strengen Sie sich an.
Projektmanagement M6 –
Controlling und Steuerung
286
Steuerung
ReaktionsmöglichkeitenPlanung anpassen
TermineInhalte, ErgebnisseQualitätMitarbeiter
Vergleiche: TeufelsquadratSonstige Maßnahmen
Ursache für Behinderung herausfindenAbstimmen
Projektmanagement M6 –
Controlling und Steuerung
288
Mögliche, typische Ursachen für zu geringe Produktivität
Mitarbeiter sind zum Teil im „Leerlauf“, weil Zulieferungen fehlen. Andere Mitarbeiter sind Flaschenhälse
in Planung berücksichtigen, Aufgaben neu verteilen.Mitarbeiter „verspielen“ sich in interessanten, aber unwichtigen Tätigkeiten
enger inhaltlich führen.Mitarbeiter glauben nicht an Projekterfolg und arbeiten nur mit halber Kraft: „Das schaffen wir sowieso nicht“
Planung muss von Mitarbeitern getragen werden.Mitarbeiter arbeiten doppelt, bzw. bereits fertig gestellte Ergebnisse passen nicht zusammen
in Planung berücksichtigen, Koordination etablieren (Chefdesign, Qualitätssicherung), ggf. auch Meetings etablieren.
Ursachen zu diffus und unklar z. B. Workshop oder Audit organisieren, Im Team Ursachen bestimmen und Maßnahmen entwickeln. Know-how von außen hinzuziehen. Wirkung der Maßnahmen überprüfen.
Projektmanagement M6 –
Controlling und Steuerung
289
Mögliche Maßnahmen zur Produktivitätssteigerung –
die „typischen“
Reaktionen
Überstunden, Urlaubssperre, etc.Psychologisches Signal: das Projekt zeigt Einsatz. Der Projektleiter steht dem Auftraggeber gegenüber besser da.Bei intensiver Anwendung überwiegt der negative Effekt den Nutzen.
Überstunden Einmalige Wirkung, kein nachhaltiger Effekt. Dauernde Überstunden wirken eher produktivitätssenkend. Einmalig ok, als Dauerzustand vermeiden.
Urlaubssperre, Absage von Schulungen, etc. Sehr hartes Mittel. Erzeugt Wirkung. Schlecht für Team und Stimmung. Verärgert langfristig Mitarbeiter.Vermeiden!
NIEMALS die geschätzten Aufwände klein- und schönreden: „Das geht bestimmt auch in 3 statt 5 Tagen“Neue Mitarbeiter ins Projekt
Wirkt nur langfristig und begrenzt.
Projektmanagement M6 –
Controlling und Steuerung
290
Druck und Mehrarbeit
Zitate aus „Der Termin“
von Tom DeMarco„Kurze Perioden der Anspannung und sogar Mehrarbeit können eine sinnvolle Taktik sein, weil sie die Konzentration der Mitarbeiter bündeln und das Gefühl für die Wichtigkeit der Arbeit erhöhen. Mehrarbeit über einen längeren Zeitraum hinweg ist aber immer ein Fehler“„Mehrarbeit über einen längeren Zeitraum hinweg ist eine Methode zur Produktivitätssenkung.“„Ein schrecklicher Verdacht: Möglicherweise steckt hinter Druck und Mehrarbeit der Grund, dass im Falle eines Scheiterns niemandem ein Vorwurf gemacht werden kann.“
Projektmanagement M6 –
Controlling und Steuerung
291
Druck im Projekt Zitate aus „Der Termin“
von Tom DeMarco
„Menschen unter Druck denken nicht schneller“„Vielleicht setzen Manager Druck deshalb so oft ein, weil sie nicht wissen, was sie sonst tun sollen, oder die schwierigen Alternativen scheuen.“IT-Projekte sind Projekte, bei denen mit dem Kopf gearbeitet wird.
Die Haupttätigkeit ist Denken.Ein Projekt soll nicht vor sich hin plätschern, deshalb setzt man in der Planung gezielt Meilensteine, um Zwischenziele zu haben und einegesunde Spannung aufrecht zu erhalten. Übermäßiger Druck ist schädlich und wirkungslos.
Projektmanagement M6 –
Controlling und Steuerung
292
Projekttagebuch –
Motivation
Störende Einflussfaktoren auf ein Projekt:Beistellungen verzögern sichExterne Entscheidungen verzögern sichHardware fällt aus, muss repariert/beschafft werden
…Diese Einflüsse verzögern das Projekt und sind vom Projekt selbst nicht zu verantworten.Trotzdem soll nicht gleich eskaliert werden, damit eine gute Zusammenarbeit im Verhältnis Auftraggeber-Auftragnehmer gewahrt wird.Diese Problemchen, die jedes für sich auch zu verkraften wären, können sich zu einem großen Problem akkumulieren. Falls es dann doch zu einer ernsthaften Diskussion über den Grund von z. B. Projektverzögerungen kommt, gerät das Projekt in Erklärungsnot.
Projektmanagement M6 –
Controlling und Steuerung
293
Projekttagebuch –
Vorgehen
Führen eines „Tagebuchs“, in dem die kleinen Behinderungen und Besonderheiten dokumentiert werden, die nicht gleich an die große Glocke gehängt werden.Das Projekttagebuch wird durch den Projektleiter geführt.Es wird nur bei Bedarf herangezogen und dient der Absicherung des Projekts.
Projektmanagement M6 –
Controlling und Steuerung
294
Teamführung
KommunikationFührungsstilVerhalten bei FehlernFeedback
Projektmanagement M6 –
Controlling und Steuerung
295
Teamführung: Kommunikation
Kommunikation ist eine der wichtigsten Aufgaben des Projektleiters.Für Kommunikation muss man aktiv als Projektleiter sorgen, Kommunikation geschieht nicht automatisch von allein.Jeder Mitarbeiter sollte wissen, woran seine Kollegen arbeiten, z. B.
durch eine kurze Statusrunde im TeammeetingThemen und Verantwortliche im Arbeitsraum als Poster aufhängen
Als PL nicht davon ausgehen, dass das Team den gleichen Kenntnisstand hat wie man selber
Das eigene Bild vom Projekt und von Projektinhalten ändert sich schleichend und unbemerktRuhig auch mal die „selbstverständlichen“ Dinge kommunizieren
Projektmanagement M6 –
Controlling und Steuerung
296
Die „selbstverständlichen“
Dinge…
…geschehen seltsamerweise nicht von selbst
BeispieleWenn ein Missstand entdeckt wird, muss man diesen beseitigen.Wenn eine Maßnahme beschlossen wird, muss man diese auch durchführen.
Häufige Ursache:Im Team fühlt sich niemand verantwortlichDer Projektleiter ist immer verantwortlich, er muss Mitarbeiter beauftragen und nachhaken
Projektmanagement M6 –
Controlling und Steuerung
297Projektmanagement M6 –
Controlling und Steuerung
Praxisbeispiel: zwei Teams
Führungsstil Team AInformationen sind Herrschaftswissen.Planung erfolgt heimlich und im „stillen Kämmerlein“Jeder Mitarbeiter wird nur über die Dinge informiert, die er zur Erledigung seiner Aufgaben benötigt.Projektleitung zieht alle Aufgaben an sich.
Führungsstil Team BStetiger Informationsfluss ins Team (allerdings nicht über noch unsichere Dinge, die das Team verunsichern können)Informationen aus Steuerungsgremien sind weitgehend transparent.Projektleitung kommuniziert, vermittelt Bild für das GanzeProjektleitung gibt Aufgaben ab.
298
De Marco, Der Termin
Vier Grundsätze guten Managements:Wählen Sie die richtigen Leute aus.Betrauen Sie die richtigen Mitarbeiter mit den richtigen AufgabenMotivieren Sie die MitarbeiterHelfen Sie den Teams, durchzustarten und abzuheben.Alles andere sind Administrivialitäten
Projektmanagement M6 –
Controlling und Steuerung
299
Umgang mit Fehlern und Kritik
Fehler sind niemals schön und erfreuen niemanden.Aber: honorieren, dass Fehler zugegeben werden. Auch schlechteNachrichten honorieren: „bad news welcome“Selber Fehler zugeben.Kritik immer zur Sache, niemals zur Person!
Projektmanagement M6 –
Controlling und Steuerung
300
Das „Wer hält am längsten die Luft an“-Spiel
Beispiel für Konsequenzen des Fehler-Verschweigens:Ein großes Projekt besteht aus mehreren Teilteams.Alle Teilteams haben Zeitverzug, der Gesamt-Termin ist nicht mehr haltbar.Alle Teilteam-Leiter wissen, dass ihre Kollegen in Verzug sind und pokern darauf, dass ihre Kollegen zuerst Zeitverzug melden müssen.Sobald das erste Teilteam Zeitverzug anmeldet, melden dann auch alle restlichen Team Verzug an, mit Hinweis auf das zuerst „aufgetauchte“Teilteam.Das Gesamtprojekt steht vor einem Scherbenhaufen. Der Termin wäre noch zu retten gewesen, wenn frühzeitig der Zeitverzug gemeldet worden wäre.
Projektmanagement M6 –
Controlling und Steuerung
301
Die Schere im Kopf
Projektsituation: Verfahrene Lage, größere ProblemeDa hilft nur ein Befreiungsschlag
Problem: Man hat „die Schere im Kopf“:Termine, bereits geleistete Arbeit, Budget, sonstige Verpflichtungen
Zur Entscheidung über das weitere Vorgehen muss man wissen, was die Probleme wirklich löst.Fragestellung an Experten/Mitarbeiter: „Was würden Sie machen, wenn Sie der Kaiser von China wären?“
Also: frei und unbefangen sagen, was in dieser Situation das beste ist.Danach die Entscheidung treffen.
Projektmanagement M6 –
Controlling und Steuerung
302
Feedback
Feedback für das Team ist enorm wichtigRegeln:
zeitnah: sobald die Gelegenheit, der Anlass dazu da ist – sonst wirkt Feedback nicht.Zu Feedback gehört auch positives Feedback:MotiviertBestärkt
Beispiel: Sie fahren Auto in einer fremden Stadt. Wegbeschreibung:„Folgen Sie der Straße 5km“ oder„Folgen Sie der Straße 5km. Nach 800m passieren Sie eine Tankstelle. Nach 1,5km fahren Sie unter einer Brücke durch. Nach weiteren 2km ist auf der linken Seite eine Windmühle“
Ständige Bestätigung, dass man auf dem richtigen Weg ist, gibt Sicherheit und motiviert.„Nicht geschimpft ist genug gelobt“ reicht nicht!
Projektmanagement M6 –
Controlling und Steuerung
303
Teambildung
Team bedeutet GemeinsamkeitTeambildung fördern:Gemeinsame ZieleRäumliche Nähe der BürosKaffeekücheTeam-Events, z. B.:Pizza Essen, Kanu fahren, Kegeln gehen, Team T-Shirt…Originalität ist wichtiger als Geld auszugeben, kreativ sein
Positiv: es bildet sich „Elite-Denken“: Wir sind die besten!
Projektmanagement M6 –
Controlling und Steuerung
304
Zusammenfassung (1)
Ein Statusreport dient zur Feststellung des Ist-Zustande und zur aktuellen Planung und enthält
Aktuelle Risikoliste des ProjektsEv. Meilenstein-TrendanalyseNächste Schritte, Vorgehen bis zum nächsten TerminEntscheidungsbedarfStatus-Ampel
Professionelle Meetings folgen auf eine Einladung, haben ein Ziel, einen Verantwortlichen sowie Protokollführer und vorbereitete Technik Ein Protokoll wird sofort nach dem Meeting aufgeschrieben und enthält
Datum und TeilnehmerVerteiler (nicht teilgenommen, aber offiziell informiert)Tagesordnungspunkte
Projektmanagement M6 –
Controlling und Steuerung
305
Zusammenfassung (2)
Teamführung heißtdie richtigen Leute auszuwählen, mit den richtigen Aufgabe zu betrauen und zu motivierenFehler zuzugeben und Missstände möglichst sofort zu behebenPositives Feedback zu geben
Übermäßiger Druck bei Projektverzug ist schädlich und wirkungslos
Eine Liste offener Punkte hilft beim ControllingEin Projekttagebuch dient der Absicherung des Projekts und wird nur bei Bedarf herangezogen.
Projektmanagement M6 –
Controlling und Steuerung
307
Ziele
Projektrisiken einschätzen und vermeiden/verringern lernenÄnderungsmanagment mit Change Requests kennen lernenTechniken des Konfigurationsmanagments kennen lernen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
308
Motivation: Herr Müller und die Sommerreifen
Das hab ich kommen sehen!15. November 2005: Herr Müller verlässt das Haus und steigt in seinen Wagen. Es hat über Nacht geschneit, doch der Wagen hat noch Sommerreifen. Herr Müller hat ein Problem: Der Weg führt über einen Hügel, aber mit Sommerreifen hat er keine Chance, über den Hügel zu kommen. Und jetzt sind die Werkstätten natürlich vollkommen überlaufen. Die Reifen können erst in zwei Wochen gewechselt werden.
Viele Probleme sind absehbar, wenn man sich nur früh genug Gedanken darüber macht.Ein Risiko ist ein potentielles Problem, das noch nicht eingetreten ist, das aber eintreten könnte.Risiken sind in der Regel einfacher zu bekämpfen als die Probleme!
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
309
Risikomanagement im Projekt
Risikomanagement ist ein ständiger Prozess.Risikomanagement geht alle im Projekt an.Verantwortlich für Risikomanagement:
Projektleiter, delegiert in der Regel an Qualitätssicherer oder Teammitglied.
Risiken ändern sich ständig und müssen immer wieder neu bewertet werden.
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
310
Risikomanagement und Projektphasen
Risikomanagementaktivitäten während der Projektdurchführung
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
311
Pareto-Regel
Beobachtungen:Pareto-Regel: 20% der Probleme verursachen 80% der KostenBehebungsverzögerung: je nach Phase bis zu 1000-fache Kosten
Konsequenzen:Fokussierung auf wichtige RisikenFrühzeitige Erkennung und Vermeidung
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Vilfredo Federico Pareto (gebürtig Wilfried Fritz Pareto; 1848 -
1923)italienischer Ingenieur, Ökonom und Soziologe
313
Identifizieren von Risiken
Sammeln von Risikenspezielle Risikorunde (PL, QS,CD, einzelne Mitarbeiter)im regelmäßigen Team-Meeting: z. B. jedes 2. Mal werden die Risiken besprochen und neue Risiken und Maßnahmen gesammelt
Bereiche für Risiken (zur Klassifikation):TechnikFachlichkeitTeamVorgehen im Projekt, PlanungAuftraggeber
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
314
Beispiel SENSORIA
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Wissenschaftliche Risiken
Technologische Risiken
Organisatorische Risiken
315
Risikoquellen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Anforderungen
Anforderungen insgesamt unausgereift oder in Teilen noch unklar
Voraussehbar zahlreiche Änderungen
Änderungsfreudigkeit des Kunden/Auftraggebers
Technik
Unrealistisches Design
Einzusetzende Technologie wird erst im Laufe des Projekts am Markt verfügbar
Unklar, ob geforderte Performanz erfüllt werden kann
Erstmaliger Einsatz neuer Tools, Soft- oder Hardwarekomponenten
Anwendung
Hohe Komplexität, viele ungelöste Probleme
Fehlende Erfahrung mit Teilaufgaben
Keine Erfahrung in neuer Anwendungsdomäne
Kunde
Konkurrierende Interessengruppen, Widerstände (z.B. von Anwendern)
Keine Erfahrung mit Auftragsvergabe nach außen
Mangelnde Kooperationsfähigkeit oder –bereitschaft
Integrierte Entwicklung Auftraggeber/Auftragnehmer
316
Risikoquellen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Projektauftrag, -abwicklung
Unrealistische Termine
Unrealistische Budgets
Projektorganisation
Einsatz von Unterlieferanten (generell)
Bekannte Probleme von Unterlieferanten
Zulieferungen von anderen Projekten oder internen Stellen
Ressourcen
Drohender Ressourcenentzug wegen anderer, wichtigerer Projekte
Ressourcenengpässe oder unzuverlässige Ressourcenzusagen
Personelle Mängel
Nicht der richtige Projektleiter (unerfahren, ungeeignet, nicht anerkannt etc.)
Nicht die richtigen Mitarbeiter (mangelnde Qualifikation oder Erfahrung)
Drohender Ausfall von Mitarbeitern (Krankheit, Kündigung)
317
Bewertung von Risiken
Bewertung:Wie schlimm sind die Auswirkungen, wenn das Risiko eintritt?Wie hoch ist die Wahrscheinlichkeit, dass das Risiko tatsächlich eintritt?Ist das Risiko vermeidbar?
Daraus Gesamtbewertung:Wie groß ist das Risiko?
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
318
Gesamtbewertung von Risiken
Üblich: 3-stufige Bewertung
gering, mittel, hoch.
Verrechnungeigentlich nach Formel:
Wahrscheinlichkeit * Schwere
Üblich: tabellarische Bewertung mit „Handjustierung“, d. h. Risiken können auch eine andere Kategorie haben als die der Tabelle
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
319
Beispiel Risikobewertung SENSORIA
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
320
Beispiel Risikobewertung SENSORIA
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
321
Beispiel: Risikoanalyse
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
KonventionalstrafeVerlust von Folgeaufträgen
nur Konventionalstrafe
wird übersehen oder kann nicht korrigiert werden
Auswirkungen mit Ereignisbaum abschätzen
wird rechtzeitig bemerkt und kann korrigiert werden
0,3 * 800.000 €
+ 0,7 * (0,2 * 11 Mio €
+ 0,8 * 1 Mio €)= 2,34 Mio €
Termin-überschreitung
+
+
1 Mio €
+ 10 Mio €
1 Mio €
Zusatzaufwand1000 PT = 800.000€
0,3
0,7
0,2
0,8
2,34 Mio €
errechnetgeschätzt
322
Beispiel: Risikoprioritätenbildung
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Maßnahmen durch Entscheidungsbaum vergleichen
Vergleich der Alternativennichts tun:
0,11 * 2,34 Mio€
= 257.400 €Pioniere:
0,7*16,000 €
+ 0,3*2,356 Mio€
= 718.000 €Korrektur:
0,1*0,8 Mio €
+ 0,9* 3,14 Mio€
= 2,906 Mio €
Korrektur durchführen
Pioniere vorschicken
nichts tun
klappt
klappt nicht
klappt
klappt nicht
klappt
klappt nicht
2,356 Mio €
0 €
2,34 Mio €
20 PT à
800€=
16.000 €
800 T€
2,34 + 0,8 =
3,14 Mio €
0,110,89
0,30,7
0,90,1
323
Beispiel: Risikoprioritätenbildung
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Maßnahmen durch Entscheidungsbaum vergleichen
Vergleich der Alternativennichts tun:
0,25 * 2,34 Mio€
= 585.000 €Pioniere:
0,7*16,000 €
+ 0,3*2,356 Mio€
= 718.000 €Korrektur:
0,7*0,8 Mio €
+ 0,3* 3,14 Mio€
= 1,602 Mio €
Korrektur durchführen
Pioniere vorschicken
nichts tun
klappt
klappt nicht
klappt
klappt nicht
klappt
klappt nicht
2,356 Mio €
0 €
2,34 Mio €
20 PT à
800€=
16.000 €
800 T€
2,34 + 0,8 =
3,14 Mio €
0,250,75
0,30,7
0,30,7
324
Maßnahmen entwickeln
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Maßnahmen zielgerichtet entwickeln: für Risiken mit hohem Risiko sollte es Maßnahmen geben.
Gegebenenfalls kann man sich auch explizit entschließen ein Risiko einzugehen oder sich schon Maßnahmen einfallen lassen, um die Auswirkungen bei Eintritt zu mildern.
325
Beispiel SENSORIA
VorgehensweiseBeobachtung von „Symptomen“Planung von Korrektivmaßnahmen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
327
Typische Präventivmaßnahmen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Bei technischen Risiken:
Simulation oder Prototyping von Systemen
Beratung, Reviews durch Unabhängige
Anbieten alternativer Funktionen/Konzepte (bei denen das Risiko nicht auftritt)
Vorherige Erprobung von neuen Technologien
Bei Risiken bezüglich Anforderungen/Kunde:
Verstärktes Bemühen um den Kunden, Kontaktpflege
Kundenworkshops
(Frühzeitige) Abnahme von Zwischenergebnissen vereinbaren
Pflichten des Kunden vertraglich absichern
328
Weitere Beispiele für Präventivmaßnahmen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Bei Ressourcenproblemen:
Schulung, Coaching von Mitarbeitern/Projektleiter
Einsetzen von Mitarbeitern in ähnliche Projekte im Vorfeld
Abwanderungsgefährdete Mitarbeiter zu halten versuchen
Prioritäten für die Ressourcenzusage mit Management diskutieren
Sonstiges
Preisaufschläge einkalkulieren
„Outsourcen“ von Risiken an Subunternehmer
330
Maßnahmen umsetzen und Wirkung prüfen
Maßnahmen sind Aufgaben:ein Verantwortlicherein Termin, bis zu dem die Maßnahme umzusetzen ist
Maßnahmen müssen wie jede andere Aufgabe auch nachgeprüft werden:
wurde die Aufgabe wirklich erledigt?
Maßnahmen können aber auch zu geringe Wirkung haben:
neue Maßnahmen oder konsequentere Umsetzung.
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
331
Dokumentation von Risiken: die Risikoliste
Eine Risikoliste umfasst:Beschreibung des Risikos
Name, BezeichnungWas kann passieren?Was sind die Konsequenzen?
BewertungWie groß ist der Schaden?Wie groß ist die Eintrittswahrscheinlichkeit?Gesamtbewertung
MaßnahmenMaßnahme, AufgabeVerantwortlicherTerminStatus
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
332
Beispiel: Risikobewertung
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
lfd.Nr.
Beschreibung
Wahrschein. Auswirkung Gewicht Gegenmaßnahme verantwortlich
Risikoliste zur Priorisierung von Risiken
1
Zulieferer fällt aus
30%
100 T 30 T 2. Zulieferer Störrle
2
Terminüber-
25%
2,34 M€
585 T€
Enge Kontrolle Wirsingschreitung
333
Tipps zum Risikomanagement
Risikomanagement darf kein leerer Formalismus sein – es muss gelebt werden.Risiken ernst nehmen, bei Erhebung nicht abblocken. Nicht sagen:„Das schaffen wir schon“Risiken gehen alle an: Mitarbeiter sollten alle die Top-5-Risiken kennenRisiken konkret formulieren – nicht abstrakt
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
334
Änderungsmanagement: Ein Szenario
Anwender Schulze:„In dem Fenster stört mich, dass ich nur zwischen den Anreden ‚Herr‘ und ‚Frau‘ auswählen kann. Eine zusätzliche Anrede ‚Familie‘ wäre praktisch.“
PL: „Ich kenne den Entwickler Meier, den rufe ich an und der macht das für mich.“Meier:
„Klar, das mach ich doch so nebenbei. Im nächsten Release ist das drin.“Alles klar?
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
335
…und die Fortsetzung
Wird das auch getestet? Irgendwo sonst im Code stand nämlich: if (anrede == „herr“) then …
else …
Passt das zu allen Schnittstellen?Wie lange dauert das Programmieren? Was bleibt deshalb liegen?Wer bezahlt das denn? – Insbesondere bei Projekten zum Festpreis
Ist das so wichtig wie der Änderungswunsch von Frau Schmidt?Ist das wirklich fachlich richtig?
Vielleicht war in der Anrede bisher das Geschlecht der Person codiert.Wer zieht das in der Nutzerdokumentation nach?
Änderungen in größeren Projekten erzeugen Unruhe, gefährden Termine, sorgen für sinkende Qualität!
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
337
Änderungsmanagement
Änderungen an Entwicklungsergebnissen sind unvermeidlichÄnderungen der AufgabenstellungNeue Erkenntnisse bei der ProduktentwicklungFehler bei der Produktentwicklung
Ziel der formalisierten Behandlung von Änderungen (Change Request) ist es, die Konsistenz der Entwicklungsergebnisse zu erhaltenÄnderungen beziehen sich auf definierte Entwicklungsergebnisse (Baselines) und haben Auswirkungen auf
Teilprozesse (Meilensteine)Davorliegende Entwicklungsergebnisse (Backtracking)Nachgelagerte Entwicklungsergebnisse
Änderungen werden einzeln oder als "Versionsentwicklung" durchgeführt
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
338
Change Request
Ein Change Request ist eine Forderung nach einer Abweichung vom ursprünglich vereinbarten Leistungsumfang, vom Auftrag
Es gibt positive und negative Change Requests: Umfang kann steigen oder sinkenRegelfall: Umfang steigt
Change Requests können vom Auftraggeber und vom Auftragnehmer eingebracht werden
Regelfall: AuftraggeberChange Requests können nicht nur die Software, sondern z. B. auch die Projektorganisation oder das Projektvorgehen betreffenChange Requests können sich auf bereits erstellte oder auf noch zu erstellende Ergebnisse beziehen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
339
Change Request-Verfahren
Das Change Request-Verfahren sorgt dafür, dass Änderungen kontrolliert in das Projekt einfließenEin Change Request sollte folgende Fragen beantworten bzw. stellen:
Was genau ist das Problem, was genau ist die Lösung?Wer will das, wer bezahlt das, wer ist davon betroffen?Wie wichtig ist der Change Request im Vergleich zu anderen? Was ist die Konsequenz, wenn der Change Request nicht umgesetzt wird?Welche Konsequenzen für Zeit, Budget, Projektinhalte hat der Change Request? (Zu ermitteln gemeinsam mit PL und Anforderer)
Beim Hinschreiben merkt man oft schon, dass mit Change Request etwas nicht stimmt.
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Change Request bewerten
Change Request formulieren
Change Request entscheiden
Change bearbeiten
340
Change Request-Verfahren
Möglichkeiten der Entscheidung über Change Request:zulassenablehnenzurückstellen
Entscheidung durchProjektleiter (kleinere Change Requests)Lenkungskreis (größere Change Requests)
Die Änderung in die Projektplanung einarbeitenPlanung ändern
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Change Request bewerten
Change Request formulieren
Change Request entscheiden
Change bearbeiten
341
Hinweise zum Change Request -Verfahren
Bearbeiten von Change Request-Anträgen dauert und kostet Geld, egal, ob diese umgesetzt werden oder nichtBei Projektbeginn schon die Spielregeln für Change Request-Verfahren bekannt machen, z. B. im Angebot bzw. im Projektauftrag beschreibenChange Requests technisch managen:
TabellenkalkulationSpezialsoftware, oft in Verbindung mit Konfig-Management und AnforderungenFreeware: BugZilla
Zurückgestellte Change Requests sind oft Basis für eine Folgestufe des ProjektsÜberspitzt formuliert ist ein Change Request-Verfahren ein Change-Verhinderungs-Verfahren:
Ein Change Request, der so ein Verfahren erfolgreich passiert, muss wirklich wichtig sein.
Changes sind keine FehlerOft schwierig auseinander zu halten, werden ähnlich gemanaged und eingeplant
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
342
Missbrauch des Change Request-Verfahrens
Anbieter gibt auf Ausschreibung ein nicht kostendeckendes, niedriges Angebot ab
Anbieter bekommt Zuschlag.Projekt startet
Auftraggeber ist an Anbieter gebundenDen Anbieter zu wechseln verzögert, das Projekt kostet mehr Geld
Im Verlauf eines Projekts ergeben sich zwangsläufig Change Requests des Auftraggebers
Anbieter finanziert das Projekt über Change RequestsAnbieter optimiert seinen Gewinn über Change Requests
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
343
Konfigurationsmanagement : Szenarien in der Software-Entwicklung
Szenario 1: „Der Fehler war doch schon mal draußen!“Wo kommt der Fehler denn jetzt wieder her, den habe ich doch schon vor Wochen beseitigtUrsachen: Code von anderen übernommen, mit der falschen Datei weitergearbeitet, etc.
Szenario 2: „Warum läuft das denn jetzt nicht mehr?“Mehrere Personen entwickeln gemeinsam. Auf jedem einzelnen Entwicklungsrechner ist der Code lauffähig, bei der Integration der beiden Codeteile nicht mehr.
Szenario 3: Wir müssen einen Fehler beheben. Und zwar in der Programmversion, die wir vor 6 Wochen ausgeliefert haben
Was war denn da genau für ein Code drin? Die neue Version ist noch nicht fertig und kann nicht genutzt werden.
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
344
Konfigurationsmanagement : Szenarien in der Software-Entwicklung
Szenario 4: Was habe ich denn eigentlich alles geändert?Der Code auf dem Entwicklerrechner ist lauffähig, aber es ist nicht klar, welche Dateien jetzt wirklich geändert wurden und welche nicht.
Szenario 5: In der Online-Hilfe ist das neue Fenster ja gar nicht beschrieben
Der Text ist aber irgendwo erstellt worden. Aber leider passen auch die GIFs nicht mehr zum Hilfetext in HTML.
Professionelle Software-Entwicklung benötigt professionelles Management der erstellten Ergebnisse/des Codes –
Konfigurationsmanagement
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
345
Konfiguration und Konfigurationsmanagement
KonfigurationsmanagementZiel:
Produkt ist hinsichtlich seiner funktionellen (Code) und äußeren (zugehörige Information) Merkmale jederzeit identifizierbar
Funktion:Sicherstellung der Identifizierbarkeit, Verfolgbarkeit, Kontrollierbarkeit, StatusDarstellung der Zusammenhänge und Unterschiede zwischen verschiedenen KonfigurationenSicherstellung der Verfügbarkeit früherer KonfigurationenSicherstellen der Integrität (Gültigkeit, Reifegrad) von Produkten
Ansatz: Explizite Verwaltung von Produkten und ihrer Versionen
KonfigurationEine Konfiguration ist eine (konsistente) Anordnung von Produkten einschließlich ihrer Beziehungen
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
346
Produkte und Aktivitäten
Produkt und Aktivität
Aktivitäten:Benötigen, erzeugen, modifizieren Produkte
Produkte:Synchronisieren, beeinflussen Aktivitäten
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
347
Konfigurationsmanagement: Produktzustände
Produktzustände:Definiert auf allen Produkten des V-ModellsVerbinden KM mit allen weiteren ModulenErmöglichen Produktverwaltung
Zusammenhänge:KM: Erfassung Produkt, Produktstatus, ProduktänderungQS. Überprüfung/Abnahme ProduktPM: Planung Produkt
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
349
Aufgaben Konfigurationsmanagement
Aufgaben KonfigurationsmanagementPlanung KonfigurationsmanagementBereitstellen Produkt-/KonfigurationsmanagementBereitstellung ÄnderungsmanagementBereitstellung von elementaren Diensten
Daten administrieren:-
Zentrale, projektübergreifende Haltung aller Daten-
Konsistente, vereinheitlichte DatendefinitionenSW-/HW-Produkte katalogisieren: Vorbereitung WiederverwendungSchnittstellen koordinieren: Sicherung kompatibler SchnittstellenErgebnisse sichern: Wahrung des erreichten ProjektstandsKM-Dokumentation führen zur Erstellung von Detailunterlagen und Übersichten verschiedenster KM-Belange,Release-Management: Kontrollierte Konfigurationsfreigabe- und verteilungProjekthistorie führen: Nachvollziehbare Dokumentation über den Projektverlauf
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
350
Techniken des Konfigurationsmanagements
Einfachster Fall: Konfigurationsmanagement durch gemeinsame AblageVersionsverwaltungBilden von KonfigurationenAufgabenbezogenes Arbeiten
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
351
Einfachster Fall: Konfigurationsmanagement durch gemeinsame Ablage
Idee: alle Mitarbeiter arbeiten auf einer gemeinsamen Ablage, z. B. einem zentralen Repository oder einem gemeinsam genutzten Dateisystem.
Alle Änderungen sind damit für alle sofort sichtbar.Dateien sind gesperrt, so lange sie bearbeitet werden.
Häufig bei gemeinsam genutzten Modellierungstools (z. B. UML-Werkzeugen) anzutreffen.Funktioniert nur bei kleinen Teams und wenn die Mitarbeiter meistens auf disjunkten Dateibeständen arbeiten.Löst die meisten Probleme in den Eingangsszenarien nicht
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
353
Versionsverwaltung
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Idee: zentrales Repository (Datenbank)Verwaltet alle Dateien in allen jemals erstellten Versionen
Entwickler kopiert Dateien auf seinen Rechner (zum Lesen)Falls er eine Datei ändern will: checkout.Eine neue Version wird erstellt.Falls er die geänderte Datei in das Repository einstellen will: check-in.
Neue Version ist für alle anderen Entwickler verfügbar. Man kann aber auch auf alte Versionen zurückgreifen.
354
Versionsverwaltung -
Konflikte
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
Ein zweiter Nutzer will die Datei ändern:System kann dies verhindern (Normalfall)
oderSystem warnt, dass Datei zwischenzeitlich verändert wurdeNutzer führt eigene Änderungen mit fremden Änderungen zusammen
355
Versionsverwaltung
Der aktuelle Stand der Gesamtsoftware ist derjenige, der aktuell im Repository eingecheckt ist.Typisches Vorgehen: nightly builds
Alle Mitarbeiter müssen bis zum Abend ihren Code wieder in das System eingecheckt haben, damit kein Code gesperrt ist.Nachts wird der gesamte Code compiliert.
Wessen Code einen Compile-Fehler erzeugt, gibt eine Runde aus ☺Der nächtlich erzeugte Stand ist die Grundlage für die Arbeit am nächsten Tag
Probleme:Änderungen, die mehrere Tage in Anspruch nehmen, werden nicht unterstütztWie kommt man an den Stand vom letzten Februar?
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
356
Erweiterung: Bilden von Konfigurationen
Eine Konfiguration/Release legt zu jeder Datei festIst die Datei Teil der Konfiguration?In welcher Version ist sie Teil der Konfiguration?
Damit lassen sich beliebige Softwarestände konservieren und wieder herstellen. Das Laden einer Konfiguration ist möglich.Einsatzszenarien:
Als Ergänzung zum bisher geschilderten Vorgehen, nur mit mächtigerer HistorieStatt nightly builds: ein Mitarbeiter übernimmt die Rolle des Konfigurationsmanagers
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
357
Erweiterung: Aufgabenbezogenes Arbeiten
Problem: Um eine Änderung durchzuführen, müssen mehrere Dateien verändert werden. Diese Dateien sollen gemeinsam verwaltet werden.
Aufgabenbezogenes ArbeitenIn das Konfigurationsmanagement wird der Begriff der Aufgabe „Task“eingeführt. Ein Beispiel für eine Task ist: „Bearbeitung CR 234“ oder „Behebung Fehler XYZ“Der Entwickler meldet im Konfigurationsmanagement an, dass er eine bestimmte Task bearbeiten will. Alle jetzt bearbeiteten Dateien werden dieser Task zugeordnet.Diese Task lässt sich dann als eine Einheit verwalten, z. B. laden oder alle bereits gemachten Änderungen verwerfen.
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
358
Festlegungen für das Konfigurationsmanagement
Was soll alles verwaltet werden?CodeDokumentation?Testfälle?Executables?…
Wie ist das KM aufgesetzt?Eingesetztes ProduktProzesse: Wann darf wer den Code verändern?Verantwortliche: Wer darf Releases und Versionen erstellen?
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
359
Zusammenfassung
Risikomanagement umfasst sowohl die Identifikation und Bewertung von Risiken als auch die Planung, Durchführung und Prüfung der Wirkung von Korrektivmaßnahmen.Risiken werden nach ihrer Eintrittswahrscheinlichkeit und ihren Auswirkungen auf das Projekt (Schwere) bewertet und der nach Formel verrechnet:
Wahrscheinlichkeit * SchwereÄnderungsmanagement: Ziel der formalisierten Behandlung von Änderungen (Change Request) ist es, die Konsistenz der Entwicklungsergebnisse zu erhaltenEin Change Request ist eine Forderung nach einer Abweichung vom ursprünglich vereinbarten Leistungsumfang, bezieht sich typischerweise auf definierte Entwicklungsergebnisse oder die Organisation des Projekts und hat Auswirkungen auf
Teilprozesse (Meilensteine), davorliegende und nachgelagerte Entwicklungsergebnisse
Eine Konfiguration ist eine (konsistente) Anordnung von Produkten einschließlich ihrer Beziehungen. Aufgabe des Konfigurationsmanagement istdie Verwaltung von Produkten und Konfigurationen und deren Änderungen. Die Techniken des Konfigurationsmanagement umfassen
gemeinsame Ablage, Versionsverwaltung, Bilden von Konfigurationen undaufgabenbezogenes Arbeiten
Projektmanagement M7 –
Risiko-, Change-
und Konfigurationsmanagement
361
Ziele
Wichtige Modelle zur Prozessverbesserung kennen lernenISO 9000 ff
Capability Maturity Model (CMM)
Software Process Improvement and Capability dEtermination (SPICE) ISO 15504
Konkrete Möglichkeiten zur Prozesseinführung und -verbesserung
kennen lernen
Projektmanagement M9 -
Prozessverbesserung
362
Prozessverbesserung
Beobachtung: Qualitätsverbesserung führt zuReduktion der EntwicklungszeitReduktion der EntwicklungskostenSteigerung der Wettbewerbsfähigkeit
Ansatz:Verbesserung EntwicklungsqualitätVerbesserung Entwicklungsprozess
(Software-)Entwicklungsprozess umfasst(Software-)lebenszyklusabhängigen Anteil
Analyse, Entwurf, RealisierungLebenszyklusunabhängigen Anteil
Planung, Kontrolle, Qualitätssicherung, KonfigurationsmanagementOrganisationsspezifischen Anteil
Prozess-Definition,-Bewertung, -Verbesserung, Ausbildung
Projektmanagement M9 -
Prozessverbesserung
363
Strukturierte Verbesserungsansätze
Ziele:Bereitstellung systematisches VorgehenRichtlinen für ProzesserfassungMetriken für ProzessbewertungMaßnahmen zur Prozessverbesserung
Ansätze:EFQM (European Foundation of Quality Management)
abstrakter, ganzheitlicher Ansatz, fragebogenbasiertCMM (Capability Maturity Model):
Reifegradbasiert, assessmentorientiertBOOTSTRAP
ähnlich CMM, detallierter, flexiblerSPICE (Software Process Improvement and Capability dEtermination)
ähnlich CMM, ISO-basiert, integriert ISO 9000, detallierter, umfassender
Projektmanagement M9 -
Prozessverbesserung
365
ISO 9000 ff –
Qualitätsmanagementsystem
ISO 9000 ff behandelt Qualitätsmanagement allgemein – nicht nur für Software. Teil 9000-3 bezieht sich auf Software.Idee: Die Gesamtheit der QS-Prozesse, Organisationsstrukturen etc. einer Firma bildet das Qualitätsmanagementsystem (QMS). Man kann Anforderungen an ein solches System definieren und ein QMS zertifizieren. Diese Zertifizierung muss in regelmäßigen Abständen wiederholt werden.Fragestellungen:
Sind die Prozesse festgelegt und dokumentiert?Werden diese Prozesse auch umgesetzt?Führen diese Prozesse zu guten Resultaten?
Projektmanagement M9 -
Prozessverbesserung
366
ISO 9000 ff –
Praxisbeispiele
Negativbeispiel: „erschlichene Zertifizierung“Positivbeispiel:
Eine Firma hat ein funktionierendes, schlankes QMSDie Auditierung für die Zertifizierung nach ISO 9000 hält diesem QMS den Spiegel vor:
Wo kann man das QMS noch verbessern?Wo sind Punkte, die man aus Betriebsblindheit übersehen hat?
Die angestrebte Zertifizierung erzeugt im Projektalltag einen gewollten Druck, damit Qualitätssicherungsaspekte nicht untergehen können.Die Produktqualität steigt, Qualität ist im Bewusstsein aller verankertDie bestandene Zertifizierung ist eine „Belohnung“, ein Lob über das sich alle freuen.
Projektmanagement M9 -
Prozessverbesserung
367
ISO 9126-1 Qualitätsmerkmale
Fragestellung: woran misst man Qualität?Problemstellung im Projekt:
Sicherstellen, dass kein wichtiger Aspekt übersehen ist:Bei der Definition von Qualitätszielen im QM-PlanBeim Erheben von Anforderungen
Ein Auftraggeber weiß unter Umständen gar nicht, dass er eine Anforderung zu einem bestimmten Kriterium hat oder er hält sie für so selbstverständlich, dass er sie gar nicht nennt.
ISO 9126-1 enthält ein Qualitätsmodell, in der Praxis am wichtigsten sind die Qualitätsmerkmale (quality model for external and internal quality)
Projektmanagement M9 -
Prozessverbesserung
368
SW-Qualität nach ISO 9126 (Wiederholung)
6 Qualitätsmerkmale nach DIN ISO 9126Funktionalität:
Vorhandensein von Funktionalität entsprechend den Anforderungen Richtigkeit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit
Zuverlässigkeit:Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu erbringenReife, Fehlertoleranz, Wiederherstellbarkeit
Benutzbarkeit:Aufwand für Benutzung, Beurteilung von BenutzergruppenVerständlichkeit, Erlernbarkeit, Bedienbarkeit
Effizienz: Verhältnis zwischen Leistungsniveau der SW und Umfang der eingesetzten BetriebsmittelZeitverhalten, Verbrauchsverhalten
Änderbarkeit: Aufwand für Korrekturen, Verbesserungen, AnpassungenAnalysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit
Übertragbarkeit: Eignung zur Übertragung in andere SW oder HW UmgebungAnpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit
Projektmanagement M9 -
Prozessverbesserung
369
CMMI
Capability Maturity Modelvon der Carnegie Mellon University (Software Engineering Institute) entwickeltes Qualitätsmanagementmodell (1991)2002 Aktualisierung zu Capability Maturity Model Integration (CMMI), in der zwischenzeitlich entstandene Spezialformen des CMM integriert wurden:
Software-CMM, Software Engineering-CMM, Integrated Product Development-CMM
Idee:Ausgangsfrage: Wie reif ist eine Organisation? Wie reif sind ihre Software Engineering Prozesse?Definition von fünf Stufen, um die Reife einer Organisation zu bewerten.
Projektmanagement M9 -
Prozessverbesserung
370
Capability Maturity Model (CMM) Aufbau
Ziel:Erhöhung der Qualität und ProduktivitätReduktion des Risikos
Verfahren: Stufenorientiert5 Stufen von 1 (schlecht) bis 5 (gut) zur Einordnung der aktuellen Prozessreife („maturity“) anhand von 18 Prozessbereichen („Key Process Areas“, KPAs)Feststellung der Einordnung mittels fragebogenbasierten AssessmentsStrukturierte Handlungsempfehlungen entsprechend Prozessreife
Zertifizierung: Einer Organisation wird die Reifegradstufe i nach CMM attestiert, wenn alle Prozessbereiche von der Organisation beherrscht werden, die zu den Reifegradstufen 1 bis inklusive i gehören.Solche Zertifizierungen sind langwierig und teuer, und im wesentlichen nur für sehr große Organisationen geeignet.Man rechnet ca. 2-3 Jahre um von Reifegradstufe i nach Reifegradstufe i+1 zu gelangen. Es gibt aber auch Fälle, wo eine Level-5-Organisation „auf der grünen Wiese“ aufgebaut wurde.
Projektmanagement M9 -
Prozessverbesserung
371
CMM Anspruch der Prozessverbesserung
Projektmanagement M9 -
Prozessverbesserung
Effizienz steigt ständig weiter„Processes are continuously and systematically improved.“
Ständige Verbesserung von Präzision und Effizienz.„Processes are quantatively understood and stabilized.“
Ausreißer werden selten„Problems are anticipated and prevented.“
Immer noch viele Pannen, aber realistischere Planung„Success depends on individuals, management supports.“
ungerechtfertigt optimistische Planung„Success depends on individual heroics.“
5
4
3
2
1
Zielgröße
Wsk
.
Ziel
Level
Ablauf
abgedeckte Prozessbereiche (KPAs)
372
CMM-Stufen
Level 1: „Initial“Wir machen es irgendwie.Wir wissen nicht so genau, wie wir es machen.
Level 2: „Managed“ (alter Name: „Repeatable“)Es gibt einen Software-Engineering Prozess.Was wir einmal hinbekommen haben, kriegen wir auch erneut hin.Das ist aber auch abhängig von den jeweiligen Personen.
Level 3: „Defined“Der Software-Engineering Prozess ist standardisiert.Wir können den Prozess auch umsetzen, wenn es mal schwierig wird.
Level 4: „Quantitatively Managed“ (alter Name: „Managed“)Der Prozess wird organisationsweit standardisiert durchgeführt.Die Ausführung des Prozesses wird dokumentiert und mitKennzahlen gemessen.
Level 5: „Optimizing“Aus den Kennzahlen leiten wir ab, wie wir uns verbessern können.
Projektmanagement M9 -
Prozessverbesserung
374
CMM und CMM-I Bewertung und Ausblick
CMM war der erste systematische Ansatz zur Prozessverbesserung.Das CMM war aber in vielerlei Hinsicht unbefriedigend
unvollständigteuer und langsam, daher nur für große Organisationen geeignetsehr stark auf Qualität fixiert, daher nicht in allen Anwendungsgebieten kosteneffizient / wirtschaftlich sinnvoll: good-enough is better.
Es gab daher Verbesserungsbemühungen für die geplante Nachfolgeversion CMM v2.0. Parallel wurden aber auch andere Ansätze (weiter-)entwickelt, insbesondere ISO 12207 & ISO 15504.Die Nachfolgeversion von CCM ist
„Integriertes CMM“
(CMM-I), das sehr ähnlich zu ISO 12207 ist.
Projektmanagement M9 -
Prozessverbesserung
375
SPICE/ISO-15504 Ursprünge
Projektmanagement M9 -
Prozessverbesserung
S oftwareP
rocess
I
mprovement &C
apability
d E
termination
ISO/IEC TR 15504(SPICE)
SW-CMM ISO 12207
ISO-15504
SPICE war ursprünglich eine Europäische Initiative,wird heute sehr stark in Australien und Japan vorangetrieben
376
SPICE/ISO-15504 Grundprinzipien
Ansatz:Integration existierender Ansätze, z.B.:
CMMISO 9000
Verfahren:Bewertung des Entwicklungsprozesses durch AssessmentsUnterteilung in Prozess- und ReifegraddimensionUnabhängige Bewertung der ProzessdimensionenIdentifikation von Verbesserungsmöglichkeiten
Projektmanagement M9 -
Prozessverbesserung
377
SPICE/ISO-15504 Grundprinzipien
Prüfung der im Unternehmen gelebten Prozesse gegen ein ProzessmodellAnalyse der Stärken und SchwächenErstellung von Verbesserungsvorschlägen
Projektmanagement M9 -
Prozessverbesserung
378
SPICE und CMM
Wesentliche Neuerung gegenüber CMM:Reifegrad von einzelnen Prozessen und nicht von einem ganzen Unternehmen.
Ansatz:Eine Reihe von Prozessen
Eine Bewertung des Reifegrads für jeden Prozessunabhängig von anderen
Projektmanagement M9 -
Prozessverbesserung
379
SPICE/ISO-15504 Dimensionen
Prozessdimension:Umfang: 3 Kategorien, 11 Unterkategorien, ca. 50 Prozesse Kategorien:
Primäre Prozesse (Aquisitionsprozesse, Kunde-Zulieferer-Prozesse, Entwicklungsprozesse, ...)Unterstützende Prozesse (Konfigurationsmanagement, Produktkontrolle, Qualitätssicherung)Organisation (Management,Prozessverbesserung, Ressourcen und Infrastruktur, Wiederverwendung)
Reifegraddimension:Umfang: 6 Stufen, 9 AttributeDefiniert für jeden Prozess
Projektmanagement M9 -
Prozessverbesserung
381
SPICE/ISO-15504 Reifegradbestimmung von Basispraktiken basierend auf 9 Attributen
Projektmanagement M9 -
Prozessverbesserung© wibas GmbH
383
SPICE/ISO-15504 Bedeutung und Bewertung
Internationale Standard im Bereich Prozessverbesserung, es sind zur Zeit ca. 4000 Beurteilungen in 45 Ländern erfolgt.Verbreitung von SPICE vor allem in Europa, CMM vor allem in USA,Indien, China.
SPICE ist in vielerlei Hinsicht besser als CMM, aber vergleichbar mit CMMI und (der zugehörigen Assessmentmethode SCAMPI).
SPICE istmoderner: terminologisch und konzeptuell reifer;umfassender: deckt wirklich alle Prozesse ab, und ist konsistent mit ISO 12207;feinkörniger: präzisere Erfassung des Standes und der Ziele; flexibler: andere Ausrichtung als bestmögliche Qualität möglich (insbesondere auch wirtschaftliche Kenngrößen);leichter: Auch für kleine Firmen sinnvoll einsetzbar.
Aber: wie alles erfordert auch SPICE erhebliche Sachkenntnis.Projektmanagement M9 -
Prozessverbesserung
384
SPICE/ISO-15504 Weitere Entwicklung
Ein neue Version ISO/IEC 15504:2003/2005/2006
wurde im März 2006 veröffentlicht.
Spezialisierungen nach Branchen werden parallel entwickelt.SPICE 4 Space (ESA)Automotive SPICEMediSPICEOOSPICE (Komponentenbasierte Entwicklung)IT Infrastructure SPICE
Projektmanagement M9 -
Prozessverbesserung
385
Nutzen von Prozessverbesserung Empirische Werte
Projektmanagement M9 -
Prozessverbesserung
Capability MaturityModel (CMM)
Level 1
Level 2
Level 3
73%
16%
10% 45
0,6%0,4%
Untersuchung des CMM, Stand 3.3.2000knapp 500 untersuchte Institutionen
Je AuslieferungProzentpunkte
Fehler -50Dauer -30
Fehler -
20Dauer -10
386
Nutzen von Prozessverbesserung Empirische Werte
CMMLevel
Monate Personen-Monate
gefundeneFehler
ausgelieferteFehler
Gesamtkosten(1000 US$)
1 29,8 593,5 1348 61 5.440
2 18,5 143 328 12 1.311
3 15,2 79,5 182 7 728
4 12,5 42,8 96 5 392
5 9 16 37 1 146
Projektmanagement M9 -
Prozessverbesserung
Daten für ein 200 KLoC-Projekt (Schätzung der SemaTech)
387
Der Wasserfallprozess als Basis für empirische Untersuchungen
Projektmanagement M9 -
Prozessverbesserung
Prozessmessung und -verbesserung ist heute sehr stark auf das Wasserfallmodell hin ausgerichtet -
aber wie geht Prozessverbesserung
von „agilen“
Prozessen?
388
Prozessverbesserung: Nebenwirkungen
Strukturierte Prozessverbesserungsansätze:Ziele:
Messung/Steigerung Prozessproduktivität/QualitätMessung/Reduktion Risiken
Ansatz: Standardisierung EntwicklungsprozessNebenwirkung:
Zusätzlicher Aufwand für ProzessverbesserungProzessoptimierung nur für traditionelle/StandardproblemeNeue Domänen verursachen:
Neue Entwicklungsmethoden (Stufe 1)Neue Qualitätssicherungsverfahren (Stufe 2)Neue Prozessdefinitionen (Stufe 3)Neue Prozesskennzahlen (Stufe 4)
Beispiel:Wechsel von Controlling-Systemen zu Billing-Systemen
Projektmanagement M9 -
Prozessverbesserung
389
Prozessverbesserung: Risiken
Risiko: Verselbständigte ProzessverbesserungProzessbewertung wichtiger als Prozessverbesserung
„Ranking“ als Ziel der ProzessverbesserungÜbertriebenes Sicherheitsdenken:
Fokussierung auf stabilen Entwicklungsprozess
Auswirkung:Vermeidung risikoreicher InnovationenÜbernahme neuer Anwendungs-/Geschäftsfelder
„Die Projekte, die es wert sind, gemacht zu werden, werden Sie eine ganze
Ebene auf der Skala nach unten bringen.“
(T. DeMarco, T. Lister Wien wartet auf Dich. Hanser, 1999)
Projektmanagement M9 -
Prozessverbesserung
390
Konkrete Prozessverbesserung Probleme
Die Durchsetzung von Prozessverbesserungen nach CMM/SPICE erfordert
Sachverstand,Entschlossenheit undDurchhaltevermögen
seitens des Managements.
Bücher sind nicht geeignet („Shelfware“).
Poster, Aushänge an öffentlich zugänglichen Orten (4K: Korridor, Kopierer, Küche, Klo) sind hingegen sehr hilfreich.
EPG‘s und Wissens-Portale sind nützlich (-> Spearmint, VM-Browser, RUP-Browser), aber aufwändig.
Projektmanagement M9 -
Prozessverbesserung
391
Prozessreview und -beratung im echten Leben Woche 1
Infrastruktur vorbereitenMail-Ordner anlegen Verzeichnisstruktur im gesicherten Bereich anlegen
Übersicht herstellenOrganigramm
Namen, Bilder, Telefon-/Raumnummern, Email-AdressenKontextdiagramm (-> Stakeholder!)
Stakes, so wie es der Berater aktuell wahrnimmtDas alles auf 4 Seiten A4 und über den Schreibtisch
Ziel feststellenAuftrag: nicht geben lassen, sondern selber formulierenAufwand: Soll/Ist festhaltenVerbessern: bis wohin?Welche Aspekte haben Priorität?
Projektmanagement M9 -
Prozessverbesserung
392
Prozessreview und -beratung im echten Leben Woche 2
Infrastruktur, Übersicht und Ziel pflegen und validierenKontinuierlich abgleichen und ergänzen!
Prüfgegenstände beschaffen
Erfassen und Bewerten bestehender Prozesse
Hilfestellung organisierenKann ich es alleine schaffen: inhaltlich/aufwandsmäßig?Wer kann mir helfen?
Entscheidungsvorlage skizzierenErste Ideen und Stichworte notieren
Projektmanagement M9 -
Prozessverbesserung
393
Prozessreview und -beratung im echten Leben Woche 3
Es gibt in der Regel Defizite in jedem Bereich. Die Prioritäten und Ursachen sind aber von Projekt zu Projekt unterschiedlich.
Meistens ist mit einigen sehr einfachen Maßnahmen schon viel gewonnen.Erfahrungsgemäß sind folgende Maßnahmen schnell wirksam.
Start-/End-Workshops für Projektabschnitte und TeilprojekteOrganigramm zur allgemeinen VerfügungProjektplan mit Terminen, Meilensteinen und Verlaufsdaten des Projektes veröffentlichen (Poster, Kaffeeküche)Risikomanagement einführenErfolgskritische Teile identifizieren (in Abstimmung mit Kunde und Projektleitung), Stand dieser Teile mit Inspektionen bestimmen.Issue-Management einführenKonfigurations- und Änderungsmanagementautomatisches Make/Build
Projektmanagement M9 -
Prozessverbesserung
394
Zusammenfassung
Der gebräuchlichste Ansatz zur Verbesserung von Produktqualität führt über die Verbesserung der Prozessqualität.Die bedeutendsten Ansätze zur Prozessverbesserung sind CMMI und ISO 1504 (SPICE). Diese Ansätze sind oft teuer und langsam, aber letztlich alternativlos.Prozessqualität bemisst sich, abgesehen von der Produktqualität, nach Produktivität, Prognostizierbarkeit und Flexibilität.Bevor ein Prozess verbessert werden kann, muss es zunächst überhaupt einen definierten Prozess in einer Organisation geben.Etwa 2/3 aller SW-Organisationen haben keinen Prozess.Wo vollumfängliche Prozesseinführung unangemessen ist, kann man sich mit einigen einfachen ersten Schritten behelfen.
Projektmanagement M9 -
Prozessverbesserung
395
Nachbemerkungen (1)
Qualitätsmanagement ist eine eigene Vorlesung, hier geht es um die Ideen und die Einordnung zum Projektmanagement.In einem Formalismus stecken auch Gefahren:
Es können riesige Regelwerke entstehen, die niemand mehr überblicken kann und deren Inhalte nicht gelebt werden können. Hat ein Formalismus erst einmal diese Größe erreicht, ist er tot. Auch die vorhandenen sinnvollen Inhalte sind dann nutzlos.Eine „hauptberufliche“ QS neigt zur Überreglementierung, indem jeder Handschlag vorgeschrieben ist. Das tötet den Spaß an der Arbeit und letztendlich auch die Qualität.Einen Formalismus betreiben und überwachen kann man auch, wenn man keine Ahnung von den eigentlichen Inhalten der Arbeit hat. Dann hält man sich an Formalia fest, die eigentlich unnütz oder sogar schädlich sind.
Projektmanagement M9 -
Prozessverbesserung
396
Nachbemerkungen (2)
Jeder leere Formalismus ist nutzlos. Durch Formalismen lässt sich Qualität nicht erzwingen. Wenn Sie im Projekt auf solche Fossilien treffen, beseitigen Sie diese.Wenn aber im Projekt Qualität gelebt wird, sind Formalismen hilfreich
Sie geben einen Rahmen.Sie stellen sicher, dass nichts übersehen wird oder in Vergessenheit gerätSie können die Priorität der Ecke „Qualität“ im Teufelsquadrat erhöhen.
Insbesondere sollte man sich um den Software-Prozess kümmern - es lohnt sich.Das wichtigste ist, sich überhaupt zu kümmern. Wie das geschieht, ist eher zweitrangig.
Projektmanagement M9 -
Prozessverbesserung
Recommended