IU Projektbericht – Agiles Projektmanagement als Hilfestellung für dein IU Studium

Mein IU Projektbericht im Modul IU Agiles Projektmanagement
Hier stelle ich dir meinen IU Projektbericht zum IU Modul Agiles Projektmanagement (DLBDBAPM01) vor. Der IU Projektbericht stellt eine mögliche Prüfungsform dar und ist somit eine Hausarbeit, welche anhand definierter Vorgaben, im Selbststudium zu erarbeiten ist.

Für die Ausarbeitung des IU Projektberichtes bist du selbst verantwortlich und kannst deine Zeit und Ressourcen nach Belieben einplanen.

Abschreiben oder die Hilfe von Ghostwritern ist natürlich nicht erlaubt. Dies muss du vor der Abgabe deiner Arbeit in einer eidesstattlichen Erklärung bestätigen.

Der IU Projektbericht im Modul Agiles Projektmanagement

Der IU Projektbericht ist eine schriftliche Ausarbeitung eines Projektes und stellt eine Prüfungsleistung dar. Als Hilfestellung wird im entsprechenden Modul ein Projektleitfaden zur Verfügung gestellt. Die Ausarbeitung findet als Hausarbeit bzw. im Selbststudium statt.

Hilfreiche Tipps findest du außerdem hier:

So erstelle ich in 10 Schritten meine IU Hausarbeiten

Mein IU Hausarbeiten Deckblatt kostenlos zum Download

Der IU Projektleitfaden zum IU Projektbericht enthält im Modul „Agiles Projektmanagement“ Angaben zu:

  • Definition und Zielsetzung
  • Gliederung und Aufbau
  • Themen und Aufgaben
  • Hinweise zur Bewertung
  • Formale Richtlinien

Es besteht im IU Modul Agiles Projektmanagement die Möglichkeit, für den IU Projektbericht aus drei Themen zu wählen. Meine Entscheidung fiel auf das Thema „Verkürzung der Release-Zeiten und schnelles Kundenfeedback“.

Die zwei weiteren möglichen Themen sind, „Transformation in eine agile Vertriebs-Organisation“ und „Agile Planung“.

Sehr ungewöhnlich war für mich, dass im Modul Agiles Projektmanagement, keine weiteren Unterlagen wie Skripte, Tutorien oder Musterklausuren angeboten werden! Man muss sich alle, für den IU Projektbericht nötigen Informationen, selbst erarbeiten.

Glücklicherweise gab es zum von mir gewählten Thema Schnittpunkte zu zwei anderen Modulen. Die Module „Grundlagen der industriellen Softwaretechnik“ und „Requirement Engineering“ behandeln auch die agilen Methoden im Projektmanagement. So konnte ich mich durch das Transferwissen schnell ins Thema einarbeiten.

Sollten trotzdem Fragen zum Modul und / oder dem IU Projektbericht auftreten, steht in der Regel der Tutor hilfreich zu Seite.

P.S. Auf meinem Blog findest du nicht nur diesen Projektbericht, sondern noch weitere IU Hausarbeiten.

Mein persönlicher IU Projektbericht zum IU Modul Agiles Management.

Um dir einen Einblick in das IU Modul Agiles Projektmanagement zu geben, stelle ich hier meinen IU Projektbericht zur Verfügung.

Bitte denke daran, dass dies eine vom mir persönlich erstellte, wissenschaftliche Arbeit ist. Das Kopieren und Vervielfältigen ist nur in Auszügen und unter Verwendung der richtiger Zitierweise gestattet! Um Probleme mit dem Urheberrecht vorzubeugen, habe ich einige Bilder entfernt.

Mein IU Projektbericht

IU Modul: Agiles Projektmanagement (DLBDBAPM01)

Thema IU Projektbericht: Anpassung der Projekt- und Organisationsstrukturen an die agilen Markt- und Kundenanforderungen bei der Firma Stöffel.

Deckblatt: Erstelle ein perfektes Hausarbeiten Deckblatt


Mein IU Projektbericht – die Einleitung

1. Einleitung

1.1 Problemstellung

Die Fa. Stöffel ist ein renommiertes und traditionell ausgerichtetes Unternehmen. Aufgrund der wachsenden Kundenanforderungen und dem erhöhten Konkurrenzdruck gerät das Unternehmen seit zwei Jahren mehr und mehr unter Druck. Die Kunden fordern immer schnellere Produktupdates. Was bei Konkurrenten bereits möglich ist, wird im Hause Stöffel durch die klassischen Projekt- und Organisationsstrukturen behindert und ausgebremst.

Derzeit herrschen bei der Fa. Stöffel klassisch hierarchische Strukturen. Produkte werden nach dem sequenziellen Wasserfallmodell entwickelt. In Kombination können so im jährlichen Rhythmus Produktupdates veröffentlicht werden.

Die Forderungen der Kunden hingegen sind, denn Entwicklungszyklus von Produktupdates auf einen monatlichen Rhythmus zu reduzieren. Konkurrenten der Fa. Stöffel sind bereits in der Lage diesen Forderungen nachzukommen. Möglich ist dies, da bei der Konkurrenz die Entwicklung der Produkte in iterativen Vorgehensmodellen stattfinden.

Um die Kundenbedürfnisse zu befriedigen und keine Marktanteile zu verlieren, plant die Fa. Stöffel eine Umstrukturierung der Produktentwicklung. Die Geschäftsführung fordert dabei, die Einführung einer iterativen Entwicklung mit allen nötigen Maßnahmen.

1.2 Zielsetzung

Von der Geschäftsführung der Fa. Stöffel wurde als wesentliches Ziel festgelegt, den Kundenanforderungen nach zu kommen und in monatlichen Zyklen neue Produktupdates zu liefern. Dazu soll das bisherige Wasserfallmodell durch ein iteratives Vorgehensmodell ersetzt werden. Hierfür ist ein passendes agiles Modell auszuwählen. Im Kontext dazu sind Projekt- und Organisationsstrukturen sowie die dazugehörigen Rollen und Verantwortlichkeiten anzupassen. Zu beachten ist dabei, dass auch die Meeting-Strukturen und die zu erstellenden Artefakte an das veränderte Vorgehen angeglichen werden.

1.3 Vorgehensweise

Um die gesetzten Ziele zu erreichen, war vor der Projektumsetzung eine detailliere Planung nötig. Diese setzten sich u. a. aus der Vorbereitungsphase und der Projektplanung zusammen. Im Zuge der Projektvorbereitung mussten Stakeholder und Anforderungen definiert, das iterative Vorgehensmodell bestimmt sowie eine Risikoanalyse durchgeführt werden. Die Projektplanung bestand hauptsächlich aus der Terminplanung sowie der Kosten- und Budgetermittlung. Der Kern der Vorbereitung lag auf der Auswahl des zukünftiges iteratives Vorgehensmodells.

Das Ziel der Durchführungsphase bestand darin, den ersten agilen Durchlauf mit Scrum zu bewältigen. Dazu mussten jedoch erst erhebliche Anpassungen an der Organisations- und Projektstruktur vorgenommen werden. Im Zuge der Reorganisation werden einige Führungspositionen wegfallen, was zu Schwierigkeiten im Projektverlauf führen kann. Es ist daher volles Augenmerk auf die Kommunikation mit den betroffenen Mitarbeitern zu legen. Gezielte Schulungen sollen dieses Vorgehen nochmals verstärkt und die Mitarbeiter auf den richtigen Weg bringen. Nach der Implementierung von Scrum im Prozess, ist der erste agile Durchlauf geplant. Um hier reibungslos agieren zu können, soll ein erfahrener externer Berater die ersten Scrum Durchläufe betreuen.


Mein IU Projektbericht – der Hauptteil

2. Umsetzung Transformationsprojekt – Agiles Vorgehensmodell

2.1 Planungsphase

Ehe das eigentliche Projekt gestartet werden konnte, mussten diverse Vorbereitungen und Planungen getroffen werden. Wie von der Geschäftsleitung gefordert, gehörte dazu die Termin- und Budgetplanung sowie eine Risikoanalyse. Der wichtigste Bestandteil in dieser Projektplanung war jedoch die Auswahl des passenden iterativen Vorgehensmodells.

2.1.1 Stakeholder definieren

Stakeholder sind Personen oder Personengruppen, die grundsätzlich ein berechtigtes Interesse am Projekt und dem Projektergebnis haben, in irgendeiner Weise vom Projekt und dem Projektergebnis betroffen sind und den Anspruch haben, Einfluss auf das Projekt und das Projektergebnis zu nehmen (Dort 2019). Somit zählen nicht nur die Geschäftsführer, sondern auch Mitarbeiter, Lieferanten und Kunden zu den Stakeholdern. Für das Projekt war es somit wichtig, alle relevanten Beteiligten zu bestimmen und aufzulisten. Dies geschah unter Zuhilfenahme einer Stakeholder-Tabelle. Um die Stakeholder Involvierung besser planen zu können, wurden in dieser Tabelle für jeden Stakeholder u. a. noch Angaben zur Position, seiner Macht, der benötigten Information und der Projektrolle eingetragen.

2.1.2 Anforderungen definieren und dokumentieren

Anhand dem Projektziel, den bestehenden Dokumenten und Prozessen sowie zusammen mit den benannten Stakeholdern konnten die Anforderungen ermittelt werden. Dies geschah unter Zuhilfenahme geeigneter Ermittlungstechniken. So kamen u. a. Befragungs-, Kreativitäts- und Beobachtungstechniken zum Einsatz. Dabei konnten durch die kreative Zusammenarbeit im Team einige Konflikte aus dem Weg geräumt und wichtige innovative Anforderungen ermittelt werden. Die ermittelten Anforderungen an das Transformationsprojekt wurden im Anschluss unter Bestimmung von Zweck und Zielgruppe im entsprechenden Detailgrad und der nötigen Dokumentationsform dokumentiert.

2.1.3 Iteratives Vorgehensmodell bestimmen

Anhand der ermittelten Anforderungen musste nun ein für die Fa. Stöffel geeignetes iteratives Vorgehensmodell bestimmt werden. Die Zielsetzung des Projektes lautet, das bisherige sequentielle Vorgehen durch ein agiles und iteratives Modell zu ersetzten. Dazu konnte unter Zuhilfenahme der ermittelten Anforderungen und den Unternehmenszielen ein passendes Vorgehensmodell ausgewählt werden. Die Kunden haben die beiden Modelle Scrum und Extreme Programming (XP) empfohlen, die Geschäftsführung hat zudem noch des Modell Kanban ins Spiel gebracht.

Kanban wird oft zur Optimierung des Workflows in der Produktion von Automobilherstellern eingesetzt. Böhm (2019, S.31) schreibt dazu, „Kanban ist ein System zur Steuerung von aufeinander aufbauenden Abläufen in einer Wertschöpfungskette bzw. der Produktentwicklung. Zentral ist dabei die Visualisierung des Arbeitsablaufes“. Für den Bereich der Softwareentwicklung ist Kanban somit nur bedingt anwendbar. Extreme Programming (XP) wird als die extremste Form der agilen Softwareentwicklung bezeichnet. Es ist sehr gut geeignet, wenn der Kunde zu Beginn noch keine klare Definition der fertigen Software hat.

Abbildung 1 (wurde hier entfernt): Agile Scrum. Quelle: https://hangoutagile.com/agile-scrum

Scrum ist ein bewährtes Modell im Bereich der agilen Softwareentwicklung. „Das Herz von Scrum ist der Sprint, ein Zeitraum [Time Box] von maximal einem Monat, innerhalb dessen ein fertiges [„Done“], nutzbares und potenziell auslieferbares Produktinkrement hergestellt wird.“ (Schwaber/Sutherland 2017, S.9).

Abbildung 2 (wurde hier entfernt): Eignung für Scrum. Quelle: Maximini 2018, S. 31.

Laut den Projektzielen und den daraus ermittelten Anforderungen, soll den Kunden in monatlichen Zyklen Produktupdates in Form von Software geliefert werden. Als passendes Vorgehensmodell hat das Projektteam hierfür Scrum definiert. Dies spiegeln auch die Tabelle (Abbildung 2) und die Aussage von Maximini (2018, S.31) wider, „wenn Sie also Software entwickeln wollen, können Sie sich ruhigen Gewissens für Scrum entscheiden“. Weiter spricht für Scrum die Bewährtheit des Modells. Da agile Methoden den Mitarbeiter bisher unbekannt sind, wurde Scrum der noch agileren Variante Extreme Programming (XP) vorgezogen. Kanban wurde ausgeschlossen, da es vermehrt in Bereichen der Produktion und Produktentwicklung und nicht der Softwareentwicklung eingesetzt wird.

2.1.4 Risikoanalyse erstellen

Ein wichtiger Punkt für die Geschäftsführung war, vor der Projektdurchführung eine Risikoanalyse zu erstellen. In der Risikoanalyse sollten mögliche Risiken dargestellt und daraus resultierende Schäden aufgezeigt werden.

Die Risikoanalyse wurde vom Projektleiter mit einem Kernteam aus Stakeholdern durchgeführt. Da das Thema Risikoanalyse nicht neu im Unternehmen war, wurden vorhanden Vorlagen zur Risikobewertung verwendet. Alle offensichtlichen Risiken konnten mit Hilfe einer Risikomatrix bewertet und anhand von Risikoklassen beurteilt werden. Als Hauptrisiken wurden das Scheitern des Projektes und die Nichtanpassungsfähigkeit der Mitarbeiter definiert.

Risiken eines Projektabbruchs:

Durch den Abbruch bzw. das Scheitern des Projektes müsste die Fa. Stöffel trotzdem die Kosten für bereits aufgewendeten Vorbereitungen tragen. Da im neuen iterativen Vorgehensmodell in monatlichen Zyklen gearbeitet wird, wäre hier das Risiko eines Abbruchs im akzeptablen Rahmen. Es könnte beim Abbruch direkt wieder auf das alte Modell gewechselt werden.

Risiken der Nichtanpassungsfähigkeit von Mitarbeitern:

In einem agilen Vorgehensmodell ist es sehr wichtig, dass alle Teammitglieder und Stakeholder am gleichen Ziel arbeiten und sich gegenseitig unterstützen. Der Scrum Guide verdeutlicht diese Aussage. „Das Scrum-Team und seine Stakeholder sind sich einig, offen mit allen Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen. Mitglieder von Scrum-Teams respektieren sich gegenseitig als fähige, eigenverantwortliche Individuen“ (Schwaber/Sutherland 2017, S.6). Für die meisten Mitarbeiter der Fa. Stöffel wird das die größte Umstellung im Transformationsprojekt sein. Da im aktuellen Wasserfallmodell bisher jeder Mitarbeiter für sich an definierten Arbeitspaketen gearbeitet hat, wird die agile Einbindung in Teams eine grundlegende Herausforderung für alle Beteiligten.

2.1.5 Terminplanung erstellen

Anhand der bisher gewonnenen Erkenntnisse wurde ein Terminplan für das Transformationsprojekt „Anpassung der Projekt- und Organisationsstrukturen an die agilen Markt- und Kundenanforderungen bei der Firma Stöffel“ erstellt.

IU Agiles Projektmanagement, mein IU Projektbericht Terminplan (PSP)

Abbildung 3: Terminplan für das Einführungsprojekt. Quelle: eigene Darstellung

2.1.6 Kosten- und Budgetplanung durchführen

Die Kostenplanung für das Projekt wurde in zwei Bereiche unterteilt, den externe- und den internen Aufwendungen. Zu den externen Kosten zählten maßgeblich die Leistungen für Beratungen sowie die Schulung der Mitarbeiter. Interne Kosten entstanden durch aufgewendete Arbeitszeiten zur Projektdurchführung. Anhand dem tagesgenauen Terminplan ließen sich die Kosten sehr genau abschätzen und das nötige Budget ermitteln.

2.1.7 Präsentation der Projektvorbereitung an die Geschäftsführung

Die bisherigen Ergebnisse und Erkenntnisse wurden der Geschäftsführung vorgelegt und detailliert erörtert. Nach Abwägung der Risiken und aufgrund der Gefahr, bei nicht Einführung agiler Vorgehensmodelle Kundenaufträge zu verlieren, hat sich die Geschäftsführung einstimmig zur Durchführung des Projektes entschieden. Aufgrund der Dringlichkeit der Projektumsetzung und ausgiebiger Diskussion konnte der Endtermin noch um eine Woche nach vorne verlegt werden. Hier kam der Vorschlag, parallel zur Anpassung der Organisationsstruktur bereits mit der Schulung der Mitarbeiter zu beginnen. Das nötige Budget lag innerhalb des geplanten Rahmens, von der Geschäftsführung gab es dahingehend keine Einwände. Das Projekt konnte pünktlich zum geplanten Starttermin beginnen.

2.2 Durchführungsphase

In der Durchführungsphase wurden zuerst die Organisations- und Projektstrukturen an die neuen Erfordernisse angepasst. Weiter war eine intensive Schulung der Mitarbeiter hinsichtlich der agilen Projektabwicklung nötig. Erst im Anschluss daran, konnte Scrum implementiert und durchlaufen werden.

2.2.1 Anpassung der Organisations- und Projektstruktur an Scrum

Ehe das neue Vorgehensmodell Scrum im Entwicklungsprozess übernommen werden konnte, waren die Organisations- und Projektstrukturen an das neue Vorgehensmodell anzupassen. Da bei einer Umstrukturierung immer auch zwischenmenschliche Konflikte auftreten, lag das Augenmerk hier auf einer gezielten Kommunikation mit den betroffenen Mitarbeitern.

Kern des neue Agilen Vorgehensmodells Scrum ist das Scrum-Team. Es besteht in der Regel aus drei Rollen, dem Scrum Master, dem Product Owner und dem Entwicklungsteam. In Summe sind es ca. fünf bis zehn Teammitglieder. Vgl. Scrum Guide, „Scrum-Teams sind selbstorganisierend und interdisziplinär. Selbstorganisierende Teams entscheiden selbst, wie sie ihre Arbeit am besten erledigen, anstatt dieses durch andere Personen außerhalb des Teams vorgegeben zu bekommen. Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen außerhalb des Teams abhängig zu sein“ (Schwaber/Sutherland 2017, S.6). Um diese Anforderungen umzusetzen, mussten die alten Organisations- und Projektstrukturen aufgespalten und angepasst werden.

Die bisherige Projektstruktur bestand aus einem klassischem Wasserfallmodell. Angefangen von der Anforderungsermittlung bis zur abschließenden Systemabnahme wurden dabei alle Aufgaben Schritt für Schritt abgearbeitet. Im neuen iterativen Vorgehensmodell Scrum hingegen, ist das Vorgehen gegenteilig. Hier wird in kurzen und fest definierten Zeiträumen (genannt Sprint) jeweils ein auslieferbares Produkt erzeugt. Mit jedem Sprint wird das Produktergebnis verbessert. Somit können, wie vom Kunden gefordert, in kürzeren Zeitabständen neue Produktupdates ausgeliefert werden. Um in Sprints agieren zu können wurde auch die Organisationsstruktur entsprechend der erforderlichen Rollen (Scrum Master, Product Owner und Entwicklungsteam) angepasst.

Der Scrum Master unterstützt und hilft dem Scrum Team durch sein Expertenwissen im Bereich Scrum, die Scrum Leitlinien zu leben und zu verstehen. Weiter steht er bei allen Fragen und Problemen zu Scrum, dem Team und allen Stakeholdern zur Verfügung. Im derzeitigen Personalstamm der Fa. Stöffel ist keine entsprechende Kompetenz zu Scrum vorhanden. Die Schulung eines Mitarbeiters wäre nicht im zeitlichen Rahmen möglich. Daher fiel die Entscheidung, von extern einen erfahrenen Scrum Master einzustellen. „Suchen Sie jemanden mit Scrum-Erfahrung, der die Rolle des Scrum Masters einnimmt“ (Maximini 2018, S.34), belegt dieses Vorgehen nochmal.

Der Product Owner ist verantwortlich für das Management des Product Backlog und den Wert des Produktes zu maximieren (Schwaber/Sutherland 2017, S.6). Außerdem kennt er als einziger die Kundenanforderungen und -wünsche. Auch wenn der bisherige Produktmanager diese Kompetenzen noch nicht komplett erfüllen kann, wurde entschieden, ihn als zukünftigen Product Owner einzusetzen. Um kein Risiko einzugehen, wird ihm für ca. sechs Monate ein externer Berater mit Erfahrung im Bereich Scrum zur Seite gestellt. So ist neben einer ersten Schulung ein gezieltes On-Job-Training möglich. Ein weiterer Vorteil besteht darin, dass die Kundenkontakte des Produktmanagers weiterhin in der Position als Product Owner bestehen bleiben. Für die Kunden ändert sich somit der vertraute Ansprechpartner nicht.

Das Entwicklungsteam besteht aus Profis, die am Ende eines jeden Sprints ein fertiges [„Done“] Inkrement übergeben, welches potenziell auslieferbar ist. Entwicklungsteams sind von der Organisation so strukturiert und befähigt, dass sie ihre eigene Arbeit selbst organisieren und managen (Schwaber/Sutherland 2017, S.6). Somit sind im neuen Scrum Entwicklungsteam kein Projektleiter und auch keine Führungskräfte mehr nötig. Weiter wird auch die Abteilung des Betriebsmanagers im Entwicklungsteam nicht benötigt. Für die neue Organisation bedeutete dies, dass das derzeitige Einliniensystem aufgespalten werden musste. Da nur noch für die Entwicklung essenzielle Funktionen integriert werden, sind die bisherigen Projektleiter, Lead Entwickler, Testmanager, Betriebsmanager und Betriebs Engineers im Scrum Team nicht mehr nötig. Ihnen wurden vorerst andere Aufgaben im Unternehmen übertragen. Der Entwickler, der Systemarchitekt, der Konfiguration Expert und der Dokumentation Expert konnten jedoch direkt ins neue Scrum Entwicklungsteam integriert werden. Von den bisherigen zwei Testern wird aufgrund der geringeren Arbeitslast nur einer ins Entwicklungsteam übernommen. Der zweite Tester übernimmt zukünftig andere Aufgaben im Unternehmen.

In Summe konnte der Personalstamm des bisherigen Projektteams von gesamt 13 Mitarbeitern auf sieben Mitarbeiter im neuen Scrum Team reduziert werden, was somit den Vorgaben von Scrum entspricht. Mit den nicht mehr benötigen Mitarbeitern wird die Fa. Stöffel, außerhalb dieses Projektes, über deren künftige Aufgaben bzw. den weiteren Verbleib im Unternehmen sprechen. Dies war eine der größten Schwierigkeiten im Verlauf des Transformationsprojektes, da die Umstellung für die beteiligten Mitarbeiter mit großen Sorgen verbunden war. Entgegenwirkend konnte die Geschäftsführung, zusammen mit der Projektleitung, durch ausgiebige und gezielte Kommunikation mit allen Beteiligten die Situation vor der Eskalation bewahren. So wurde u. a. dargelegt, dass ohne diese Umstellung eventuell die Kunden abspringen werden, was dann wiederum die Existenz der Fa. Stöffel gefährdet hätte. Durch Klarheit und Transparenz konnte das Vertrauen der Mitarbeiter gewonnen und die Projekt- und Organisationsstrukturen entsprechend angepasst werden.

2.2.2 Anpassung der Meeting Strukturen und Artefakte an Scrum

Scrum besteht aus nur drei Artefakten, dem Produkt Backlog, dem Sprint Backlog und dem Inkrement. Schwaber und Sutherland (2017, S.15f.) beschreiben diese Artefakte wie folgt. „Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich. Das Sprint Backlog ist ein ausreichend detaillierter Plan, um den Fortschritt innerhalb des Sprints im Daily Scrum erkennen zu können. Das Entwicklungsteam passt das Sprint Backlog während des Sprints an; das Sprint Backlog entwickelt sich so während des Sprints. Diese Entwicklung erfolgt, während das Entwicklungsteam den Plan abarbeitet und mehr über die noch benötigten Schritte zur Erreichung des Sprint-Ziels. Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product-Backlog-Einträgen und dem Resultat der Inkremente aller früheren Sprints. Am Ende eines Sprints muss das neue Inkrement fertig [„Done“] sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition of Done des Teams erfüllen.“

Um die Anforderungen der neuen Artefakte zu erfüllen, konvertierte man bestehende Dokumente und Prozesse in die neuen Artefakte. In das neue Product Backlog wurden u. a. die Inhalte der Lasten- und Pflichtenhefte, sämtliche Anforderungskataloge und offene To-Do Listen integriert. Nach der Übertragung musste alle Product Backlog Einträge noch detailliert und priorisiert werden. Mit Hilfe des fertigen Product Backlog erstellte das Team das neue Sprint Backlog. Dazu wurde, anhand der Dauer des ersten Sprint Durchlaufes, ein ausreichend großes Arbeitspaket bestehend aus Produkt Backlog Einträgen ermittelt und in das Sprint Backlog übertragen. Das neu erstellte Sprint Backlog dient innerhalb des ersten Sprints um ein fertiges Inkrement zu entwickeln.

Das iterative Vorgehensmodell Scrum basiert außerdem auf festgelegten Ereignisstrukturen auch Meetings genannt. Bestehenden Strukturen mussten somit im Zuge des Transformationsprojektes angepasst werden. Als Ereignisse sind in Scrum (neben dem Sprint) noch das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive definiert. Zusammengefasst handelt es sich hier, mit Ausnahme des Sprints, um zeitlich festgelegte und definierte Besprechungen. Parallel zu den Artefakten passte das Projektteam auch die bestehenden Besprechungen der Fa. Stöffel an das neue Vorgehensmodell an. Unter Mitwirken des externen Beraters konnte ein genauer Meeting-Ablauf für den ersten Scrum Durchlauf erstellt werden. Das täglich stattfindende Daily Scrum gilt dabei von allen Ereignissen laut Gloger und Margetich (2018, S.71) fast als das Symbol der agilen Kultur. Anstatt in gewohnter Weise im Besprechungsraum, treffen sich die Teammitglieder am Taskboard, einer Pinnwand mitten im Raum, an dem die einzelnen Arbeitspakete in Tasks heruntergebrochen visualisiert werden.

IU Agiles Projektmanagement, mein IU Projektbericht - Ablaufplan Scrum

Abbildung 4: Go-Live – Erster Scrum Durchlauf bei Fa. Stöffel. Quelle: eigene Darstellung

2.2.3 Schulung der Mitarbeiter

Ehe das neue Vorgehensmodell Scrum im Entwicklungsprozess übernommen werden konnte, mussten alle beteiligten Mitarbeiter gezielt geschult werden. Der Projektleiter vermittelte dabei Anpassungen zur Organisations- und Projektstruktur. Hingegen führte ein externer Scrum Berater (aufgrund der Wichtigkeit) die Schulungen zu Scrum sowie den neuen Artefakten und Meeting Regeln durch. Dieser betreute im Anschluss auch die Einführung von Scrum im Prozess und stand den Mitarbeitern dabei unterstützend zur Seite. So sollte ein reibungsloser Übergang vom sequenziellen zum iterativen Abarbeiten der Aufgaben sichergestellt werden.

Zu Beginn bekamen alle internen Stakeholder eine Schulung zum Thema Scrum. Hierbei legten die Geschäftsführer viel Wert darauf, den Mitarbeitern die Theorie und die Werte von Scrum näherzubringen. Im Anschluss daran, gab es für definierte Mitarbeiter noch rollenbezogen Schulungen. Im Speziellen für die künftigen Product Owner und Scrum Teams. Sehr wichtig war es bei den Schulungen, den Mitarbeitern die Prinzipien agiler Softwareentwicklung zu vermitteln, denn ohne deren Verständnis ist ein iteratives Vorgehen nicht umzusetzen. Im Manifest für agile Softwareentwicklung (Beck et al. 2001) heißt es dazu u. a., „Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten“ sowie „die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams“.

2.2.4 Go-Live – Erster Scrum Durchlauf

Nachdem alle Vorbereitungen erfolgreich abgeschlossen waren, einigte sich das Projektteam noch auf ein geeignetes Entwicklungsprodukt für den ersten agilen Durchlauf. Die Entscheidung fiel auf ein eher einfaches Produktupdate. Dies kommt dem neuen Entwicklungsteam entgegen, da dies sich neben der Entwicklung auch auf den neuen Scrum-Prozess konzentrieren muss.

Im Anschluss hat die Projektleitung den ersten Scrum Durchlauf angestoßen. Für den ersten Sprint-Zeitraum hat man zwei Wochen angesetzt. Eine weitere Sprinteinheit von zwei Wochen soll daran folgen. Unterstützend wird der externe Berater das Scrum-Team dabei in den nächsten Wochen begleiten. Die erste Sprinteinheit startete mit einem vier stündigen Sprint Planning. Das Scrum Team erarbeitete anhand dem Product Backlog, die für die Sprinteinheit gesetzten Ziele. Dabei kam es zu ersten Meinungsverschiedenheiten innerhalb des Teams. Der Product Owner war bestrebt möglichst viele Aufgaben aus dem Product Backlog in das Sprint Backlog zu packen. Die Entwickler, welche aus praktischer Erfahrung die Aufwände besser abschätzen können, hatten hier andere Vorstellungen. Durch gezielte Kommunikation konnte der erfahrene Berater das Team auf einen gemeinsamen Weg bringen. Ein für alle akzeptabler Kompromiss als Ziel für das Sprint Backlog wurde festlegen.

In den folgenden zwei Wochen, während dem Sprint, leistete das Entwicklungsteam die Entwicklungsarbeit. Hierbei versammelte sich das Scrum Team täglich um acht Uhr zum Daily Scrum Meeting. Das Team plante darin gemeinsam die Arbeit für den Tag und überprüfte ob die Arbeitslast noch zu den Aufgaben aus dem Product Backlog passt. Während dem Sprint bestand die Aufgabe des Scrum Masters die Scrum Richtlinien zu überprüfen und wenn nötig beratend zur Seite zu stehen. Nach Ablauf der zwei Wochen bzw. zum Ende der Sprint-Einheit folge das Sprint Review. Im Sprint Review wurde das entwickelte Produkt vom Entwicklungsteam den relevanten Stakeholdern vorgeführt. Das Produkt wurde überprüft und alle Abweichungen im Product Backlog angepasst. Das neue Product Backlog diente wiederum als Vorlage für die nächste Sprinteinheit.

Die Sprint Retrospektive ist das abschießende Meeting eines Scrum Durchlaufes. Das Scrum-Team überprüfte dabei selbstkritisch das Vorgehen und die Ergebnisse der letzten Sprints. Um dem iterativen Gedanken zu folgen, ist in der Sprint Retrospektive eine grundlegende Reflexion und Selbsteinschätzung der Ergebnisse äußerst wichtig. Aufgrund des relativ einfach gewählten Produktes, gab es im ersten Scrum Durchlauf keine Probleme hinsichtlich der Entwicklungsarbeit. Für den neuen Product Owner war es jedoch nicht immer einfach sich mit den neuen Artefakten Product Backlog und Sprint Backlog zurecht zu finden. Nach dem ersten Durchlauf folgte in gleicher Weise direkt der Zweite. Das Team handelte Sprint Planning, Sprint, Sprint Review und Sprint Retrospektive in gleicher Art und Weise ab. Aufgrund der immer besser werdenden Kommunikation innerhalb des Teams, konnten negative Erfahrungen aus dem ersten Durchlauf bereits minimiert und verbessert werden. Mit Hilfe von Scrum lieferte das Scrum-Team nach vier Wochen und zwei Sprints ein für den Kunden zufriedenstellendes Produkt-Update aus.

2.2.5 Projektabschluss

Der Projektabschluss war der letzte Meilenstein im Transformationsprojekt bei der Fa. Stöffel. Unter Abwägung der Chancen und Risiken wurde das Transformationsprojekt mit hohen Erwartungen von der Geschäftsführung in Leben gerufen. Trotz einer sehr intensiven Vorbereitung ist die Projektleitung bei der Durchführung immer wieder auf kleinere Probleme gestoßen. Die Mitarbeiter betrachteten anfänglich vor allem die Anpassung der Organisationsstruktur sehr kritisch. Gezielte interne Kommunikation konnte hier jedoch schnelle Abhilfe schaffen. Positiv aufgenommen wurde hingegen die kontinuierliche Betreuung des Projektes durch den externen Berater sowie die Neueinstellung eines erfahrenen Scrum Masters. Beide halfen durch ihre Erfahrung die Mitarbeiter zu sensibilisieren, was maßgeblich zum erfolgreichen Projektabschluss beigetragen hatte. So konnte die Fa. Stöffel im Zeitraum von sieben Wochen ein neues Vorgehensmodell einführen und ist jetzt wieder auf Augenhöhe mit den Wettbewerbern.

Im ersten der beiden Sprinteinheiten sind auch wieder kleinere Konflikte im Bereich der Kommunikation aufgetreten. Durch ein gezieltes Sprint Review nach dem ersten Sprint konnte dies im zweiten Durchlauf verhindert werden. Nach zwei erfolgreichen Sprints übergab das Scrum-Team ein fertiges Produkt-Update an den Kunden.

Nach dem erfolgreichen Durchlauf von Scrum und dem Projektabschluss liegt es nun in den Händen der Geschäftsführung, das weitere Vorgehen zu bestimmen. Von Seiten der Projektleitung und auch dem gesamten Scrum Team wird die Empfehlung ausgesprochen, Scrum im Unternehmen zu Skalieren und über weitere Entwicklungsteams auszurollen.


Mein IU Projektbericht – der Schluss

3. Projektergebnis und Zielerreichung

Als maßgeblicher Faktor für die erfolgreiche Durchführung eines Projektes ist die Zielerreichung zu nennen. Hierbei gleicht man die Projektzielt mit den Projektergebnissen ab. Da Hauptziel dieses Projektes war es, den Kundenanforderungen der Fa. Stöffel nach zu kommen und in monatlichen Zyklen neue Produktupdates zu liefern. Hierfür wurde ein Terminplan erstellt und ein Projektbudget ermittelt, auch diese Parameter zählen in die Zielerreichung mit ein.

Nach einer detaillierten Projektvorbereitung, konnte der erste Scrum Durchlauf unter Einhaltung der gesetzten Termine pünktlich starten. Auch das angestrebte Endziel wurde, durch die enge Zusammenarbeit aller Beteiligten, auf den Punkt erreicht. Nach zwei Scrum Durchläufen, konnte das geplante Produktupdate nach Kundenvorgaben entwickelt und übergeben werden. Das Projektbudget hingegen wurde um ca. 15% übertroffen, da die Kosten für Schulungen und den neuen Scrum Master höher als geplant ausgefallen sind.

Der neu eingestellt Scrum-Master kam seinen Aufgaben hervorragend nach, und schaffte es immer wieder das Scrum-Team zu motivieren und bei Fragen zum Ablauf unterstützend zu agieren. Auch der Produktmanager konnte sich gut in seine Rolle als Product Owner integrieren. Wobei er hinsichtlich der Arbeit mit den neuen Artefakten, wie u. a. dem Product Backlog, tatkräftige Unterstützung vom externen Berater bekam. Das Entwicklungsteam benötigte fast zwei Wochen, bis sich die neuen Abläufe eingespielt hatten. Auch hier unterstützen der Scrum Master und der externen Berater in weiten Bereichen, so dass das Team schon im zweiten Scrum Durchlauf selbstständig agieren konnte.

Wichtig ist jetzt, dass das agile Vorgehen weiteres Vertrauen bei den Mitarbeitern findet. Auch ist in nächster Zeit darauf zu achten, dass die Meetings strikt eingehalten sowie die Artefakte nach Vorgabe erstellt und bearbeitet werden. Hier steht für weitere vier Monate der externe Berater zur Seite. In diesem Zeitraum hat die weitere Sensibilisierung der Mitarbeiter höchste Priorität.

Zurückblickend war das Projekt ein großer Erfolg für die Fa. Stöffel, da nun den Kundenanforderungen von monatlichen Produktupdates nachkommen werden kann. Für die Fa. Stöffel ist das nicht nur ein wichtiger Schritt zur Kundenbindung, sondern auch zur Akquise neuer Aufträge. Ohne die Umstellung wären womöglich Kunden abgesprungen, was die Existenz des Unternehmens bedroht hätte. Abschließend empfiehlt das Projektteam der Geschäftsführung, das agile Vorgehensmodell Scrum über weitere Entwicklungsteams zu skalieren. Hierbei können die bereits gewonnenen Erfahrungen hilfreich verwendet werden, so dass das Ausrollen schneller und kostengünstiger von Statten gehen kann.

I. Literaturverzeichnis

  • Beck, K. et al. (2001): Manifest für Agile Softwareentwicklung. (URL: http://agilemanifesto.org/iso/de/principles.html [letzter Zugriff: 29.06.2020]).
  • Böhm, J. (2019): Erfolgsfaktor Agilität. Springer Vieweg, Wiesbaden.
  • Dort, S. (2019): Die Stakeholderanalyse. (URL: https://www.agile-master.de/stakeholderanalyse-projektmanagement [letzter Zugriff: 18.06.2020]).
  • Gloger, B./Margetich, J. (2018): Das Scrum-Prinzip: Agile Organisationen aufbauen und gestalten. 2. Auflage, Schäffer-Poeschel, Stuttgart.
  • Maximini, D. (2018): Scrum – Einführung in der Unternehmenspraxis. 2. Auflage, Springer Gabler, Berlin.
  • Schwaber, K./Sutherland, J. (2017): Der Scrum Guide™. (URL: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf [letzter Zugriff: 29.06.2020]).

Wie wurde mein IU Projektbericht im Modul Agiles Projektmanagement bewertet

Nach einer Wartezeit von über sechs Wochen wurde die Note zum IU Projektbericht veröffentlicht. Diese Wartezeit ist im IU Fernstudium bei Hausarbeiten leider normal.

Da die Notenvergabe immer 30 Tage nach Monatsende (in dem du eingereicht hast) erfolgt, kann es sein, dass es über zehn Wochen dauert, bis die Note kommt. Wenn du z. B. am 1. Juni einreichst, bekommst du die Note der Hausarbeit erst 30 Tage nach dem 30. Juni.

Für mich hat sich das Warten auf die Note wirklich gelohnt, denn mein IU Projektbericht „Agiles Projektmanagement“ wurde mit der Note 1,3 bzw. 92 % bewertet.

IU Fernstudium, meine Note im IU Modul Agiles Projektmanagment

Hierzu die Bewertungskriterien im Detail:

  • Transfer (15 %): 90 %
  • Dokumentation (10 %): 90 %
  • Ressourcen (10 %): 90 %
  • Prozess (25 %): 90 %
  • Kreativität (15 %): 100 %
  • Qualität (25 %): 90 %
  • Summe (100 %): 92 %

Hast du Fragen zu meinem IU Projektbericht? Schreib es mir doch bitte kurz in einem Kommentar.

Mein Fazit zum IU Modul Agiles Projektmanagement

In Summe hatte ich für die Ausarbeitung des IU Projektberichtes gute zwei Wochen benötigt. Dies entspricht in etwa 50 % der von der IU – Internationalen Hochschule veranschlagten Zeit (anhand der 5 ECTS Punkte für das Modul Agiles Projektmanagement). Da ich bereits ein gewisses Vorwissen im Bereich agile Methoden hatte und zudem recht fix im Schreiben von Texten bin, konnte ich dieses Modul schneller als geplant abschließen.

Trotz der fehlenden Lehrmaterialien hat es mir Spaß gemacht, mich in dieses komplexe Thema einzuarbeiten. Ein reines Auswendiglernen wie z. B. in BWL ist hingegen nicht so mein Ding. Hier ist wohl jeder ein individueller Lerntyp und hat seine Vorlieben und Abneigungen.

Um dich zu unterstützen, findest du im Beitrag „So erstelle ich in 10 Schritten meine IU Hausarbeiten“ weiterführende Infos zum Thema.

Wenn du weitere Fragen zum IU Projektbericht oder dem IU Fernstudium hast, dann schreibe jetzt einen Kommentar.

Ich wünsche dir viel Spaß und Erfolg beim Lernen

Herzliche Grüße

Dein Michael

P.S. Du bist selbst Student und hast Interesse deinen eigenen Erfahrungsbericht oder deine Hausarbeiten online zu stellen? Dann wäre es super, wenn du dich per E-Mail bei mir meldest.


Zusätzlich wird dich Folgendes interessieren:

✅ Weitere IU Hausarbeiten (Beispiele)

Meine Erfahrungen im IU Fernstudium


Hier bloggt Michael Schmid,

Michael Schmid von ich-mach-weiter.de - lachend

er ist glücklicher Familienvater, langjähriger Fernstudent und Blogger … weiterlesen

Um dich zu unterstützen, teilt er hier seine Erfahrungen mit dem wissenschaftlichen Arbeiten im Fernstudium. Durch sein Motto „ich mach weiter“, überzeugt er seine Leser vom lebenslangen Lernen und unterstützt Sie auf dieser Reise.

Folge und like ich-mach-weiter gerne auf LinkedIn.

Noch offene Fragen? Dann poste gerne einen Kommentar.

Schreibe einen Kommentar

Dieser Beitrag hat 18 Kommentare

  1. Daniel

    Hallo Michael,
    vielen Dank für den Einblick in deinen Projektbericht.
    Du hast in deinem Projektbericht z.B. angegeben…“das Projektbudget hingegen wurde um ca. 15% übertroffen, da die Kosten für Schulungen und den neuen Scrum Master höher als geplant ausgefallen sind“. Was ich generell noch nicht ganz an einem Projektbericht verstehe… Sind die ganzen Sachen, die mit der Geschäftsleitung vereinbart und abgesegnet wurden fiktiv ausgedacht (Budget)?

    Besten Dank für deine Antwort!
    VG Daniel

    1. Michael Schmid

      Servus Daniel,

      sehr gerne, besten Dank für deine Frage. Ja, den ganze Projektbericht habe ich mir „fiktiv“ ausgedacht, so wie es in der Aufgabe 2 beschrieben ist.

      In richtigen Leben bezieht sich ein Projektbericht natürlich auf Tatsachen anhand eines richtigen Projektes. 😉

      Liebe Grüße
      Michael

  2. Maria

    Hallo Michael,
    vielen Dank für die Veröffentlichung deines Berichts. Ich hatte Schwierigkeiten mir vorzustellen, wie ich die Aufgabenstellungen angreifen sollte, da diese doch recht lasch formuliert sind. Jetzt habe ich einen super Anhaltspunkt, weiter so!

    1. Michael Schmid

      Hallo Maria,

      herzlichen Dank für deinen Kommentar, ich freue mich immer über solch ein tolles Feedback. Vor allem, dass du dir mit Hilfe des Blogs dein Fernstudium ein wenig erleichtern konntest.

      LG und viel Erfolg bei der Ausarbeitung des Projektberichtes

      Michael

  3. Theresa

    Hallo Michael,
    dein Blog ist super, da die Ausführungen der IU hier und da etwas spartanisch gehalten sind.

    Meine Frage hast du das Modul Digital Skills auch bearbeiten müssen? Falls ja, gibt es da von dir auch eine so schöne Aufbereitung wie beim Modul Agiles Projektmanagement?
    LG Theresa und mach weiter so, deine Arbeit ist eine große Hilfestellung für alle Studierenden

    1. Michael Schmid

      Hallo Theresa,

      danke für dein Lob und die netten Worte. In meinem Studiengang steht das Modul Digital Skills nicht auf dem Programm. Daher kann ich dir in diesem Fall leider nicht weiterhelfen.

      Ich wünsche dir viel Erfolg beim Erstellen deiner Hausarbeit und liebe Grüße
      Michael

    2. Nadine Leesmeister

      Ich könnte dir bei digital skills evtl. helfen. hab dieses Modul bereits abgeschlossen.

      1. Michael Schmid

        Liebe Nadine,

        vielen Dank für deinen Kommentar und dem Angebot zum Modul „Digital Skills“.

        Weiterhin alles Gute und viele Grüße
        Michael

  4. Andy

    Hallo Michael,

    danke für deine rasche Antwort.
    Ich studiere derzeit B.A. Logistikmanagement und bin bisher mit dem Studiengang sehr zufrieden.
    Der Wechsel hätte noch den Vorteil, dass die meiste Modularprüfungen wie Personalmanagement, Recht und Wirtschaftsmathe(Einführung, Vertiefung) wegfallen.
    6 Semester stumpf Scripte auswendig lernen ist sehr monoton und anstrengend. Deswegen werde ich hochst wahrscheinlich die Opton wahrnehmen.

    Wann bist du eigentlich fertig mit deinem Studiengang? Strebst du noch einen Matser an?

    1. Michael

      Hallo Andy,

      immer wieder sehr gerne. Wenn dir der Wechsel einen Vorteil bringt warum nicht. 😉

      Bei mir zieht sich das Studium aus diversen Gründen etwas in die Länge, mal schauen wie lange es noch dauert… Ich priorisiere derzeit die Kinderbetreuung und bin dabei ab Juli ein Urlaubssemester zu beantragen.

      Einen Master plane ich nicht, hatte ich noch nie als Ziel vor Augen.

      LG
      Michael

  5. Andy

    Hi Michael,

    dein Blogg ist echt ein Segen. Ich habe schon sehr viele Informationen aus deinen ganzen Beiträgen entnehmen und einsetzten können.
    Eine Frage: So eine Projektarbeit/Fallstudie ist in der Regel nicht so umfangreich wie „Einführung in das wissenschaftliche Arbeiten“ oder? Das war echt schon ein hartes Stück Holz 😀

    Für meinen Studiengang gibt es aktuell eine Reakkreditierung (Curriculum) mit vielen neuen Modulen.
    Hier hat man mehr Projektarbeiten und Fallstudien die mich reizen würden als immer nur stumpfe Prüfungen zu schreiben (nur Auswendig lernen).

    Du hast oben geschrieben, dass du auch nicht soo der Klausurtyp bist und eher rechachierst und gerne Papier schwarz machst. Was sagst du, würde sich der „wechsel“ lohnen? Oder schieße ich mir damit ein eigen Tor.

    Danke dir

    1. Michael

      Servus Andy,

      herzlichen Dank für deine netten Worte. Sehr gerne versuche ich auf deine Frage einzugehen.

      Um ehrlich zu sein, war für mich der gesamte Aufwand (alle aufgewendeten Stunden) für den Projektbericht etwas mehr wie für das Workbook. Für eine Hausarbeit muss im Vergleich zum Workbook schon etwas tiefgreifender recherchiert werden, was eben auch viel Zeit in Anspruch nimmt. Workbook können hingegen meist auf Grundlage des Skriptes beantwortet werden.

      Ob nun Klausur oder Hausarbeit ist aus meiner Sicht vom persönichen Geschmack abhängig. Mir persönlich liegen Module wie z.B. BWL überhaut nicht, da es dort nur ums sture auswendig lernen von Definitionen geht. Wenn ich bei so einem Modul dann mal zwei Tage nicht lerne, mache ich gefühlt einen Rückschritt von 4 Tagen. Hausarbeiten haben hier aus meiner Erfahrung den Vorteil, dass diese leichter als Pausenfüller eingeschoben werden können. Somit etwas flexibler sind als das Lernen auf Klausuren.

      Ob sich nun der Wechsel für dich lohnt hängt ganz von deinem individuellen Lerntyp und deiner persönlichen Lebenssituation ab.

      Ich hoffe dass ich dir weiterhelfen konnte. Lass mich doch wissen, wie du dich entschieden hast. In welchem Studiengang bist du denn?

      LG
      Michael

  6. Samira

    Hallo Michael,

    vielen Dank für diesen Beitrag, er hilft definitiv als Anhaltspunkt für das Erstellen des Projektberichts.

    Kannst du sagen, wie du zum Projektthema gekommen bist? Ist es ein fiktives Projekt oder hast du wirklich schon die Möglichkeit gehabt, ein solches Projekt zu begleiten?

    Viele Grüße

    Samira

    1. Michael

      Hallo Samira,

      danke für deinen Kommentar, freut mich wenn ich dir mit diesem Beitrag helfen konnte.

      Diesen Projektbericht hatte ich anhand einem vorgegebenem Thema erstellt. Ist somit alles nur fiktiv.

      Wünsche dir alles Gute und frohe Ostern

      Liebe Grüße
      Michael

  7. Ariane Körtgen

    Hey Michael,

    ich bin soeben auch bei der Erstellung der Hausarbeit, kannst du mir vielleicht hierzu das pdf zukommen lassen, damit ich dich richtig zitieren kann.

    Vielen Dank für die Veröffentlich des Projektberichts, der hat mir wirklich sehr geholfen.

    Lg Ariane

    1. Michael

      Hallo Ariane,

      danke für dein Anfrage bezüglich meiner Hausarbeit. Leider kann ich dir den Projektbericht (aus diversen Gründen) nicht als PDF zukommen lassen.

      Weiter würde ich nicht aus anderen Hausarbeiten zitieren, da diese keine ausreichenden wissenschaftlichen Quellen darstellen. Ebenso solltest du nicht aus Lehrmaterialien der IUBH zitieren. Schaue dir dazu auch meinen Beitrag IUBH Hausarbeit erstellen – So schreibe ich in 10 Schritten meine IUBH Hausarbeiten! an.

      Schöne Grüße und viel Erfolg für deinen Projektbericht.

      Michael

  8. Jan

    Lieber Michael,

    vielen Dank für deinen ausführlichen Beitrag auf deiner Website zum Projektbericht und speziell im Modul Agiles Projektmanagement.
    Diese Auflistung hilft wirklich enorm, da die Infos im Kurs leider sehr kurz gehalten sind.
    Diese ganzen Informationen werden mir bei der Erstellung enorm weiterhelfen können!

    1. Michael

      Lieber Jan,

      es freut mich, dass ich Dir weiterhelfen konnte und wünsche Dir viel Erfolg bei der Erstellung Deines IUBH Projektberichtes.

      Lass mich doch bitte wissen, wie dein Ergebnis bewertet wurde.

      Herzliche Grüße
      Michael