Zwischenabnahmen

Zwischenabnahmen während des Projektes sind ohne Zweifel gut und notwendig. Sie geben dem Projekt eine gewisse Sicherheit, in die nächste Phase überzugehen. Sie bilden somit auch eine Art Scope-Basis auf der der Projektleiter weiter verhandeln kann.
Die Frage stellt sich aber, wann Zwischenabnahmen gemacht werden sollen und wie.

Dazu soll sich der Projektleiter aber erst einmal im Klaren sein, wo oder zu welchem Zeitpunkt es in seinem Projekt eine Zwischenabnahme geben soll.

Beispiele:

• Nach Abschluss der Konzeption beziehungsweise vor dem Umsetzungsstart
• Nach Erarbeitung des Designs
• Vor Migrationsbeginn
• Allgemein bei Erreichung von Meilensteinen

Zwischenabnahmen können auf unterschiedliche Art und Weisen durchgeführt werden. Am besten gibt dies  der Projektleiter vor. Hier ein paar Beispiele:

1. Zwischenabnahme-Protokoll: 
Der Projektleiter und der Auftraggeber erstellen ein Zwischenabnahme-Protokoll in dem ein Teil des Projektes (z.B. Screendesign) formal abgenommen wird. Das Protokoll wird von beiden Seiten unterzeichnet und gelangt in die allgemein zugängliche Projektablage.

2. Zwischenabnahme über das Issuetracking System:
Im Issuetracking-System (Beispielsweise JIRA) wird ein Task für die Zwischenabnahme erstellt (z.B. Abnahme des Screendesigns). Der Auftraggeber bestätigt nun die Abnahme über das Issue Tracking System, in dem er das Issue entsprechend kommentiert und auf "Done" setzt. Hat er Ergänzungen zur Abnahme, so kann er diese ebenfalls über die Kommentarfunktion hinzufügen.

3. Zwischenabname im Wochenreport:
Der Projektleiter vereinbart mit dem Auftraggeber, dass die Zwischenabnahme erfolgt ist und dokumentiert dies im Wochenreport. Wichtig hier ist, dass der Auftraggeber, den Wochenreport formal abnimmt (z.B. schriftliche Bestätigung per Mail oder ebenfalls über das Issue Tracking System (idealerweise ist das aber sowieso bei jedem Wochenreport der Fall).

4. Zwischenabnahme über Mail:
Der Projektleiter erstellt ein Bestätigungsmail für die Zwischenabnahme und der Auftraggeber bestätigt dieses.

Empfehlung:
Aus meiner Erfahrung eignet sich Punkt 2 am Besten für eine Zwischenabnahme. Wenn sich der Prozess über das Issue Tracking System etabiliert hat, so ist das die schnellste Art und Weise, eine Zwischenabnahme durchzuführen.
Die Erstellung eines Zwischenabnahme-Protokolls ist in vielen Fällen sehr aufwändig. Für die Unterzeichnung ist idealerweise ein physisches Meeting notwendig, allenfalls muss danach das Protokoll nochmals angepasst werden und erst dann kann die Unterschrift erfolgen. Solche Anpassungen können über die Kommentarfunktion im Issue Tracking System einfach und schnell gemacht werden.
Punkt 3 eignet sich auch gut für die Zwischenabnahme, aber nur dann, wenn sich im Projekt ein Abnahmeprozess für die Wochenreports etabiliert hat. Wenn nicht, wäre es nicht konsequent, wenn der Auftraggeber einmal den Wochenreport formal abnehmen muss und ein andermal nicht.
Punkt 4 ist nur dann zu empfehlen, wenn keine weiteren Hilfsmittel (Issue Tracking oder Wochenreport) vorhanden sind. Ansonsten werden Mails oftmals versehentlich gelöscht oder gehen in der Menge der Mails unter.
Die Endabnahme sollte aber in jedem Fall auf schriftlichem Weg in einem Abnahmeprotokoll erfolgen.

Wichtig ist, solche Abnahmeprozesse zu Beginn des Projektes mit dem Auftraggeber festzulegen, so dass diese Zwischenabnahmen reibungslos erfolgen können und die Weiterarbeit am Projekt nicht verhindern oder verzögern.

Projektleitungs-Stolpersteine: Weiterleiten von Mails

Des öfteren erlebe ich folgende Situation:
Der Kunde hat per Mail eine Anfrage an den Dienstleister (den Projektleiter) gestellt. Der Projektleiter leitet das Mail intern an den Entwickler weiter, weil er die Anfrage nicht selbst beantworten kann. Der Entwickler antwortet auf das Mail und der Projektleiter leitet das Mail mit dem Vermerk "Lieber Kunde, unten stehend finden sie die Antwort" an den Kunden wieder weiter.

So nicht, Projektleiter!

Aus meiner Sicht ist es überhaupt nicht kundenfreundlich, wenn der Kunde, der eine Anfrage erstellt hat, zuerst das ganze Mail Ping-Pong zwischen Projektleiter und Entwickler  durchlesen muss um eine Antwort auf seine Frage zu erhalten.
Der Projektleiter soll sich die Zeitnehmen, selbständig eine Antwot für den Kunden zu formulieren und direkt auf das Mail vom Kunden antworten. Die History zwischen Entwickler und Projektleitung hat nichts im Mail an den Kunden verloren.

Fazit:
Antworten auf eine Kundenanfrage immer selbst formulieren:

• Der Projektleiter setzt sich so ebenfalls mit der Thematik auseinander und kann auf eine allfällige telefonische Nachfrage des Kunden kompetent reagieren.
• Das Mail enthält die Sprache des "Projektleiters" und nicht des "Entwicklers", was oftmals für den Kunden verständlicher ist.
• Der Kunde erhält die Antwort auf einen Blick, ohne das ganze Mail Ping-Pong durchlesen zu müssen.

Teil 5: Kommunikation im Projektteam

Innerhalb eines Projekt-Teams gibt es sehr viele Kommunikationsmöglichkeiten, die meiner Meinung nach auch sehr viel "Konflikt-Potential" beinhalten. Hier ein paar Beispiele:

Kommunikation über Skype / Instant Messaging
Chat-Kommunikation ist sehr praktisch, vor allem, wenn man nicht im gleichen Raum sitzt und dem Entwickler eine Info weitergeben möchte (z.B. einen Link schicken oder ein Dokument etc.). Es birgt aber auch viele Gefahren:

• Chat ist zeitaufwändig! Tippen geht oftmals länger als telefonieren
• Chat ist nicht immer verständlich: Ohne Mimik und Gestik und ohne Tonfall des Gesprächspartners können Dinge oft falsch verstanden werden. 
• Chat ist Abklenkung: Wenn dauernd das Instant Messaging Icon aufleuchtet, lenkt das von der eigentlichen Arbeit ab

Für Kurzinformationen ist Chat sicherlich sinnvoll. Ernste Themen (z.B. wenn ein Team-Mitglied die Spielregeln verletzt) sollten niemals über Chat angesprochen werden, sondern immer persönlich.

Kommunikation über Issue-Tracking und Kommunikation über Mail:
Issue Tracking: siehe Post hier
Mail: siehe Post hier

Persönliche Kommunikation:
Innerhalb eines Projektteams, ist die persönliche Kommunikation meiner Meinung nach die Wichtigste und die Effizienteste. Hindernisse, Probleme aber vor allem auch Lob und Kritik sollten sofort und persönlich angesprochen werden. Dabei helfen folgende Dinge:

• Regelmässige Feedbackrunden im Team und wenn notwendig auch im persönlichen Gespräch
• Regelmässige physische Projektstatusmeetings
• Smalltalk in den Pausen oder einfach mal Zwischendurch
• Regelmässiger Austausch im Team 

Wenn keine Gespräche mehr stattfinden, alles virtuell gemacht wird, dann kann der Projektleitder davon ausgehen, dass etwas im Team nicht stimmt...

Teil 4: Kommunikation in Meetings

Meetings müssen immer vom Meetinginitiator vorbereitet werden, das ist selbstverständlich und muss an dieser Stelle nicht genauer erläutert werden. Auch ein anschliessendes Protokoll gehört zu einem Meeting. Ich gehe in diesem Post eher auf die Kommunikation in einem Meeting ein und gebe ein paar Tips, was man dabei beachten sollte:

1. Sich verstehen
Immer wieder erlebe ich Situationen, in denen 5 Leute an einem Tisch sitzen und über ein Issue diskutieren und dabei komplett aneinander vorbei reden. Bei solchen Situationen hilft es, zuerst ein gemeinsames Verständnis für das Problem zu schaffen, beispielsweise, in dem das Problem aufgezeichnet wird. Oder in dem jeder seine Sichtweise erläutert.

2. Hilfmittel verwenden
Oftmals werden für ein Meeting PPT Slides vorbereitet und gezeigt. Das hat aber viel mehr Präsentations- an Stelle von Meeting-Charakter. Präsentationen sind für den Roten Faden im Meeting sicher hilfreich. Dennoch sollten auch andere Hilfsmittel verwendet werden, beispielsweise Flipchart oder ein Issue direkt am System oder auf dem Web anschauen und besprechen.

3. Moderieren
Endlos-Diskussionen sollten vermieden werden. Hierfür ist es hilfreich, wenn jemand bewusst die Moderations-Rolle übernimmt. Der Moderator hat auch die Zeit, welche für das Meeting vorgesehen im Griff und schaut, dass alle Themen besprochen werden können oder verschiebt Themen in ein nächstes Meeting. Der Moderator soll auch dafür sorgen, dass alle Beteiligten beim Thema bleiben. Hilfreich ist, wenn zu Beginn des Meetings, alle (ausser derjenige der das Protokoll schreibt) die Handys und Notebooks beiseite legen. Diese lenken oft von der eigentlichen Thematik ab

4. Zuhören und Ausreden lassen
Wichtig ist, die Personen ausreden zu lassen. Wenn der Projektleiter aber dabei ein Mail liest, oder mit den Gedanken komplett woanders ist, ist das genauso respektlos, wie wenn man der Person das Wort abschneiden würde. Zuhören ist wichtig, auch wenn nicht immer alles mit der Thematik zu tun hat. Wenn das Gesagte ein anderes Thema betrifft, so soll der Moderator das auf ein nächstes Gespräch verschieben.

.

Der unangenehme Projektleiter....

... überbringt dauernd schlechte Nachrichten. Eine typische Kundenaussage ;o).

...Es sind Performance Probleme aufgetreten. Wir suchen eine Lösung.
...Gemäss Angebot ist das leider nicht im Scope. Wir könnten dafür einen Change Request eröffnen.
...Der Termin kann auf Grund von xyz nicht gehalten werden, es sei denn, wir streichen einige Funktionalitäten.
...

Ja, die Aufgabe des Projektleiters ist es, nebst allem anderen auch mal eine schlechte Nachricht zu überbringen. Meistens bewegen sich solche Nachrichten im Dreieck Termine, Kosten Leistung. Dass der Kunde nicht erfreut darüber ist, ist klar, aber es gibt ein paar Möglichkeiten, dass das Projekt deswegen nicht gerade eskaliert wird:


Als erstes Grundprinzip gilt die Ehrlichkeit:
Der Projektleiter soll niemals dem Kunden ein Luftschloss bauen und sich mit vagen Ausreden dem Kunden gegenüber zu äussern. Wenn ein Problem auftritt, so muss das sofort auf den Tisch und es muss darüber gesprochen werden:

• Schlechte Nachrichten nicht in einem Statusbericht oder einem Mail verpacken, sonder persönlich mit dem Auftraggeber anschauen und klären.
• Es hilft als Vorbereitung auch bereits mögliche Lösungszenarien zu entwerfen und dem Auftraggeber somit zeigen, dass man bereits eine Lösung für das Problem hat. 

Ehrlichkeit schafft auch Vertrauen!

Als zweites Grundprinzip gilt die Rollenklärung:
Da des Projektleiters tägliche Arbeit auch daraus besteht, den Scope zu überwachen, zu kommunizieren und informieren, ist es nun mal so, dass es oft am Projektleiter hängen bleibt, eine schlechte Nachricht zu kommunizieren. Das wissen wir als Projektleiter und es gibt kaum ein Projekt in dem es keine "schlechte Nachrichten" gibt. Hier hilft es, wenn der Projektleiter zu Beginn des Projektes den Auftraggeber ganz konkret darauf aufmerksam macht, dass das seine Rolle ist und dass es somit auch mal passieren kann, dass etwas Unangenehmes gesagt werden muss. Aber wie bereits erwähnt, Luftschlösser haben im Projekt nichts verloren. Es ist immer noch besser, frühzeitig über ein Problem informiert zu werden, als am Schluss eine böse Überraschung zu erleben.
Wenn es dem Projektleiter gelingt, ein kollegiales Verhältnis aufzubauen, dann fällt es leichter, solche Nachrichten zu kommunizieren. Bei eher eisigen Kundenverhältnissen soll der Projektleiter einfach authentisch sein und Mitgefühl zeigen, sich versuchen in die Lage des Kunden zu versetzen. Im Notfall kann man auch eine Schlichtungsperson beiziehen.

Als drittes Grungprinzip gilt die Verhandlungsbasis:
Der Projektleiter muss sich, gerade wenn Probleme auftreten über die Verhandlungsbasis im Klaren sein. Das heisst, er muss genau wissen, was vereinbart worden war, wo das Projekt steht, und auf welche Faktoren das Problem Auswirkungen haben kann. Dabei kann folgendes helfen:

• Zu Beginn des Projektes den Tade-Off definieren
• Zwischenabnahmen durchführen
• Den Vertrag und die Allgemeinen Bedingungen kennen
• Die wöchtentlichen Statusberichte und die Meetingprotokolle kennen
• Erst bei Problemen oder Hindernissen kommt man zur Erkenntnis, dass alles sauber dokumentiert werden sollte. Die Dokumentation des Projektes sollte niemals vernachlässigt werden, auch nicht wenn alles rund läuft.
• Von Vorteil ist es, wenn der Projektleiter einen Joker hat: Das heisst, der Projektleiter hat schon bevor das Problem aufgetreten ist, vorgesorgt. Risikoanalysen und entsprechende Massnahmen können hierbei helfen.

Teil 3: Kommunikation am Telefon

Nebst den physischen Meetings sind Telefongespräche das wichtigste Kommunikationsmittel im Projektmanagement. Oftmals glaubt der PL zwar, dass er mit einem Mail schneller ist, aber ein Telefongespräch ist immer besser:

• Durch das Gespräch wird ein Sachverhalt verständlicher, die beiden Gesprächsparteien haben die Möglichkeit die Situation zu erklären.
• Viele schreiben lieber über ein heikles Thema, als dass sie darüber sprechen, doch ein heikles Thema kann in einem Gespräch besser dargelegt werden, als im Mail (Tonfall, Einleitung mit Smalltalk)
• Gewisse Dinge können sofort geklärt werden, man kriegt sofort eine Antwort, beim Mail kann es durchaus wieder einen Tag oder mehr dauern, bis eine Antwort vorliegt.

Dennoch sollte der Projektleiter nicht wahllos das Telefon in die Hand nehmen und einfach mal beim Kunden anrufen und dann von Thema zu Thema hüpfen. Wie beim Meeting auch, gehört zu einem Telefongespräch auch eine gewisse Vorbereitung:

Vor dem Telefongespräch:

• Ziel des Gespräches Festlegen
• Wichtigste Argumente aufschreiben (da diese während dem Gespräch oft vergessen werden)
• Gesprächsleitfaden festlegen (Einleitung, Argrumentation, Forderung)
• Allenfalls dem Kunden im Vorfeld eine Agenda zum Gespräch zukommen lassen, damit dieser sich ebenfalls vorbereiten kann. 
• Bei "schwierigen Gesprächen" ein Sitzungszimmer buchen
• Zeit für das Gespräch einplanen (auch Zeit vom Kunden einfordern)
• Allenfalls Gesprächsunterlagen vorgängig dem Kunden schicken.

Während dem Telefongespräch:

• Ziele zu Beginn kommunizieren, Einverständnis des Gesprächspartners einholen
• Falls mehrere Teilnehmer sind (Telefonkonferenz) die Beteiligten jeweils vorstellen
• Gesprächsleitfaden im Auge behalten und Abweichungen vermeiden
• Sich nicht durch andere ablenken lassen
  
• Am Schluss des Gespräches nochmals die wichtigsten Punkte und das Resultat sowie die weiteren Schritte zusammenfassen

Nach dem Gespräch:

• Kurzprotokoll mit den Gesprächsergebnissen an den Kunden schicken. 

Und was tun wir, wenn wir vom Kunden angerufen werden?

• Versuchen, eine Struktur in das Gespräch zu bringen, nach den Zielen Fragen, gezielte Fragen stellen
• Wenn man keine Antworten auf das Anliegen des Kunden weiss, soll man das ehrlich sagen und den Kunden zu einem späteren Zeitpunkt zurückrufen. 
• Gespräche im Zug oder an öffentlichen Stellen vermeiden, oder nur mit "Code-Wörtern" führen. Es gibt immer Leute die zuhören. Auch könnte das Gespräch auf Grund schlechter Verbindung unterbrochen werden. Auch hier um Rückruf bitten.