Die nie abgeschlossene Konzeption

Oftmals erlebe ich Projektsituationen, bei denen sehr ausfühliche Konzepte (Technisches Konzept und Business Konzept) vorhanden sind. In nahezu endloser Arbeit wurden Seite um Seite spezifiziert. Dies hat sicherlich seine Vorteile: Der Kunde fühlt sich sicher und weiss was er im Endeffekt kriegt. Zudem kann auf Grund der vorliegenden Spezifikation relativ genau abgeschätzt werden, wie hoch der Aufwand und die Risiken für die Umsetzung sind.

Doch so ausführlich die Konzepte auch sind, irgendwo tauchen während der Implementierung immer wieder Fragen auf und es gibt ein paar ganz pragmatische Tipps, wie der Projektleiter mit solchen Situationen umgehen kann:

1. Konzept lesen (Business und technisches Konzept)
Ich habe schon oft Diskussionen mit Entwicklern über Konzepte geführt, die eigentlich gar nicht notwendig waren, wenn man mal einen Blick ins Business Konzept geworfen hätte. Das bedeutet nicht, dass der Entwickler zu Beginn des Projektes über 1000 Seiten Konzept lesen muss. Aber er soll, wenn er ein Arbeitspaket erhält, zumindest diese Teile aus dem Konzept lesen, die für das AP relevant sind. Dazu gehört auch das Business Konzept. Oftmals wird das während der Entwicklung völlig vergessen.

2. Das Gespräch suchen
Egal ob Entwickler oder Projektleiter: Wenn Fragen zu einem Konzept auftauchen, soll man diese sofort im Gespräch klären. Einfach Annahmen zu treffen ist unter Umständen schneller ja, aber nicht unbedingt zielführender, insbesondere, wenn die Annahme falsch war. Idealerweise spricht der Entwickler zuerst mit dem Projektleiter. Dieser kann allenfalls bereits weiterhelfen. Ist dies nicht der Fall, so soll der Projektleiter ein entsprechendes Meeting einfordern. 
Offene Fragen sollten dann mit entsprechender Vorbereitung seitens Projektleitung/Entwicklung und mit einem Konzeptvorschlag mit dem Kunden diskutiert werden und anschliessend in einem Protokoll, oder Wochenreport festgehalten werden. So kann dies auch zu einem späteren Zeitpunkt  nachvollzogen werden.

3. Konzept mit fehlenden Elementen ergänzen. 
Sollten tatsächlich Spezifikationsteile fehlen, so sollen diese ergänzt werden. Meistens gibt es bis zum Schluss eines Projektes und vermutlich auch darüber hinaus immer wieder Elemente, die in einem Konzept ergänzt werden sollten. Ein Konzept lebt während eines Projektes und sollte nicht unantastbar sein. Auf Grund der Diskussion mit dem Kunden kann ein Konzept auch mal abgeändert werden, insbesondere dann, wenn es aus technischer Sicht empfehlenswert ist. Das muss der Projektleiter aber von Situation zu Situation beurteilen und entsprechend handeln.

Verhandlungen richtig führen

Kürzlich habe ich einen sehr schönen Beitrag mit Tipps für Verhandlungen gelesen. Dieses Thema möchte ich in diesem Post aufnehmen und über meine Erfahrungen berichten.

Ein Projektleiter steht nahezu täglich irgendeiner Verhandlung gegenüber:
- Verhandlungen über das Budget
- Verhandlungen über den Projektscope und über Change Requests
- Vertragliche Verhandlungen
- etc.

Hier ein paar Tipps, was der Projektleiter bei Verhandlungen unbedingt beachten sollte:

1. Win-Win Situation erzielen:
Der Projektleiter sollte bei einer Verhandlung stets versuchen, eine Win-Win Situation zu erziehlen. Das heisst, dass sein Lösungsvorschlag fair und für beide Parteien gewinnbringend sein sollte. Nur so kann er sicher stellen, dass das Projekt auf gutem Kurs bleibt und allenfalls ist der PL dann auch mal froh, wenn er ein faires Angebot von seinem Gegenüber erhält.

2. Saubere Vorbereitung:
Verhandlungsziel festlegen, Argumente sammeln, damit der Projektleiter seine Meinung klar vertreten kann, ist eine Voraussetzung für eine erfolgreiche Verhandlung. Dazu gehört auch, dass der Projektleiter bereits einen konstruktiven Lösungsvorschlag mitbringt und diesen vorstellt und sein Ziel sollte es dann auch sein, dass der Lösungsvorschlag akzeptiert wird. Dafür braucht es Informationen, beispielsweise allfällige Risiken, Vor- und Nachteile, allenfalls Kosten- oder Terminfolgen. All das muss der Projektleiter vor der Verhandlung festhalten. 

3. Sachliche Argumentation:
Eine Verhandlung sollte (bis auf wenige Ausnahmen) nicht auf der emotionalen Ebene geführt werden. Sachliche Argumentation auf Basis der Vorbereitung ist zielführender als allfällige Anschuldigungen oder Schudlzuweisungen. Zudem überzeugen sachliche und ehrliche Argumente insbesondere bei den nicht involvierten Personen (z.B. Stakeholdern) mehr und sind um einiges profesioneller als unnötige Emotionen). Eine Verhandlung ist keine Feedbackrunde, sondern ein Mittel, um eine geeignete Lösung für ein Problem zu finden.

4. Den guten alten Joker im Ärmel haben:
Verhandlung führen bedeutet auch Kompromisse einzugehen. Während der Vorbereitung sollte der Projektleiter seine Kompromisse bereits festlegen und diese Joker einsetzen, wenn es dies während der Verhandlung erfordert. Das verhindert unnötige Überraschungen während der Verhandlung, die möglicherweise einen anderen Ausgang als geplant nehmen. Und für den Projektleiter ist es immer eine sehr konfortable Situation, wenn er einen Joker hat, das bringt auch eine gewisse Gelassenheit mit sich.

Inwiefern ist der Kunde König?

In einer Dienstleister - Kundenbeziehung bewegt sich der Projektleiter meistens auf einem schmalen Grat. Er muss ständig abwägen, ob eine gewisse Handlung den Kunden zufriedenstellt, oder dem Projekt, bezw. dem Projektteam schadet.

Auf der einen Seite steht das Projekt, das termin- und kostengerecht umgesetzt werden soll und auf der anderen Seite steht der Kunde, der zufrieden sein möchte. Aber es gibt auch noch eine weitere Dimension, die ebenfalls beachtet werden muss: das Projektteam. Ein Beispiel:

Bei einem Change Request in letzter Minute steht der Launchtermin auf dem Spiel. Der Kunde möchte aber trotzdem, dass das unbedingt noch umgesetzt werden muss, wenn notwendig halt übers bevorstehende Wochenende. Der Kunde hat ein Grossprojekt umgesetzt und gehört zu den wichtigsten Kunden.
Nun hat das Projektteam aber schon die letzten Wochenenden durchgearbeitet, um das System termingerecht fertig zu stellen. Das Projekt wurde rechtzeitig fertiggestellt und jetzt kommt ein Change Request, der schon viel früher hätte gemacht werden können.
Was tun? Sich zu Gunsten des Kunden oder zu Gunsten des Projektteams entscheiden?

Solche Entscheidungen sind schwierig. Auf jeden fall soll der Projektleiter bei einer solchen Situation mit beiden Parteien das Gespräch suchen. In solchen Fällen finde ich es nicht unfreundlich, wenn der Projektleiter dem Kunden die Situation darlegt und ihm erklärt, dass es bereits ausserordentliche Einsätze gab und dass das Projektteam eigentlich eine "Pause" verdient hat. Die Verhandlung wird bewusst ein wenig auf die emotionale Ebene verlegt, um dem Kunden aufzuzeigen, dass Menschen am Projekt arbeiten und keine Maschinen. Der Projektleiter zeigt so auch dem Team, dass er sich für die Interessen im Projektteam einsetzt.
Parallel dazu soll der Projektleiter sicherlich auch das Gespräch mit dem Team suchen und ihnen ebenfalls die Situation darlegen.
Schlussendlich hat aber doch der Kunde das letzte Wort, er ist und bleibt König. Aber ich hatte schon oftmals das Gefühl, dass durch solche Gespräche mit dem Kunden die Wertschätzung erhöht wurde, was ja im Endeffekt positiv ist. Und nicht wenige entscheiden so auch mal zu Gunsten des Projektteams.

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.

Teil 2: Kommunikation über ein Issue Tracking System

Vielfach wird während des Projektes ein unterstützendes Tool für das Issue- oder auch für das Bug-Tracking System verwendet (Beispielsweise JIRA).
Kommt ein solches System zum Einsatz, so wird darin sehr viel Projektinformation dokumentiert. Das können beispielswese Informationen folgender Art sein:

• Ein Change Request 
• Eine neue Anforderung
• Eine Frage, die beantwortet werden soll
• Ein Fehler der behoben werden soll

Zu diesen Punkten entstehen Zusatzinformationen, die im Issue Tracking System über die Beschreibung des Issues oder über einen dazugehörigen Kommentar veröffentlicht werden.
Für diese Art von Kommunikation gibt es folgende Regeln:

• Der Kunde hat oft auch Zugriff zum Issue Tracking System und kann darin alles nachlesen. Somit sollten immer "kundentaugliche" Informationen in einem Issue stehen. Manchmal ist der Kunde auch Erfasser von Issues und verfolgt dann noch genauer den Inhalt dieses Issues.
• Jede Statusänderung sollte zur besseren Nachvollziebarkeit entsprechend kommentiert werden.
• Jeder Kommentar sollte nachvollziehbar sein. Es soll auf vorangegangene Kommentare oder auf die Beschreibung des Issues einen Bezug hergestellt werden. 
• Wie beim Mail sollten auch hier die Einträge strukturiert / formatiert sein. 
• Lange Diskussionen über die Kommentarfunktion sollten vermieden werden. Hier lieber schnell mit dem Kunden telefonieren und anschliessend das Resultat des Telefongespräches als Kommentar dokumentieren. 

Teil 1: Projektkommunikation über E-Mail

Es gibt sehr viele Quellen im Internet, die darüber berichten, wie man E-Mails schreiben soll und was die wichtigstend Grundregeln dazu sind. Ich habe mir diese Quellen für die Verfassung dieses Posts bewusst nicht angeschaut, sondern berichte hier über die gemachten Erfahrungen im Umgang mit Mails in einem Projekt.

In einem Projekt, egal ob man mit dem Kunden oder mit dem Projektteam, dem Projektauftraggeber oder mit den Stakeholdern über Mail kommuniziert sollten folgende einfache Regeln befolgt werden:

• Empfänger klar definieren
• Handlungsaufforderung aufführen
• Grund aufführen, warm der Empfänger dieses Mail erhält
• Datum bis wann etwas erledigt sein soll
• Text strukturieren für die bessere Übersichtlichkeit, insbesondere bei längeren Mails
• Bei Mails mit "kritischem" Inhalt vor dem Abschicken des Mails mit dem Empfänger telefonieren und den Inhalt mündlich besprechen. Den Empfänger also auf den kritischen Inhalt vorbereiten. 

Ein schlechtes Beispiel:

Fazit: Ein solches Mail landet bei mir relativ schnell im Papierkorb. Ich muss hier ja nichts konkretes machen.

Ein gutes Beispiel:

Wichtig ist, diese Regeln auch zu befolgen, wenn beispielsweise ein "FYI"-Mail (For your Information Mail) weitergeleitet wird. Hier soll man unbedingt reinschreiben, warum das Mail für den Empfänger wichtig ist, sonst besteht ebenfalls die Gefahr, dass das Mail schnell im Papierkorb landet, obwohl es eigentlich wichtig gewesen wäre. Es erleichtert dem Leser auch, auf einen Blick zusehen, worum es geht.

Auch soll sich der Verfasser gut überlegen, an wen das Mail verschickt werden soll. CC Mails sollten wenn möglich vermieden werden. BBC Mails sind aus meiner Sicht ein absolutes "NoGo". 

95% des Projektmanagements ist Kommunikation: Einleitung

95% des Projektmanagements ist Kommunikation, sei es gegenüber den Stakeholdern, gegenüber dem Projektteam, in Meetings, gegenüber dem Auftraggeber oder dem Linienvorgesetzten: In Projekten wird kommuniziert und das ziemlich oft auf ziemlich unterschiedlichen Kanälen. Ich werde hier eine Reihe von Posts veröffentlichen, die das Thema Kommunikation im Projekt beleuchten und die einige Tipps bei der Anwedung von verschiedenen Tools beinhalten:

• Kommunikation über E-Mails
• Kommunikation über ein Issue Tracking-System
• Kommunikation am Telefon
• Kommunikation in Meetings
• Kommunikation innerhalb des Projektteams
• Stakeholder Kommunikation

Ergänzungen und Anregungen können gerne über die Kommentarfunktion hinzugefügt werden.

Entscheidungsgrundlagen: einfach, stukturiert, übersichtlich

Der Projektleiter ist während des Projektes oft damit beschäftigt, Entscheidungen einzufordern. Oft geht es dabei um eine Scope-Änderung oder um die zusätzliche Implementierung eines Change Requests oder einer neuen Anforderung. Gerade bei Change Requests oder neuen Anforderungen ist es wichtig, eine schnelle Entscheidung seitens Auftraggeber zu haben, da solche Punkte meistens auch Auswirkungen auf den Zeit- und Ressourcenplan haben. Und je eher wir wissen, ob eine Änderung beauftragt wird oder nicht, desto schneller können wir darauf reagieren.

Damit der Auftraggeber schnell aber auch gewissenhaft entscheiden kann, sollten einfache Entscheidungsgrundlagen erstellt werden. Hier die wichtigsten Regeln dazu:

• Einfach und übersichtlich (auf einer Seite)
• Auch ohne Erläuterungen für den Leser verständlich
• Vor- und Nachteile aufführen (inklusive allfällige Mehraufwände, Terminverschiebungen oder Risiken)
• Empfehlung seitens Projektteam abgeben

Ein Beispiel, wie eine solche Entscheidungsgrundlage aussehen könnte:

Beispiel Entscheidungsgrundlage (Inhalt nur beispielhaft dargestellt)

Eine solche Vorlage hat der Projektleiter innert Minuten erstellt und kann entsprechend wiederverwendet werden. Das Resultat einer Entscheidung sollte danach selbstverständlich protokolliert werden.

Vorsicht im Umgang mit Grobkostenschätzungen

Ich habe schon oft die Situation erlebt, dass ich eine Ausschreibung auf dem Tisch liegen habe, bei dem der Kunde ein sogenanntes "Full Service" Projekt offeriert haben möchte. "Full Service" im Bereich E-Business heisst in diesem Fall: Konzeption und Design einer neuen E-Business Lösung, danach die Implementierung der Lösung und zum Schluss noch der Betrieb dieser Lösung. Dass soll nun alles in eine Offerte gepackt werden und entsprechend mit Zahlen versehen werden.

Es ist aber ziemlich schwierig, die Umsetzung einer Lösung zu schätzen, wenn noch keine Konzepte vorliegen. Hier gibt es die Möglichkeit, jeweils für die Umsetzung eine Grobkostenschätzung abzugeben, die auf Erfahrungswerten basiert. Das hat den Vorteil, dass der Auftraggeber eine Übersicht über die Kosten für die Komplettdienstleistung erhält, und wir haben die Möglichkeit, die Umsetzungskosten nach abgeschlossener Konzeption nochmals zu verifizieren.
Das klingt alles ganz gut und plausibel... ABER: Der Auftraggeber nagelt einem in der Regel auf den Betrag der Grobkostenschätzung fest und erwartet dann auch, dass die Umsetzung in diesem geschätzten Kostenrahmen durchgeführt werden kann.

Damit beginnt das Scope-Management bereits in einer sehr frühen Phase des Projektes. Hier einige Tipps, damit die Umsetzungskosten die Grobkostenschätzung nicht übersteigen:

• Der Umsetzungsaufwand kann über die Konzeption gesteuert werden. Hat der Kunde plötzlich neue Requirements oder ändert den Scope so kann bereits in der Konzeption darauf hingewiesen werden, dass das Impact auf den Umsetzungsaufwand hat. 
• Bei kleineren Budgets sollte in der Konzeption berücksichtigt werden, dass nicht die Luxusversion konzipiert wird, sondern die Version, die mit dem vorhandenen Budget auch umgesetzt werden kann. 
• Falls der Umsetzungsaufwand nach abgeschlossener Konzeption angepasst werden muss, so soll der PL genau argumentieren können, wie es zu den Mehraufwänden gekommen ist. Mehraufwände müssen für den Kunden transparent und nachvollziehbar sein.
• Hilfreich ist es, wenn man zu Beginn mit dem Kunden definiert hat, was der genaue Trade-Off des Projektes ist: Hat ein Endtermin die höchste Priorität, dann sind Kosten und Scope flexibel. Hat das Budget Priorität, dann sind Termine und Scope flexibel. Hat der Scope Priorität, dann ist das Budget und der Termin flexibel. Der Trade-Off soll während der Konzeptionsphase dem Kunden und dem Konzeptionsteam immer vor Augen gehalten werden.
• Falls während der Konzeptionsphase ein Design erarbeitet wird, so muss genau geprüft werden, dass sich im Design nicht neue Features einschleichen. Hat der Kunde nämlich Konzept und Design abgenommen, so ist das ebenfalls festgenagelt. Auch wenn auf dem Design allfällige eingeschlichene neue Features nicht konzipiert sind, erwartet der Kunde, dass er dies kriegt. Hier auch den Kunden auf den Scope aufmerksam machen.

Für den Kunden ist es natürlich immer eine bittere Pille, wenn er im Endeffekt mehr aufwänden muss. Aus diesem Grunde sind die Transparenz und die ständige Kommunikation diesbezüglich während der Konzeptionsphase extrem wichtig.

Fazit:
Grobkostenschätzung: ja, auf jeden fall anwenden, aber nur unter Berücksichtigung der oben genannten Punkte.

Die Trade-off Matrix als Kommunikationsgrundlage im Projekt

Zu Beginn eines Projektes werden in der Regel in Zusammenarbeit mit dem Kunden den Scope definiert, eine Budgetplanung und eine Zeitplanung erstellt. Oftmals tauchen bei diesen anspruchsvollen Aufgaben bereits schon erste „Konflikte“ auf:

• Der Kunde hat bereits einen Going Live Termin definiert, hat aber eine riesige Liste an Anforderungen. Der Projektleiter sieht schon heute dass diese in der verfügbaren Zeit nicht umsetzbar sind.
• Der Kunde hat ein vorgegebenes Budget. Während der Ausgestaltung des Projektplanes stellt sich aber heraus, dass es eine Feature-Liste gibt, die bis heute nicht bekannt ist und das vorhandene Budget deutlich übersteigt.
• Der Kunde möchte innerhalb von 3 Monaten eine fertige Lösung, die Ressourcen sind aber nicht vorhanden
• …

Solche Zielkonflikte tauchen immer wieder auf und es gibt eine ganz einfache Methodik, gemeinsam mit dem Kunden diese Zielkonflikte zu lösen. Und zwar mit der Trade-Off Matrix.

Trade-Off Matrix

Die Trade-Off Matrix besteht aus 3 Kriterien, die gemeinsam mit dem Kunden festgelegt werden:

• Fixed: Bei diesem Kriterium kann nichts geändert werden (Als Beispiel: Die Ressourcen/Budget sind fix.)
• Chosen: Dieses Kriterium wird gewählt, wenn beispielsweise wie in der Abbildung angezeigt, der Zeitplan höhere Priorität als die Features haben. Sprich, damit wird festgelegt, dass der Kunde bereit ist, auf einige Features zu verzichten um den Zeitplan einzuhalten
• Adjustable: Dieses Kriterium ist generell verhandelbar. Hier werden Kompromisse eingegangen um die beiden anderen Kriterien einzuhalten. 

Für die Ausfüllung dieser Matrix gibt es nur eine Regel: Jede Zeile und jede Spalte darf jeweils nur ein Häkchen haben.

Im oben aufgeführten Beispiel hat man folgendes festgelegt: Bei einem fixen Budget/Ressourcen, hat der Endtermin zweite Priorität. Die Features werden so angepasst, dass diese zum vereinbarten Enddatum und innerhalb des vorliegenden Budgets umgesetzt werden können.

Je nachdem, wie die Trade-Off Matrix ausgefüllt wird, hat das Auswirkungen auf die weitere Planung und auch auf die weitere Steuerung im Projekt. Die Matrix hilft, innerhalb eines Projektteams einen klaren Fokus zu haben. Bei Changes oder bei zusätzlichen Features kann immer wieder an die Vereinbarung erinnert werden, die zu Beginn des Projektes gemacht worden ist. Wichtig ist zu beachten, dass diese Vereinbarung alle Projektbeteiligten, auch der Projektsponsor kennt.


Weitere Informationen dazu:
Quelle 1
Quelle 2