Projekt Kick-Off

Was ein Kick-Off Meeting erreichen sollte

Eine Frage aus dem Daily Business. Was muss ein Kick-Off Meeting erreichen? Oder besser gefragt, was kann ein Kick-Off Meeting erreichen? Meine Meinung dazu.

Ich weiß, dass PRINCE2 normalerweise keine Kick-Off Veranstaltung kennt. Dennoch sehe ich es als eine essentielle und notwendige Veranstaltung. Vor allem dann, wenn das Projektteam nicht in der immer gleichen Aufteilung unterwegs ist. Kann man also darauf verzichten, wenn man Beispielsweise ein Scrum-Team hat und dieses Team dann immer wieder in der gleichen Rollenverteilung auf neue Projekte losgelassen wird? Selbst da würde ich ungern darauf verzichten. Denn dieses Meeting bietet allen Projektbeteiligten die Möglichkeit sich gegeneinander kennen zu lernen und einen ersten Eindruck zu gewinnen. Außerdem wird in diesem Meeting das Verständnis der einzelnen Aufgaben, die fachlichen Hintergründe, die Personen und Rollen geschaffen. Sowohl für das Projektteam, als auch den Auftraggeber.

Somit ist aus meiner Sicht das Kick-Off lebensnotwendig für einen Projekterfolg. Und zwar nicht als Monolog des Projektleiters, sondern als kollegialer und positiver Austausch, bei dem der Projektleiter der Moderator ist. Ein Kick-Off sollte meiner Meinung nach folgende Ziele haben:

Das Projektziel sollte klar kommuniziert sein.
„Am Tag X müssen wir Y fertig haben, damit der Kunde damit Z erreicht. Der Milestone A ist dabei von essentieller Wichtigkeit, da er die Kernkomponente darstellt.“ Das Projektziel und die Gründe des Kunden für dieses Ziel schaffen ein Verständnis für das Projekt und jeder Einzelne kann dann beurteilen, an welcher Stelle eventuell etwas zurückgestellt werden kann, um am Tag X die notwendigen Komponenten bereit zu haben. Nacharbeiten sind normal, dürfen aber nicht das Ziel des Kunden behindern. Und im Notfall muss man ein Provisorium einrichten, um dem Kunden das Ziel zu ermöglichen. Wobei hier Vorsicht geboten ist, denn nichts hält länger als ein Provisorium!

Klare Definition der Verantwortlichkeiten der einzelnen Projektmitglieder
Welche Aufgaben hat jemand zu erfüllen und welche nicht? Im Gespräch mit verschiedenen Beteiligten eines bestimmten Projektes ist mir hier ein Paradebeispiel aufgefallen. In diesem Projekt gab es einen Beteiligten. Er wurde vom Projektleiter als Softwarearchitekt gesehen. Dies wurde aber scheinbar nicht offen genug kommuniziert, oder die damit verbundenen Verantwortlichkeiten waren nicht klar. Denn der Betroffene selbst hat sich als technischer Ansprechpartner für den Kunden und Vermittler zu den Entwicklern wahrgenommen. Davon, dass er für die Konzeption der Architektur und deren Überprüfen verantwortlich war, wusste er jedenfalls nichts. Derartige Unklarheiten müssen direkt im Kick-Off beseitigt werden, indem sich jeder Projektmitarbeiter in eigenen Worten auf sein Ziel und seine Aufgaben commited. Dies sollte für spätere Nachvollziehbarkeit oder Projektmitglieder, die später in das Projekt kommen, auch schriftlich fixiert werden.

Konkrete Vermittlung der Milestones, der Aufgaben und der Definition of Done
Wann muss welches Ziel erreicht werden? Welche Aufgaben müssen dafür realisiert werden und wann können sie als erledigt betrachtet werden? Und auch, wer wird wann welche Aufgabe angehen und voraussichtlich abschließen können? Wo ist der kritische Pfad der Applikation und wie können wir ggf. Ausfallsicherheit für einzelne Personen schaffen? Oder haben wir eine Möglichkeit den kritischen Pfad mit einer zusätzlichen Person zu entlasten? Wenn diese Themen klar und transparent sind, ist es dem Team möglich ein Gesamtverständnis zu erhalten und bei Bedarf den Kollegen hilfreich beiseite zu stehen.

Welche Methoden nutzen wir technologisch und organisatorisch. 
Darüber habe ich bereits an anderen Stellen viel gesprochen und möchte hier nicht detailliert auf die Methoden eingehen, da es ansonsten den Rahmen sprengen würde. Als Keywords seien Scrum vs. V-Modell, Unit-Tests & User Acceptance Tests, Azure DevOps und Continues Integration genannt.

Welche Schwierigkeiten gibt es noch?
Commitment auf die Probleme, einen Verantwortlichen und mögliche Lösungsansätze. Alles was zu dem Kick-Off noch nicht klar ist oder Probleme die noch nicht behoben sind, müssen in einer Liste erfasst und mit einem Verantwortlichen versehen werden. Auch ein Termin für die Bearbeitung ist notwendig.

Das sind aus meiner Sicht die wichtigsten Erkenntnisse eines Projekt-Kick-Offs. Das Kick-Off sollte übrigens auch mit dem Kunden stattfinden, sodass er weiß was getan wird und sich abgeholt fühlt. Ich bin ein Freund der offenen Kommunikation mit dem Kunden. Schließlich sitzt auf der anderen Seite auch nur ein Mensch und wir sollten mit ihm arbeiten, statt gegen ihn. Wenn es Probleme gibt, kommunizieren wir sie. Dann hat der Kunde die Möglichkeit darauf zu reagieren. Schlimmer wird es, wenn er davon überrascht wird oder anfangen wird Dinge zu faken. Holt den Kunden mit ins Boot und lasst ihn die Entscheidungen mittragen. Das nimmt den Druck aus der Sache und eventuell hat auch der Kunde noch eine Idee zur Lösung.

Mehr zum Thema?

Rollen und Verantwortung

Bei einer Ausschreibung bin ich über 2 Begriffe gestoßen, die ich selbst so nie unterschieden habe, bei denen es mir jedoch jetzt sinnvoll erscheint. Es geht um die Rollen Software-Architect und Software-Engineer. Hättet ihr gewusst, wo die Unterscheidung liegt? Nun, über diese und weitere Rollen möchte ich in diesem Beitrag berichten und versuchen ein einheitliches Verständnis zu schaffen. Zumal diese Begriffe nie wirklich vereinheitlicht wurden. Diese Liste erhebt jedoch keinen Anspruch auf Vollständigkeit und natürlich können mehrere Rollen auch von einer Person ausgeübt werden.

Projektleiter
Er ist die Person, die ein Projekt zusammen hält und den Überblick hat. Er arbeitet am besten, wenn er wie ein Fluglotse agieren kann. Selbst ist er an der Umsetzung nicht beteiligt, sondern ist derjenige, der alle Informationen über Das Projekt hat. Er kennt den großen Status des Projektes, weiß welche Pakete aktuell umgesetzt werden, welche abgeschlossen sind und wo es Probleme gibt. Außerdem benennt er die Verantwortlichkeiten im Projekt und sorgt dafür, dass die Leute auch entsprechend handeln und handeln können. Er berichtet in regelmäßigen Abständen an den Kunden und das Projekt-Controlling.

Teil-Projektleiter
In besonders großen und interdisziplinären Projekten, kann es sein das ein z.B. technischer und ein fachlicher Projektleiter den Hauptprojektleiter unterstützen. Sie nehmen die gleichen Funktionen der Koordinierung wahr und berichten an den Projektleiter. Alle interdisziplinären Entscheidungen und sehr wichtige Teilprojektentscheidungen werden durch oder in Absprache mit dem den Hauptprojektleiter getroffen.

(Software-)Architekt
Der Architekt ist derjenige, der für die gesamte Lösung das große Bild erstellt. Er entscheidet welche Technologien und Applikationen verwendet werden. Soll der SharePoint mit dem SQL reden? Dann ist das eine Architekturentscheidung. Auch ob eine Farm-Solution oder CSOM eingesetzt wird obliegt ihm. Ferner bestimmt er zusammen mit dem Projektleiter die Entwicklungsmethodik. Arbeit nach Scrum oder V-Modell zum Beispiel. Er berichtet an den (Teil-)Projektleiter. Ihm unterstellt sind die Ingenieure aller Disziplinen.

Qualitätsmanager
Bei dem Qualitätsmanager handelt es sich um eine interdisziplinäre Rolle. Ähnlich wie beim Projektleiter handelt er am besten, wenn er nicht direkt in das Projekt eingebunden wurde, sondern als Stabsstelle des Projektleiters fungiert. Er prüft die Arbeitsergebnisse aller Disziplinen und gibt wenn notwendig Verbesserungsvorschläge oder verweist auf Standards. In seiner Verantwortung liegt, dass das Projekt sauber abgewickelt wird. Wenn Kompromisse im Projekt eingegangen werden, überwacht er, dass diese sauber dokumentiert und wenn notwendig durch den Kunden zur Kenntnis genommen oder abgesegnet werden. Er berichtet an den Projektleiter und wenn notwendig an das Projekt-Controlling.

(Software-, Test-) Ingenieur
Der Ingenieur ist für die konkrete Umsetzung verantwortlich und überwacht diese. Während der Architekt die Entwicklungsmethodik und Technologie vorgegeben hat, kümmert sich der Ingenieur um die konkreten Schnittstellen und die Einhaltung der Richtlinien. Er ist quasi der Erste der Entwickler und sorgt auch dafür das die einzelnen Module und Pakete reibungslos miteinander laufen.

Neben dem Softwareingenieur gibt es hier auch den Testingenieur. Seine Aufgaben gleichen sich in einer anderen Fachrichtung. Er überwacht die Erstellung und Ausführung der Tests und prüft dabei immer wieder, ob die Qualitätsrichtlinien auch sauber umgesetzt wurden.

(UX-, Software-, Test-) Designer
Der Designer ist dafür verantwortlich, dass das Frontend ansprechend und den Anforderungen gemäß umgesetzt wird. Während der Softwaredesigner sich um das Design der Oberflächen kümmert, kümmert sich der UX-Designer darum, dass der User ein möglichst leicht zu bedienendes Produkt erhält und die Klickpfade kurz und verständlich bleiben. Beide sind in der Regel dem Softwareingenieur unterstellt.

Der Testdesigner erstellt die Testszenarien für die Anforderungen und sorgt dafür, dass alle Akzeptanzkriterien abgehandelt werden. Er ist dem Testingenieur unterstellt.

(Software-) Entwickler
Der Entwickler ist für die Realisierung der Anforderungen zuständig. Er berichtet im Rahmen der Projektmeetings an die Vorgesetzten und ist für seine Arbeitspakete und deren Qualität verantwortlich. Er ist der einzige, der einem Produkt wirklich etwas hinzufügt.

Tester
Der Tester nutzt die Arbeitspakete des Testdesigners und führt diese aus. Er dokumentiert Widersprüche zwischen Software und Tests und teilt diese in den Projektmeetings mit. Seine Arbeitsresultate sind notwendig um die einzelnen Testphasen abzuschließen. Der Tester kann sowohl durch den Lieferanten als auch durch den Kunden oder auch gemischt besetzt werden.

Consultant
Der Consultant ist der Berater des Kunden. Er nimmt die Anforderungen auf und bringt sie in eine standardisierte Form, sodass diese durch die Softwareentwicklung in ein konkretes Arbeitspaket interpretiert und umgesetzt werden kann. Er nimmt auch Änderungswünsche auf und kommuniziert diese in beide Richtungen.

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.

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.