Projektabschluss

Der Projektabschluss ist wohl die Projektphase, die am häufigsten ignoriert, oder nur halbherzig durchgeführt wird. Die Projektmitglieder sind in der Regel bereits für neue Themen eingespannt. Der Projektleiter ist froh, dass alles in Time und in Budget funktioniert hat, oder er möchte das Projekt lieber schnell vergessen, da es total schief gelaufen ist und das Projekt ein Fehlschlag war.

Dazu kommt noch, dass ein sauberer Projektabschluss in der Regel nicht durch den Kunden bezahlt wird, der das Projekt in Auftrag gegeben hat. Auch seine Leute sind bereits wieder neu eingespannt und er hat nur wenig Interesse daran, die Strukturen des Auftragnehmers zu stärken und zu verbessern.

Warum also sollte man dennoch auf einem Projektabschluss bestehen? Und was umfasst dieser Abschluss eigentlich alles? Genau darum soll es im folgenden gehen.

Was sind die Pflichtaufgaben beim Projektabschluss?

Damit wir überhaupt vom gleichen reden können, möchte ich hier die aus meiner Sicht wichtigsten Faktoren eines Projektabschlusses benennen. Natürlich müssten wir dafür erst einmal definieren, wo der Projektabschluss beginnt. Das Ganze ist ein fließender Prozess. Es gibt optionale und nicht optionale Bestandteile. Ich würde gerne an dem Punkt beginnen, an dem das erstellte Stück Software den Go-Live absolviert hat. Hier kann man guten Gewissens vom Ende des Projektes reden. Eventuell gibt es noch einen Wartungsvertrag für das Produkt, doch dies ist dann nicht länger Teil eines Projektes, sondern ein neuer Abschnitt des Produktes.

Nun sollten beide Seiten, Auftraggeber und Auftragnehmer, noch einmal überprüfen ob auch alle Abnahmegegenstände geliefert wurden.

  • Gibt es alle verlangten Dokumentationen?
  • Sind die Testfälle alle sauber abgeschlossen?
  • Liegt der Testbericht beiden Seiten vor?
  • Gab es eine Quellcode-Überlassung, die nun noch durchgeführt werden muss?
  • Oder wurde der Code beim Kunden entwickelt und muss nun noch in die eigenen Systeme zurück gespiegelt werden?
  • Sind alle Aufwände im Buchungssystem erfasst?
  • Wurden diese auch in Rechnung gestellt?

All diese Fragen sind nicht optional und sollten definitiv bei jedem Projektabschluss gestellt werden. Nur so sind tatsächlich auch alle Bedingungen für eine saubere Projektübergabe sichergestellt.

Wie kann man seine Erfahrungen für die Unternehmen nutzbar machen?

Über diese Pflichtaufgaben gibt es noch die Kür. Der Prozess, der für beide Seiten einen Mehrwert in der Methodik schaffen kann. Es gibt de Facto kein Projekt, dass absolut glatt läuft. Immer gibt es kleinere und größere Fehler, Missverständnisse und Kompromisse. Diese Erfahrungswerte befinden sich nun in den Köpfen der Projektmitarbeiter auf beiden Seiten. Sie sind noch frisch und man hat genau in Erinnerung was man auf keinen Fall wieder tun würde, oder wo es zumindest Verbesserungsbedarf gibt. Die Dinge, die man nie wieder tun würde, vergisst man natürlich nicht. Aber was ist mit den Kleinigkeiten, über die man vielleicht sogar schon mehrfach gestolpert ist, dann aber wieder vergessen hat? Und wie können die Kollegen im Unternehmen auf beiden Seiten von diesen Erfahrungen profitieren? Genau darum geht es bei der zweiten Phase des Projektabschlusses. Folgende Punkte sollte man dabei berücksichtigen und einsetzen, wenn diese sinnvoll erscheinen.

  • Eine offene Projekt-Retropektive, bei der Kunde, das Projektteam und der Kundenvertreter (Sales) gemeinsam darüber reden, was in dem Projekt gut und was nicht so gut gemacht wurde.
  • Blick nach vorne. Wie fügt sich das Projekt in die Landschaft des Kunden ein. Es gibt eventuell weitere Punkte, an denen der Kunde noch Bedarf sieht.
  • Daraus folgend ein Lessons Learned, bei dem die wichtigsten Erkenntnisse erfasst werden. Sowohl im Positiven, als auch im Negativen.
  • Einzelgespräche mit den Projektmitarbeitern, bei dem man die konkreten Stärken und Schwächen des Einzelnen anspricht und Verbesserungspotenziale sichtbar macht (Die Protokolle können auch für die Personalentwicklung interessant sein)
  • Prüfung, ob aus dem erfolgreichen Projekt eine Case Study gemacht werden kann. Eventuell erklärt sich der Projektverantwortliche des Kunden auch dazu bereit seinen Fall und das Projekt in einem Vortrag zu erläutern.
  • Man sollte prüfen, ob Module, Dokumente oder andere Ergebnisse künftig auch für andere Projekte genutzt werden können. Das kann als Codeschnipsel sein, als Dokumentenvorlage, als Template oder ähnliches. Hier sollte man allerdings auch prüfen, ob der Aufwand den Nutzen rechtfertigt.

All diese Punkte bieten für das abgeschlossene Projekt keinen Mehrwert mehr. Doch für die Organisation als Ganzes und auch die Bindung zum Kunden können diese sehr nützlich sein. Denn dies ist noch einmal die Gelegenheit dem Kunden zu zeigen, dass man sein Projekthandwerk versteht und wirklich daran interessiert ist die aufgetretenen Fehler nicht erneut zu begehen. Im Idealfall ergibt sich aus dem Gespräch mit dem Kunden und dem Blick nach vorne auch die Möglichkeit neue Felder zu erschließen und eventuell lassen sich daraus – und mit dem guten Gefühl, dass der Kunde durch so ein Gespräch erhält – neue Projekte, die man im Idealfall sogar mit dem bereits eingespielten Projektteam bestreiten kann um somit möglichst viele Synergien nutzen zu können.

Selbst wenn dies nicht der Fall ist, eine ausführliche Nachbereitung des Projektes dauert meist nur sehr kurz, vor allem wenn die agilen Mechanismen und Scrum sauber genutzt wurden und dadurch ohnehin bereits regelmäßig Verbesserungen erfolgt sind. Der Nutzen diese Verbesserungen nun festzuhalten dient allen in der Firma und sollte möglichst weitgehend genutzt werden um ein Verständnis dafür zu schaffen und die Leute zu sensibilisieren.

Ein Sprichwort sagt, dass die Erfahrung die Summe der Fehler ist, die ein Mensch gemacht hat. Wenn diese Erfahrung nun dazu genutzt wird auch bei anderen Kollegen ein Wissen aufzubauen, ohne die Fehler machen zu müssen, dann ist dies ein Prozess der positiven Verstärkung und der eigentliche Vorteil, den eine starke projektorientierte Firma gegenüber einem Freelancer auszeichnen kann.

Mehr zum Thema?

End of Life – Eine Applikation wird abgelöst

Es gibt weitere Phasen im Leben einer Applikation, welche von dem aktuellen Entwurf von Application Lifecycle Management nicht beachtet werden, da es für das eigentliche Produkt nicht relevant ist. Dennoch sollten sie in einem ganzheitlichen Ansatz beachtet werden. Es geht um die Stilllegung der Applikation. Jede Applikation wird früher oder später abgeschaltet werden. Sei es, weil sich die Anforderungen des Kunden verändert haben, oder weil das zugrundeliegende Framework nicht mehr gewartet wird. Als Berater sollten wir auch diese Phase im Auge behalten, da sie auch vom Kunden oft übersehen wird und dennoch einen enormen Mehrwert bieten kann.

Natürlich könnten wir jetzt sagen, was haben wir damit zu tun? Wenn die Applikation nicht mehr gepflegt werden kann, dann haben wir auch keinen Auftrag mehr. So zuletzt oft gesehen mit IBM und Lotus Notes. Die bestehende Software wird abgeschaltet und durch eine komplett neue Technologie mit neuen Beratungsunternehmen ausgetauscht. Doch das muss ja nicht sein. Was wäre zum Beispiel, wenn wir eine Farmsolution aus SharePoint 2010 künftig in die O365-Cloud transferieren sollen? Und zwar nicht einfach 1:1, sondern angepasst auf den aktuellen Stand der Technik. Mit neuen Sozialen Features und Gruppenräumen? Nun, in diesem Fall wäre es sicherlich gut, wenn wir möglichst einfach die Geschäftsdaten transferieren könnten.

Auf die Einstellung kommt es an!

Oftmals wird ein Migrationsprojekt verharmlost und nur selten dem ALM-Prozessen unterworfen. Schließlich handelt es ich ja nur um eine Einmalaktion und muss nicht ständig gewartet und verbessert werden. Es handelt sich also um ein schnelles Projekt ohne besondere Herausforderungen an die Qualität und Wartbarkeit. In der Regel ist das Gegenteil der Fall! Eine Migration sieht sich mit Daten aus dem kompletten Lebenszyklus der Applikation konfrontiert. Je nachdem wie gut die Applikation gewartet wurde, kann es also durchaus Daten geben, die nur zu einem bestimmten Zeitpunkt gültig waren und nun gar nicht mehr in die aktuelle Informationsarchitektur passen, oder neu aufbereitet werden müssen. Dem Projektteam sollte dieser Umstand klar sein und im Idealfall sollten möglichst viele Beteiligte des Lebenszyklus der Applikation konsultiert werden um auf derartige Fallen vorbereitet zu sein. Natürlich ist auch an dieser Stelle eine saubere Dokumentation Gold wert, da viele Dokumente erst zu diesem späten Stadium wieder wirklich relevant werden und bis zu diesem Zeitpunkt scheinbar viel unnütze Arbeit in diese Strukturen gesteckt wurde.

 Vorarbeiten im ALM-Prozess

Damit es möglich ist, eine Applikation möglichst problemlos abzuschalten, muss die Gesamt- und insbesondere die Informationsarchitektur der Lösung gut durchdacht und – auch hier wieder – dokumentiert werden. Dies ist besonders wichtig, da die Verantwortlichen der Lösung mit einer gewissen Wahrscheinlichkeit bei Abschaltung nicht mehr bei der Firma oder für diese Applikation arbeiten und Ihr Wissen nach dem Abschluss des Projektes wahrscheinlich auch nicht mehr weitergegeben wurde. Aus diesem Grund ist es essentiell Dokumente zu haben, woraus ersichtlich wird, wie die Daten in Verbindung stehen, wo sie abgelegt sind und wie diese möglichst einfach herausgezogen werden können.

Im Idealfall gibt es bereits Schnittstellen um diese Daten abzugreifen, oder sie werden im Rahmen der Applikationsentwicklung eingerichtet. Solche Schnittstellen sind nicht nur für das Ende der Applikation hilfreich, sondern helfen auch dabei das Programm in die Systemlandschaft zu integrieren und Informationen auch in anderen Applikationen zu verwenden. SharePoint bietet dieses Schnittstellen bereits Out-Of-The-Box. Wichtig ist nur, dass auch die neu hinzugefügten Applikationen und ihre Datenhaltung diese Schnittstellen nutzen können, oder neue Schnittstellen implementiert und dokumentiert werden.

Die Transfervorbereitung

In der Transferphase geht es hauptsächlich um einen Aspekt, der dieser auch den Namen geben. Wie bekomme ich die bestehenden Geschäftsdaten am besten aus meiner Alt-Applikation um die Applikation verlustfrei abschalten zu können?

Hier kommen meist Third Party Migrationstools zum Einsatz, welche die Daten aus einer Applikation heraus holen und in eine andere hinein schieben können. Der Architekt der Alt-Applikation sollte wie oben erwähnt bereits in der Konzeptionsphase des ALM darauf zu achten, dass dieser Weg möglichst einfach ist. Für SharePoint gibt es bereits gute Migrationstools. Im Idealfall setzt auch die Applikation auf dem SharePoint Standard auf, oder stellt wie oben erwähnt bereits geeignete Schnittstellen für die Datenmigration bereit.

Ziel ist es demnach, dass in der Transferphase alle Vorbereitungen getroffen werden, um die Daten aus dem Altsystem in das neue System überführen zu können. Zu den Liefergegenständen dieser Phase gehören Vorgehensbeschreibungen, Migrationsskripte und -tools und Rollback-Szenarien. Beteiligt sind an dieser Phase meistens das alte und das neue Operations-Team, sowie die alte und neue Wartungsmannschaft der Zulieferer. Im Idealfall sind auch die Architekten beider Lösungen noch greifbar. Erforderlich sind meist auch der Architekt und die Entwicklungsmannschaft der neuen Lösung. Diese Phase sollte wie aus dem ALM gewohnt auch den Dokumentations- und Qualitätsrichtlinien entsprechen. 

Die Stilllegung und das neue Go Live

Die Stilllegungsphase ist der kritische Teil einer Migration. Hier wird das alte System ab- und das neue System live geschaltet. Wie genau findet dieser Prozess nun statt und wie kommen die Daten nun wirklich in das System?

Wichtig ist zu beachten, dass die meisten Applikationen eine gewisse Kritikalität für den Kunden haben und daher die Übergangsphase möglichst reibungslos ablaufen muss. Dafür gibt es zwei Ansätze. Der erste ist die Abschaltung des Altsystems, der Transfer der Daten und die Anschaltung des neuen Systems. Meistens ist jedoch die Transferzeit zu lang, sodass es eine Zeitspanne gibt, in der ein Parallelbetrieb beider Applikationen stattfindet. In diesem Fall gibt es meist auch nicht nur einen einzelnen Datentransfer, sondern die Daten werden mehrfach vom Altsystem in das Neusystem repliziert. Dabei muss besonders darauf geachtet werden, dass es zu jedem Zeitpunkt nur einen Single Point of Truth gibt – also neue Daten immer nur in einem System erfasst werden können. Dies sorgt dafür, dass es später nicht zu unvorhersehbaren Zuständen kommt und die einen Nutzer bereits Informationen im Neusystem, andere im Altsystem für die gleichen Datensätze erfassen.

Die Migration findet nun nach den vorher definierten Prozessen statt. Obwohl dieser Teil sehr wichtig für den Erfolg ist, gibt es dazu wenig zu erklären. Sämtliche Prozesse wurden im Vorfeld bereits definiert und werden nun abgehandelt. Da Migrationen so gut wie nie komplett glatt laufen, sollten in dieser Phase nach Möglichkeit alle Beteiligten der Transferphase greifbar sein um somit möglichst agil auf neue Anforderungen reagieren zu können. Wichtig ist nur, dass alle aufgetretenen Probleme und spontanen Änderungen ebenfalls sauber dokumentiert und festgehalten werden, sodass die Migrationsprozesse sauber nachvollzogen werden können.

Am Ende der Phase gibt es zwei mögliche Zustände. Entweder die  Migration ist erfolgreich durchgelaufen und es gibt nun ein neues System. In diesem Fall greift wieder der normale ALM Prozess und das Team der neuen Applikation kann in die Betriebs- und Optimierungsphase übergehen. Ist die Migration fehlgeschlagen, muss das Rollback-Szenario ausgeführt werden, sodass das Altsystem weiterhin das führende System ist. In diesem Fall muss erneut in die Transferphase übergegangen werden und die aufgetretenen Fehler müssen analysiert, dokumentiert und beseitigt werden.