Projektmanagement. Projekt und Projektorganisation Projektziele Kick-off Phasen- und Entwicklungsmodelle Change Management Projektplanung

Transkript

1 Projektmanagement Projekt und Projektorganisation Projektziele Kick-off Phasen- und Entwicklungsmodelle Change Management Projektplanung Oktober 2012, Robert Kolb

2 Themen Was ist ein Projekt?, Eckpfeiler eines Projekts Was ist Projektmanagement?, Projektorganisationsformen Rollen von Auftraggeber und Projektleiter Projektziele Kick-Off Meeting Phasen und Entwicklungsmodelle Change Management Projektplanung Anhang Literaturhinweise 2

3 Lernziele Sie können die Eckpfeiler eines Projekts aufzählen und kennen mögliche Organisationsformen Sie können erklären, wozu Projektziele benötigt werden und wie diese Ziele formuliert sein sollten Sie können den Zweck und die Bedeutung des Kick-off Meetings erläutern Sie können aus Projektzielen einen Projektstrukturplan und daraus eine Tätigkeitsliste erstellen 3

4 Was ist ein Projekt? 4

5 Die Eckpfeiler eines Projekts Qualität und Funktionalität Kosten Zeit Am Anfang eines jeden Projekts steht die Analyse, was genau zu erstellen ist. Spezifikation Das Budget, welches einem Projekt zur Verfügung gestellt wird, richtet sich nach den Kosten, die geschätzt wurden und nach dem, was das Unternehmen dafür ausgeben kann oder will. Budget Ein Projekt ist durch feste Zeitbegrenzungen limitiert. Zu einem bestimmten Zeitpunkt muss das Endprodukt fertig und den Benützern überstellt sein. Terminplanung 5

6 Was ist anders im Projekt Mitarbeiter müssen mehr Unsicherheiten aushalten können Aufgabe ist ungewohnt und kann zunächst unüberschaubar sein Anforderungen können häufig und überraschend wechseln Hierarchie ist nicht gefestigt Arbeit beschränkt sich nicht auf vertraute Umgebung Kontakte und Kommunikation mit Bereichen ausserhalb des Projekts und ausserhalb des eigenen Fachgebietes sind notwendig Keine Aussicht auf feste Position in einem Hierarchiegebilde 6

7 Projektmanagement und Projektorganisation 7

8 Aufgaben des Projektmanagements Abgrenzen des Problems und der Aufgabenstellung Vereinbarung der Ziele und des Vorgehens Durchführung von realistischen Schätzungen Planung, Einsatz und Disposition der Ressourcen Durchsetzung der Qualitätsanforderungen Überwachung und Steuerung des Projektablaufes Projektmarketing Führung der Projektgruppe Gestaltung sozialer Prozesse 8

9 Projektorganisation Die Projektorganisation ist eine spezielle temporäre Organisation für die Dauer des Projekts. Die Projektorganisation passt sich über die verschiedenen Lebensphasen hinweg immer wieder dem Projekt an. Nach Projektende wird die Projektorganisation aufgelöst. Die grundsätzlichen Organisationstypen unterscheiden sich primär in der Art und Weise, wie sie mit der Linienorganisation verknüpft sind. Je nach Organisationstyp hat der Projektleiter mehr oder weniger Kompetenzen bzw. das Projektteam einen grösseren oder kleineren Freiheitsgrad bezüglich seiner Arbeit. 9

10 Reine Projektorganisation (1) GL F&E Produktion Vertrieb Finanzen MA MA MA MA MA MA MA MA MA MA MA MA Projektleiter MA MA MA MA MA

11 Reine Projektorganisation (2) Charakteristik Praktisch eine eigenständige Organisation (Schattenorganisation). Kann als Extremform sogar als Projektgesellschaft (= eigenständige Organisation) geführt werden (PL = Unternehmensleiter). PL und Teammitglieder sind vollamtlich im Projekt. Im Vergleich zu anderen Organisationsformen besitzt der PL eine relativ weitgehende Verfügungsgewalt, d.h. er ist mit sämtlichen Führungs- und Entscheidungskompetenzen ausgestattet. PL trägt Verantwortung für die Zielerreichung in sachlicher, terminlicher und kostenmässiger Hinsicht. 11

12 Reine Projektorganisation (3) Weitere Bezeichnung: Task Force, Parallel-Linienorganisation Voraussetzung: - Komplexes, innovatives Projekt mit Bedarf an hoch qualifizierten und vollamtlichen Mitarbeitern - Projekte die unter Zeitdruck stehen und mit grosser Unsicherheit behaftet sind - Notwendigkeit des dauernden Informationsaustausches und einer intensiven Abstimmung der Aktivitäten zwischen Projektmitgliedern Eignung: Die reine Projektorganisation eignet sich für ausserordentlich grosse Vorhaben, die relativ wenig Berührung zu den herkömmlichen Aufgaben haben (z.b. Entwicklung einer völlig neuen Produktelinie, Erstellung eines Neubaus) 12

13 Reine Projektorganisation (4) Effiziente Organisation für Grossprojekte Schnelle Reaktion bei Störungen Hohe Identifikation des Teams mit dem Projekt Optimale Orientierung aller Tätigkeiten und Ressourcen auf das Projektziel hin Wenig Personalflexibilität, besonders bei nur zeitweise benötigten Spezialisten Rekrutierung (und Wiedereingliederung nach dem Projektende) von Projektmitarbeitern kann schwierig sein Gefahr einer autoritären, nicht teamorientierten Führung (da Projektleiter umfassender Vorgesetzter) 13

14 Stabs-Projektorganisation (1) GL Projektleiter F&E Produktion Vertrieb Finanzen MA MA MA MA MA MA MA MA MA MA MA MA

15 Stabs-Projektorganisation (2) Charakteristik Minimalform einer Projektorganisationsform. Funktionale Hierarchie bleibt bestehen, wird nur um Stabsstelle (Projektkoordination) ergänzt. Der Koordinator ist verantwortlich für die rechtzeitige Information der entsprechenden Linieninstanzen, hat aber keine Weisungsbefugnisse diesen gegenüber. PL ist nicht unbedingt eine vollamtliche Stelle PL kann nicht für die sachliche, terminliche und kostenmässige Erreichung bzw. Nichterreichung der Projektziele verantwortlich gemacht werden. 15

16 Stabs-Projektorganisation (3) Weitere Bezeichnung: Projektkoordination, Einfluss-Projektorganisation Voraussetzung: - Der Projektablauf und die Aufgabenstellung sind den Beteiligten grundsätzlich bekannt. - Der PL ist fachlich und/oder führungsmässig so gut qualifiziert, das ein Projekterfolg auch ohne weitgehende Kompetenzen des PL wahrscheinlich ist. - Geringer zeitlicher Druck Eignung: Die Stabs-Projektorganisation eignet sich für kleinere Projekte, die den Rahmen der herkömmlichen Aufgaben nicht wesentlich übersteigen (z.b. grosse Kundenaufträge, Produkteweiterentwicklung, Rationalisierung). Gut geeignet für Projekte, deren Ziel es ist, Informationen zu sammeln. 16

17 Stabs-Projektorganisation (4) Hohes Mass an Flexibilität hinsichtlich des Personaleinsatzes Relativ einfacher Erfahrungsaustausch und einfache Erfahrungssammlung über die verschiedenen Projekte Keine organisatorische Umstellung Niemand fühlt sich für das Projekt verantwortlich Geringe Reaktionsgeschwindigkeit Organisationsübergreifende Sichtweise erschwert Kein eigentliches Projektteam 17

18 Matrix-Projektorganisation (1) GL F&E Produktion Vertrieb Finanzen Projektleiter MA 11 MA 21 MA 22 MA 32 MA 43 MA MA MA MA MA MA MA

19 Matrix-Projektorganisation (2) Charakteristik Projektbezogen sind die Verantwortung und Kompetenzen zwischen dem PL und den Linieninstanzen aufgeteilt. Diese Aufteilung kann in weiten Grenzen variieren. Der PL koordiniert sämtliche funktionalen Tätigkeiten der Linieninstanzen. Die Kompetenzlinien kreuzen sich bei den jeweiligen Mitarbeitern, dabei kann es zu Konflikten kommen. Kombination aus reiner Projektorganisation und Stabs- Projektorganisation. 19

20 Matrix-Projektorganisation (3) Ist in der Praxis die weitaus häufigste Organisationsform. Voraussetzung: - Lösung besonders schwieriger Aufgaben, in Bezug auf terminliche Festsetzung und Koordination zwischen Spezialisten. - Der Mitarbeitereinsatz ist im Zeitablauf unterschiedlich stark, die Projektmitarbeiter sind in der Regel noch teilweise in ihren Abteilungen tätig - Notwendigkeit eines Projektleiters, der auch die Vorgehensverantwortung trägt. Eignung: Die Matrix-Projektorganisation hat einen weiten Anwendungsbereich, sofern die Problematik der Kompetenzkonflikte bewältigt werden kann. Geeignet für Neuentwicklungen von Produkten, Einführung neuer Arbeitsmittel, Fusionen von Unternehmungen. 20

21 Matrix-Projektorganisation (4) PL und Team fühlen sich verantwortlich für das Projekt Eindeutige Projektverantwortung und Entscheidungskompetenz beim Projektleiter Flexibler Personaleinsatz, keine Auslastungsprobleme Kontinuität der fachlichen Weiterbildung, kein Kontaktverlust zur Linie Zielgerichtete Koordination verschiedener Interessen Gefahr von Kompetenzkonflikten zwischen Linien- und Projektautorität Verunsicherung von Vorgesetzten (Verzicht auf Ausschliesslichkeitsanspruch) und Mitarbeitern (Diener zweier Herren) Hohe Anforderungen an die Informations- und Kommunikationsbereitschaft Relativ hoher Organisations- und Kostenaufwand 21

22 Kompetenzen PL Kompetenzen nach Organisation Je nach Projektorganisation hat der Projektleiter wenige bis viele Kompetenzen Stabs- Projektorganisation Matrix- Projektorganisation Reine Projektorganisation 22

23 Scrum: Team Organisation (1) Im Gegensatz zu Projekt Teams sollten Scrum Teams nicht als temporäre Organisationen verstanden werden Team Grösse sollte nicht zu gross werden (< 9 Mitglieder, optimal ca. 5) -> Ineffizienz durch zuviele Absprachen steigt erheblich Team Skills sollten gemischt sein, analog zu Projekt Teams. Spezialisten sparsam einsetzen, damit Wissensaustausch stattfinden kann/muss. 23

24 Scrum: Team Organisation (2) Know-how ist in den Köpfen und im Code, wenig(er) Dokumentation für Know-how Transfer vorhanden -> Team Zusammensetzung stabil halten Velocity (Team Performance) sollte einschätzbar sein, da Planungsgrundlage -> Team Zusammensetzung stabil halten Besser Feature Teams bilden als Komponenten Teams, um Kundennutzen schneller zu erzeugen 24

25 Die Rolle des Auftraggebers Wer zahlt, befiehlt!? 25

26 Aufgaben des Auftraggebers Abstecken der strategischen Randbedingungen Durchsetzen der übergeordneten Unternehmensinteressen gegenüber PL und Linienchefs Formulieren des Auftrages, bzw. der Projektvereinbarung Mit dem Projektleiter Meilensteine definieren und deren Erreichung überwachen Bestimmen des Projektleiters Projektorganisation festlegen Fällen von Freigabe-Entscheiden sowie wichtigen Teilentscheiden Bei Engpässen festlegen von Prioritäten 26

27 Fallen bei der Integration des Auftraggebers (1) Passen Sie auf, dass der Auftraggeber... Die Projektvereinbarung schon zu Beginn messbar formuliert Nicht permanent versucht, neue Wünsche und Ergänzungen durchzusetzen (dadurch besteht die Gefahr, dass der Leistungsumfang erweitert wird, was in Zusatzkosten resultiert) Nicht zahlreiche unnötige Vor-Ort-Gespräche anberaumt (verursacht zusätzliche Kosten, Zeitverlust) 27

28 Fallen bei der Integration des Auftraggebers (2) Passen Sie auf, dass der Auftraggeber... Nicht auch bei internen Entscheidungsprozessen Einfluss nehmen will (dadurch besteht die Gefahr, dass er das Projekt in eine bestimmte Richtung lenkt) Sich überhaupt nicht einbeziehen lassen will (dadurch besteht die Gefahr, dass die Überraschungen zum Projektende kommen) 28

29 Die Rolle des Projektleiters Der Projektleiter als Generalist 29

30 Aufgaben des Projektleiters im Detail (1) Projektvereinbarung mit dem Auftraggeber aushandeln Überprüfen der Auftragsgrundlagen auf Vollständigkeit und Eindeutigkeit Bilden des Projektteams Durchführen des Kick-off Meetings Erarbeiten des Projektplanes Erstellen eines Termin- und Kostenplanes Koordination der Projektbeteiligten und Organisation des Projektteams Führen der Projektgruppe Beschaffen von erforderlichen projektspezifischen Informationen Interne Projektbesprechungen in regelmässigen Abständen 30

31 Aufgaben des Projektleiters im Detail (2) Intensiven Kontakt zum Auftraggeber pflegen Schriftliches Festhalten der Änderungswünsche des Auftraggebers Regeln der Projektdokumentation, des Berichts- und Informationswesens Regelmässige Projektfortschrittsberichte für Vorgesetzte und Auftraggeber erstellen (z.b. wieviel % sind erledigt?) Kosten-, Leistungs-, Termin- und Qualitätskontrolle Durchführen der Abschlussbesprechung beim Auftraggeber Abschlussmeldung an die Rechnungsabteilung Präsentation des Projekts Durchführen eines Debriefings des Projektteams 31

32 Kompetenzbereiche eines Projektleiters Sozialkompetenz Fachkompetenz Methodenkompetenz Betriebswirtschaftliche Kompetenz 32

33 Die vier Bereiche Ihres Erfolges als Projektleiter Projekt gemäss Zielvereinbarungen führen Rolle als Führungskraft wahrnehmen (Leadership) Produkt auf Kundennutzen trimmen (Kundenorientierung) Dem Projekt ein gutes Image verschaffen 33

34 Projektziele Erreichtes Ziel = erreichter Erfolg 34

35 Problematik bei unklaren Zielen 35

36 Projektziele versus Requirements Projektziele sind den Requirements übergeordnet Projektziele sind breiter gefasst und können neben der Lösung auch Ablauf, Vorgehen und Kosten spezifizieren Requirements beschreiben primär die Lösung und lassen sich in einer ununterbrochenen Kette auf Projektziele zurückführen 36

37 Scrum: User Stories vs. Requirements Fokus der User Stories liegt auf User Bedürfnis und weniger auf Details zur Technologie, DB Schema, Algorithmen oder GUI Layout. Die User Story sollte so verfasst sein, dass sie eine einigermassen risikolose Schätzung ermöglicht. Details der User Story werden erst bei bei Sprint Planning II und der Implementation geklärt. Angaben zur Testbarkeit der User Stories sind in den Akzeptanzkriterien vorhanden. Die User Story selbst beinhaltet keine oder kaum solche Angaben. 37

38 Was ist ein Ziel? (1) Aus den Zielen muss abgeleitet werden können: Das ist zu machen Das gehört nicht dazu Diese Qualität ist zu erreichen Zu diesem Zeitpunkt soll der Nutzen wirksam werden Achten Sie bei der schriftlichen Formulierung darauf, dass Sie nicht nur Prosabeschreibungen erhalten. Sie brauchen harte Fakten und Zahlen. Das kann sein: Geldsummen, Datum, Anzahl von irgendwas... 38

39 Was ist ein Ziel? (2) Denn: Ziele, die nicht messbar formuliert sind, können nicht zu einem messbaren Erfolg führen. Erfolg, der nicht messbar ist, kann nicht nachgewiesen werden. Erfolg, der nicht nachgewiesen werden kann, kann streitig gemacht werden. Also: Vereinbaren Sie mit Ihrem Auftraggeber nicht nur die Ziele, sondern auch gleichzeitig, wie am Ende des Projektes der Grad der Zielerreichung nachgewiesen werden soll. 39

40 Grundsätze zur Zielformulierung S pezifisch Ist das Ziel so präzise formuliert, dass es keinen Spielraum für Interpretationen oder Nachforderungen lässt? M essbar Woran erkenne ich, dass das Projektziel erreicht wurde? A ktionsorientiert Kann ich die Zielerreichung weitgehend selbst beeinflussen? R ealistisch Ist das Ziel anspruchsvoll, aber auch erreichbar? T erminiert Ist ein klarer Endtermin festgelegt? 40

41 Scrum: User Stories formulieren User Stories folgen in der Regel einem einheitlichen Satzmuster und sind bewusst kapp gehalten (1-2 Sätze). Als [Benutzerrolle] will ich [das Ziel], so dass [Grund für das Ziel]. Als [Benutzerrolle] will ich in der Lage sein, [das Ziel] innerhalb von [dieser Zeit] zu erhalten. As [some type of user] I can [do something] in order to [achieve some benefit]. 41

42 Scrum: Was User Stories nicht können User Stories sind ungeeignet zur Beschreibung von Anforderungen an die Benutzeroberfläche, Subsysteme oder Komponenten. Für GUI-Layouts UI-Spezifikationen oder Usability Prototypen verwenden UML-Dokumente für Subsysteme oder Komponenten. 42

43 Scrum: Akzeptanzkriterien für User Stories Jede User Story braucht Akzeptanzkriterien Akzeptanzkriterien bilden die Grundlage für die Akzeptanztests. Beispiel User Story: Als Anwender möchte ich in der Lage sein, Informationen innerhalb von 500ms zu erhalten. Akzeptanzkriterium: Bis zu 5000 Anwender sind zeitgleich eingeloggt. 43

44 Ziel-Prioritäten (1) (MuSCoW) Muss-Ziele (Must have) Diese Ziele müssen unbedingt erreicht werden, oder das Projekt gilt als gescheitert. Soll-Ziele (Should have) Diese Ziele sollten erreicht werden. Falls sie verfehlt werden, muss es dafür wichtige Gründe geben. 44

45 Ziel-Prioritäten (2) (MuSCoW) Kann-Ziele (auch Wunsch-Ziele genannt) (Can have) Wenn es möglich ist, diese Ziele auch noch zu erreichen, wäre es sehr schön. Notfalls stehen diese Ziele jedoch zurück, sollte es im Projekt zu Engpässen kommen. Nicht-Ziele (Won't have) Ziele, die nicht erreicht werden sollen, weil sie nicht Gegenstand dieses Projekts sind. Ziele, die unbedingt vermieden werden müssen, weil sie ein Risiko darstellen könnten. Diese Ziele erfordern ein Risikomanagement. 45

46 Scrum: Prioritäten des Product Backlog Priorität der User Stories folgt dem MuSCoW Ansatz, d.h. fast analog den Projektzielen Ausnahme: Nicht-Ziele (Won't have), braucht es nicht, da implizit weil nicht im Backlog enthalten Anpassung: Won't have this time d.h. diese User Stories sind nur zur Zeit nicht gefordert und werden in einem kommenden Release untergebracht 46

47 Grundsätzliches Muss-Ziel Das Produkt muss von denen akzeptiert werden, die es benutzen sollen. Für den Projektleiter ist es deshalb unbedingt wichtig, dass bei der Zielbildung die Benutzer des zukünftigen Produktes beteiligt sind. Wenn nur der Auftraggeber und der Projektleiter gemeinsam Ziele vereinbaren, kann es dazu führen, dass die Benutzer sich als Beplante fühlen und Misstrauen entwickeln. Es kann passieren, dass die Anwender das Projektprodukt bereits ablehnen, bevor es erstellt ist und bevor sie wissen, was und wie es werden soll. 47

48 Scrum: Product Vision The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is. (Ken Schwaber) Essentiell, muss als eines der ersten Artefakte erstellt werden Beschreibt die Idee und Potential des Produkts Leitfaden für die Ausrichtung des Produkts Ausgangsbasis für die User Stories Ausführlichere Beschreibung: 48

49 Scrum: Inhalt der Product Vision Die Product Vision ist bewusst kurz aber prägnant formuliert. Sie beantwortet folgende Fragen: Wer wird das Proukt kaufen? Wie stellt man sich den Zielkunden vor? Welche Kundenbedürfnisse will das Produkt ansprechen? Welche Produkteigenschaften sind ausschlaggebend für die erfolgreiche Befriedigung der angesprochenen Kundenbedürfnisse? Wo steht das Produkt im Vergleich zu existierenden Produkten von Mitbewerbern und der eigenen Firma? Welches sind die Unique Selling Points des Produkts? Wie sieht der Zeitrahmen und das Budget aus für die Entwicklung und die Markteinführung des Produkts? 49

50 Kick-off Meeting You never get a second chance for a first impression 50

51 Weshalb ein Kick-off Meeting? (1) Die Erfahrung zeigt, dass die Grundlagen für den Erfolg in den frühen Phasen eines Projekts gelegt werden. Hauptziel: Das Projekt-Team ist arbeitsfähig. 51

52 Weshalb ein Kick-off Meeting? (2) Jede Gruppe, die sich neu formiert oder bei der sich die Zusammensetzung verändert, durchläuft einen Entwicklungsprozess. In der ersten Phase (forming) einer neuen Gruppenzusammensetzung, kann etwa Folgendes beobachtet werden: Die Teilnehmer sind stark auf den Leiter konzentriert. Jeder ist damit beschäftigt, sich zu orientieren und an die Situation zu gewöhnen. Es herrscht Unsicherheit über die gültigen Normen (was ist erlaubt?) und die Rollenzuteilung. 52

53 Ziele des Kick-off Meetings (1) Das Projekt-Team ist arbeitsfähig Das Projekt ist allen bekannt gemacht Alle haben ein gemeinsames Verständnis von den Projektzielen Die Risiken sind bekannt Zielkonflikte sind transparent Alle (Ansprech-) Partner kennen sich Die Rollenverteilung ist bekannt und akzeptiert 53

54 Ziele des Kick-off Meetings (2) Die Vorgehensweise ist gemeinsam verabschiedet Wesentliche Meilensteine sind gemeinsam festgelegt Die Projekt-Organisation ist gemeinsam verabschiedet Schnittstellen sind definiert Spielregeln des Projekt-Teams sind vereinbart Alle haben den gleichen Informationsstand Alles Wesentliche ist dokumentiert Ein Signal ist gesetzt: Die gemeinsame Arbeit hat begonnen 54

55 Kick-off: Wann, wo und wie? Wann So früh wie möglich nach Erteilung des Projektauftrages. Vorbereitung durch den Projektleiter während der Projektgenehmigung. Wo Möglichst nicht im gewohnten Arbeits-Umfeld und nicht in der Nähe der Arbeitsplätze, damit die Teilnehmer nicht verführt werden, in den Pausen schnell an ihrem Arbeitsplatz "vorbeizuschauen". Wie Kick-off so zu legen, dass die Teilnehmer einen Abend gemeinsam verbringen können. Bei dem sprichwörtlichen Glas Bier, das sie dann zusammen trinken können, wird Information übermittelt, die für den Projektleiter äusserst wichtig sein kann, während des offiziellen Teils der Veranstaltung jedoch nicht zur Sprache kommt. 55

56 Kick-off Agenda Vorgeschichte des Projekts (Was war der Anstoss zum Projekt?) Projektziele abstimmen, gemeinsames Verständnis Projektablaufplan, Termine, Überblick über Arbeitsaufwand Projektorganisation und entsprechende Bearbeiter Verantwortlichkeiten Einordnung des Projekts beim Auftraggeber Projektumfeld und Projektrisiken Bedeutsame Projektmerkmale (Bedeutung für das Unternehmen, Vertraulichkeit etc.) Massgebende Spielregeln für die Projektarbeit (Verantwortung, Arbeitsablauf, Informationsfluss, Qualitätskontrolle etc.) Erste Vergabe von Aufträgen 56

57 Scrum: Kick-Off Wird Scrum im Rahmen eines Projekt angewendet, so ist es hilfreich, dass am Projekt Kick-off die Andersartigkeit von Scrum erwähnt und erklärt wird. Z.B.: Planung und Vorgehensweise Umgang zwischen Entwicklern und Kunden Umfang und Art der erstellten Dokumentation Vorgehensweise zur Implementation der Anforderungen Umgang mit Änderungen Wenn diese Unterschiede schon zu Beginn bekannt sind, erscheinen die sich daraus ergebenden Friktionen nicht unerwartet und lassen sich besser beseitigen. 57

58 Projekt Broschüre erstellen (Product Vision) Das gemeinsame Erstellen einer Projekt Broschüre ist ein sehr effektives Mittel, um die Projektidee bei allen Projektmitarbeitern zu verankern. In der Broschüre soll das fertige Produkt im Stil eines Verkaufsprospekts oder Marketing Flyers beschrieben werden. Die Zielgruppe der Broschüre sind diejenigen, welche nicht im Projekt involviert sind, d.h. Management, Sponsoren und andere Interessierte. Dies als Ergänzung zum Product Vision Dokument, welches fürs Projektteam gedacht ist. 58

59 Auftragserteilung Ein Auftrag besteht immer aus Sachziel Welche Spezifikation bzw. Funktion ist zu erfüllen? Kostenvorgabe Arbeitsaufwand und Anschaffungen Übergabe und Endtermin Wann, wie und wo wird das Resultat erwartet? 59

60 Anzahl Aufgaben pro Mitarbeiter Die Anzahl paralleler Aufgaben, welche ein Mitarbeiter verkraften kann ist beschränkt Optimale Effizienz bei 2-3 parallelen Aufgaben Restrukturierungen oder andere grössere Veränderungen im Umfeld des Mitarbeiters entsprechen bereits einer Aufgabe Häufiges Task-Switching vermeiden 60

61 Phasen- und Entwicklungsmodelle Immer noch Phasenmodelle? Gibt es nichts Moderneres? 61

62 Das Phasenkonzept Phasen sind eine Konkretisierung des Prinzips Vom Groben zum Detail aus dem Systems Engineering Phasen haben den Zweck, den Werdegang einer Lösung in überschaubare Teiletappen zu gliedern Phasen ermöglichen einen stufenweisen Planungs-, Entscheidungs- und Konkretisierungsprozess mit vordefinierten Marschhalten bzw. Korrekturpunkten (Meilensteine) Phasenmodelle gibt es mehrere, d.h. es gibt kein einzig richtiges Die Anzahl Projektphasen und der Formalismus hängt von der Projektgrösse ab 62

63 Traditionelles Wasserfall-Modell 63

64 Häufig beobachtete Nachlässigkeiten (1) Es wird bereits mit Arbeiten der Folgephase begonnen, bevor die Vorphase abgeschlossen und ihr Ergebnis abgenommen ist Die Baseline, die nach einer Phasenabnahme gelten sollte, wird wieder in Frage gestellt, obwohl sie bereits die Basis für die Weiterentwicklung war Parallele Teilprojekte werden schlecht koordiniert (gemeinsame Phasenabschlüsse sind nicht synchronisiert) 64

65 Häufig beobachtete Nachlässigkeiten (2) Kein sorgfältiges Review am Ende der Projektphase, d.h. eine Phase wird für beendet erklärt, obwohl das Ergebnis noch nicht offiziell abgesegnet ist Akzeptieren und Einbau von Änderungen ohne Beachtung der Regeln des Change Managements Die Projektkontrolle greift zu spät. Soll-Ist Vergleiche werden zu spät durchgeführt. 65

66 Iterative Entwicklung (z.b. RUP) 66

67 Rational Unified Process (RUP): Phasen, Disziplinen, Iterationen 67

68 Spezielles für den RUP Projektleiter Für den gesamten Projektablauf besteht nur ein grober Plan (Projectplan) Die detaillierte Planung erfolgt jeweils nur für die nächste Iteration (Iterationspläne) Die Anforderungsanalyse ist zu Beginn noch unvollständig, trotzdem werden alle klassischen Schritte bis zum getesteten Code durchgeführt Iterative Softwareentwicklung erfordert mehr Zeit für Planung und Management als klassische Entwicklungsprozesse Das Führen einer Risikoliste ist aufwendig, aber notwendig, um den Schwerpunkt für die nächsten Iterationen richtig zu definieren 68

69 RUP: Projectplan Der Projectplan des RUP unterscheidet sich stark vom Projectplan der klassischen Phasenmodelle. Der Projectplan enthält primär einen Phasenplan, der die 4 Phasen des RUP über die gesamte Projektlaufzeit verteilt. Weiter werden die Phasen mit Iterationen unterteilt. Die Inception-Phase enhält in der Regel keine Iteration. Die Elaboration-Phase enthält je mehr Iterationen je mehr Risiken vorhanden sind oder bei häufigem Wechseln der Anforderungen. Üblich sind 2 bis 3 Iterationen. Die Construction-Phase enthält üblicherweise 2 bis 3 Iterationen, bei kleinen Projekten ev. nur eine. Die Transition-Phase besteht meist nur aus einer Iteration (Beta- Phase). 69

70 RUP: Iterationspläne Entsprechen eher den Projektplänen der klassischen Wasserfallmodelle Enthalten den Zeitplan, welche RUP Aktivitäten vom wem in welchem Zeitraum ausgeführt werden Werden während einer Iteration für die nächste Iteration erstellt Die zeitnahe Planung ist nötig, damit neue Erkenntnisse sofort in der Planung berücksichtigt werden können Idealerweise nach Disziplinen geordnet Klassische PM-Tools wie MS-Project sind für Iterationspläne geeignet 70

71 Scrum: Scrummerfall (nicht empfehlenswert) Ungünstige Einbettung des Wasserfall Modells in Scrum Sprints bestehend aus 2 Wochen Implementierung, dann eine Woche Test und Integration, d.h sequenzielle Abfolge innerhalb des Sprints Diese Kombination ist nicht zu empfehlen, da es eine Übergabe zwischen Coding und Testing/Integration gibt. D.h. es braucht Wissensaustausch (-> zusätzliche Artefakte). Bei dieser Konbination ist die Gefahr gross, dass Testing nicht als Teil der Entwicklung verstanden wird und deshalb automatische Tests vernachlässigt werden. 71

72 Scrum: WaterScrum Einbettung von Scrum in ein Wasserfall Projekt, d.h. Scrum Team liefert ein Teilprodukt an das Gesamtprojekt. (z.b. eingesetzt bei Microsoft zur Entwicklung von Visual Studio 2010) 1. Phase: Requirements Engineering, Design (teilweise nach Scrum) 2. Phase: Produkt Entwicklung (nach Scrum) 3. Phase: Integration und Testing (Stabilization Phase) 4. Phase: Markteinführung Requirements eher grob fassen (werden nachher detailliert) In den ersten Sprints den Fokus auf externe Schnittstellen legen Intensive Zusammenarbeit mit den Konsumenten des Produkts (ext. Systeme) Vom Scrum Team werden voraussichtlich Artefakte und Zusagen erwartet, die es nicht erbringen kann (z.b. vollständige Planung, vollständiger Design) 72

73 Problematik iterativer Projekte im Geschäftsalltag Zu Beginn des Projekt steht kein vollständiges Anforderungsdokument (Pflichtenheft) zur Verfügung. D.h. das geplante Resultat des Projekts ist nicht klar fassbar, was dem Management oder dem Kunden häufig wichtig ist. Eine detaillierte und gesicherte Planung ist nicht über die gesamte Projektlaufzeit vorhanden. Budgetplanungen werden so erschwert. Fixpreis-Offerten für iterative Projekte sind extrem schwierig abzugeben, doch werden sie in den allermeisten Fällen vom Kunden gefordert. Dies deshalb, weil der Kunde darauf seine eigenen Budgeteingaben abstützt. Häufig besteht bereits ein detailliertes Anforderungspflichtenheft, das bei der Ausschreibung des Projekts abgegeben wird. Dadurch kommt ein wesentlicher Vorteil der iterativen Entwicklung bereits nicht mehr zum Tragen. 73

74 Hinweise für iterative Prozess Modelle (1) Iteratives Prozessmodell impliziert Folgendes: Häufige Installationen neuer Releases Häufige Übernahme von Daten aus vorherigen Releases Kleine Anpassungen in der Bedienung Häufiges Durchlaufen der Qualitätskontrolle 74

75 Hinweise für iterative Prozess Modelle (2) Darum: Klare Release Kennung im Produkt, automatisch generiert, für Benutzer jederzeit abrufbar Versionsinfo für Datenstruktur und Konfiguration als Hilfe für Datenmigration Einfache Installation der Software über bestehende Installation ermöglichen, von Beginn an Datenmigration während der Installation, auch über mehrere Releases hinweg What's new oder Release Notes direkt im Produkt abrufbar Konfigurationsmangement, von Beginn an Automatisiertes Testen, von Beginn an 75

76 Scrum: Vorbereitung für den Umstieg zu Scrum Ausprobieren und einführen agiler Entwicklungspraktiken, z.b.: Pair Programming fördert die Wissensverbreitung über den Code Gemeinsam Verantwortung übernehmen. Motto: Der Code gehört allen. Kontinuierliche Integration, (voll-)automatische Builds Testgetriebene Entwicklung Refactoring. Motto: Verlasse den bearbeiteten Code besser als er vorher war. Achtung: Dies erfordert ein Sicherheitsnetz in Form von automatisierten Tests. Bewusst Zeit für die Reflektion über Verbesserungspotential einplanen Einführen eines Verbesserungs BackLogs möglichst einfache Form wählen (z.b. Post-it auf einem Verbesserungs-Board) jede Woche wird mindestens eine Verbesserung umgesetzt und anschliessend beurteilt Einführen von Verbesserungs Communitys 76

77 Scrum: Einführung von Scrum (ADAPT) Um Scrum erfolgreich und dauerhaft einführen zu können sind folgende Faktoren entscheidend: A wareness Situationsbewusstsein, jetzige Prozesse führen nicht zu akzeptablen Ergebnissen D esire Wille zur Anwendung von Scrum als Möglichkeit die Probleme anzugehen A bility Befähigung dazu, mit Scrum zum Erfolg zu kommen P romotion Erfolg bekannt machen und Erfahrungen weitergeben T ransfer Ausweitung von Scrum, damit das ganze Unternehmen einbezogen wird 77

78 Change Management Je länger ein Projekt dauert, desto höher ist die Chance, dass Änderungen erforderlich werden. 78

79 Erhöhte Wahrscheinlichkeit für Änderungen Merkmale von Projekten mit erhöhter Wahrscheinlichkeit für Änderungen: Lange Projektdauer Komplexes Projekt Projekt hat grössere Umstellungen in den Arbeitsweisen und Verfahren zur Folge Machen Sie dies auch dem Auftraggeber deutlich. Versuchen Sie möglichst früh, das Vorgehen in dieser Thematik mit ihm abzustimmen. 79

80 Scrum: Umgang mit Änderungen Im Umgang mit Änderungen bestehen erhebliche Unterschiede zwischen Scrum und dem klassischen Projektmanagement. Scrum: Änderungen und Erweiterungen sind bei Scrum Teil des Prozesses und fliessen permanent in das Product Backlog ein. D.h. das Product Backlog verändert sich kontinuierlich und es wird bewusst mit Änderungen gerechnet. Projektmanagement: Änderungen werden zwar toleriert, werden aber in einem geringeren Mass erwartet. D.h. man geht davon aus, dass nach dem Requirements Engineering einigermassen stabile Verhältnisse herrschen. 80

81 Erkennen der Notwendigkeit von Änderungen Um möglichst viel Aufwand, Kosten und Ärger zu vermeiden, sollten Sie grossen Wert darauf legen, dass Entwickler und Benutzer ständig eng zusammenarbeiten. Es muss früh erkannt werden, wenn sich das Produkt doch nicht so entwickelt, wie es gebraucht wird. Es reicht nicht aus, stur den vereinbarten Anforderungen entsprechend zu arbeiten. Das Resultat könnte sein: Ziele erreicht, Produkt sinnlos. Je später Sie die Notwendigkeit von Änderungen erkennen, desto aufwändiger wird die Bearbeitung und desto mehr bisherige Arbeit geht verloren. 81

82 Änderungs- und Fehlerbehebungskosten je später, desto teurer 82

83 Änderung oder Korrektur? In Projekten kommt es immer wieder zu Diskussionen, was nun als Änderung und was als Korrektur zu gelten hat. Diese Diskussionen sind nicht immer einfach, denn es geht in der Regel um Geld. Änderungen können als Zusatzaufwand verrechnet werden, wogegen Korrekturen aus dem laufenden Budget zu finanzieren sind. 83

84 Was sind Änderungen? Um Änderungen handelt es sich, wenn Ziele, Anforderungen oder Randbedingungen nicht mehr mit den ursprünglichen Vereinbarungen übereinstimmen. Um eine Änderung handelt es sich auch dann, wenn der Auftraggeber mit dem Produkt auf einen Stand vor dem letzten abgenommenen Meilenstein zurück will. 84

85 Was sind Korrekturen? Um einen zu korrigierenden Fehler oder Mangel handelt es sich, wenn Anforderungen an Funktionalität oder Qualität nicht so erfüllt sind, wie es vereinbart war. Vielleicht ist die Realisierung falsch oder unvollständig. 85

86 Was ist demnach zu tun? Schützen Sie sich gegen unbegründete Korrekturen durch: frühzeitig getroffene Vereinbarung über Änderungsverfahren (Change Management) messbar formulierte Vereinbarungen (Ziele, Meilensteine, Beschlüsse etc.) enge Zusammenarbeit mit dem Auftraggeber und den Benutzern abnehmen lassen von Meilensteinen und Zwischenergebnissen durch den Auftraggeber 86

87 Mögliches Vorgehen bei Änderungswünschen 1. Änderungswunsch schriftlich festhalten (Change Request, Tool), entweder durch Auftraggeber oder PL (durch Auftraggeber prüfen lassen) 2. Zusammen mit Projektteam abklären, welche dazu Arbeiten notwendig werden, wie lange es dauert und was es kostet. Zudem sollte abgeklärt werden, ob die Änderung auf das Produkt Auswirkungen haben kann (Performance, Wartbarkeit, Akzeptanz etc.) 3. Halten Sie schriftlich fest, welche zusätzlichen Aufwände für die Änderungen geschätzt werden. 4. Lassen Sie den Änderungswunsch genehmigen (z.b. durch Beschlussliste) 5. Wird der Änderungswunsch genehmigt, dann müssen nun die Pläne angepasst werden (z.b. Test- und Abnahmespezifikation) 6. Dokumentieren Sie die Änderung: Was geändert? Wer wollte es? Warum? Wann wollte man die Änderung? 87

88 Trac: Change Management Tool (1) Trac ist ein sehr gut geeignetes Hilfsmittel zur Unterstützung von kleineren bis mittleren Softwareentwicklungen. Es ist frei erhältlich, Open Source und sehr gut dokumentiert. Was ist Trac genau? Ein integriertes System für die Verwaltung von Software Projekten Ein erweitertes Wiki Ein flexibles Web basiertes Ticketing System Ein Interface zum Subversion Revision Control System 88

89 Trac: Change Management Tool (2) What does Trac do? Trac lets software project developers and users track, use and manage: software issues bug reports feature requests overall progress over time project tasks source code changes documentation / wiki text 89

90 Trac: Change Management Tool (3) Web Seite: Plattformen auf denen Trac läuft: Linux, Mac OS X, BSD, Solaris, Windows (Apache oder IIS) Details zu den Plattformen: 90

91 Projektplanung Wer gut geplant hat, kann besser improvisieren Plane nicht zu weit und zu lange, es kommt sowiso anders. 91

92 Sie müssen planen. Wozu? Das sind die Ziele des Planens: Unsicherheiten feststellen und klären oder klärbar machen Komplexität überschaubar und beherrschbar machen Bedarf feststellen (Personen, Qualifikationen, Material, Budget, Zeit...) Wege zum Ziel definieren Meilensteine festlegen und somit Kontrollen ermöglichen Aufgaben, Ressourcen und Verantwortung zuordnen Steuerung möglich machen Risiken und Engpässe frühzeitig erkennen 92

93 Praxistipp Sie können nicht mit allem rechnen. Rechnen Sie jedoch damit, dass es Ereignisse geben wird, mit denen Sie nicht gerechnet haben. Berücksichtigen Sie, dass nur etwa 60-80% des Aufwandes planbar sind. Motto: Besser fast richtig als genau falsch. Alle Pläne werden hinfällig, wenn die Menschen, die sie befolgen sollen, Probleme miteinander haben. 93

94 Meilensteine Meilensteine markieren im Projekt die Points of no return 94

95 Was ist ein Meilenstein? Der Meilenstein dient als Führungsinstrument zwischen Auftraggeber und Projektleiter. Ein Meilenstein ist ein Entscheidungszeitpunkt, an dem der Auftraggeber die bisherigen Ergebnisse der Projektarbeit beurteilt und die Freigabe der nächsten Projektphase beschliesst. Meilensteine dienen auch zur Motivation der Mitarbeiter. Denn, es ist für Menschen nicht leicht, Ziele zu verfolgen, die zu weit in der Ferne liegen. Dann liegen auch die Erfolgserlebnisse zu weit entfernt. 95

96 Wo Meilensteine festlegen? Meilensteine stehen immer an entscheidenden Stellen des Projekts. Mindestens am Ende jeder Projektphase muss ein Meilenstein stehen. Der Meilenstein ist das Produkt des jeweils abgeschlossenen Schrittes (auch Phasenprodukt genannt) Bei komplexen Projekten kann es zusätzlich auch Meilensteine innerhalb der Phase geben. 96

97 Scrum: Meilensteine Bei der Kombination von klassischen Projekt-Meilensteinen mit Scrum müssen Sie zusätzlich Folgendes beachten: Termine der Meilensteine auf den Sprint Rhythmus abstimmen Dem Scrum Team muss bewusst sein, dass es nach dem letzten Sprint vor dem Meilenstein tatsächlich zu einer "Auslieferung" kommt. 97

98 Praxistipp Wenn ein Meilenstein kurz vor dem Abschluss steht, werden noch einmal, wie bei einem Endspurt, alle Kräfte mobilisiert. Wenn er dann erreicht ist, schlaffen die Kräfte zunächst einmal ab. Planen Sie deshalb nach jedem Meilenstein einen Puffer mit ein. Ein Meilenstein ist nicht ein Zeitpunkt sondern ein Meeting zur Entscheidungsfindung. Planen Sie die Meilensteine deshalb mit einer bestimmten Dauer ein. 98

99 Projektübersicht, Tätigkeitsliste und Terminplan Gut geplant ist halb getan! 99

100 Ablaufplanung ist ein Gemeinschaftswerk Die Ablaufplanung wird optimaler Weise von der Projektgruppe gemeinsam erarbeitet und nie vom Projektleiter allein. 100

101 Ablaufplanung ist keine Einzelarbeit des PL! Dafür gibt es zwei gute Gründe: Der Projektleiter als Generalist hat nicht gleichviel notwendiges interdisziplinäres Fachwissen, wie es die ganze Projektgruppe zusammen hat. Die aktive Beteiligung am Planungsprozess fördert den Ehrgeiz aller Teammitglieder, die Pläne auch einzuhalten. 101

102 Planung des Projektablaufs Bei der Planung des Projektablaufs ist sinnvollerweise das Prinzip vom Groben zum Detail anzuwenden. Vorgehen in nicht zu grossen, verkraftbaren Schritten: Projekt-Gesamtaufgabe Teilprojekte, Aufgabenpakete + Phasen Grobtätigkeiten (Fachprobleme) Detailtätigkeiten (Aktivitäten) 102

103 Teilprojekte, Aufgabenpakete und Phasen erstellen Der Projektstrukturplan (PSP) ist das Werkzeug, um die Gesamtaufgabe in handhabbare Elemente herunter zu brechen. Ein PSP ist eine an den Liefergegenständen orientierte Anordnung von Projektelementen, die den Gesamtinhalt und Umfang des Projekts strukturiert und definiert. Aus dem PSP lassen sich Teilprojekte und Aufgabenpakete ableiten. Abhängigkeiten zu anderen Projekten und Grössen der Aufgabenpakete bilden die Grundlage für die Einteilung in Phasen. 103

104 Projektstrukturplan (PSP) Als Darstellungsform wird z.t. noch das kassische Strukturdiagramm verwendet, zunehmend jedoch das Mindmap. Im Englischen spricht man von der Work Breakdown Structure (WBS) Der PSP wird bis auf Arbeitspakete als unterste Ebene aufgelöst. Aktivitäten gehören nicht mehr zum PSP. Auf der obersten Ebene sollte der PSP nach den Hauptliefergegenständen gegeliedert sein, um das Projekt leicht erkennbar abzubilden. 104

105 PSP als Mind Map 105

106 PSP als Strukturdiagramm 106