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?

Was ist Application Lifecycle Management (ALM)?

Application Lifecycle Management beschreibt einen ganzheitlichen Ansatz, der eine Anwendung während allen Phasen der Software begleitet. Er definiert Artefakte und Rollen und sorgt dafür, dass die einzelnen Schritte der Realisierung eingehalten und geprüft werden. Der Sinn von ALM liegt in einer Steigerung der Gesamtqualität der Software und der Zusammenarbeit mit dem Kunden, sowie in einer möglichst weitgehenden Standardisierung von Einzelschritten, dass Mitarbeiter der gleichen Rolle in verschiedenen. Der Gesamtprozess untergliedert sich dabei in verschiedene Phasen, die nachfolgend einzeln beschrieben werden.

Analyse- und Anforderungsphase

In diesem Schritt wird der konkrete Bedarf des Kunden ermittelt und in seinem betriebswirtschaftlichen Gesamtkontext bewertet. Ziel ist es die Bedürfnisse des Kunden so konkret wie möglich zu verstehen um in der nächsten Phase einen geeigneten Lösungsansatz dafür auszuwählen.

Typische Artefakte dieser Phase sind das Lasten- und Pflichtenheft, welche mit ersten Mockups und ersten Designentwürfen angereichert werden können. Auch Entwicklungs-, Design- und andere Richtlinien des Kunden sollten zu diesem Zeitpunkt durch den Kunden bekannt gemacht werden.

Beteiligte Personen in dieser Phase sind der Kunde und die Business Consultants. Weitere Personen wie Architekten und Designer können bei Bedarf unterstützen.

 Konzeptionsphase

Die Konzeptionsphase nutzt die Erkenntnisse aus der Anforderungsphase und wählt einen geeigneten Lösungsansatz für die Problemstellung aus. Während der Konzeptionsphase kann es immer wieder zu Rücksprüngen in die Analyse- und Anforderungsphase kommen, wenn Anforderungen nicht präzise genug waren oder neue Gesichtspunkte erneute Fragen aufstellen. Ziel dieser Phase ist es, einen Lösungsansatz zu wählen, der den Bedürfnissen des Kunden entspricht und auch robust genug ist, um künftige Änderungen und Weiterentwicklungen abzubilden.

Typischerweise werden während der Konzeptionsphase ein Grob- und ein Feinkonzept erstellt, welche um weitere Konzepte für Design, Software-Architektur, Release Management und Test Management ergänzt werden sollten.

Beteiligte Personen in der Konzeptionsphase sind Projektleiter, Software-Architekten, Qualitätsmanager und Designer. Business Consultants und ggf. die Kundenseite können bei Bedarf unterstützen.

 Realisierungsphase

Die Realisierungsphase umfasst die eigentliche Umsetzung einer Lösung und geht vom Aufsetzen der Entwicklungs- und Abnahmeumgebungen über die Entwicklung der Software und begleitenden Dokumente bis zur Installation der Lösungen in der Integrationsumgebung. Am Ende dieser Phase müssen die Anforderungen des Kunden durch das Umsetzungsteam vollständig implementiert, dokumentiert und getestet sein.

Artefakte dieser Phase sind die eigentliche Lösung, Deployment-Skripte, das Installations-, Administrations- und Benutzerhandbuch, sowie durch den Entwickler ausgeführte Testszenarien und Unit Tests.

In dieser Phase tragen Entwickler, Designer und Tester die Hauptlast der Arbeit. Ergänzt werden diese durch Projektleiter, Software-Architekten und Qualitätsmanager, welche die Ausführung überwachen und steuern.

 Qualitätssicherungsphase

Die Qualitätssicherungsphase beginnt mit dem Abschluss der Realisierung und dem Beginn des Abnahmeprozesses. Der Abnahmeprozess startet, wenn die Entwicklung der Software abgeschlossen und die Tests durch den Entwickler erfolgreich ausgeführt werden konnten. Der Test durch den Entwickler kann z.B. auf einer Entwicklungs- oder Integrationsumgebung ausgeführt worden sein.

Die Qualitätssicherungsphase selbst umfasst den Review aller erstellten Dokumente und Testfälle, sowie die Prüfung der Software anhand der Testfälle. Außerdem können hier weitere Mittel wie Exploratory Tests genutzt werden, um die Qualität weiter zu steigern. Werden Fehler gefunden, werden diese Dokumentiert und an das Realisierungsteam zurück gespiegelt. Diese haben dann in einer Nachbereitungsphase die Möglichkeit diese Fehler zu beseitigen. Fehler gelten wiederum als behoben, wenn Software, Dokumentation und Testfälle vollständig korrigiert wurden. Ist die Nacharbeit erfolgreich abgeschlossen erfolgt eine neue Prüfungsphase. Nacharbeit- und Prüfungsphase wechseln sich so lange ab, bis keine Fehler an dem Produkt mehr gefunden werden. Das Produkt kann dann an den Kunden zur Abnahme übergeben werden. Wenn dann keine Nacharbeit mehr anfällt, ist diese Phase abgeschlossen.

Ergebnis dieser Phase sind, dass das Produkt auf allen Abnahmeumgebungen (z.B. Integrationsumgebung und QA-Umgebung) erfolgreich getestet werden konnte. Dies wird üblicherweise in einem Abnahmedokument festgehalten. Weitere Artefakte können das Statusprotokoll der ausgeführten Tests oder auch ein Protokoll der Unit Tests sein.

Hauptverantwortlich in dieser Phase sind der Qualitätsmanager und die Tester. Weitere Aufgaben übernehmen der Ressourcen aus der Realisierungsphase. Die Abnahme am Ende der Qualitätssicherungsphase erfolgt durch den Kunden.

 Release- und Deployment-Phase

Die Release und Deployment Phase beschäftigt sich mit der Paketierung und Auslieferung der Software auf die Produktivumgebung. Hierfür sollte über ein Build-Werkzeug, wie zum Beispiel den Team Foundation Server (Visual Studio Online), nach einem standardisierten Vorgehen eine Release-Version des Produktes erzeugt und paketiert werden. Dieses Paket kann anschließend entweder vollautomatisiert oder administrativ über Deployment-Skripte auf dem Produktivsystem installiert werden. Sind beide Optionen nicht gangbar wird ein ausführliches Installationshandbuch benötigt, welches ebenfalls den ALM-Prozess durchlaufen muss.

Ein weiterer wichtiger Punkt dieser Phase ist die Versionierung der Software. Es muss sichergestellt werden, dass jede Version beim Kunden wartbar bleibt und auch zukünftige Bugfixes in eine alter Version übernommen werden können. Die Informationen dafür sollten aus dem Release Management Konzept kommen.

In dieser Phase findet beim Kunden auch die Schulung der künftigen Anwender des Produktes statt, sofern dies erforderlich ist. Die Schulungsunterlagen dafür sind entweder bereits in der Realisierungs- und Qualitätssicherungsphase entstanden, oder können während der Release-Phase erstellt werden. Wichtig ist, dass auch diese einen Review durch das Qualitätsteam erhalten. Die Schulung beim Kunden wird anschließend entweder durch einen Business Consultant oder den Kunden selbst vorgenommen.

Ziel der Release und Deployment Phase ist ein vollständiger Rollout der Installation mit optionaler Schulung der Anwender und Go Live der Anwendung. Ist diese Phase abgeschlossen kann das eigentliche initiale Umsetzungsprojekt als abgeschlossen betrachtet werden und das Produkt wird in den Managed Service überführt.

Hauptverantwortlich für diese Phase ist der Release Manager und das Operation-Team, der entweder vom Zulieferer oder dem Kunden selbst gestellt wird. Zuarbeiten können durch Business Consultants und den Kunden erfolgen.  

Wartungs- und Optimierungsphase

Diese Phase dauert in der Regel am längsten, auch wenn der Zulieferer hiervon meist nur wenig merkt. Das Produkt ist live geschaltet und die Anwender benutzen das Produkt in ihrem Arbeitsalltag. In der Regel betreut ein Support-Team das Produkt und löst die Probleme die nach der Entwicklung im Umgang mit dem Produkt entstehen. Diese können durch Fehlverhalten der Nutzer, eine fehlerhafte Konfiguration des Produktes oder echte Programmierfehler entstanden sein.

Während dieser Phase kann es durchaus vorkommen, dass weitere Versionen des Programms durch den ALM-Zyklus gebracht werden. Ziel in der Wartungs- und Optimierungsphase ist es, solche Änderungen als Updates einzuplanen und den reibungsfreien Betrieb sicherzustellen, sodass es auf den Arbeitsalltag möglichst geringe Auswirkungen hat.

Hauptverantwortlich für diese Phase sind das Operation-Team und gegebenenfalls die Mitglieder des Managed Service für dieses Produkt beim Zulieferer.