Projektplanung im E-Learning

Im klassischen Projektmanagement kennt man „Wasserfallmodell“ oder „Gantt-Charts“, seit wenigen Jahrzehnten darüber hinaus „lean management“ mit Kanban und anderen Projektmanagement-Tools und seit einigen Jahren den Hype um SCRUM. Welche Methode ist aber für E-Learning-Projekte am besten geeignet? Hierzu ein paar Gedanken am Beispiel der Produktion von E-Learning-Inhalten.

Als ich Projektmanagement studierte, ging es in erster Linie um altbewährte Modelle, die sich um das Dreieck von Qualität - Zeit - Budget drehten. Es geht hier um lineare Planung, oft mithilfe von Projektmanagement-Software wie der Office-Anwendung Microsoft Project, welche die zu diesem Projektmanagement-Ansatz gehörenden Gantt-Charts, Arbeitspakete und Meilensteine visualisierte und die Möglichkeit bietet, diese nachzuhalten. Für ein E-Learning-Projekt wurden entsprechend klare Ziele definiert, die zum Einsatz kommenden Tools und Ressourcen, Meilensteine vereinbart und schließlich ein klares Pflichtenheft erstellt. Das hat eigentlich in der Praxis sehr gut funktioniert! Mit schrittweiser Abnahme durch die Kunden von Grobkonzept, Feinkonzept, Templates und ersten grafischen Entwürfen gab es keine bösen Überraschungen und es konnte auch verhindert werden, dass in die falsche Richtung gearbeitet wurde. Das Budget des Kunden wird hier für ein eindeutig definiertes Ergebnis eingesetzt.

Lean Management & SCRUM im E-Learning

In letzter Zeit ist es aber „in“, einen „Lean Management“-Ansatz im Projektmanagement zu verfolgen. „Lean“ bedeutet schlank, es wird auf lange Beschreibungen und Zieldefinitionen im Anfangsstadium häufig verzichtet. Es entspricht der agilen Software-Entwicklung, die schneller auf Feedback reagieren können soll. Projektmanagementtools sind hier in erster Linie SCRUM und Kanban. Zu Kanban später mehr. SCRUM nutzt kurze „Sprints“, zwei Wochen, in denen das gesamte Team sich selbst organisiert, um ein bestimmtes Ergebnis abzuliefern. Dann wird geschaut, ob es das sein soll. Das Team trifft sich jeden einzelnen Morgen, um zu besprechen, was bislang gemacht wurde, welche Aufgaben erfüllt sind und wo es Probleme gab. Das wird auf einem SCRUM-Board festgehalten - meist in Form von Post-its, die je eine Aufgabe beschreiben und diese einer Person oder einem Sub-Team zuordnen.

In der Softwareentwicklung ist es bei dieser Herangehensweise so, dass das Budget den Ressourcen zugeordnet wird, nicht einem Ergebnis. Man geht davon aus, dass man nicht alle Eventualitäten vorhersehen könne, will aber gleichzeitig Kundenfeedback schneller in den Prozess mit einfließen lassen, um dann quasi auf dem Weg zum Ziel das richtige Produkt zu erarbeiten.

Nun ist es so, dass ich als E-Learning-Spezialistin bei bereits laufenden Projekten hinzu geholt worden bin, bei denen dieser Ansatz begonnen wurde und das Budget des Kunden bereits verbrannt war, ohne dass der Kunde ein Ergebnis hatte, wie er es sich vorgestellt hatte. Und ich erfahre immer häufiger, dass (in der Regel von Agenturen) direkt ein Drehbuch - oder gar das fertige Produkt im Autorentool - erstellt wird, ohne dass zuvor ein Feinkonzept mit dem Kunden abgestimmt worden ist. Dies entspricht der Idee des Lean Management. Und endete jedes Mal in erheblichem Mehraufwand zulasten des Kunden.

Gleichzeitig - trotz des Ziels verschlankter Prozesse - gab es Kosten für ein gesamtes Team, auch wenn eine Rolle ggf. in der Zeit weniger zu tun hatte sowie laufend den Überbau von „SCRUM-Master“ plus „Product Owner“. Manchmal wurde auch auf eine dieser Rollen auch verzichtet, was jedoch erst recht zu Chaos führte.

Kostenfallen im Lean Project Management

Was man außerdem wissen sollte: SCRUM ist eigentlich ein Framework, welche von Softwareentwicklern erfunden wurde, die keine neue Software entwickelten, sondern bestehende Software aktualisierten. Es sieht selbst keine klaren Ziele vor, erlaubt aber viel Eigenverantwortung der Team-Mitglieder. Dies wird dann ein Problem, wenn mehrere unerfahrene Mitarbeiter im Projekt mitarbeiten, wie es in Agenturen aus Kostengründen (bzw. Gewinnspanne) sehr häufig der Fall ist. Der Nachteil für den Kunden: Es gibt für junge, unerfahrene Mitarbeiter zwar weniger Stundenhonorar, aber dafür häuft sich die Masse der verbrannten Zeit aufgrund von Ungeübtheit, Fehler aufgrund mangelnder Erfahrung und darüber hinaus mangelnde Erfahrung im Umsetzen bzw. unstrukturiertem Arbeiten und vermeidbarem doppeltem Aufwand.

Doppelter Aufwand entsteht außerdem, wenn eben niemand die Aufgaben klar verteilt und im Blick hat, bzw. wenn unerfahrene Team-Mitglieder unter sich abmachen, wer was macht, wie beispielsweise, dass ein Grafiker entscheidet, dass es zu den Aufgaben des Drehbuchautoren gehört, vor der Umsetzung das Layout für jedes Slide vorzuarbeiten. Ein SCRUM Master sollte das zwar verhindern, sagt in einem solchen Modell dann aber, dass er ja nicht der Spezialist ist und dass er gerne Verantwortung abgibt, weil das die Philosophie agiler Entwicklung sei. Wer zahlt? Der Kunde.

Weitere Beispiele für Kostenfallen auf Seiten der eingesetzten „Fachkräfte“: Grafiker, die bislang für andere Medien gearbeitet haben und nun die falschen Tools und falschen Parameter nutzen. „Producer“ (das sind im Neudeutsch die, die das Autorentool zur Umsetzung benutzen, also manchmal auch die Autoren selbst), die die Programme nicht flüssig genug kennen und keine Erfahrung darin haben, welche verschiedenen Optionen sie im Autorentool für die Umsetzung haben.

Mein Verdacht ist, dass Unternehmen, die behaupten, dass der Einsatz von SCRUM alleine ihre Produktivität erhöht habe, darauf zurückzuführen ist, dass es vorher gar keine Kommunikations- und Produktions-Frameworks gab. So war SCRUM natürlich ein Fortschritt. Tägliche Meetings und Berichte sorgen auch für eine Art Überwachungskultur, zudem geht dieses Modell häufig mit Großraumbüros einher, in denen je ein Team sitzt und sich auch gegenseitig überwacht. Manche Mitarbeiter mögen dieses fortlaufende Feedback schätzen und die Abhängigkeit vom Team, aber andere eben auch nicht. Auch Sicht der Produktivität kann ich diesem Usus nicht zustimmen.

Kanban für E-Learning Prozesse

Eine spezielle Rolle im Lean Projektmanagement nimmt Kanban ein. Es wird häufig als Lean Project Management-Tool bezeichnet, ist es aber genau genommen gar nicht. Kanban ist ein Modell, um Prozesse zu optimieren und kann sowohl in klassisches Projektmanagement integriert werden, als auch in Lean Management. Kanban zeichnet Prozesse ab, was das A und O eines effizient arbeitenden Unternehmens ist. Es wurde für die Produktion erfunden (übrigens für die Automobilindustrie).

Heißt Klassisches und Wasserfall-Projektmanagement automatisch, dass es zu viel Überbau hat und unflexibel ist?

Meiner Ansicht nach keineswegs. Zwei Dinge sollte man wissen: Kritik an klassischem Projektmangement wurde in der Softwareentwicklung geübt, weil es durch lineare Abfolgen dazu kam, dass vom Kunden eigentlich nicht so gewünschte Ergebnisse oder nicht-funktionierende Anwendungen zu spät erkannt wurden. Das lässt sich natürlich vermeiden, indem man trotzdem frühzeitig und laufend Feedback einholt und eben im Sinne guten Projektmanagements laufend prüft, ob alles korrekt läuft und erste Ergebnisse funktionieren und dem Kunden zusagen, also den Vorstellungen bei der Projektvergabe entspricht.

Darüber hinaus kann man auch das Wasserfallmodell in mehreren Schleifen hintereinander nutzen, also ein sog. Sprialmodell einsetzen. Weitere Modelle sehen vor, Kanban für Teilschritte (Meilensteine) zu integrieren.

Die Entstehung von Netzdiagrammen

Es ist auch interessant zu wissen, wie das klassische Projektmanagement mit Netzdiagrammen entstanden ist: Es wurde zunächst in der Baubranche für komplexe Projekte eingesetzt und nennt sich eigentlich Netzplanung. Diese Netzplanung ist deutlich im Gantt-Chart durch die Abhängigkeiten dargestellt: es wird gezeigt, welche Aufgaben zuerst kommen müssen, bevor ein anderes Team-Mitglied (in unserem Falle) sinnvoll mit seiner Arbeit beginnen kann. Andere Rollen können dann wiederum bereits überflüssig geworden sein. Im Sinne eines Netzes, also echter Vernetztheit, zeigt ein Ganttchart aber vor allem auch Auswirkungen auf das ganze Projekt, sobald ein geplanter Schritt schneller oder langsamer fertig gestellt wird, als geplant. Außerdem werden hier Pufferzeiten eingeplant für Urlaube, Krankheitstage und eben unvorhersehbare Ereignisse und Bugs.

Diese Vernetztheit zu verstehen, ist das A und O und die Grundlage klassischen Projektmanagements, scheint aber vielen Projektmanagern völlig unbekannt zu sein, wenn man aus der praktischen Erfahrung schließt.

Mit der Klassischen Projektplanung wird jede unnütze Aufgaben, doppelte Arbeiten, unnötige Personentage etc. vermieden und es wird ganz genau getrackt, wie hoch der Aufwand ist und ob die Ziele wie mit dem Kunden vereinbart in dem vereinbarten Budget eingehalten werden können. Wenn nicht, kann frühzeitig eingegriffen werden. Das ist eigentlich gesunder Menschenverstand, aber trotzdem offenbar nicht selbstverständlich.

Ich habe es in Projekten, zu denen ich hinzugeholt wurde als das Kind bereits in den Brunnen gefallen war, erlebt, dass der Kunde einfach nur sprachlos und völlig vor den Kopf gestoßen vor Arbeitsergebnissen stand, die nicht seinen Vorgaben und Wünschen entsprachen, aber unfassbar viel Ressourcen verschlungen hatten. War es der Fehler des Kunden, nicht bereits bei der Abnahme des Feinkonzepts eingegriffen zu haben? Nein, denn dieses war in diesem Lean Umfeld nicht vorgesehen. Außerdem sollte der Kunde natürlich gar nicht eingreifen müssen, dafür bezahlt er in Agenturen den Projektmanager UND den Account Manager.

Bei anderen Projekten habe ich es erlebt, dass statt ein Drehbuch zu erstellen direkt mit dem Autorentool gearbeitet wurde. Anschließende Änderungswünsche des Kunden - auch simple Textänderungen, aber vor allem Änderungen bei den Visuals und vor allem Abläufen - sorgten für erheblichen Mehraufwand. Warum? Weil ein Drehbuch eben für schnelle Änderungen vorgesehen ist und vorher zeigt, was produziert werden soll, weil die anschließende Produktion nun einmal sehr viel zeitaufwändiger ist! Im Drehbuch werden Medien außerdem nur vorskizziert, parallel können Entwürfe für Templates und grafische Entwürfe dem Kunden zur Abnahme gezeigt werden, bevor diese in die Produktion gehen.

Das hört sich selbstverständlich an, ist es aber heute nicht mehr.

Mein Ratschlag:

Vertrauen Sie nicht jedem blind, der eine E-Learning-Software anwenden kann. Oder dies behauptet. Denn dies bedeutet noch lange nicht, dass diese effizient eingesetzt wird oder dass sie bestmöglich und flüssig genutzt wird. Tatsächlich habe ich es in mehreren Projekten mit Agenturen erlebt, dass die Software erst nach Auftragsvergabe erlernt wurde.

Lassen Sie sich vielmehr erläutern, wo die Kompetenzen liegen, welche nachweisliche(!) Erfahrung bei jedem einzelnen Team-Mitglied und insbesondere bei der Projektleitung vorhanden ist und nach welcher Methodik vorgegangen wird. Lassen Sie sich zusichern, dass die Personen, die Ihnen VOR Auftragsvergabe als Fachkräfte vorgeschlagen werden, das Projekt auch selbst umsetzen. Achten Sie darauf, dass Ihnen erläutert wird, in welchem Umfang Indiviualproduktionen möglich sind, d. h. auf welche Programmierkenntnisse können im Projekt zugegriffen werden und können die Screendesigner selbst neue Grafiken erstellen oder werden nur Assets (z. B. Bilder) fertig eingekauft? Ist für den visuellen Teil ein Medien-Programmierer oder doch nur ein Mediengestalter vorgesehen? Denn das ist ein himmelweiter Unterschied. Wie wirkt sich das auf die Kosten aus? Vereinbaren Sie klare, frühzeitige Meilensteine und feste Termine. Vereinbaren Sie außerdem vorher schriftlich, welchen Zusatzaufwand das Projekt auf keinen Fall überschreiten darf. Jeder Produktionsschritt sollte Ihrer schriftlichen Abnahme bedürfen, bevor weiter gemacht wird.

Überlegen Sie vor Auftragsvergabe gut, was Sie wirklich brauchen - an Kompetenzen, an multimedialen Inhalten, etc. - und lassen Sie sich die Gründe erläutern, wenn Ihnen ein Angebot besonders günstig oder besonders hochpreisig erscheint. Dies sollte jeweils klar nachvollziehbare, transparente Gründe haben. Lassen Sie sich im Zweifel in allen Punkten von einer dritten Person beraten, die das Angebot gut einschätzen kann.

Go to top