fme AG (en)
fme SRL
fme Indien (en)
fme US
Mit diesem Blogpost ist unsere Reise auch schon wieder vorbei. Doch eine Aufgabe bleibt noch: ein Rückblick. Was haben wir gelernt? Was nehmen wir mit? Was hat gut funktioniert und wo können wir uns vielleicht nächstes Mal noch verbessern? Diese Fragen gilt es in einem Lessons Learned zu beantworten.
Der eine oder andere Beteiligte ist nach Abschluss oft geneigt, dem Projekt den Rücken zuzuwenden und direkt zum nächsten Projekt über zu gehen. Dabei sind die Informationen aus einem Lessons Learned unerlässlich für den zukünftigen Projekterfolg. Denn nur zu gern sind einstige Fehler und Fettnäpfchen schnell vergessen und verdrängt, um sich dann beim nächsten Mal mit einem dumpfen Gefühl von „War das nicht letztes Mal auch schon so?“ zu wiederholen. Dabei lassen sich gut dokumentierte Herausforderungen leicht im Vorhinein umgehen.
Lessons Learned leicht gemacht
Wie so oft führen auch beim Lessons Learned viele Wege zum Erfolg. Beim Scrum nennt es sich „Retrospektive“ oder in PRINCE2 „Review“ als Teil des Project Closure. In Details unterscheiden sich diese Formate, aber letzten Endes geht es immer darum, einen Lernprozess abzuleiten, um sich stetig weiterzuentwickeln. Wichtig ist aber auch der Zeitpunkt: Es mag verlockend klingen, sich erst am Ende eines Projektes damit zu beschäftigen. Viel besser ist es jedoch in regelmäßigen Abständen, beispielsweise bei definierten Meilensteinen, auch eine solche Bestandsaufnahme anzusetzen. Nur so wird auch dokumentiert, was noch frisch im Gedächtnis ist.
Je nach Projekt- und Teamgröße sollten dafür mindestens ein bis zwei Stunden eingeplant werden. Am besten sind dazu alle Projektbeteiligten, also auch der Auftraggeber und ggf. externe Mitarbeiter, dabei. So lässt sich eine einseitige Sichtweise vermeiden. Unter Umständen lohnt es sich vorab, Themen bei den Teilnehmern abzufragen, um daraufhin die Agenda entsprechend zu erstellen.
Eine beliebte Methode zur Abfrage von Themen im Workshop ist „Keep-Stop-Start“: Womit sollten wir weitermachen wie bisher? Womit sollten wir aufhören? Womit sollten wir anfangen? Am besten machen sich die Teilnehmer zunächst allein Gedanken und notieren diese, um auch alle einzubeziehen. Wenn sehr viele Themen genannt werden, macht es Sinn, diese in einem Zwischenschritt zunächst zu priorisieren. Aus den Ergebnissen wiederum werden Maßnahmen und Verantwortlichkeiten abgeleitet. Im Anschluss an den Workshop werden die Ergebnisse dokumentiert und allen Projektbeteiligten zugänglich gemacht. Im laufenden Projekt empfiehlt es sich, auch die Erinnerung an die Ergebnisse in Folgeworkshops aufzufrischen und zu ergänzen. Soweit zur Theorie, doch was haben wir konkret aus unserem Projekt mitgenommen?
Und was haben wir gelernt?
- Weniger ist oft mehr… den Minimum Viable Product (MVP) Ansatz haben wir im > letzten Beitrag schon beschrieben. Aber die Frage, was wirklich essenziell ist und damit Teil des MVP werden soll, ist oft nicht einfach zu beantworten. Wir haben unseren Scope einige Male weiter eingeschränkt, bis er wirklich dem MVP entsprach. Und das Ergebnis wird intern bei der fme gut angenommen. Es muss also nicht gleich beim ersten Aufschlag alles zu 100 % passen.
- Eine große Erkenntnis hatten wir vor allem im Teilprojekt DMS: Die Anforderungen aus der letzten großen Systemumstellung und den entsprechenden Veränderungen in der Zwischenzeit reichen heute nicht mehr aus! Benutzer erwarten von neuen (und modernen) Lösungen mehr als von Legacy Applikationen. Wir sind seitdem als Unternehmen stark gewachsen. Es kann und muss deshalb viel mehr automatisiert im System geregelt werden. Zum Glück gibt es bei uns im Unternehmen neben den „das war doch schon immer so“-Stimmen auch die „wenn wir es jetzt neu machen, dann bitte richtig“-Stimmen. Manche Dinge müssen also einfach angegangen werden.
- Große Projekte erfordern einen hohen Zeitaufwand der Hauptakteure. Das macht man nicht „mal eben“ und nebenbei – wie gerne vom Management postuliert. Selbst dann nicht, wenn es sich um das eigene Kerngeschäft handelt, solche Projekte durchzuführen sowie ausreichend Erfahrungen vorhanden sind. Gerade deshalb wissen wir ja, wie wichtig es ist, hier sorgfältig und mit Bedacht zu agieren. Neben dem Projektteam selbst, sollte aber auch genügend Zeit der anderen Stakeholder eingeplant werden: in unserem Fall z. Bsp. die Finanzabteilung, die aufgrund gesetzlicher Vorgaben besondere Anforderungen im Bereich Dokumentenmanagement hat.
- Kommunikation war, ist und wird immer der wesentliche Kern eines solchen Projekts sein. Hier umso mehr, da so ziemlich jeder Mitarbeiter des Unternehmens betroffen war. Leider konnten wir hier nicht so viel Aufwand reinstecken, wie wir gerne gewollt hätten. Aber schon eine regelmäßige Information über den Status Quo und kurze Anleitungen zur Einführung machen einen großen Unterschied und können viel bei der Akzeptanz der Anwender bewirken.
Folgen Sie einfach unseren Social Media Accounts um auf dem Laufenden zu bleiben.
0 Kommentare