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

Größe: px
Ab Seite anzeigen:

Download "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

Projektmanagement. Projektmanagement

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

Mehr

Praxis-Handbuch Projektmanagement 00 / Inhaltsangabe

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

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Semesterprojekt SS 2011

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

Mehr

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

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

Mehr

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

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

Mehr

Grundlagen der Projektarbeit

Grundlagen der Projektarbeit Lerninhalte ❶ ❷ ❸ ❹ ❺ ❻ Ziele und Aufgaben des s Beteiligte des s Aufstellung der IS-Architektur (Überblick) Projektplanung Projektentwicklung Projektorganisation Lerninhalte L1 i Ziele und Aufgaben des

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

Mehr

Einführung in das Projektmanagement 1

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

Mehr

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

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

Mehr

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

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

Mehr

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

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

Mehr

Agile Programmierung - Theorie II SCRUM

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

Mehr

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

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

Mehr

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

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

Mehr

Grundlagen des Projektmanagements

Grundlagen des Projektmanagements Grundlagen des Projektmanagements dynamisch Umweltzustände statisch Steigende Notwendigkeit neuerer, effektiver Organisationsformen einfach Aufgabentypen komplex Vorphase Analyse Entwurf Realisierung Einführung

Mehr

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

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

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

5.3.2 Projektstrukturplan

5.3.2 Projektstrukturplan 5.3.2 Der ist eine der wichtigsten Planungs- und Controllingmethoden und das zentrale Kommunikationsinstrument im Projekt. Er bildet die Basis für sämtliche weitere Projektmanagement- Pläne sowie für die

Mehr

Keywords: Projektmanagement, Erfahrungen Projektmanagement

Keywords: Projektmanagement, Erfahrungen Projektmanagement Sage mir, wie ein Projekt beginnt und ich sage Dir, wie es endet". "Projektmanagement - heute" Projektmanagement stellt eine klare Herausforderung an die Managementqualitäten der Unternehmen dar. Projektmanagement

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

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

Mehr

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

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

Mehr

Lösungen zum Test objektorientierter Software

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

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

Ü K 131: Projektmanagement

Ü K 131: Projektmanagement Ü K 131: Projektmanagement Inhalt Was ist ein Projekt?... 4 Verschiedene Projektarten:... 4 Eckpfeiler eines Projektes... 4 Kritische Erfolgsfaktoren... 5 Risiken abschätzen... 5 Projektinstanzen (Rollen)...

Mehr

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

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

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

Mehr

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt Scrum undprojektmanagement à la GPM Markus Schramm compeople AG Frankfurt GPM scrum ed GPM, Scrum, warum? Projektablauf koordinieren Einheitliches Vorgehen Gemeinsames Verständnis Gemeinsame Sprache Freestyle

Mehr

Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12.

Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12. Talk im Schloss Zusammenbringen was zusammen gehört Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12.2007 F.Riemenschneider +49 177 291 68 32 falko.riemenschneider@itemis.de

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Software-Lebenszyklus

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

Mehr

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

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

Mehr

AD HOC Personal- und Organisationsberatung GmbH, Obergrundstrasse 50, 6003 Luzern Fon 041 211 14 04 Fax 041 211 14 05 www.adhoc-beratung.

AD HOC Personal- und Organisationsberatung GmbH, Obergrundstrasse 50, 6003 Luzern Fon 041 211 14 04 Fax 041 211 14 05 www.adhoc-beratung. AD HOC Personal- und Organisationsberatung GmbH, Obergrundstrasse 50, 6003 Luzern Fon 041 211 14 04 Fax 041 211 14 05 www.adhoc-beratung.ch Projektmanagement Was ist ein Projekt, und was ist Projektmanagement?

Mehr

V-Methode, RUP, Waterfall oder was?

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

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41913-1 sowie im Buchhandel.

Mehr

Wie funktioniert agile Software-

Wie funktioniert agile Software- Wie funktioniert agile Software- Entwicklung mit SCRUM Zürich, 8. Mai 008 Jean-Pierre König, namics ag Software Engineer Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich www.namics.com Agenda»

Mehr

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

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

Mehr

Übungsaufgaben zum Lerntransfer. Projektmanagement

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

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Management großer Projekte Ein modellbasierter Ansatz

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

Mehr

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Silvio Simone, Bison Group Susanne Mühlbauer, HOOD GmbH Scrum Day 2012 Bison Schweiz AG Surentalstrasse 10 CH-6210 Sursee www.bison-group.com HOOD GmbH

Mehr

Lehrplan: Projektmanagement

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

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

Prof. Dr.-Ing. Dagmar Meyer Projektmanagement PROJEKTPLANUNG

Prof. Dr.-Ing. Dagmar Meyer Projektmanagement PROJEKTPLANUNG Prof. Dr.-Ing. Dagmar Meyer Projektmanagement PROJEKTPLANUNG Übersicht Planungsschritte Projektmanagement Projektplanung Prof. Dr.-Ing. Dagmar Meyer 2 Projektumfang festlegen Festlegung des Projektumfangs

Mehr

ABLAUF PROJEKTMANAGEMENT

ABLAUF PROJEKTMANAGEMENT ABLAUF PROJEKTMANAGEMENT Zusammenstellung der Phasen, der inhaltlichen Bearbeitungspunkte und der dazu passenden Fragestellungen. Dabei gehen wir davon aus, dass die Projektidee bereits geboren ist und

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

Planung in agilen Projekten

Planung in agilen Projekten Planung in agilen Projekten Angelika Drach DeutscheScrum 2012 improuv GmbH Agile Leadership. h7p://improuv.com Über mich Lange Jahre Erfahrung in der Bauplanung Planung und Agiles Vorgehen sind ein Widerspruch?

Mehr

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 Sabotage in Scrum dem Prozess erfolglos ins Knie schiessen Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 1 Überblick Sabotage? Wer kann sabotieren? Was kann sabotiert werden? Wieviel

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Wer bin ich Kurse und Vorträge mit Jeff Sutherland und Ken Schwaber Verschiedene Kurse der Scrum.org Professional

Mehr

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Scrum ist eine Erfolgsstory Aus der Praxis entstanden Nachweislich erfolgreich Gut geeignet für komplexe Probleme Produktentwicklung

Mehr

Basiswissen Software-Projektmanagement

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

Mehr

IT-Projektmanagement - Methoden und Techniken

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

Mehr

PMO. Projektmanagement in den Kliniken der Stadt Köln. 23. Juni 2010

PMO. Projektmanagement in den Kliniken der Stadt Köln. 23. Juni 2010 PMO Projektmanagement in den Kliniken der Stadt Köln 23. Juni 2010 Agenda Inhalt 1.Das Projektmanagement Office (PMO) bei den Kliniken der Stadt Köln ggmbh 2.Strukturierung und Priorisierung der Projektarbeit

Mehr

Aller Anfang ist schwer Starthilfen in der Wissenschaft. Projektplanung: Do s and Don ts

Aller Anfang ist schwer Starthilfen in der Wissenschaft. Projektplanung: Do s and Don ts 6. COMBATing Breast Cancer Chances for Cure Aller Anfang ist schwer Starthilfen in der Wissenschaft Projektplanung: Do s and Don ts Dieter Niederacher COMBATing Breast Cancer 2013 Präsymposium TraFo Kommission

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

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

Mehr

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

Mehr

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master,

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master, TFS Customzing in der Praxis Thomas Gugler ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com Thomas Gugler seit 2005 bei

Mehr

Die Projektphasen. Projektphasen eines Organisationsprojekt. Beispiel Messeauftritt Frankfurter Buchmesse: Phase 1: Anstoß.

Die Projektphasen. Projektphasen eines Organisationsprojekt. Beispiel Messeauftritt Frankfurter Buchmesse: Phase 1: Anstoß. Die Projektphasen Projektphasen eines Organisationsprojekt Beispiel Messeauftritt Frankfurter Buchmesse: Phase 1: Anstoß Phase 2: Konzept Phase 3: Detailplanung Phase 4: Realisierung Phase 5: Auswertung

Mehr

Stakeholder Management

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

Mehr

Der Grüne Faden des Projektmanagements

Der Grüne Faden des Projektmanagements Behrens Projektmanagement GmbH Hasenberg 6 35041 Marburg Tel.: 06421 / 294 93 26 E-Mail: info@behrens-pm.de Der Grüne Faden des Projektmanagements Planungsphase Die Weichen für ein erfolgreiches Projekt

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

Software-Projektmanagement

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

Mehr

Agenda. VP Projektmanagement SS 2007 Termin 1 Einleitung / Projektstart. VP Projektmanagement SS 07 (Termin 1) - Einleitung & Projektstart

Agenda. VP Projektmanagement SS 2007 Termin 1 Einleitung / Projektstart. VP Projektmanagement SS 07 (Termin 1) - Einleitung & Projektstart (Termin 1) - Kopfzeile VP Projektmanagement SS 2007 Termin 1 Einleitung / Projektstart Agenda Einleitung (Zeitmanagement, Vorstellung, Inhalte der Vorlesung, Spielregeln, Warum Projektmanagement?) Was

Mehr

Projekte strukturieren

Projekte strukturieren Projekte strukturieren Compendio: Kapitel 6, Seiten 91-101 16.06.2013 SWE-IPM 1 Inhalt Vorteile der Projektstrukturierung Projektstrukturplan (PSP) Grundstruktur Gliederungsprinzipien Objektorientierte

Mehr

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Bekannte Tools in einem agilen Ansatz Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Vorher Lange Planungszeiten und Releasezyklen Manche Features brauchten lange und wurden nicht gebraucht

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen? Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee

Mehr

Des Weiteren gibt es Anpassungsprogrammierer, die reine Projektanpassungen umsetzen, eventuell Mitarbeiter für Datenübernahmen oder Schulungen.

Des Weiteren gibt es Anpassungsprogrammierer, die reine Projektanpassungen umsetzen, eventuell Mitarbeiter für Datenübernahmen oder Schulungen. ERP Einführung 1. Vorgehen, Terminplan, Projektrealisierung 1.1 Kickoff Termin Bei diesem Termin wird das Projektmanagement definiert. Dies bedeutet, dass das Projektteam auf beiden Seiten skizziert wird.

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

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

Mehr

Kapitel 2: Projektmanagement Umsetzung

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

Mehr

Projektmanagement Aufgabenstellung

Projektmanagement Aufgabenstellung Modulprüfungen SVF-ASFC Ausgabe Herbst 2010 Projektmanagement Aufgabenstellung Dauer der Prüfung: 60 Minuten Erlaubte Hilfsmittel: keine Kleben Sie Ihre Prüfungsmarke hier auf! Punkte: Note: Unterschrift

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Zusammenarbeit im Projekt

Zusammenarbeit im Projekt Zusammenarbeit im Projekt Die folgenden Folien geben ein paar Grundsätze und Tips aus unserer Projektmanagement Erfahrung weiter. Vielleicht nicht viel Neues? just do it! Grundsätze Viele Firmen sind nach

Mehr

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

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

Mehr

Machbar? Machbar! 07.10.2010

Machbar? Machbar! 07.10.2010 TANNER AG 2010 TANNER AG Kemptener Straße 99 D-88131 Lindau (B) Telefon +49 8382 272-0 Fax +49 8382 272-900 www.tanner.de info@tanner.de Agile Softwareentwicklung im regulativen Umfeld. Machbar? Machbar!

Mehr

Notwendigkeit einer eigenen Struktur

Notwendigkeit einer eigenen Struktur Projektmanagement Robert Johnen 04.09.12 Seite 1/33 Projektdefinition Neuheit des Tuns konkrete Zielvorgaben Notwendigkeit einer eigenen Struktur Nicht alles was man Projekt nennt, ist auch eins! Robert

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42524-8 sowie im Buchhandel.

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Checkliste für Scrum-Meetings

Checkliste für Scrum-Meetings Checkliste für Scrum-Meetings Gesamtdarstellung 2 Produktvision teilen 3 Estimating 4 Planning 1 - Das WAS 5 Planning 2 - Das WIE 6 Daily Scrum 7 Das Review 8 Die Retrospektive 9 Artefakte 10 GOagile!

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

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

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

Mehr

Stefan Mieth, AIT GmbH & Co. KG

Stefan Mieth, AIT GmbH & Co. KG Stefan Mieth, AIT GmbH & Co KG As a requirements engineer I want to use the TFS 12032015; 16:30 17:30 Requirements Engineering ist neben Testing wohl der Dauerbrenner, wenn es um gerne vernachlässigte

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

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

Mehr

Projektmanagement: Projektorganisation

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

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr