Budget at Complete (BAC)
Auch dieser Begriff ist aufgeladen mit Missverständnissen. Denn klar ist, dass es alleine wegen des Worts Budget um Geld geht. Und wenn man es genau nimmt geht es auch um Geld, dass vom Projekt verbraucht werden darf. Allerdings liegt das Missverständnis eben darin, dass es oft als Geld begriffen wird, was jemand in der Hierarchie oder Linie der Organisation bereitstellt. Zumeist ohne genaue Kenntnis dessen, was etwas wirklich kostet. Das BAC steht dann fest, wenn ein Plan angenommen wird. Oder, wenn die Änderung des Plans (Change Request (CR)) angenommen wird. Ein CR verändert das Budget. Das hören zwar die Controller in der Firma ungern, dem ist aber so.
Ebenso wichtig ist es, dass in einem Plan, der einen BAC ausweißt, alle Kosten aufgenommen werden, die das Projekt zu verantworten hat. Wenn also Zukäufe in der Verantwortung des Projekts liegen müssen auch diese ausgewiesen und in der WBS abgelegt werden. Wenn dem Projekt Kosten wie Räume, Telefon, Rechnernutzung, Entgelte für die Nutzung von Tools berechnet werden, müssen auch diese benannt sein.
Das Projekt, zumeist in der Person des Projekt Managers, ist letztlich genau diesem monetärem Wert verpflichtet. In dem Dreieck von Scope, Time und Budget ist der BAC zu 100% das Budget.
Um dies zu veranschaulichen, kommen wir auf ein Beispiel, was uns weiter begleiten wird und ein stark vereinfachtes Projekt nachbildet:
Als Besitzer eines schönen Ferienhauses, das auf einem Grundstück von 10m * 10m steht, planen Sie um das Grundstück herum eine Mauer zu bauen. Ein Unternehmen bietet Ihnen als Kostenvoranschlag dies an als Time & Material. Richtwert sind € 100,- pro laufendem Meter Mauer als Material und Arbeitsleistung. Sie nehmen an, und da sie 40 Meter Mauer bauen wollen, ist Ihr BAC damit bei € 4000,-.
Natürlich würden Sie als guter PM diesen Auftrag als Gewerk und zum Festpreis vergeben. Aber dann würde es für mich schwerer dies als Beispiel zu verwenden J
Und noch etwas wissen Sie damit aus der Definition des Earned Value (EV): Wenn die Mauer so fertig gestellt ist, werden Sie einen EV von € 4.000,- haben. Denn das ist es Ihnen ja auch wert!
Eines muss noch dringend erwähnt sein: Der BAC gilt auf jeder Ebene der WBS bis runter zum Arbeitspaket. Wenn also geplant ist, dass ein AP 4 PT à 500,- kostet, so ist dies der BAC des Arbeitspakets. Diese Sichtweise ist im Rahmen der EVA enorm wichtig, da sie es erlaubt sehr granular ein Projekt zu betrachten. Der BAC wird auf den Ebenen der WBS kumuliert, bis man auf der obersten Ebene den BAC für das gesamte Projekt erhält (Buttom up).
Aber auf hier Beispiele aus der realen Welt der Projekte:
1. Komplettes Projekt (mit eindeutiger Spezifikation)
Das Projekt ist es die Serverlandschaft zu erneuern. Sowohl die Spezifikation der einzelnen Maschinen ist klar als auch das es einen 1:1 Umzug der Applikationen und Services geben soll. Aus der Erfahrung hat der Auftraggeber (Sponsor) bei seiner Firma für Neubeschaffung, Aufbau, Konfiguration und Umzug € 2.000.000,- errechnet und sich das Budget in dieser Höhe genehmigen lassen. Nach der Initialisierung des Projekts beginnt die erste Planung. Unter Beachtung allen Aufwands (d.h. auch Meetings, PM-Kosten, Reisen, Dokumentation, Risiken etc.) kommt der PM auf Kosten von € 1.880.000,-. Mit diesem Plan geht er zum Sponsor und lässt sich den Plan genehmigen. Obwohl der Sponsor das Budget von 2 Mio Euro hat, ist von nun an das BAC des Projekt Managers 1,88 Mio Euro. Egal, wieviel Geld der Sponsor wirklich bereit gestellt bekommen hat.
2. Iteratives Projekt
Nehmen wir an, die oben genannte Aufgabe soll in Iterationen (z.B. nach Fachbereichen) durchgeführt werden. In diesem Fall würde die WBS auf der ersten Ebene sich in die einzelnen Iterationen Teilen. Die Aufgaben würden werden auf die einzelnen Iterationen verteilt. Dadurch ist weiter auf der obersten Ebene der BAC des gesamten Projekts, in der Ebene darunter der BAC der einzelnen Iterationen. Somit ist ersichtlich wie teuer jede Iteration ist und gegen diesen Wert kann die Durchführung der Iteration überwacht werden.
3. Agiles Projekt (ohne eindeutige Spezifikation)
Bleiben wir immer noch bei der Erneuerung der Serverlandschaft. Hier soll in kurzen Phasen gemäß der Periodisierung die Server ersetzt werden. Auch steht vielleicht noch nicht genau fest, wie viele Systeme wirklich betroffen sind. Aber auch hier ist es nicht schwer den BAC zumindest für die einzelnen Sprints zu ermitteln. Denn am Anfang des Sprints steht ja immer die Festlegung, was in einem Sprint umgesetzt werden kann/muss. Damit erhält jeder Sprint seinen BAC und kann mit diesem während seiner Umsetzung controlled werden. Nicht möglich ist es allerdings einen gesamten BAC auf das Projekt zu entwickeln, wenn der Umfang nicht bekannt ist. Sollten die Mittel des Auftraggebers eben bei 2 Mio. begrenzt sein, wäre an dieser Stelle eben dann Schluss mit dem Projekt oder es müssen weitere Mittel nachgeschoben werden. Die ist aber eines der Grundthemen von agilen Projekten.
Wer jetzt denkt, dass der BAC ein über die Laufzeit eines Projekts fester Wert ist, der irrt an dieser Stelle. Grade dies wird von den vehementen Verteidigern der agilen Vorgehensmodelle immer wieder als Argument gegen Projekt Management Methoden verwendet. Denn immer wenn es zu einem CR kommt, wird dieser mit hoher Wahrscheinlichkeit einen Einfluss auf das Budget haben. Nicht immer, denn es gibt auch Kostenneutrale CR. Aber wenn ein CR angenommen wird, der nicht Kostenneutral ist, entsteht ein neuer aktualisierter BAC, also eine neue Kosten-Baseline. Dies ist natürlich bei agilem Vorgehen nicht der Fall, da sich der BAC lediglich Sprint für Sprint ergibt.