IT-Projektmanagement SS 2015 Prof. Dr. Herrad Schmidt Kapitel 3 und 4 Vorgehensmodelle zur Projektdurchführung Projektorganisation

3. Vorgehensmodelle zur Projektdurchführung Als Vorgabe für die Prozessschritte zur Realisierung eines IT-Projektes und der anzuwendenden Verfahren hinsichtlich der Vorgehensweise im Team dienen sog. Vorgehensmodelle. Ein Vorgehensmodell beschreibt den organisatorischen Ablauf in Phasen. Die Einteilung des Projektablaufs in Phasen erleichtert die Festlegung von Arbeitsschritten, Arbeitsresultaten, sowie die Kapazitäts-, Termin- und Kostenplanung. Eine Phase endet mit einem prüfbaren Phasenergebnis, dem Meilenstein. Ein Meilenstein ist ein definiertes, termingebundenes Sachergebnis. Phasen werden jeweils durch den Meilenstein-Entscheid abgeschlossen. Durch den Meilenstein-Entscheid wird die Freigabe der Folgephase bedingt.

In den verschiedenen Vorgangsmodellen werden die Phasen mit ihren Aufgaben und Meilensteinen beschrieben. Modelle: Sequentielle Vorgehensmodelle Inkrementelle Vorgehensmodelle V-Modell Agile Vorgehensmodelle Weitere und Mischformen Allen Modellen im Prinzip zugrundeliegende Phasen:

Sequentielle Vorgehensmodelle (1): Rein sequentielles Vorgehen Wasserfallmodell (Barry W. Boehm, 1980)

Sequentielle Vorgehensmodelle (2): Spiralmodell (Boehm, 1988)

Inkrementelles Vorgehensmodell: Ein komplexes IT-System wird in sinnvolle, selbständig entwickelbare Teilsysteme zerlegt, die nacheinander oder parallel erstellt werden. Diese Teilsysteme sollen möglichst früh einsetzbar sein bzw. zunächst als Prototypen (iterative Entwicklung) erstellt werden. In der ersten Ausbaustufe wird die Systemarchitektur entworfen. Der Funktionsumfang des Systems wird in Form von Releases erweitert. In mehreren Ausbaustufen entsteht dann das vollständige System. Quelle: Ruf/Fittkau (2008), S. 33

V-Modell XT: s.a. IABG, http://v-modell.iabg.de Verbindlich vorgeschriebener Entwicklungsstandard für IT-Systeme des Bundes für die Planung und Durchführung von IT Projekten International anerkannter Entwicklungsstandard für die Entwicklung von IT-Systemen Leitfaden zum Planen und Durchführung von Entwicklungsprojekten unter Beachtung des gesamten Systemlebenszyklus Definition der in einem Projekt zu erstellenden Ergebnisse Beschreibung der konkreten Vorgehensweisen, mit dem diese Ergebnisse erarbeitet werden Festlegung der Verantwortlichkeiten jedes Projektbeteiligten Vertragsgrundlage, Arbeitsanleitung und Kommunikationsbasis s.a. IABG, Downloads: V-Modell XT (932 S.)

Agile Softwareentwicklung (1): Das Agiles Manifest (2001) beruht auf vier Werten und zwölf Prinzipien, die zusammen als Leitsatz für agile Arbeit gelten. s.a. http://agilemanifesto.org/iso/de/manifesto.html Die Verfahren bauen auf dem Modell der inkrementellen Entwicklung auf. Die Entwurfsphase soll auf ein Mindestmaß reduziert werden. Die Entwicklungszyklen (Iterationen) sind relativ kurz mit dem Ziel, jeweils ein lauffähiges System zu erhalten (kontinuierliche Auslieferung). Nach jeder Iteration wird ein für den Kunden greifbares Resultat erreicht. Auftraggeber und Entwickler arbeiten eng zusammen.

Agile Softwareentwicklung (2): Anforderungen werden zeitnah zusammengestellt. Veränderungen sind vorgesehen. Dokumentationen werden möglichst klein gehalten. Das Team arbeitet selbstorganisierend. Die Projekte müssen für kleine Teams (< 10) realisierbar sein. Ziele sind eine Verminderung der Risiken und eine Verbesserung der Kundenzufriedenheit mit dem Projektergebnis. Es gibt zahlreiche Ansätze. Zu den bekanntesten zählen eXtreme Programming (XP) und Scrum.

Scrum: Scrum-Guide von Ken Schwaber und Jeff Sutherland http://www.scrumguides.org/ Definition: “Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.“ ScrumGuide.pdf, S. 3 Scrum wird als Prozessrahmenwerk zur Entwicklung komplexer Produkte seit den 1990er Jahren eingesetzt. Scrum beruht auf einem iterativen, inkrementellen Ansatz. Das Scrum Rahmenwerk besteht aus Scrum Teams und den mit ihnen verbundenen Rollen, Ereignissen, Artefakten und Regeln.

Der Sprint: fixer Zeitraum von maximal einem Monat, innerhalb dessen ein nutzbares und potenziell auslieferbares Produkt-Inkrement hergestellt wird Jeder Sprint hat einen definierten Leistungsumfang (Sprint-Ziel). Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden. Am Ende eines Sprints wird ein Sprint Review abgehalten, um das Inkrement zu überprüfen. Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog (s. nächste Folie).

Scrum Artefakte: Product Backlog geordnete Liste aller Features, Funktionalitäten, Änderungen, Verbesserungen und Fehlerbehebungen Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter. Sprint Backlog Ausgewählte Product Backlog-Einträge für einen Sprint mit der Funktionalität für den nächsten Sprint. Inkrement Ergebnis aus allen in einem Sprint fertiggestellten Product Backlog- Einträgen und dem Resultat der Inkremente aller früheren Sprints. Das Inkrement muss in einem verwendbaren Zustand sein („Done“). Es ist getestet.

Das Scrum Team: Scrum Teams sind selbstorganisierend. Scrum Teams liefern Produkte iterativ und inkrementell. Es besteht aus: Product Owner, Entwicklungsteam, Scrum Master Product Owner: übernimmt die Verantwortung für das Projektergebnis ist für das Management des Product Backlogs verantwortlich Entwicklungsteam: erstellt das Produkt-Inkrements für jeden Sprint sind interdisziplinär aufgestellt arbeiten selbstorganisierend besteht aus drei bis neuen Mitgliedern Scrum Master: ist für das Verständnis und die Durchführung von Scrum verantwortlich sorgt für die Einhaltung der Theorie, Praktiken und Regeln

Quelle: http://www.it-agile.de/wissen/methoden/scrum/

Grün, Capgemini sd&m, Vortrag vom 05.12.2005

Klassische Karikatur der Phasen: Phase 1: Begeisterung Phase 2: Verwirrung Phase 3: Ernüchterung Phase 4: Suche der Schuldigen Phase 5: Bestrafung der Unschuldigen Phase 6: Auszeichnung der Nichtbeteiligten

4. Projektorganisation Nach DIN 69901 ist unter Projektorganisation die „Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmtes Projektes“ zu verstehen. Aus dem Praxisleitfaden des BMI, S. 11f.: „Bei der Konzipierung einer Projektorganisation geht es darum, Aufgaben, Kompetenzen und Verantwortung zielgerichtet auf die Mitarbeiter zu verteilen. Die Wahl der zweckmäßigen Projektorganisation hat weitreichende Konsequenzen für die zukünftige Projektarbeit. Hier werden die Rollen und Handlungsspielräume sowie die Verfügbarkeit aller Projektbeteiligten definiert.“ Die Projektorganisation stellt eine für die Durchführung eines Projekts eingerichtete Sekundärorganisation dar, die in die bestehende Primärorganisation integriert werden muss.

In die Projektorganisation sind einige Instanzen direkt oder indirekt involviert: Der Auftraggeber (Projektträger) erteilt den Projektauftrag und sorgt für die Rahmenbedingungen für eine effektive Projektabwicklung. Der Projektleiter trägt die Gesamtverantwortung für das Projekt. Er ist für die Planung, die auftragsgerechte Durchführung, die Steuerung und Überwachung zuständig und verantwortlich. Er koordiniert, organisiert und kommuniziert die Projektarbeit. Das Projektteam ist für die operative Abwicklung der Projektarbeit zuständig. Häufig werden zur Überwachung und als Entscheidungsinstanz im Sinne einer Unterstützung des Auftraggebers ein Lenkungsausschuss (Steuerungsgremium) eingesetzt. Weiterhin sind die Betroffenen (Kunde, Vertreter der Fachabteilungen bzw. Benutzer, Betriebsrat, etc.) und Spezialisten, Gutachter, Berater, Datenschutzbeauftragte, etc. einzubeziehen.

Größe, Zeitrahmen und Arbeitsintensität bestimmen den Freistellungsgrad der involvierten Mitarbeiter. Mitarbeiter können vollständig oder zeitweise freigestellt werden. Die Kompetenzen der Linien- und Projektorganisation ergeben sich aus der gewählten Organisationsform. Durch die Organisationsform werden Weisungskompetenz, Handlungsspielräume für den Projektleiter und Verfügbarkeit der Projektmitarbeiter bestimmt. Für die Aufbauorganisation haben sich in der Praxis drei Organisationsformen herauskristallisiert:  Reine Projektorganisation (Task Force)  Einfluss-Projektorganisation (Stabs-Projektorganisation)  Matrix-Projektorganisation

Reine Projektorganisation (Task Force) Es entsteht eine neue Organisationseinheit. Die Mitarbeiter werden aus der Linienorganisation freigestellt und externe werden direkt in die Projektorganisation eingeordnet. Der Projektleiter erhält die gesamte Weisungs- und Entscheidungsbefugnis und somit die Gesamtverantwortung. Der Projektleiter hat die Verfügungsgewalt über alle Ressourcen. Diese Organisationsform eignet sich für große und komplexe Projekte.

Vorteile: Nachteile: Reine Projektorganisation Volle Konzentration auf das Projekt Hohe Identifikation Eindeutige Weisungsbefugnis Schnelle Reaktion Nachteile: Starke Kapazitätsbindung Gefahr der Isolierung Gefahr der Spezialisierung Probleme bei der Wiedereingliederung

Einfluss-Projektorganisation (Stabs-Projektorganisation) Der Projektleiter hat eine Stabsstelle inne und die Rolle eines Projektkoordinators. Er hat kein Entscheidungs- und Weisungsrecht. Entscheidungen werden in der Linie getroffen. Er erstellt die Pläne für das Projekt. Er überwacht den Projektfortschritt, bestimmt die Art und Weise der Projektdurchführung, koordiniert die Projektarbeiten und hat die Berichtspflicht. Er sorgt für Akzeptanz bei den Instanzen. Er ist auf die Unterstützung der Linienmanager angewiesen. Diese Organisationsform ist nur für kleinere oder mittlere Projekte zu empfehlen.

Vorteile: Nachteile: Einfluss-Projektorganisation Geringfügige Umstellungen Hohe Flexibilität kostengünstig Keine Wiedereingliederung Nachteile: Kompetenzschwierigkeiten Problem der aufgabenbezogenen Dezentralisierung Schwierige Kontrolle Geringere Identifikation

Matrix-Projektorganisation Es handelt sich um eine Mischform aus Einfluss-Projektorganisation und reiner Projektorganisation. Es findet eine Kompetenzaufteilung zwischen Projektleiter und Linieninstanz statt (Mehrliniensystem). Die Projektmitarbeiter sind dem Projektleiter fachlich unterstellt und ihren Linienvorgesetzten disziplinarisch. Die Mitarbeiter arbeiten zeitanteilig an Projekt- und Abteilungstätigkeiten. Die Matrix-Projektorganisation wird empfohlen, wenn das Know- how mehrerer Mitarbeiter zeitlich begrenzt benötigt wird.

Vorteile: Nachteile: Matrix-Projektorganisation Optimale Kapazitätsauslastung Definierte Zuständigkeit Stärkung der Verantwortlichkeit Keine volle Herauslösung der Mitarbeiter Nachteile: Konfliktpotential Trennung der Weisungsbefugnis Höhere Qualifikation der Mitarbeiter erforderlich großer Kommunikationsbedarf

Instanzen und Rollen Rollen: Bei der Bildung von Stellen für eine Projektorganisation sind eindeutig festzulegen: Aufgaben Kompetenz Verantwortung Dabei gilt der Grundsatz von Einheit und Kongruenz. Rollen: Projektträger (Auftraggeber) Projektleiter Mitarbeiter in der Projektgruppe Fachmitarbeiter (Anwender)

Projektträger (Auftraggeber) Aufgaben  Projektauftrag  Zielvorgabe  Vorgabe von Budget und Zeit  Ernennung des Projektleiters  Durchsetzung der Unternehmensinteressen gegenüber dem Projektleiter  Abstimmung mit dem Lenkungsausschuss  Überwachung des Projektfortschritts  Meilensteinentscheide und Entscheidung in Ausnahmefällen  Kontrolle und Abnahme der Projektergebnisse Verantwortung für die Ergebnisse, also Finanz-, Sach- und Terminverantwortung Kompetenz zur Gänze

Der Projektleiter Aufgaben  Initialisierung und Definition des Projekts  Entwicklung der Arbeitspakete und der Aufgabenprozesse  Planung, Steuerung und Kontrolle der einzelnen Projekttätigkeiten  Überwachung der Termine und des Budgets  fachliche und evtl. disziplinarische Führung der Projektmitarbeiter  Qualitätskontrolle  Arbeits-, Ergebnis- und Informationskoordination  Schaffung der Voraussetzung für die Projektdurchführung  Information des Auftragsgebers bzw. Lenkungsausschusses  Gewährleistung des Projektabschlusses  Vertretung des Projekts nach außen Verantwortung für die Ergebnisse (s.o.), Führung des Projekts Kompetenz  abgeleitete Entscheidungsbefugnisse  Arbeitsauftragsvergabe an Teammitglieder  Disposition über Projekt-Ressourcen

Mitarbeiter in der Projektgruppe Aufgaben  Ausarbeitung von Lösungsentwürfen  Durchführung der Arbeitspakete  Test und Qualitätskontrolle für seine Tätigkeiten  Unterstützung bei der Einführung  Berichtspflicht Verantwortung  Durchführung und Dokumentation der eigenen Arbeiten  persönliche Ergebnisverantwortung Kompetenz  für die Durchführung der Teilaufgaben notwendige und aus der des Projektleiters abgeleitete Kompetenz  persönliche Ergebnisverantwortung  Information und Kommunikation mit anderen Teammitgliedern und ggfs. den Anwendern

Fachmitarbeiter (Anwender) Aufgaben  Unterstützung bei der Istanalyse  Darstellung der Geschäftsprozesse  Bereitstellung von Formularen und Dokumenten  Formulierung der Anforderungen  Überprüfung der Resultate  Meldung von Fehlern  Freigabe der Ergebnisse  Kooperation Verantwortung  Korrektheit und Vollständigkeit der Anforderungen  Abnahme der Ergebnisse  Wahrung der Interessen der Fachabteilung Kompetenz  für die Freigabe  für die Mitarbeit (Freistellung)  Veranlassung von Mängelbeseitigung

Gremien: Übergreifende oder projektbegleitende Gruppen, in Form von Ausschüssen (dauerhaft) oder Kollegien (zeitlich befristet) zur Unterstützung bei der strategischen Planung und Steuerung eines Projekts zur Sicherstellung eines umfassenden Informationsflusses Arten:  Planungs- und Kontrollgremium  Steuerungsgremium  Entscheidungsgremium  Kommunikationsgremium  Beratungsgremium In der Praxis werden die Gremien häufig zu einem IT-Lenkungsausschuss zusammengefasst. Als Praxisbeispiel folgt die Regelung bei sd&m (Grün, Vortrag vom 2.12.2004):