ALM Tech Blog

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?

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