Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Methoden des SW-Projektmanagements

Ähnliche Präsentationen


Präsentation zum Thema: "Methoden des SW-Projektmanagements"—  Präsentation transkript:

1 Methoden des SW-Projektmanagements
Warum? ok Was? 1.Tag: Motivation, Definition u. Abgrenzung Projektmanagement 2.Tag: Projektphasen u. Managementregelkreis 3.Tag: Techniken für Vorbereitung u. Initiierung 4.Tag: Techniken für Planung, Steuerung u. Abschluss 5.Tag: Tipps u. Wiederholung Wie? Wann? Initiating Planning Controlling Executing Closing Methoden des SW-Projektmanagements

2 Warum Projektmanagement?
Was ist PM? Wer hat schon in IT-Projekten mitgearbeitet? Wer hat schon IT-Projekte geleitet? Welche Projekte haben Sie schon geleitet? Was ist die Konsequenz ohne PM? ohne Planung keine Steuerung ohne Steuerung keine Kostenkontrolle Ist PM immer nötig? Lohnt sich PM? 1. Einführung Motivation Definition Abgrenzung Regelkreis 2. PM in IT 3. Techniken I 4. Techniken II 5. Kontrolle PM ist die Strukturierung, Planung und Steuerung von komplexen Aufgabenstellungen. Ein Projekt ohne Steuerung, ist wie ein Schiff ohne Kapitän. PM ist nicht für alle Tätigkeiten nötig. Der Kapitän ist z.B. kein Projektmanager! Methoden des SW-Projektmanagements 2

3 Wie nötig ist Projektmanagement?
Methoden des SW-Projektmanagements 3

4 Gründe für das Scheitern..
1. unvollständige Anforderungen 13,1% 2. fehlender Userinput 12,4% 3. nicht genügend Ressourcen 10,6% 4. unrealistische Erwartungen 9,9% 5. keine Unterstützung durch das Management 9,3% 6. Änderung der Anforderungen 8,7% 7. keine Planung 8,1% 8. nicht mehr benötigt 7,5% 9. kein Management 6,2% 10. unbekannte und unreife Technologie 4,3%   andere 9,9% 44,1% 14,3% 10,6% 43% Anforderungen 14% PM 11% keine Resourcen 9% keine Unterstützung Report der Standish Group über 365 Firmen und ca Projekte in US [Chaos1995] Methoden des SW-Projektmanagements 4

5 Projektdefinition Definition Projekt nach DIN 69901:
Ein Vorhaben, das im wesentlichen durch Einmaligkeit in seiner Gesamtheit gekennzeichnet ist bezogen auf: die Zielvorgaben (Qualität, Kosten, Termin) die Begrenzungen (zeitlich, finanziell, personell) die Organisationsform (projektspezifische Rollen) die Abgrenzung gegenüber anderen Vorhaben (komplexe Aufgabenstellung) . Praktische Definition: Ein Projekt ist ein Vorhaben, das in vorgegebener Zeit und beschränktem Aufwand ein bestimmtes Ziel erreichen soll Anmerkungen: Ein Projekt braucht ein Ziel, damit die Zielvorgaben (auch Q-Ziele oder Magisches Dreieck) sinnvoll sind. Zielvorgaben werden häufig gegenüber dem Kunden kommuniziert und vereinbart. Die Begrenzungen stellen eher die interne Sicht der beschränkten Ressourcen dar. Projekte müssen nicht immer wirtschaftlich sein, sondern gelten oft als Investition beim Kunden. Für den Kunden ist es ein Projekt - für den Berater ein Auftrag. Die Projektmitarbeiter haben oft zwei Chefs (Linie und PM), dies ist ein ständiger Konflikt. Die Zusammenarbeit verschiedener Abteilungen in einem Projekt wird oft durch die „interdisziplinäre“ Aufgabenstellung nötig. Ein Projekt stellt oft eine besondere Herausforderung dar und hat erhöhte Risiken (kein Standard-Prozess oder bekannter Erstellungsprozess) Oft ist in einem Projekt ein Scheitern eingeplant, Projekt als Vorstudie, als Pilot. Die Abgrenzung wird gemacht, weil dadurch die Besonderheiten im PM und die Konflikte und Nöte eines PL klar werden. Die bloße Organisationsform oder eine Abgrenzung gegenüber anderen Vorhaben wird meist als nicht ausreichend für die Klassifizierung als Projekt angesehen. Hier spricht man eher von Aufträgen oder Aufgaben. z.B.: Vorbereiten eines Raumes - Vorbereiten einer Veranstaltung Erstellung einer Präsentation - Erstellung einer Studie Projekte sind Vorhaben mit großem Risiko (Neuheit, Neues Team, Neue Methode) Hängen viele Projekte miteinander zusammen, so heißt die Gesamtheit „Programm“. Mit steigender Anzahl und Komplexität werden aus: Aufgaben -> Projekte -> Programme Trotzdem können viele der Prinzipien des PM auf alle drei Klassen angewandt werden! Normen: DIN 69901, PMBOK*, ICB**, PMF *** *Die Grundbedeutung von "Project Management Body of Knowledge" ist zunächst das gesamte Wissen und der gesamte Erfahrungsschatz aller Projektmanager(innen) weltweit. Nachdem dieses Abstraktum schwer zu greifen ist, bemüht sich das Project Management Institute (PMI, Pennsylvania, USA), den "Common Ground" dieses PMBoK in seiner Veröffentlichung "A Guide to the Project Management Body of Knowledge" zusammenzustellen und wiederum allen Projektmanager(innen) an die Hand zu geben. (http://www.projektmagazin.de/glossar/) ** International Competence Baseline (http://gpm-ipma.de/index.html) *** Project management Framework (http://www.its.qut.edu.au/pp/framework/) Methoden des SW-Projektmanagements 5

6 Definitionscheck Sind das Projekte? Brief schreiben
Hausbau planen (Bauherr) Hausbau planen (Planungsfirma) SW-Entwicklung (AG) SW-Entwicklung (AN) Projektdefinition: Einmaligkeit (ID) Ziel (QKT) Begrenzung (?) Spezielles Team Abgrenzung Brief schreiben : ID der Instanz, aber immer wiederkehrende Tätigkeit / K – im Rahmen der Tätigkeit / keine Schwierigkeit /selbst / nein Hausbau (S) : Einmalig i.d.R./ Ziele sind klar/ Schwierig/ Handwerker+Architekten/ von allem abgegrenzt Hausbau (F) : Instanz ja, aber immer wiederkehrende Tätigkeit (Kundenprojekt)/ Ziele klar/ nicht komplex/ bekanntes Team/ Buchhalterisch getrennt, aber für Leute oft nicht (gemeinsame Ressourcen) SWE (AG) : einmalige Instanz, kann öfters vorkommen/ Ziele klar/ nicht mit eignen Mittel machbar/ Team beauftragen/ eigenes Projekt SWE (AN) : einmalige Instanz, immer wiederkehrende Tätigkeit im Prinzip/ Ziele klar/ kann komplex sein / gleiches Team, aber andere Kunden / eigenes Projekt Es gibt unterschiedliche Projektarten: Forschungsprojekt: meist unklares Ziel oder unklare Vorgehensweise, viel Kreativität, große Planungsunsicherheit Entwicklungsprojekt: Klare Ziele, bekannte Vorgehensweise, geringe Unsicherheiten Projektierungsprojekte: Montage aus vorhandenen Bausteinen Vertriebsprojekte: Koordination und Vertragsmanagement Betreuungsprojekt: Wartung und Anwenderunterstützung (kein klares Ende, daher kein Projekt) Methoden des SW-Projektmanagements 6

7 :) Alternative Definition
Ein Projekt ist .... ein unsichtbarer Parasit, der Geld und Leute verschlingt eine Gelegenheit für gelangweilte Manager sich in Meetings zu treffen ein bürokratisches Monster, dass große Mengen Papier ausspeit eine Ausrede etwas nicht zu tun, was zu seinen Aufgaben gehört hätte ein Oxymoron Methoden des SW-Projektmanagements 7

8 Komplexität der IT-Projekte
LOC Fehlertolerantes verteiltes Betriebssystem 21.538 Textverarbeitung in ADA 38.732 Flugabwehrraketen Simulator für die AIR FORCE 40.000 SHIP 2000 für die schwedische Marine 55.000 Cabin Management System für Boeing 777 in ADA 70.000 ADA Cross Compiler für Z80 Mikroprozessoren 80.000 Static Analyser für ADA Source Code Bahnverfolgung von Satelliten für die NASA Grapical Kernel System (GKS) in ADA Sprachübersetzter von COBOL und FORTRAN in ADA Steuerungssystem der amerikanischen Raumfähre Steuerungssoftware Stahlwalzwerk Airplan Information Management System für Boeing 777 Flugkontrolle Luftraum über Spanien Flugkontrolle der amerikanischen FAA Kernkraftwerkssteuerung Frankreich in ADA Buchhaltungssoftware US -Armee Software Boeing 777 größtenteils in ADA Software für Advanced Tactical Figther der US-Air-Force Windows NT 4.0 Methoden des SW-Projektmanagements 8

9 Mehrdimensionale Komplexität
Kompetenzen eines Projektleiters Komplexität der Aufgaben Soziale Kompetenz Fachliche Management Routine- projekt Potential- Multi- Pionier- soziale Komplexität Aufgabe Manage- ment fachliche Komplexität Managementkompetenz Planungskompetenz Problemlösekompetenz Methodenkenntnis Wirtschaftlichkeitsdenken Zeitmanagement Organisationstalent Sozialkompetenz Mitarbeiter führen und motivieren Teamarbeit fördern Kommunikative Kompetenz in Einzel- und Gruppengesprächen, Verhandlungen,Präsentationen Kooperationsbereitschaft Konfliktlösekompetenz Fachliche Kompetenz Kenntnis der betroffenen Bereiche und der Schnittstellen Kenntnis der Unternehmensstrategie und des Umfelds Softwarekenntnisse Abstraktes Denkvermögen Methoden des SW-Projektmanagements 9

10 Fachliche Komplexität von IuK
Metallgewerbe Holzgewerbe Textilgewerbe Papiergewerbe Gummi und Kunststoffe Keramische Industrie Chemische Industrie T-Markt (Fernmeldedienst) Elektrizität und –verteilung Verlags-, Druckgewerbe RF-, Fernsehtechnik Büromaschinen, EDV Kraftwagen und –teile Luft- und Raumfahrt Ernährungsgewerbe Maschinenbau Branchen IT-Branche SW Tools, Methodik, Treiber, OS, Architektur Technik HW Server, Chips, Standards, Busse, Power, Karten, Kabel Netze Protokolle, Hubs, Router, Kabel, Gateways Methoden des SW-Projektmanagements 10

11 Phasen im Life-cycle einer SW
Planung/Studie Design Entwicklung Anpassung Wartung Ein Projekt kann sich auf eine oder mehrere Phasen erstrecken. Im Lifecycle einer SW fallen verschiedene Phasen an. Ein Projekt kann sich über eine oder mehrere Phasen erstrecken! Methoden des SW-Projektmanagements 11

12 Vergleich: Lösungsprozesse
Analyse Stoffsammlung Betrieb Print/Vermarktung Grobkonzept Gliederung, Story Abnahme Druckfahnen Fachkonzept Kurzbeschreibung Integration Gesamtreview DV-Konzept Layout, Handl.-stränge Komponententest Kapitelweise Review Phasenmodell Systemplanung ·      Problemanalyse (Vorstudie, Ist-Aufnahme (Erhebung des gegenwärtigen Zustandes), Schwachstellenanalyse (Auswertung der IST-Aufnahme) ·      Anforderungsanalyse (grob: Aufgabendefinition): Lastenheft (Anforderungskatalog) Vorwiegend verbale (qualitative) Beschreibung der noch nicht auf Realisierbarkeit geprüften Kundenanforderungen. ·      Fachkonzept (Pflichtenhefterstellung, Gesamt-aufwand, Konzept fachlich) ·     DV-Konzept (Design DV-technisch) Systemimplementierung (=Realisierung) ·      technische Implementierung ·      organisatorische Implementierung ·     Test ·     Integration und Integrationstest Systembetrieb ·      laufender Betrieb ·      Wartung Implementierung Rohversionen Methoden des SW-Projektmanagements 12

13 Entwicklungsphasen Methoden des SW-Projektmanagements 13
Problemanalyse Anforderung System-entwurf Design Implemen-tierung Integration Systemtest Gegen-stand Organisation, Geschäft Geschäft, DV als Black Box DV DV+Benutzer Ergebnis Ist-Analyse Schwachstellenanalyse Rahmen-bedingung Anforderungen (Vorstudie) Grobkonzept, Machbarkeit Alternativen Anfor-derungen (Lastenheft Anforderungs-katalog) Fachkonzept IT-Services Architektur Ablauf/ Prozesse Use Case Datenmodell Protoyp Q-Anfor-derungen (Pflichtenheft Spezifikation) DV-Konzept Komponenten Schnitt-stellen DV-Modelle (Design IT-Spezifkation) Code Datenbankschema Migration Klassen kodieren Code-Review Programm Installationsroutine Installation beim Kunden Test Test-Strategie Test- Spezifikation Test-Daten Test-Drehbuch Testbench, Testengine Testengine codieren Testen Lasttest Sicherheits-test Abnahme Methoden des SW-Projektmanagements 13

14 Auftraggeber-Auftragnehmer
AN Vertrag Kunde Vorgesetzter -Mitarbeiter Dienstleister Projekte haben in der Regel einen größeren Rahmen und eine Vorgeschichte. Der größere Rahmen vererbt sich rekursiv nach unten. Projekte haben einen größeren Rahmen... Methoden des SW-Projektmanagements 14

15 Projekt + Management Projekt Management einmalig planen komplex
begrenzt (TQK) Management planen überwachen steuern organisieren Projektmanagement Methoden zur Bearbeitung von Projekten Leitungsaufgaben Organisationskonzepte Um die Komplexität und die Mannigfaltigkeit der Projekte zu managen, kann man nicht alle speziellen Templates, Phasen und Prozessmodelle schulen. Stattdessen werden die Prinzipien, Methoden und Techniken geschult. Diese Prinzipien müssen sie auf alle anfallenden Situation anwenden. Dazu müssen Sie die Prinzipien wirklich gut verstehen! Methoden des SW-Projektmanagements 15

16 Projektmanagement Definition Projektorganisation (DIN 69901):
Gestaltung von projektbezogenen Regelungen. Definition Projektmanagement (DIN 69901): Gesamtheit von Führungsaufgaben, -organisation, -techniken und –mittel für die Abwicklung eines Projektes. Praktische Definition: "Getting Things Done." oder „Die Kunst ein guter Projektleiter zu sein“ Projekt- ziele Projekt- rollen Projekt- ablauf Projekt- planung Projekt- führung Projekt- steuerung Anmerkungen: Projektleitung ist die Organisation und der Projektleiter ist der Verantwortliche der Projektleitung. Projektleiter = Projektmanager = Projektkoordinator Projektmanagement beschreibt die Tätigkeit, Aufgabe und die Methodik des Projektleiters. „Gettings Things Done“, heißt nicht „unreflektierten Loslegen“, sondern, soll aussagen „Management nicht als Selbstzweck“, d.h. Ziel ist es das Ergebnis in Q, in T, in K zu liefern oder anders ausgedrückt: Der Planungsaufwand muss durch die Reduktion an Durchführungsaufwand ausgeglichen werden. Methoden des SW-Projektmanagements 16

17 Selbsttest Wer hat schon einmal ein Programm geschrieben? alleine
ohne Design ohne Zeitplan hat es funktioniert? 1. Warum stellt der Kursleiter die Frage? - will die Erwartungen der Teilnehmer kennen lernen und mit seinen Inhalten abstimmen (braucht Liste, die er mit nachhause nehmen kann) - will die Erwartungen zu den vorbereiteten Themen gruppieren und kommentieren (braucht Post-It, die er auf vorbereites FlipChart klebt) - will eine Pause von 5 min (egal was rauskommt) - will eine Lektion erteilen (braucht AHA-Effekt) 2. Was ist das Ergebnis? - einer trägt eine Liste vor - Gruppe bereitet FlipChart vor - jeder hat sich Gedanken gemacht - gewichtete Liste der Erwartungen 3. Wie gehen wir vor? - jeder für sich - es werden 3 Gruppen gebildet - es gibt einen Moderator und einen Sprecher - es werden zuerst Themen aufgelistet und darunter Erwartungen einsortiert als Beispiel - es wird abgestimmt, in welcher Reihenfolge (Wichtung, logische Reihenfolge) die Erwartung präsentiert werden 4. Wann haben wir was? - Zwischenergebnisse, z.B. Klärung Vorgehen, Brainstorming Liste, Präsentations Chart 5. Durchführung 6. Kontrolle -> geht nur, wenn wir Zwischenergebnisse definiert haben, sonst sehen wir erst am Ende, ob wir es geschafft haben oder nicht. -> gut ist es das Risiko „Zeit reicht nicht!“ parallel zu planen. Alternativplan erstellen, Notfall-Lösung, Paralleles Arbeiten... AHA-Effekt: Projektmanagement wurde erfunden für das Management von Projekten, d.h. von schwierigen weil einmaligen Vorgängen, z.B. Mondlandung, Bau der Pyramide. Projektmanagement ist eine Kunst für Fortgeschrittene. Techniken des Projektmanagements können jedoch von JEDEM und für jede AUFGABE eingesetzt werden. Die Verwendung von Projektmanagement-Techniken erfordert keinen großen Extraaufwand, sondern nur Nachdenken bevor man Losstürmt: - warum? - was? - wie? - wann? Methoden des SW-Projektmanagements 17

18 Problem der Skalierung
kann von einer Person gebaut werden minimaler Plan einfacher Prozess einfache Werkzeuge erfordert ein Team mit unterschiedlicher Ausbildung Vielzahl von Plänen detaillierter Plan komplexe Modelle knappe Ressourcen Methoden des SW-Projektmanagements 18

19 Historie des PM Do Check Do Plan (Design) Check CMM-Level 1:
Idee Code CMM-Level 1: undefiniert Erfolg = Leistung von Helden CMM-Level 2: wiederholbar geplant und dokumentiert Erfolg durch PM CMM (Capability maturity Model) Reifegradmodell Idee Code Design Do Check Plan (Design) Do-Check: typische ein-Mann Projekte, nur Endkontrolle möglich Plan-Do-Check: immer nötig, wenn mehrere Personen beteiligt und wenn Design wieder verwendet wird. Es gibt Meilensteine und Meilensteinergebnisse! Absicherung der Unsicherheit durch Zwischenabnahme und Zwischenkontrolle! Nötig, wenn der Zielzustand am Anfang noch nicht genau beschrieben werden kann und nach dem Meilenstein eine Entscheidung benötigt wird. Methoden des SW-Projektmanagements 19

20 Shewhart Cycle or the Deming Cycle
Analyse Plan (design) Do Check Act (decide) “think first, then do” PLAN: Plane und Entwerfe eine Änderung DO: Setze die Änderung um CHECK: Bewerte die Wirksamkeit der Änderung ACT: Entscheide welche Änderung nötig ist (Analyse, Zielkriterien, Alternativen, Entscheidung) W. Edwards Deming in the 1950's proposed that business processes should be analyzed and measured to identify sources of variations that cause products to deviate from customer requirements. He recommended that business processes be placed in a continuous feedback loop so that managers can identify and change the parts of the process that need improvements. As a teacher, Deming created a (rather oversimplified) diagram to illustrate this continuous process, commonly known as the PDCA cycle for Plan, Do, Check, Act* In Japan heisst der PDCA-Cycle Hoshin Kanri : Hoshin Kanri can be thought of as the application of Deming's Plan-Do-Check-Act (PDCA) cycle to the management process. The PDCA cycle represents a generic approach to continual improvement of activities and processes. IN THE 'PLAN' STEP, a plan of action is developed to address a problem. Corresponding control points and control parameters are created. The plan is reviewed and agreed. planning documents, once finalized, are kept alive and acted on daily, and not shelved as soon as they have been completed. IN THE 'DO' STEP, the plan is implemented. IN THE 'CHECK' STEP, information is collected on the control parameters. The actual results are compared to the expected results. IN THE 'ACT' STEP, the results are analyzed. Causes of any differences between expected and actual results are identified, discussed and agreed. Corrective action is identified. The intention is that, in companies using Hoshin Kanri, everybody is aware of management's vision, departments don't compete against each other, projects run to successful conclusions, business is seen as a set of coordinated processes. The PDCA cycle was in fact originally developed by Walter A, Shewhart, a Bell Laboratories scientist who was Deming's friend and mentor, and the developer of Statistical Process Control (SPC) in the late 1920s.  So sometimes this is referred to as the "Shewhart Cycle".  There are also several recent variations on this concept.   See The Man Who Discovered Quality by A. Gabor, Penguin Books, 1990. GTZ ZOPP (An Introduction to the Method). Eschborn, Germany Methoden des SW-Projektmanagements 20

21 Managementregelkreis
Analyse Projekt Kontrolle Lösungs- Strategie Durch- führung Warum? Was? ok? Wie? Tun! Wann? Planung Ziel- Definition Anmerkungen: 1. Ist Analyse (Warum) Das erste Warum ist oft trivial, z.B. weil unser Lehrer das gesagt hat. Weil wir jedes Jahr in den Urlaub fahren. Ziel der Frage: Motivation des Kunden verstehen. Tipp: Kunden denken oft in Entscheidungen und benötigen dazu Informationen (Ergebnisse). 2. Ziel Definition (was) Das Ziel lässt sich auf 3 Arten beschreiben: a) Vision des Endzustands (Sehnsucht nach dem Meer, Sicherheit, Ruhe / erholt, braun, glücklich); -> durch Ist-Analyse b) Ergebnisse (Haus mit Garten, 5 Zimmer, etc. / Sonne, Strand ..) > Produktstruktur c) Arbeitsanweisung (do-it-yourself Bausatz / organisierte Tour) > durch Strategie Hier ist das Ergebnis im Sinne von versprochener Leistung oder versprochenen Lieferprodukten gedacht (Deliverables) Ziel der Frage: Was soll abgenommen werden? Wann habe ich einen guten Job gemacht? Problem: Oft sind viele Zielerwartungen implizit, z.B. Windows-like, so gut wie was wir schon haben... 3. Lösungsstrategie (wie) Bei Standardentwicklungen vorgegeben (Software Entwicklungsmethoden). Muss jedoch angepasst werden. Bei neuen, einzigartigen Projekten noch offen!! z.B. Haus bauen, bauen lassen, mieten? Urlaub an einem Ort? zusammen? Kreativer Prozess mit Lösungsvarianten, die anschließend bewertet werden und zu einer Entscheidung führen. (Gründe der Entscheidung = Teil der Motivation!) Ziel des Schritts: Methode finden, nach der geplant und vorgegangen wird. 4. Planung (wann) Viele Techniken der Planung. Wichtige Aufgabe am Anfang: was Du nicht planst, kannst Du nicht kontrollieren! Ziel des Schritts: Definition von Arbeitspakete = überschaubare Aufgaben für eine verantwortliche Person (Teilprojekt!) 5. Durchführung (tun) Jeder Projektmitarbeiter soll möglichst ungestört (!) seine Aufgabe erledigen können. -> SPU ist ok, keine Konflikte mit Linienorganisation, keine Zusatzaufgaben durch den Auftraggeber, klare Vorgaben, klare Projektorganisation 6. Projektkontrolle (ok) Regelmäßige Meetings für: - Projektfortschritt (Ergebnisse, verbrauchte Zeit, geschätzte Restzeit) - Probleme die 5. beeinflussen an PL abgeben - Interne Abstimmung (Koordination, evtl. veränderte Planung) - Risikomanagement an PL melden (evtl. veränderte Methode und neuer Plan) - Stimmung und Wir-Gefühl stärken Ziel der Kontrolle: „Getting Things done“, keine Schuldzuweisung, sondern Projekt erfolgreich durchführen. Jeder Projektmitarbeiter hat mitzuhelfen: - Stundenaufschreibung - Meldung von Störungen - nicht automatisch selbst lösen! - Meldung von Risiken - Ehrlichkeit (sich selbst gegenüber = realistisch) in den Schätzungen - Änderungen in seinen Schnittstellen, Planung, etc. aktiv kommunizieren und absegnen lassen. Methoden des SW-Projektmanagements 21

22 1. Übungsaufgabe Was sind Ihre Erwartungen an den Kurs? Randbedingung:
1. Warum stellt der Kursleiter die Frage? - will die Erwartungen der Teilnehmer kennen lernen und mit seinen Inhalten abstimmen (braucht Liste, die er mit nachhause nehmen kann) - will die Erwartungen zu den vorbereiteten Themen gruppieren und kommentieren (braucht Post-It, die er auf vorbereites FlipChart klebt) - will eine Pause von 5 min (egal was rauskommt) - will eine Lektion erteilen (braucht AHA-Effekt) 2. Was ist das Ergebnis? - einer trägt eine Liste vor - Gruppe bereitet FlipChart vor - jeder hat sich Gedanken gemacht - gewichtete Liste der Erwartungen 3. Wie gehen wir vor? - jeder für sich - es werden 3 Gruppen gebildet - es gibt einen Moderator und einen Sprecher - es werden zuerst Themen aufgelistet und darunter Erwartungen einsortiert als Beispiel - es wird abgestimmt, in welcher Reihenfolge (Wichtung, logische Reihenfolge) die Erwartung präsentiert werden 4. Wann haben wir was? - Zwischenergebnisse, z.B. Klärung Vorgehen, Brainstorming Liste, Präsentations Chart 5. Durchführung 6. Kontrolle -> geht nur, wenn wir Zwischenergebnisse definiert haben, sonst sehen wir erst am Ende, ob wir es geschafft haben oder nicht. -> gut ist es das Risiko „Zeit reicht nicht!“ parallel zu planen. Alternativplan erstellen, Notfall-Lösung, Paralleles Arbeiten... AHA-Effekt: Projektmanagement wurde erfunden für das Management von Projekten, d.h. von schwierigen weil einmaligen Vorgängen, z.B. Mondlandung, Bau der Pyramide. Projektmanagement ist eine Kunst für Fortgeschrittene. Techniken des Projektmanagements können jedoch von JEDEM und für jede AUFGABE eingesetzt werden. Die Verwendung von Projektmanagement-Techniken erfordert keinen großen Extraaufwand, sondern nur Nachdenken bevor man Losstürmt: - warum? - was? - wie? - wann? Randbedingung: 15 min Zeit Methoden des SW-Projektmanagements 22

23 Inhalte des Kurses Warum? Was? ok? Wie? Tun! Wann? Ist: Motivation
Chaos-Report Ziel: gute PL Praxis Kontrolle: Prüfung Erfolg Strategie: Kurs Zertifikat Tun: Skipt, Folien, Plan: Semester Kurstage Anmerkungen: Motivation Wie Eingangs erwähnt die Misserfolge in vielen Projekten. Die Tatsachen, dass man IT-Experte und Management studieren kann, aber PM nicht. 2. Ziel Für mich: Viele Kursteilnehmer machen eine gute Prüfung, Kursteilnehmer wenden Tipps an, Kurs macht Spass! Fur Sie: (siehe Erwartungen) 3. Strategie Projektmanagement als Technik und Methode in einem Kurs vorstellen. Relevanz von Projektmanagement und Kunst (Können) der Elitetechnik deutlich machen. Aufgaben des PL erklären und verständlich machen. Managementregelkreis erklären Denken in Ergebnissen Abgrenzung AM-PM-AP 4. Planen Aufteilung des Kurses in Semster Aufteilen des Stoffes auf Dozenten Aufteilen eines Kurses auf Tage 5.Tun: Ergebnisse: Skript, Folien, Kurs Gliederung: Einführung, Techniken, Tools, Beispiele, Tipps, Literatur Techniken für: - Interview - Brainstorming/Moderation/Kreativität - Schätzung, Planung, Risikomanagement - IT-Entwicklungsmethoden - Konfliktmanagement, Kommunikation - Meetings, Reviews, Kontrolle 6. Kontrolle Übungsaufgaben Vorbereitung auf die Prüfung Vorbereitung auf den Job Kontrolle, ob meine Inhalte ok sind. Kontrolle, ob Prinzipien verstanden und gelebt werden. Hidden Agenda: Managementkreis ist ein gutes Strukturierungsmittel, jedoch - Jede Struktur ist besser als keine. - Jeder Plan ist besser als keiner. Methoden des SW-Projektmanagements 23

24 2. Übungsaufgabe Sie sind der Projektleiter!
Die Familie braucht ein Haus? Die Familie will in den Urlaub! 1. Definition der Motivation für den Hausbau (Problem aus Sicht des Kunden, oder Auftraggebers = Bauherr, Familie) WARUM-Frage 2. Definition des Ziels = Haus, Urlaub WAS-Frage 3. Strategie der Zielerreichung = Vergabe, Selbstbau, Miete/Art der Entscheidung - WIE-Frage 4. Planung der Zielerreichung WANN-Frage 5. Durchführung = Bau,Kauf / reisen DOING 6. Kontrolle = Baufortschritt / Entscheidung ok?, Motivation ok?, Lessons learned? - OK oder WIE GUT-Frage Randbedingung: 2 Gruppen 20 min Zeit Methoden des SW-Projektmanagements 24

25 Begriffe Projekt: Produkt:
Ziel (was?, wohin?) Start (warum?) Prozess, Strategie (wie?) Projekt XYZ Q Projektrahmen Auftraggeber Stakeholder Organisation Ressourcen Tools Methoden Aufgabe Projekt: Einmaliges Vorhaben, Ziel, Be-, Abgrenzung, spez. Rollen Prozess: Vorgehen im Projekt Ablauf der Aktivitäten Produkt: Ergebnis eines Projektes, bzw. eine Prozesses Projekt: Ein Vorhaben, das im wesentlichen durch Einmaligkeit in seiner Gesamtheit gekennzeichnet ist bezogen auf: die Zielvorgaben (Qualität, Kosten, Termin) die Begrenzungen (zeitlich, finanziell, personell) die Organisationsform (projektspezifische Rollen) die Abgrenzung gegenüber anderen Vorhaben (komplexe Aufgabenstellung) Prozess: Sachlogisch zusammenhängende Reihe von zielgerichteten Tätigkeiten zur Erreichung eines definierten Ergebnisses. Er verursacht Kosten und Verbraucht Resourcen. Er stellt eine Transformation von Input zu Output dar. Aufgabe: Beschreibung der Verantwortung und Tätigkeit einer Rolle (Organisationssicht) Ziel und Zweck eines Prozesses Mini-Projekt für Mitarbeiter (Arbeitspaket-Sicht) Methoden des SW-Projektmanagements 25

26 Abgrenzung Projekt-/ Lösungsprozess
Warum? Abgrenzung Projekt-/ Lösungsprozess ok Was? Wie? Wann? Projektprozess: Vorgehensweise zur Durchführung des Projekts Projektvorbereitung Projektinitialisierung Projektplanung Projektdurchführung Projektabschluss ausgeführt vom PM basiert auf Management-regelkreis Lösungsprozess: Vorgehensweise zur Erarbeitung einer Projektlösung Wasserfallmodell V-Modell Spiralmodell Prototyping ausgeführt von Projektmitarbeiter Experten basiert auf fachliche Vorgehensmodelle Anmerkung: Projektvorbereitung (Motivation) (Problemerkennung, -analyse, Machbarkeitsanalyse, Risikoanalyse, Entscheidung) Projektdefinition (Ziel) (Projektbeurteilung, -start) Projektdesign (Strategie) (Projekteinbindung, -betreuung, - leitung, -gruppe, Lösungsprozess) Projektplanung (Planung von Aufgaben, Personal, Terminen, Sachmitteln, Kosten, Dokumentation, Qualität, Bedarf) Projektdurchführung (Projektleitung mit Teambildung, Mitarbeiter-führung, Projektsteuerung und Projektcontrolling; sowie Projektarbeit mit Teamarbeit, Arbeitstechniken, Verhandeln, Präsentieren, Visualisieren, Dokumentieren) Projektabschluss (Kontrolle) (Projektkontrolle, Projektnachweise, Projektauflösung) Im Lösungsprozess werden meist nur die Ergebnisse (Diagramme), die Strategie und die Durchführung beschrieben. Methoden des SW-Projektmanagements 26

27 Mini-Quiz Was ist die Definition von einem Projekt? Wie unterscheidet es sich von anderen Tätigkeiten? (mind. 3 Merkmale) Welche Projektphasen kennen Sie? Warum scheitern viele Projekte? (4 Gründe) Was sind die 6 Schritte des Managementregel-kreises? Was sind die Phasen des Deming Cycle‘s? Methoden des SW-Projektmanagements 27

28 Zusammenfassung Prinzipien
Grundlage ist der Management Regelkreis Projektleiter denken in Ergebnissen, aber verstehen wozu Ergebnisse gebraucht werden Projektleiter handeln pro-aktiv planen kontrollieren und steuern frühzeitig Projektmanagement ist kein Selbstzweck, sondern überlebensnotwendig Sinn jeder Kontrolle/jedes Berichts ist klar Projektmanagement Techniken können überall und von jedem angewandt werden kosten ein paar Sekunden nachdenken! Warum? Was? Wie? ok Wann? Methoden des SW-Projektmanagements 28

29 Wiederholung: 1. Tag Motivation
Projekte sind anspruchsvolle neue Herausforderungen PM = Projekte managen (strukturieren, planen, leiten) PM ist nötig, aufwendig und lohnt sich Prinzipien Managementregelkreis ist einfach, aber wird oft ignoriert oder nicht angewandt 1. Einführung Motivation Definition Abgrenzung Regelkreis 2. PM in IT 3-Ebenen Proj.-Phasen 3. Techniken I 4. Techniken II 5. Kontrolle Projektmanager sind Führungskräfte, die den Kunden verstehen fachliche Zusammenhänge strukturieren können neue Teams zusammenschweißen können Teams moderieren und leiten können das Team von jeder Störung abschotten sehr gut kommunizieren Probleme mit dem Kunden kreativ lösen können Ergebnisse verkaufen können Methoden des SW-Projektmanagements 29

30 Regelkreis in der Praxis
Nr Phase Unternehmen Auftraggeber Auftragnehmer Problem 1 Analyse (Warum) Geschäfts- idee Projektidee Ist-Analyse / Motivation des Kd Problem­ definition 2 Ziel Definition (was) Geschäftsziel Vision Projektziel Lieferleistung, Ergebnisse (SMART) Ziel­ formulierung 3 Lösungs­ Strategie (wie) Organisation Op- Ziele Proj.­konzept Business Case Vorgehen, Org Methode, Regeln Strategie, Lsg.- alternativen Auswahl Gründung Ausschreibung Angebot Entscheidung 4 Planung (wann) Geschäftsplan Projektplan Netzplan, Kapazitätsplan Aktionsplan 5 Durch­ führung (tun) Geschäft machen Projekt­ auftrag koordinieren, kommunizieren moderieren dokumentieren Lösen 6 Projekt­ Kontrolle (ok) Berichtswesen Projektkontrolle und -abnahme Soll/Ist Vergleich Risiko- management Kontrolle Methoden des SW-Projektmanagements 30

31 3 Ebenen des Projektmanagement
Lieferplan Vertrag Entscheidungen ispl Projektplan Projektphasen Ini-Plan-Control-End PM Meilenstein Aufgaben Projekt Organisations are sometimes unable to clearly express their business needs and goals. Lack of mutual understanding between the supplier and the customer is another reason. Deficiencies in Contract Monitoring and Risk management has also found be another critical factor Results or documents on the contractual level are deliverables and need to be quality reviewed in ISO9000 Ergebnisse Vorgehensmodell SWE-Methoden Methoden des SW-Projektmanagements 31

32 Zusammenhänge Auftragsmanagement Projektmanagement Zeitmanagement
Warum? Was? Wie? ok Wann? Auftragsmanagement Projektmanagement Zeitmanagement Motivation Aufgabendefinition Lieferstrategie Überwachung Abschluss Aufgabe Lösungsansatz persönlicher Zeitplan Durchführung Arbeitsbericht Projektvorbereitung Projektinitialisierung Projektplanung Projektsteuerung Projektabschluss Liefer- plan Projekt- plan Arbeits- paket Projektvorbereitung (Problemerkennung, -analyse, -entscheidung, Machbarkeitsanalyse, Risikoanalyse, Projektplanungsentscheidung) Projektdesign = Projektinitialisierung (Projekteinbindung, -betreuung, -leitung, -gruppe, Lösungsprozess) Projektplanung (Planung von Aufgaben, Personal, Terminen, Sachmitteln, Kosten, Dokumentation, Qualität, Bedarf) Projektauslösung = Kick-Off (Projektbeurteilung, -entscheidung, -start) Projektdurchführung = Projektsteuerung (Projektleitung mit Teambildung, Mitarbeiter-führung, Projektsteuerung und Projektcontrolling; sowie Projektarbeit mit Teamarbeit, Arbeitstechniken, Verhandeln, Präsentieren, Visualisieren, Dokumentieren) Projektabschluss (Projektkontrolle, Projektnachweise, Projektauflösung) Ergebnisstruktur (Produktstruktur) + Termine Projektstruktur + Termine + alle Zwischenergebnisse Methoden des SW-Projektmanagements 32

33 Zeitmanagement-Regelkreis
Zielsetzung Analyse und Ziele Planung Alternativen und Pläne Entscheidung Auswahl der Alternativen Realisierung Tagesgestaltung und Organisation der Abläufe Kontrolle der Ergebnisse mit den Zielen Kontrolle Zielsetzung 5 1 Kommu- nikation 4 2 Realisierung Organisation Planung 3 Lothar J. Seiwert, „Mehr Zeit für das Wesentliche“, mvg-Verlag, 1996 (ISBN ) Zeitmanagement ist dem Managementkreislauf sehr ähnlich, weil es derselbe Prozess ist, nur am Ende der Kette. Auftrag-Projekt-Zeitmanagement/Problemmanagement Entscheidung Methoden des SW-Projektmanagements 33

34 Abgrenzung Projekt-/ Lösungsprozess
Projektprozess: Vorgehensweise zur Durchführung des Projekts Projektvorbereitung Projektdefinition Projektdesign Projektplanung Projektdurchführung Projektabschluss Lösungsprozess: Vorgehensweise zur Erarbeitung einer Projektlösung Wasserfallmodell V-Modell Spiralmodell Prototyping Anmerkung: Projektvorbereitung (Motivation) (Problemerkennung, -analyse, Machbarkeitsanalyse, Risikoanalyse, Entscheidung) Projektdefinition (Ziel) (Projektbeurteilung, -start) Projektdesign (Strategie) (Projekteinbindung, -betreuung, - leitung, -gruppe, Lösungsprozess) Projektplanung (Planung von Aufgaben, Personal, Terminen, Sachmitteln, Kosten, Dokumentation, Qualität, Bedarf) Projektdurchführung (Projektleitung mit Teambildung, Mitarbeiter-führung, Projektsteuerung und Projektcontrolling; sowie Projektarbeit mit Teamarbeit, Arbeitstechniken, Verhandeln, Präsentieren, Visualisieren, Dokumentieren) Projektabschluss (Kontrolle) (Projektkontrolle, Projektnachweise, Projektauflösung) Im Lösungsprozess werden meist nur die Ergebnisse (Diagramme), die Strategie und die Durchführung beschrieben. Warum? Was? Wie? ok Wann? Methoden des SW-Projektmanagements 34

35 Übungsaufgabe Was soll in einem Angebot stehen? (Struktur)
1. Warum? - Hintergrundinfo, Vorgeschichte - Zeigen, dass man verstanden hat, um was es geht. 2. Was? Ergebnisse, die man abgeben muss (SMART) Liefer- und Leistungsumfang Was ist ausgeschlossen? Was muss der Kunde liefern? 3. Wie? Methode für das Vorgehen – begründen mit der jeweiligen Situation! Zeigen, dass man Experte ist Zusammenarbeit mit Kunde: Expert-Driven, Participatory, Top-Down, Incremental, Evolutionary Methode für Entscheidungen bei Meilensteine, Abnahmen... 4. Wann? Liefertermine (gekoppelt an Entscheidungen über das weitere Vorgehen!) 5. Tun! Qualifikationsnachweis (meist als Anhang mit CV und Referenzprojekte) Zahlungsbedingungen (meist nach Arbeitsfortschritt, siehe Liefertermine) 6. Kontrolle Meilensteine, Berichte, Kriterien der Lieferprodukte Unterschiedlich, je nach Vertragsart: Werkvertrag über ein Gewerk mit Gewährleistung oder Dienstleistungsvertrag mit anderen AGBs. Randbedingung: Gemeinsame Themenbearbeitung Struktur gemäß Managementregelkreis Methoden des SW-Projektmanagements 35

36 Struktur eines Angebots
1 Überblick / Grundlagen 2 Aufgabenstellung 3 Angebotene Leistungen (und Ergebnisse) 4 Leistungen von Seiten des Kunden 5 Termine (und Projektablauf) 6 Kosten und Zahlungsmodalitäten 7 Vertrag, Bindefrist (, Kündigung) 8 Anhang Allgemeine Geschäftsbedingungen (AGBs) Qualifikation (CVs, Referenzkunden) Überblick / Grundlagen Warum, Hintergründe, Vorgeschichte, Allgemeines Aufgabenstellung Verständnis über das Ziel Angebotene Leistungen (und Ergebnisse) Konkretisierung der Leistung am Ende des Projektes und wesentliche Zwischenergebnisse mit einer Erwartung des AN (Entscheidung des Kunden) Leistungen von Seiten des Kunden Absicherung des AN. Beistellungen des Kunden klar festhalten -> Risiko beim Kunden Termine (und Projektablauf) Evtl. das Wie, d.h. die Lösungsstrategie beschreiben. Bei Festpreis eher weniger üblich. Kosten und Zahlungsmodalitäten Abhängig vom Kostenmodell (Festpreis, nach Aufwand) Zahlungsziele vereinbaren (nach Meilenstein, nach Monat, am Ende..) Vertrag, Bindefrist (, Kündigung) normalerweise Verweis auf Standard 8 Anhang Qualifikation des AN (Referenzprojekte, Größe, Veröffentlichungen..) Lebenslauf der wichtigen Personen (nur wenn verlangt) Warum? Was? Wie? ok Wann? Methoden des SW-Projektmanagements 36

37 Struktur des Vertrags Vertrag Managementkreis Task 1. Überblick 2.
1.1. Beschaffungszweck 1.2. Problembeschreibung 1.3. Struktur des Angebots 2. Aufgabenstellung 2.1. Leistung und Lieferung 2.2. Situationsanalyse 2.3. Risiken 3. Projektablauf 3.1. Vorgehen 3.2. Projektkontrolle 3.3. Changemanagement 4. Termine 4.1. Entscheidungen 4.2. Abnahme Anhang Managementkreis Task Warum? Was? Umsetzen Kontrolle Wer? Wann? Wie? Methoden des SW-Projektmanagements 37

38 Entwicklung der Dokumente
der Business Case beschreibt in dem das Problem, die Lösung und den Nutzen die Ausschreibungsunterlagen beschreiben die Randbedingungen, Auswahlkriterien der Ausschreibung das Angebot beschreibt eine Lösungsalternative Lieferplan Kosten Qualifikation des AN. der Vertrag beschreibt Lieferleistung, Lieferplan und Kosten verbindlich Methoden des SW-Projektmanagements 38

39 Dokumente der 3 Ebenen Methoden des SW-Projektmanagements 39
Vertragliche Ebene Act ·      Business Case, Ausschreibung ·      Change Requests Plan ·      Angebot/Vertrag, Lieferplan Do ·      Lieferungen, Managementberichte, Protokolle   Check ·      Abnahmeprotokoll, Abrechung Projekt­ management Act ·      Projektauftrag ·      Arbeitspaketbeschreibung Plan ·      Projekthandbuch (Organisation, Konfiguration, Risikomanagement), Projektplan Do ·      Protokolle, Zwischenergebnisse, Tests, Lieferungen Check ·      Projektbericht persönliches Zeitmanagement Act ·      Arbeitspaketbeschreibung Plan ·      Zeitplan, Terminkalender Do ·      Ergebnisse, Tests Check ·      Arbeitsnachweis Methoden des SW-Projektmanagements 39

40 Aus schreibungs- Unterlagen
Dokumente der 3 Ebenen Dokumente vertragliche Ebene Projekt Ebene Fachliche Ebene Aus schreibungs- Unterlagen Modelle Abnahmen, Changes HW, SW, Handbücher Pläne Berichte Studien Methoden des SW-Projektmanagements 40

41 Tipp: Ablage 0 /Kundensicht 0 /Intern 0 /Projekt- management
0 /Projekt- management Arbeitskopien für das Team Plan und interne Kosten, Protokolle, interne Berichte Ausschreibung – Angebot – Changes Lieferungen – Abnahmen - Rechnungen Veröffentlichungen Methoden des SW-Projektmanagements 41

42 Kunde denkt in Entscheidungen
Ziel der Entscheidung benötigte Inputs als Grundlage der Entscheidung Entscheidungsprozess Abstimmung Bericht Abnahme Design Entscheidung Lieferprodukt Methoden des SW-Projektmanagements 42

43 Arten von Entscheidungen
Zweck Lieferprodukte ?! Investment Berichte/Studien Kosten/Risiken/Investment Funktionale und Qualitätsmerkmale investieren kaufen oder entwickeln Design Beschreibung ok? Design auswählen Merkmale (Designs, Prototyps, Modells) Alternativen Merkmale (Designs, Prototyps, Modells) Alternativen Abnahmekriterien System- Abnahme eines Lieferprodukts Abnahme abnahme nächste Entscheidung Änderungen Kontrolle Lieferplan Änderungsplan Vertrags- änderung Methoden des SW-Projektmanagements 43

44 PL denkt in Ergebnissen
Was muss ich am Ende abgeben? Wie komme ich dahin? Wie lange brauche ich mit QM? „gut, aber woher weiß ich ob es dem Kunden gefällt?“ Warum? Was? Wie? ok Wann? Methoden des SW-Projektmanagements 44

45 Prozesssicht PM - AM Anmerkung:
Ausschreibung Angebot AN-Auswahl Vertragsabschluß Vertragskontrolle Vertragsanpassung Abnahme der Lieferung Vertrags- beendigung Ausschreibung Monitor phase Abschluß Projektmanagment Vorbereitung Plan Lieferungen Anmerkung: ein Projekt wird akquiriert – meist durch den Vertrieb oder Kundenbeauftragten: es geht primär um Lösungen für Probleme! Für den Vertragsabschluss benötigt man eine Schätzung des Aufwands und einen Terminplan! Während das Projekt läuft, will der Kunde (Auftraggeber) Zwischenergebnisse – warum? (Methode oder weil er Fortschritt kontrollieren möchte?) Im Projekt werden Meilensteine so geplant, das die (Zwischen)-Ergebnisse bereit zur Abnahme sind. (QM nicht vergessen!) Dies ist die Theorie. In der Praxis arbeit das Team teilweise beim Kunden oder mit dem Kunden zusammen. Die Rollen sollten trotzdem getrennt sein! In großen Organisationen (BMW) liest der Auftraggeber nicht mehr das Ergebnis, sondern nur noch eine Empfehlung seines Vertrauten. -> im Vorfeld mit Vertrauten Ergebnisse absichern! -> PM sollte diese Zusammenhänge verstehen und wenn nicht am Anfang so lange nachfragen, bis sie geklärt sind. -> Für den PM ist die Abnahme das Ergebnis! -> Entscheider, Abnahmekriterien, Abnahmeprozess Herstellung Kick-Off Meilenstein Projektteam Methoden des SW-Projektmanagements 45

46 Generische Projektphasen (PDCA)
A: Projektinitialisierung Erfahrungen der Praxis belegen: Projektgruppen, die die Phasen A und B sorgfältig durcharbeiten, haben > 50 % des Projekterfolgs in der Tasche - Klärung der Ausgangslage - Erarbeitung der Projektziele - Gruppenführung + Teammanagm. B: Projektplanung - Projektstruktur erarbeiten - Erfolgs- u. Mißerfolgsfaktoren analys. - Projektbeschluß herbeiführen - Durchführungsplanung C: Projektdurchführg. - Projektsteuerung und Kontrolle - Änderungsmanagement Aber: Aus Zeitmangel oder Erfolgsdruck starten viele Projektgruppen mit Phase C “durch” und erhöhen somit das Risiko des Scheiterns ihres Projekts! Managementregelkreis für PM (ohne Schleifen, ohne Akquise) Wichtig ist trotzdem, dass oft Initiierung und Planung vernachlässigt werden! Dabei sind mit diesen Phasen bereits 50% des Aufwands eines PL und des Erfolgs erreicht! -> siehe 44% Scheitern weil Anforderungen schlecht sind! Wenn die Projektmitarbeiter gleich starten, dann kann der PL seine Arbeit nicht vernünftig machen, weil er gleichzeitig, organisieren, planen und managen soll – doch gegen was? -> Frust des PL, weil er keine Möglichkeit sieht wie er sinnvoll arbeiten kann -> Frust der Mitarbeiter, weil sie sehen dass der PL nicht für sie da ist und sich um ihre Schwierigkeiten kümmert: Meetings, Templates, Abrechnung, Fragen zum Auftrag beantworten, Informationen gleichmäßig an alle verteilen, Sinn gibt, motiviert, als Leuchtfigur Projekt repräsentiert Warum wird Initiierung übersprungen? Weil Projekt für Management bereits viel früher begonnen hat! Tipp: PL muss Mitarbeiter zunächst für die Phase Initiierung und Planung einspannen! Dann hat er Zeit das zu tun, was er tun muss, damit er managen kann. Mitarbeiter sind informiert. PL muss jedoch zeigen, dass er auch arbeitet! Nicht unbedingt zusammen mit dem Team, aber es müssen schnell Ergebnisse von ihm kommen, die man anerkennt! Erste Ergebnisse des PL: Vorgabe der Arbeiten für Phase Ini und Planung (Templates, Vorgehen, Managementregelkreis erklären) Projektpräsentation, Reports, Zusammenfassungen der Meetings Projektstruktur in der Ablage Integration der Detailpläne und Projektstruktur in einen Gesamtplan Check und Prüfung gegenüber Lieferplan, Urlaub, Verfügbarkeit, Machbarkeit (offene Ehrlichkeit!) Bericht über Gespräche mit externen (AG, AN-Mgt, externe Experten...) Offenes Ohr für persönliche Probleme und schnelle Lösung dieser! D: Projektabschluß - Soll-Ist-Vergleich - Dokumentation Methoden des SW-Projektmanagements 46

47 Hindernisse in der Praxis
Management Entscheidungen sind nicht-technisch Techniker verstehen sie nicht Techniker brauchen sie nicht verstehen Techniker haben Angst sich zu blamieren Die IST-Analyse ist zu teuer, aber das neue System soll so gut sein wie das alte Fehler sollen nicht wiederholt werden das IST soll verbessert werden Die Experten kennen bereits eine Strategie, aber ist sie für die Situation die beste? Methoden des SW-Projektmanagements 47

48 Menschliches Irren Nicht das,
was wir nicht wissen, bringt uns zu Fall... sondern das, was wir fälschlicherweise zu wissen glauben. Methoden des SW-Projektmanagements 48

49 Warum Planung? Planung ersetzt den Zufall durch den Irrtum -> Irrtum ermöglicht Lernen Plane und du wirst Irren -> ja, aber geplant damit umgehen. Je genauer der Plan, desto härter trifft der Zufall -> zu genaue Pläne sind oft falsch Je mehr der Zufall trifft, desto nötiger ist der Plan -> je neuer die Situation, umso nötiger ein Plan Plane nur soviel wie Du kontrollieren willst/kannst -> keine Diagnose und Steuerung ohne Planung -> keine Planung ohne Diagnose und Steuerung Planung ersetzt den Zufall durch den Irrtum. Ohne Planung erscheinen die Geschehnisse im Projekt zufällig -> keinen Handlungsdruck Plane und du wirst Irren. Irrtümer sind in Projekten völlig normal. Es sollte allerdings geplant sein, wie damit umgegangen werden soll. Je genauer der Plan, desto härter trifft der Zufall. Meist werden sehr detaillierte Pläne von Projektleitern im "stillen Kämmerlein" erstellt. Lassen Sie Ihr Team mitdenken! Je mehr der Zufall trifft, desto nötiger ist der Plan. Wird mit einem Projekt "Neuland" betreten, beschäftigt es sich mit einem schwierigen, dynamischen Umfeld. Haben die Projektbeteiligten wenig Erfahrung, so gibt ein detaillierter Plan vor allem für die ersten Schritte ausreichend Sicherheit. Plane nicht und du wirst auch nicht wissen, ob du geirrt hast. Ohne Planung werden viele Lernchancen vergeben. Irrtümer sind gute Gelegenheiten, um zu lernen. Ohne Planung fehlen Vergleichsmöglichkeiten und konkrete Ansatzpunkte für Verbesserungen. Plane nur soviel wie Du kontrollieren wirst (kannst und willst) Das bedeutet: keine Diagnose und Steuerung ohne Planung - keine Planung ohne Diagnose und Steuerung Die Planung formuliert den Qualitätsanspruch an die Ergebnisse. Die Qualität wird sinken, wenn diese Qualitätsanforderungen nicht überprüft werden. Umfang und Form der Planvorgaben bestimmen den Führungsstil im Projekt. Vertrauen Sie als Projektleitung Ihrem Team und planen Sie ziel- und ergebnisorientiert, denn sonst steigt der Kontrollaufwand. Methoden des SW-Projektmanagements 49

50 Projektphasen & Abhängigkeiten
Initiating Planning Controlling Executing Closing Act (decide) Plan (design) Do Check nach PMBok Methoden des SW-Projektmanagements 50

51 Projektmanagement über die Zeit
Projektphasen im Laufe eines Projektes. Man erkennt, dass die ersten Phasen ohne „Auftrag“ – oft ohne „Verrechnung“ unter Akquise oder „Freundschaftsdienst“ laufen! Diese Darstellung ist zu optimistisch, da man annimmt, dass Tätigkeiten nicht wiederholt werden! Oft dauert die Entscheidung für Projekt sehr lange und es kommen ganz andere Leute zum Projekt, als bei der Ausschreibung! Program Management Body of Knowledge, PMBOK Guide 2000 (pp 30-31) Methoden des SW-Projektmanagements 51

52 Projektphasen Projektmanagement Vor- bereitung Initiali- sierung Plan-
Steuer- ung Ab- schluß Vertrag Projekt- auftrag Team Kick-Off Projekt- plan Projekt- ziele Team auflösen Lessons learned Laut DIN ist eine Projektphase ein "zeitlicher Abschnitt eines Projektablaufs, der sachlich gegenüber anderen Abschnitten getrennt ist." Diese Trennung erfolgt in der Regel durch einen Meilenstein. Vorprojektphase: Die Projektidee bzw. die Anforderung des Kunden/Auftraggebers wird konkretisiert,grob geplant, Angebote abgegeben und Verträge ausgehandelt. Initialisierung: Projektauftrag verabschiedet, Ziele für Projektteam und PL definiert (interner Vertrag), Team zusammengestellt, Infrastruktur & Rahmenbedingungen geklärt Planungsphase: In der Planungsphase konkretisiert das Projektteam die Planung. In dieser Phase werden insbesondere Aufgaben, Termine und Kosten im Detail geplant. Steuerungsphase (Realisierungsphasen): Die Projektziele und -inhalte werden in mehreren Phasen umgesetzt. Die einzelnen Realisierungsphasen werden in der Regel durch Meilensteine abgeschlossen, die wesentliche Zwischenergebnisse bzw. Stop-Or-Go-Punkte im Projekt darstellen. Lieferprodukte dienen dem AG/AN für Entscheidungen! Während der Realisierung wird die Projektplanung immer wieder den aktuellen Rahmenbedingungen angepasst. Abschlussphase: Nach der Abnahme erfolgt die Bezahlung und die Wartung beginnt. Am Ende eines jeden Projekts ist es ratsam, die gemachten Erfahrungen im Team zu diskutieren, zu reflektieren und zu dokumentieren. Anschließend wird die Projektorganisation durch Entlastung des Projektteams aufgelöst. Das Projekt ist somit beendet. Methoden des SW-Projektmanagements 52

53 Projektphasen in der Praxis
Projekt-vorbereitung Problemerkennung, -analyse, Machbarkeitsanalyse, Risikoanalyse, Entscheidung Projekt-initialisierung Projektdefinition (Ziele, Risiken) Projektorganisation (Team + Infrastruktur) Projektstart (Initialisierungsmeeting) Projekt- planung Projektplanung (Strategie, Struktur, Plan) Resourceneinteilung (Arbeitspakete) Projekt- steuerung Projektkontrolle, -steuerung (Berichte, Meetings) Risikomanagement (Risiken, Maßnahmen) QS-Maßnahmen (Review, Test, Doku) Vorbereitung (Anbahnung): Korrespondiert mit der Ausschreibung! (Warum, Was, Wie – Entscheidung!) Initalisierung (eigentlicher Start): Warum, Was, Wie (hinterfragen der Info, da oft andere Leute) Wie mit Experten prüfen! (hängt oft von Personen ab, welche Strategie nötig ist) -> Entscheidung über Strategie im Team (Teambildungsprozess! Gemeinsames Kommitment) Planung (im Detail): PL gibt groben Rahmen gemäß Vertrag, Urlaub, Kalender vor! PL rechnet immer rückwärts (Lieferdatum – Puffer, QS, Zwischenkontrolle, Entscheidungen..) Experten müssen selbst Inhalt und Details definieren! (Arbeitspakte, die vom PL geprüft werden können! Arbeitspakte für Kontierung!) Mitarbeiter planen eigene Zeit (Zeitplan der Experten und des Projekts ist machbar?) Mitarbeiter haben nötigen Skills? nötige Tools? nötige Info? Was fehlt? Steuerung: Mitarbeiter planen ihre Arbeitspakte, definieren ihre Lösungsstrategie, verwenden Vorgaben, Reports, Templates... Mitarbeiter erkennen Risiken, Probleme und berichten darüber in Teammeetings und machen technische Vorschläge PL erstellt: Templates, Regeln für Meetings, Moderiert, Integriert Arbeitspaketpläne, Präsentiert, Organisiert, Informiert... PL reagiert auf Probleme (Änderung der Gesamtplanung, mehr Ressourcen, besorgt zusätzliche Info, motiviert, holt Hilfe von außen) Abschluss: PL übergibt, PL sucht neues Projekt für Mitarbeiter, PL dokumentiert und archiviert und berichtet Projekt- abschluss Übergabe der Lieferprodukte Auflösung der Service-Infrastruktur Lessons Learned Methoden des SW-Projektmanagements 53

54 Projektvorbereitung Problemerkennung
Situationsanalyse (Techniken der Ist-Analyse) Warum-Fragen (Soft-Systems Methode) Probleme erkennen (Ursache-Wirkung-Analyse) Projektanalyse Umfeldanalyse (Stakeholders, Historie, Systeme) Machbarkeitsanalyse (Grobplan, Prototyp, Lösungsidee) Risikoanalyse (Kosten, Termine, Qualität, Personal) Entscheidung Chancen – Risiken (Stop-Go) Vertragsform (Risikominimierung) Preis (Kostenschätzung, Konkurrenzanalyse) Methoden des SW-Projektmanagements 54

55 Projektvorbereitung Idee Problem Ist-Analyse Ziel-Definition Strategie
Business Case Machbar- keitsstudie Ist-Analyse Ziel-Definition Strategie Planung (grob) Risiko x Methoden des SW-Projektmanagements 55

56 Managementregelkreis
Analyse Projekt Kontrolle Lösungs- Strategie Durch- führung Warum? Was? ok? Wie? Tun! Wann? Planung Ziel- Definition Anmerkungen: 1. Ist Analyse (Warum) Das erste Warum ist oft trivial, z.B. weil unser Lehrer das gesagt hat. Weil wir jedes Jahr in den Urlaub fahren. Ziel der Frage: Motivation des Kunden verstehen. Tipp: Kunden denken oft in Entscheidungen und benötigen dazu Informationen (Ergebnisse). 2. Ziel Definition (was) Das Ziel lässt sich auf 3 Arten beschreiben: a) Vision des Endzustands (Sehnsucht nach dem Meer, Sicherheit, Ruhe / erholt, braun, glücklich); -> durch Ist-Analyse b) Ergebnisse (Haus mit Garten, 5 Zimmer, etc. / Sonne, Strand ..) > Produktstruktur c) Arbeitsanweisung (do-it-yourself Bausatz / organisierte Tour) > durch Strategie Hier ist das Ergebnis im Sinne von versprochener Leistung oder versprochenen Lieferprodukten gedacht (Deliverables) Ziel der Frage: Was soll abgenommen werden? Wann habe ich einen guten Job gemacht? Problem: Oft sind viele Zielerwartungen implizit, z.B. Windows-like, so gut wie was wir schon haben... 3. Lösungsstrategie (wie) Bei Standardentwicklungen vorgegeben (Software Entwicklungsmethoden). Muss jedoch angepasst werden. Bei neuen, einzigartigen Projekten noch offen!! z.B. Haus bauen, bauen lassen, mieten? Urlaub an einem Ort? zusammen? Kreativer Prozess mit Lösungsvarianten, die anschließend bewertet werden und zu einer Entscheidung führen. (Gründe der Entscheidung = Teil der Motivation!) Ziel des Schritts: Methode finden, nach der geplant und vorgegangen wird. 4. Planung (wann) Viele Techniken der Planung. Wichtige Aufgabe am Anfang: was Du nicht planst, kannst Du nicht kontrollieren! Ziel des Schritts: Definition von Arbeitspakete = überschaubare Aufgaben für eine verantwortliche Person (Teilprojekt!) 5. Durchführung (tun) Jeder Projektmitarbeiter soll möglichst ungestört (!) seine Aufgabe erledigen können. -> SPU ist ok, keine Konflikte mit Linienorganisation, keine Zusatzaufgaben durch den Auftraggeber, klare Vorgaben, klare Projektorganisation 6. Projektkontrolle (ok) Regelmäßige Meetings für: - Projektfortschritt (Ergebnisse, verbrauchte Zeit, geschätzte Restzeit) - Probleme die 5. beeinflussen an PL abgeben - Interne Abstimmung (Koordination, evtl. veränderte Planung) - Risikomanagement an PL melden (evtl. veränderte Methode und neuer Plan) - Stimmung und Wir-Gefühl stärken Ziel der Kontrolle: „Getting Things done“, keine Schuldzuweisung, sondern Projekt erfolgreich durchführen. Jeder Projektmitarbeiter hat mitzuhelfen: - Stundenaufschreibung - Meldung von Störungen - nicht automatisch selbst lösen! - Meldung von Risiken - Ehrlichkeit (sich selbst gegenüber = realistisch) in den Schätzungen - Änderungen in seinen Schnittstellen, Planung, etc. aktiv kommunizieren und absegnen lassen. Methoden des SW-Projektmanagements 56

57 Strategisches Management
Vision: Marktführer Neues Produkt Geschäft morgen Geschäft heute Umfeld: Globalisierung Konkurrenz Neue Technik Neue Märkte Strategie: Kaufen Entwickeln Outsourcen strategische Ziele: Ertrag (Rendite) Wachstum (Marktanteil) Innovation Produktivität (Prozessverbesserung Risiken minimieren Methoden des SW-Projektmanagements 57

58 Übungsaufgabe Was sind Ihre ersten Schritte als Projektleiter?
Phase: Projektinitiierung Was tun Sie selbst? Was delegieren Sie? Ziele festlegen – SMART! (akzeptiert) – Präsentieren im Kick-Off Rahmenbedingungen festlegen: Team, AG-AN, Angebot/Vertrag, Vorgabe/Meilensteine, Arbeitsweise (Jour Fix, Kommunikation, Tools, Standards) – Präsentieren grob, Dokumentieren! Strategie wählen: zusammen in einem Workshop!, Entscheidung! Arbeitspaketplanung: Jeder MA freiwillig wählen, beschreiben, planen – Kontrolle des Verständnisses Planung: Wechselwirkungen der APs, Meilensteine, MA-Zuordnung, Grobplan – Machbar? Planung vorstellen und verabschieden! Präsentieren gegenüber AG Randbedingung: Projektstart, Phasenmodell 10 min, Präsentation Methoden des SW-Projektmanagements 58

59 "Kein Projekt ohne Projektauftrag!"
Projektinitiierung Definition (Ziele + Motivation) SMART, d.h. messbar und akzeptiert (muss) Stakeholder-Analyse Rahmenbedingungen (muss) (Vertagstermine, Kosten, Meilensteine, Lizenzen...) Projektauftrag (interne Ziele, Strategie) (muss) Wirtschaftlichkeit Organisation Rollen/Aufgabenbeschreibungen (muss) Projekthandbuch (Ablage, Arbeitsweise, Standards) Produktionsumgebung (SPU) (muss) Start Kick-Off Workshop Initialisierungsmeeting Ziele festlegen – SMART! (akzeptiert) – Präsentieren im Kick-Off Rahmenbedingungen festlegen: Team, AG-AN, Angebot/Vertrag, Vorgabe/Meilensteine, Arbeitsweise (Jour Fix, Kommunikation, Tools, Standards) – Präsentieren grob, Dokumentieren! Strategie wählen: zusammen in einem Workshop!, Entscheidung! Arbeitspaketplanung: Jeder MA freiwillig wählen, beschreiben, planen – Kontrolle des Verständnisses Planung: Wechselwirkungen der APs, Meilensteine, MA-Zuordnung, Grobplan – Machbar? Planung vorstellen und verabschieden! Präsentieren gegenüber AG "Kein Projekt ohne Projektauftrag!" Methoden des SW-Projektmanagements 59

60 SW-Produktionsumgebung (SPU)
Rechner sind verfügbar Projektordner ist vorhanden Projektmitglieder als Gruppe mit gleichen Rechten Struktur der Ablage ist dokumentiert Unterlagen sind alle gesammelt (Definition+....) Einigung über Software für Dokumente Programme Designs IT-Unterstützung für Kontierung IT-Unterstützung für Kommunikation IT-Unterstützung für Terminplanung Viel zu tun! Und vieles geschieht im Vorfeld, bevor das Kick-Off zustande kommt! - PL hat einen Großteil seiner Aufgaben mit Beginn des Projektes bereits geleistet! - wohin die Zeit buchen? Methoden des SW-Projektmanagements 60

61 Projektplanung Produktstruktur erstellen gemäß Entscheidungen AG
muss vollständig sein! Projektstruktur erstellen gemäß Phasenmodell bis auf die Ebene der Arbeitspakete Schätzen der Aufwände (bottom-up) Vergleich mit Angebot Einteilung der Ressourcen gemäß der Faustformel: Zeit = Aufwand/MA möglichst MA ganz für einen Zeitraum Urlaub berücksichtigen Optimieren der Kommunikation Teams bilden / Teilprojekte Kommunikationsweg festlegen Regeln festlegen Risiken einplanen Buffer Maßnahmen Methoden des SW-Projektmanagements 61

62 Projektplanung - Abhängigkeiten
Aufwand pro Aufgabe Meilenstein definieren Strategie wählen Aufgaben zuordnen Kreativität Termin Aufwand pro MA Ziele festlegen – SMART! (akzeptiert) – Präsentieren im Kick-Off Rahmenbedingungen festlegen: Team, AG-AN, Angebot/Vertrag, Vorgabe/Meilensteine, Arbeitsweise (Jour Fix, Kommunikation, Tools, Standards) – Präsentieren grob, Dokumentieren! Strategie wählen: zusammen in einem Workshop!, Entscheidung! Arbeitspaketplanung: Jeder MA freiwillig wählen, beschreiben, planen – Kontrolle des Verständnisses Planung: Wechselwirkungen der APs, Meilensteine, MA-Zuordnung, Grobplan – Machbar? Planung vorstellen und verabschieden! Risikoanalyse und -management Projektstrukturplan (PSP) Termin- und Meilensteinplan Kosten- und Ressourcenplan Kommunikationsplan Präsentieren gegenüber AG Methoden des SW-Projektmanagements 62

63 Projektsteuerung „Dokumentation, Sorgfalt, Transparenz“
Projektkontrolle Ist-Soll Vergleich (regelmäßige Meetings) Fortschrittskontrolle (Earned Value) Meilensteintrendanalyse Projektsteuerung Maßnahmen überlegen Parallelisierung Verstärkung Neudefinition des Projektauftrags Änderung des Plans (realistisch, akzeptiert, verbindlich) Risikomanagement Neue Risiken entdecken (beobachten!) Wirksamkeit von Maßnahmen verfolgen QS-Maßnahmen Planen, durchführen, motivieren, reagieren! „Dokumentation, Sorgfalt, Transparenz“ Aufnahme des Problems nicht den Boten bestrafen Ursachensuche nur sinnvoll, um vergleichbares Problem zu vermeiden Kreative Lösung suchen Änderung der Netzplanlogik Änderung der Rahmen (Inhalt, Qualität, Zeit) Änderung der Methode (kaufen statt entwickeln) Hilfe bei Experten suchen (Delegieren) Verzögerung wo anders wettmachen Steuerung kommunizieren Neuer Plan Akzeptanz beim Entscheider, evtl. Auftraggeber Methoden des SW-Projektmanagements 63

64 Projektkontrolle Ist-Analyse Projekt Kontrolle Ziel- Definition Durch-
führung Lösungs- Strategie Anmerkungen: 1. Ist Analyse (Warum) Das erste Warum ist oft trivial, z.B. weil unser Lehrer das gesagt hat. Weil wir jedes Jahr in den Urlaub fahren. Ziel der Frage: Motivation des Kunden verstehen. Tipp: Kunden denken oft in Entscheidungen und benötigen dazu Informationen (Ergebnisse). 2. Ziel Definition (was) Das Ziel lässt sich auf 3 Arten beschreiben: a) Vision des Endzustands (Sehnsucht nach dem Meer, Sicherheit, Ruhe / erholt, braun, glücklich); -> durch Ist-Analyse b) Ergebnisse (Haus mit Garten, 5 Zimmer, etc. / Sonne, Strand ..) > Produktstruktur c) Arbeitsanweisung (do-it-yourself Bausatz / organisierte Tour) > durch Strategie Hier ist das Ergebnis im Sinne von versprochener Leistung oder versprochenen Lieferprodukten gedacht (Deliverables) Ziel der Frage: Was soll abgenommen werden? Wann habe ich einen guten Job gemacht? Problem: Oft sind viele Zielerwartungen implizit, z.B. Windows-like, so gut wie was wir schon haben... 3. Lösungsstrategie (wie) Bei Standardentwicklungen vorgegeben (Software Entwicklungsmethoden). Muss jedoch angepasst werden. Bei neuen, einzigartigen Projekten noch offen!! z.B. Haus bauen, bauen lassen, mieten? Urlaub an einem Ort? zusammen? Kreativer Prozess mit Lösungsvarianten, die anschließend bewertet werden und zu einer Entscheidung führen. (Gründe der Entscheidung = Teil der Motivation!) Ziel des Schritts: Methode finden, nach der geplant und vorgegangen wird. 4. Planung (wann) Viele Techniken der Planung. Wichtige Aufgabe am Anfang: was Du nicht planst, kannst Du nicht kontrollieren! Ziel des Schritts: Definition von Arbeitspakete = überschaubare Aufgaben für eine verantwortliche Person (Teilprojekt!) 5. Durchführung (tun) Jeder Projektmitarbeiter soll möglichst ungestört (!) seine Aufgabe erledigen können. -> SPU ist ok, keine Konflikte mit Linienorganisation, keine Zusatzaufgaben durch den Auftraggeber, klare Vorgaben, klare Projektorganisation 6. Projektkontrolle (ok) Regelmäßige Meetings für: - Projektfortschritt (Ergebnisse, verbrauchte Zeit, geschätzte Restzeit) - Probleme die 5. beeinflussen an PL abgeben - Interne Abstimmung (Koordination, evtl. veränderte Planung) - Risikomanagement an PL melden (evtl. veränderte Methode und neuer Plan) - Stimmung und Wir-Gefühl stärken Ziel der Kontrolle: „Getting Things done“, keine Schuldzuweisung, sondern Projekt erfolgreich durchführen. Jeder Projektmitarbeiter hat mitzuhelfen: - Stundenaufschreibung - Meldung von Störungen - nicht automatisch selbst lösen! - Meldung von Risiken - Ehrlichkeit (sich selbst gegenüber = realistisch) in den Schätzungen - Änderungen in seinen Schnittstellen, Planung, etc. aktiv kommunizieren und absegnen lassen. Planung Methoden des SW-Projektmanagements 64

65 Steuerung á la Regelkreis
Aufnahme des Problems nicht den Boten bestrafen Ursachensuche nur sinnvoll, um vergleichbares Problem zu vermeiden Kreative Lösung suchen Änderung der Netzplanlogik Änderung der Rahmen (Inhalt, Qualität, Zeit) Änderung der Methode (kaufen statt entwickeln) Hilfe bei Experten suchen (Delegieren) Verzögerung wo anders wettmachen Steuerung kommunizieren Neuer Plan Akzeptanz beim Entscheider, evtl. Auftraggeber Methoden des SW-Projektmanagements 65

66 Projektabschluss Übergabe der Lieferprodukte Abnahme Rechnungsstellung
Auflösung der Service-Infrastruktur Auflösung der Infrastruktur Auflösung des Teams (Hilfe bei Wiedereingliederung) Lessons Learned Abschlussbericht (Ergebnis, Zahlen, Soll-Ist von Q,K,T, finanzielle & politische Betrachtung des Kosten/Nutzen, Chancen für Folgeprojekte) Lessons learned für zukünftige Projekte Lessons kommunizieren Methoden des SW-Projektmanagements 66

67 Projektabschluss Was tun wir wenn.... ..ein Programm falsch ist…..
.. der SW-Prozeß schlecht ist ... 3+4=7 4+2=3 3+4=7 4+2=3!=> 6 korr! korrigieren! ·       Geschichten (narratives Wissensmanagement) ·       Schätzgrößen für firmeninterne Schätzmodelle (CoCoMo, Function Point etc) ·       strategische Änderungen im Prozess ·       Anregung für persönliche Verbesserungen. …..ändern wir das Programm, nicht das Resultat! …….ändern wir meist das Produkt! Methoden des SW-Projektmanagements 67

68 Wiederholung: 2. Tag (Mini-Quiz)
Warum unterscheidet man die 3 Managementebenen? Welche Unterschiede zwischen dem Projektprozess und dem Lösungsprozess kennen Sie? (Ziele, Aktoren, Modelle) Welche Projektphasen kennen Sie? Was geschieht in der Projektinitiierung? 1. Einführung Motivation Definition Abgrenzung Regelkreis 2. PM in IT 3-Ebenen Proj.-Phasen 3. Techniken I Vorbereitung Initiierung 4. Techniken II 5. Kontrolle Projektmanager sind Führungskräfte, die den Kunden verstehen fachliche Zusammenhänge strukturieren können neue Teams zusammenschweißen können Teams moderieren und leiten können das Team von jeder Störung abschotten sehr gut kommunizieren Probleme mit dem Kunden kreativ lösen können Ergebnisse verkaufen können Methoden des SW-Projektmanagements 68

69 3 Ebenen des Projektmanagement
Projektplan Meilenstein Entscheidungen Vorgehensmodell SWE-Methoden Aufgaben PM Projekt Vertrag ispl Lieferplan Ergebnisse Projektphasen Ini-Plan-Control-End Organisations are sometimes unable to clearly express their business needs and goals. Lack of mutual understanding between the supplier and the customer is another reason. Deficiencies in Contract Monitoring and Risk management has also found be another critical factor Results or documents on the contractual level are deliverables and need to be quality reviewed in ISO9000 Methoden des SW-Projektmanagements 69

70 PM-Techniken pro Phase
Projekt-vorbereitung Istanalyse, Risikoanalyse, Maßnahmen zur Risikoreduktion, Auswahl von Angeboten Projekt-initialisierung Projektauftrag, Ziele, Organisationsmodelle Projekt- planung Produktstruktur, Projektstruktur, Arbeitspaket, Schätzung, Resourceneinteilung, Netzplan Projekt- steuerung Meilensteintrendanalyse, Konfliktmanagement, Feedback, Meetings, Kreativitätstechniken, Risikomanagement, Review, Test, Doku Vorbereitung (Anbahnung): Korrespondiert mit der Ausschreibung! (Warum, Was, Wie – Entscheidung!) Initalisierung (eigentlicher Start): Warum, Was, Wie (hinterfragen der Info, da oft andere Leute) Wie mit Experten prüfen! (hängt oft von Personen ab, welche Strategie nötig ist) -> Entscheidung über Strategie im Team (Teambildungsprozess! Gemeinsames Kommitment) Planung (im Detail): PL gibt groben Rahmen gemäß Vertrag, Urlaub, Kalender vor! PL rechnet immer rückwärts (Lieferdatum – Puffer, QS, Zwischenkontrolle, Entscheidungen..) Experten müssen selbst Inhalt und Details definieren! (Arbeitspakte, die vom PL geprüft werden können! Arbeitspakte für Kontierung!) Mitarbeiter planen eigene Zeit (Zeitplan der Experten und des Projekts ist machbar?) Mitarbeiter haben nötigen Skills? nötige Tools? nötige Info? Was fehlt? Steuerung: Mitarbeiter planen ihre Arbeitspakte, definieren ihre Lösungsstrategie, verwenden Vorgaben, Reports, Templates... Mitarbeiter erkennen Risiken, Probleme und berichten darüber in Teammeetings und machen technische Vorschläge PL erstellt: Templates, Regeln für Meetings, Moderiert, Integriert Arbeitspaketpläne, Präsentiert, Organisiert, Informiert... PL reagiert auf Probleme (Änderung der Gesamtplanung, mehr Ressourcen, besorgt zusätzliche Info, motiviert, holt Hilfe von außen) Abschluss: PL übergibt, PL sucht neues Projekt für Mitarbeiter, PL dokumentiert und archiviert und berichtet Projekt- abschluss Abnahme Lieferprodukte (Q-Merkmale) Lessons Learned (Story Telling , Kennzahlen) Methoden des SW-Projektmanagements 70

71 Analyse Techniken für Ist-Analyse und Problemanalyse (Motivation des Kunden verstehen, Ist = Meßlatte) Inventurmethode (messen, zählen, beobachten) ideal für Zahlenmaterial Fragebogenmethode für entlegene Standorte für anonyme Meinungen, Verbesserungen Berichtsmethode Kunde wird zur Selbstaufschreibung gebeten, gut für Prozesse (jedoch einzelne Sicht!) Interviewmethode Stimmungen einfangen, Information herauslocken Konferenzmethode wir sind nur Moderator oder informieren Analogiemethode zur Kontrolle oder zur Vorbereitung Anmerkung: Inventurmethode: Ideal zur Erstellung von Zahlenmaterial (Mengengerüste) Nicht Selbstzweck, sondern Voraussetzung für weiterführende Methoden. Bedingt geeignet für Meinungen, Stimmungen, Abläufe. Fragebogenmethode Rücklauf gering ungut für Prozesse Berichtsmethode Gefahr der Manipulation Interviewmethode Persönlichste aller Methoden (Motivierend, subjektiv) Unklarheiten können sofort geklärt werden Sehr zeitaufwändig Konferenzmethode („Gruppeninterview“) ideal für externe Berater nur sinnvoll mit gutem Betriebsklima und geeigneten Personen Methoden des SW-Projektmanagements 71

72 Entscheidungen des Kunden
Geschäftsmodell Was das Unternehmen zu leisten hat. Arbeitsmodell Wer ist wo verantwortlich? Änderungsgeschwindigkeit Informationstechnik Wie kann die Arbeit unterstützt werden? Methoden des SW-Projektmanagements 72 6

73 Schwachstellenanalyse
Schwachstellen in der Aufgabenerfüllung Bearbeitern Arbeitsabläufen Sachmitteln innerbetrieblicher Kommunikation Daten (Genauigkeit, Vollständigkeit, Aktualität)   Schwachstellen in den Auswirkungen quantifizierbaren Mängeln qualitative Mängel Schwachstellen in der Wirtschaftlichkeit nicht quantifizierbare Mängel bewerten über die Zeit kumuliert rechnen Schwachstelle in der Aufgabenerfüllung: z.B. zu späte Rechnungsschreibung, zu späte Mahnung, Differenzen in der Buchhaltung, lange Lieferzeiten, unausgelastete Maschinenkapazitäten, Maschinenausfälle. Schwachstellen in den Auswirkungen (Folgeschäden) z.B. Auftragsverlust, Zinsverlust, Überstunden, Wiederholläufe (Wieder-anlaufverfahren, Recovery) im EDV-Bereich z.B. Imageverlust, Verlust von Kunden und Marktanteilen, fehlende Info Wirtschaftlichkeit z.B. zu starke Kapitalbindung im Lager, zu hoher Materialverbrauch, zu teure Werbung Methoden des SW-Projektmanagements 73

74 Heuristiken bei der Analyse
Sozialer Ansatz IT-Experten alleine Anwender+Experten Cognitiver Ansatz große, komplexe Systeme, Komplexe Technik (Inventur/Analogie) Information oder Prozesse sind komplex. (Interview/Fragebogen/Bericht) Analytisch Unklare Situation Anwender nicht verfügbar (Prototyp, Modell anpassen) Unklare Situation Anwender sind verfügbar (Konferenz) Experimentell Methoden des SW-Projektmanagements 74

75 Klassifizieren der Risiken
Terminüberschreitung bei knapper Kalkulation falsche SW bei unklaren Anforderungen Netzausfall bei Störung Kein Projekt nach Vorarbeiten Schaden 2 Versicherung (z.B. Vertragsänderung) 1 Vorsorge (z.B. zweistufiges Projekt) 1 2 Projektmitarbeiter wird krank Budgetüberschreitung bei Kampfpreis 1. Vorsorge= z.B. Mitarbeit des Kunden für Klarheit der Anforderungen, Experten einschalten, zusätzliche Mitarbeiter zweistufig= z.B. erst Analyse, dann Festpreis, Prototyp zur Absicherung der Anforderungen, strenge Kontrolle 2. Versicherung, z.B. gegen Preisüberschreitung, Vertrag ändern und mehr Kosten über Folgeaufträge oder ähnliches reinholen, kritische Teile an 3. übergeben. - Angebot nicht abgeben! Wahrscheinlichkeit Methoden des SW-Projektmanagements 75

76 Risiken Definition Projekt nach DIN 69905:
Risiken sind Ereignisse durch die der "vorgesehene Ablauf oder Ziele des Projektes gefährdet werden„ Ein Projektrisiko kann qualifiziert werden hinsichtlich seiner Eintrittswahrscheinlich-keit seinen Auswirkungen technische Risiken betriebswirtschaftliche Risiken personelle Risiken politische Risiken Wettbewerbs- und Marktrisiken Risiken aus dem Projektumfeld (Verzögerung, Kostenerhöhung, Qualitätseinbuße) und dem von ihm verursachten Schaden. Technische Risiken: (z.B. Materialeigenschaften) Betriebswirtschaftliche (z.B. Bonität der Geschäftspartner) personelle (z.B. Krankheit, Kündigung usw.) Politische (z.B. Änderung der Unternehmensstrategie) Marktrisiko (z.B. Konkurrenzprodukt ist besser und billiger) Projektumfeld (z.B. Wetter) Methoden des SW-Projektmanagements 76

77 Analyse in der Initialisierung
Akquisitionsziel Abgrenzung Ziel der Beschaffung Kosten / Nutzen Paten / Politik Akquisitionsstrategie Lieferszenario Risikominimierung Beschaffungsstrategie Entscheidungspunkte Organisationsstruktur Ziel Business Case verändert verändert Problem/ Situation und verlangt In der Definition des Anschaffungsziels müssen die notwendigen Lieferprodukte und Leistungen identifiziert und die Anforderungen dafür festgelegt sein. Wenn das Anschaffungsziel nicht genau genug definiert ist, wird die Durchführung einer Anforderungsanalyse empfohlen. Ziel: Ausreichend genaue Informationen über die Anforderungen an die Systeme und Leistungen, die Gegenstand der Anschaffung sind. Input: Geschäftserfordernisse, Vorschlag eines Anschaffungsziels Aktivitäten: 1.        Zielbereich (möglicherweise mit Teilbereichen) definieren. (Schnittstellen) 2.        Anschaffungsziel im Hinblick auf die System- und Leistungsanforderungen präzise definieren. 3.        Kosten-Nutzen-Analyse. 4.        Interessen und Beteiligte feststellen. Ergebnis: Anschaffungsziel zu 3. Wichtig ist es, alle Kosten in Zusammenhang mit der Anschaffung zu identifizieren und nicht nur die Kosten für Hardwarekauf und Softwareentwicklung zu berücksichtigen. Beispiele für sonstige Kosten: Anschaffungsmanagement, Projekt- und Leistungsmanagement, Qualitätssicherung, Aufstellung von Testdaten, Schulung, Systeminstallation und Leistungsintegration. zu 4. Wenn die Akteure in der Anschaffung keinen Nutzen sehen, besteht die Gefahr einer negativen Einstellung Ziel: Definition einer situationsspezifischen Anschaffungsstrategie, Planung der wichtigsten Phasenentscheidungen für die Anschaffung und Festlegung der Anschaffungsorganisation. Input: Definition des Anschaffungsziels (System- und Leistungsanforderungen). 1.        Globale Szenarios für Anpassungen und Leistungserbringungen festlegen. 2.        Risiken analysieren. 3.        Anschaffungsstrategie anhand der Risikomanagementvorgaben festlegen: 4.        Die wichtigsten Phasenentscheidungen für die Anschaffung planen. 5.        Auftraggeberorganisation im Rahmen der Anschaffung aufbauen (z.B. Entscheidung über die Hinzuziehung externer Hilfe für das Anschaffungsmanagement). Strategie (machbar) birgt Risiken für verändert Methoden des SW-Projektmanagements 77

78 Vertragstypen Werkvertrag (§631 BGB) Herstellung eines Werkes
Garantie für Erfolg (AN) Garantie für Termin (AN) AG hat kein generelles Weisungsrecht, nur bezüglich des Ergebnisses (Werk) Vergütung: Festpreis Obergrenze nach Aufwand (Meilensteinabhängig) Dienstvertrag (§611 BGB) versprochener Dienst jeder Art Personalleistungs-vertrag Dienstleistungs-vertrag AG ist weisungsberechtigt Vergütung: nach Aufwand monatliche Zahlung Risiko Werkvertrag: technischer Erfolg Rechtzeitigkeit Kostendeckung Risiko Dienstvertrag Kündigung Bonität des AG Methoden des SW-Projektmanagements 78

79 Übungsaufgabe Wie könnte die Checkliste für ein Angebot aussehen?
Struktur des Angebots Situation und Aufgabe verstanden (warum) Liefer-/Leistungsumfang komplett, klar, messbar (was) Strategie dokumentiert Expertenwissen und ist der Situation angepasst (wie) Kosten/Termine korrekt, konsistent, plausibel (wann) Formale Kriterien Termin eingehalten alle Unterlagen beigelegt (Qualifikation) Unterschrift Risikocheck Machbar? (Größe, Komplexität, Unsicherheit) Vertragstyp? Personal vorhanden? Qualifikation vorhanden? Auftraggeber bekannt (liquide)? Unterauftragnehmer? Randbedingung: Struktur eine Angebots formale Ausschreibungsbedingungen Risikoanalyse Methoden des SW-Projektmanagements 79

80 Checkliste für Angebot
Struktur des Angebots Situation und Aufgabe verstanden (warum) Liefer-/Leistungsumfang komplett, klar, messbar (was) Strategie dokumentiert Expertenwissen und ist der Situation angepasst (wie) Kosten/Termine korrekt, konsistent, plausibel (wann) Formale Kriterien Termin eingehalten alle Unterlagen beigelegt (Qualifikation) Unterschrift Gewinnen wir die Ausschreibung? Wer ist die Konkurrenz? Was ist es dem Kunden wert? Was ist das Budget? Machen wir Profit? Machbar? (Größe, Komplexität, Unsicherheit) Vertragstyp? Personal vorhanden? Qualifikation vorhanden? Auftraggeber bekannt (liquide)? Unterauftragnehmer? langfristige Perspektive? Methoden des SW-Projektmanagements 80

81 Reiner Kostenvergleich
Nachteil: - Nutzen wird außer Acht gelassen - Kosten für Systeme, die es bisher noch nicht gab!?? - oft nur statische Geldwertbetrachtungen (Zinsen, Miete Leasing, Kauf) Ø Entwicklungsaufwand (Projektkosten) Ø Personalbedarf (Anzahl, Qualifikation) Ø grober Zeitplan für Entwicklung und Einführung Ø Schulungsaufwand für die Benutzer Ø Zusätzliche Hardwarekosten (z.B. Datenendgeräte, größere Platten) Ø einmalige Anschaffungs- und Umstellungskosten Ø laufende Betriebskosten (Strom, Kommunikation, Internet) Ø Folgekosten (Datenpflege, Programmwartung) Ø mögliche Einsparungen an Personal und Sachmitteln Methoden des SW-Projektmanagements 81

82 Nutzwertanalyse Kriterien Gewicht A B C (Misch) (HW) (SW) Preis HW 30% 30.000 3 20.000 5 40.000 1 Preis SW 20% 12.000 4 20.000 2 10.000 5 Erweiterungsfähigkeit HW 10% alles 5 nur Peripherie 3 keine 1 Garantie der SW–Pflege 20% evtl. 1 ab nä. Jahr 3 ja 5 Wartungsbereitschaft 15% 100 km 3 am Ort 5 1 Flug-std. 2 Anzahl Referenzinstallation 5% 15 5 3 1 6 3 Nutzwertanalyse (zum Vergleich verschiedener Alternativen) Vorgehensweise: -        Kriterienkatalog aufstellen -        Gewichte festlegen (Summe = 100%!) -        Gegenüberstellung der Alternativen (Angebote) -        Bewertung der Alternativen z.B. 5 (= sehr gut) bis 1 (= sehr schlecht) -        Gewichte * Bewertungspunkte -        Summen der Produkte pro Alternative è                    Nutzwerte è                    Alternative mit dem deutlich höchsten Nutzwert erhält den Zuschlag (bei "knappen Rennen" Sensitivitätsanalyse) Nutzwerte 100% 3,1 3,6 2,9 Bewertung: 5 starke Verbesserung ..... 1 starke Verschlechterung Das Angebot B hat den höchsten Nutzwert und erhält den Zuschlag Methoden des SW-Projektmanagements 82

83 Multifaktorenmethode
Beispiel: Einführung EDV im Lagerwesen Multifaktorenmethode Vorgehensweise: -        Kriterienkatalog aufstellen (möglichst unabhängige Kriterien) -        Gewichte festlegen (Gewichtung zur Priorität des Kriteriums) z.B. 3 sehr wichtig 2 erwünscht 1       nicht so wichtig -        Bewertung inwieweit das neue System zur Verbesserung oder Verschlechterung beiträgt z.B. +3 starke Verbesserung 0       keine Veränderung -3 starke Verschlechterung -        Ausmultiplikation: Gewichte * Bewertung -        Summe der Produkte (für das neue System) wird geteilt durch die Summe der Gewichte (= Ausdruck für den Ist-Zustand, das alte System); ergibt den Nutzenkoeffizient (Wirtschaftlichkeitskoeffizient). Wenn dieser Wert > 1 ist, verspricht das neue System eine verbesserte (indirekte) Wirtschaftlichkeit. Gewicht: +3 sehr wichtig 0 erwünscht -3 nicht wichtig Bewertung: +3 starke Verbesserung 0 keine Veränderung -3 starke Verschlechterung Nutzenkoeffizient 20/11 = 1,8 (Verbesserung) Methoden des SW-Projektmanagements 83

84 Methoden zur Angebotsauswahl
KO-Kriterien aufstellen  Andere Kriterien aufstellen  Kriterien wichten  Kostenvergleich: Gewichte = 1 Nutzwertanalyse:  Gewichte = 100% Multifaktorenanalyse: Gewichte = {3,2,1} Alternativen bewerten (subjektiv)  Kostenvergleich: Preis Nutzwertanalyse: {5,4,3,2,1} Multifaktorenanalyse: {+3,2,1,-1,-2,-3} Gewichte Summe = Ergebnis Sensitivitätsanalyse wenn knapp Kostenanalyse = monitärer Vergleich Nutzwert = Alt-neu Betrachtung Multifaktoren = Varianten Beurteilung (nicht monitär) Methoden des SW-Projektmanagements 84

85 PM-Techniken pro Phase
Projekt-vorbereitung Istanalyse, Risikoanalyse, Maßnahmen zur Risikoreduktion, Auswahl von Angeboten Projekt-initialisierung Projektauftrag, Ziele, Organisationsmodelle Projekt- planung Produktstruktur, Projektstruktur, Arbeitspaket, Schätzung, Resourceneinteilung, Netzplan Projekt- steuerung Meilensteintrendanalyse, Konfliktmanagement, Feedback, Meetings, Kreativitätstechniken, Risikomanagement, Review, Test, Doku Vorbereitung (Anbahnung): Korrespondiert mit der Ausschreibung! (Warum, Was, Wie – Entscheidung!) Initalisierung (eigentlicher Start): Warum, Was, Wie (hinterfragen der Info, da oft andere Leute) Wie mit Experten prüfen! (hängt oft von Personen ab, welche Strategie nötig ist) -> Entscheidung über Strategie im Team (Teambildungsprozess! Gemeinsames Kommitment) Planung (im Detail): PL gibt groben Rahmen gemäß Vertrag, Urlaub, Kalender vor! PL rechnet immer rückwärts (Lieferdatum – Puffer, QS, Zwischenkontrolle, Entscheidungen..) Experten müssen selbst Inhalt und Details definieren! (Arbeitspakte, die vom PL geprüft werden können! Arbeitspakte für Kontierung!) Mitarbeiter planen eigene Zeit (Zeitplan der Experten und des Projekts ist machbar?) Mitarbeiter haben nötigen Skills? nötige Tools? nötige Info? Was fehlt? Steuerung: Mitarbeiter planen ihre Arbeitspakte, definieren ihre Lösungsstrategie, verwenden Vorgaben, Reports, Templates... Mitarbeiter erkennen Risiken, Probleme und berichten darüber in Teammeetings und machen technische Vorschläge PL erstellt: Templates, Regeln für Meetings, Moderiert, Integriert Arbeitspaketpläne, Präsentiert, Organisiert, Informiert... PL reagiert auf Probleme (Änderung der Gesamtplanung, mehr Ressourcen, besorgt zusätzliche Info, motiviert, holt Hilfe von außen) Abschluss: PL übergibt, PL sucht neues Projekt für Mitarbeiter, PL dokumentiert und archiviert und berichtet Projekt- abschluss Abnahme Lieferprodukte (Q-Merkmale) Lessons Learned (Story Telling , Kennzahlen) Methoden des SW-Projektmanagements 85

86 Lastenheft und Pflichtenheft
Lastenheft DIN (Anforderungskatalog, Ausschreibung) AG beschreibt Umgebung Anforderungen (Funktionen, Eigenschaften) Schnittstellen Mengengerüst Zeit- und Kostenrahmen (oft Basis für Angebot, oft mit muss/kann/soll Unterscheidung) Pflichtenheft DIN (Grobkonzept, Angebot) AN beschreibt das Lieferprodukt/System Teilsysteme (Architektur) Funktionen / Input-Output / Oberfläche (Methoden / Klassen) Vorgehen Qualität (funktional / nicht-funktional) Kosten/Termine Wartungsleistung (grob, aber verbindlich und vollständig) Das Lastenheft (Requirements specification) DIN , VDI/VDE 3694: ..enthält die vom Auftraggeber festgelegten Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages (was soll erreicht, gemacht werden?). Im Pflichtenheft sind nach DIN die vom "Auftragnehmer erarbeiteten Realisierungsvorgaben" niedergelegt. Sie beschreiben die "Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts". Weitergehende Vorgaben werden von der DIN nicht gemacht. In einfachen Projekten (one step), beschreibt bereits das Angebot das Grobkonzept! In komplexeren Projekten wird das Grobkonzept erst in einem späteren Zeitpunkt als „Zwischenergebnis“ erstellt. Methoden des SW-Projektmanagements 86

87 Projektdoku - Auftrag interne Vereinbarung zwischen AG-AN
Projekthintergrund Ziele Wirtschaftlichkeit / Projektbegründung Anforderungen (grob) Abgrenzung Betroffene Schnittstellen Lösungsalternativen (grob) Grobe Vorgehensweise Rahmenbedingungen / Voraussetzungen Risiken, Schutzaspekte Projektorganisation Offene Punkte Projektbegründung Projektorganisation Personen Rollen AG-AN-QS Projektplanung interne externe interne Vereinbarung zwischen AG-AN Methoden des SW-Projektmanagements 87

88 Arbeitspaket (Auftrag)
Ziel Aufgabe Ergebnisse Rahmenbedingung Ressourcen Termine Warum? Was? Wie? ok Wann? verständlich (SMART) überschaubar (7-14 d) möglichst 1 MA (evtl. Zuarbeit von andern) S=Spezifisch, Simple M=Messbar A=attraktiv R=realistisch T=Timing Der langsamste, der sein Ziel nicht aus den Augen verliert, ist immer noch geschwinder als der, der ohne Ziel herum irret! (Lessing) Methoden des SW-Projektmanagements 88

89 Grobkonzept (Problemanalyse)
Ist-Analyse Ziele (messbar) Anforderungen (präzisiert) Sollkonzept für Kernprozesse Geschäftsprozesse Aufgabenhierarchie Aufbauorganisation Grobdatenmodell Schnittstellenübersicht Lösungsalternativen Lösungsvorschlag (ggf. IK-Vorlage) Sollkonzept Infrastruktur Leistungsstufen / Teilsysteme Warum? Was? Wie? ok Wann? Methoden des SW-Projektmanagements 89

90 Ziele SMART definieren
Ziele sollen SMART definiert werden S=spezifisch (eindeutig, präzise), M=messbar, A= akzeptiert, attraktiv, ausführbar, R= realistisch, T=terminierbar Was hier steht, wird in der Kontrolle überprüft! Was? S=Spezifisch, Simple M=Messbar A=attraktiv R=realistisch T=Timing Methoden des SW-Projektmanagements 90

91 Rollen im Projekt Externe Rollen Auftraggeber (AG) Projektbetreuer
Reviewer/Control Board Stakeholder Prozess-Owner /Aufsichtsrat (Chef des AG) Financial Controller Fachlicher Experte Nutzer Administrator Interne Rollen Auftragnehmer (AN) Projektleiter Projektmitarbeiter technischer Experte fachlicher Experte Qualitäts-verantwortlicher Verwalter Betroffene Rollen Abteilungsleiter Controller anderer Projektleiter Methoden des SW-Projektmanagements 91

92 Stabs-Projektorganisation
Vorteile schnelle Projektinitialisierung Know-how bleibt erhalten flexibler Personaleinsatz Nachteile Geringe Reaktions- geschwindigkeit (Instanzenweg) Geringere Projekt- verantwortung (kleine Projekte) Konflikte sind vorprogrammiert Leitung SysOp Web Java Admin Stab-Proj 1 Stab Proj 2 PL Stabs-Projektmanagement: Beim Einfluss-PM wird die funktionale Hierarchie unverändert übernommen und lediglich eine Stabstelle Projektkoordinator der Unternehmensleitung zugeordnet Es ist erforderlich, die Stabstelle genügend hoch anzusiedeln, damit der Projektleiter direkten Zugang zu den Führungskräften der einzelnen Fachbereiche erhält. Synonym werden auch die Begriffe „Stabs-Projektorganisation“ oder „Einmann-Projekt-Organisation“ verwendet Das Stabs-Projektmanagement ist typisch für Unternehmen mit einer reinen Linienorganisation, in der nur wenige, strategische Projekte durchgeführt werden. Der Projektleiter erhält hierbei eine direkt der Unternehmensführung zugeordnete Stabstelle. Dadurch wird deutlich, dass das Projekt von der Unternehmensführung gewünscht und unterstützt wird. Das Organisationskonzept PM in der Linie wird dann eingesetzt, wenn Projektmanagement verhältnismäßig geringe Bedeutung hat. PM in der Linie kann folgendermaßen beschrieben werden: Die Personal- und Führungsverantwortung für die Projektmitarbeiter verbleibt bei den Linienvorgesetzten. Der Projektleiter hat in der Regel nur eingeschränkte Weisungsbefugnis über seine Projektmitarbeiter. Linienarbeit hat tendenziell Vorrang. Projekte werden "nebenbei" gemacht. Methoden des SW-Projektmanagements 92

93 Matrix Projektorganisation
Vorteile Hohes Sicherheitsgefühl der Mitarbeiter Konfliktbewältigung auf mittlerer Ebene flexibler Personaleinsatz Know-how bleibt erhalten Nachteile Verunsicherung von Vorgesetzten Konflikte sind vorprogrammiert (Schlichter) Mitarbeiter ist „Diener zweier Herren" Hohe Kommunikationsbereitschaft nötig Querverrechnungen Leitung SysOp Web Java Admin Kunde1 Kunde2 Land PL Matrix - Projektmanagement: Das Matrix-Projektmanagement ist nur bei Divisional-, Matrix- und Tensor-organsiation einsetzbar Das Projekt wird unabhängig von Geschäfts- und Unternehmensbereichen direkt einer Projektzentralabteilung unterstellt Bei dieser Organisationsform wird die Organisationseinheit der Fachabteilung und dem Projektleiter unterstellt. Da ein Projekt zeitlich beschränkt ist, erhält es keine dauerhaften Mitarbeiter. Die Projektmitarbeiter werden vielmehr aus der Linienorganisation für das Projekt in einem bestimmten Umfang freigestellt. Die Projektmitarbeiter finden sich also in einer "Matrix" zwischen Linienorganisation und Projektorganisation wieder. Wenn die Freistellung für das Projekt nur teilweise ist, dann führt dies im Regelfall zu Konflikten zwischen Projektleitung und Führung der Linienorganisation bzw. zur Überlastung der Mitarbeiter. Fehler bei der Matrixorganisation eines Projektes sind die Hauptursache für die Ablehnung eines Projektes durch die Mitarbeiter eines Unternehmens. Der PMBOK beschreibt vier Stufen der Matrixorganisation: "Weak Matrix Organization", "Balanced Matrix Organisation", "Strong Matrix Organization" und "Composite Organization". Bei den ersten beiden Organisationsformen haben die Projektmanager keine eigene Stellung innerhalb der Unternehmenshierarchie, während es in der "Strong Matrix Organization" und der "Composite Organization" eine eigene Projektabteilung gibt, deren Abteilungsleiter, der Manager of Project Managers, gleichrangig mit den anderen Abteilungsleitern (Functional Manager) ist. Projektleiter und -mitarbeiter erfüllen parallel Linien- und Projektaufgaben. Im Rahmen des Projekts ist der Mitarbeiter dem Projektleiter unterstellt. Sobald der Mitarbeiter seiner Fachfunktion nachkommt, ist der Linienvorgesetzte zuständig. Die Personalverantwortung verbleibt üblicherweise in der Linie. Methoden des SW-Projektmanagements 93

94 Reine Projektorganisation
Vorteile konzentrierte Projektinitialisierung hohe Motivation Schnelle Reaktion bei Störungen Eindeutige Weisungs-befugnis direkter Zugang zum Chef Nachteile hohe Kosten Trennung von Fachabteilungen Know-how-Verlust bei Projektende Probleme bei der Wieder-eingliederung Leitung Projekt1 Projekt2 Abt1 Admin PL Reines Projektmanagement: Für das Projekt wird eine eigenständige Projektorganisation aus der Unternehmensorganisation gebildet Dies tritt auf, wenn innerhalb des Unternehmens funktionale Organisations-formen existieren Die Projektorganisation steht mit den funktionalen Bereichsleitungen auf einer Ebene und ist nur der Geschäftsleitung unterstellt Die reine Projektorganisation wird nur bei stark projektorientierten Unternehmen angewandt, die einen Großteil der Wertschöpfung in Projekten generieren. Der Projektleiter hat weitreichende Kompetenz innerhalb des Projekts. Die Projektmitarbeiter sind formal dem Projektleiter unterstellt. Die Projektmitarbeiter sind für die Dauer des Projekts meist zu 100 % für das Projekt abgestellt. Projekte funktionieren wie "Unternehmen auf Zeit" innerhalb der Organisation.  Methoden des SW-Projektmanagements 94

95 Teaming Kennenlernen Interviewspiel (Vorstellung eines Stargasts)
was bringt sie aus der Fassung? worüber können sie sich richtig freuen? wovor haben sie am meisten Angst? in welche Persönlichkeit würden sie gerne hineinschlüpfen? Gemeinsames Wochenende/Essen Gemeinsamer Erfolg Hochseilgarten, Rafting.. Präsenatation Nur mit gegenseitigem Vertrauen und Akzeptanz erreicht man Synergien. Mitarbeiter müssen Spaß am Projekt haben, d.h. das tun, was sie gut können, gelobt und anerkannt werden für ihre Leistung. Mitarbeiter wollen beteiligt sein am Weg zum Erfolg (Planung, Lösungsfindung, eigene Verantwortung) Mitarbeiter wollen die Umgebung verstehen in der sie arbeiten (Spielregeln). Übliche Rollen: Auftaggeber (extern) Entscheider (interner Auftragsverantwortlicher) PL Controller (für Technik, für Prozess, für Betriebswirtschaftlichkeit) Experte (Mitarbeiter) Methoden des SW-Projektmanagements 95

96 Teamentwicklung Selbstregelung Vertrauen gegenseitige Impulse
Kennenlernen Unsicherheit Platzfinden I Forming II Storming IV Performing III Norming Integration Regeln Kompromiss gemeinsames Ziel Rollenkampf Konflikte Cliquenbildung Konkurrenz Einfluss Methoden des SW-Projektmanagements 96

97 6. Übungsaufgabe: Wie viele Quadrate sehen Sie?
Randbedingung: 5!=5*4*3*2*1 1 5x5 pro Zeile 2 4x4 pro Zeile 3 3x3 pro Zeile 4 2x2 pro Zeile 5 1x1 pro Zeile eine 5er Gruppe alle andern alleine 5 min Zeit Methoden des SW-Projektmanagements 97

98 Aufgaben PL - Projektmitarbeiter
Projektleiter muss... planen strukturieren schätzen dokumentieren leiten delegieren organisieren (SPU, Meetings) motivieren, moderieren Störungen abhalten steuern kontrollieren berichten kommunizieren präsentieren Projektmitarbeiter muss... planen eigene Zeit planen dem PL helfen PL fragen, wenn nötig leiten Aufgaben selbständig erledigen (Verantwortung) entwerfen, konstruieren, erfinden, programmieren, testen berichten Aufwände, Status dokumentieren Probleme frühzeitig melden (Ehrlichkeit, mitdenken) Methoden des SW-Projektmanagements 98

99 Wiederholung: 3. Tag (Mini-Quiz)
Beschreiben Sie den Unterschied der Interview-Technik und der Fragebogen-Technik (Vorbereitung, Vor- und Nachteile) Welche Möglichkeiten zur Reduzierung des Risikos haben Sie in der Vorbereitungsphase (Auftraggeber, Auftragnehmer) Warum ist es wichtig den Projektauftrag zu definieren? Was sind die Vor- und Nachteile der Stabsorganisation? 1. Einführung Motivation Definition Abgrenzung Regelkreis 2. PM in IT 3-Ebenen Proj.-Phasen 3. Techniken I Vorbereitung Initiierung 4. Techniken II Planung Steuerung Abschluss 5. Kontrolle Interviewmethode ·        wird vorbereitet z.B. in Form eines Fragekatalogs und persönlich und mündlich durchgeführt ·        Vorteil ist die direkte Interaktion z.B. durch Nachfragen, das Einfangen von Stimmungen und die Analyse mit dem Befragten ·        Nachteil ist die Subjektivität und Abhängigkeit der Ergebnisse von der momentanen Situation und Fragetechnik des Interviewers, ·        Methode ist teuer, da hoher Aufwand für Durchführung und Nachbereitung nötig ist und den Betriebsablauf stört Vorteil der Stabs-PO (3 von 6) ·        Projektmitarbeiter und damit deren Wissen und Know-how bleibt in der Linie erhalten ·        Keine Probleme der MA bei der Beendigung eines Projektes, bzgl. Folgeauftrag ·        Gut geeignet für kleine Projekte, die meist an externe Berater vergeben werden ·        Schnell zu initiieren ·        Flexibler Personaleinsatz ·        Billige Variante, da kein Personal vorgehalten werden muss Nachteil der Stabs-PO (3 von 4) ·        Konflikte zwischen Projektleiter und Linienvorgesetzte, Zuständigkeit und Verantwortung unklar ·        Lange Durchlaufzeiten bei Probleme, z.B. über Mehrarbeit von MA ·        MA sind nicht 100% vom Tagesgeschäft befreit ·        Ungeeignet bei großen Projekten, da die Bedeutung der Projekte im Tagesgeschäft untergeht. Methoden des SW-Projektmanagements 99

100 PM-Techniken pro Phase
Projekt-vorbereitung Istanalyse, Risikoanalyse, Maßnahmen zur Risikoreduktion, Auswahl von Angeboten Projekt-initialisierung Projektauftrag, Ziele, Organisationsmodelle Projekt- planung Produktstruktur, Projektstruktur, Arbeitspaket, Schätzung, Resourceneinteilung, Netzplan Projekt- steuerung Meilensteintrendanalyse, Konfliktmanagement, Feedback, Meetings, Kreativitätstechniken, Risikomanagement, Review, Test, Doku Vorbereitung (Anbahnung): Korrespondiert mit der Ausschreibung! (Warum, Was, Wie – Entscheidung!) Initalisierung (eigentlicher Start): Warum, Was, Wie (hinterfragen der Info, da oft andere Leute) Wie mit Experten prüfen! (hängt oft von Personen ab, welche Strategie nötig ist) -> Entscheidung über Strategie im Team (Teambildungsprozess! Gemeinsames Kommitment) Planung (im Detail): PL gibt groben Rahmen gemäß Vertrag, Urlaub, Kalender vor! PL rechnet immer rückwärts (Lieferdatum – Puffer, QS, Zwischenkontrolle, Entscheidungen..) Experten müssen selbst Inhalt und Details definieren! (Arbeitspakte, die vom PL geprüft werden können! Arbeitspakte für Kontierung!) Mitarbeiter planen eigene Zeit (Zeitplan der Experten und des Projekts ist machbar?) Mitarbeiter haben nötigen Skills? nötige Tools? nötige Info? Was fehlt? Steuerung: Mitarbeiter planen ihre Arbeitspakte, definieren ihre Lösungsstrategie, verwenden Vorgaben, Reports, Templates... Mitarbeiter erkennen Risiken, Probleme und berichten darüber in Teammeetings und machen technische Vorschläge PL erstellt: Templates, Regeln für Meetings, Moderiert, Integriert Arbeitspaketpläne, Präsentiert, Organisiert, Informiert... PL reagiert auf Probleme (Änderung der Gesamtplanung, mehr Ressourcen, besorgt zusätzliche Info, motiviert, holt Hilfe von außen) Abschluss: PL übergibt, PL sucht neues Projekt für Mitarbeiter, PL dokumentiert und archiviert und berichtet Projekt- abschluss Abnahme Lieferprodukte (Q-Merkmale) Lessons Learned (Story Telling , Kennzahlen) Methoden des SW-Projektmanagements 100

101 Planungsprozess (1) Gantt Produktstrukturplan (Ergebnisstruktur)
Projektstrukturplan (Work Breakdown Structure) Ablaufplanung Terminplanung Arbeitspaketplanung Aufwandschätzung Ressourcenplanung Risiko- planung System Analyse Design Impl. Test Produktstruktur: Ergebnisse, wie sie im Angebot, Auftrag vereinbart sind! Projektstrukturplan: Ergebnisse, jeweils verfeinert um die Zwischenprodukte, die methodisch nötig sind, oder von verschiedenen Personen erstellt werden, oder zur Kontrolle (Abhängigkeiten) nötig sind. Ablauf: Balkendiagramm von H.L. Gantt für die logische Abfolgebeziehung der Vorgänge (vgl. Urlaubsplanung) Terminplan (1), rein auf grund der Abhängigkeiten der großen Brocken. HW Analyse Design Impl. Test SW Analyse Design Impl. Test Doku Analyse Design Impl. Test Gantt Methoden des SW-Projektmanagements 101

102 Planungsprozess (2) Gantt Produktstrukturplan Projektstrukturplan
Ablaufplanung (Abhängigkeiten berücksichtigen) Terminplanung (Zeiten / MA berücksichtigen) Arbeitspaketplanung Aufwandschätzung Ressourcenplanung Risiko- planung HW Test Produktstruktur: Ergebnisse, wie sie im Angebot, Auftrag vereinbart sind! Projektstrukturplan: Ergebnisse, jeweils verfeinert um die Zwischenprodukte, die methodisch nötig sind, oder von verschiedenen Personen erstellt werden, oder zur Kontrolle (Abhängigkeiten) nötig sind. Ablauf: Balkendiagramm von H.L. Gantt für die logische Abfolgebeziehung der Vorgänge (vgl. Urlaubsplanung) Terminplan (1), rein auf grund der Abhängigkeiten der großen Brocken. SW Doku Gantt T0 T0+1 T0+2 T0+3 T0+4 T0+5 Methoden des SW-Projektmanagements 102

103 Planungsprozess (3) Produktstrukturplan Projektstrukturplan
Ablaufplanung Terminplanung Arbeitspaketplanung Aufwandschätzung Ressourcenplanung Risikoplanung HW SW Doku T0+1 T0+2 T0+3 T0+4 T0+5 T0 Test AP Verantwortlich Aufwand Termin Interview mit AP1: Meier 6 Tage 31.3 X AP2: Müller+Josef 4 Tage 2.4 Y AP3: Meier 5 Tage 6.4 X AP4: Müller + Meier 1 Tag 7.4 Ablaufplanung kann sich ändern, wenn MA-Verfügbarkeiten und MA-Schätzung der Aufwandszeit und KalenderZeit berücksichtigt werden. Terminplanung mit MA abgestimmt (Feiertage nicht vergessen, Urlaub, Verfügbarkeiten von Interviewpartner etc.) QS-Maßnahmen nicht vergessen! Aufwandschätzung (bottom –up) Ressourcenplanung: Achtung ein MA kann nur einmal verplant werden! Risikoplanung gegen: Krankheit, zu optimistische Schätzung, nicht Verfügbare Technik.... Methoden des SW-Projektmanagements 103

104 Mitarbeiter - Zeit Teilbarkeit der Aufgabe Organisationsform
Kommunikation Methoden des SW-Projektmanagements 104

105 Einfluss der Kommunikation
Jeder spricht mit jeden anderen -> n (n-1)/2 D = 2 Std * Kn/K3 Weil 4 MA doppelt soviel kommunizieren (K4=2*K3), besprechen sie sich doppelt so lange! Weil 6 MA (= 2*3 MA) gleich 5x mehr kommunizieren (K6= 5*K3) -> 10 Std /Woche für Meetings! Kn=n*(n-1)/2 3 MA besprechen sich je 2Std pro Woche 4 MA besprechen sich je 4Std pro Woche! Methoden des SW-Projektmanagements 105

106 Mitarbeiter - Zeit ohne Kommunikation Zeit = Aufwand / MA
mit Kommunikation Zeit = Aufwand / (MA*Eff) Methoden des SW-Projektmanagements 106

107 Organisation der Kommunikation
Jeder spricht mit jeden anderen -> n (n-1)/2 Wenn man jedoch Teams bildet und die Kommunikation über festgelegte Kanäle (Informationsvermittler) ablaufen lässt, kann man das Kommunikationsaufkommen stark reduzieren. Bildung von Kernteams Austausch der Info der Teams über Sprecher (Teilprojektleiter, Infomanager) Bildung von Plattformen zum allgemeinen Info-Austausch (EDV = ein weiterer virtueller Infomanager) K5=5*(5-1)/2 = 10 K5=5 Methoden des SW-Projektmanagements 107

108 Zusammenfassung: Planung
Produktstruktur erstellen gemäß Entscheidungen AG muss vollständig sein! Projektstruktur erstellen gemäß Phasenmodell bis auf die Ebene der Arbeitspakete Schätzen der Aufwände (bottom-up) Vergleich mit Angebot Einteilung der Ressourcen gemäß der Faustformel: Zeit = Aufwand/MA möglichst MA ganz für einen Zeitraum Urlaub berücksichtigen Optimieren der Kommunikation Teams bilden / Teilprojekte Kommunikationsweg festlegen Regeln festlegen Risiken einplanen Buffer Maßnahmen Methoden des SW-Projektmanagements 108

109 Netzplantechniken CPM (Critical Path Methode)
Zeit pro Aktivität ist fix und wird mit Pfeil dargestellt Abhängigkeiten durch Knoten symbolisiert Optimieren durch Verkürzung der Zeit unter Erhöhung des Preises PERT (Programm Evaluation and Review Technique) Jedes Ereignis ist ein Knoten (EKN) Ein Ereignis hat eine Wahrscheinlichkeit (3 Werte) Gut für Risikoplanung Gantt (Balkendiagramm v. Betriebswirt H.L.Gantt) Aktivität als zeitlicher Balken (VKN) logische Abhängigkeiten durch Pfeile Der Begriff Netzplantechnik umfasst „alle Verfahren zur Analyse, Planung, Steuerung und Überwachung von Abläufen auf der Grundlage der Graphentheorie, wobei Zeit, Kosten, Einsatzmittel bzw. Ressourcen und weitere Einflussgrößen berücksichtigt werden können“ (DIN 69900, Teil 1). Ein Netzplan ist die „graphische oder tabellarische Darstellung von Abläufen und der Abhängigkeiten.“ (DIN 69900, Teil 1). Vorgang = Geschehen, das Zeit erfordert im Projektablauf Ereignis = Zustand im Projektablauf (Meilenstein) Anordnungsbeziehung = Abhängigkeiten (AOB) NF=Normalfolge, B beginnt nachdem A fertig ist. AF=Anfangsfolge, B beginnt, wenn A beginnt EF=Endfolge, A und B enden gleichzeitig SF=Sprungfolge, B endet, wenn A beginnt EKN= Ereignis-Knoten-Netz (Ereignisse sind Konten, z.B. PERT) VKN=Vorgangs-Knoten-Netz (Vorgang ist Knoten oder Balken (Gantt), z.B. MPM=Metra Potential Method) VPN=Vorgangspfeilnetz (Ereignis sind Knoten und Vorgänge sind Pfeile, Gantt wenn man Balken als Pfeil und Meilenstein als Knoten betrachtet) Methoden des SW-Projektmanagements 109

110 Anordnungsbeziehungen (EKN)
NF=Normalfolge EA-Beziehung Bestellung Bauteile Montage Entwicklung Elektronik Bestellung Bauelemente AF=Anfangfolge Überlappung (AA) EF=Endfolge EE Endmontage Inbetriebnahme Vorgang = Geschehen, das Zeit erfordert im Projektablauf Ereignis = Zustand im Projektablauf (Meilenstein) Anordnungsbeziehung = Abhängigkeiten (AOB) Vorwärtsrechung: wie lange dauert es Minimum? (progressive Zeitrechnung des frühesten Endtermins) Rückwärtsrechnung: wann muss eine Tätigkeit spätestens anfangen, damit alles wie geplant fertig wird? Gibt es bei einem Startvorgang und einem Endtermin einen geschlossenen Weg von Vorgängen ohne Puffer, so dies der kritische Pfad. SF=Sprungfolge unterbrechungsfrei AE Betrieb Neuanlage Abschalten Altanlage Methoden des SW-Projektmanagements 110

111 Schätzverfahren Analogieverfahren Vergleich mit ähnlichen Projekten (Erfahrungs-DB) Prozentverfahren Hochrechnung von vorausgegangenen Aufwänden auf die Zukunft gemäß Phasenverteilung ( ) ADesign=AEntwurf*20%/40% Faktoren-Verfahren Zusammenhang zwischen gemessener Produktgröße, Einflussfaktoren und geschätztem Aufwand A=f(M,E) z.B. CoCoMo, Function Point A= Aufwand M=Menge E= Einflussfaktoren z.B. SLIM (SW-Lifecycle Managment): A= 0,4*M³*T^(0,25)*C^(0,33) Methoden des SW-Projektmanagements 111

112 Analogieverfahren Schätzung durch Vergleich mit ähnlichen, bereits abgeschlossenen Projekten. Kann früher als andere Verfahren verwendet werden. Liefert aber nur Anhaltspunkte. Bezugsgrößen: Ø Lines of Code LOC Ø Anzahl Komponenten Ø Anzahl Testfälle Ø Anzahl Anforderungen Ø Anzahl Seiten Ähnlichkeit bezüglich: Ø Aufgabenstellung Ø Branche Ø Programmiersprache Ø Qualitätsansprüche" Methoden des SW-Projektmanagements 112

113 Prozentsatzverfahren
Zeitaufwand für die einzelnen Phasen wird als Prozentsatz der Gesamtzeit ausgedrückt. Voraussetzung: Die erste Phase ist bereits abgeschlossen. Bewertung: Die Vorleistungen in der ersten Phase müssen beurteilt werden, damit keine Über- bzw. Unterschätzung der restlichen Phasen erfolgt. z.B. geringe Vorleistungen -> wenig erfolgte Planung -> größere Nacharbeiten Je größer und komplexer ein Projekt ist, desto mehr Verwaltungs- und Planungsaufwand fällt an (hat sich in 1. Phase nicht niedergeschlagen). Methoden des SW-Projektmanagements 113

114 Prozentsatzverfahren (Beispiel)
+ PM ca. 10% + QM ca. 5% Methoden des SW-Projektmanagements 114

115 Faktoren-Verfahren Gesamtaufwand = Fachlicher Aufwand + DV-Aufwand
= FU*FT*FE + DU*DT*DE*DO*DW*DS FU /DU = Fachl. Umfang (#Funktionen) FT /DT = Tätigkeit (0,1 bis 1,1) FE /DE = Erfahrung für Tätigkeit DO = Organisatorische Schwierigkeiten DW = Wiederverwendung gewünscht DS = Maschinennahe Sprache Faktorenverfahren = Gewichtungsverfahren, Parametrische Schätzgleichungen, Multiple Regressionsanalyse Vorgehen: Faktoren so wählen, dass vergangene Projekte richtig geschätzt werden. FT: Faktor für die Tätigkeit, z.B: Ist-Aufnahme, organisatorische Änderungen etc. DO= an verschiedenen Orten, häufiger Wechsel der MA, großes Team DS= 1 für Assembler, 0,85 für problemorientierte Sprachen Methoden des SW-Projektmanagements 115

116 CoCoMo-Verfahren (Constructive Cost Model nach Barry Boehm)
Grundformel: MM = MF (Quan * Qual * Prod)EX MM = Mitarbeitermonate (1 MM = 20 MT = 160 Std) MF = Multiplikationsfaktor ,4 /2,7 /3,0 (Batch/gemischt/Online) Quan = Anzahl der unterschiedlichen Datenelemente und der Anweisungen aus dem Anweisungsteil des Programms, dividiert durch 1000 Qual = Qualitätsfaktor Prod = Produktivitätsfaktor EX = Exponent 1,05 /1,09 /1,12 (Batch/gemischt/Online) Qual: Faktoren zur Qualitätsbestimmung Zuverlässigkeitsgrad Sicherheit Effizienz (Zeitverbrauch) Effizienz (Speicherverbrauch) Benutzerfreundlichkeit Ausbaufähigkeit (Erweiterbarkeit) Übertragbarkeit (Portabilität) Wartungsfreundlichkeit Prod: Faktoren zur Produktivitätsbestimmung Kompatibilität Entwicklungsrechner zu Zielrechner Arbeitsbedingungen für die Entwicklung Verfügbarkeit des Entwicklungsrechners Spezifikations-, Entwurfs-, Prog.- und Testmethoden Spezifikations-, Entwurfs-, Prog.- und Testwerkzeuge Qualitätssicherungsprogramm Ausbildungsgrad der Entwickler Anwendungserfahrung der Entwickler Programmiersprachenkenntnisse der Entwickler DB/DC-Kenntnisse der Entwickler Methoden des SW-Projektmanagements 116

117 Schätzklausur Erläuterung der Methode (Moderator) 15 min
Arbeitstechnik, Regeln (Moderator) 10 min jeder unabhängig (Kärtchen, separat) Extreme Unterschiede diskutieren, ansonsten Mittelwert. Schätzgrundlagen (PL) 15 min Annahmen für die APs Schätzung der Arbeitspakete 2 Std Vorstellung des AP (Ergebnisse) Methode, Zwischenergebnisse, Tätigkeiten Mengengerüst (evtl. auch schätzen) Aufwand schätzen Dokumentieren der Annahmen plus Schätzung Einfachbefragung: ungenau, einseitig Mehrfachbefragung: repräsentativ, genauer Delphi-Methode: systematische Mehrfachbefragung. Kommunikation nur mit dem Koordinator. Alle bekommen alle Schätzungen und dürfen eigene geheim überarbeiten. (evtl. wiederholt) Schätzklausur: gruppendynamisch, offene Rede und Gegenrede, um die Schätzung zu begründen, wenn sie weit auseinanderliegen Methoden des SW-Projektmanagements 117

118 PM-Techniken pro Phase
Projekt-vorbereitung Istanalyse, Risikoanalyse, Maßnahmen zur Risikoreduktion, Auswahl von Angeboten Projekt-initialisierung Projektauftrag, Ziele, Organisationsmodelle Projekt- planung Produktstruktur, Projektstruktur, Arbeitspaket, Schätzung, Resourceneinteilung, Netzplan Projekt- steuerung Meilensteintrendanalyse, Konfliktmanagement, Feedback, Meetings, Kreativitätstechniken, Risikomanagement, Review, Test, Doku Vorbereitung (Anbahnung): Korrespondiert mit der Ausschreibung! (Warum, Was, Wie – Entscheidung!) Initalisierung (eigentlicher Start): Warum, Was, Wie (hinterfragen der Info, da oft andere Leute) Wie mit Experten prüfen! (hängt oft von Personen ab, welche Strategie nötig ist) -> Entscheidung über Strategie im Team (Teambildungsprozess! Gemeinsames Kommitment) Planung (im Detail): PL gibt groben Rahmen gemäß Vertrag, Urlaub, Kalender vor! PL rechnet immer rückwärts (Lieferdatum – Puffer, QS, Zwischenkontrolle, Entscheidungen..) Experten müssen selbst Inhalt und Details definieren! (Arbeitspakte, die vom PL geprüft werden können! Arbeitspakte für Kontierung!) Mitarbeiter planen eigene Zeit (Zeitplan der Experten und des Projekts ist machbar?) Mitarbeiter haben nötigen Skills? nötige Tools? nötige Info? Was fehlt? Steuerung: Mitarbeiter planen ihre Arbeitspakte, definieren ihre Lösungsstrategie, verwenden Vorgaben, Reports, Templates... Mitarbeiter erkennen Risiken, Probleme und berichten darüber in Teammeetings und machen technische Vorschläge PL erstellt: Templates, Regeln für Meetings, Moderiert, Integriert Arbeitspaketpläne, Präsentiert, Organisiert, Informiert... PL reagiert auf Probleme (Änderung der Gesamtplanung, mehr Ressourcen, besorgt zusätzliche Info, motiviert, holt Hilfe von außen) Abschluss: PL übergibt, PL sucht neues Projekt für Mitarbeiter, PL dokumentiert und archiviert und berichtet Projekt- abschluss Abnahme Lieferprodukte (Q-Merkmale) Lessons Learned (Story Telling , Kennzahlen) Methoden des SW-Projektmanagements 118

119 Kontrolle Termin Aufwand Qualität
+ Termin + Aufwand + Qualität Kontrolle Kurze Bestandsaufnahme nach festen Regeln zu festen Zeiten: Kenngrößen qualitätiv (TBQ) Kenngrößen quantitativ z.B. Schätzung des Restaufwands z.B. Vergleich Ist-Stunden/linearen Plan-Stunden z.B. Stundenverbrauch mit Fertigstellungsgrad Risikoüberwachung Probleme Planungsänderung nötig? Feedback vom PL Methoden des SW-Projektmanagements 119

120 Meilensteintrendanalyse
Berichtszeitpunkte Termine 15.3 1.4 1.5 15.5 1.7 3 2 2 1.7. 1.6 Idealer Fall Terminverzug Abbruch 1.5 1 Methoden des SW-Projektmanagements 120

121 Terminverfolgung Arbeitspakte AP1 AP2 fertig AP3 AP4 50% fertig fertig
Zeit heute Methoden des SW-Projektmanagements 121

122 Aufwandsverfolgung MA-Std V-Ist Obergrenze Risiko (Eskalation)
kalkulierter Aufwand 2 3 1 Erhöhung wegen Anforderungen Krankheit MA1 MA2 war effektiver als erwartet Berichtspunkte Methoden des SW-Projektmanagements 122

123 Phasenentscheidungssitzung
Sinn Controlling Eskalation, wenn nötig (Hilfe vom Mgt) Entscheidung des Mgt (Entlastung des PL) Agenda Bericht über die Phase (Zeit, Budget) Gutachten über Qualität der Ergebnisse Entscheidung (Abnahme, Maßnahme) Plan für nächste Phase Freigabe nächste Phase nächster Termin Protokoll Bei internen Projekten und bei Großprojekten erfolgt die Steuerung über Phasenentscheidungssitzungen. Das Management will aktiv entscheiden, ob das Projekt so fortgeführt wird oder nicht. -> sind Überziehungen ok -> sind Terminverschiebungen ok -> ist die bisherige Qualität ok -> ist der Plan für die nächste Phase ok Methoden des SW-Projektmanagements 123

124 Steuerung Aufnahme des Problems nicht den Boten bestrafen
Ursachensuche nur sinnvoll, um vergleichbares Problem zu vermeiden Kreative Lösung suchen Änderung der Netzplanlogik Änderung der Rahmen (Inhalt, Qualität, Zeit) Änderung der Methode (kaufen statt entwickeln) Hilfe bei Experten suchen (Delegieren) Verzögerung wo anders wettmachen Steuerung kommunizieren Neuer Plan Akzeptanz beim Entscheider, evtl. Auftraggeber Methoden des SW-Projektmanagements 124

125 Change-Request-Verfahren
Änderungswünsche werden gebündelt Es findet eine Entscheidung im Change Control Board statt, ob Änderung ohne Mehraufwand akzeptiert wird Änderung zu Mehraufwand führt Endtermin geändert wird Jeder Change des Kunden, der eine Auswirkung auf Zeit, Qualität oder Aufwand hat, ist eine Vertragsänderung! Methoden des SW-Projektmanagements 125

126 Risikomanagement „Risk management is a people issue“
Alle Projektbeteiligte tragen Risikoverantwortung Projektleiter initiiert und führt RM-Prozess durch Management ist in der Überwachung und Steuerung beteiligt Risiken verändern sich bzgl. Wahrscheinlichkeit, Dringlichkeit und Auswirkung Risiken + Maßnahmen müssen verfolgt werden RM-Prozess muss einfach und pragmatisch sein Dokumentation so viel wie nötig, so wenig wie möglich, Methoden des SW-Projektmanagements 126

127 Beispiele aus der Praxis....(PL)
Situation schon am Projektanfang reicht die geplante Zeit nicht! ein Arbeitspaket ist überfällig was ist die Konsequenz für das Gesamtprojekt? Auftraggeber sucht einen Schuldigen. Teammitarbeiter arbeitet in einem anderen Projekt Drohen oder belohnen? Tipp nicht drängeln, neu planen, Synergie ausnutzen neu planen – kritischer Pfad nicht mehr Leute! andere AP von Anfang an mit mehr Leute planen PM ist schuld! Vor das Team stellen. Einigung mit anderen Projekt suchen – ganz oder gar nicht Zeitweise, dann aber am Stück für ein AP. Am Anfang ist es wichtig, dass das Team zusammenwächst und Synergien entwickelt. Der Verzug eines AP kann nicht durch mehr Leute aufgeholt werden Man wird nicht in einem Monat Vater, wenn man gleichzeitig neun Frauen schwängert! 3.Der PM muss immer wissen wie sich ein Verzug auf das Ganze auswirkt. Viele AP können überlappen. Nur wo echte Abhängigkeiten da sind ist der kritische Pfad. Besser noch nicht begonnene APs mit mehr Personal planen und dort Zeit einholen. 4. Die Schuldfrage zerstört ein Team und auch die Synergie. Der PM muss alle Politik vom Team fernhalten! 5. Halbe – halbe führt immer zu Problemen – Rüstzeit beachten! kein Verlass auf Einsatz. 6. Drohungen motivieren nur bedingt zu höheren Leistungen. Eine Drohung kann so ernst sein wie sie will: Eine Aufgabe wird nicht termingerecht erledigt werden, wenn die veranschlagte Zeit zu knapp bemessen ist. Schlimmer noch: Wenn das Ziel nicht erreicht wird, muss man seine Drohungen womöglich wahr machen. Methoden des SW-Projektmanagements 127

128 Meetings (kurz-zielgerichtet)
Agenda vorbereiten Planung der Ergebnisse (was = warum) Planung des Ablaufs (wie) Meeting organisieren alle einladen (Agenda verschicken) Raum reservieren, Material bereit (Stift, Beamer) Pünktlich sein Durchführen Moderation (jeden hören – evtl. Kollegen bitten) Visualisieren der Agenda Visualisieren der Ergebnisse Protokoll der Ergebnisse Techniken wie: Blitzlicht, Visualisieren, Gruppenarbeit, Feedback, Moderation Klare Trennung von den Phasen: Kreativität, Diskussion, Entscheidung Entscheidungsprozess ist klar oder wird separat gemacht. Festlegung einer klaren, messbaren Zielsetzung. Handelt es sich um eine Informations-, Problemlösungs- oder Entscheidungskonferenz? Gute Organisation (Technik, Raum, Hilfsmittel) mittels Checkliste und Zeitplan (Anfang und Ende) sicherstellen. Inhaltliche Vorbereitung (Tagesordnungspunkte mit grober Zeiteinteilung pro Thema, Informationen, Unterlagen) aller Beteiligten veranlassen. Zeitrahmen setzen und einhalten. Die optimale Dauer liegt bei max. 90, besser nur 60 Minuten; bei zu vielen TOPs eine Pause einlegen. Pünktlich beginnen: Wer einmal wartet, wartet immer. Sind alle Unterbrechungsmöglichkeiten und Störfaktoren ausgeschaltet? Selbst- und Zeitdisziplin aller Beteiligten. Sind die Zeitführer ernannt und eine optimale Zeitdauer mit definiertem Ende für die Besprechung festgelegt worden? Visualisierungshilfen (Flipchart, Tafel, Overhead-Projektor, Arbeitsblätter) nutzen. Diskussionsbeiträge sollten für alle sichtbar aufgeschrieben werden. Konsequentes Konferenzmanagement: Begrenzen Sie Abschweifungen vom Thema und kontrollieren Sie, ob vereinbarte Zielsetzungen auch erreicht werden. Einigung und Entscheidung zur Ergebnissicherung mit Follow-ups: Wer macht was bis wann? Handschriftlicher Aktivitätenplan und Ergebnisprotokoll. Beides kann sofort fotokopiert und am Ende allen Beteiligten mitgegeben werden. Methoden des SW-Projektmanagements 128

129 PM-Techniken pro Phase
Projekt-vorbereitung Istanalyse, Risikoanalyse, Maßnahmen zur Risikoreduktion, Auswahl von Angeboten Projekt-initialisierung Projektauftrag, Ziele, Organisationsmodelle Projekt- planung Produktstruktur, Projektstruktur, Arbeitspaket, Schätzung, Resourceneinteilung, Netzplan Projekt- steuerung Meilensteintrendanalyse, Konfliktmanagement, Feedback, Meetings, Kreativitätstechniken, Risikomanagement, Review, Test, Doku Vorbereitung (Anbahnung): Korrespondiert mit der Ausschreibung! (Warum, Was, Wie – Entscheidung!) Initalisierung (eigentlicher Start): Warum, Was, Wie (hinterfragen der Info, da oft andere Leute) Wie mit Experten prüfen! (hängt oft von Personen ab, welche Strategie nötig ist) -> Entscheidung über Strategie im Team (Teambildungsprozess! Gemeinsames Kommitment) Planung (im Detail): PL gibt groben Rahmen gemäß Vertrag, Urlaub, Kalender vor! PL rechnet immer rückwärts (Lieferdatum – Puffer, QS, Zwischenkontrolle, Entscheidungen..) Experten müssen selbst Inhalt und Details definieren! (Arbeitspakte, die vom PL geprüft werden können! Arbeitspakte für Kontierung!) Mitarbeiter planen eigene Zeit (Zeitplan der Experten und des Projekts ist machbar?) Mitarbeiter haben nötigen Skills? nötige Tools? nötige Info? Was fehlt? Steuerung: Mitarbeiter planen ihre Arbeitspakte, definieren ihre Lösungsstrategie, verwenden Vorgaben, Reports, Templates... Mitarbeiter erkennen Risiken, Probleme und berichten darüber in Teammeetings und machen technische Vorschläge PL erstellt: Templates, Regeln für Meetings, Moderiert, Integriert Arbeitspaketpläne, Präsentiert, Organisiert, Informiert... PL reagiert auf Probleme (Änderung der Gesamtplanung, mehr Ressourcen, besorgt zusätzliche Info, motiviert, holt Hilfe von außen) Abschluss: PL übergibt, PL sucht neues Projekt für Mitarbeiter, PL dokumentiert und archiviert und berichtet Projekt- abschluss Abnahme Lieferprodukte (Q-Merkmale) Lessons Learned (Story Telling, Kennzahlen) Methoden des SW-Projektmanagements 129

130 Qualitätsdefinition Definition Qualität nach DIN 55350:
Die Gesamtheit von Eigenschaften eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht. bezieht sich auf Projekt und Produkt „geeignet für den Verwendungszweck“ Methoden des SW-Projektmanagements 130

131 Qualität nach ISO 9126 Funktionalität Angemessen Sicherheit
Genauigkeit Interoperabilität Konformität zu Standards Zuverlässigkeit Reife Fehlertoleranz, d.h. stürzt nicht ab bei Fehleingabe Wiederherstellbarkeit Effizienz Zeitverbrauch Speicherverbrauch Die Fähigkeit von Produkten ihre Aufgaben exakt zu erfüllen, wie sie durch Anforderungen und Spezifikationen definiert sind. Die Korrektheit ist ein Spezialfall. Die Zuverlässigkeit ist die Wahrscheinlichkeit, daß ein System verfügbar und korrekt arbeitet. geringen Fehlerrate Zeit bis zum nächsten Ausfall [mean time between failure] Die Effizienz ist die Eigenschaft eines Systems, seinen Zweck unter bestmöglicher Ausnutzung aller benötigten Ressourcen zu erfüllen. Harte Kriterien (direkt messbar) [Brö2000 S.99] 1. Funktionalität Die Fähigkeit von Softwareprodukten ihre Aufgaben exakt zu erfüllen, wie sie durch Anforderungen und Spezifikationen definiert sind. Die Korrektheit ist ein Spezialfall von Funktionalität. 2. Zuverlässigkeit Die Zuverlässigkeit eines Programms wird durch die Korrektheit und durch die Verfügbarkeit bestimmt. Sie ist die Wahrscheinlichkeit, daß das System innerhalb eines vorgegebenen Zeitintervalls eine Funktion für eine vorgegebene Anzahl von Eingabefällen unter festliegenden Eingabebedingungen erfüllt. Bei einer geringen Fehlerrate kann das Softwaresystem als zuverlässig angesehen werden. Die Zeit bis zum nächsten Ausfall [mean time between failure] ist ein Maß für die Zuverlässigkeit des Systems. 3. Effizienz (Performance) Die Effizienz ist die Eigenschaft eines Softwaresystems, seinen Zweck unter bestmöglicher Ausnutzung aller benötigten Ressourcen zu erfüllen. 4. Benutzbarkeit Die Benutzbarkeit umfasst die Adäquatheit, die Erlernbarkeit und die Robustheit eines Softwaresystems. ·     Unter der Adäquatheit versteht man die Forderung nach optimalem Bedienungskomfort bei der vom Benutzer verlangten Eingabe, der vom Softwaresystem angebotenen Leistung und der vom Softwaresystem produzierten Ergebnisse. ·     Die Erlernbarkeit eines Softwaresystems hängt unmittelbar von der Gestaltung der Benutzungsschnittstelle und der Klarheit und Einfachheit der Benutzeranleitung ab. ·     Unter der Robustheit eines Programmsystems versteht man die Eigenschaft, die Auswirkungen von Bedienungsfehlern, falschen Eingabedaten und Hardwarefehlern abzuschwächen. Weiche Kriterien (nicht messbar) --> Flexibilität 5. Wartbarkeit (Änderbarkeit ) Die Fähigkeit Änderungen an den Funktionen vornehmen zu können. z.B. Änderung der Mehrwertsteuer, neue Telefontarife, neues Postleitzahlensystem. Die Wartbarkeit eines Softwaresystems bezeichnet die Eignung ·     für die Lokalisierung von Fehlerursachen, ·     für die Durchführung von Fehlerkorrekturen und ·     die Eignung zur Veränderung oder Erweiterung der Programmfunktionen. D. h. die Wartbarkeit hängt von der Lesbarkeit, der Erweiter­bar­keit und der Testbarkeit eines Softwaresystems ab. 6. Portierbarkeit Darunter versteht man die Leichtigkeit, mit der ein Softwaresystem auf andere Rechner übertragen werden kann. Z.B. Wechsel des Betriebssystem, DBMS, TP-Monitor Methoden des SW-Projektmanagements 131

132 Qualität nach ISO 9126 Benutzbarkeit (Useabiltity,) Verständlichkeit Erlernbarkeit Bedienbarkeit Robustheit Änderbarkeit (Erweiterbarkeit, Wartbarkeit) Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Übertragbarkeit (Portabilität) Anpassbar, d.h. 100% portabel, wenn 0 Aufwand! Installierbarkeit Austauschbarkeit Die Benutzbarkeit umfasst die Adäquatheit, die Erlernbarkeit und die Robustheit eines Softwaresystems. Die Fähigkeit Änderungen an den Funktionen vornehmen zu können. Die Wartbarkeit hängt ab, von der Lesbarkeit, der Erweiterbarkeit und der Testbarkeit eines Systems. Darunter versteht man die Leichtigkeit, mit der ein System in einer anderen Umgebung verwendet werden kann. Harte Kriterien (direkt messbar) [Brö2000 S.99] 1. Funktionalität Die Fähigkeit von Softwareprodukten ihre Aufgaben exakt zu erfüllen, wie sie durch Anforderungen und Spezifikationen definiert sind. Die Korrektheit ist ein Spezialfall von Funktionalität. 2. Zuverlässigkeit Die Zuverlässigkeit eines Programms wird durch die Korrektheit und durch die Verfügbarkeit bestimmt. Sie ist die Wahrscheinlichkeit, daß das System innerhalb eines vorgegebenen Zeitintervalls eine Funktion für eine vorgegebene Anzahl von Eingabefällen unter festliegenden Eingabebedingungen erfüllt. Bei einer geringen Fehlerrate kann das Softwaresystem als zuverlässig angesehen werden. Die Zeit bis zum nächsten Ausfall [mean time between failure] ist ein Maß für die Zuverlässigkeit des Systems. 3. Effizienz (Performance) Die Effizienz ist die Eigenschaft eines Softwaresystems, seinen Zweck unter bestmöglicher Ausnutzung aller benötigten Ressourcen zu erfüllen. 4. Benutzbarkeit Die Benutzbarkeit umfasst die Adäquatheit, die Erlernbarkeit und die Robustheit eines Softwaresystems. ·     Unter der Adäquatheit versteht man die Forderung nach optimalem Bedienungskomfort bei der vom Benutzer verlangten Eingabe, der vom Softwaresystem angebotenen Leistung und der vom Softwaresystem produzierten Ergebnisse. ·     Die Erlernbarkeit eines Softwaresystems hängt unmittelbar von der Gestaltung der Benutzungsschnittstelle und der Klarheit und Einfachheit der Benutzeranleitung ab. ·     Unter der Robustheit eines Programmsystems versteht man die Eigenschaft, die Auswirkungen von Bedienungsfehlern, falschen Eingabedaten und Hardwarefehlern abzuschwächen. Weiche Kriterien (nicht messbar) --> Flexibilität 5. Wartbarkeit (Änderbarkeit ) Die Fähigkeit Änderungen an den Funktionen vornehmen zu können. z.B. Änderung der Mehrwertsteuer, neue Telefontarife, neues Postleitzahlensystem. Die Wartbarkeit eines Softwaresystems bezeichnet die Eignung ·     für die Lokalisierung von Fehlerursachen, ·     für die Durchführung von Fehlerkorrekturen und ·     die Eignung zur Veränderung oder Erweiterung der Programmfunktionen. D. h. die Wartbarkeit hängt von der Lesbarkeit, der Erweiter­bar­keit und der Testbarkeit eines Softwaresystems ab. 6. Portierbarkeit Darunter versteht man die Leichtigkeit, mit der ein Softwaresystem auf andere Rechner übertragen werden kann. Z.B. Wechsel des Betriebssystem, DBMS, TP-Monitor Methoden des SW-Projektmanagements 132

133 Testen Modul Test Daten Bericht Driver
Warum? Was? Wie? ok Wann? Testen Warum? Beweis, dass die Anzahl der Fehler eines realisierten Systems unterhalb einer definierten Schwelle liegt Was? Code, Modul, Gesamtsystem, Abdeckungsgrad, Test-Daten, Abnahme, Kriterien Wie? Manuel (Fagan, Testuser), Automatisch, wie oft Blackbox, Whitebox, Debugging, Trace Planen Wer, Wann, ...Test der Testumgebung Testen Testbericht Modul Test Daten Bericht Driver Testplanung welche Programme? welche Testdaten? wie viele Testdaten werden benötigt wer erstellt die Testdaten, wer ist verantwortlich? wer überwacht die Testdurchführung? wer testet? auf welchen Maschinen wird getestet? wer erstellt die Dokumentation? wer ist für die Testdokumentation verantwortlich? Methoden des SW-Projektmanagements 133

134 Abnahme Der Kunde prüft die Produkte gemäß Spezifikation im Angebot
Spezifikation laut Prozess Spezifikation laut vorheriger Phase Qualität bezüglich der Verwendung Gesetzliche festgelegter Abnahmeprozess AN gibt Produkt zur Abnahme frei AG hat 4 Wo um annehmen ohne Mängel annehmen mit Mängel ablehnen mit Begründung Methoden des SW-Projektmanagements 134

135 Wiederholung: 4. Tag (Mini-Quiz)
Welche Schätzverfahren kennen Sie? Was ist der Unterschied einer Schätzklausur einer Mehrfachbefragung? (Vorgehen, Vor- u. Nachteil) Was sind Knoten und Kanten? (EKN, VKN, VPN) Welche Anordnungsbeziehungen kennen Sie? Was sind die Qualitätsmerkmale nach ISO 9126? 1. Einführung Motivation Definition Abgrenzung Regelkreis 2. PM in IT 3-Ebenen Proj.-Phasen 3. Techniken I Vorbereitung Initiierung 4. Techniken II Planung Steuerung Abschluss 5. Kontrolle Tipps Wiederholung Vorgang = Geschehen, das Zeit erfordert im Projektablauf Ereignis = Zustand im Projektablauf (Meilenstein) Anordnungsbeziehung = Abhängigkeiten (AOB) NF=Normalfolge, B beginnt nachdem A fertig ist. AF=Anfangsfolge, B beginnt, wenn A beginnt EF=Endfolge, A und B enden gleichzeitig SF=Sprungfolge, B endet, wenn A beginnt EKN= Ereignis-Knoten-Netz (Ereignisse sind Konten, z.B. PERT) VKN=Vorgangs-Knoten-Netz (Vorgang ist Knoten oder Balken (Gantt), z.B. MPM=Metra Potential Method) VPN=Vorgangspfeilnetz (Ereignis sind Knoten und Vorgänge sind Pfeile, Gantt wenn man Balken als Pfeil und Meilenstein als Knoten betrachtet) Methoden des SW-Projektmanagements 135

136 Beurteilung des Erfolgs
Haben wir das Ziel erreicht? Haben wir gut zusammengearbeitet? Wo waren unsere Stärken? Was haben wir in diesem Projekt gelernt? Was werden wir in Zukunft anders machen? konstruktive Kritik! konstruktive Kritik Methoden des SW-Projektmanagements 136

137 Gründe für erfolgreiche Projekte
1. Einbindung der Nutzer 15,9% 2. Unterstützung durch das Management 13,9% 3. klare Anforderungen 13,0% 4. realistische Planung 9,6% 5. realistische Erwartungen 8,2% 6. kleine Abstände der Meilensteine 7,7% 7. erfahrenes und kompetentes Team 7,2% 8. Übernahme der Verantwortung 5,3% 9. klare Vision und Ziele 2,9% 10. konzentriert und gut arbeitendes Team 2,4%   andere 13,9% Transparenz Kommunikation Entscheidungen Regeln Ablage/ Dokumentation Methoden des SW-Projektmanagements 137

138 Tipp Ein Tag, der am Anfang eines Projekts verloren geht, tut genauso weh wie ein Tag, der am Ende verloren geht. Begrenzen Sie Verluste: Blasen Sie scheiternde Anstrengungen frühzeitig ab – ohne Wenn und Aber. Sie können Ihre Gesamtleitung stärker durch Eindämmen der Misserfolge als durch Optimierung der Erfolge verbessern. Drohungen motivieren nur bedingt zu höheren Leistungen. Eine Drohung kann so ernst sein wie sie will: Eine Aufgabe wird nicht termingerecht erledigt werden, wenn die veranschlagte Zeit zu knapp bemessen ist. Schlimmer noch: Wenn das Ziel nicht erreicht wird, muss man seine Drohungen womöglich wahr machen. Es gibt endlich viele Möglichkeiten, einen Tag zu vertun ... aber keine einzige, ihn zurückzubekommen. Methoden des SW-Projektmanagements 138

139 Kommunikationstheorie
Jede Nachricht wird von 4 „Ohren“ empfangen. „Ziehe dich warm an, es ist kalt“ kann bedeuten: Sachohr -> es ist kalt Beziehungsohr -> Du bist klein und ich muss dich bemuttern Selbstoffenbarungsohr -> es hat sich früher nie jemand um sie gekümmert Appellohr -> zieh Dich an! ich bin doch kein kleines Kind Wenn man ein Beziehungsproblem hat, redet man auf der Sachebene aneinander vorbei: Mutter: Zieh dich warm an! Kind: Es ist nicht kalt (ich bin doch kein kleines Kind) Die Ablehnung ist gegen die Botschaft auf der Beziehungsebene! Methoden des SW-Projektmanagements 139

140 7. Übungsaufgabe: Hören sie auf allen 4 „Ohren“!
Sehen Sie man kommt hier her und will gute Arbeit leisten und dann erkennt man, dass alles sinnlos ist, weil der Vorgesetzte alles anders macht. Sie können doch nicht wirklich erwarten, dass ich eine Arbeit von zwei Wochen in einer erledige. Unser neuer Kollege glaubt, das Schießpulver erfunden zu haben. Ich bin nicht schuld! Das ist zwar ehrgeizig, aber Sie schaffen das schon. Randbedingung: in 2er Gruppen 15 min Zeit Methoden des SW-Projektmanagements 140

141 Gute Kommunikation Beziehungsebene klären
Statt auf dem Beziehungsohr, das Gras wachsen hören: positive Unterstellung Beziehungsprobleme offen ansprechen Im Vorfeld die Beziehungsebene zusichern: Schulterklopfen, Lächeln, klare Ansage Konflikt auf der Sachebene als Chance sehen These-Antithese: Synthese Widerspruch als neuer Aspekt Anerkennen und auf Lösungssuche gehen Nicht: entweder/oder, sondern: oder auch Guter Stil Sachlich bleiben Ausreden lassen, aber selbst kurz halten Regeln vereinbaren Feedback seines Beziehungs-Ohr geben. (keine Du-Botschaften, keine Anschuldigung) Methoden des SW-Projektmanagements 141

142 Gesprächsführung Gesprächsbereitschaft sicherstellen
Rahmen setzen (Thema) Frage nach Zeit Akzeptanz der Situation Problem schildern persönliche Sicht (Ich-Botschaft) Abgleich des Verständnisses Gegenseitige Erwartungen (Ziele) persönliche Sicht (Lösungsvorschlag) Frage nach anderer Sicht Einigung/Entscheidung Vereinbarung der nächsten Schritte Wann berichten über Erfolg? Dank und Verabschiedung Rahmen setzen: Kontakt nehmen, Stimmung ausloten 2. Situation Lage definieren (Selbsteröffnung, Gefühl, Begründung...) z.B. ich bin ratlos, ich bin enttäuscht, ich habe das Gefühl..., dies ist für mich wichtig, weil.. Einwände klären (Zuhören, präzisieren wenn nötig) z.B. Offensichtlich haben sie Schwierigkeiten, bitte erzählen sie dies genauer.. Gemeinsame Sicht der Lage abholen (Bestätigung, Gemeinsame Basis!) 3. Gemeinsames Verständnis des Ziels möglicherweise auch hier: Einwände klären Absichern der gemeinsamen Sicht Lösungsstrategie erarbeiten (Vorschlag ist immer erwünscht) Alternativen finden 4. Entscheidung = Vereinbarung über Ziel über Strategie über konkrete Schritte über messbaren Erfolg (wann berichten) Der Vorgesetzte sollte an der Stelle, den MA motivieren: positive Zieldarstellung, positive Aussichten Dank und Verabschiedung. Methoden des SW-Projektmanagements 142

143 Sandwich Feedback - Beispiele
So geht es nicht weiter Herr Meier! Ihre Präsentation ist katastrophal! Gut finde ich Ihren Mut zu schwierigen Themen Stellung zu beziehen. Im Mittelteil ist mir aufgefallen, dass viele Zuschauer irritiert waren. Mich hat ihr Zeigestab auch nervös und kribbelig gemacht. Vielleicht könnten sie sich etwas einfallen lassen, die Ergebnisse besser zu visualisieren. Im Vergleich zu früher war dies schon viel besser. Weiter so! Methoden des SW-Projektmanagements 143

144 Feedback geben Positive Basis schaffen (Rahmen setzen) z.B. darf ich Ihnen meine Wahrnehmung/Meinung schildern? Wahrnehmung mitteilen (Situation aus persönlicher Sicht) z.B. ich hatte beobachtet... Persönliche Reaktion = Wirkung beschreiben z.B: da habe ich mich geärgert... Ziel als persönlichen Wunsch formulieren (möglicherweise als Frage verpacken) z.B: Können Sie beim nächsten Mal...? Nutzen für beide Seiten darstellen (positive Gesamtaussage) Unterschied: A: So geht es nicht weiter, Herr Meier! Ihre Präsentation ist katastrophal! B: Gut finde ich Ihr Engagement und ihren Mut zu diesem schwierigen Thema Stellung zu beziehen. Beim Mittelteil ist mir aufgefallen, dass viele Zuhörer sehr irritiert waren. Auch ich hatte Schwierigkeiten ihnen zu folgen. Mich hat ihr häufiges Spiel mit dem Zeiger stark abgelenkt. Ich würde mir eine bessere Gliederung und Visualisierung wünschen. Vielleicht können Sie sich dazu etwas einfallen lassen. Im Vergleich zu früheren Präsentationen, was diese deutlich besser. Weiter so. Methoden des SW-Projektmanagements 144

145 Feedback bekommen Fragen (eigener Rahmen) oder aktiv annehmen (Antwort auf Rahmen) Aktiv zuhören (Fragen, selbst wiederholen, keine Argumentation!) z.B: habe ich richtig verstanden..., Sie haben das so empfunden..? Nachdenken, nachempfinden Versuchen in den anderen zu spüren z.B. aha, da muss ich darüber nachdenken, welche Auswirkungen das hat... Bedanken für das Feedback (Feedback akzeptieren) Es wird keine sofortige Lösung/Änderung erwartet! Keine Verteidigung. Kein Kampf.. Methoden des SW-Projektmanagements 145

146 Reaktionen auf Killerphrasen
"Wie kommen Sie gerade jetzt auf diese Frage?" "Nach dieser Killerphrase kommen wir zurück zur Sache." "Soso!" "Vielen Dank für diesen Hinweis.„ "Wenn es Ihnen hilft, gebe ich Ihnen gerne Recht." "Wenn Sie darunter verstehen, dass..." "Lieber die Taube auf dem Dach als der Spatz in der Hand“ oder "Weil wir gerade davon reden, haben Sie den interessanten Film am Freitag über die Buschkaninchen gesehen.... Killerphrasen: „Tja, wenn das alles ist, was Sie aufbereitet haben ..." oder „Da hätte ich ja schon mehr von Ihnen erwartet" "Wie kommen Sie gerade jetzt auf diese Frage?" Sie stellen also eine Gegenfrage und bringen damit Ihren "Gegner" aus dem Konzept, denn viel eher hat er ja damit gerechnet, dass Sie sich jetzt rechtfertigen oder emotional reagieren. "Nach dieser Killerphrase kommen wir zurück zur Sache." Sie decken also die Machenschaften Ihres Gegenübers auf und kommen zu Ihrem Thema zurück. "Soso!" Sie antworten mit einem zweisilbigen Kommentar, z.B. Ach was. Sag bloß. Und mit nichts weiter, auch, wenn Ihnen noch das eine oder andere auf der Zunge liegt. Mit dieser Minimalantwort lassen Sie jeden "Killerphrasendrescher" auflaufen. "Vielen Dank für diesen Hinweis." Sie gehen über diesen Angriff einfach hinweg und beziehen sich inhaltlich mit keinem Wort darauf. "Vielen Dank für diese Lebenshilfe." Mit einem Kompliment strafen Sie Ihren Gegner und er fühlt sich sicher gar nicht wohl in seiner Haut. "Ich mag die Art, wie Sie die Worte aneinander reihen." Ist eine etwas ironische Alternative. "Sie meinen also, die Sachlage ist so - na, wenn ausgerechnet Sie das sagen." Sie wiederholen den Inhalt der Killerphrase, allerdings mit einem ebenso ironischen Unterton. "Wenn es Ihnen hilft, gebe ich Ihnen gerne Recht." Sie geben anscheinend nach und stimmen Ihrem Gegner zu - damit hat er nun ja überhaupt nicht gerechnet. Allerdings können Sie diese Taktik nur anwenden, wenn Sie es unbeschadet überstehen, also nicht, wenn es z.B. um Ihre fachliche Kompetenz geht. "Lieber die Taube auf dem Dach als der Spatz in der Hand." Oder ein beliebiges anderes Sprichwort. Der Angreifer wird so verwirrt sein, dass er noch Tage zu grübeln hat, was Ihr Sprichwort mit seinem Angriff zu tun hat. "Wenn Sie darunter verstehen, dass..." Wenn jemand zu Ihnen sagt: “Sie sind aber faul!“, kommt es doch nur darauf an, was der Einzelne unter "faul" versteht. Antworten Sie doch einfach mit einer Umdefinition, hier zum Beispiel: "Wenn Sie darunter verstehen, dass ich gut delegieren kann, dann gebe ich Ihnen gerne recht!" Methoden des SW-Projektmanagements 146

147 Konfliktmanagement – WinWin
Konfliktlösung auf der Sachebene nach Harvard-Verhandlungsmodell: gemeinsame Interessen suchen und sichern meist hinter den Interessen = Motivation unterschiedliche Ziele motivieren und anerkennen Alternative Wege suchen Objektive Kriterien zur Bewertung suchen und vereinbaren Kompromiss schließen Kontrolle vereinbaren Konflikte auf der Beziehungsebene über Zuhören, Feedback, Spiegeln Reindenken mit positiver Unterstellung Moderator/ Mediator wir ich du Konflikte als Chance sehen! These – Anti-These – Synthese! Sachkonflikte machen Spaß, weil jeder dazulernt. Dies ist wesentlich besser als zu grantln und ewige Feindschaft zu starten! z.B.: Konflikt : Zugriff von außen auf das Firmennetz (Pos1) - Sichern des Netzes (Pos2). gemeinsame Motivation: Firma soll profitieren Positionen bezüglich der gemeinsamen Motivation erklären und akzeptieren Alternative Wege suchen -> Sicherheitssystem installieren – kostet aber Geld! – Ist es das wert? Kompromiss: Pos1 zahlt, Pos2 realisiert Kontrolle: läuft in 2 Monaten. Generell gibt es verschiedene Konfliktursachen: Zielkonflikt (gegensätzliche Ziele und Interessen) -> nach Harvard Positionen über dahinterliegende Motivation erklären Beurteilungskonflikt (unterschiedlicher Informationsstand, unterschiedliches Vorgehen, unterschiedliche Erfahrung) -> Kennen, berücksichtigen, entscheiden Verteilungskonflikt (ungenügend Mittel, hohe Ansprüche) -> hören, erklären, Kompromiss suchen (Firmeninteresse) Wertekonflikt (unterschiedliche Einstellungen) -> erfordert Toleranz, erfordert Einsatz der Mitarbeiter dort, wo sie gut sind! Beziehungskonflikt (Vorurteile, Misstrauen, Ablehnung) -> Aussprache, Vertrauen ineinander schaffen (Teamingprozess) Methoden des SW-Projektmanagements 147

148 8. Übungsaufgabe Spiel: Konfliktlösung nach dem Harvard-Modell
Sie sind SysOp und sind für die Sicherheit des IT-Systems verantwortlich. Zugriff von außen ist sehr gefährlich. Ihr Kollege will für eine Präsentation beim Kunden einen Zugriff von außen, um zu zeigen die Firma ist Spitze in IT. Spiel: Konfliktlösung nach dem Harvard-Modell 1. Warum? - fachliche Anforderungen - unabhängig von Technik - Konsequenzen, wenn eine Anforderung nicht erfüllt wird - Nötiges Verständnis für Entwickler und Designer, um die richtigen Designentscheidungen zu treffen 2. Was? - siehe Gliederung (muss evtl. angepasst werden) 3. Wie? - Offen 4. Wann? 20 miin 5. Tun! 6. Kontrolle - Präsentieren - Arbeitspakte? - Schätzung, Abhängigkeiten? Randbedingung: 2 Gruppen 20 min Zeit Methoden des SW-Projektmanagements 148

149 Konfliktarten Konfliktart Ursache Lösung Verteilung knappe Ressourcen
Prioritäten, Kriterien Beziehung schlechte Erfahrung, Stil Vertrauen aufbauen, Umgangsformen Rollen Rollen nicht geklärt klären Entschei-dung/ Ziel unterschiedliche Prioritäten, Vorstellungen gemeinsamer Nenner, Motivation Werte /Meinung kulturelle Ursache, innere Werte, Geschmack nicht lösbar -> Toleranz Es gibt auch verschiedene Entscheidungsarten: gemeinsame Entscheidung Minderheitsentscheidung Mehrheitsentscheidung Konsens Methoden des SW-Projektmanagements 149

150 Entwicklung eines Konflikts
Sachliche Meinungsverschiedenheit (Argumentation) Machtkampf (Koalitionen, „ums Prinzip“, Angriff auf der persönlichen Ebene) Zerstörung (Mobbing, Drohung, Sabotage) Für/Wider-Liste objektive Kriterien finden Wichtung der Kriterien Abstimmmodus Beziehung klären übergeordnete Ziele finden über den Weg einigen (Regeln) Moderator externe Hilfe Bruch/Trennung ansprechen Methoden des SW-Projektmanagements 150

151 Konfliktsymptome Angriff (verbal) Widerspruch Vorwurf Drohung
Nebenkriegsschauplatz Angriff (non-verbal) Unruhe Intriege Mobbing Sabotage Flucht (verbal) Schweigen Bagatellisieren Standardantwort Dienst nach Vorschrift Flucht (non-verbal) Unaufmerksamkeit Müdigkeit Krankheit innere Kündigung Methoden des SW-Projektmanagements 151

152 Techniken zur Kreativität
Brainstorming Aufnahme von Ideen Gegenseitige Stimulation keine Diskussion, keine Frage, keine Kritik Gruppenarbeit 3-5 Mitglieder Effektivität steigern durch Wettbewerb mit anderen Gruppen Präsentation der Ergebnisse (MindMap) Diskussion jeden hören Bodo-Hüte verteilen Devils Advokat spielen (was wäre das schlechteste?) STOP-Technik (Denkmuster erkennen) Nachteil des Brainstorming: viel Ausschuss, einzelne Mitglieder verstecken sich in der Gruppe Brainwriting: systematische Weiterentwicklung von Grundideen. Wenn alle Ideen auf dem gleichen Prinzip beruhen: Moderator ruft STOP! und macht alle auf die festgefahrene Denkmuster aufmerksam! -> man geht eine Stufe abstrakter und dann wieder kreativ in die Tiefe. Visualisieren der Kreativität mittels MindMap -> alles darstellen -> keine Wertung -> viele Verknüpfungen sind möglich -> einzelne Äste können verschieden tief gehen Analogien suchen, z.B: UBoot in Pinguin-Form.. Methoden des SW-Projektmanagements 152

153 ´6 Thinking Hats' (Edward de Bono)
focus on the data available look at problems using intuition, gut reaction, and emotion look at all the bad points of the decision think positively (vision, optimistic) think creatively (no critisism) control process (chairing meeting) Example: The directors of a property company are looking at whether they should construct a new office building. The economy is doing well, and the amount of vacant office space is reducing sharply. As part of their decision they decide to use the 6 Thinking Hats technique during a planning meeting. White Hat - analyze the data. - examine the trend in vacant office space, which shows a sharp reduction. - anticiipate that by the time the office block would be completed, that there will be a severe shortage of office space. - current government projections show steady economic growth for at least the construction period. Red Hat - some of the directors think the proposed building looks quite ugly. - while it would be highly cost-effective, they worry that people would not like to work in it. Black Hat - they worry that government projections may be wrong. - economy may be about to enter a 'cyclical downturn', in which case the office building may be empty for a long time. - if the building is not attractive, then companies will choose to work in another better-looking building at the same rent. Yellow Hat - if the economy holds up and their projections are correct, the company stands to make a great deal of money. - If they are lucky, maybe they could sell the building before the next downturn, or rent to tenants on long-term leases that will last through any recession. Green Hat - think whether they should change the design to make the building more pleasant. - perhaps they could build prestige offices that people would want to rent in any economic climate. - alternatively, maybe they should invest the money in the short term to buy up property at a low cost when a recession comes. Blue Hat - has been used by the meeting's Chair to move between the different thinking styles. He or she may have needed to keep other members of the team from switching styles, or from criticizing other peoples' points. Six Thinking Hats is a good technique for looking at the effects of a decision from a number of different points of view. It allows necessary emotion and skepticism to be brought into what would otherwise be purely rational decisions. It opens up the opportunity for creativity within decision-making. The technique also helps, for example, persistently pessimistic people to be positive and creative. Methoden des SW-Projektmanagements 153

154 Motivation für Risikomanagement
Ursachen für unzufriedene Kunden (zu spät / zu teuer / keine Qualität): Kein Projektmanagement (fehlende Projektkontrolle, kein Änderungsmanagement) Chaotische Prozesse (improvisierend, teure Nacharbeiten, keine Disziplin) Feuerwehreinsätze (Risiken werden zu Problemen) Fehlende Basis (unverstandene Anforderungen, unzureichende Planungsbasis) Schlechtes Management (fehlende Verantwortung, Kompetenzen, Motivation) Methoden des SW-Projektmanagements 154

155 Risikomanagement Definitionen
Nach PMBOK (Project Management Body of Knowledge): Risiko: Ein unsicheres Ereignis oder Bedingung, die im Eintrittsfall einen positiven (!) oder negativen Effekt auf die Projektziele hat Risiko = Eintrittswahrscheinlichkeit * Auswirkungen Risikomanagement: Systematischer Prozess der Identifikation, Analyse und Antwort auf ein Projektrisiko Nach DIN 69905: Risikomanagement: Ausschaltung, Vermeidung oder Verringerung von Projektrisiken Identifizierung und Bewertung gehört zur Risikoanalyse! Methoden des SW-Projektmanagements 155

156 Nutzen von Risikomanagement
Fokussierung der begrenzten Ressourcen Problemverhinderung reduziert Zeit und Aufwand Schätzungen und Projektpläne werden zuverlässiger Die Eigner der Risiken werden klar erkennbar Verbessert die Qualität und Vorhersehbarkeit im Projekt Entkriminalisiert Risiken Bedeutet eine Kulturveränderung (Risiko + Ignoranz = Problem) Risiken und Nutzen wachsen parallel Die Wahrscheinlichkeit wächst, ein Produkt zur rechten Zeit mit den richtigen Inhalte in geforderter Qualität im geplanten Budget zu liefern Methoden des SW-Projektmanagements 156

157 Der Prozess des Risikomanagements
Identifizierung Verfolgung Strategie Bewertung Abschwächung Methoden des SW-Projektmanagements 157

158 Risiken identifizieren
Arten siehe Seite 76 Techniken zur Identifizierung Brainstorming SWOT-Analyse (Strengths, Weaknesses, Opportunities, Threats) Bedrohungsszenarien Frühere Probleme, Erfahrungen, Ursachen Interviews Konfliktanalyse Checklisten Werkzeuge Methoden des SW-Projektmanagements 158

159 Die wichtigsten Risiken der Softwareentwicklung
Unzureichende Ressourcen Unrealistische Zeit- und Budgetplanung Falsche Funktionen werden entwickelt Falsche Benutzerschnittstelle Over Engineering Ständige Änderungen der Anforderungen Unzureichende Qualität externer Komponenten Lieferantenverzug Unzureichende Performance Technologieüberforderung Methoden des SW-Projektmanagements 159

160 Template für den Risikoplan
Inhalt Beschreibung Beispiel Identifikation Jedes Risiko hat Namen, Nummer, PROJ-Zuordnung Project-2012, Risc_01 Rangnummer Wichtigste Risiken zuerst 2 Kurze Beschreibung (Ursache und Effekt) Test-Infrastruktur nicht verfügbar Bewertung Eintrittswahrscheinlichkeit und Auswirkungen zu verschiedenen Zeitpunkten Identifiziert: Wahrscheinlichkeit: 3 Auswirkung: 4 (Termin) Indikator Verfolgung des Status und frühe Warnung Verfügbarkeitstermin Status Wenige definierte Statusklassen offen Abschwächung Aktionen zur Abschwächung mit Zeitplan und Verantwortlichen Externer Lieferant als backup ab verfügbar Verfolgung Zeitplan und Verantwortung für Aktionen Weickert, 07/2012, Review 08/2012 Budget Eingeplante Aufwände für Abschwächung Evolution Kriterien für Neubewertung, Notfallplan Eigene Infrastruktur vorhanden Notfallplanung Spezifischer Plan für Risiken, die häufig auftreten Nichtanwendbar Methoden des SW-Projektmanagements 160

161 Mathematische Risikobewertung
Das Risiko macht ein an sich singuläres Ereignis quantifizierbar und erlaubt eine vergleichende Bewertung Das Risiko erlaubt, Ungunstereignisse zu quantifizieren und in Ihrer Gesamtheit zu betrachten Die Addition aller Risiken erlaubt, den Gesamtschaden mit einem Gesamtaufwand zur Abschwächung zu vergleichen und in die Kalkulation mit einzubeziehen Die quantifizierte Risikobetrachtung hilft dabei, Abläufe und Prozesse systematisch dort zu verbessern, wo es am meisten Nutzen bringt und sie erlaubt systemische Analysen von zusammmengesetzten Risiken Methoden des SW-Projektmanagements 161

162 Risikobewertung einfach halten (1)
Wahrscheinlichkeit Stufe Wert Kriterien 5 So gut wie sicher Alles deutet darauf hin, dass dies zum Problem wird 4 Sehr sicher Große Wahrscheinlichkeit, dass dies zum Problem wird 3 Wahrscheinlich (50/50) Gleichverteilte Chance, dass dies eintritt 2 unwahrscheinlich Manchmal wird dies zum Problem 1 Fast unmöglich Sehr unwahrscheinlich, dass dies jemals eintritt Methoden des SW-Projektmanagements 162

163 Risikobewertung einfach halten (2)
Auswirkung Stufe Wert Kriterien: Technisch /Kosten / Zeitrahmen 5 Katastrophal Keine Kontrolle möglich / >50 M€/ Abbruch 4 kritisch Gravierende Mängel / M€ / Einfluss auf Folgeprojekt 3 mittelmäßig Beträchtliche Abweichungen /1 -10 M€ / Beträchtlich, Umplanung 2 gering Performanceeinflüsse/ 0,1 – 1M€ / > 1 Monat Verzögerung 1 vernachlässigbar Unbedeutend / unbedeutend / unbedeutend Methoden des SW-Projektmanagements 163

164 Risikobewertung: Rechenbeispiel
Risikoeintritt: Wahrscheinlichkeit und Verlust Kritischer Fehler gefunden Risiko Summe Ja P=0,75 L=5 Mio k. F. nicht gefunden 3,75 Mio Kosten 5 Mio. kein k.F. P=0,05 L=30 Mio 1,5 Mio 6,25 Mio Regressionstest P=0,20 L=5 Mio 1,0 Mio Kritischer Fehler gefunden P=0,30 L=1 Mio 0,30 Mio Kosten 1 Mio. Nein k. F. nicht gefunden 13,50 Mio P=0,50 L=26 Mio 13 Mio Kein k. F. P=0,20 L=1 Mio 0,20 Mio Methoden des SW-Projektmanagements 164

165 Risiken abschwächen Vermeiden (d.h. Eintrittswahrscheinlichkeit reduzieren und damit aber auch nicht die Chancen wahrnehmen, die aus dem Eingehen des Risikos entstehen könnten) Begrenzen (d.h. Auswirkungen begrenzen, z.B. mit verschiedenen Vertragsmodellen, also ähnlich der Wirkung einer Haftpflichtversicherung ggf. mit Selbstbeteiligung als max. Kosten) Behandeln (setzt an beiden Faktoren an und optimiert die Summe der Risiken mit begrenztem Aufwand, ist somit ein zusätzlicher Aufwand, um mit kreativen Lösungen die Eintrittswahrscheinlichkeit oder die Auswirkungen reduzieren) Ignorieren (setzt die Wahrnehmung des Risikos ungeachtet der Eintrittswahrscheinlichkeit und der Auswirkungen auf Null, ...) Methoden des SW-Projektmanagements 165

166 Risiken verfolgen Grundfragen:
Greifen die vereinbarten Aktionen zur Abschwächung? Sind die Risiken und vereinbarten Aktionen noch relevant? Hat sich ihre Bewertung verändert? Hat sich der Status der Risiken verändert? Sind die Risiken zu einem Problem geworden? Gibt es neue Risiken? Methoden des SW-Projektmanagements 166

167 Tipps zur Risikoverfolgung
Die wichtigsten Risiken kontinuierlich verfolgen Nur so viele Risiken verfolgen wie Kapazitäten zur Abschwächung eingeplant sind Verfolgung einfach halten mit standardisierten Templates Keine Bestrafung für das Kommunizieren von Risiken Risiken müssen auch mal in Kauf genommen werden und gleichzeitig abgeschwächt werden (unerwartete Risiken, die bei Auftreten zum Problem werden sind das eigentliche Problem) Hinreichend genaue Notfallpläne falls Risiken doch mal eintreten (damit es keine Panik gibt,...) Dokumentation und somit Auditierbarkeit der Risikoverfolgung (vgl. Gesetzgebung bei Kreditvergabe!) Formalisierte und systematische Reviews zur Fortschrittsverfolgung, Statusbewertung, Entscheidung zwischen handlungsalternativen, Zuweisung von Ressourcen Methoden des SW-Projektmanagements 167

168 Risikostrategie Risikostrategie als Anleitung für das Tagesgeschäft
Umgang mit typischen sich wiederholenden Risiken Risikomanagement als skalierbarer Prozess (Risikomanagement funktioniert auch unter unterschiedlichen Randbedingungen) Systematisierung der internen und externen Kommunikation von Risiken (intern zur Standardisierung des Risikomanagements, extern, um Verbindlichkeit gegenüber Kunden zu erzeugen) Risikomanagement vor Projektstart (die meisten späteren Probleme sind vor Projektstart bekannt!) Konsistenz des Risikomanagementprozesses (Risikostrategie als verbindliche Richtlinie für das ganze Unternehmen) Methoden des SW-Projektmanagements 168

169 Literaturhinweise Projekt Management Body of Knowledge (PMBOK) International Competence Baseline (ICB) vor allem Buchliste, Kurse u. Veranstaltungen Wissensdatenbank mit 1500 Beiträgen Glossar Project management Framework (PMF) (englisch, aber viele Artikel) Normen: DIN 69901, PMBOK*, ICB**, PMF *** *Die Grundbedeutung von "Project Management Body of Knowledge" ist zunächst das gesamte Wissen und der gesamte Erfahrungsschatz aller Projektmanager(innen) weltweit. Nachdem dieses Abstraktum schwer zu greifen ist, bemüht sich das Project Management Institute (PMI, Pennsylvania, USA), den "Common Ground" dieses PMBoK in seiner Veröffentlichung "A Guide to the Project Management Body of Knowledge" zusammenzustellen und wiederum allen Projektmanager(innen) an die Hand zu geben. (http://www.projektmagazin.de/glossar/) ** International Competence Baseline (http://gpm-ipma.de/index.html) *** Project management Framework (http://www.its.qut.edu.au/pp/framework/) Methoden des SW-Projektmanagements 169


Herunterladen ppt "Methoden des SW-Projektmanagements"

Ähnliche Präsentationen


Google-Anzeigen