28. Oktober 2010

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. 

25. Oktober 2010

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". 


22. Oktober 2010

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:
Ergänzungen und Anregungen können gerne über die Kommentarfunktion hinzugefügt werden.

19. Oktober 2010

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.

17. Oktober 2010

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.

14. Oktober 2010

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