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.