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?
- Projekte in der Krise I – Warum Projektplanung wichtig ist
- Projekte in der Krise II – Über Testmanagement und Qualitätsansprüche
- Projekte in der Krise III – Die Krux mit der Entwicklungsmaschine
- Projekte in der Krise IV – Das Problem mit der Ausbaustufe
- Projekte in der Krise V – Übernahme von externen Fremdprojekten
- Projekte in der Krise VI – Übernahme von internen Fremdprojekten
- Projekt Kick-Off
- Projektabschluss