Projektmanagement: Einführung Bernhard Bauer

Größe: px
Ab Seite anzeigen:

Download "Projektmanagement: Einführung Bernhard Bauer"

Transkript

1 Projektmanagement: Einführung Bernhard Bauer Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße 14, Augsburg Tel.: (+49) 821/ , Fax: URL:

2 Ziele der Vorlesung Lernziele: Die Studierenden sind in der Lage, sich in einem Projekt zu orientieren können konstruktiv in einem Projekt mitarbeiten haben 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 2

3 Übersicht Einführung Projektvorbereitung Projektplanung Projektkontrolle und steuerung Qualitätsmanagement und Prozessverbesserung Ethische Leitlinien im Software Engineering Projektmanagement M1 - Einführung 3

4 Literatur H. Balzert: Lehrbuch der Software-Technik, Band 2, Spektrum Akademischer Verlag, 2002 I. Sommerville: Software Engineering. Pearson, U. Witschi, A. Erb, R. Biagini, Projekt-Management: Der BWI-Leitfaden zu Teamführung und Methodik. Verlag Industrielle Organisation Zürich, 1996 T. DeMarco, T. Lister: Wien wartet auf Dich. Der Faktor Mensch im DV- Management. Tom DeMarco. Peopleware: Productive Projects and Teams. B&T, Tom DeMarco. Der Termin. Hanser Wirtschaft, Projektmanagement M1 - Einführung 4

5 Folien und Skripte Bernhard Schätz: Vorlesung Projektorganisation und Management, Leopold- Franzens Universität Innsbruck, Sommersemester 2003 Bernhard Bauer: Vorlesungsfolien Projektmanagement Gerhard Pews: Vorlesung Projektmanagement, Universität Kaiserslautern, Wintersemester 2005/06 Martin Wirsing: Vorlesung Projektmanagement 2007 Projektmanagement M1 - Einführung 5

6 Wo sind wir: Welt der Softwaretechnik Technik-Katastrophen: September 1999: Verlust der Sonde "Mars Climate Orbiter" wegen falscher Einheitenumrechnung 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-System 2003: Einführung des LKW-Mautsystems in Deutschland verzögert sich um 18 Monate Projektmanagement M1 - Einführung 6

7 Erfolgreiche und gescheiterte IT-Projekte Erfolgreiche Projekte Projekte mit Abweichungen % 53 % 31 % % 49 % 23 % % 53 % 18 % Gescheiterte Projekte Quelle: Standish Group: Chaos Report Projektmanagement M1 - Einführung 7

8 Aktuelle Fehlschläge CW Probleme mit Hartz-IV-Software Eine Bearbeitung von Erst- und Fortzahlungsanträgen für das Arbeitslosengeld 2 (ALG2) ist seit dem 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 Bayern kippt Polizeisystem Diplaz Nach jahrelangen Querelen rund um das neue Dienstplanungs- und Zeitwirtschaftssystem (Diplaz) hat das bayerische Innenministerium das Projekt gestoppt 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 2006 auf 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 2007 Wä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 8

9 Ziele dieser Vorlesungseinheit Begriffe Projekt und Projektmanagement definieren Schwierigkeiten des Projektmanagement diskutieren Aufgaben des Projektmanagement kennen lernen Tätigkeiten während des Projektverlaufs kennen lernen und im V-Modell wiederfinden Projektmanagement M1 - Einführung 9

10 Begriff Projekt Was sind Projekte? neue Ziele Projekte Experimentierfreude Innovativ Kreativ Risiko Konflikte alte Ziele Sicherheit Festigkeit Standardisierung Genaues Regelsystem Routineaufgaben Veränderungsaufgaben Linien- Organisation alte Wege neue Wege Projektmanagement M1 - Einführung 10

11 Begriff Projekt Ein Projekt ist ein Vorhaben, das im wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.b. Zielvorgabe zeitliche, finanzielle, personelle und andere Begrenzungen Abgrenzung gegenüber anderen Vorhaben projektspezifische Organisation. (DIN ) 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 11

12 Abgrenzung eines Projekts Zeitliche Abgrenzung Zeitplan, Termine, Vor- und Nachprojekt-Phase Sachliche Abgrenzung Ziele, Hauptaufgaben, Nicht-Ziele zu anderen Projekten, Tätigkeiten Soziale Abgrenzung Projektleiter, Projektauftraggeber, Projektteam Umwelt-/Umgebungsanalyse Projektmanagement M1 - Einführung 12

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 13

14 Projektmanagement Projektmanagement umfasst alle Aufgaben bei der Durchführung von Projekten hinsichtlich Vorbereitung (Struktur und Personal) Planung Kontrolle Steuerung Dazu gehören auch projektübergreifende Aufgaben: Projektabschluss und Ergebnisdokumentation Prozessverbesserung Personalführung Interaktion mit dem Kunden und Koordination von Zulieferern. Projektmanagement M1 - Einführung 14

15 Projektmanagement Projektmanagement ist die Kunst mit 10 Fingern 11 Korken unter Wasser zu halten Quelle: G..Pews sd&m Projektmanagement ist einfach zu begreifen, aber schwer zu tun Projektmanagement 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 15

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 really believe 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 16

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 17

18 Schwierigkeiten im IT-Projektmanagement Effizienz vs. Flexibilität: Effizienz: Einsatz bewährter Methoden zur Kostenreduktion: Standardanwendungsdomäne Standardentwicklungsplattform Standardentwicklungsprozess Standardentwicklungsumgebung Flexibilität: Das Unvorhersehbare planen: Änderung der Anforderungen durch den Kunden Änderung der Entwicklungsplattform durch das Management Mitarbeiterfluktuation Änderung des Ausliefertermins durch das Management Verzögerungen durch die Zulieferer Projektmanagement M1 - Einführung 18

19 Schwierigkeiten im IT-Projektmanagement Immaterialität des Produkts: Software ist unsichtbar und damit Für den Kunden schwer erlebbar (Kostenbewusstsein) Bzgl. des Fertigungsgrades schwer messbar Risiko: Umfang, Kosten und Laufzeit Innovativität des Produkts: Software ist i.a. Null -Serie und damit Mit dem Einsatz neuester Technologie verbunden Mit der Realisierung umfassender neuer Funktionen verbunden Risiko: Stabilität (Qualität) und Laufzeit Mangelnde Prozessreife: SE ist eine junge Disziplin und damit fehlen standardisierte und etablierte Entwicklungsprozesse Verständnis für die ingenieurmäßige SE (Kunst vs. Handwerk) Risiko: Qualität und Laufzeit Projektmanagement M1 - Einführung 19

20 Magisches Projektmanagement-Dreieck (Triple Constraints) Projektziel Aufwand Zeitraum Bernhard Bauer, all rights reserved

21 Projektmanagement Teufelsquadrat nach Harry Sneed Zielgrößen auf den Diagonalen: Zeit: Projektlaufzeit Kosten: Budget Qualität: z.b. Funktionalität, Nutzbarkeit, Wartbarkeit Leistungsumfang: 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. Projektmanagement M1 - Einführung 21

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. Projektmanagement M1 - Einführung 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. 22

23 Projektmanagement Zielgrößen Kosten Zeit 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. 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 23

24 Projektmanagement Zielgrößen Qualität Ist der am schwierigsten zu messende Faktor und sind nicht so klar vorgegeben wie Budget und Zeit Qualitä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 24

25 Aufgabenfelder Projektmanagement 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) Es folgt eine Kurzübersicht über deren Themen Projektmanagement M1 - Einführung 25

26 Vorbemerkung: Wann wie viel? Viele der nachfolgend beschriebenen Aufgaben sind nur für Großprojekte im vollen Umfang sinnvoll Bei mittelgroßen Projekten sollten viele davon vereinfacht werden aber welche und wie stark hängt vom Einzelfall ab Bei 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 26

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 Aufgabenfeldern Anmerkung: Ein solcher Plan existiert immer (evtl. nicht detailliert, evtl. nicht einmal schriftlich) Projektleitung konkrete Anweisungen geben, Entscheidungen fällen etc. Projektüberwachung kontinuierlich 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 27

28 Umfangsmanagement (scope mgmt) Umfangsdefinition Was 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 28

29 Zeitmanagement (time management) Entwickeln einer Aktivitätenliste Zu jedem Teilprodukt laut WBS gehören eine oder mehrere Aufgaben (Aktivitäten, also Prozesse) (Zeit-) Aufwandsschätzung für die Aktivitäten Wie 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 29

30 Kostenmanagement (cost management) Kostenschätzung Budgetaufstellung Kostenü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 30

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 ergreifen z.b. korrigieren, Teil wegwerfen und neu bauen, Aufgabe an andere Person übergeben, Entwicklungsprozess ändern, etc. Projektmanagement M1 - Einführung 31

32 Personalmanagement (human resource management) Personalplanung Definition von Rollen, Verantwortlichkeiten, Weisungsbefugnisse (Prozessmodell & Organisationsplanung) Aufstellung eines Personalzeitplans Wie 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, Teamformung Teilnahme an einem Projekt sollte freiwillig sein Mitglieder müssen ein Gemeinschaftsgefühl entwickeln Teamführung Leistung der Mitglieder verfolgen, Feedback geben, Konflikte auflösen, Arbeit bei Änderungen neu koordinieren Projektmanagement M1 - Einführung 32

33 Kommunikationsmanagement (communication management) Kommunikationsplanung Welche Beteiligten brauchen regelmäßig welche Information? Informationsverteilung Den Betroffenen relevante Information stets zügig zukommen lassen Fortschrittsberichte Statusberichte und Planfortschreibung regelmäßig erarbeiten und allen Betroffenen zuleiten Interaktion mit Beteiligten Besprechungen 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 33

34 Risikomanagement (risk management) Risiken identifizieren Welche Ereignisse könnten die plangerechte Durchführung bedrohen? Risikoeinschätzung Risikogrößen abschätzen, Risikobehandlung priorisieren Vorbeugung planen Was wird getan, um welchem Risiko vorzubeugen? Gegenmaßnahmen planen Was wird getan, wenn welches Risiko eintritt? Risikomanagement-Überwachung Kontinuierlich nach neuen oder veränderten Risiken Ausschau halten Fortführung und Wirkung eingeleiteter Vorbeugungen und Gegenmaßnahmen überwachen. Ggf. korrigierend eingreifen Projektmanagement M1 - Einführung 34

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-Lizenzen Ist aber meist nicht sehr kompliziert Projektmanagement M1 - Einführung 35

36 Projektverlauf Projektvorbereitung Projektdurchführung Projektabschluss 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 36

37 Projektverlauf Projektvorbereitung Projektdurchführung Projektabschluss 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 Projektmanagement M1 - Einführung 37

38 Projektverlauf Prozesse im Submodell PM des VM 97 Kunde Projekt Zulieferer Projektvorbereitung Projektdurchführung Projektabschluss Prozesse nach VM 97 (Submodell PM) PM1: Projektinitialisierung PM2: Vergabe/Beschaffung PM3: Auftragnehmer-Management PM4: Feinplanung PM5: Kosten-/Nutzenanalyse PM6: Durchführungsentscheidung PM7: Risikomanagement Projektmanagement M1 - Einführung PM8: Projektkontrolle und steuerung PM9: Informationsdienst/Berichtswesen PM10: Schulung/Einarbeitung PM11: Bereitstellung der Ressourcen PM12: Vergabe von Arbeitsaufträgen PM13: Einweisung der Mitarbeiter PM14: Projektabschluss 38

39 Projektverlauf Prozesse im Submodell PM des VM 97 Projektmanagement M1 - Einführung 39

40 Projektverlauf Prozesse im Submodell PM des VM 97 Projektmanagement M1 - Einführung 40

41 Zusammenfassung (1) Ein Projekt ist eine zeitlich beschränkte Anstrengung zur Erzeugung eines einmaligen Produktes oder Dienstes Projektmanagement bezeichnet Gesamtheit von Führungsaufgaben, - organisation, -techniken und -mitteln für die Abwicklung eines Projektes Das Teufelsquadrat von Sneed beschreibt den Zusammenhang von Zeit, Kosten, Leistungsumfang und Qualität eines Projekts Projektmanagement M1 - Einführung 41

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 aus Projektvorbereitung Projektdurchführung mit Projektkontrolle und -Steuerung Projektabschluss Projektmanagement M1 - Einführung 42

43 Projektmanagement: Prozessmodelle und Projektorganisation

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 ). Projektorganisation Unternehmenss- und Projektstrukturen kennenlernen Einbinden des Projekts in die Unternehmensorganisation bewerten Rollen und Verantwortlichkeiten in Projekten verstehen Projektmanagement M2 Prozessmodelle und Projektorganisation 44

45 Prozessmodell Funktion: Beschreibung und Strukturierung des Prozesses zur Abwicklung eines Projekts Elemente: Phasen Aktivitäten der Phasen (Teil-)Produkte der Phasen Projektrollen (Kompetenzen, Verantwortlichkeiten, Qualifikationen) Richtlinen, Standards, Methoden, Werkzeuge Bernhard Bauer, all rights reserved

46 Paradigmen der SW-Entwicklung Einordnung der anfallenden Tätigkeiten Anforderungsanalyse & Fachliche Konzeption Technische Konzeption (Design, Entwurf) Realisierung Integration & Test in Vorgehensmodelle Projektmanagement M2 Prozessmodelle und Projektorganisation 46

47 Das sequentielle Paradigma Das sequentielle Paradigma bezeichnet ein sequentielles Vorgehen mit klar definierten Phasen und Ergebnissen Bekannteste Vorgehensmodelle: Wasserfall-Modell V-Modell Projektmanagement M2 Prozessmodelle und Projektorganisation 47

48 Sequentiell: Wasserfallmodell (schematisch) Eingeführt von Walker Royce 1970, Weiterentwicklung der stufenweisen Entwicklung ( stagewise development ) von Benington Ansatz: Top-down Stufenmodell mit eingeschränkter Rückkopplung Phasensynchronisation durch (Zwischen-) Produkte Geringer Managementaufwand Fach. Konzeption Tech. Konzeption Realisierung Test & Integration 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. Projektstart Ziel Projektmanagement M2 Prozessmodelle und Projektorganisation 48

49 Sequentiell: V-Modell Entwicklungsstandard für IT-Systeme des Bundes Eingeführt 1991/1997, Bundesamt für Wehrtechnik und Beschaffung Einsatz Bei allen Beschaffungen für IT-Systeme des Bundes Referenzmodell in vielen Unternehmen der Privatwirtschaft (nominell) Module: Projektmanagement Systementwicklung Qualitätssicherung Konfigurationsmanagement Bernhard Bauer, all rights reserved

50 Das sequentielle Paradigma: Vor- und Nachteile Vorteile einfach durchzuführen schränkt Freiheitsgrade stark ein, daher auch für sehr große Projekte anwendbar Komplexitätsbeherrschung sehr effizient bei bekannten und konstanten Anforderungen ist gut zu vermessen (notwendig z.b. für Prozessverbesserung) Erhöhte Transparenz Nachteile Risiken 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 50

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 51

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 52

53 Rational Unified Process (RUP) RUP ist eine Weiterentwicklung von Jacobsons Objectory Geschäftsmodellierung RUP hat UML als Sprache voreingestellt Anforderungen RUP wird von Rational/IBM bezeichnet als inkrementell & iterativ, architektur-zentriert, und anwendungsfallgetrieben. Analyse & Entwurf Implementierung Test Auslieferung Konfigurations-Mgmt Propjektmanagement Infrastruktur Arbeitsschritte Konzeption Preliminary Iteration(s) Entwurf Iter. #1 Iter. #2 Projektmanagement M2 Prozessmodelle und Projektorganisation Zeitliche Phasen Konstruktion Iter. #n Iter. #n+ 1 Iterationen Iter. #n+ 2 Übergang Iter. #m 53 Iter. #m+ 1

54 Das iterative Paradigma: Vor- und Nachteile Vorteile Risiken können früher erkannt werden volatile Anforderungen können besser berücksichtigt werden inkrementelle Auslieferung wird erleichtert Nachteile Mehrarbeit komplexeres Projektmanagement schwerer messbar Projektmanagement M2 Prozessmodelle und Projektorganisation 54

55 Das adaptive Paradigma Unter einem adaptiven SW-Prozess versteht man eine Weiterentwicklung des iterativen Paradigmas, bei der die Planung der Iterationen dynamisch erfolgt und von Anfang an Prototypen erstellt werden Charakteristikum: kontinuierliche Anpassung an Änderungen Prinzipien: Individuum und Interaktion (geht) vor Prozess und Werkzeug ausführbare SW vor vollständiger Dokumentation Zusammenarbeit mit Kunden vor Vertragsverhandlung Berücksichtigung von Änderungen vor Beharren auf Plan Bekannte Vorgehensweisen: XP SCRUM,... Projektmanagement M2 Prozessmodelle und Projektorganisation 55

56 XP (Extreme Programming) Merkmale XP arbeitet mit kleinen Releases, unterteilt in Iterationen und Arbeitspakete. Anforderungsanalyse Aufgaben und Anforderungen in Form von Stories Beschränkung auf wenige Anforderungen pro Iteration Pair Programming Zwei 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 56

57 Das adaptive Paradigma: Vor- und Nachteile Vorteile Gut einsetzbar bei unklaren Zielen und sich ändernden Anforderungen/Umgebung Verspricht besseres Kosten/Nutzen-Verhältnis Vermutlich durchschnittliche Code-Qualität besser Nachteile Ergebnis ist nicht vorhersagbar Qualitätseigenschaften können nicht garantiert werden Oft 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 57

58 Wasserfallmodell versus Inkrementelle Software-Entwicklung Was ist besser? Projektmanagement M2 Prozessmodelle und Projektorganisation 58

59 Wasserfallmodell versus Inkrementelle Software-Entwicklung Wasserfall Hohe Sicherheit für Software- Anbieter Gesamtblick (aber: zu viele Details) Unüberschaubare Konzeptpapiere Geringere Flexibilität, aber Change- Request-Verfahren Nutzen erst bei Einführung Deckel drauf bekommen Einfache Struktur, Qualitätssicherung zwischen Phasen Entspricht Denkweise: Geld für definierte Leistung Iteratives Vorgehen Früher Nutzen für Kunden Besseres, qualifizierteres Feedback Kosten für Übergangslösungen Schwieriger zu managen Geringeres Einführungsrisiko Projektmanagement M2 Prozessmodelle und Projektorganisation 59

60 Verbesserung: Gestuftes Vorgehen Wasserfall als Vorgehen stößt an Grenzen Große Projekte werden handhabbar Verringern des Risikos Fachliches Risiko Technisches 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 Projektmanagement M2 Prozessmodelle und Projektorganisation 60

61 Gestuftes Vorgehen Bei Aufsetzen des Projekts Immer den Umfang des Projekts im Auge behalten Bei größerem Umfang Stufung versuchen Umfang niemals unterschätzen! Nach Fachkonzeption oder Studie Zusätzlicher Schnittpunkt für Stufenbildung (fachlich) Indizien für zu großen Projektumfang Umfang 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 61

62 Beispiele für gestuftes Vorgehen im Projekt Projektmanagement M2 Prozessmodelle und Projektorganisation 62

63 Projektorganisation Projektorganisation: Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projektes [nach DIN ] Einrichten einer projektspezifischen Organisation: Aufbauorganisation: Einbinden des Projekts in die Unternehmensorganisation Einrichten von Rollen und Verantwortlichkeiten Ablauforganisation: Abwickeln des Projekts entsprechend des Entwicklungsprozess Festlegen von Aktivitäten und Abläufen In der Projektorganisation wird folgendes festgelegt: Arbeitsteilung zwischen Personen und Teams AKV: Aufgaben, Kompetenzen, Verantwortlichkeiten Weisungsbefugnisse, Kontrollrechte und Aufsichtspflichten Koordinationsinstrumente (z. B. Abstimmungszirkel) Projektmanagement M2 Prozessmodelle und Projektorganisation 63

64 Unternehmensstrukturen Grundstruktur: Organisationsleitung: Funktion: Strategische Führung Beispiel: Geschäftsführung Mittellinie: Funktion: Operative Führung Beispiel: Mittleres Management, Gruppenleiter Betrieblicher Kern: Funktion: Operative Ausführung Beispiel: Entwickler Stab: Funktion: Unterstützende Ausführung Beispiel: Rechtsabteilung, Telefonzentrale, Methodenberatung Projektmanagement M2 Prozessmodelle und Projektorganisation 64

65 Varianten von Organisationsformen Formen der Unternehmensorganisation: Bereichsstruktur: Untergliederung nach Geschäftsfunktion Bereiche: z.b. Marketing, Entwicklung, Vertrieb, Buchhaltung, Forschung Beispiel: BMW, Microsoft Marktstruktur: Untergliederung nach Produktgemeinsamkeiten Märkte: z.b. BIS (ERP, CRM, etc.), Medizintechnik, Telekom Beispiel: Siemens Spezielle Varianten: Nach Niederlassungen Nach Kunden Projektmanagement M2 Prozessmodelle und Projektorganisation 65

66 Bereichsstruktur Schwerpunkte: Know-How-Transfer, Ressourcenflexibilität Projektmanagement M2 Prozessmodelle und Projektorganisation 66

67 Marktstruktur Schwerpunkte: Effizienz, Produktidentifikation, minimierte Kommunikation Projektmanagement M2 Prozessmodelle und Projektorganisation 67

68 Vor- und Nachteile der Organisationsformen Bereichsstrukturierte Organisation: Vorteile: Standardisierung der Abläufe, erhöhte Wirtschaftlichkeit Spezialisierung, Fachhierarchien, Wissenstransfer Nachteile: Aufwändige Koordination funktionsübergreifender Tätigkeiten Mangelnde Flexibilität Ausrichtung: Fertigung von Standardprodukten Marktorientierte Gruppierung: Vorteile: Flexibilität (neue Marktsegmente) I.A. geringerer bürokratischer Aufwand Nachteile: Schwacher Wissenstransfer durch fehlende Spezialisierung Mangelnde Effizienz durch mangelnde Standardisierung Ausrichtung: Fertigung von Individualprodukten Projektmanagement M2 Prozessmodelle und Projektorganisation 68

69 Projektformen Wesentliches Element: Verantwortung Fachliche Verantwortung ( Was wird wann gemacht ) Führungsverantwortung (Personalverantwortung) ( Wer macht es wann mit welchem Aufwand ) Problem: Mitarbeiter sind in langfristige Organisationshierarchien eingebunden Projekte konkurrieren kurzfristig mit diesen Hierarchien Resultat: Konflikt zwischen Interessen der Linienhierarchie und der Projekthierarchie (i.e. Linienverantwortung vs Projektverantwortung) Projektstrukturen: Projektorganisation als Linien- Organisation Stab-Linien-Organisation Matrixorganisation Projektmanagement M2 Prozessmodelle und Projektorganisation 69

70 Projektorganisation als Linienorganisation Eignung: Kritische Projekte mit hoher Priorität Projektmanagement M2 Prozessmodelle und Projektorganisation 70

71 Projektorganisation als Linienorganisation Prinzip: Eigenständige Organisationseinheit für Projekt Projektmitarbeiter werden aus Bereichen freigestellt Verantwortung Projektleiter: Fachliche Verantwortung UND Führungsverantwortung Vorteile: Klare Kompetenzen und Verantwortlichkeiten Hohe Projektidentifikation Kurze Kommunikationswege Nachteile: Umstellungsaufwände durch Aus- und Wiedereingliederung Schwächung der Bereiche, ev. Konkurrenzsituation mit Bereichen Problem der ungleichmäßigen Projektbelastung Projektmanagement M2 Prozessmodelle und Projektorganisation 71

72 Projektorganisation als Linienorganisation Extremfall: Projektstruktur als Unternehmensform Projektmanagement M2 Prozessmodelle und Projektorganisation 72

73 Beispiel: sd&m Sonderfall: IT-Projekthäuser Fü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

74 Stab-Linien-Organisation Eignung: Niedrigpriore Projekte oder Konsensprojekte Projektmanagement M2 Prozessmodelle und Projektorganisation 74

75 Stab-Linien-Organisation Prinzip: Keine Leitungsinstanz/Organisationseinheit für Projekt Projektmitarbeiter verbleiben vollständig in Bereichen Verantwortung Projektleiter (hier typischerweise Koordinator ): Keine fachliche Verantwortung Keine Führungsverantwortung Stabsfunktion (berichtend, koordinierend) Vorteile: Schneller Know-How-Transfer Flexible Kapazitätsauslastung Keine Umstellungsaufwände Nachteile: Aufwändige Koordinations- und Abstimmungsprozesse Keine Projektidentifikation Keine Instanz mit Weisungsbefugnis Projektmanagement M2 Prozessmodelle und Projektorganisation 75

76 Matrixorganisation Prinzip: Zeitlich befristetes Mehrliniensystem Projektmitarbeiter verbleiben vollständig in Bereichen Verantwortung Projektleiter: Fachliche Verantwortung Keine Führungsverantwortung Vorteile: Schneller Know-How-Transfer Optimale Kapazitätsauslastung Geringe Umstellungsaufwände Nachteile: Konfliktpotential durch Doppelunterstellung Hohe Anforderungen an Selbstdisziplin und Eigenständigkeit Hohe Anforderung an Teamfähigkeit und Sozialkompetenz von Mitarbeitern und Leitungskräften Projektmanagement M2 Prozessmodelle und Projektorganisation 76

77 Matrixorganisation Eignung: Flexible Projektabwicklung in dynamischem Umfeld (Markt und Technologiedynamik) Projektmanagement M2 Prozessmodelle und Projektorganisation 77

78 Interne Projektstruktur Festlegung der Projektstruktur: Bereitstellung von Mitarbeitern: Einbettung in die Unternehmensorganisation Einrichten einer internen Projektstruktur: Definition von Rollen und Verantwortlichkeiten Projektstruktur: ähnlich Unternehmensstruktur: Leitung: Projektleiter Kern: Projektmitarbeiter Stab: Übergreifende Tätigkeiten (z.b. QM, KM) Projektmanagement M2 Prozessmodelle und Projektorganisation 78

79 Ablauf- vs. Produktorganisation von Projekten Projektorganisation ähnlich Produktstruktur Mehrere 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 Entwicklungsprozess Teams für die Phasen des Entwicklungsprozesses: Fachteam für fachliche Spezifikation Technisches Team für technische Konstruktion, Implementierung Test-Team tech./fach. Architekten arbeiten in den Teams mit. Projektmanagement M2 Prozessmodelle und Projektorganisation 79

80 Produkt- vs. Ablauforganisation Produkt- Organisation: Ablauf- Organisation: Projektmanagement M2 Prozessmodelle und Projektorganisation 80

81 Vergleich der Organisationsformen 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. Ablauforganisation Spezialisten 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. Projektmanagement M2 Prozessmodelle und Projektorganisation 81

82 Rollen Rollenstruktur: Beeinflusst von: Prozessstruktur (z.b. Analyse, Design, Implementierung, Integration) Produktstruktur (z.b. Präsentation, Logik, Datenhaltung) Projektrollen: Projektausschuss Auftraggeber Anwender Projektleiter Projektmitarbeiter Projektmanagement M2 Prozessmodelle und Projektorganisation 82

83 Rolle: Projektleiter Aufgaben: Erstellung Projekt-, Termin- und Kostenplan Organisation und Koordination Projektteam Durchführung Fortschrittskontrolle Steuerung und Festlegung von Entscheidungen (fachlich) Evtl.: Personelle Betreuung Projektmitarbeiter Kompetenzen: Mitwirkung bei der Projektzieldefinition Mitspracherecht bei der Bestimmung der Fachverantwortlichen projektbezogenes Informations-, Weisungs- und Entscheidungsrecht Projektmanagement M2 Prozessmodelle und Projektorganisation 83

84 Rolle: Mitarbeiter Aufgaben: Mitwirkung an Projektplanung Durchführung der zugewiesenen Arbeitspakete Dokumentation der zugewiesenen Arbeitsergebnisse Kompetenzen: Vorbereitung/Herbeiführung von Entscheidungen Umsetzung von Vorgaben Einsatz von Ressourcen Projektmanagement M2 Prozessmodelle und Projektorganisation 84

85 Weitere Mitarbeiter-Rollen Software Engineering-spezifische Team-Rollen: Systemanalytiker Systementwickler Tester Software Engineering-spezifische Stabs-Rollen: Qualitätsmanager, Qualitätsbeauftragter Konfigurationsmanager IT-Sicherheitsbeauftragter Projekt-Controller Generelle Prinzipien: Personifizierte Verantwortung Klare Aufgaben und Kompetenzen Projektmanagement M2 Prozessmodelle und Projektorganisation 85

86 Zusammenfassung (1) Das sequentielle Prozessparadigma (Wasserfall, klassisches V-Modell) ist einfach durchzuführen auch für sehr große Projekte anwendbar sehr effizient bei bekannten und konstanten Anforderungen ABER Risiken gesammelt am Schluss ( Big Bang ) und starr während des Ablaufs Das iterative Paradigma (RUP, Spiralmodell) erleichtert frühe Erkennung von Risiken Berücksichtigung sich ändernder Anforderungen inkrementelle Auslieferung ABER es erfordert Mehrarbeit, komplexeres Projektmanagement und ist schwerer messbar Projektmanagement M2 Prozessmodelle und Projektorganisation 86

87 Zusammenfassung (2) Das agile Prozessparadigma (XP) ist Gut einsetzbar bei unklaren Zielen und sich ändernden Anforderungen/Umgebung Verspricht besseres Kosten/Nutzen-Verhältnis Vermutlich durchschnittliche Code-Qualität besser ABER das Ergebnis ist nicht vorhersagbar Qualitä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 87

88 Zusammenfassung (3) Als Projektorganisation bezeichnet man die Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projektes Die Grundstruktur eines Unternehmens besteht aus : Organisationsleitung, Mittellinie, Betrieblichem Kern und Stab Man unterscheidet Markt- und Bereichsstruktur Mögliche Projektstrukturen sind Stab-Linien-Organisation Projektorganisation als Linien-Organisation Matrixorganisation Typische Projektrollen sind Projektausschuss Auftraggeber Anwender Projektleiter Projektmitarbeiter Projektmanagement M2 Prozessmodelle und Projektorganisation 88

89 Projektmanagement: Projektvorbereitung und -abschluss

90 Ziele Tätigkeiten der Projektvorbereitung kennen lernen: Projekt-Idee und Studie Beauftragung mit Ausschreibung, Angebot und Auftrag Projektinitialisierung und Kick-Off-Meeting Tätigkeiten am Projektende kennen lernen: Projektabschluss Touch Down Meeting Projektmanagement M3 - Projektvorbereitung 90

91 Grundparameter Projektmanagement verdeutlicht Abfolge in Projektgeschehen Einsatz von Aufwänden (Geld, Personal, Maschinen,...) und Verbrauch an Zeit soll bestimmtes Ergebnis erzielt werden PM hat zentrale Aufgabe Erbringung geforderte Leistung im optimalen Verhältnis zu Zeit und Einsatzmitteln Parameterausrichtung kostenfixierte Parameterausrichtung terminfixierte Parameterausrichtung leistungsfixierte Parameterausrichtung 91

92 Projektverlauf Projektmanagement M3 - Projektvorbereitung 92

93 Auslöser von Projekten Beispiele für Auslöser von Projekten In 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 Forschung Auslö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 93

94 Studie Eine Studie dient dem Nachweis von Machbarkeit und Nutzen eines Software-Projekts. Sie enthält i.a. Grobdefinition der Ziele des Projekts Grobabschätzung des Nutzens Grobabschätzung der Kosten und benötigten Einsatzmittel Erstvorschlag zur Projektorganisation Eine Studie im Vorfeld gibt es z. B. in folgenden Fällen bei größeren Vorhaben wenn die Aufgabenstellung noch nicht ganz klar ist wenn genauer nachvollzogen werden soll, ob sich die Investition lohnt. Unterschiedliche Arten von Studien Auftragsprojekt: Anforderungskatalog Innovationsprojekt: Marktstudie/Technologiestudie Pflege/Änderungsprojekt: Verbesserungsvorgaben Wichtig: Festlegung Projekterfolgskriterien Messbare Kriterien Projektmanagement M3 - Projektvorbereitung 94

95 Durchführungsentscheidung Ziel: Annahme/Ablehnung Projekt Verfahren: Ermittlung Kosten: Auf Basis Studie/Grobplan Personalkosten (inkl. Personalvorbereitung) Betriebsmittelkosten Organisationskosten Ermittlung Nutzen: Monetärer Gewinn: Marktanalyse, Effizienzanalyse Investitionsgewinn Risikoanalyse: Wirtschaftliche Risiken Fachliche Risiken Evtl: Alternativen erstellen und beurteilen Ergebnis: Annahme oder Ablehnung des Projekts Projektmanagement M3 - Projektvorbereitung 95

96 Beauftragung Projektmanagement M3 - Projektvorbereitung 96

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ündlich Zusätzliche Absprachen Unvollständig Im Projekt wird der Projektauftrag vervollständigt bzw. geschrieben. Zweck: Ziele und Aufgabenstellung für das Projekt glasklar festlegen Ein Auftrag muss schriftlich fixiert sein Bei 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 97

98 Inhalte eines Projektauftrags Projektleiter: Verantwortlicher für das Projekt Auftraggeber: Wer will das Projekt eigentlich? Derjenige, der bezahlt, bestimmt auch bzw. wer bestimmen will, muss auch zahlen. Kurzbeschreibung des Projekts Ziele, ggf. hierarchisch verfeinert Zu 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ände Projekthandbuch: Entwicklungsprozess Rahmenbedingungen Abhängigkeiten von anderen Projekten und Personen, Zulieferungen Start, Ende, Meilensteine Projektmanagement M3 - Projektvorbereitung 98

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 sonst Projektmitarbeiter sind schon freigestellt, müssen beschäftigt werden Formulierung scheitert an vermeintlich unwichtigen Details Das 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 99

100 Projektinitialisierung Projektmanagement M3 - Projektvorbereitung 100

101 Projektinitialisierung Ziel: Die Arbeit kann beginnen, das Team kann loslegen, alle Rahmenbedingungen sind geschaffen. Wichtig: Kernteam muss in der Projektinitialisierung besetzt sein Projektleiter Qualitätssicherer Mitarbeiter, 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 101

102 Besetzung des Projektleiters Häufiges Problem: Projektleiter kommt erst spät in das Projekt Gute 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: Zeitverlust Der Projektleiter kann ein Projekt erst nach einer Einarbeitung sinnvoll leiten: Das Projekt ist zunächst führungslos Die 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 102

103 Tätigkeiten während der Projektinitialisierung Ziele klären Qualitätskriterien klären Organisation des Projekts festlegen, einschließlich Ansprechpartner des Auftraggebers Projektstruktur im Projektstrukturplan festlegen (falls nicht schon im Auftrag fixiert) Schätzung validieren Planung: Grob- und Feinplanung für die ersten Schritte Infrastruktur etablieren Struktur für das Controlling aufsetzen Im Projekthandbuch festhalten Projektmanagement M3 - Projektvorbereitung 103

104 Initialisierung: Warum braucht ein Projekt Ziele? Quelle: G. Pews sd&m Projektmanagement M3 - Projektvorbereitung 104

105 Ziele Ziele sind elementar wichtig in einem Projekt Erzeugen ein gemeinsames Bild, eine gemeinsame Ausrichtung Sind einfach kommunizierbar Ziele sollte man für alle wichtigen Tätigkeiten definieren z. 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 105

106 Ziele formulieren Ausgangsbasis Auftrag, 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 Arbeitshypothesen Arbeitshypothesen dem Auftraggeber mitteilen Diese Technik funktioniert generell an vielen Stellen des Projekts. Ziele SMART festhalten Projektmanagement M3 - Projektvorbereitung 106

107 SMARTe Ziele S pezifisch M easurable A chievable R elevant T ime-based Knackig, verständlich, eindeutig, stimmig mit anderen Zielen. Messbar. Es muss klar sein, wann das Ziel erreicht ist. Erreichbar. Unerreichbare Ziele führen zu Demotivation. Die wichtigen Dinge als Ziel formulieren, nicht jeden Kleinkram. 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 107

108 Antoine de Saint Exupéry: Wenn du mit anderen ein Schiff bauen willst, so beginne nicht, mit ihnen Holz zu sammeln, sondern wecke in ihnen die Sehnsucht nach dem großen, weiten Meer. Projektmanagement M3 - Projektvorbereitung 108

109 Ziele formulieren Ein Ziel aktiv formulieren: Nicht: Man wird mir das Rauchen abgewöhnen Sondern: Ich werde nicht mehr rauchen. Ein Ziel so formulieren, als ob es schon erreicht ist (Gegenwart statt Zukunft): Nicht: Ich werde nicht mehr rauchen Sondern: 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 109

110 Qualitätskriterien festlegen Vom Auftraggeber die Qualitätskriterien erfragen, nach denen er seine Zufriedenheit misst. Beispiele Know-how beim Auftraggeber aufbauen Sich pro-aktiv um alles kümmern (Auftraggeber-Sorglos-Paket) Qualifizierte Mitarbeiter ins Projekt stecken Schnelle Resultate, schnell ein vorzeigbares Ergebnis allg.: 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 110

111 Projektstrukturplan Ziel Zerteilung 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 Software Orientierung am Projektablablauf Orientierung an den Funktionen im Projekt Mischformen sind üblich Muss (wie jeder Plan) bei Bedarf angepasst werden. Projektmanagement M3 - Projektvorbereitung 111

112 Projektinfrastruktur (1/2) Die Projektinfrastruktur umfasst alle Hilfsmittel, die das Team zum Arbeiten benötigt Infrastruktur 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 Projektstrukturplan z. B. gemeinsames Wiki (mit Sicherung!) für verteilte Teams und Teams unterschiedlicher Firmen Projektmanagement M3 - Projektvorbereitung 112

113 Projektinfrastruktur Werkzeuge bereitstellen Office-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. Verteiler, etc. Nutzungskonzepte: Ein Werkzeug allein reicht oft nicht, es muss auch festgelegt sein, wie es im Projekt eingesetzt werden soll. Projektmanagement M3 - Projektvorbereitung 113

114 Infrastruktur etablieren Etablieren der Infrastruktur hört sich trivial an, aber ist zeitaufwändig und daher nicht zu unterschätzen nicht vorhandene Infrastruktur behindert das Team massiv. Tipp: Aufbau der Infrastruktur früh planen und initiieren, Anschaffungen haben oft langen Vorlauf. Projektmanagement M3 - Projektvorbereitung 114

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 115

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 116

117 Kick-Off Meeting Ziele des Kick-Offs Das 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 verstehen Team über die wichtigsten Inhalte der Projektinitialisierung informieren, auf Stand zum Arbeiten bringen. Inhalte des Kick-Offs Projektziele, Inhalt des Projektauftrags Projektstruktur Projektvorgehen und Planung kommunizieren: wichtige Meilensteine Wichtige Standards festlegen Verantwortlichkeiten, Rollen kommunizieren, Organigramm Verhaltens- und Kommunikationsregeln des Teams, ggf. erarbeiten. Projektmanagement M3 - Projektvorbereitung 117

118 Durchführung des Kick-Offs Dauer des Kick-Offs: ca. ½ - 1 Tag Moderation durch Projektleiter Tipps: Früh genug darum kümmern, dass alle am Kick-Off teilnehmen können Gut vorbereitet sein: Präsentation vorbereiten, nicht darauf verlassen, dass man die Inhalte aus der Initialisierung immer noch präsent hat Bei 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 Essen Beieinandersein an Stehtischen im Foyer Gute 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 118

119 Nachbereitung des Kick-Offs Zumindest ein Protokoll machen und Ergebnisse des Kick-Offs konservieren Ein 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 an die Teilnehmer verschicken oder gleich die vorhergesehene Stelle auf der Teamablage nutzen Projektmanagement M3 - Projektvorbereitung 119

120 Projektablauf Projektmanagement M3 - Projektvorbereitung 120

121 Projektabschluss und Touch Down Formaler Projektabschluss: Definierte Beendigung eines Projekts Erreichen des Projektziels Abbruch eines Projekts Prozessabschluss hat unterschiedliche Dimensionen: Produktdimension: Sicherung der Produkte und Ergebnisse Vorbereitung Softwarepflege und Änderung Vorbereitung der Wiederverwendung/Verbreitung der Ergebnisse Projektdimension: Freigeben von Ressourcen und Personal Rechenschaftsberichte erstellen Projekt auflösen Projektabschluss umfasst Abnahme durch Auftraggeber und (internen) Touch Down Projektmanagement M3 - Projektvorbereitung 121

122 Projektabschluss: Abnahme Formale Abnahme durch Auftraggeber Abnahme ist Hauptpflicht des Auftraggebers Abnahmekriterien 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/Abteilung Hat 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 122

123 Projektabschluss: Abnahme Zweigliedriger Abnahmebegriff körperliche Entgegennahme und Billigung der Leistung 2 mögliche Vorgehensweisen Projektbegleitende Abnahme (dringend empfohlen) Big bang (manchmal nicht anders machbar) Verfahren und Detailvorgehensweise muss vor der Abnahme bekannt sein (auch Testdaten etc.) Projektmanagement M3 - Projektvorbereitung 123

124 Projektabschluss: Abnahmekriterien Abnahmekriterien Für die Abnahme wird die Übereinstimmung mit den sog. Annahmekriterien geprüft Einhaltung von Planungs- und Managementprozessen Definition der Verifikationsmethoden Definition der Zeitdauer der Abnahme Vereinbarung von Fehlerklassen Zeitdauer für die Behebung von Problemen Wichtig: Allen Beteiligten muss klar sein, was Abnahme heißt und was die Regeln sind! Projektmanagement M3 - Projektvorbereitung 124

125 Projektabschluss: Abnahmephasen Abnahmephasen: Überprüfung und Vollständigkeitskontrolle des vom Auftragnehmer gelieferten Programms einschl. Dokumentation Installation und anschl. Test in Testumgebung Performancetests auf Basis vereinbarter Mengenprofile Test des störungsfreien Wiederanlaufs nach Abbruch oder Stromausfall Auftraggeber trägt: Verantwortung für Aufbau und Betrieb Testumgebung Verantwortung für Testfälle und -daten Projektmanagement M3 - Projektvorbereitung 125

126 Projektabschluss: Rechtliche Auswirkungen Rechtliche Auswirkungen Vermutung der vollständigen Lieferung Mangelausschluss ( 640 II BGB) Untersuchungs- und Rügepflichten ( 377, 381 II HGB) Mängelbeseitigungs- statt Erfüllungsanspruch Beweislastumkehr Gefahrenübergang Nutzungsrechtseinräumung Verschuldensunabhängiger Zinsanspruch ( 641 II BGB) Fälligkeit des Vergütungsanspruchs ( 641 BGB) Verjährungsbeginn ( 638 BGB) Projektmanagement M3 - Projektvorbereitung 126

127 Projektabschluss: Bemerkungen Somit Hauptproblem bei der Abnahme ist i.d.r. kein rechtliches sondern ein psychologisches beim Auftraggeber Formaler Teil muss sein, aber dabei partnerschaftliches Verhältnis zwischen Projekt und Auftraggeber beachten Gutes Änderungsmanagement zahlt sich (spätestens) hier aus Kriterien und Verfahren möglichst früh klären und festlegen (Abnahmephase ist Stress...) Bestmögliche Betreuung der zur Abnahme berechtigten Mitarbeiter des Auftraggebers sicherstellen Schnelle Reaktion auf auftretende Probleme Projektmanagement M3 - Projektvorbereitung 127

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 verglichen Archivierung der Projektergebnisse: nicht einfach auf einem Laufwerk liegen lassen, irgendwann sind sie weg. Projektmanagement M3 - Projektvorbereitung 128

129 Touch-Down Meeting Gegenstück zum Kick-Off: Das offizielle Ende der Projektdurchführung Teilnehmer: alle Projektbeteiligten Bei 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 129

130 Exkurs: Werkleistungen und Dienstleistungen Werkvertrag für Gewerke geschuldet ist ein Werk, der Projekterfolg Geld gibt s für den Erfolg Das Risiko liegt beim Auftragnehmer Aber: der Auftragnehmer hat die Freiheit zu entscheiden, wie er den Erfolg erzielt. Dienstvertrag für Dienstleistungen Geschuldet ist die Tätigkeit Geld gibt es, wenn man arbeitet, auch wenn der Projekterfolg nicht eintritt. Das Risiko liegt beim Auftraggeber Auftraggeber kann Vorgehensweise, Arbeitsort und - zeiten bestimmen. Abwertende Bezeichnung: BodyLeasing Projektmanagement M3 - Projektvorbereitung 130

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 die Gesamtvergütung) Oft: Werkvertrag zum Festpreis, Dienstvertrag nach Aufwand muss aber nicht zwingend so sein. Projektmanagement M3 - Projektvorbereitung 131

132 Zusammenfassung (1) Die Projektvorbereitung umfasst Projekt-Idee und Studie Beauftragung mit Ausschreibung, Angebot und Auftrag Projektinitialisierung und Kick-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 Rahmenbedingungen Abhängigkeiten von anderen Projekten und Personen, Zulieferungen Start, Ende, Meilensteine Projektmanagement M3 - Projektvorbereitung 132

133 Zusammenfassung (2) Tätigkeiten während der Projektinitialisierung umfassen Klärung der Ziele und Qualitätskriterien Festlegung der Organisation des Projekts und der Projektstruktur (im Projektstrukturplan) Validierung der Schätzung Grob- und Feinplanung für die ersten Schritte Etablierung der Infrastruktur und der Struktur für das Controlling Ein Kick-Off-Meeting ist wichtig um das Team auf ein gemeinsames Ziel einschwören und wichtige Ziele, Verantwortlichkeiten, Standards etc zu kommunizieren Das Projektende tritt ein bei Erreichen des Projektziels Abbruch 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 133

134 Projektmanagement: Schätzverfahren

135 Ziele Generelles Vorgehen bei Schätzungen kennen lernen Grundlegende Schätzmuster und Maße zur Systemkomplexität kennen lernen Schätzverfahren für den Aufwand eines Software-Projekts kennen lernen und beurteilen Delphi-Methode Function Points CoCoMo Projektmanagement M4 - Schätzung 135

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 Realisierungsaufwand Realisierungszeit Abhängig von Systemkomplexität und Produktivität Möglichst vor Systemrealisierung Prinzipielle Strategie beim Schätzen: per Analogie Schätzungen sind unfair : Passieren zu einem sehr frühen Zeitpunkt Man weiß wenig über die Aufgabe Auf die Zahlen wird man später festgenagelt Projektmanagement M4 - Schätzung 136

137 Herangehensweisen Von den Arbeitspaketen zur Aufwandszahl Schätzung der einzelnen Arbeitspakete Summe ergibt Gesamtaufwand Schätzung als Grundlage für Aufwand Vom fixierten Aufwand zu den Arbeitspaketen Frage: Was darf es denn insgesamt kosten? Projekt so aussteuern, dass es im Kostenrahmen bleibt Aufgaben werden nur so gut erledigt, wie Geld da ist Schätzung zur Prüfung der Machbarkeit Faustregeln: Hochinnovative Projekte kann man nicht schätzen Nur normales Vorgehen lässt sich schätzen, radikales nicht Projekte mit fließenden Anforderungen kann man nicht verlässlich schätzen Projektmanagement M4 - Schätzung 137

138 Auswirkungen einer falschen Schätzung Zu hohe Schätzung Ist 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ätzung Geld 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 138

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 Blindflug Auch Schätzen ist ein Prozess: sobald erste Erfahrungen und ermittelte Aufwände im Projekt vorliegen, wird nachgeschätzt und die Schätzung korrigiert Die Schätzung wird im Laufe des Projekts immer genauer. Projektmanagement M4 - Schätzung 139

140 Einflussfaktoren auf den Aufwand (wichtigste Faktoren) Umzusetzende Fachlichkeit (funktional) Masken Druckstücke Berechnungen zu berücksichtigende Fehlersituationen Migrationen aus Altsystemen Abhängigkeit von anderen Systemen Technologische Umsetzung, nicht-funktionale Anforderungen Performance, Antwortzeitverhalten Architektur Systemplattform, Basis- Technologien Projektmanagement-Faktoren Team Mitarbeiterqualifikation Erfahrung Eingespieltes Team Projektorganisation Projektvorgehen, Methodik Unterstützung durch Tools Sonstige Faktoren Auftraggeber Aufwände steigen mit Größe der Aufgabe Projektmanagement M4 - Schätzung 140

141 Generelles Vorgehen bei der Schätzung Eine gute Vorbereitung ist elementar für die Schätzung Komplettieren 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 141

142 Schätzmuster Schätzungen werden fast immer aus einer Kombinationen der folgenden grundlegenden Schätzmuster hergeleitet Insbesondere 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 Vergleich Schätzen durch Zerlegung Anforderungen des Entwurfs Schätzen durch Experten Schätzen mit Korrekturfaktoren Schätzen mit Stellvertretergröße Schema für Schätzmuster: Problem/Kontext Vorgehensidee Vorteile, Nachteile evtl. Varianten, Anmerkungen Projektmanagement M4 - Schätzung 142

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: Vorteile Nachteile Variante: Wähle aus dem Erfahrungsschatz das ähnlichste Ding aus und benutze dessen Aufwand als Schätzung Einfach, schnell Evtl. zu wenig Erfahrung; Ähnlichkeitsmaß unklar 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 143

144 Schätzen durch Zerlegung (Anforderungen) Problem/Kontext: Wenn Anforderungen wenig voneinander abhängen, d.h. das System nur einen kleinen Kern aufweist Vorgehensidee: Vorteile: Nachteile: Schätze Aufwand pro Anforderung einzeln; summiere Starke Reduktion der Komplexität 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 144

145 Schätzen durch Zerlegung (Entwurf) Problem/Kontext: Wenn die Architektur des Systems bereits erkennbar ist Vorgehensidee: Vorteile: Nachteile: Schätze den Aufwand für die Subsysteme und addiere Im Prinzip ist eine sehr genaue Zerlegung und Schätzung möglich 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 145

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ätzung Lasse die Experten Ihre Schätzungen und Begründungen diskutieren und modifizieren Resultat: Konsens über einen geschätzten Aufwandsbereich Vorteile: Sehr breitbandig, bezieht enorm viele Faktoren ein Unsicherheit 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 146

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 147

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 148

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 149

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 anonym Breitband Delphi-Verfahren: Schätzergebnisse werden gegenseitig bekanntgegeben, damit Resultate diskutiert und ggf. korrigiert werden können Häufig Schätzung im Rahmen einer Schätzklausur Projektmanagement M4 - Schätzung 150

151 Schätzklausur Phase 1: Auftragsdefinition Auftraggeber, Kunde, Verantwortliche und Durchführende festlegen Ziel definieren Aufgaben analysieren (Prozesszerlegung) Phase 2: Schätzungsvorbereitung Geeignete Leute einladen Fachleute, Verantwortliche, Durchführende 2 Stunden ansetzen Excel-Sheet vorbereiten Phase 3: Schätzung Projekt und Projektplan vorstellen, Aufwands- und Zeitplan austeilen, ggf. korrigieren (lassen) Jeder schreibt seine Schätzungen auf Ansage auf Jeder sagt seine Schätzungen auf Ansage an Extrema diskutieren, ggf. entfernen Mittelwerte bilden Summe bilden Projektmanagement M4 - Schätzung 151

152 Schätzklausur Meistens gibt es anschließend noch eine Phase 4, in der die Schätzung interessengeleitet verändert wird. Projektmanagement M4 - Schätzung 152

153 Zwischenfazit 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. Projektmanagement M4 - Schätzung 153

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 und :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 Stellvertreterverfahren Anschließend kann man noch Projektumstände berücksichtigen, um die Schätzung anzupassen (angepasste FP) Hinzu kommt also ein Korrekturfaktorverfahren Projektmanagement M4 - Schätzung 154

155 Unangepasste FP (UFP) Messverfahren: Klassifiziere Anforderungen in Eingaben Eingabemasken, für die Datensätze eingegeben werden können Ausgaben Datenpräsentationsdarstellung ("Report") Abfragen Eingabe eines Suchkriteriums plus Anzeige des Gefundenen Datenbestä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 komplex Eingaben Ausgaben Interaktionen Datenbestände Referenzdaten Projektmanagement M4 - Schätzung 155

156 Angepasste FP FP = UFP * TK wobei der Korrekturfaktor Technische Komplexität (TK) gebildet wird durch 1.35) TK = ,01 Σ i=1..14 F i (d.h <= TK <= und F i Korrekturwerte gemäß dem Schwierigkeitsgrad gewisser nichtfunktionaler Anforderungen darstellen: F 1 Reliable back-up and recovery F 2 Data communications F 3 Distributed functions F 4 Performance F 5 Heavily used configuration F 6 Online data entry F 7 Operational ease F 8 Online update F 9 Complex interface F 10 Complex processing F 11 Reusability F 12 Installation ease F 13 Multiple sites F 14 Facilitate change haben je einen Wert zwischen 0 und 5 (für nicht bzw. sehr stark vorhanden). Projektmanagement M4 - Schätzung 156

157 Technische Korrekturfaktoren Übersetzung und Erläuterung Faktor Originalname Erläuterung F1 Reliable back-up & recov. Anforderungen an die Datenintegrität F2 Data communications Datenaustausch mit Umsystemen F3 Distributed functions Applikationen auf mehr als einem Rechner F4 Performance Leistungsanforderungen F5 Heavily used config. Starke Konfigurationsabhängigkeiten F6 Online data entry Interaktive Benutzung F7 Operational ease Interaktionsqualität F8 Online update unmittelbare Aktualisierung (WYSIWYG) F9 Complex interface komplexe Benutzerschnittstelle F10 Complex processing algorithmisch komplexe Verarbeitung F11 Reusability geplante Wiederverwendung/Wartung F12 Installation ease Installationskomfort F13 Multiple sites mehrere (unterschiedliche) Installationen F14 Facilitate change Unterstützung der Anpassung in der Wartung Projektmanagement M4 - Schätzung 157

158 Berechnung am Beispiel Ausleihmaske Ausleihsystem Stammdaten Lesernummer Name Vorname Kontodaten Titel Signatur Frist Mögliche Interaktionen: 1) Ausweis scannen 2) Konto- und Stammdaten abfragen durch Eingabe der Lesernummer 3) Stammdaten eingeben Geburtsdatum OK Neu Stammdaten Kontodaten Bestand Projektmanagement M4 - Schätzung 158

159 Berechnung am Beispiel Ausleihmaske 1.) Elemente zählen (1) (2) (3) Eingaben 1x einfach - 1x mittel Ausgaben - 1x mittel - Abfragen Referenzdaten Datenbestände 1x einfach 3x einfach Projektmanagement M4 - Schätzung 159

160 Berechnung am Beispiel Ausleihmaske 2.) UFP berechnen (1) (2) (3) Eingaben 1x 3-1x 4 Ausgaben - 1x 5 - Abfragen Referenzdaten 1x 5 Datenbestände 3x 7 UFP = = 38 Projektmanagement M4 - Schätzung 160

161 Berechnung am Beispiel Ausleihmaske 3.) Technische Faktoren schätzen 2 F 1 Reliable back-up & recovery 1 F 2 Data communications 2 F 3 Distributed functions 1 F 4 Performance 0 F 5 Heavily used configuration 3 F 6 Online data entry 5 F 7 Operational ease 3 F 8 Online update 2 F 9 Complex interface 0 F 10 Complex processing 1 F 11 Reusability 1 F 12 Installation ease 4 F 13 Multiple sites 1 F 14 Facilitate change Technische Komplexität TK = 0,65+0,01 Σ i=1..14 F i hier also TK = 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 Projektmanagement M4 - Schätzung 161

162 Ist das Produktivitätsparadoxon behoben? Sprache LoC / FP LoC / Mannmonat relativ konstant. Komplexität niedrig mittel hoch Assembler C Fortran Cobol C Smalltalk => In einer höheren Programmiersprache schafft ein Programmierer mehr Funktionalität pro Zeiteinheit. => Es gibt Produktivitätsunterschiede 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 Systemkomplexität insgesamt ab. Aber FPs sind schon deutlich besser als LoC. Erfahrungswert: Die Erstellung eines Function Points kostet etwa Projektmanagement M4 - Schätzung 162

163 Schätzverfahren: CoCoMo (Constructive Cost Modeling) Entwickler: Barry Boehm 1981 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: PM DEV = a * Size b * m Laufzeit: T DEV = 2,5 * PM d DEV PM DEV Entwicklungsaufwand in PM und T DEV Projektlaufzeit a, b, d, m unternehmensspezifisch zu kalibrierende Faktoren b beschreibt überproportionale Auswirkung großer Projekte m dient zur Berücksichtigung von Korrekturfaktoren für Produkt, Vorgehen und die Qualität von Entwicklern Barry Boehm *1935 PhD UCLA, Prof. USC, Erfinder von V- und Spiralmodell, CoCoMo Projektmanagement M4 - Schätzung 163

164 CoCoMo I Differenzierung in Projekt-Klassen Einfach (Organic Mode) einfache Anwendungssoftware, Größe <50 KDSI eingespieltes Team, bekannte Umgebung, wenig Neuland PM DEV = 2,4 * (KDSI) 1,05 * m T = 2,5 * PM DEV DEV 0,32 Mittelschwer (Semi-detached Mode) mittelschwere Projekte, Größe typischerweise <300 KDSI PM DEV = 3,0 * (KDSI) 1,12 * m T = 2,5 * PM DEV DEV 0,35 Eingebettete Systeme (Embedded Mode) schwierige Projekte, beliebige Größe starker Kosten-, Termindruck, viel Neuland PM DEV = 3,6 * (KDSI) 1,2 * m T = 2,5 * PM DEV DEV 0,38 Projektmanagement M4 - Schätzung 164

165 COCOMO: Größe vs. Aufwand Projektmanagement M4 - Schätzung 165

166 Der Korrekturfaktor m dient zur Einflussfaktoren, Kostentreiber Berücksichtigung unternehmensspezifischer und projektspezifischer Kostenfaktoren Produkt RELY: geforderte Zuverlässigkeit der (cost drivers): Software m = m1 * m2 * * m15 DATA: Größe der Datenbasis MM CPLX: Komplexität des Produktes DEV = a * KDSI b * m Computer TIME: benötigte Rechenzeit STOR: Nutzung verfügbarer Speicherplatz VIRT: Änderungshäufigkeit der Systembasis TURN: Bearbeitungszyklus Projekt MODP: Verwendung moderner Entwicklungsmethoden TOOL: Verwendung von Tools SCED: Anforderungen an die Entwicklungszeit Personal ACAP: Analysefähigkeit der Projektmitarbeiter AEXP: Erfahrung der Mitarbeiter im Arbeitsgebiet PCAP: Programmierfähigkeit der Mitarbeiter VEXP: Erfahrung der Mitarbeiter in der Systemumgebung LEXP: Erfahrung der Mitarbeiter in der Programmiersprache Projektmanagement M4 - Schätzung 166

167 Kostenfaktoren m = m1 * m2 * * m15 Projektmanagement M4 - Schätzung 167

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 Wiederverwendung basierend 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 168

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 * KSLOC B * M Entwicklungszeit T = 2,66 * PM wobei KSLOC: Kilo Source Lines of Code 0,33 + 0,2 (B - 1,01) Wachstumsfaktor B = 1,01 + 0,01 Σ SF i SF i sind insgesamt fünf Skalierungsfaktoren (scaling factors) M ist das Produkt der insgesamt 17 Kostenfaktoren (effort multipliers) Projektmanagement M4 - Schätzung 169

170 COCOMO II: Skalierungsfaktoren (scaling factors) Faktor Sehr Gering Nominal Hoch Sehr Extra gering hoch hoch Erfahrung 4,05 3,24 2,43 1,62 0,81 0 Flexibilität 6,07 4,86 3,64 2,43 1,21 0 Risikoumgang 4,22 3,38 2,53 1,69 0,84 0 Zusammenarbeit 4,94 3,95 2,97 1,98 0,99 0 Prozessreife 4,54 3,64 2,73 1,82 0,91 0 Erfahrung: Vertrautheit des Entwicklungsteams mit dem Produkt Flexibilität bezüglich der Einhaltung von Anforderungen / Vorgaben Risiko-Umgang: Qualität des Risikomanagements Güte der Zusammenarbeit zwischen allen Projektbeteiligten Reife des Entwicklungsprozesses Projektmanagement M4 - Schätzung 170

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 171

172 COCOMO II: Kostenfaktoren (effort multipliers) Projektmanagement M4 - Schätzung 172

173 Beispiel: 2,45 * KSLOC 1.17 * M SLOC Projektmanagement M4 - Schätzung 173

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 verbindlich Viele Firmen sammeln Aufwandsdaten nicht Dann hat man sie nur in den Köpfen der Entwickler/Projektleiter Das ist sehr ungenau! Oft wird das Ergebnis der Schätzung nicht akzeptiert sondern 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 174

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 Systemrealisierung Typische 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 Vergleich Schätzen durch Zerlegung (Anforderungen oder Entwurf) Expertenschätzung Schätzen mit Korrekturfaktoren Schätzen mit Stellvertretergröße Projektmanagement M4 - Schätzung 175

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 PM DEV = a * Size b * m COCOMO II ist ein 3-Stufen Modell, das bei Entwicklungsfortschritt immer genauere Schätzungen ermöglicht Projektmanagement M4 - Schätzung 176

177 Projektmanagement: Planung

178 Ziele Kennenlernen der wichtigsten Planungstätigkeiten und Arten von Projektplänen Lernen Netzpläne und Balkendiagramme zu erstellen Lernen Grundzüge der Risikoplanung zu verstehen Aufgaben der Personalplanung kennenlernen Bernhard Bauer, all rights reserved

179 Warum denn überhaupt planen? Auch ein falscher Plan ist besser als kein Plan Alternative: totaler Blindflug Ein 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

180 Wirkung des Planungsaufwands 180

181 4 Schätzverfahren und Projektplanung 4.2 Projektplanung Planungstechniken Ziele: Überblick über den Projektablauf Vorbereitung der Projektdurchführung Zeitschätzung und Terminbestimmung Planung 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

183 Planung im Projektverlauf Bernhard Bauer, all rights reserved

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

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 werden Die Planung gibt es im Detail und in der Übersicht Detail z. B.: Excel, MS Project Übersicht z. B.: PowerPoint Die Planung kommunizieren In den Teamräumen aushängen Bei jedem Teammeeting wiederholen Projektstatus im Rahmen der Planung darstellen Bernhard Bauer, all rights reserved

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

187 Beispiel Projektkontext Ein 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. Fragestellung Ist eine Einführung im Januar 2009 oder erst im Juli 2009 möglich? Bernhard Bauer, all rights reserved

188 Grobplanung Ausgehend von der Aufwandsdimensionierung von 9-10 PJ kann man nach dem Schlüssel ( ) eine ungefähre Verteilung auf die Projektphasen vornehmen fachliche Konzeption (30%) ca. 35 PM technische Konzeption (15%) ca. 15 PM Implementierung (40%) ca. 45 PM Integration & 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 machbar Bei 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

189 Projektplan Funktion: beschreibt aktuellen Planungsstand (Soll-Werte) Vorbereitung Ressourcenbereitstellung Vorbereitung Kontrolle/Steuerung Bestandteile von Projektplänen Zusammenfassung mehrerer Vorgänge zu einer Phase Festlegung von Meilensteinen als Abschluss von Phasen oder Vorgangsgruppen: Null-Dauer Überprüfbarkeit: Teilprodukt ist fertiggestellt Kurzfristigkeit: kurze Zeitdauer zwischen Meilensteinen Gleichverteilung: kontinuierliche und gleiche Verteilung Abhängigkeiten zwischen Meilensteinen und Vorgängen: fachliche terminliche Integration in Netzplänen personelle Elemente (Planung): Projektstrukturplan Terminplan Personalplan Ressourcenplan Zusätzlich: Ist-Werte Projekt 189

190 Projektplan Funktion: beschreibt aktuellen Planungsstand (Soll-Werte) Vorbereitung Ressourcenbereitstellung Vorbereitung Kontrolle/Steuerung Bestandteile von Projektplänen Zusammenfassung mehrerer Vorgänge zu einer Phase Festlegung von Meilensteinen als Abschluss von Phasen oder Vorgangsgruppen: Null-Dauer Überprüfbarkeit: Teilprodukt ist fertiggestellt Kurzfristigkeit: kurze Zeitdauer zwischen Meilensteinen Gleichverteilung: kontinuierliche und gleiche Verteilung Abhängigkeiten zwischen Meilensteinen und Vorgängen: fachliche terminliche Integration in Netzplänen personelle Elemente (Planung): Projektstrukturplan Terminplan Personalplan Ressourcenplan Zusätzlich: Ist-Werte Projekt 190

191 Projektstrukturplan Projektstrukturplan oder Work Breakdown Structure Ziel: Erfassen der Abhängigkeiten im Projektverlauf Vorbereiten der Aufwands- und Zeitplan Idee: Zerlegung des Projekts solange in Teilaufgaben, bis diese umsetzbar sind Die einzelnen umsetzbaren Teilaufgaben werden mit Meilensteinen für Beginn und Ende versehen (und deren Erreichung überprüft) Ist ein Mittel, ein Projekt graphisch in Teile zu zerlegen und darzustellen kein Terminplan keine Abbildung der Projektorganisation 191

192 Projektstrukturplan Projektstrukturplan 192

193 Typen von Projektstrukturplan Objektorientierter Projektstrukturplan Definition der Aufgabenpakete nach der technischen Struktur des Projektes z.b.: Objekte/Blöcke - Funktionen Hausbau: Keller, Erdgeschoss, Dachgeschoss Funktionsorientierter Projektstrukturplan Definition nach Entwicklungsfunktionen (Bereichen) z.b.: Funktionsblöcke - Teilfunktionen - Einzelaufgaben Hausbau: Rohbau, Ausbau Ablauforientierter Projektstrukturplan Definition gemäß Entwicklungsprozeß z.b.: Phasen - Fachgebiete - Verantwortlichkeiten Hausbau: Planung, Umsetzung Meist werden Mischformen verwendet (z.b.: erste Ebene phasenorientiert, ab zweiter Ebene funktionsorientiert) 193

194 Projektstrukturplan Projektprozessauswahl Auswahl von Phasenkonzept oder Vorgehensmodell z. B. IT-Projekt im öffentlichen Bereich nach V-Modell Tailoring: projektspezifische Anpassung und Detaillierung Erstellung: Instantiierung Prozessmodell Produktstruktur: Erfassen/Festlegen der Teilprodukte und ihrer Abhängigkeiten Ablaufstruktur: Festlegen der Vorgänge abhängig von der Produktstruktur Elemente: Phasen (entsprechen Prozessphasen) hierarchische Strukturierung der Aufgaben Vorgänge (konkretisieren Prozessaktivitäten) Meilensteine (entsprechen Prozessereignissen) 194

195 Meilensteine Ziel: Ermöglichen die Projektkontrolle Gezieltes Erkennen der Projektverzögerung Rechtzeitiges Erkennen der Projektverzögerung Entsprechen synchronisierenden Projektereignissen Projektstart, Projektende, Vorgangsende Daher: Geknüpft an Erstellung eines (Teil)Produkts Dichte: Relativ zur Gesamtlaufzeit: Abstände bis zu vier Wochen Gleichverteilung: ungefähr gleiche Abstände Eigenschaften: Überprüfbarkeit: Objektive Kriterien Systemarchitektur liegt vor Testdrehbuch mit 10 Testfällen liegt Nicht: Implementierung zu 80% abgeschlossen 195

196 Meilensteine Achtung: 90%-Syndrom! 196

197 Projektablaufplan Ein Projektablaufplan dient zur Darstellung des zeitlichen Verlaufs und der Abhängigkeiten von Projektaufgaben und Ergebnissen: Abhängigkeiten zwingende Folge empfehlende Folge freie Folge Verschiedene Ablaufplänen mit unterschiedlichem Informationsgehalt Linearpläne Netzpläne 197

198 Projektablaufplan Darstellungstechniken Listungstechnik nur bei kleinen (Linear-)Plänen sinnvoll einsetzbar Terminlisten: Workpackages (Vorgangslisten), von außen vorgegebene Termine Netzplantechnik, zusätzlich technologische Abhängigkeiten z. B. Vorgangspfeilnetzplan (CPM) Vorgangsknotennetzplan Ereignisknotennetzplan Balkendiagrammtechnik zusätzlich je Teilaufgabe Start- und Endtermin bzw. Dauer z. B. Gantt-Diagramm PLANNET-Diagramm Vernetzte Balkenpläne zusätzlich einfache Abhängigkeiten zwischen Vorgängen 198

199 Terminlisten Enthält Liste der Aktivitäten bzw. Vorgänge Zu jedem Vorgang wird die Liste der beteiligten oder verantwortlichen Personen angegeben Weiter wird (meist) eine Deadline für jeden Vorgang definiert Zusätzlich kann eine Liste der Meilensteine existieren bzw. eine separate Liste von außen vorgegebener wichtiger Termine (Deadlines) 199

200 Netzplantechnik Netzplantechniken Ziel Terminplanung für Vorgänge/Ereignisse Berücksichtigung der Abhängigkeiten (evtl. Varianten) Kennzeichen umfassendes Planungsinstrument für komplexe Projekte bietet übersichtlichen Überblick über den Projektablauf, inklusive der eindeutigen Darstellung der Abhängigkeiten einzelner Vorgänge im Ablauf ermöglicht genaue Zeitschätzung bzw. Terminfestlegung für den Gesamtablauf sowie für einzelne Vorgänge Erkennen der zeitintensivsten Ablauffolge: kritischer Weg ermöglicht relativen Vergleich der Konsequenzen von Terminen, Kosten und Einsatzmitteln verschiedener Planungsvarianten fö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. 200

201 Netzplantechnik Netzplantechniken Netzplantechnik ist geeignet für: - Strukturplanung - Zeitplanung - Einsatzmittelplanung - Kostenplanung bewährte Arten von Netzplänen: -CPM: Critical Path Method -PERT: Program Evaluation and Review Technic -MPM: Metra-Potential-Method zahlreiche Softwareprodukte unterstützen den Einsatz der Netzplantechnik; oft: Zusammenfassung verschiedener Arten von Netzplänen; daher: Vorsicht auf Konsistenz! 201

202 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 Dauer ggf. der direkten Nachfolgetätigkeiten Erstellung der Tätigkeitsliste (auch Vorgangsliste ) Beispiel siehe nächste Folie 202

203 Netzplantechnik CPM Beispiel: Tätigkeiten mit Zeitangaben und Vorgängerrelationen 203

204 Netzplantechnik Netzplantechniken Netzplanvarianten: 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. 204

205 Netzplantechnik Vorgangsknoten Netzpläne - Activity on Node (AoN) Knoten: enthalten Vorgänge, Vorgangsnummern und Dauern Kanten: beschreiben die Anordnungsbeziehungen zwischen den Vorgängen Vier Anordnungsbeziehungen zwischen Vorgängen Normalfolge (Ende-Anfang Beziehung) Anfangsfolge (Anfang-Anfang Beziehung) Endfolge (Ende-Ende Beziehung) Sprungfolge (Anfang-Ende Beziehung) 205

206 Netzplantechnik Vorgangsknotennetzplan - Beispiel 206

207 Netzplantechnik - Vorgangsknotennetzplan Vorgangsknotennetzplan Vorgangsknotennetzplan KNP = (A,R,a,A,e,E) A = {a 1,...,a m } 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 = { r 1,...,r n } A A Menge der Abhängigkeiten a/a frühester/spätester Starttermin Projekt e/e frühester/spätester Endtermin Projekt Begriffe: Pfad (a 1,...,a m ): Menge von Aktivitäten mit (a i, a i+1 ) R Vorgänger V(a): { a (a, a) R } Nachfolger N(a): { a (a, a ) R } 207

208 Netzplantechnik - Vorgangsknotennetzplan Vorgangsknotennetzplan Ein Netzknoten ist i.a. wie folgt aufgebaut: FA - frühester Anfang FE - frühestes Ende SA - spätester Anfang SE - spätestes Ende Subnetze: komplexe Netzknoten können aus Gründen der Übersichtlichkeit in Subnetze zerlegt werden 208

209 Netzplantechnik - Vorgangsknotennetzplan Vorgangsknotennetzplan Normalfolge Das Ende von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (EA: Ende- Anfang) Anfangsfolge Der Beginn von Vorgang 1 ist Voraussetzung für den Beginn von Vorgang 2 (AA: Anfang - Anfang) 209

210 Netzplantechnik - Vorgangsknotennetzplan Vorgangsknotennetzplan Endfolge Das Ende von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (EE: Ende - Ende) Sprungfolge Der Beginn von Vorgang 1 ist Voraussetzung für das Ende von Vorgang 2 (AE: Anfang - Ende) 210

211 Netzplantechnik - Vorgangsknotennetzplan Terminberechnung Berechnung 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äten Berechnung 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äten Berechnung Pufferzeiten p(a): Zeit zwischen frühestem und spätestem Anfang Zeit zwischen frühestem und spätestem Ende Kritischer Pfad: Eine Aktivität mit Pufferzeit 0 ist eine zeitkritische Aktivität All zeitkritischen Aktivitäten auf einem Pfad bilden einen kritischen Pfad Verzögerung kritischer Aktivitäten führen zu Gesamtprojektverzögerungen 211

212 Netzplantechnik - Vorgangsknotennetzplan Vorgangsknotennetzplan Beispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen 212

213 Netzplantechnik - Vorgangsknotennetzplan 213

214 Netzplantechnik - Vorgangsknotennetzplan Vorgangsknotennetzplan Beispiel - Tätigkeiten mit Zeitangaben und Vorgängerrelationen 214

215 Netzplantechnik - Vorgangsknotennetzplan 215

216 Netzplantechnik Netzplantechnik umfasst folgende Schritte: Erstellen der Tätigkeitsliste aufgrund des Projektstrukturplans Erstellen des Netzplans Berechnen der Vorgangszeitpunkte Ermitteln der Pufferzeiten Errechnen des kritischen Weges Verwendung des Netzplans als Basis von Balkendiagrammen, z.b. Belegungsplan, Einsatzplan Einsatzmittel-Auslastungsdiagrammen, z.b. zwecks Bedarfsglättung 216

217 Netzplantechnik CPM CPM: Vorgangskantennetzplan / Vorgangspfeilplan Knoten: 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 2 Zeitwert der Vorwärtsrechnung Zeitwert der Rückwärtsrechnung 217

218 Netzplantechnik CPM CPM: Vorgangskantennetzplan oft werden Ereignisknoten auch folgendermaßen dargestellt 218

219 Netzplantechnik CPM CPM: Vorgangskantennetzplan gerichtete 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 219

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

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

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

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

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

225 Netzplantechnik CPM Beispiel: CPM Netzwerk Tätigkeiten mit Zeitangaben und Vorgängerrelationen 225

226 Netzplantechnik CPM Beispiel: CPM Netzwerk - Numerierung der Knoten 226

227 Netzplantechnik CPM Beispiel: CPM Netzwerk - Bestimmung der frühesten Beginnzeiten 227

228 Netzplantechnik CPM Beispiel: CPM Netzwerk - Bestimmung der spätesten Beginnzeiten 228

229 Netzplantechnik CPM Beispiel: CPM Netzwerk - Bestimmung des kritischen Pfades 229

230 Netzplantechnik CPM Erstellen des Netzplans: Eintragen der logischen Abhängigkeiten zwischen Tätigkeiten Eintragen 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 und Eintrag 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. 230

231 Netzplantechnik CPM Beispiel eines Netzplans mit einem kritischen Weg: 231

232 Netzplantechnik CPM Berechnen der Vorgangszeitpunkte ( Tätigkeitszeitpunkte ): frühester Anfangszeitpunkt des Ereignisses: spätester Endzeitpunkt eines Vorganges: frühester Endzeitpunkt eines Ereignisses: spätester Anfangszeitpunkt eines Vorganges: Zweck: Berechnung der Pufferzeiten und Erstellen des Einsatz- Auslastungsdiagramms, z.b. zwecks Bedarfsglättung FA SA SE FE 232

233 Netzplantechnik CPM 233

234 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) - D oder GP = SZ(j) - FZ(i) - D Bedeutung: GP gibt an, wie lange ein Vorgang höchstens verlängert/verzögert werden kann, ohne daß der Endtermin beeinträchtigt wird. 234

235 Netzplantechnik CPM Freie Pufferzeit (FP): FP = FE(j) - FA(i) - D oder FP = FZ(j) - FZ(i) - D Freie 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. 235

236 Netzplantechnik CPM Unabhängige Pufferzeit (UP): UP = FE(j) - SA(i) - D Bedeutung: 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 und b) der Vorgang muß den frühestmöglichen Endzeitpunkt einhalten können. weitere Kenngröße: Schlupf im Zustand i: SL(i) = SZ(i) - FZ(i) 236

237 Netzplantechnik CPM Übersicht zu Pufferzeiten und Schlupf 237

238 Netzplantechnik Zusammenfassung Netzplantechnik Eingabe: - Projektstrukturplan - Terminvorgaben - Aufwandsschätzung (Zeitaufwände) Ergebnis: - Meilensteinplan - Terminplan Einschränkende Annahmen Annahme: Vorgangsdauer genau abschätzbar Annahme: Ressourcen frei planbar Konsequenz: Termin- und Ressourcenplanung verschränkt durchführen 238

239 Balkendiagramm Balkendiagramm (GANTT-Diagramm) Entwickelt von Henry L. Gantt, Graphische Darstellung der Terminlisten unter Einbeziehung der Dauer der einzelnen Vorgänge Gute Visualisierung der einzelnen Phasen und des Projektfortschritts Aktivitäten werden in Balkenform aufgetragen Die Länge des Balkens entspricht der Länge der Aktivität Graue 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 dar Aus Gantt-Diagrammen sind die Zusammenhänge der einzelnen Aktivitäten nicht ersichtlich 239

240 Balkendiagramm Balkendiagramm (GANTT-Diagramm) Balkendiagramme: vielseitige Verwendung; horizontale Achse: Zeit vertikale Achse: z.b. - Sachmittel: Belegungsplan - Aufgaben: Tätigkeitsplan, Projektfortschrittsplan - Aufgabenträger: Einsatzplan Erweiterungen: Balken können mit Wert beschriftet werden z.b. Mitarbeitername je ein Balken für Soll- und Ist-Wert zwecks Vergleich 240

241 Balkendiagramm Balkendiagramm Gesamtpersonalplan Alle Projektpartner kumuliert Zeitplan - Angaben als 'Personen pro Monat' Personaleinsat Quartale berücksich 0,2*3=0,6 Arbeitsschritte Meilensteine Jahr Balkendiagramm Meilensteine Einteilung nach Vergütungsg bei Wirtschafts-Unternehme o.ä. Quartal 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 2 AP 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 Regelbibliothek AP 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 3 MS 3.2 Transformations / Codegen. In Innovator AP 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, 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 Eval AP 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 241

242 Balkendiagramm Vernetzte Balkenpläne In das Balkendiagramm werden zusätzlich Informationen über einfache Abhängigkeiten zwischen den einzelnen Vorgängen eingefügt Darstellung: Pfeile vom Vorgänger-Balken zum jeweiligen Nachfolger Dadurch 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 242

243 Balkendiagramm Balkendiagramm 243

244 Balkendiagramm 1st Quarter 3rd Quarter 1st Quarter 3rd Quarter 3rd Quarter 1st Quarter 1st Quarter 3rd Quart 3rd Quart ID ID Task Name 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 D17 Annual Report Review 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 31/03 31/03 30/04 31/12 31/03 31/12 30/05 30/06 20 D22 Specifications of Field Trials 30/08 21 D23 Evaluation of Field Trials 22 WP3 WP3 Light. Ext. Agent Platform 30/06 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 D34 LEAP Version WP4 WP4 Agent Services & Applications 33 T4.1 Design 34 T4.2 Implementation 35 T4.2 Integration 36 T4.4 Maintenance 31/05 31/07 31/12 30/08 37 D41 Agent Services Design 30/08 38 D42 Lab Trial 31/12 39 D43 LEAP Application Implementations 28/09 40 Phase 1 Phase 2 244

245 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 ) 2) Durchführende Personen oder Rollen Chefdesigner 3) Notwendige Fähigkeiten des/der Durchführungen Gute technische und funktionale Kenntnisse Mobile Odors, Trainerausbildung 245

246 Arbeitspaketbeschreibung PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining 4) Dauer und Aufwand 5) Liefergegenstände Schulungsdauer: 2 Tage (à 8 Stunden), Aufwand noch zu bestimmen 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 246

247 Arbeitspaketbeschreibung PSP-ID 5.3 Schulungen, Teilpaket internes Vertriebstraining 4) Dauer und Aufwand 5) Liefergegenstände Schulungsdauer: 2 Tage (à 8 Stunden), Aufwand noch zu bestimmen 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 247

248 Personalplanung Personalplanung Aufgaben der projektbezogenen Personalplanung Sicherstellung der Mitarbeiterverfügbarkeit Optimaler Einsatz der Mitarbeiter - Vermeidung von Mitarbeiterüberlastung - Vermeidung von mangelnder Mitarbeiterauslastung 248

249 Personalplanung Ermittlung Personalaufwand Prinzipieller Ansatz: Eingaben: Aufwand Aktivität, Dauer Aktivität Ausgabe: Anzahl benötigter Mitarbeiter Verfahren: Zusätzlich: Benötigte Qualifikation Rechenbeispiel: 10 PM Dauer 10 KM : 1 MA Dauer 2 KM : 5 MA Bemerkungen: Annahme der normierten Leistung (1 MA leitet 1 PM pro Monat) Annahme der unabhängigen Multiplizität von Mitarbeitern Berücksichtigung Brutto/Netto-Leistung 249

250 Personalplanung Personalplanung Prinzipieller Ansatz: Ermittlung Personalaufwand (Projektstrukturplan, Aufwandsschätzung, Terminplan) Ermittlung Personalressourcen Personalzuordnung und Optimierung der Auslastung Varianten der Zuordnung/Optimierung: Terminorientiert: Aufwände in Abhängigkeit vorgegebener Termine Aufwandsorientiert: Termin in Abhängigkeit vorgegebener (Maximal-)Aufwände Realistisch: Mischverfahren 250

251 Personalplanung Optimierung Varianten der Zuordnung/Optimierung: Terminorientiert: - Einhaltung vorgegebener Termine - Erhöhung der Personalzuordnung Aufwandsorientiert: - Einhaltung vorgegebener (Maximal-)Aufwände - Verschiebung des Termins 251

252 Personalplanung Organisatorische Randbedinungen Qualifikation der Mitarbeiter: Qualifizierte Mitarbeiter einsetzen Mitarbeiter 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 einplanen Matrixstruktur: Linenvorgesetzten in Planung einbeziehen Generell: Mitarbeiter rechtzeitig in Planung einbeziehen 252

253 Personalplanung Humane Randbedingungen Produktivitätsvarianzen: Starke Produktivitätsschwankungen zwischen Mitarbeitern Schwache Produktivitätsschwankungen im Team Teamkohäsion Teamidentifikation mittels gemeinsamer Normen Never change a winning team Ausrichtung auf ein gemeinsames Ziel Projektidentifikation Identifikation erhöht Produktivität Multiprojekteinsatz reduziert Produktivität Generell: Humane Faktoren sind primäre Produktivitätstreiber 253

254 Personalplanung Produktivität Produktivitätsvarianzen: Beste Mitarbeiter um Faktor 10 besser als schlechteste Beste Mitarbeiter um Faktor 2,5 besser als Durchschnitt Überdurchschnittliche Mitarbeiter um Faktor 2 besser als unterdurchschnittliche Unabhängig von Leistungsmetrik: - Anzahl der Fehler - Kalenderzeit bis Meilenstein - Funktionspunkte pro Zeiteinheit 254

255 Personalplanung Ressourcenplanung Verfahren: Im wesentlichen analog Personalplanung Ähnliche Probleme - Qualifikation: Vorbereitung - Multiprojekteinsatz: Umrüstung Unterscheidung Nichtverbrauchbare Ressourcen Verbrauchbare Ressourcen (eingebettete SW) 255

256 Projektmanagement: Controlling und Steuerung

257 Ziele Massnahmen zum Controlling eines Projekts kennen lernen Aspekte der Teamführung diskutieren Projektmanagement M6 Controlling und Steuerung 257

258 Projektkontrolle (Controlling) Controlling umfasst Fortschrittskontrolle Budget-/Zeitkontrolle Überprüfen von Risiken im Rahmen des Risikomanagement Mitarbeiterkontrolle Überprüfen der Qualitätsstands im Rahmen des Qualitätsmanagement Konfigurationsmanagement... Ziele der Fortschrittskontrolle Bestandsaufnahme: Wo steht das Projekt aktuell (regelmäßig)? Feststellung Projekt/Produktstatus und Abweichungen Unterstützung Steuerung Basis für weitere Planungen Produktivitätsentwicklung (Soll/Ist) Zeitplanung Kapazitätsplanung Identifikation von Problembereichen Reaktion auf Probleme, Definition und Durchführung von Gegenmaßnahmen Projektmanagement M6 Controlling und Steuerung 258

259 Projektmanagement M6 Controlling und Steuerung 259

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 260

261 Prinzip des Controlling: Soll-Ist-Vergleich Beispiel: Was sagt diese Kurve aus? Projektmanagement M6 Controlling und Steuerung 261

262 Ist-Soll-Vergleich: Meilensteintrendanalyse Verfahren: Regelmäßige Erfassung Status Erfassung pro Meilenstein Keine rückwirkende Änderungen Projektmanagement M6 Controlling und Steuerung 262

263 Meilensteintrendanalyse Ziel: Prognostizierung Termine Erhöhung Planungssicherheit: Erkennen Schätzfehler Verfahren: Status: Regelmäßige Erfassung geplanter Termine Prognostizierung: Interpolation Änderungen Propagierung: Änderung abhängiger Termine Verifizierung: Berücksichtigung Streuung Erkennbare Planungsfehler: Indikatoren Unrealistische Schätzung: (Super)lineare Verschiebungen Starke Schwankungen Späte Neuschätzung: Terminasymptoten Projektmanagement M6 Controlling und Steuerung 263

264 Meilensteintrendanalyse Berichtszeitpunkte Meilenstein- Termine x x x x x IV III II I IV III II I IV III II I IV III II I IV III II I 200x 200x 200x 200x 200x I II III IV I II III IV I II III IV I II III IV I II III IV Projekt: xxx Projektleiter: xxx Projektmanagement M6 Controlling und Steuerung 264

265 Meilensteintrendanalyse Berichtszeitpunkte Berichtszeitpunkte Meilenstein-Termine 1 Meilenstein-Termine Ausgangssituation nach Planung Erste Projektbesprechung mit Terminkontrolle nach einem Monat Meilenstein-Termine Berichtszeitpunkte Berichtszeitpunkte Meilenstein-Termine Zweite Projektbesprechung mit Terminkontrolle nach zwei Monaten Dritte Projektbesprechung mit Terminkontrolle nach drei Monaten Projektmanagement M6 Controlling und Steuerung 265

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

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 Meilensteinen Wöchentliche (oder mehr wöchentliche) Planungsmeetings, Statusmeetings In kritischen Phasen sogar täglich Projektmanagement M6 Controlling und Steuerung 267

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 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, Risikobericht Qualitätssicherung: Fehlerbericht Statusberichte haben einen formalen Rahmen, stellen sicher, dass alle Punkte beleuchtet werden Projektmanagement M6 Controlling und Steuerung 268

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 269

270 Antwort Erst fertig ist fertig. Erinnerung: ein Arbeitspaket/eine Aktivität hat definierte Ergebnisse und Qualitätskriterien Insbesondere bei der Programmierung: Code ist erst dann fertig, wenn der Entwicklertest erfolgreich stattgefunden hat NIEMALS auf die Antwort Fast fertig einen Fertigstellungsgrad von mehr als 50% annehmen. Projektmanagement M6 Controlling und Steuerung 270

271 Technische Umsetzung des Controlling Spalte für Restaufwände ab aktueller Woche Im Beispiel hier: bei wöchentlicher Statusabfrage werden Fertigstellungsgrad und Restaufwände ermittelt Projektmanagement M6 Controlling und Steuerung 271

272 Controlling der Restaufwände LOP Die Liste offener Punkte Problemstellung: Idee: 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. Führen einer Liste der Offenen Punkte (LOP) Projektmanagement M6 Controlling und Steuerung 272

273 Controlling der Restaufwände LOP- Umsetzung Inhalte der LOP Name des Punkts Beschreibung Wer hat ihn eingestellt (wg. Nachfragen)? Wer kümmert sich um die Klärung? Bis wann? Status bei großen Listen ggf.: Prioriät Ordnungskriterium, z. B. Projektphase ( Fachkonzept Technisches Konzept, etc.) Umsetzung mit Tabellenkalkulation Projektmanagement M6 Controlling und Steuerung 273

274 Controlling der Restaufwände Vorgehen LOP Verantwortlichen für die LOP benennen, Aufgaben: Aktualisierung Übersicht behalten Nachhalten von Terminen Befüllen der LOP i. d. R.: jeder darf eintragen und sammeln. Regelmäßig (z. B. zu den wöchentlichen Team-Meetings) Vorbereitung: Punkte durchgehen und bewerten Im Meeting Status erheben, Aufgaben verteilen Projektmanagement M6 Controlling und Steuerung 274

275 Typische Inhalte eines Statusreports Ist-Zustand und aktuelle Planung Wo laufen Ist und Soll auseinander? Welche Maßnahmen wurden ergriffen? Sind Meilensteine gefährdet? Aktuelle Risikoliste des Projekts Welche Projektrisiken bestehen, welche Maßnahmen wurden ergriffen? Nächste Schritte, Vorgehen bis zum nächsten Termin Entscheidungsbedarf Reduktion auf Status-Ampel grün: alles ok gelb: Projekterfolg wahrscheinlich gefährdet rot: Projekterfolg gefährdet, Handlungsbedarf Projektmanagement M6 Controlling und Steuerung 275

276 Controlling entlang der Projekthierarchie Projektmanagement M6 Controlling und Steuerung 276

277 Statusreports auf höheren Organisationsebenen Typische Reportingzyklen Team an (Teil-)Projektleiter: wöchentlich Teilprojektleiter an Gesamtprojektleiter: wöchentlich bis 2-wöchentlich. Gesamtprojektleiter an Lenkungsgremium: 1 x im Monat oder seltener. Bei Projektleitungsmeetings: Statusreports Nutzen entsteht bereits dadurch, dass der Berichtende sich selbst über den Status seines Teams bewusst werden muss. Projektmanagement M6 Controlling und Steuerung 277

278 Exkurs: Meetings Projektmanagement M6 Controlling und Steuerung 278

279 Die Einladungsmail From: To: Subject: Einladung Hallo Kollegen, am findet um 14:15 in Raum 1.31 das Meeting zum Thema Integration von Web Services statt. Mit freundlichen Grüßen Michael Projektmanagement M6 Controlling und Steuerung 279

280 Professionelle Meetings Ziel festlegen und aufschreiben! Verantwortlichen festlegen Verantwortlicher verschickt Einladung Termin, Ort, Zeitrahmen Teilnehmer Wer muss denn wirklich dabei sein? Ziel Agenda Wer moderiert, wer führt Protokoll? Technik vorher organisieren: Beamer, Flipchart, Getränke, Projektmanagement M6 Controlling und Steuerung 280

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 281

282 Das Protokoll Protokoll vom Anwesend: Hr. Meier, Fr. Müller, Hr. Schulze, Fr. Schmidt TOP* 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/Schulze Hr. Schmidt klärt, ob die Services auch unter Windows genutzt werden sollen. TOP 2: Security Herr Müller stellt das Security-Konzept vor. Anlagen: Präsentation WebServices Präsentation Security *TOP = Tagesordnungspunkt Projektmanagement M6 Controlling und Steuerung 282

283 Was gehört ins Protokoll? Datum Teilnehmer Verteiler (nicht teilgenommen, aber offiziell informiert) Vorgehen Gleich nach dem Meeting aufschreiben, an Verteiler verschicken, ggf. Feedback einarbeiten. Tagesordnungspunkte Information, Feststellung, Beschluss, Aufgabe Aufgaben immer mit Termin und einem Verantwortlichen Projektmanagement M6 Controlling und Steuerung 283

284 Protokoll Lenkungskreis Projekt XY Protokoll vom Anwesend: Hr. Meier, Fr. Müller, Hr. Schulze, Fr. Schmidt. Verteiler: Teilnehmer, Fr. Wagner TOP 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 Anlage: Präsentation Teilprojekt Dialoge Projektmanagement M6 Controlling und Steuerung 284

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 285

286 Steuerung Reaktionsmöglichkeiten Planung anpassen Termine Inhalte, Ergebnisse Qualität Mitarbeiter Vergleiche: Teufelsquadrat Sonstige Maßnahmen Ursache für Behinderung herausfinden Abstimmen Projektmanagement M6 Controlling und Steuerung 286

287 Wiederholung: Teufelsquadrat nach Sneed Projektmanagement M6 Controlling und Steuerung 287

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 288

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 289

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 290

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 eine gesunde Spannung aufrecht zu erhalten. Übermäßiger Druck ist schädlich und wirkungslos. Projektmanagement M6 Controlling und Steuerung 291

292 Projekttagebuch Motivation Störende Einflussfaktoren auf ein Projekt: Beistellungen verzögern sich Externe Entscheidungen verzögern sich Hardware 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 292

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 293

294 Teamführung Kommunikation Führungsstil Verhalten bei Fehlern Feedback Projektmanagement M6 Controlling und Steuerung 294

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 Teammeeting Themen 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 unbemerkt Ruhig auch mal die selbstverständlichen Dinge kommunizieren Projektmanagement M6 Controlling und Steuerung 295

296 Die selbstverständlichen Dinge geschehen seltsamerweise nicht von selbst Beispiele Wenn 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 verantwortlich Der Projektleiter ist immer verantwortlich, er muss Mitarbeiter beauftragen und nachhaken Projektmanagement M6 Controlling und Steuerung 296

297 Praxisbeispiel: zwei Teams Führungsstil Team A Informationen 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 B Stetiger 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 Ganze Projektleitung gibt Aufgaben ab. Projektmanagement M6 Controlling und Steuerung 297

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 Aufgaben Motivieren Sie die Mitarbeiter Helfen Sie den Teams, durchzustarten und abzuheben. Alles andere sind Administrivialitäten Projektmanagement M6 Controlling und Steuerung 298

299 Umgang mit Fehlern und Kritik Fehler sind niemals schön und erfreuen niemanden. Aber: honorieren, dass Fehler zugegeben werden. Auch schlechte Nachrichten honorieren: bad news welcome Selber Fehler zugeben. Kritik immer zur Sache, niemals zur Person! Projektmanagement M6 Controlling und Steuerung 299

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 300

301 Die Schere im Kopf Projektsituation: Verfahrene Lage, größere Probleme Da 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 301

302 Feedback Feedback für das Team ist enorm wichtig Regeln: zeitnah: sobald die Gelegenheit, der Anlass dazu da ist sonst wirkt Feedback nicht. Zu Feedback gehört auch positives Feedback: Motiviert Bestä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 302

303 Teambildung Team bedeutet Gemeinsamkeit Teambildung fördern: Gemeinsame Ziele Räumliche Nähe der Büros Kaffeeküche Team-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 303

304 Zusammenfassung (1) Ein Statusreport dient zur Feststellung des Ist-Zustande und zur aktuellen Planung und enthält Aktuelle Risikoliste des Projekts Ev. Meilenstein-Trendanalyse Nächste Schritte, Vorgehen bis zum nächsten Termin Entscheidungsbedarf Status-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 Teilnehmer Verteiler (nicht teilgenommen, aber offiziell informiert) Tagesordnungspunkte Projektmanagement M6 Controlling und Steuerung 304

305 Zusammenfassung (2) Teamführung heißt die richtigen Leute auszuwählen, mit den richtigen Aufgabe zu betrauen und zu motivieren Fehler zuzugeben und Missstände möglichst sofort zu beheben Positives Feedback zu geben Übermäßiger Druck bei Projektverzug ist schädlich und wirkungslos Eine Liste offener Punkte hilft beim Controlling Ein Projekttagebuch dient der Absicherung des Projekts und wird nur bei Bedarf herangezogen. Projektmanagement M6 Controlling und Steuerung 305

306 Projektmanagement: Risiko-, Änderungs- und Konfigurationsmanagement

307 Ziele Projektrisiken einschätzen und vermeiden/verringern lernen Änderungsmanagment mit Change Requests kennen lernen Techniken des Konfigurationsmanagments kennen lernen Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 307

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 308

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 309

310 Risikomanagement und Projektphasen Risikomanagementaktivitäten während der Projektdurchführung Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 310

311 Pareto-Regel Beobachtungen: Pareto-Regel: 20% der Probleme verursachen 80% der Kosten Behebungsverzögerung: je nach Phase bis zu 1000-fache Kosten Konsequenzen: Fokussierung auf wichtige Risiken Frühzeitige Erkennung und Vermeidung Vilfredo Federico Pareto (gebürtig Wilfried Fritz Pareto; ) italienischer Ingenieur, Ökonom und Soziologe Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 311

312 Identifizieren von Risiken Sammeln von Risiken spezielle 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): Technik Fachlichkeit Team Vorgehen im Projekt, Planung Auftraggeber Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 313

313 Beispiel SENSORIA Wissenschaftliche Risiken Technologische Risiken Organisatorische Risiken Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 314

314 Risikoquellen 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 Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 315 Integrierte Entwicklung Auftraggeber/Auftragnehmer

315 Risikoquellen 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) Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement Drohender Ausfall von Mitarbeitern (Krankheit, Kündigung) 316

316 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 317

317 Gesamtbewertung von Risiken Üblich: 3-stufige Bewertung gering, mittel, hoch. Verrechnung eigentlich 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 318

318 Beispiel Risikobewertung SENSORIA Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 319

319 Beispiel Risikobewertung SENSORIA Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 320

320 Beispiel: Risikoanalyse Auswirkungen mit Ereignisbaum abschätzen 0,3 Terminüberschreitung 2,34 Mio 0,7 wird rechtzeitig bemerkt und kann korrigiert werden Zusatzaufwand 1000 PT = wird übersehen oder kann nicht korrigiert werden 0,2 Konventionalstrafe Verlust von Folgeaufträgen + 1 Mio + 10 Mio 0,8 0,3 * ,7 * (0,2 * 11 Mio + 0,8 * 1 Mio ) = 2,34 Mio Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement nur Konventionalstrafe 1 Mio errechnet geschätzt 321

321 Beispiel: Risikoprioritätenbildung Maßnahmen durch Entscheidungsbaum vergleichen Korrektur durchführen Pioniere vorschicken nichts tun klappt klappt nicht klappt klappt nicht 0,1 0,9 0,7 0,3 800 T 2,34 + 0,8 = 3,14 Mio 20 PT à 800 = ,356 Mio klappt klappt nicht Vergleich der Alternativen nichts tun: 0,11 * 2,34 Mio = Pioniere: 0,7*16, ,3*2,356 Mio = Korrektur:0,1*0,8 Mio + 0,9* 3,14 Mio = 2,906 Mio 0,89 0,11 0 2,34 Mio Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 322

322 Beispiel: Risikoprioritätenbildung Maßnahmen durch Entscheidungsbaum vergleichen Korrektur durchführen Pioniere vorschicken nichts tun klappt klappt nicht klappt klappt nicht 0,7 0,3 0,7 0,3 800 T 2,34 + 0,8 = 3,14 Mio 20 PT à 800 = ,356 Mio klappt klappt nicht Vergleich der Alternativen nichts tun: 0,25 * 2,34 Mio = Pioniere: 0,7*16, ,3*2,356 Mio = Korrektur:0,7*0,8 Mio + 0,3* 3,14 Mio = 1,602 Mio 0,75 0,25 0 2,34 Mio Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 323

323 Maßnahmen entwickeln 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. Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 324

324 Beispiel SENSORIA Vorgehensweise Beobachtung von Symptomen Planung von Korrektivmaßnahmen Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 325

325 Beispiel SENSORIA Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 326

326 Typische Präventivmaßnahmen 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 Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 327

327 Weitere Beispiele für Präventivmaßnahmen 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 Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 328

328 Maßnahmen umsetzen und Wirkung prüfen Maßnahmen sind Aufgaben: ein Verantwortlicher ein 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 330

329 Dokumentation von Risiken: die Risikoliste Eine Risikoliste umfasst: Beschreibung des Risikos Name, Bezeichnung Was kann passieren? Was sind die Konsequenzen? Bewertung Wie groß ist der Schaden? Wie groß ist die Eintrittswahrscheinlichkeit? Gesamtbewertung Maßnahmen Maßnahme, Aufgabe Verantwortlicher Termin Status Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 331

330 Beispiel: Risikobewertung Risikoliste zur Priorisierung von Risiken lfd.nr. Beschreibung Wahrschein. Auswirkung Gewicht Gegenmaßnahme verantwortlich 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 Wirsing schreitung Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 332

331 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 kennen Risiken konkret formulieren nicht abstrakt Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 333

332 Ä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 334

333 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 335

334 Der Konflikt Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 336

335 Änderungsmanagement Änderungen an Entwicklungsergebnissen sind unvermeidlich Änderungen der Aufgabenstellung Neue Erkenntnisse bei der Produktentwicklung Fehler 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 337

336 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 sinken Regelfall: Umfang steigt Change Requests können vom Auftraggeber und vom Auftragnehmer eingebracht werden Regelfall: Auftraggeber Change Requests können nicht nur die Software, sondern z. B. auch die Projektorganisation oder das Projektvorgehen betreffen Change Requests können sich auf bereits erstellte oder auf noch zu erstellende Ergebnisse beziehen Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 338

337 Change Request-Verfahren Change Request formulieren Change Request bewerten Change Request entscheiden Change bearbeiten Das Change Request-Verfahren sorgt dafür, dass Änderungen kontrolliert in das Projekt einfließen Ein 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 339

338 Change Request-Verfahren Change Request formulieren Change Request bewerten Change Request entscheiden Change bearbeiten Möglichkeiten der Entscheidung über Change Request: zulassen ablehnen zurückstellen Entscheidung durch Projektleiter (kleinere Change Requests) Lenkungskreis (größere Change Requests) Die Änderung in die Projektplanung einarbeiten Planung ändern Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 340

339 Hinweise zum Change Request -Verfahren Bearbeiten von Change Request-Anträgen dauert und kostet Geld, egal, ob diese umgesetzt werden oder nicht Bei Projektbeginn schon die Spielregeln für Change Request-Verfahren bekannt machen, z. B. im Angebot bzw. im Projektauftrag beschreiben Change Requests technisch managen: Tabellenkalkulation Spezialsoftware, oft in Verbindung mit Konfig-Management und Anforderungen Freeware: 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 Fehler Oft schwierig auseinander zu halten, werden ähnlich gemanaged und eingeplant Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 341

340 Missbrauch des Change Request-Verfahrens Anbieter gibt auf Ausschreibung ein nicht kostendeckendes, niedriges Angebot ab Anbieter bekommt Zuschlag. Projekt startet Auftraggeber ist an Anbieter gebunden Den 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 Requests Anbieter optimiert seinen Gewinn über Change Requests Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 342

341 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 beseitigt Ursachen: 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 343

342 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 344

343 Konfiguration und Konfigurationsmanagement Konfigurationsmanagement Ziel: Produkt ist hinsichtlich seiner funktionellen (Code) und äußeren (zugehörige Information) Merkmale jederzeit identifizierbar Funktion: Sicherstellung der Identifizierbarkeit, Verfolgbarkeit, Kontrollierbarkeit, Status Darstellung der Zusammenhänge und Unterschiede zwischen verschiedenen Konfigurationen Sicherstellung der Verfügbarkeit früherer Konfigurationen Sicherstellen der Integrität (Gültigkeit, Reifegrad) von Produkten Ansatz: Explizite Verwaltung von Produkten und ihrer Versionen Konfiguration Eine Konfiguration ist eine (konsistente) Anordnung von Produkten einschließlich ihrer Beziehungen Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 345

344 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 346

345 Konfigurationsmanagement: Produktzustände Produktzustände: Definiert auf allen Produkten des V-Modells Verbinden KM mit allen weiteren Modulen Ermöglichen Produktverwaltung Zusammenhänge: KM: Erfassung Produkt, Produktstatus, Produktänderung QS. Überprüfung/Abnahme Produkt PM: Planung Produkt Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 347

346 Aufgaben Konfigurationsmanagement Aufgaben Konfigurationsmanagement Planung Konfigurationsmanagement Bereitstellen Produkt-/Konfigurationsmanagement Bereitstellung Änderungsmanagement Bereitstellung von elementaren Diensten Daten administrieren: - Zentrale, projektübergreifende Haltung aller Daten - Konsistente, vereinheitlichte Datendefinitionen SW-/HW-Produkte katalogisieren: Vorbereitung Wiederverwendung Schnittstellen koordinieren: Sicherung kompatibler Schnittstellen Ergebnisse sichern: Wahrung des erreichten Projektstands KM-Dokumentation führen zur Erstellung von Detailunterlagen und Übersichten verschiedenster KM-Belange, Release-Management: Kontrollierte Konfigurationsfreigabe- und verteilung Projekthistorie führen: Nachvollziehbare Dokumentation über den Projektverlauf Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 349

347 Techniken des Konfigurationsmanagements Einfachster Fall: Konfigurationsmanagement durch gemeinsame Ablage Versionsverwaltung Bilden von Konfigurationen Aufgabenbezogenes Arbeiten Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 350

348 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 351

349 Leistungsfähigere Ansätze Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 352

350 Versionsverwaltung 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. Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 353

351 Versionsverwaltung - Konflikte Ein zweiter Nutzer will die Datei ändern: System kann dies verhindern (Normalfall) oder System warnt, dass Datei zwischenzeitlich verändert wurde Nutzer führt eigene Änderungen mit fremden Änderungen zusammen Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 354

352 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ützt Wie kommt man an den Stand vom letzten Februar? Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 355

353 Erweiterung: Bilden von Konfigurationen Eine Konfiguration/Release legt zu jeder Datei fest Ist 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 Historie Statt nightly builds: ein Mitarbeiter übernimmt die Rolle des Konfigurationsmanagers Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 356

354 Erweiterung: Aufgabenbezogenes Arbeiten Problem: Um eine Änderung durchzuführen, müssen mehrere Dateien verändert werden. Diese Dateien sollen gemeinsam verwaltet werden. Aufgabenbezogenes Arbeiten In 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 357

355 Festlegungen für das Konfigurationsmanagement Was soll alles verwaltet werden? Code Dokumentation? Testfälle? Executables? Wie ist das KM aufgesetzt? Eingesetztes Produkt Prozesse: Wann darf wer den Code verändern? Verantwortliche: Wer darf Releases und Versionen erstellen? Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 358

356 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 erhalten Ein 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 ist die Verwaltung von Produkten und Konfigurationen und deren Änderungen. Die Techniken des Konfigurationsmanagement umfassen gemeinsame Ablage, Versionsverwaltung, Bilden von Konfigurationen und aufgabenbezogenes Arbeiten Projektmanagement M7 Risiko-, Change- und Konfigurationsmanagement 359

357 Projektmanagement: Prozessverbesserung

358 Ziele Wichtige Modelle zur Prozessverbesserung kennen lernen ISO 9000 ff Capability Maturity Model (CMM) Software Process Improvement and Capability determination (SPICE) ISO Konkrete Möglichkeiten zur Prozesseinführung und -verbesserung kennen lernen Projektmanagement M9 - Prozessverbesserung 361

359 Prozessverbesserung Beobachtung: Qualitätsverbesserung führt zu Reduktion der Entwicklungszeit Reduktion der Entwicklungskosten Steigerung der Wettbewerbsfähigkeit Ansatz: Verbesserung Entwicklungsqualität Verbesserung Entwicklungsprozess (Software-)Entwicklungsprozess umfasst (Software-)lebenszyklusabhängigen Anteil Analyse, Entwurf, Realisierung Lebenszyklusunabhängigen Anteil Planung, Kontrolle, Qualitätssicherung, Konfigurationsmanagement Organisationsspezifischen Anteil Prozess-Definition,-Bewertung, -Verbesserung, Ausbildung Projektmanagement M9 - Prozessverbesserung 362

360 Strukturierte Verbesserungsansätze Ziele: Bereitstellung systematisches Vorgehen Richtlinen für Prozesserfassung Metriken für Prozessbewertung Maßnahmen zur Prozessverbesserung Ansätze: EFQM (European Foundation of Quality Management) abstrakter, ganzheitlicher Ansatz, fragebogenbasiert CMM (Capability Maturity Model): Reifegradbasiert, assessmentorientiert BOOTSTRAP ähnlich CMM, detallierter, flexibler SPICE (Software Process Improvement and Capability determination) ähnlich CMM, ISO-basiert, integriert ISO 9000, detallierter, umfassender Projektmanagement M9 - Prozessverbesserung 363

361 ISO 9000 ff Qualitätsmanagementsystem ISO 9000 ff behandelt Qualitätsmanagement allgemein nicht nur für Software. Teil 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 365

362 ISO 9000 ff Praxisbeispiele Negativbeispiel: erschlichene Zertifizierung Positivbeispiel: Eine Firma hat ein funktionierendes, schlankes QMS Die 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 verankert Die bestandene Zertifizierung ist eine Belohnung, ein Lob über das sich alle freuen. Projektmanagement M9 - Prozessverbesserung 366

363 ISO 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-Plan Beim 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 enthält ein Qualitätsmodell, in der Praxis am wichtigsten sind die Qualitätsmerkmale (quality model for external and internal quality) Projektmanagement M9 - Prozessverbesserung 367

364 SW-Qualität nach ISO 9126 (Wiederholung) 6 Qualitätsmerkmale nach DIN ISO 9126 Funktionalitä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 erbringen Reife, Fehlertoleranz, Wiederherstellbarkeit Benutzbarkeit: Aufwand für Benutzung, Beurteilung von Benutzergruppen Verständlichkeit, Erlernbarkeit, Bedienbarkeit Effizienz: Verhältnis zwischen Leistungsniveau der SW und Umfang der eingesetzten Betriebsmittel Zeitverhalten, Verbrauchsverhalten Änderbarkeit: Aufwand für Korrekturen, Verbesserungen, Anpassungen Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit Übertragbarkeit: Eignung zur Übertragung in andere SW oder HW Umgebung Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit Projektmanagement M9 - Prozessverbesserung 368

365 CMMI Capability Maturity Model von 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: Idee: Software-CMM, Software Engineering-CMM, Integrated Product Development-CMM 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 369

366 Capability Maturity Model (CMM) Aufbau Ziel: Erhöhung der Qualität und Produktivität Reduktion des Risikos Verfahren: Stufenorientiert 5 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 Assessments Strukturierte 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 370

367 CMM Anspruch der Prozessverbesserung Level Ablauf abgedeckte Prozessbereiche (KPAs) 5 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. Wsk. ungerechtfertigt optimistische Planung Success depends on individual heroics. Ziel Zielgröße Projektmanagement M9 - Prozessverbesserung 371

368 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 372

369 CMM-Verbreitung (SEI 2006) Projektmanagement M9 - Prozessverbesserung 373

370 CMM und CMM-I Bewertung und Ausblick CMM war der erste systematische Ansatz zur Prozessverbesserung. Das CMM war aber in vielerlei Hinsicht unbefriedigend unvollständig teuer und langsam, daher nur für große Organisationen geeignet sehr 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 & ISO Die Nachfolgeversion von CCM ist Integriertes CMM (CMM-I), das sehr ähnlich zu ISO ist. Projektmanagement M9 - Prozessverbesserung 374

371 SPICE/ISO Ursprünge SW-CMM ISO ISO/IEC TR (SPICE) ISO S P I C d E oftware rocess mprovement & apability termination SPICE war ursprünglich eine Europäische Initiative, wird heute sehr stark in Australien und Japan vorangetrieben Projektmanagement M9 - Prozessverbesserung 375

372 SPICE/ISO Grundprinzipien Ansatz: Integration existierender Ansätze, z.b.: CMM ISO 9000 Verfahren: Bewertung des Entwicklungsprozesses durch Assessments Unterteilung in Prozess- und Reifegraddimension Unabhängige Bewertung der Prozessdimensionen Identifikation von Verbesserungsmöglichkeiten Projektmanagement M9 - Prozessverbesserung 376

373 SPICE/ISO Grundprinzipien Prüfung der im Unternehmen gelebten Prozesse gegen ein Prozessmodell Analyse der Stärken und Schwächen Erstellung von Verbesserungsvorschlägen Projektmanagement M9 - Prozessverbesserung 377

374 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 Prozess unabhängig von anderen Projektmanagement M9 - Prozessverbesserung 378

375 SPICE/ISO 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 Attribute Definiert für jeden Prozess Projektmanagement M9 - Prozessverbesserung 379

376 SPICE/ISO Prozesse Projektmanagement M9 - Prozessverbesserung 380

Projektmanagement: Projektorganisation

Projektmanagement: Projektorganisation Projektmanagement: Projektorganisation Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Unternehmensstrukturen und Projektstrukturen kennen lernen Einbinden

Mehr

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

Projektmanagement: Prozessmodelle und Projektorganisation

Projektmanagement: Prozessmodelle und Projektorganisation Projektmanagement: Prozessmodelle und Projektorganisation Martin Wirsing in Zusammenarbeit mit Andreas Schroeder Institut für Informatik Ludwig-Maximilians-Universität München WS 2008/09 Ziele Wichtige

Mehr

Projektmanagement: Einführung

Projektmanagement: Einführung Projektmanagement: Einführung Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Die Lehrenden Martin Wirsing Ordinarius für Informatik, LMU wirsing@lmu.de Tel.: 089-2180-9154

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Projektmanagement: Projektvorbereitung

Projektmanagement: Projektvorbereitung Projektmanagement: Projektvorbereitung Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Tätigkeiten der Projektvorbereitung kennen lernen 2 Projektverlauf

Mehr

Vorlesung Projektorganisation und Management

Vorlesung Projektorganisation und Management Vorlesung Projektorganisation und Management Dr. Bernhard Schätz Leopold-Franzens Universität Innsbruck Sommersemester 2003 B.Schätz - Projektmanagement 1 Übersicht 1. Übersicht 2. Projektmanagement und

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

IT-Projektmanagement - Methoden und Techniken

IT-Projektmanagement - Methoden und Techniken IT-Projektmanagement - Methoden und Techniken Seminarunterlage Version: 6.02 Version 6.02 vom 9. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Block E (SW-Prozess & Projektmanagement): Vorgehensmodelle 18.1.2005 1. Vorlesung Methoden des Software Engineering

Block E (SW-Prozess & Projektmanagement): Vorgehensmodelle 18.1.2005 1. Vorlesung Methoden des Software Engineering Block E (SW-Prozess & Projektmanagement): Vorgehensmodelle 18.1.2005 1 Vorlesung Methoden des Software Engineering Block E Software-Prozess und Projektmanagement Vorgehensmodelle Martin Wirsing Einheit

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Einführung in das Projektmanagement 1

Einführung in das Projektmanagement 1 Einführung in das Projektmanagement 1 Gliederung 1. Einführung und Grundlagen 1.1 Beispiele 1.2 Grundbegriffe und Definitionen 1.3 Erfolgsfaktoren des Projektmanagements 2. Projektorganisation 3. Projektphasen

Mehr

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Vortrag bei der Fachgruppe IT-Projektmanagement 22. Mai 2015, Steinbeis-Transferzentrum IT-Projektmanagement, Stuttgart hoffmann@stz-itpm.de

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Software-Projektmanagement

Software-Projektmanagement Software-Projektmanagement Björn Lohrmann Software Engineering Projekt Technische Universität Berlin WS 2007/2008 February 1, 2008 Software-Projektmanagement 1/29 Gliederung Gliederung des Vortrags: Begriffe

Mehr

POCKET POWER. Projektmanagement. 3. Auflage

POCKET POWER. Projektmanagement. 3. Auflage POCKET POWER Projektmanagement 3. Auflage 3 Inhalt 1 Einleitung.................................... 5 2 Grundlagen des Projektmanagements................... 8 2.1 Projektdefinition..............................

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Lehrplan: Projektmanagement

Lehrplan: Projektmanagement Lehrplan: Projektmanagement Tobias Brückmann Volker Gruhn Gliederung 1 Grundlagen der industriellen So?ware Entwicklung 2 Grundprinzipien und Aufgaben im Projektmanagement 3 Stakeholder- Management 4 Ziel-

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Semesterprojekt SS 2011

Semesterprojekt SS 2011 Semesterprojekt SS 2011 Projektmanagement Teil 1 Dr. rer. nat. Andreas Tewes Als Vorlage zu dieser Vorlesung diente: projektmanagement für newcomer RKW Sachsen GmbH Kompetenzzentrum Managementsysteme Selbst

Mehr

Vorlesung "Softwaretechnik" Buchkapitel 14 Projektmanagement (PM)

Vorlesung Softwaretechnik Buchkapitel 14 Projektmanagement (PM) Vorlesung "Softwaretechnik" Buchkapitel 14 Projektmanagement (PM) Lutz Prechelt Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ Was und wofür? Aufgabenfelder Integrierende

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Basiswissen Software- Projektmanagement

Basiswissen Software- Projektmanagement Bernd Hindel Klaus Hörmann Markus Müller «Jürgen Schmied Basiswissen Software- Projektmanagement Aus- und Weiterbildung zum Certified Professional for Project Management nach isqi-standard 2., überarbeitete

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Praxis-Handbuch Projektmanagement 00 / Inhaltsangabe

Praxis-Handbuch Projektmanagement 00 / Inhaltsangabe Praxis-Handbuch Projektmanagement Kapitel 01 - Einführung und Grundlagen Unternehmen im Wandel der Zeit Wandel der Organisation 01-03 Gründe für Projektmanagement 01-04 Projektdefinition Merkmale eines

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

IT-Projektmanagement Projektorganisation Kaiserslautern, WS 2007/2008 Dr. Gerhard Pews

IT-Projektmanagement Projektorganisation Kaiserslautern, WS 2007/2008 Dr. Gerhard Pews IT-Projektmanagement Projektorganisation Kaiserslautern, WS 2007/2008 Dr. Gerhard Pews AGENDA Umfeld: eines Unternehmens Projektorganisation Rollen im Projekt Ausgestaltung der Projektorganisation 2 Projektumfeld:

Mehr

Basiswissen Software-Projektmanagement

Basiswissen Software-Projektmanagement isql-reihe Basiswissen Software-Projektmanagement Aus- und Weiterbildung zum Certified Professional for Project Management nach isqi-standard von Bernd Hindel, Klaus Hörmann, Markus Müller, Jürgen Schmied

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

1/6/2008. Oliver Kühn

1/6/2008. Oliver Kühn PRAKTIKUM BERUFSAKADEMIE KARLSRUHE KLASSISCHES PROJEKTMANAGEMENT Oliver Kühn Vorstellung Dozent 2 Oliver Kühn 38 Jahre alt Dipl. Wirtschaftsingenieur (FH) Seit 11 Jahren Berufserfahrung im IT-Umfeld Mehrjährige

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Inhaltsverzeichnis. Abbildungsverzeichnis. Tabellenverzeichnis. Abkürzungsverzeichnis. 1 Überblick und Grundlagen 1

Inhaltsverzeichnis. Abbildungsverzeichnis. Tabellenverzeichnis. Abkürzungsverzeichnis. 1 Überblick und Grundlagen 1 Inhaltsverzeichnis Vorwort Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis VII XV XXI XXIII 1 Überblick und Grundlagen 1 1.1 IT-Projekte 3 1.1.1 Probleme bei IT-Projekten 3 1.1.2 Risiken

Mehr

(Management großer Softwareprojekte) Sommersemester 2007 Kap. 1 - Einführung

(Management großer Softwareprojekte) Sommersemester 2007 Kap. 1 - Einführung (Management großer Softwareprojekte) Sommersemester 2007 Kap. 1 - Einführung Prof. Dr. rer. nat. Uwe Aßmann Lehrstuhl Softwaretechnologie Fakultät Informatik TU Dresden Version 07-0.6, April 11, 2007 [1]

Mehr

Sanierung von IT-Projekten

Sanierung von IT-Projekten Sanierung von IT-Projekten Präsentation zur Vorlesung Juristisches IT-Projektmanagement bei Dr. Frank Sarre im Wintersemester 2013/2014 Ludwig-Maximilians-Universität München Folie 1 Agenda Motivation

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Kapitel 2: Projektmanagement Umsetzung

Kapitel 2: Projektmanagement Umsetzung 1. Projektmanagement-System 2. Projektphasen 3. Aufbauorganisation 4. Menschen im Projekt und ihre Rollen 5. Excurs: Gruppendynamik 6. Methoden und Werkzeuge Dr. Ulrich Meyer 22 Kapitel 2: PM-Umsetzung

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Raphael Leiteritz, raphael@leiteritz.com, 22. April 2002 1 Inhalt 1 Was

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

1 Phase «Initialisierung»

1 Phase «Initialisierung» 1.1 Übersicht Projektanmeldung Projektportfolio Projektrandbedingungen Projekt vorbereiten Projektantrag Projekthandbuch Projektplan Zurückweisung Projektauftrag Projektportfolio Status Abbruch Phase Voranalyse

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Übungen zu Projektorganisation und Management in der Software-Entwicklung

Übungen zu Projektorganisation und Management in der Software-Entwicklung Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 1 Dr. H. Ehler, S. Wagner 06. Mai 2004 Übungen zu Projektorganisation und Management in der Software-Entwicklung Aufgabe 1 Prozessmodell und Projektorganisation

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

IT-Projektmanagement Steuerung Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews

IT-Projektmanagement Steuerung Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews IT-Projektmanagement Steuerung Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews Der Fahrplan durch die Vorlesung Inhalte Einführung Das Was : Der Gegenstand von Softwareprojekten Das Wie : Die Tätigkeiten

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Softwarepraktikum. Gernot A. Fink SS 2005

Softwarepraktikum. Gernot A. Fink SS 2005 Softwarepraktikum Gernot A. Fink SS 2005 Einführung Wichtige Grundbegriffe Was ist Softwareengineering? Software- und Projektentwicklung Anfordernugen and Softwareentwicklung Softwareprozesse und Vorgehensmodelle

Mehr

Semester: -- Workload: 150 h ECTS Punkte: 5

Semester: -- Workload: 150 h ECTS Punkte: 5 Modulbezeichnung: Modulnummer: IPMG IT-Projektmanagement Semester: -- Dauer: Minimaldauer 1 Semester Modultyp: Pflicht Regulär angeboten im: WS, SS Workload: 150 h ECTS Punkte: 5 Zugangsvoraussetzungen:

Mehr

Agiles Projektmanagement

Agiles Projektmanagement Agiles Projektmanagement A B U S I N E S S P E R S P E C T I V E Christian Setzwein Agenda Rahmenbedingungen für Projekte Der Umgang mit Unsicherheit im klassischen PM Agiles PM: Techniken, Prinzipien,

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis Leseprobe Joachim Drees, Conny Lang, Marita Schöps Praxisleitfaden Projektmanagement Tipps, Tools und Tricks aus der Praxis für die Praxis ISBN: 978-3-446-42183-7 Weitere Informationen oder Bestellungen

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

Projektmanagement in Vorarlberg. Einleitung

Projektmanagement in Vorarlberg. Einleitung Zusammenfassung der Studienergebnisse Projektmanagement in Vorarlberg Entwicklungsstand im Projektmanagement am Beispiel der Vorarlberger Wirtschaft Kooperationspartner Einleitung Die Anforderungen an

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete)

Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) 5. Projektplanung und -verfolgung Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm Ressourcenverwaltung Projektverfolgung 112 Vor dem Projektstart Bevor die eigentliche

Mehr

Vor dem Projektstart. 5. Projektplanung und -verfolgung. Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm

Vor dem Projektstart. 5. Projektplanung und -verfolgung. Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm 5. Projektplanung und -verfolgung Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm Ressourcenverwaltung Projektverfolgung Vor dem Projektstart Bevor die eigentliche

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Multi-Projektmanagement. Stand: Januar 2012

Multi-Projektmanagement. Stand: Januar 2012 Multi-Projektmanagement als Teil der Unternehmenssteuerung Stand: Januar 2012 ButzConsult: Die Optimierungsberater Optimierung ist unser Ziel Beratung unsere Leidenschaft Stefan Butz Geschäftsführender

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Bernd Oestereich (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Christian Weiss (Geschäftsführer) Copyright by oose GmbH 2006 Das Wasserfallmodell ein historisches Mißverständnis. Der Wasserfallprozess-

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Vorlesung Methoden des Software Engineering. Martin Wirsing. Einheit E.1, 22.1.2007

Vorlesung Methoden des Software Engineering. Martin Wirsing. Einheit E.1, 22.1.2007 Block E (SW-Prozess & Projektmanagement): Vorgehensmodelle 22.1.2007 1 Vorlesung Methoden des Software Engineering Block E Software-Prozess und Projektmanagement Vorgehensmodelle Martin Wirsing Einheit

Mehr

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Oktober 2014 PRODUKTENTWICKLUNG. Dr. Ralf Lauterbach

Oktober 2014 PRODUKTENTWICKLUNG. Dr. Ralf Lauterbach PRODUKTENTWICKLUNG Dr. Ralf Lauterbach Produktentwicklung digitaler Produkte - was ist zu tun? - Generelle Aufgaben bei jeder digitalen Produktentwicklung Produktmanagement Marktanalysen Markteingangsstrategie

Mehr

Projektmanagement. Inhalts- und Umfangsmanagement. Version: 2.0 Stand: 09.04.2015

Projektmanagement. Inhalts- und Umfangsmanagement. Version: 2.0 Stand: 09.04.2015 Projektmanagement Inhalts- und Umfangsmanagement Version: 2.0 Stand: 09.04.2015 Lernziel Sie können die Ziele des Inhalts- und Umfangsmanagements in Projekten nennen. Sie können erklären wie Anforderung

Mehr

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Stakeholder Management

Stakeholder Management Stakeholder Management Bruno Jenny Partner für Projekt und Portfoliomanagement Aktives Betreiben von Stakeholder Management Wird aktiv Stakeholder Management in den Projekten betrieben? Manchmal 42 % 34

Mehr

Projekt Rollenbeschreibung

Projekt Rollenbeschreibung Projekt Rollenbeschreibung Projektrolle Projektauftraggeber (PAG): Projektbezogene Wahrnehmung der Unternehmensinteressen Beauftragung und Unterstützung des Projektteams Führung des/der Projektleiters/in

Mehr

Prüfung eines Migrationsprojekts

Prüfung eines Migrationsprojekts Prüfung eines Migrationsprojekts Peter Ursprung Ursprung Consulting Postfach 8042 Zürich 044 361 12 21 peter.ursprung@bluewin.ch 1 Inhalt Interdisziplinarität von in IT-Projekten Welche Kompetenzen sind

Mehr

Aspekte zur Vorgehensweise bei Planung & Einführung eines SDM-Systems

Aspekte zur Vorgehensweise bei Planung & Einführung eines SDM-Systems Aspekte zur Vorgehensweise bei Planung & Einführung eines SDM-Systems Martin Liebscher DYNAmore GmbH Stuttgart, 2. Juli 2013 1 Überblick Phasen der Softwareentwicklung / -beschaffung Anforderungsanalyse

Mehr

Management großer Projekte Ein modellbasierter Ansatz

Management großer Projekte Ein modellbasierter Ansatz Management großer Projekte Ein modellbasierter Ansatz Dr. Dehla Sokenou Herausforderungen des Projektmanagements Projekt Initialisierung Aufgaben sinnvoll planen/partitionieren Projekt Monitoring Arbeitsergebnisse/Status

Mehr

IT-Projektmanagement - Methoden und Techniken

IT-Projektmanagement - Methoden und Techniken IT-Projektmanagement - Methoden und Techniken Seminarunterlage Version: 5.01 Version 5.01 vom 11. Juni 2013 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

IT-Projektmanagement Teil 2: Der Gegenstand von Softwareprojekten. Wintersemester 2012/2013 Dr. Gerhard Pews

IT-Projektmanagement Teil 2: Der Gegenstand von Softwareprojekten. Wintersemester 2012/2013 Dr. Gerhard Pews IT-Projektmanagement Teil 2: Der Gegenstand von Softwareprojekten Wintersemester 2012/2013 Dr. Gerhard Pews Dieser Vorlesungsteil vertieft den Gegenstand von Softwareprojekten. Einordnung in den Fahrplan

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

Vorlesung am 18.11.2008. Projektmanagement. Dr. F. Sarre Wintersemester 2008 / 2009. Folie 114

Vorlesung am 18.11.2008. Projektmanagement. Dr. F. Sarre Wintersemester 2008 / 2009. Folie 114 Vorlesung am 18.11.2008 Projektmanagement Folie 114 Projektmanagement Was umfasst Projektmanagement? Organisation, Planung und die Steuerung von (IT-) Projekten Führungsaufgaben Teilprojektleitung Steuerung

Mehr

Übungsaufgaben zum Lerntransfer. Projektmanagement

Übungsaufgaben zum Lerntransfer. Projektmanagement Übungsaufgaben zum Lerntransfer Projektmanagement 1. Welche 4 Merkmale charakterisieren ein Projekt? Vorhaben Zeitlich befristet Einmalig Komplex 2. Wie ist der Begriff Projekt definiert? Vorhaben, das

Mehr

A B C D E F & # + ", 12,", $("& 6 & )& %, )& H " 4 7&" < Beteiligte/Betroffene Management Projektleiter Mitarbeiter. Kunde.

A B C D E F & # + , 12,, $(& 6 & )& %, )& H  4 7& < Beteiligte/Betroffene Management Projektleiter Mitarbeiter. Kunde. 0,!" ' #$%&& & # ",!" -.&, / Rahmen A B C D E F Anforderungen Architektur Formale Methoden Test, Validation, Verifikation Prozeß Web-Engineering Grundlagen und Überblick Verbreitete Vorgehensmodelle Prozesseinführung

Mehr

GPM/IPMA Zertifizierung ICB 3.0 Fragen zur Prüfungsvorbereitung (PM3, Auflage 1) Kapitel 3.02

GPM/IPMA Zertifizierung ICB 3.0 Fragen zur Prüfungsvorbereitung (PM3, Auflage 1) Kapitel 3.02 Was ist ein Programm? Ein Programm ist eine Menge von Projekten, die miteinander verknüpft sind und ein gemeinsames übergreifendes Ziel verfolgen. Ein Programm ist zeitlich befristet. Es endet spätestens

Mehr

Multiprojektmanagement an der TIB Ein Erfahrungsbericht. Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015

Multiprojektmanagement an der TIB Ein Erfahrungsbericht. Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015 Multiprojektmanagement an der TIB Ein Erfahrungsbericht Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015 Motivation Die Ausgangssituation Das Umfeld von Bibliotheken befindet sich im

Mehr

IT-Projektrichtlinie für die Fachhochschule Kiel

IT-Projektrichtlinie für die Fachhochschule Kiel IT-Projektrichtlinie für die Fachhochschule Kiel Version 1.0 Stand: 05. September 2012 mit Präsidiumsbeschluss der Fachhochschule Kiel vom 05.09.2012 IT-Projektrichtlinie Inhaltsverzeichnis Inhaltsverzeichnis

Mehr

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit.

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit. Mi 2.3 Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases Tom Krauß Agenda Motivation Use Case orientiertes Projektmanagement Grundsätzliche Idee Variationsmöglichkeiten Integration in

Mehr

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen E-Mail : Berkan.Kutlutuerk@hs-furtwangen.de Seite

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

Multiproj ektmanagement

Multiproj ektmanagement Jörg Seidl Multiproj ektmanagement Übergreifende Steuerung von Mehrprojektsituation^n^durch Projektportfolio- und Programmmanagement vq. Springer Inhaltsverzeichnis 1 Einführung und Grundlagen 1 1.1 Projektmanagement

Mehr

Projektmanagement einführen und etablieren

Projektmanagement einführen und etablieren Projektmanagement einführen und etablieren Erfolgreiches und professionelles Projektmanagement zeichnet sich durch eine bewusste und situative Auswahl relevanter Methoden und Strategien aus. Das Unternehmen

Mehr

Internet Briefing Agile SW-Entwicklung

Internet Briefing Agile SW-Entwicklung 1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com

Mehr