Projekte in der Krise IV

Wie ein Projekt seiner Ausbaustufe das Leben schwer machen kann

Puh. Es war ein harter Weg, doch das Projekt steht endlich. Wir befinden uns in der Abnahmephase. Einige kleinere Findings und Nice-To-Have-Wünsche hat der Kunde noch. Wir haben noch etwas Budget in unserem Projekt und diese letzten Aufgaben werden gerade realisiert. Der Business Consultant hat das Ohr direkt am Kunden und wir erfüllen diese neuen Anforderungen quasi in Realtime. Ein kurzes Meeting mit dem Kunden, eine Mail an den Entwickler und los. Der Kunde testet jede neue Funktionalität direkt am System. Damit das knappe Restbudget für die Extras noch reit, machen wir sie schnell direkt auf dem System, welches bald live gehen soll. Der Code wird dann anschließend gesammelt in das Quellcodeverwaltungssystem eingecheckt. Der letzte Code, der letzte Test, Booya!

Der GoLive verläuft weitgehend problemlos. Die Codes sind JavaScript und andere Frontend-Logik, die wir in das Produktivsystem eingespielt haben. Damit musste die Seite nun nur noch öffentlich bekannt gemacht und die Rechte für die Benutzergruppen gesetzt werden. Alles läuft weitgehend glatt. Kleinere Bugfixes im Livesystem werden ebenfalls zeitnah gefixt. Die Akzeptanz ist hoch, die Stimmung gut.

Die Zeit vergeht. Das System läuft stabil, die Endnutzer arbeiten damit und entwickeln neue Ideen für Verbesserungen und neue Use Cases. Da das System wichtig ist, hat das Steering Board die wichtigsten Vorschläge und neuen Anforderungen gesammelt und ein neues Paket geschnürt. Das Projekt geht in Phase II und aufgrund der guten Leistung sind auch wir wieder als Entwicklungs- und Consultingmannschaft mit dabei.

Leider ist das damalige Entwicklungsteam inzwischen in anderen Projekten eingesetzt und nur sporadisch erreichbar. Daher wird ein neues Team eingesetzt. Der Business Consultant und Projektleiter konnten glücklicherweise aus anderen Projekten abgezogen werden und somit stehen zumindest an der Kundenfront die gleichen Ansprechpartner. Ein mehr oder weniger typisches Setting für eine Folgebeauftragung also.

Die Phase II

Und so beginnt es von Neuem. Doch schon bei Beginn liegt Ärger in der Luft. Die Entwicklermannschaft hat sich in die Dokumente der Anforderungsphase eingearbeitet und auch die INT- und QA-Maschine angesehen. Irgendwie ist es passiert, dass in den Anforderungs- und CR-Dokumenten etwas anderes steht, als im INT-System umgesetzt wurde. Das QA-System scheint sich außerdem ebenfalls in einzelnen Aspekten vom INT-System zu unterscheiden. Zudem geistern immer wieder E-Mails von dem letzten Entwicklerteam durch den Raum, die noch etwas anderes verkünden.

Klar, es war ja etwas hektisch zu Projektende. Aber im Quellcodesystem sind ja die aktuellsten Sources hinterlegt. Dann erneuern wir INT- und QA-System eben. Und schon tauchen die nächsten Fragen auf. Scheinbar wurden die Codes ohne oder unzureichendem Kommentar eingecheckt. Auch lassen sich daraus keine Pakete mehr erkennen weil gleich mehrere Pakete auf einmal eingecheckt wurden. Also lassen sich daraus keine Rückschlüsse auf Änderungen und Bugs schließen und auch der aktuelle Stand lässt sich so nicht eindeutig ermitteln. Na schön. Also installieren wir alles und schauen es uns an.

Der Business Consultant drängelt inzwischen etwas, da er für die neuen Anforderungen gerne einige Konzeptpapiere erstellen würde. Doch dazu braucht er Daten aus dem Bestandssystem und auch einige Screenshots.

Und nun wieder das Entwicklerteam, denn es ist leider wurden auch noch einige Konfigurationen nicht aktualisiert und nun funktionieren einige Funktionen nicht. Schließlich muss ein Entwickler der letzten Phase aus einem anderen Projekt losgeeist werden, damit dieser die Konfigurationen einstellen kann.

All das verzögert leider auch unsere Phase II immer weiter und der Anfangs gute Eindruck des Kunden wird leider getrübt. Natürlich kann man die Aufwände durch entsprechende Mehrarbeit wieder hereinholen, doch nun müssen auch die Dokumentationen aus Phase I noch nachbereitet werden. Und da nicht mehr alle Anforderungen vorhanden sind und man sich dem Kunden gegenüber natürlich auch keine Blöße geben will, wird man nie völlig aus dieser Klemme herauskommen und immer wieder gezwungen sein Dinge nach zu dokumentieren und durch Mehraufwände auszugleichen.

Was kann man tun?

Die Lösung ist natürlich offensichtlich und greift die Prinzipien aus dem ersten Teil der Serie auf. Nicht nur ein Projektplan muss sauber erstellt werden, sondern auch alle Änderungen im späteren Prozess müssen nachgetragen und aktualisiert werden. Man sollte bei der Umsetzung eines Projektes immer auch den gesamten Application Lifecycle im Blick haben. Was passiert, wenn eine Phase II kommt, oder ich die Applikation ablösen und auf eine neue Plattform heben will? Wir profitieren selbst davon, dass wir sauber dokumentieren und auch neue Anforderungen nachhalten. Denn wenn man gute Arbeit geleistet hat, ist es sehr wahrscheinlich, dass ein Kunde auch für den Folgeauftrag wieder den gleichen Dienstleister auswählt, anstatt sich der Gefahr auszusetzen mit einem etwas günstigeren Anbieter neues Lehrgeld zahlen zu müssen. Im Idealfall wirkt sich saubere Arbeit also sogar auf den Tagessatz aus, da man einen guten Ruf durchaus auch mal etwas höhere Kosten ausgleichen kann.

Und im Detail?

Soweit die Theorie. Aber was kann man denn nun ganz konkret tun? Nun, ich empfehle das ALM-Tool Visual Studio Online (ehem. Team Foundation Server). Durch geringe Kosten, hohe Verfügbarkeit und gute Skalierbarkeit bietet dieses Tool nahezu für jede Anwendung optimale Voraussetzungen. Außerdem bietet es diverse Werkzeuge für das ALM-Management. Zum Beispiel bei der Erfassung von Requirements, Tasks, Bugs, Issues, Testcases und ähnlichem, oder bei der Planung von Teams, Sprints und Kanban Boards. Aber auch für die Abbildung großer Projekte mit unterschiedlichen Epics, Features und User Stories ist es gut geeignet. Außerdem kann man die erstellen Dokumente oder auch Quellcode direkt zu jedem dieser Elemente direkt referenzieren. Die Vorteile sind so vielseitig, dass es für eine eigene Serie reicht. Deshalb soll dies nur als Anregung gedacht sein, sich selbst zu informieren. Oder natürlich auf ebenjene Serie zu warten. 🙂

Mehr zum Thema?

Projekte in der Krise II

Über Testmanagement und Qualitätsansprüche

Nachdem ich im ersten Teil dieser Serie davon geschrieben habe, wie wichtig gute Projektinitialisierung ist kommen wir im zweiten Teil auf einen Dauerbrenner. Das Testmanagement. Ich möchte diesen Teil relativ früh in der Serie bringen, obwohl die Entscheidung dafür bei den Tests zu sparen oft sehr spät fällt. Wieso? Weil es einer der häufigsten Missstände ist und oft sowohl von den Lieferanten als auch den Kunden als der Punkt angesehen wird, bei dem man schnell mal 20 % Budget einsparen kann. Ein Trugschluss, wie sich oft zeigt.

Aber von Anfang. Das Projekt ist gestartet, die Voraussetzungen gut. Zwar sind die Anforderungen etwas nebulös, aber wir haben im Vertrag einen guten Grundstock gelegt. Konzeption, Realisierung, Test und Abnahme. Alle Phasen vorhanden und als Milestones definiert. Das Zeitfester ist gerade ausreichend. Die Mitarbeiter sind für Ihre Jobs qualifiziert und haben sich auf Ihre Aufgaben committed. Die Konzeption findet direkt mit dem Kunden statt und erstmals definiert der Kunde wirklich, was er sich unter den einzelnen Punkten vorstellt. Der Nebel verschwindet und Klarheit kehrt ein. Langsam wird klar, dass das Projekt an der ein oder anderen Stelle deutlich komplexer ist als angenommen. Zum Teil verstecken sich die entsprechenden Anmerkungen in Nebensätzen der Ausschreibung, zum Teil wurde einfach vergessen die entsprechenden Bereiche abzugrenzen. Der Kunde weigert sich mehr Budget bereitzustellen, da diese Anforderungen aus seiner Sicht Kern-Bestandteil der Anwendung sind. Was nun? Der Projektleiter möchte den Kunden nicht verärgern und dieser hat Jahresziele auf dieser Applikation und möchte bei seinem Vorstand nicht schlecht dastehen, indem er mehr Budget aushandelt. Man geht also gemeinsam durch das Konzept und identifiziert schließlich einen großen Block, der nicht wirklich etwas zum Projekt beiträgt. Das Testmanagement!

Natürlich fordert der Vorstand einen entsprechenden Bericht von dem Projekt. Schließlich ist das ja eine wichtige Vorgabe aus dem V-Modell! Da das Projekt natürlich agil läuft hat sich der Vorstand letzten Ends darauf eingelassen, dass ein einzelner Testbericht erstellt wird. Aber der muss dann umfänglich sein.

Die Projektsteuerung aus Kunde und Lieferant kommt auf eine einfache Lösung. Das Testmanagement in der geplanten, strukturierten Form mit Unit-Tests, Testfällen und eigenem Integrationstest wird gestrichen. Stattdessen sollen die Entwickler ihren Code testen und die Ergebnisse in einem Excel zusammenfassen. Am Ende wird so ein Testbericht entstehen, der alle Bereiche umfasst und somit klar den Anforderungen des Vorstandes entspricht. Ursprünglich waren 20% für Testmanagement eingeplant. Nun konnte es auf 5% reduziert werden. Die Ersparnisse werden ausreichen um das Projekt umzusetzen und sogar noch etwas Puffer überlassen um ein paar Bugs mehr zu beheben, die diesem Vorgehen geschuldet sind.

Das Projekt läuft gut an. Die Kollegen sind zufrieden die lästigen Tests los zu sein und arbeiten schnell und effektiv die Aufgaben ab. Als weiteren Einsparungseffekt hat man auf Sprintplanung und -abschluss verzichtet. Gelegentlich zeigt man dem Projektleiter und dem Kunden einen zwischenstand und diese wirken auch soweit zufrieden. Ab und zu treten Bugs während dieser Vorführung auf. Diese werden jedoch immer bis zur nächsten Vorstellung beseitigt.

Schließlich erreicht das Projekt einen Stand, in dem die ersten Testbenutzer des Kunden auf das System kommen. Und schnell stellt sich die Ernüchterung ein. Zwar funktionieren alle Module so, wie sie vom Entwickler entwickelt wurden, doch einige gingen einfach komplett an der Anforderung vorbei. Andere erfüllen zwar ihre Aufgabe, doch bei der ersten Fehleingabe entstehen völlig unnütze Daten oder das System katapultiert sich in einen undefinierten Zustand. Auch fachliche Defizite werden schnell wieder offenkundig, da der Projektleiter des Kunden zwar weiß worum es in der Anwendung ging, er selbst jedoch nicht aus der Fachabteilung kommt, sondern Teil der IT ist. Schnell werden Fragen laut. Warum wurde die Fachseite in die Erstellung der Tests nicht involviert? Wie wurde denn dies oder jenes überhaupt getestet? Natürlich wurde das neue Testvorgehen nicht schriftlich fixiert, da es ja unter dem Radar laufen sollte und nun passiert das, was zu erwarten war. Der Projektverantwortliche auf Kundenseite zieht seinen Kopf aus der Schlinge und beruft sich auf das Angebot. Dort steht ja ganz klar etwas von der Erstellung von Testfällen für die einzelnen Testschritte der Testphase.

Das Ganze eskaliert. Der Projektverantwortliche des Kunden wird abgezogen und ein Projektteam übernimmt die Fertigstellung. Es stellt sich heraus, dass das Projekt einige schwerwiegende Punkte falsch oder unzureichend implementiert hat. Die Fehlerrate ist überdurchschnittlich hoch und Testergebnisse sind nicht nachvollziehbar. Der Lieferant bangt um Folgeaufträge, da es sich um einen wichtigen Kunden handelt und verspricht die Missstände zu beseitigen. Es wird sich darauf verständigt die fehlenden Tests nicht mehr nachzuholen und die Bugs im Eskalationsmodus zu beheben. Ein Testteam des Kunden wird aus der Fachabteilung zusammengestellt und die Fehler gefunden und behoben. Das Budget war bereits vorher stark strapaziert und für Bugfixing bleiben lediglich 5 % über, die nun deutlich überschritten werden. Insgesamt belaufen sich die Mehraufwände auf weitere 15 % und das Projekt hat damit die Grenze der Wirtschaftlichkeit erreicht. Beide Parteien bringen das Projekt zu Ende. Die fertiggestellte Applikation ist lauffähig. Leider nicht so performant wie erhofft, denn dafür hat unter dem Strich die Zeit gefehlt. Änderungen sind teuer, da man sich immer durch den Code der Eskalationsphase quälen muss, welcher natürlich mit der heißen Nadel gestricht wurde. Durch das fehlen von Unit-Tests sind auch nachfolgende Änderungen nicht ohne Risiko und Fehler schleichen sich immer wieder ein, die auch die Wirtschaftlichkeit der Änderungen immer wieder gefährdet. Unter dem Strich kann dieses Projekt zwar als Erfolg, jedoch nicht als Glanztat gewertet werden und jeder Entwickler stöhnt leise auf, wenn wieder eine Änderung daran stattfinden soll oder ein Bug aus alter Zeit doch noch aufgrund von Gewährleistungsansprüchen gelöst werden muss.

Hätte all das verhindert werden können? Meiner Meinung nach ja. Und auch wenn in diesem Beispiel mehr Faktoren als nur das Testmanagement eine Rolle gespielt haben, ist es doch dieser Punkt auf den ich mich konzentrieren möchte. Weitere Faktoren waren sicherlich bereits im Angebot mit fehlenden Abgrenzungen und unzureichenden Fachkenntnissen, oder auch das knappe Budget der Kundenseite. Beides lässt sich nicht so einfach abstellen aber ich werde diese Themen in einem späteren Beitrag sicherlich noch einmal ausführlich behandeln.

Warum sollten wir Testmanagement betreiben? Ich denke, es wurde deutlich. Testmanagement umfasst viele verschiedene Aspekte mit dem gleichen Ziel. Die Anforderungen des Kunden möglichst scharf zu zeichnen, diese durch den Kunden abnehmen zu lassen und anschließend genau gegen diese Anforderungen zu entwickeln und das Ergebnis anhand dieser Anforderungen zu verifizieren. Wie kann das funktionieren? Nun, als erstes haben wir einen Wunsch von einem Kunden. Im Agilen Prozess nennen wir das einmal Feature. Jedes Feature besteht aus einer Anzahl an Anforderungen oder Use-Cases oder User-Stories, welche alle umgesetzt werden müssen, damit der Kunde das Feature benutzten kann. Beispielsweise könnte das Feature eine Kontaktverwaltung sein. Die einzelnen Use-Cases sind dann Anlegen, Löschen, Bearbeiten, Anzeigen, Exportieren etc. Jeder Use-Case hat dann noch Vorgaben. So genannte Abnahmekriterien. Abnahmekriterien für die Anlage können Pflichtfelder, Validierungen, Designvorgaben oder Ansprechzeiten sein.

481cd1a2-bf0c-4c03-a9e8-87d81bf15e91tests%20pro%20artefakt

Und genau dieser Struktur stellen wir nun unsere Tests gegenüber. Beispielsweise werden für die Akzeptanzkriterien entsprechende Unit-Tests erstellt. Für die Anlage der Pflichtfelder prüfen wir wie sich das Feld verhält, wenn es ausgefüllt wurde, wenn es nicht ausgefüllt wurde und wenn in ein Zahlenfeld Text eingetragen wird. Entsprechen alle Testergebnisse unseren Erwartungen, können wir davon ausgehen, dass das Akzeptanzkriterium damit erfüllt ist.

Nun schreiben wir noch einen Oberflächen-Test für den Endnutzer. Dort sollten wir die Akzeptanzkriterien berücksichtigen. Also etwa lege einen Eintrag an. Prüfe dabei ob die Pflichtfelder richtig dargestellt werden. Prüfe ob die Validierungen greifen, prüfe ob die Designvorgaben stimmen. Prüfe ob die Reaktionszeit im gewünschten Bereich liegt. All das kann in einem oder in mehreren Testfällen geschrieben werden. Da dieses Beispiel tatsächlich alles die Anlage behandelt würde ich alles zusammen in einen Test schreiben. Würde es Anlegen und Löschen behandeln wären es 2, usw.

Als letztes machen wir unseren Integrationstest und prüfen damit, ob unser neu erstelltes Feature auch zu den restlichen Komponenten passt. Das kann bspw. dann interessant werden, wenn der Kontakt als Referenz zu einem Kunden dient oder für Veranstaltungen. Wir führen also alle Tests unserer Use Cases nun gemeinsam auf der Integrationsumgebung aus.

All diese Arbeit erfüllt 4 Ziele. Erstens, durch die Untergliederung der Features bis hinunter zu Akzeptanzkriterien haben wir eine Anforderungsebene erreicht, auf der sich auch der Entwickler wohl fühlt und genau weiß was er machen muss, damit das Feature umgesetzt werden kann.

Zweitens, der Kunde versteht bei dieser Untergliederung den Zusammenhang zwischen seinem Feature und den Akzeptanzkriterien des Entwicklers und kann anhand dieser Abstufung verstehen was er da genau vor sich stehen hat und auch was er von der fertigen Anwendung erwarten kann.

Drittens, durch dieses Verständnis kann der Kunde die Akzeptanzkriterien freigeben, bevor die eigentliche Entwicklung startet. Damit haben wir die Sicherheit, dass wir die Anforderung richtig verstanden haben und wir haben eine konkrete Liste bei der wir sagen „Lieber Kunde, das waren die konkreten Anforderungen, die wir umgesetzt haben. Nichts links, nichts rechts davon. Wenn jetzt etwas fehlt ist das ein Change.“ Das gibt uns Planungssicherheit.

Und schließlich viertens, durch die Erstellung, Ausführung und Protokollierung der Tests erhalten wir die Sicherheit, dass die Anwendung tut was sie soll und der Kunde erhält die Sicherheit, dass wir auch alle Akzeptanzkriterien und damit schlussendlich das Feature vollständig umgesetzt haben.

Und somit erreichen wir unser eigentliches Ziel. Wir setzen genau das um, was der Kunde fordert und zwar so, wie es besprochen war. Die Missverständlichen Features wurden in einfach verständliche Akzeptanzkriterien heruntergebrochen. Natürlich macht das alles Mehraufwände. Doch wir sparen am Ende die Zeit bei der Fehlerbehebung und der Nacharbeit wegen falschen oder fehlenden Schritten wieder ein. Leider ist Testmanagement immer eine Gefühlssache, da man natürlich nicht messen kann, wie viel Zeit man dadurch gespart oder mehr verbraucht hat. Währen die guten Ergebnisse mit Testmanagement auch ohne erreichbar gewesen? Ich sage, vielleicht. Aber nur dann, wenn es sich um einen stark standardisierten Prozess handelt und jeder beteiligte über großes Fachwissen verfügt. Für einen Dienstleister im Projektgeschäft halte ich es für nicht realistisch und dementsprechend das Testmanagement für unabdingbar.

Mehr zum Thema?

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?

​ Projekte in der Krise I ​

Warum Projektplanung wichtig ist.

Das Projektgeschäft ist bekanntermaßen ziemlich tückisch. Oft gibt es Probleme, die man erst im Nachhinein erkennt und selten nimmt sich jemand die Zeit die Probleme aus der Vergangenheit wirklich zu reflektieren und auszuwerten. Das führt dazu, dass einige Projektleiter mit großer Erfahrung ein Projekt zum Erfolg führen können. Hauptsächlich dann, wenn genügend Probleme der aus vorhergehenden Projekten bereits bekannt sind und man weiß wie man damit umgeht. Kommen zu viele unbekannte Probleme oder ist der Projektleiter nicht erfahren in dieser Materie, wird irgendwann der kritische Punkt überschritten, bei dem das Projektteam die Fehler nicht mehr ausgleichen oder korrigieren kann. In diesem Fall wird das Projekt dann ein Desaster.

Viele Firmen, die ich kennen gelernt habe sind der Meinung, dass sie mit Projekten umgehen können. Eben weil sie ausreichend Projekte absolviert haben, bei denen das Ergebnis letzten Ends den Erwartungen des Kunden entsprochen hat – oder zumindest die Mindestanforderungen erfüllt hat. Am Ende zählt nur noch das Ergebnis und der Weg dorthin verschwindet oft im Gedächtnis des Einzelnen. Selten wird das Projekt noch einmal reflektiert oder gar Erkenntnisse schriftlich festgehalten.

Aus diesem Grund möchte ich in dieser Beitragsserie mal über meine persönlichen Erfahrungen der größten Projektfehler berichten und mögliche Gegenmaßnahmen zeigen. Leider sind das alles keine magischen Werkzeuge, die alles einfach machen, sondern nur Strukturen und Prozesse, die Initial erst einmal wieder Mehraufwände verursachen, bevor sie ihre Magie wirken können. Ein gewisses Maß an Vertrauen und auch Durchsetzungsvermögen gegenüber den Projektbeteiligten ist also durchaus notwendig.

Keine ausreichende Planung zu Beginn eines Projektes

Tatsächlich ist die mangelnde Planung am Anfang oft schon der Grundstein für das Fiasko. Dabei waren die Absichten gut. Der Kunde hat Zeitdruck, es geht nur um einen sehr überschaubaren Projektrahmen oder der Entwickler hat ohnehin schon signalisiert, dass er genau weiß was zu tun ist oder man möchte man Zeit aufholen. Es gibt diverse Gründe dafür den Projektstart ad hoc durchzuführen und einfach mal loszulegen. Oft ist die Ursache auch nicht bei einem einzelnen Grund zu suchen, sondern ergibt sich aus einer Summe verschiedener Teile.

Und dann passiert es. Zum Beispiel hat sich der entscheidende Entwickler krank gemeldet. Der Zeitplan ist aufgrund von Fehlern im Projekt nun unhaltbar geworden und es ist viel zu spät aufgefallen um noch Gegenmaßnahmen zu ergreifen. Der überschaubare Projektrahmen wurde durch diverse kleinere Änderungen aufgebläht, ohne das es aufgefallen ist. Die Architektur hat sich durch diese kleineren Änderungen nun doch entscheidend geändert.

Das Ergebnis ist oftmals verheerend. Der mangelnde Pflegeaufwand am Anfang zieht sich dann meistens wie ein roter Faden durch das Projekt. Änderungswünsche werden nicht dokumentiert, Probleme nicht an den Kunden kommuniziert und der Druck auf die Projektmitarbeiter wird immer größer. Da nicht klar ist, welche Anforderung wann und wie rein kam, wird einfach gemacht was der Kunde sagt. Man weiß nicht mehr, wie genau er seine Anfrage gestellt hat und irgendwann ist das Geld alle und das Produkt noch nicht fertig. Beide Parteien streiten sich um das Produkt und am Ende wird das Projekt entweder eingestampft oder unter enormen Kosten zu Ende geführt. Niemand ist glücklich und voraussichtlich war es das letzte Projekt in dieser Konstellation.

So könnte zumindest der Extremfall aussehen. Normalerweise ist es so, dass die Mitarbeiter des Zulieferers mit Überstunden, Vermutungen und einer gewissen Bugtoleranz doch noch das Ziel erreichen. Der Kunde ist zwar nicht glücklich, doch die Fehler werden mit dem nächsten und übernächsten Release gefixt und das Projekt unter „Erfahrung“ verbucht. Leider wieder ohne Retrospektive.

Dieses Beispiel zeigt wie leicht aus gutem Willen am Anfang und der Idee die eigene Agilität zu demonstrieren ein Desaster werden kann. Doch was hilf dagegen? Natürlich, Struktur. Sonst hätte ich den Beitrag ja nicht so eingeleitet. Aus meiner Sicht gibt es einige Grundsätzliche Dinge, die beim Projektstart auf jeden Fall erledigt werden müssen. In welcher Ausbaustufe das ganze Stattfindet, hängt dabei vom jeweiligen Projektumfang ab und einige Sachen können auch zunächst grob Skizziert und später ausdefiniert werden. Aber zumindest die Grundstrukturen sollten da sein.

Ein Projektplan auf Basis der Schätzung

Für das Projekt wurde initial irgendetwas geschätzt. Sonst hätte man den Auftrag ja nicht bekommen. Das sind die Zahlen, die für einen ersten Projektplan als Grundgerüst dienen. Welche Pakete wurden vereinbart, welche Zahlen stehen in PT für welche Rolle daran. Gibt es Abgabetermine und wer kann die Rollen besetzen. Je detaillierter dieser Projektplan definiert werden kann, umso besser sind die Ergebnisse später messbar. Doch es reicht am Anfang auch ein grobes Gerüst als Richtschnur. So sehen wir zumindest, wenn etwas völlig aus dem Ruder läuft und wir gegensteuern oder den Kunden informieren müssen.

Personalplanung auf Basis des Projektplans

Damit die richtigen Leute für mein Projekt zur Verfügung stehen muss ich diese auch einplanen. Je früher und weitreichender ich diese Planung durchführen kann, desto höher ist die Chance, dass meine Leute auch verfügbar sind. Damit ich nicht rate, wann ich welche Leute benötige, sollte der Projekt- und Meilensteinplan vorher zumindest in einem ersten Stand sein. Somit weiß ich, dass ich nach Meilenstein M1 die Person XY benötige, da sie eine Kernkompetenz für die Erbringung von M2 hat. Natürlich kann ich noch nicht auf den Tag genau sagen welche Personen ich von Anfang bis Ende benötige. Aber über den Projektplan bekomme ich eine Vorstellung und kann die Leute in dem betreffenden Zeitraum zumindest schon einmal vorplanen. Mit jedem Statusmeeting und jedem erfolgreichen Modul, dass abgeschlossen wurde, kann ich den Projektplan nachschärfen und auch die Personalplanung optimieren. Somit wird nicht nur für mich, sondern auch meine Leute der eigentliche Termin immer greifbarer und andere Projekte können sich nach dieser Planung immer besser richten.

Klärung der Abnahmekriterien der ersten Meilensteine / Sprints etc.

Bis zum nächsten Meilenstein, besonders am Anfang, gibt es oft sehr viel zu tun. Auch Dinge, die eigentlich nichts mit meiner Zielerreichung zu tun haben, sondern bereits vorgeplant werden für spätere Schritte. Damit man das eigentliche Ziel des aktuellen Meilensteins nicht aus den Augen verliert und sich in Details verstrickt, sollte für jeden Meilenstein klare Abnahmekriterien definiert sein. Was muss erreicht werden, damit der Kunde glücklich ist? In Scrum würden diese Aspekte einen möglichst hohen Wert in Story Points bekommen und somit zeitnah erledigt werden. Während die Arbeiten für später oder die weniger relevanten Nebentätigkeiten entsprechend herunter priorisiert werden. Dies hilft jedem einen klaren Blick auf das Ziel zu behalten und dem Projektleiter die Erreichbarkeit des Ziels und den aktuellen Status leichter zu messen.

Definition und Beschaffung der benötigten Arbeitsmaterialien

Es hört sich total trivial an, doch oftmals ist genau hier der Knackpunkt von vielen Projekten. Spätestens beim Projekt-Kick-Off muss klar sein, welche Arbeitsmaterialien benötigt werden, wer diese beschafft und wann die Arbeitsfähigkeit hergestellt ist. Erst dann – und wirklich erst dann – lohnt es sich mit einem Team in das Projekt einzusteigen. Bis zu diesem Zeitpunkt sollten lediglich die Experten für die Arbeitsmaterialien arbeiten und alle anderen Personen in anderen Aufgaben aktiv sein. Zu diesen Arbeitsmaterialien gehören in unserer Welt VSTS (TFS)-Projekt, Entwicklungsmaschinen, Zugriffe auf Kundensysteme, vollständige Anforderungen (zumindest für die ersten 2 Sprints), Ansprechpartner, Architekturkonzepte, Testkonzepte und ähnliches. So lange diese Bausteine nicht verfügbar sind und problemlos ihre Aufgabe erfüllen ist jede Art von operativer Hektik kontraproduktiv und wird letzten Ends die Qualität des Projektes untergraben und einem später wieder auf die Füße fallen.

Klärung der Aufgabenbereiche und Rollen

Auch das klingt einfach. Ein Entwickler soll natürlich den Code schreiben! Dafür haben ihr ihn ja dazu genommen! Ja, schon. Aber was denn noch? Ist er für das Aufsetzen der Entwicklungsmaschine zuständig? Ist der Architekt für Kundenkommunikation zuständig? Ist der Qualitätsmanager für die Erstellung der Testfälle zuständig? Für jeden Mitarbeiter sollte es ein gezieltes Onboarding in das Projekt geben. Wenn dies nicht möglich ist, sollte das Onboarding zumindest zentral in einem Projekt-Kick-Off stattfinden. Am Ende muss sich der Mitarbeiter genau auf diese Rollenbeschreibungen verlassen können und sich auch direkt darauf committen. Denn nur so ist sichergestellt, dass er eine implizite Andeutung nicht überhört hat. Gerade bei den oben genannten Beispielen ist dies nicht zwangsläufig so und der Kollege fühlt sich vielleicht gar nicht zuständig, obwohl der Projektleiter es eigentlich genau so gemeint hat. Deshalb lieber einmal zu viel sagen, was der Kollege machen soll und ihn das auch noch einmal in eigenen Worten wiederholen lassen, damit alle auf den selben Stand sind. Besonders bei langen Projekten bietet sich außerdem an, diese Aufgaben noch einmal schriftlich zu fixieren, damit sie nicht in Vergessenheit geraten. In Scrum könnte man diese dann zum Teil der Retrospektive machen. Waren wirklich alle Teammitglieder in Ihrer Rolle aktiv? Sind sie gut damit klar gekommen, oder bestehen irgendwo Lücken, die es zu schließen gilt?

Mehr zum Thema?

Komponenten-, Integrations-, System- und Abnahmetests

Ein kleiner Exkurs. Diesmal zu Testverfahren. Ich war gerade im Gespräch mit einem Kollegen über verschiedene Testverfahren. Dabei kam die Frage auf, wie man verschiedene Testfälle angehen kann. Hier nun also das Resultat.

Komponententest

Klassische Unit-Tests. Im Minimalmodell müssen hier vor allem die Schnittstellen zwischen den Systemen abgetestet werden. Die meisten Qualitätsverfahren gehen davon aus, dass die meisten Fehler genau an den Schnittstellen passieren, da der Entwickler sein eigenes Modul gut kennt und die Fehler ehr durch unerwartete Parameter entstehen können.

Im Fall von O365 ist JavaScript wahrscheinlich die häufigste Oberfläche. Daher würde ich die Unit-Tests auch auf dieser Ebene ansiedeln und jede Kommunikation zwischen der Oberfläche und dem Backend abtesten. So wissen wir, welche Funktionen wir aufrufen und bei welchen Parametern wir welche Ergebnisse erwarten. Genau diese würde ich hier testen. So kann man bei jedem Aufruf einmal den Positivfall und die eingebauten Fehlerfälle abtesten.

Ein Beispiel:
GetYearOfDate(„2007-12-12“) assert „2007“
GetYearOfDate(„2. Feb. 2017“) assert „2017“
GetYearOfDate(„30.02.2002“) assert InvalidDateException

Integrationstest

Integrationstests sind Testfälle die zu Testszenarien verbunden sind. Ich habe das zum Beispiel immer gemacht, indem ich mir eine UserStory/UseCase/Requirement des Kunden geschnappt habe. Das war mein Testszenario. Dann habe ich für jedes von mir identifizierte Akzeptanzkriterium einen Testfall geschrieben um es abzuprüfen.

Diese würde ich üblicherweise im VSO Test Manager schreiben. Der Vorteil ist, dass wir diese Testfälle über unseren SSO-Login und den Web-Client auch bei Kunden in ihrem eigenen System nutzen können. Für ausgeführte Testfälle erhalten wir dann nämlich auch ein sehr detailliertes Testprotokoll.

Idealerweise werden Integrationstests auf einer expliziten Testumgebung (der INT-Stage) ausgeführt. Diese Testfälle sind bei mir immer durch einen Tester auf Entwicklerseite ausgeführt worden. Nicht jedoch durch den Entwickler, der das Modul geschrieben hat. Gerne aber durch einen anderen Entwickler, der daran nicht beteiligt war.

Ein Beispiel:

Anforderung:
Ein Nutzer möchte eine Übersicht aller seiner aktiven Projekte aus der Projektliste auf der Startseite.

Implizite Akzeptanztests (zur Abnahme beim Kunden):

  • Es muss möglich sein, dass auf der Startseite ein Anzeigemodul (z.B. Webpart) platziert wird, dass eine Liste von Projekten anzeigen kann
  • Die Liste auf einen speziellen Nutzer gefiltert werden
  • Projekte anderer Nutzer sollen nicht angezeigt werden
  • Es sollen nur aktive Projekte aus der Liste ermittelt werden.
  • Inaktive oder beendete Projekte sollen nicht angezeigt werden.

In diesem Fall schreiben wir ein Testszenario „Aktuelle Projektübersicht eines Nutzers“ und haben darin 5 Testfälle, die jeweils ein Akzeptanzkriterium enthalten.

Systemtest

Der Systemtest ist die Gesamtheit aller Testszenarien die hier im Zusammenspiel getestet werden. Es sollte also eine Testumgebung geben (normalerweise der QA-Stage), auf der kurz vor der Abnahme einmal alle Komponenten installiert werden. Hier testet ein Test-Team, welches wieder vom Entwicklungsteam gestellt werden kann.

Bei mir war es oft so, dass zu diesem Zeitpunkt bereits einige Key-User auf der Plattform unterwegs waren und über Exploratory Testing – also freies Testen nach Gefühl – unterstützt haben, um somit Fehler zu finden, die mehr Fachwissen benötigen.

Auch gibt es als Output ein Testprotokoll.

Abnahmetest

Dieser kann als einziger Test nicht durch den Zulieferer erfolgen. Er wird auch User Acceptance Test (UAT) genannt und lässt die späteren Nutzer – oder eine Teilmenge davon – auf die Umgebung. Im Idealfall kann dieser Test bereits auf der späteren Produktivumgebung stattfinden, damit sichergestellt ist, dass alles richtig eingerichtet wurde. Sollte dies nicht möglich sein, findet der Test auf der QA-Umgebung statt, welche per Definition identisch mit der Produktivumgebung ist.

Zusammenfassung

Komponententest dienen der Abprüfung der Applikationsschnittstellen über Unit-Tests um die Konsistenz der Applikation zu gewährleisten. Liefergegenstand ist das Protokoll der Unit-Tests.

Die Integrationstests entsprechen dem Schreiben von Testszenarien anhand der Requirements und von Testfällen anhand abgenommener Akzeptanzkriterien. Ausführung erfolgt bei Fertigstellung einzelner Module auf der Integrationsumgebung. Liefergegenstand ist das Testprotokoll der Integrationsumgebung.

Als Systemtest versteht man die Ausführung aller Testszenarien der Integrationstests. Ausführung erfolgt auf der QA-Umgebung bei Abschluss der Implementierungsphase. Liefergegenstand ist das Testprotokoll der QA-Umgebung.

Und der Abnahmetests beschreibt die Ausführung aller Testszenarien oder eigener Tests auf der QA- oder Produktivumgebung durch die Fachabteilung. Wir sind hier lediglich beratend tätig und halten Ressourcen für die Fehlerbehebung bereit.

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.