Delegieren ist nicht immer einfach

Ein Projektleiter muss in der Lage sein, Dinge delegieren zu können. Fehlt ihm diese Fähigkeit, so kann es passieren, dass er sehr schnell mit Tasks überlastet ist und darunter leidet schlussendlich das gesamte Projekt.

Es gibt ein paar Dinge die beim Delegieren beachtet werden sollten:

Klare Aufgabenformulierung: 

Der PL muss sicherstellen, dass die Aufgabe, die delegiert werden soll, klar formuliert ist. Dazu gehört ein Briefing und vor allem ein "Lieferobjekt". Der PL soll veranschaulichen, was er als Resultat gerne hätte.

Allenfalls sind auch die Definition von "Zwischen-Lieferobjekten" resp. Reviews sinnvoll, insbesondere bei grösseren Aufgaben.

Identifikation mit dem Task: 

Der PL muss sicherstellen, dass sich derjenige, der eine Aufgabe übernimmt, sich damit identifiziert und dass die Verantwortung dafür übernommen wird.  So kann der PL auch darauf vertrauen, dass der Task auch wirklich erledigt wird. Dies kann er beispielsweise erreichen indem...:

• ...die Wichtigkeit der Aufgabe betont wird
• ...die Auswirkungen bei Nichterledigung veranschaulicht werden
• ...allenfalls Belohnung in Aussicht gestellt wird 
• ...zum Voraus gelobt wird ("Wenn Du das alles gemacht hast, bin ich sehr stolz auf Dich")

Sich zurückziehen: 

Ist der Task übergeben, so soll sich der PL bewusst zurückziehen. Ansonsten läuft er Gefahr, dass er sich trotzdem um alles kümmert und somit schlussendlich doch selbst den Task erledigt. Das ist aber genau nicht im Sinne des Delegierens. Deshalb soll er den Beauftragten einfach mal machen lassen (man hat ja Zwischenreviews definiert), auch wenn er dadurch allenfalls ins „Kalte Wasser geworfen wird“. Gerade bei grösseren Aufgaben, die einem vielleicht selbst Spass machen, muss der PL besonders darauf achten (z.B. auch bei einer Projektübergabe). 

Frühzeitige Übergabe: 

Wie alles in einem Projekt, sollte auch das Delegieren geplant sein. Derjenige der die Aufgabe übernimmt, soll genügend Zeit erhalten, sich sorgfältig einzuarbeiten, sodass er sich auch angemessen um die Aufgabe kümmern kann. In der Praxis ist das natürlich der Idealfall. Meistens muss man Dinge ja delegieren, wenn etwas Unvorhergesehenes passiert ist und deshalb bleibt auch keine "Planungszeit" übrig. Trotzdem sollte der PL versuchen, auch wenns hektisch ist, diese Dinge zu beachten. 

In diesem Post gibt es noch weitere Tipps.

Projektmanagement auf dem Weg ins Web 2.0

Kürzlich durfte ich an der SPM Frühjahrstagung ein Referat über Web 2.0 und Projektmanagement halten. Hier die Präsentation dazu: 

Projektmanagement 2.0 - Erfolgreicher Einsatz von Web 2.0 im Projektmanagement

View more presentations from Nina Braschler.

Wichtigste Erkenntnisse:

• Projektmanagement erfährt unter dem Aspekt Web 2.0 eine Veränderung in der gesamten Projektkommunikation
• Web 2.0 im Projektmanagement schafft Transparenz
• Web 2.0 im Projektmanagement eliminiert E-Mails
• Web 2.0 im Projektmanagement schafft Projektidentität

Quelle: Namics Blog

Fortschrittskontrolle - was der PM berücksichtigen sollte

Wie messe ich den Fortschritt in meinem Projekt? Eigentlich eine tägliche Arbeit des Projektleiters, allerdings eine nicht ganz anspruchslose Aufgabe.
Der Projektleiter muss sich bei der Fortschrittkontrolle (wie bei der gesamten Projektsteuerung auch) sich im Klaren sein muss, was der Trade-Off des Projektes ist. Darauf aufbauend soll auch die Fortschrittskontrolle gemacht werden.

Aus meiner Sicht gibt es folgende Grundregeln, die bei der Fortschrittskontrolle zwingend gemacht werden sollte:

Ganzheitliche Fortschrittskontrolle
Für eine zuverlässige Aussage über den aktuellen Projektstand. müssen immer alle Dimensionen (Kosten, Termine und Leistung) berücksichtigt werden sollen. Dem Auftraggeber hilft es wenig, wenn ihm mitgeteilt wird, dass für das Arbeitspaket X 5 Tage aufgelaufen sind. Wenn er aber gleichzeitig weiss, dass das Arbeitspaket zur Hälfte fertig gestellt ist und dass es planmässig abgeschlossen werden kann, ist das um einiges aussagekräftiger.

Prognosen erstellen
Dies ist integrierender Bestandteil der Fortschritssmessung: Je nach Trade Off muss der Projektleiter eine zuverlässige Aussage über die Endkosten, resp. Endtermin des Projektes machen können. Gerade bei fixen Kosten (oder Terminen) muss er wissen, ob mit dem bereits geleisteten Umfang des Projektes die Kosten oder der Termin gehalten werden kann. Kann er dies nicht bestätigen, so muss er entsprechend steuern. Entsteht ein Mehraufwand, gibt es zwei Methoden die hilfreich sind:

• Additiv
  Der Projektleiter zählt den zum Zeitpunkt x angefallenen Mehraufwand zur Kostenschätzung, resp. Endtermin des AP’s hinzu. Diese Methode kann dann angewendet werden, wenn der Projektleiter davon ausgeht, dass der angefallene Mehraufwand einmalig ist (beispielsweise auf Grund einer einmaligen Einarbeitung eines weiteren Projektmitarbeiters).

• Linear
  Hier zählt der Projektleiter den angefallenen Mehraufwand auf sämtliche folgende Arbeitsschritte bis zur Fertigstellung des Arbeitspaketes hinzu. Diese Methode wendet der Projektleiter an, wenn er sieht, dass der angefallene Mehraufwand sich wiederholen wird (beispielsweise wenn ein Projektmitarbeiter regelmässige Unterstützung eines Experten benötigt).

Transparente Kommunikation gegenüber dem Auftraggeber ist hier unabdingbar, insbesondere dann, wenn es eine Planabweichung gibt (Vgl. Post über Verhandlung und Projektleitung)
 

Nicht nur auf Zahlen fixieren:
Wichtig ist, dass sich der Projektleiter nicht nur auf die Zahlen fixiert, sondern auch das persönliche Gespräch mit dem Projektteam wie auch mit dem Auftraggeber sucht. Insbesondere bei einer Abweichung sollte der Auftraggeber informiert werden. Es soll ihm aufgezeigt werden, was man tun kann, damit das ursprünglich vereinbarte Ziel dennoch erreicht werden kann. Das ist schlussendlich eine Teamarbeit, die von allen Teammitgliedern Kreativität und Mitdenken erfordert.

Der Projektleiter darf auch mal "Nein" sagen

Ich wurde kürzlich gefragt, wie man lernt, "Nein" zusagen. Ehrlicherweise hatte ich keine Antwort auf diese Frage. Vielleicht liegt das im Naturel der Person, dass man selbst merkt, wenns genug ist, und wann man "Stopp" sagt. Trotzdem kann ich ein paar einfache Tipps mitgeben, die das "Nein" sagen aus Projektsicht allenfalls erleichtern.

1. Erkenntnis 
Bevor man überhaupt "Nein" sagen kann, muss der Projektleiter erkennen, dass für einen zusätzlichen Auftrag, Task oder Meeting nun wirklich keine Zeit (oder auch kein Budget) mehr übrig ist. Fehlt diese Erkenntnis, ist der Projektleiter gar nicht in der Lage, etwas zurückzuweisen. Um diese Erkenntnis zu erhalten, muss der Projektleiter den Projektumfang, den Fortschritt, die Abmachungen etc. sehr gut kennen. Eine saubere Dokumentation der Entscheide, des Scopes etc. ist hierfür zwingende Voraussetzung.

2. Sachliche Begründung
Der Projektleiter ist eigentlich immer in der "konfortablen" Situation, dass nahezu alles sachlich in den Dimensionen Kosten, Termine und Leistung (das Magische Dreieck) ausdiskutiert und begründet werden kann. Kommt der Projektauftraggeber mit einem zusätzlichen Auftrag oder einer zusätzlcihen Anforderung, so muss der Projektleiter sich sofort über folgendes Gedanken machen:

• Welche Auswirkungen hat das auf meinen Endtermin?
• Welche Auswirkungen hat das auf das Budget?
• Welche Auswirkungen hat das auf den Rest des Projektumfangs? (Birgen sich darin allfällige Risiken, die andere Leistungen/Funktionen massiv beeinträchtigen?)

3. Die Entscheidung zum "Nein" verlagern
Kann oben genannte Begründung dem Auftraggeber veranschaulicht werden, so erreicht der Projektleiter eine Verlagerung des Entscheides. Die Entscheidung, ob nämlich allenfalls der Termin nicht gehalten werden kann, oder das Budget erhöht werden muss oder ob das Risiken mit sich bringt, liegt beim Auftraggeber und nicht mehr beim Projektleiter. Trotzdem ist es hilfreich, wenn der Projektleiter hier eine Empfehlung abgeben kann. Sind nämlich die notwendigen Mittel vorhanden, so braucht es allenfalls gar keine Zurückweisung.

4. Es darf nicht endlos weitergehen
Nichts desto Trotz braucht es irgendwann ein (Projekt)-Ende. Für das Projekt ist es nicht immer von Vorteil, wenn ständig noch was dazu kommt, auch wenn dafür das notwendige Zeit- und Kostenbudget zur Verfügung gestellt wird. Der Projektleiter soll sicherstellen, dass der Projekt kein "Endlosprojekt" wird und entsprechend dagegen steuern. Dies kann er ebenfalls mit einer Argumentation hinsichtlich der Risiken sicherstellen.

5. Ein "Nein" gegenüber dem Vorgesetzten oder dem Projektteam
"Kannst du nicht noch schnell den Task erledigen und die Dokumentation fertig schreiben?" "Kannst Du nicht schnell in einer Stunde das Projekt vor der Geschäftleitung vorstellen?" Auf den Projektleiter treffen täglich unvorhergesehene Aufgaben. Klare Arbeitspriorisierung ist Voraussetzung, dass alle Aufgaben seriös gemacht werden können. Genau wie beim Auftraggeber auch, muss der Projektleiter auch gegenüber dem Team und dem Vorgesetzten argumentieren, warum eine Aufgabe nicht zum gewünschten Zeitpunkt erledigt werden kann, oder wenn eine andere wichtigere Aufgabe unter der sofort angeforderten Aufgabe leidet. Transparente Darstellung der eigenen Tasks und entsprechende Argumentation helfen hier.

Hilfe in meinem Projekt stimmt die Qualität nicht mehr

Diese Situation ist nicht neu: Ein grösseres Softwareentwicklungsprojekt wurde mit einer 10 köpfigen Mannschaft begonnen. Man hat gute Fortschritte gemacht, der Auftraggeber ist mit den ersten Resultaten zufrieden. Alle Entwicklungstasks sowie die internen Test sind nahezu abgeschlossen, das Projekt neigt sich dem Ende zu. Längst können nicht mehr alle 10 Team Mitglieder beschäftigt werden sondern diese sind teilweise bereits wieder in anderen Projekten tätig. Plötzlich merkt der Projektleiter, dass die Qualität im Projekt nicht mehr stimmt. Wann die Fehler aufgetreten sind, ist an dieser Stelle gar nicht mehr wichtig, sondern viel mehr, was der Projektleiter in einer solchen Situation tun kann, respektive wie er solche Situationen vermeiden kann:

1. Das Team bleibt bis zum Schluss ein Team
Obwohl das Projektteam nicht mehr ausschliesslich für dieses Projekt arbeitet, bleibt es bis zur Projektabnahme ein Team. Es kann durchaus sein, dass einige Leute auf anderen Projekten arbeiten und nahezu nicht mehr für das eigene Projekt tätig sind, dennoch muss der Projektleiter sicherstellen, dass die Informationen an alle Team Mitglieder verteillt werden. Statusmeeting, oder persönliche Updates an Leute, die keine konkrete Tasks mehr haben sind unerlässlich. Und warum?

• Der Entwickler soll bis zum Schluss für seine Komponenten verantwortlich sein und wenn möglich auch darin gefundene Fehler beheben. Wenn er sich jedesmal für eine Fehlerkorrektur komplett neu orientieren muss, so dauert das unter Umständen viel zu lange. Ist er aber informiert, was im Projekt gelaufen ist, so kann er geziehlt mit der Fehleranalyse beginnen. 
• Wird die Verantwortung plötzlich abgegeben, so müssen andere Personen die Fehler glatt ziehen. Das ist nicht im Sinne eines Teams, in dem jeder seine Verantwortung übernommen hat.
• Wird das Team Mitglied nicht mehr informiert, verliert es sehr schnell die Motivation. Selbst wenn dann Fehler behoben werden müssen, wird dies allfällig lieblos und ohne ausführliches Testing / Review erledigt.  

Wenn ein Team Mitglied gar keine Zeit für das Projekt mehr hat, so muss der Projektleiter eine saubere Übergabe an einen anderen Entwickler sicher stellen, damit dieser die Verantwortung über die entsprechende Komponente übernimmt.

2. Nach den ersten Erfolgen darf die Qualitätssicherung nicht vernachlässigt werden
Ist der Auftraggeber mit den bisherigen Leistungen zufrieden, besteht sehr schnell die Gefahr, keine ausführliche Qualitätssicherung mehr zu machen wie bis anhin. Das Vertrauen des Auftraggebers hat man ja durch die ersten Erfolge für sich gewonnen. Sehr schnell kommt jetzt die Denkweise "die können ja auch mal testen" auf. Das ist kontraproduktiv und nicht sinnvoll. Code Reviews, Überprüfung der Code Qualität ist auch in einer späteren Phase des Projektes unerlässlich. Durch eine schnelle Fehlerkorrektur können sich auch schnell Folgefehler einschleichen. Darunter leidet die (Code) Qualität zwangsläufig. Ein sorgfältiges Retesting der Fehlerkorrektur durch Entwickler und Tester ist in dieser Phase besonders wichtig.

Das hier Beschriebene klingt sehr stark nach dem "Idealfall". Mir ist bewusst, dass oftmals weder Zeit noch Budget für eine ausführliche Qualitätssicherung resp. für regelmässige Updates im gesamten Projektteam vorhanden ist. Dennoch soll sich der Projektleiter der Thematik bewusst sein und früh gegen dieses Problem steuern.

Teil 6: Stakeholder Kommunikation

Über Stakeholder und Stakeholderkommunikation gibt es gute theoretische Grundlagen, wie beispielsweise die Stakeholderanalyse oder die Kommunikationsmatrix. Ich möchte in diesem Post nicht diese theoretischen Grundlagen erläutern oder nochmals wiedergeben, sondern viel mehr beschreiben, was man nebst diesen Methoden als PL für die Kommunikation mit den Stakeholdern verwenden kann. 

Für die gezielte Kommunikation mit den Stakeholdern ist eine ausführliche Stakeholderanalyse unerlässlich. Auch wird der Projektleiter vermutlich zu Beginn des Projektes sich überlegt haben, welche Stakeholdergruppen wann wie und worüber informiert werden (Kommunikationsmatrix). Aber hat man mit einer sauberen Analyse und den entsprechenden Reports die Stakeholder wirklich im Boot?

Persönliche Kommunikation als wichtigste Ausgangslage für die Stakeholderkommunikation:

Ich glaube, dass bei der Kommunikation mit den Stakeholdern genau wie beim Projektteam die persönliche Kommunikation eine ebenso wichtige Rolle spielt. Je nach Stakeholder vielleicht nicht in der Intensität wie innerhalb des Teams, aber von Zeit zu Zeit ein Anruf oder bei einen gemeinsamen Kaffee zu plaudern schadet nichts. Dies aus folgenden Gründen:

• Stakeholder, die nicht so nah am Projekt sind, haben oft gar keine Zeit, alle Reports zu lesen und zu verstehen, die ihnen einmal im Monat zugeschickt werden. Da hier keine tägliche Kommunikation stattfindet, vergisst man oft den Zusammenhang. Hilfreicher sind hier Projektpräsentationen, bei denen in der Pause auch mal das persönliche Gespräch gesucht werden kann.
• Im persönlichen Gespräch kann der Projektleiter mit gezielten Fragen eher herausfinden, wo allenfalls der Schuh drückt, als in einer Einwegkommunikation.
• Im persönlichen Gespräch hat der Stakeholder die Möglichkeit Fragen zu stellen und das ist für den Projektleiter die ideale Möglichkeit falsche Annahmen aus dem Weg räumen.
• Es ist besser möglich, im persönlichen Gespräch das Vertrauen eines Stakeholeders zu gewinnen. Der Stakeholder kennt danach das „Gesicht“ hinter demjenigen, der regelmässig Reports schickt. Und wer weiss, vielleicht werden diese Reports dann doch angeschaut ;o)

Es ist klar, dass in einem grossen Projekt nicht jeder einzelne Stakeholder persönlich durch den Projektleiter betreut werden kann. Aber der Projektleiter könnte im Projekt jemanden bestimmen, der für die Stakeholderkommunikation verantwortlich ist. Diese Person entscheidet dann auch, wann der Projektleiter dabei sein soll/muss.

Ohne Zuhören läuft im Projekt gar nichts

Zuhören ist eine der wesentlichen Eigenschaften, die ein Projektleiter mich sich bringen muss. Es ist natürlich noch besser, wenn auch alle Team-Mitglieder zuhören können, aber diese Voraussetzung ist nicht immer gegeben. Umso wichtiger, dass der Projektleiter mit gutem Beispiel voran geht.

Warum Zuhören für das Projekt und für das Team wichtig ist:
Der Projektleiter ist weit mehr als nur der Terminkoordinator, Kosten- und Leistungsüberwacher. Der Projektleiter soll auch auf die Bedürfnisse im Team eingehen. Auch wenn der Projektleiter nicht immer für alles eine Lösung griffbereit hat, soll er als zentraler Ansprechpartner für alle fungieren. Das kann er durch Zuhören erreichen und damit, indem er jeden einzelnen eingeht. Der Projektleiter muss erreichen, dass er eine Vertrauensperson wird. Es reicht, bei einem Kaffee einfach mal zuzuhören und sich voll und ganz dem Team-Mitglied zuwidmen.
Darüber hinaus sollte der Projektleiter erreichen, dass nicht nur er selbst zuhört, sondern auch das Team einander zuhört. Vielfach gehen nämlich Dinge vergessen oder werden falsch interpretiert, weil das Team nicht richtig zugehört hat.
Wenn der Projektleiter und auch das Team einander nicht zuhören, grenzt das für mich persönlich an Respektlosigkeit. Und das ist vermutlich eine der schlimmsten Gegebeneheiten, wenn man in einem Team ein Ziel erreichen will.

Wie der Projektleiter das Zuhören bei sich selbst und auch im Team fördern kann:

• Regelmässige Feedbackrunden machen. Raum für Kritik (auch an den Projektleiter selbst) schaffen
• Als gutes Beispiel vorangehen, selbst immer aktiv zuhören. 
• Meetings moderieren und Regeln einführen: Handy, Notebooks etc. sind ein absolutes NoGo während einem Meeting. Darauf hinweisen und um Aufmerksamkeit bitten, auch wenn jemand anders spricht.
• Persönliche Gespräche mit den einzelnen Team Mitglieder führen, sich Zeit nehmen für deren Bedürfnisse. Dabei sich nicht von anderen Tasks ablenken lassen
• Den Austausch zwischen den Team Mitglieder fördern und aktiv einfordern, z.B. gegenseitiger Review von entwickelten oder konzipierten Komponenten, fachlicher Austausch nach dem Statusmeeting. Dabei achten, dass die "Kommunikationsregeln" eingehalten werden.

Mehr zum Thema "aktives Zuhören"
- Aktives Zuhören
- Begriffsdefinition

Puffer in der Projektabwicklung

Puffer sind ein wichtiges Element in der Projektabwicklung. Sie dienen dazu, allfällige Risiken im Vorfeld zu minimieren. Auf dieser Seite habe ich eine plausible Einteilung von verschiedenen Puffer-Arten gelesen. Diese Einteilung nehme ich hier gerne auf und ergänze die Punkte mit meinen Erfahrungen. 

1. Zeitliche Puffer

Diese sind am meisten verbreitet und können in der Planungsphase relativ einfach den einzelnen Tasks oder den Meilensteinen zugeordnet werden. Diese Puffer sollten aber bereits in der Offerte oder bei Termindefinitionen im Projektvertrag berücksichtigt werden. Vielfach ist es so, dass sich zeitliche Puffer automatisch einschleichen, beispielsweise auf Grund von definierten Terminen: Meistens muss ein Termin zwischen allen Projektbeteiligten gefunden werden und bis alle an einem Tisch sitzen, sind gerne zwei oder drei Wochen vergangen. Diese Zeit kann aber bereits für die Projektarbeit genutzt werden.

2. Finanzielle Puffer

Diese werden insbesondere dem Kunden gegenüber nicht als solche genannt. In der Regel wird hier versucht, in der Kalkulation Tasks aufzuführen, welche plausibel klingen, in Wirklichkeit aber keinen oder nur sehr wenig Aufwand mit sich bringen. Hat man das während der Offertphase versäumt, besteht die Möglichkeit, bei allfälligen auftretenden Change Requests einen finanziellen Puffer einzubauen.   

3. Qualitative Puffer

Diese Puffer bewegen sich schon stark in Richtung Change Management. Meistens möchte der Kunde noch Nachbesserungen, obwohl aus unserer Sicht das Projekt gemäss dem definierten Umfang abgeschlossen ist. Auch hier soll der PL stets einen Trumpf im Ärmel haben. Dies kann er erreichen, wenn er beispielsweise eine "Luxus-Lösung" vorantreibt, dem Kunden aber erstmal nur die vereinbarte "Normal-Lösung" präsentiert. Allfällige Nachlieferungen können so unter Umständen schnell erledigt sein. Auch kann er beispielsweise technische Risiken präventiv behandeln. Wenn dann das Risiko tatsächlich auftritt, hat man schon eine Lösung parat.

Wichtig ist, insbesondere dann, wenn die Puffer nicht gebraucht werden diese in Joker umzuwandeln und zum richtigen Zeitpunkt auszuspielen. So kann dem Kunden überraschend einen grossen Mehrwert geboten werden. Aus Projektsicht war dies dann aber kein Mehraufwand, da dies schon zu Beginn eingeplant wurde.

Mehr zum Thema

http://www.projektmagazin.de/glossar/gl-0418.html

Ein Angebot erstellen will gelernt sein.

Bei der Erstellung eines Angebotes muss der Projektleiter (oder derjenige, der das Angebot erfasst) den Scope des Projektes sehr genau kennen. Meistens sind die Angebote und der darin aufgeführte Scope die Basis des Projektes und oftmals ist das Angebot auch integrierender Bestandteil des Projektvertrages.

Der Projektleiter (beispielsweise auf Agenturseite) soll ein Angebot also sehr sorgfältig schreiben. Aus meiner Sicht soll in einem Angebot zwingend jedes Arbeitspaket mit den folgenden Attributen versehen werden:

• Kurze Beschreibung des Arbeitspaketes (was soll in diesem Arbeitspaket gemacht werden)
• Aufgaben Dienstleister (Aufzählen, was der Dienstleister (also wir) zur Erfüllung des Arbeitspaketes beiträgt, diese Aufgaben wenn möglich beziffern oder genau beschreiben, beispielsweise Auflistung der Funktionen, die spezifiziert werden)
• Aufgaben Kunde (Aufzählen, was der Kunde zur Erfüllung des Arbeitspaketes beitragen soll)
• Deliverable (Beschreiben, was tatsächlich am Ende vorliegt, was der Kunde bekommt, z.B. HTML Files)
• Abgrenzungen (Beschreiben, was ein Arbeitspaket nicht beinhaltet, beziehungsweise was nicht Teil des Angebotes ist)
• Optional: Vorgehen (Beschreibung der Art und Weise, wie ein Deliverable erarbeitet wird (z.B. Erarbeitung der Anforderungsspezifikation in 3 Workshops). 
• Aufwand (Selbstverständlich muss der Aufwand seitens Dienstleister beziffert werden)

Natürlich gehören in ein Angebot noch weitere Elemente, aber die Scope-Definition ist vermutlich der zentrale Teil des Angebotes. Wenn dieser von Anfang an klar definiert ist, weiss der Kunde auch, was er am Ende kriegt (insbesondere durch die Aufzählung der Deliverables). Wenn die Anforderungen des Kunden nicht klar definiert ist, sodass kein umfängliches Angebot erstellt werden kann, so sei auf die Grobkostenschätzung verwiesen.
Werden Angebote ohne Scope definiert so kann das schon zu Beginn des Projektes einige unangenehme Folgen mit sich ziehen:

• Ein "schwammiges" Angebot zieht vermutlich einen "schwammigen" Projektvertrag mit sich. Dies kann sich weiter bis hin zu einer "schwammigen" Spezifikationen ziehen.
• Scope-Diskussionen sind vorprogrammiert und der Projektleiter kann sich nicht auf eine klar definierte Vereinbarung stützen.
• Das Vertrauen zwischen Kunde und Dienstleister kann sehr schnell zerstört werden, da der Kunde nicht das Gefühlt hat, dass er das kriegt, was er "bestellt" hat. 

Der Wochenreport

Ich habe schon in vielen Berichten auf den Wochenreport verwiesen, diesen aber noch nie wirklich in einem Beitrag vorgestellt. Das möchte ich nun nachholen.

Der Wochenreport ist ein Kommunikationsmittel, um die Projektbeteiligten und die Stakeholder über den Status des Projektes zu informieren. Aus meiner Sicht müssen im Wochenreport folgend Themen behandelt werden:

Informationen über die Kosten:
Der Leser soll einen überblick über die Kosten erhalten. Idealerweise liegen ihm folgende Informationen vor:

• Wie hoch ist das Gesamtbudget?
• Welche Kosten sind bereits angefallen?
• Welche Kosten sind bereits verrechnet worden?
• Wie hoch ist das Restbudget?

Der Detaillierungsgrad kann hier variieren, bei Projekten mit dem Trade-Off Budget würde ich  beispielsweise die Kosten auf Arbeitspaketebene aufführen.


Informationen über die Termine:
Der Leser soll über die Termine und über den groben Projektplan informiert werden. Es soll ersichtlich sein, wann welche Arbeitspakete auf der Zeitachse abgeschlossen werden.

Informationen über die Leistung:
Es soll aufgeführt sein, wieviel eines Arbeitspaketes bereits geleistet wurde und wie viel noch zu leisten ist. Auch soll angegeben werden, wie hoch die Abweichung von den Plandaten und den effektiven Daten (Kosten, Termine) ist. So hat der Leser bereits in einer frühen Phase eine Übersicht, welche Arbeitspakete tendenziell über Budget ist und wo allenfalls noch Luft ist.

Beschreibung des Projektstatus:
Die oben genannten Punkte wären mal der formale Teil. Das lässt sich übrigens sehr gut in einem Excel mit ein paar netten Grafiken darstellen.
Was aus meiner Sicht aber genau so wichtig ist, ist der Text-Teil, wo in Worten über die Kosten, Termine und Leistungen berichtet wird. Es besteht zwar die Gefahr, dass dann das, was in den Grafiken wiedergegeben wird, nochmals erklärt wird, aber meine Erfahrungen zeigen, dass dies meistens effizienter ist. Im Textteil wird auf Risiken und auf deren Auswirkungen aufmerksam gemacht, hier wird erklärt, wenn ein Change Request beauftragt wurde und deshalb das Kostendach erhöht wurde, hier werden Entscheidungen dokumentiert und es werden auf die wichtigsten Issues (welche allenfalls in einem Issue-Tracking System verwaltet werden) verwiesen.

Formale Abnahme des Wochenreports:
Wichtig ist: der Kunde soll den Wochenreport formal abnehmen. Dazu gibt es unterschiedliche Möglichkeiten. Idealerweise trifft sich der Projektleiter auch einmal die Woche mit dem Kunden und bespricht den Wochenreport persönlich.
Mit der formalen Abnahme gewinnt der Wochenreport mehr Gewicht und wird dadurch ein wichtiges Kommunikationsmittel im Projekt.