Projektsteckbrief

Oft wird man gefragt, ob man nicht mal schnell dies oder das übernehmen kann. Oder – im Falle eines Managers – ob man nicht jemanden für dies oder jenes parat hat. Ruck-Zuck entsteht ein Hin- und hergeschreibe, bei dem die Details geklärt werden und es geht schnell mal eine halbe Stunde oder mehr ins Land, bevor überhaupt das wesentliche geklärt ist. Klar, man könnte einfach den Höhrer in die Hand nehmen und anrufen. Aber in der Regel wird geschrieben.

Damit solche Eskapaden reduziert werden, habe ich ein Tool übernommen, was mein alter Chef gerne eingesetzt hat. Wobei Tool schon zuviel gesagt ist. Ein kleiner Steckbrief für Projekte, damit man schnell eine Übersicht bekommt.

Der Steckbrief

Projektname: (Gib dem Kind einen Namen. Im Idealfall ist die Projektablage auch unter dem Namen zu finden)

Projektbeschreibung: (Beschreibe das Thema und mit 2-3 Sätzen.)

Projektleiter: (Wer ist bei uns Hauptverantwortlicher?)

Kunde: (Wer will dieses Projekt. Im Idealfall Kunde und Abteilung)

Ansprechpartner: (Wer ist beim Kunden verantwortlich)

Aufwand: (Wie groß wird das Ganze voraussichtlich. Eine Range reicht auch aus [z.B. 50-100 PT])

Benötigte Rollen: (Entwicklung, Testmanagement, Architektur, Infrastruktur, Suche, UI, UX …)

Technologien und Fähigkeien: (SharePoint 2007, O365, Clientside Development, Serverside Development, AnguarJS, Taxonomy Termstores, Projektmanagement etc…)

Diese Fragen sind aus meiner Sicht schnell beantwortet und geben einen guten ersten Eindruck von einem Projekt. Außerdem können Sie für ein Projektstammblatt verwendet werden und machen Themen vergleichbar.

Projekte in der Krise III

Die Krux mit der Entwicklungsmaschine

Und wieder kommt ein neuer Stolperstein in das Projekt. Dieses mal handelt es sich gar nicht um die Projektmethodik selbst, sondern um ein viel banaleres und dennoch genauso ärgerliches Thema. Wir haben die Planung sauber durchgeführt, auch das Kick-Off war gut und jeder weiß was zu tun ist. Wir haben Qualitätsprozesse etabliert und sind nun bereit endlich den ersten Code zu schreiben! Wir gehen also zu unserem Entwicklungsteam und sagen, dass sie starten können. Und nun die Ernüchterung. Das Entwicklungsteam, dass wir ab heute voll eingeplant haben, und das ab heute auch unser Budget aufzehrt, kann nicht arbeiten! Wieso? Nun, wir haben für das Team keine Entwicklungsmaschinen.

Ja, aber! Das ist ja wohl Aufgabe des Entwicklers, dass er sein Handwerkszeug mitbringt! Schließlich habe ich ihm als Projektleiter ja auch keinen Laptop oder Tastatur besorgt! Schon, aber so einfach ist das nicht. Natürlich hat der Entwickler bereits für viele Kunden gearbeitet und natürlich hat er sich irgendwann auch mal eine Development-VM aufgesetzt. Doch die ist leider nicht das, was wir für unsere Anforderungen brauchen. Das kann dann sein, wenn wir z.B. mit einer ganz neuen Version von SharePoint arbeiten, für die es schlicht noch nichts gibt. Oder wir benötigen eine K2 oder Nintex Engine. Außerdem wurde diese Entwicklungsmaschine ja schon von 10 Projekten mit 1.000 Einzelanforderungen genutzt. Jede hat die Maschine etwas weiter kaputt konfiguriert und nun ist sie für uns einfach nicht mehr brauchbar.

Diese Problem mag einigen Projektleitern etwas weit hergeholt zu sein. Und tatsächlich tritt es auch nicht so häufig auf. Besonders in Zeiten des Client-Server-Object-Models ist es ehr selten, dass ein Projekt wirklich den ganzen Server kaputt konfiguriert. Doch auf der anderen Seite steht, dass der Schaden beträchtlich sein kann, wenn es wirklich auftritt. Spätestens bei Release-Wechsel der Host-Plattform (z.B. SharePoint) muss definitiv eine neue Maschine her. Im Idealfall haben wir tatsächlich eine Maschine pro Projekt und/oder Kunde, auf der wir den letzten Stand einfach archivieren können und wenn der Kunde eine Weiterentwicklung möchte, reaktivieren wir einfach die Maschine und arbeiten weiter. Meist ist dies aus Platzgründen Wunschdenken. Außerdem möchten die Projekte diese Konfiguration der Entwicklungs-VMs natürlich nicht zahlen. Also, was machen wir nun?

Die eleganteste Lösung bietet aus meiner Sicht die Azure Cloud an. Vor allem, wenn man selbst ein Entwickler mit MSDN-Subscription ist. Denn dann hat man auf der Azure Plattform bereits ein gewisses Cloud-Kontingent gratis dabei. Ja, schön. Aber ist das Problem dann jetzt nicht nur von meiner eigenen VM in eine Cloud-VM verschoben? Die Antwort ist nein. Denn Microsoft bietet inzwischen unzählige Images an, die verschiedenste Anforderungen abdecken. Im Rahmen dieses Artikels habe ich mir den aktuellsten Stand selbst einmal angesehen. Aktuell werden aktuell bereits Visual Studio 2017 RC und die SharePoint 2016 Trail Version als Konfigurationssetting für die eigene VM angeboten.

Ich habe der Vollständigkeit halber auch einmal getestet, wie lange die Installation der beiden Systeme dauert. Für Visual Studio hat es mich vom Einstellen der Parameter bis zur Eingabe der ersten Quellcode-Zeile etwa 30 Minuten gekostet. Das Öffnen von Visual Studio innerhalb der neuen VM hat beinahe genauso lange gedauert wie das Provisionieren der VM durch Azure. Aus meiner Sicht eine wirklich überzeugende Geschwindigkeit.

Für den SharePoint 2016 sah das Ganze ähnlich aus. 20 Minuten vom Konfigurieren bis zum Öffnen des Config Wizards. Insgesamt haben wir also innerhalb von etwa einer Stunde sowohl eine SharePoint 2016er Plattform als auch Visual Studio als Entwicklungsumgebung aufgesetzt und konnten anschließend arbeiten.

Wer übrigens eine vollständige Anleitung zum Installieren einer VM für SharePoint 2016 auf Azure benötigt, wird hier fündig: https://technet.microsoft.com/de-de/library/mt723354(v=office.16).aspx

Nachdem diese Maschinen übrigens einmal aufgesetzt wurden, kann man in den Einstellungen auch so genannte Automatisierungsskripte finden. Diese Skripte erlauben es einem exakt die gleiche Umgebung erneut aufzusetzen, indem man bspw. über PowerShell das Skript erneut ausführt. Das ist also dann interessant, wenn jemand zum Start eine blanke 2016er SharePoint VM mit Visual Studio 2015 R3 benötigt. Ein Skript absetzen und etwas warten. Dann wird in der eigenen Azure Umgebung eine neue Applikation provisioniert und kann anschließend eingesetzt werden.

Aber die Kosten! Ja, die sollte man nicht aus den Augen verlieren. Für eine virtuelle Maschine mit 8 Kernen und 14 GB RAM werden bei 160 Stunden Laufzeit (also 20 Tage * 8 Stunden) ca. 100€ fällig. Nimmt man einen separaten Domain Controller mit 2 Kernen und 4 GB RAM dazu ist man zusammen bei etwa 120€ pro Entwickler und Monat. Ein nicht unerheblicher Betrag. Doch man muss bedenken, dass einem Entwickler mit MSDN Lizenz ohnehin etwa 130 Euro Guthaben pro Monat zur Verfügung stehen. In diesem Fall würde er also nicht einen Euro echten Geldes kosten und hätte eine frische virtuelle Maschine für jedes Projekt, die auch nur dann das Guthaben belastet, wenn sie wirklich eingeschaltet ist.

Einzig die Staging-Maschinen sollten dann von einem Konto betrieben werden, dass nicht direkt den Entwicklern zugeordnet ist, um nicht die Budgetgrenzen zu sprengen. Oder man entscheidet sich dafür, dieses Geld zu investieren.

Und wenn man einen guten Sales Manager hat, dann verkauft dieser die entstehenden Kosten gleich mit. Immer mit dem Argument, dass die Entwicklungsmaschinen anschließend nicht gelöscht werden müssen und damit der letzte Entwicklungsstand sauber archiviert wird. Ein ziemlich guter Vorteil für Unternehmen im agilen Umfeld, wenn ihr mich fragt.

Mehr zum Thema?

Meetingkultur

Worauf man bei Meetings achten sollte

Während meines bisherigen Arbeitslebens habe ich verschiedenste Arten und Organisationsformen von Meetings und Schulungen erlebt. Einige empfand ich und meine Kollegen als extrem zielgerichtet und wirkungsvoll. Es wurden Dinge beschlossen und die Umsetzung sauber geplant. Die Leute gingen motiviert und mit einer Vision aus dem Raum. Bei anderen Meetings hatte ich das Gefühl das mein Hirn in Watte gepackt ist. Man hört zwar zu, doch es interessiert einen nicht. Die dritte große Kategorie waren Meetings, bei denen wohl selbst der Veranstalter nicht wusste, worum es eigentlich ging und bei denen es schnell in ein unorganisiertes Durcheinander ausgeartet ist.

Doch woher kommen diese Unterschiede? Gibt es Regeln, die man beachten sollte? Und bringen diese Wirklich einen Mehrwert? In diesem Beitrag soll es genau darum gehen. Was muss bei einem Meeting beachtet werden.

Vor dem Meeting

Die Vorbereitung eines Meetings ist ebenso wichtig wie das Meeting selbst. Man sollte sich bewusst machen, dass man bei einem Meeting eine große Anzahl (3 oder mehr) von Personen in einem Raum versammelt um gemeinsam einen Sachverhalt zu klären oder eine Entscheidung herbeizuführen. Hierbei sollte einem immer klar sein, dass hierfür enorme Mengen an Arbeitszeit aufgewendet werden. Bei einem Meeting über 2 Stunden und mit 4 Personen ist bereits ein ganzer Arbeitstag aufgewendet. Umso wichtiger ist es, dass der Veranstalter möglichst viele Informationen bereits im Vorfeld bereitstellt und seine Anfragen und Klärungsabsichten möglichst klar formuliert. Hierfür eignet sich am besten direkt die Einladung, die beispielsweise über Outlook versendet wird.

Das Wichtigste ist dabei direkt der Titel, mit dem diese Einladung versendet wird. Steht dort prägnant um was es in diesem Meeting gehen soll? Wenn es nicht möglich ist den Zweck dieses Meetings in einem einfachen Titel zu umschreiben, sollte man noch einmal grundsätzlich über die Ausrichtung dieses Meetings nachdenken. Ist die Aufgabenstellung für das Meeting überhaupt geeignet? Sind die Fragen und Aufgaben prägnant genug um in einem solchen Meeting geklärt zu werden? Erst wenn man einen prägnanten Titel (z.B. Sprintplanungsmeeting, Klärung des Bugs XY, Mentoring für Person ABC) hat, sollte man hier fortfahren.

Ebenso wichtig ist der Empfängerkreis. Lade ich wirklich nur die Personen ein, die direkt in die Entscheidung eingebunden werden sollen? Haben die Personen also einen wichtigen Beitrag zu leisten? Wenn es nur darum geht, dass diese Personen ein oder zwei Anmerkungen machen sollen, oder an einem Teilproblem mitwirken, wäre es dann vielleicht besser, diese Personen gesondert zu einem anderen Termin einzuladen? Oder ist es dem Veranstalter möglich die Informationen bereits im Vorfeld einzuholen, sodass auf die Personen verzichtet werden kann? Es wäre ja auch möglich diese Leute einfach per Skype zu dem Meeting dazu zu holen, wenn es notwendig wird. So könnten diese den Rest des Meetings fernbleiben und während dieser Zeit etwas anderes machen.

Kommen wir zum Text der Einladung. Dieser sollte mindestens eine Agenda enthalten, in welcher die Sachverhalte erläutert werden, um die es im Meeting geht. Im Idealfall wird bereits so gut wie möglich vorgearbeitet und die Anfrage möglichst klar kommuniziert. Auch weiterführende Links zur Projektablage oder ähnlichem können hier weiterhelfen. Es sollte nach Möglichkeit alles enthalten sein, was den Beteiligten im Vorfeld hilft ein detailliertes Bild von der Situation zu bekommen. Da es sich bei den meisten Meetings um kein völlig neues Thema handelt und die Kollegen meistens schon recht genau wissen worum es gehen könnte, ist die Agenda mit einigen Details angereichert meist auch schon genug. Wichtig ist, dass klar hervor geht, welche Frage geklärt oder welcher Sachverhalt bearbeitet werden soll.

Die Uhrzeit und Dauer des Meetings sind natürlich auch wichtig. Man sollte bereits im Vorfeld die Terminkalender der Beteiligten überprüfen, damit es hier nicht zu Terminüberschneidungen kommt. Wenn möglich sorgt auch eine gewisse Vorlaufzeit dafür, dass die Kollegen sich eventuell den Termin freischaufeln können.

Während des Meetings

Okay, die Vorbereitungen sind also getroffen. Die Kollegen nehmen an dem Meeting teil und es beginnt. Was ist nun zu beachten? Als erstes sollte der Meeting-Leiter natürlich noch einmal in eigenen Worten erklären worum es in dem Meeting geht und was aus seiner Sicht die zu erzielenden Ergebnisse sind. Anschließend sollte er die Sicht der Beteiligten einholen, die eventuell noch etwas zu dieser Zielsetzung beitragen können. Wichtig ist,´dass die Veranstaltung der Diskussion und Lösungsfindung zwischen den Teilnehmern dienen soll. Es ist an dieser Stelle also meist wenig ratsam

Eventuell ist es auch so, dass nicht alle Meeting-Teilnehmer die gleiche Relevanz haben. So kann es durchaus sein, dass einige Kollegen nur für Teilbereiche der Aufgabenstellung benötigt werden. Diese Teilbereiche sollte man dann natürlich nach vorne verschieben um die Arbeitszeit der Kollegen möglichst wenig mit dem Meeting zu belasten. Ist ihre Aufgabe erledigt, können diese Kollegen dann wieder zu ihrer eigentlichen Arbeit zurückkehren.

Wichtig ist dabei, dass alle getroffenen Entscheidungen, alle Aufgaben und alle Unklarheiten, die in diesem Meeting auftreten auch protokolliert werden. Während eines Meetings ist es oft so, dass viele Aussagen getroffen und oftmals auch schnelle Entscheidungen getroffen werden. Teilweise auch unter der Annahme, dass jeder diese Aufgabe verstanden, akzeptiert und für sich irgendwie notiert oder gespeichert hat. Dabei sind jedoch nicht alle Entscheidungen für alle Mitarbeiter gleich wichtig und manche Kollegen merken sich eventuell eine Entscheidung nicht, da diese aus ihrer aktuellen Situation nichts mit ihnen zu tun hat. Erst wesentlich später wird dieser Aspekt – vielleicht aufgrund eines Rollenwechsels oder aufgrund einer falschen Einschätzung des Kollegen – wieder interessant und relevant. Aus genau diesem Grund ist es wichtig, dass es während eines Meetings einen Protokollführer gibt, der alle neuen Entscheidungen, Fragen und Aussagen notiert. Das kann über einen PC, Clipboard, Block oder sonst einem Medium geschehen. Zu diesem Zeitpunkt ist möglichst leichte Handhabung wichtiger als Struktur!

Hat ein Kollege seine Aufgaben in einem Meeting erfüllt – bspw. muss der Programmierer nicht für Design-Fragen bleiben. Hier reicht später eine Zusammenfassung – sollte man seine Aufgaben und die mit ihm gewonnen Erkenntnisse noch einmal kurz zusammenfassen, sodass alle Parteien eine ähnliche Vorstellung davon haben. Aufgrund der subjektiven Wahrnehmung der Teilnehmer ist eine identische Vorstellung eines Sachverhalts meist nicht möglich und auch an dieser Stelle lassen sich Unklarheiten nur reduzieren, nicht jedoch ausschließen. Ist diese Zusammenfassung erfolgt, sollte man den Kollegen auch von dem Rest des Meetings freistellen. Oftmals werden Kollegen von Anfang bis Ende in einem Meeting gehalten, obwohl sie nur einen sehr speziellen Aspekt betreuen. Dies führt zu Frust über das Meeting bei dem Kollegen und verschlingt unnötig die kostbare Projektzeit. Eine Zusammenfassung der wichtigsten Themen im Nachgang wird später noch genauer beleuchtet und dient diesen Kollegen als Verständnisbasis des restlichen Meetings.

Während des gesamten Meetings hat der Meeting-Leiter vor allem eine Aufgabe. Er koordiniert die Teilnehmer und sorgt dafür, dass die Diskussionen in den richtigen Bahnen verläuft. Sobald ein Teilnehmer zu ausschweifend wird oder sich zu sehr in Details verstrickt, sollte der Meeting-Leiter diesen Kollegen freundlich aber bestimmt zurück zum eigentlichen Thema führen. Schnell verlieren sich die Teilnehmer sonst in Diskussionen, bei denen wieder nur ein Teil der Teilnehmer wirklich etwas zu sagen hat, oder das eigentliche Thema wird nicht bearbeitet und bleibt liegen. Natürlich kann dies bei einem wichtigeren Thema durchaus sinnvoll sein, sofern es auch hier wieder dokumentiert wird. Wichtig ist jedoch wie gesagt, dass der Meeting-Leiter die Sorge dafür trägt, dass der eigentliche Fokus des Meetings nicht aus den Augen verloren wird.

Nähert sich das Meeting dem Ende sollte der Meeting-Leiter noch einmal die getroffenen Vereinbarungen, Entscheidungen, offenen Fragen etc. zusammenfassen, sodass jeder noch einmal überprüfen kann, ob auch alle für ihn relevanten Ergebnisse vertreten sind oder er noch etwas anmerken, hinzufügen oder klarstellen möchte. Dies ist auch dann wichtig, wenn das Meeting sich als zu kurz herausgestellt hat. In diesem Fall sollten bereits die wichtigsten Punkte für die unmittelbare Zukunft geklärt sein. Die Zwischenergebnisse werden noch einmal zusammengefasst und die Punkte für den Folgetermin besprochen.

Da die Kollegen in aller Regel Folgetermine oder reguläre Aufgaben haben, sollte das Ende des Termins stets eingehalten werden. In Ausnahmen kann der Meeting-Leiter die Kollegen fragen, ob sie mit einer Verlängerung des Termins einverstanden wären. In diesem Fall sollte jedoch auch geprüft werden, ob der gebuchte Raum noch frei ist.

Nach dem Meeting

Ist das Meeting abgeschlossen, sollte der Meeting-Leiter die erarbeiteten Erkenntnisse verarbeiten und ablegen. Zum einen sollte er die zuvor mündliche Zusammenfassung nun noch einmal schriftlich an alle Teilnehmer versenden. Zum einen ist dies eine Gedächtnisstütze für die Kollegen, zum anderen haben eventuell Kollegen das Meeting vorzeitig verlassen.

Gibt es zu diesem Meeting außerdem noch Stakeholder, also Leute, die an den Ergebnissen interessiert sind ohne direkt Mitsprache zu haben, können auch diese eine Zusammenfassung erhalten. Diese ist meist verkürzt gegenüber der internen Zusammenfassung, da dieser Personenkreis deutlich weniger in der Materie und meist nur an den eigentlichen Ergebnissen interessiert ist. Dafür kann es notwendig werden, weitere Erklärungen in die Zusammenfassung einzubinden. Zum Beispiel für spezielle Sachverhalte oder Fachbegriffe.

Alle erarbeiteten Ergebnisse müssen schließlich noch auffindbar abgelegt werden. Das kann zum Beispiel in einem speziellen Projekt- oder Themenraum sein. Der Link sollte ebenfalls an die Zusammenfassung – zumindest bei den beteiligen Kollegen – angehangen werden.

Tut das Not, dass da so viel Arbeit reingesteckt wird?

Jetzt kann ich schon hören, wie einige sich insgeheim fragen, ob das alles Not tut. Das kann man doch auch viel schneller machen und so hat man ja einen Riesenaufwand! Ja, den Aufwand will ich nicht leugnen. Trotzdem ist das aus meiner Sicht die richtige Vorgehensweise, wenn man ein Meeting zu einem wichtigen, verbindlichen Thema machen will. Die Frage, die ich mir ehr stelle ist, warum ich ein Meeting aufsetzen will, wenn  ich keine verbindlichen Aussagen haben möchte. In diesem Fall könnte ich mich schließlich auch mit den Kollegen beim Mittag oder auf einen Kaffee treffen.

Ein Meeting hat für mich immer einen offiziellen Charakter und sollte auch so gelebt werden. Es muss eine Hürde geben ein Meeting einzuberufen, da man sonst nur noch in solchen Veranstaltungen hängt. Typische Beispiele für ein Meeting sind aus meiner Sicht die Meilensteinplanung, Eskalationsmeetings, Phasenabschlussmeetings oder die Scrum-Meetings. Und ja, selbst bei dem Daily Scrum gibt es diese Form. Wir haben einen festen Teilnehmerkreis, jeder berichtet möglichst flott was er geleistet hat, was er vor hat und was ihn hindert. Und diese Erkenntnisse werden dann schriftlich im Sprint-Backlog und der Impediments-Liste erfasst. Eine Zusammenfassung kann hier entfallen, da die Liste für jeden zugänglich ist und es bekannt ist, dass die Ergebnisse hier abgelegt sind.

Von daher meine Bitte, überlegt euch ob ihr ein Meeting benötigt. Und wenn, dann führt es so aus, dass auch in ein paar Wochen noch klar ist, was besprochen wurde und wo ich die Ergebnisse finden kann.

Zusammenfassung

Vor dem Meeting:

  • wähle einen Titel der möglichst treffend ist
  • lade nur ein, wer wirklich notwendig ist
  • mache ggf. mehrere Meetings mit unterschiedlichen Teilnehmern
  • schreibe eine Agenda zum Meeting
  • verlinke, wenn notwendig, auf weiterführende Informationen und Projekträume
  • fasse die konkreten Anforderungen verständlich zusammen
  • wähle eine Zeit, in der die Personen zeit haben oder kläre mit verhinderten Personen, ob sie den Termin zwischenschieben können

Während dem Meeting:

  • Fasse den aktuellen Stand anfangs zusammen
  • Fasse die konkreten Aufgaben und Fragestellungen zusammen
  • Es ist eine Diskussionsrunde. Verzichte auf PowerPoints und Monologe
  • Lass die Teilnehmer notwendige Ergänzungen machen
  • Behandele zuerst die Themen, bei denen Kollegen vorzeitig das Meeting verlassen können
  • Notiere jede Entscheidung, Frage oder Erkenntnis mit
  • Fasse den aktuellen Stand auch am Ende des Termins zusammen
  • Vereinbare direkt einen Folgetermin, wenn dieser notwendig ist
  • Verlängere den Termin nur in Ausnahmen und mit Zustimmung der Beteiligten

Nach dem Meeting:

  • Eine Meeting-Zusammenfassung mit den wichtigsten Ergebnissen und Entscheidungen wird an alle Teilnehmer versendet
  • Erarbeitete Ergebnisse werden auffindbar abgelegt
  • Eine verkürzte Zusammenfassung kann eventuell an Stakeholder versendet werden, sofern sinnvoll

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.