Project Management Beyond Budgeting

Im klassischen Projektmanagement wird vor allem Termin- und Budgettreue belohnt. Doch ist das der richtige Anreiz für einen Projektmanager, das Projekt zum Erfolg zu führen?

Bereits bei der Budgetplanung eines Projekts bauen die Projektmanager erhebliche Puffer ein, um einer Budgetkürzung zuvor zu kommen und noch immer genügend Mittel für die Umsetzung des Projekts zur Verfügung zu haben. Schon hier beginnen die Probleme des Budgeting. D.h. mehr als wirklich notwendigen Mittel werden einem Projekt zugeschrieben und können so nicht anderweitig eingesetzt werden. Der Projektmanager steht nun vor einem Dilemma: nutzt er – trotz höherer Angaben zum Bedarf – nur den wirklich notwendigen Teil seines Budgets, muss er sich anschließend dafür rechtfertigen, warum er nicht richtig geplant hat und warum das Projekt im Endeffekt günstiger als angedacht war. Im schlimmsten Fall stehen ihm nun für folgende Projekte generell weniger Mittel in seinem Budget zur Verfügung.

Um diesem Problem zu entgehen und die Budgetvorgaben genauestens zu erfüllen, werden also unnütze und überflüssige Ausgaben getätigt – nur um das Budget wie geplant auszuschöpfen. Doch worum geht es eigentlich? Um die wesentliche Zielerreichung innerhalb des Projekts, oder um die exakte Ausschöpfung des Budgets? Es ist sicher eindeutig, dass die Zielerreichung von deutlich höherer Priorität ist.

Daher sollte man den Projektmanagern bei der Planung ihrer Budgets die Angst nehmen, dass eine niedrigere Budgetplanung als beim vorigen Projekt eine unmittelbare Auswirkung auf folgende Projekte hat. Jedes Budgetplanung sollte für sich betrachtet werden und innerhalb der aktuellen Begebenheiten. Nur so kann man davon ausgehen, ehrlichen Angaben zur Budgetbedarfsplanung zu bekommen. Projektmanagern sollten zudem andere Anreize gegeben werden, um maximale Ergebnisse bei minimalen Kosten und minimaler Zeit zu erzielen.

Und wie können diese Anreize aussehen? Wie wäre es, wenn man einem Projektmanager das Angebot unterbreitet, dass er 10% von den Einsparungen aus seinem Budget als Bonus erhält? D.h. der Projektmanager veranschlagt beispielsweise ein Budget von 1 Mio. EUR. Wenn er es nun schafft, die Kosten so gering zu halten, dass er von diesem Budget nur 900.000 EUR effektiv nutzt, dann erhält er einen Bonus von 10.000 EUR. Im Gegenzug müsste natürlich auch ein Malus vereinbart werden, für den Fall, dass er das Budget überzieht.

Wäre das ein attraktiver Anreiz, um die bekannte Budgetierungsproblematik zu umgehen? Vielleicht! Denn auch hier müssen mögliche Schlupflöcher für ein opportunistisches Verhalten im Vorwege gestopft werden. Dies bedeutet, dass der Projektmanager von einem Kontrollgremium, einem Lenkungskreis überwacht und kontrolliert werden muss, um so sicher zu gehen, dass er nicht bereits bei der Budgetfestlegung ein zu hohes Budget angibt, um dann im Nachhinein einen größeren Bonus zu erhalten. Dieser Lenkungskreis muss sich also gut mit den marktrelevanten Daten auskennen, um so beurteilen zu können, ob der Projektmanager realistische Zahlen vorlegt.

Doch auch während des Projekts sollte ein Lenkungskreis stets die Arbeit überwachen. Nur so kann sichergestellt werden, dass die Kosten nicht mit unlauteren Methoden reduziert werden und der Projektmanager mit diesen Methoden zu seinem Bonus gelangt.

Doch wir wollen einem Projektmanager gar nicht so viel Opportunismus unterstellen. Wir brauchen aber eine Alternative zum bisherigen Budgeting-Prozess, die attraktiv für alle Seiten ist. Nur so können wir die Kosten für unser Unternehmen senken und den Projektmanagern die Angst nehmen, für Folgeprojekte nicht mehr genügend Ressourcen zur Verfügung gestellt zu bekommen. Denn die Budgetierung erfolgt hier für jedes Projekt neu und völlig frei von den vorhergegangenen Projekten.

Eine Alternative könnte Folgendes darstellen: Die Planung des Budgets erfolgt von unabhängigen Planern. Da diese lediglich die Aufgabe haben, einen Kostenplan für das Projekt zu erstellen und weder Vor- noch Nachteile zu erwarten haben, wenn der Plan nicht eingehalten werden kann, gibt es für diese keine Anreize überflüssige Reserven einzuplanen. Dieser Plan kann nun an den Projektmanager übergeben werden. Sollte er es schaffen, diesen Plan günstiger umzusetzen greift wieder das besprochene Bonussystem.

Was denken Sie darüber? Ist es so möglich richtige Anreize für einen Projektmanager zu schaffen? Teilen Sie uns Ihre Meinung mit!

Wozu eigentlich Clouds?

Als Gründe für den Wechsel in die Cloud werden meist angeführt

  • Mehr Flexibilität – die “atmende IT”
  • Kostenargumente

Aber – mal ganz ehrlich – in wievielen real existierenden Unternehmen ändert sich der Bedarf an Rechenleistung so dynamisch, dass das relevant ist? Die Zahl der User ändert sich nicht ohne weiteres von heute auf morgen – sieht man einmal von Insolvenzen, Betriebsschließungen etc. ab, und das kann ja nicht das Argument für die Cloud sein.

Auch der Bedarf an Rechenleistung im Backend ändert sich in den meisten Unternehmen eher langsam. Und mit einer “atmenden IT” hat auch das nicht viele zu tun, denn i.d.R. wächst der Bedarf an Rechenleistung ständig und monoton. Größere Schwankungen hingegen sind  eher selten.

Bedeutet also die vielzitierte Flexibilität nicht ganz einfach, dass Rechenleistung aus der Cloud schneller bereitgestellt wird oder anders ausgedrückt – dass die interne IT zu langsam ist?

Auch Kostenargumente müssen auf den Prüfstand! Erfahrungen mit größeren IT-Organisationen zeigen, dass Skaleneffekte in der IT nur schwer zu realisieren sind. Die Stückkosten in großen IT-Organisationen sind oft höher als die Stückkosten in kleineren Teams. Die schiere Größe von Cloud-Anbietern allein kann also noch keine Einsparungen bewirken.

Geht es vielleicht um etwas anderes? Ist die interne IT vielleicht nicht in der Lage konsequent zu standardisieren? Und schüttet man vielleicht deshalb gleich das Kind mit dem Bade aus und verzichtet völlig auf jedewede Flexibilität indem man in die Cloud wechselt, weil man nicht in der Lage ist eine vernünftige Ballance zwischen Flexibilität und Effizienz zu finden? Weil die Fachseite im Verhältnis zur IT einfach zu durchsetzungsstark ist?

Der Fachseite ist natürlich viel leichter zu verkaufen: “Unser Cloud-Anbieter unterstützt das leider nicht.” als “BYOD – nicht bei uns!”

SOA in der Cloud

Was hat SOA mit Clouds zu tun? Okay, beides sind Buzzwords, die man bald schon nicht mehr hören kann. SOA ist – was den Marketing-Hype angeht – schon wieder auf dem absteigenden Ast, dem Cloud-Computing steht dies noch bevor.

Aber da ist noch mehr: Clouds machen ohne SOA wenig Sinn. Ebenso erschließt sich das Potential von SOA erst in der Cloud. Wieso das?

Bei dem ganzen Hype um die Cloud wird vielleicht manchmal über das Thema Integration zu wenig nach gedacht. Aber kann man denn nach all den vielen Integrationsprojekten die die Beraterbranche in den letzten ca. 30 Jahren reich gemacht hat der Ansicht sein, dass Applikationen wie z.B. ein CRM einerseits und ein ERP-System andererseits mehr oder weniger unverbunden nebeneinander existieren können? Und dass das Sinn macht?

Diese beiden Systeme über eine individuelle Schnittstelle zu verbinden, kann aber auch nicht der Weg sein, denn gerade über solche Schnittstellen werden ja Unternehmensarchitekturen in Stein gemeißelt. Die Flexibilität und Agilität die die Cloud mit sich bringt, ginge sofort wieder verloren. Der Wechsel von einem Cloud-Provider zu einem anderen würde durch diese Schnittstelle erheblich erschwert.

Die Lösung liegt auf der Hand: SOA! Wenn standardisierte Interfaces für solche Datentransfers angeboten werden, wird eine schnelle und unkomplizierte Integration von Systemen aus unterschiedlichen Domänen realistisch.

Und umgekehrt: Ist es wirklich sinnvoll den Zugriff z.B. auf die Kostenstellendaten über einen proprietären Web Service im Unternehmen zu regeln? Wie viele Applikationen werden denn in einem nicht allzu großen Unternehmen diese Schnittstelle nutzen? Wie hoch ist die Chance, dass dieser Service tatsächlich ‚resused‘ wird? Anders aber in der Public-Cloud: Hier ist eine standardisierte Schnittstelle immens wertvoll.

Das würde bedeuten, dass das Cloud-Computing erst dann die heute versprochenen Benefits einfahren kann, wenn SOA einen entsprechenden Reifegrad erreicht hat und wenn v.a. die Web Services übergreifend einigermaßen standardisiert sein werden. Und das kann natürlich noch etwas dauern. Bleibt also noch etwas Zeit, sich darauf gut vorzubereiten!

ITIL-Implementierung in der Praxis

Über das Design von ITIL-Prozessen gibt es Unmengen an Literatur. Das Thema „Einführung von ITIL-Tools“ führt im Vergleich dazu eher ein Schattendasein. Dabei gehen gerade ITIL-Tooleinführungsprojekte oft schief. Die Fehler, die  hier gemacht werden sind immer wieder dieselben.  Wir haben zusammen mit Kunden und Tool-Herstellern eine Vorgehensweise zur Implementierung von ITIL-Tools entwickelt, die eine schnelle und problemlose Einführung ermöglicht. So konnte z.B. bei einem der großen Energieversorger in nur fünf Monaten eine CMDB zur Abbildung von 200.000 CIs eingeführt werden.

Weiterlesen