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!

• 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!”

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!

Wieso scheitern Projekte zur Einführung von ITIL-Tools denn so oft? Grund für das Scheitern ist fast immer, dass die Projekte nicht als Change-Projekte aufgesetzt werden. Der Projektauftrag sieht in der Regel „nur“ vor ein Tool zur Unterstützung der bereits definierten ITIL-Prozesse einzuführen. Dabei wird übersehen, dass in der Regel erst mit der Tooleinführung die Prozesse institutionalisiert werden. Die Auswirkungen, die eine solche Tool-Einführung somit auf die Organisation haben, werden daher nicht ausreichend berücksichtigt worden.

Anwender einbeziehen  Weil ITIL-Tool-Einführungsprojekte die Organisation ändern, treffen sie häufig auf Widerstände. Werden die Anwender nicht rechtzeitig mit einbezogen, so findet die implementierte Lösung keine Akzeptanz egal wie gut sie ist. Bereits bei der Toolauswahl  sollten die Anwender dabei sein. Natürlich können Entscheidungen nicht mit allen Anwendern diskutiert werden. Empfehlenswert ist daher die Bildung eines Anwenderausschusses. Nur der Anwenderausschuss ist berechtigt, Anforderungen an das neue Tool zu stellen. Seine Aufgabe ist es, Anforderungen in den jeweiligen Bereichen abzustimmen. In der Praxis bewähren sich Teams mit bis zu 15 Personen. Erfolgskritisch ist die Auswahl der Mitglieder dieses Gremiums. Die Mitglieder müssen sehr gut innerhalb der Organisation vernetzt sein und sollten über ein gutes „standing“ verfügen und am besten hierarchisch nicht zu hoch angesiedelt sein; denn die Organisation von Meetings mit 15 Vertretern des mittleren Managements ist in den meisten Unternehmen kurzfristig kaum machbar.

Perspektivenwechsel nach der Toolentscheidung Der reinen Lehre zufolge werden zuerst die Prozesse definiert und dann erst wird ein Tool zur Prozessunterstützung eingeführt. Diese Vorgehensweise führt in der Praxis aber oft dazu, dass die Tools unnötigerweise „verbogen“ werden; denn die detaillierte Festlegung von Prozessen beruht in der Regel auf teilweise willkürlichen Festlegungen. Beispielsweise könnte die Reihenfolge von einzelnen Prozessschritten oft vertauscht werden, ohne dass dies zu einer Qualitätsbeeinträchtigung führt. Legt man also eine bestimmte Aktivitätenreihenfolge ohne genaue Toolkenntnis fest, stellt man später oft fest, dass diese vom Tool so  nicht unterstützt wird. Es muss dann entweder das Tool oder der Prozess angepasst werden.

Besser ist es daher, den Prozess nur so detailliert zu planen, wie für die Tool-Auswahl notwendig. Wenn die Toolentscheidung einmal getroffen ist sollte ein Perspektivenwechsel stattfinden: Ausgangspunkt sind dann die konkreten Eigenschaften des Tools, die bestimmte Prozessvarianten besser unterstützen als andere. Zu prüfen ist dann, wo das Tool zwingend angepasst werden muss, weil die vorgegebenen Prozessabläufe nicht zu den Randbedingungen im Unternehmen passen. Ratsam ist dabei, den gewählten Standard zunächst möglichst wenig zu verändern. Die Erfahrung zeigt, dass die Priorisierung der Anforderungen schon wenige Monaten oder gar Wochen nach Tool-Einführung ganz anders getroffen wird, als in den frühen Design-Phasen.

Time- und Budget-Boxing Aber auch wenn man sich nur auf die notwendigsten Anpassungen beschränkt, wird man feststellen, dass die Zahl der Anforderungen wächst und wächst. Man hat also die Wahl, den geplanten Einführungstermin immer weiter nach hinten zu verschieben oder man betreibt von vorneherein time- und budget-boxing: Es wird also ein fester Zeit- und Budget-Rahmen gesetzt und es wird nur das realisiert, was innerhalb dieses Rahmens realisiert werden kann. Alles andere wird bis zu einem späteren Release zurückgestellt. Entscheidende Bedeutung kommt hier dem Anforderungsmanagement zu, damit sichergestellt ist, dass die Anforderungen mit dem größten Kundennutzen auch umgesetzt werden.

Zyklisches Vorgehen Aber auch bei einer solchen Vorgehensweise kann man unangenehme Überraschungen erleben; insbesondere dann, wenn die Anwender zum ersten Mal Praxisfälle mit dem neuen Tool durchspielen. Ist zu diesem Zeitpunkt kein Budget mehr für Änderungen vorhanden, hat man meist verloren, denn es werden vielfältige Anpassungen notwendig sein. Daher sollte für das erste Beta-Release, das Grundlage der ersten Praxistests ist, nicht mehr als 50% des Budgets veranschlagt werden. Die neuen Anforderungen, die im Rahmen dieser Tests in der Regel identifiziert werden, können dann gegenüber bereits früher gestellten Anforderungen und notwendigen Fehlerkorrekturen priorisiert werden.

Richtig spannend wird es, wenn die Tests zum ersten Mal mit Echtdaten durchgeführt werden. Erst dann werden viele konzeptionelle Fehler und Lücken erkannt. Wenn also eine Daten-Migration notwendig ist, sollte diese möglichst so frühzeitig erfolgen, dass die Praxistests auf Basis von Echtdaten erfolgen können.

Internes und externes Know-how nutzen Und wie vermeidet man die vielen Stolperfallen, die ein solches Projekt mit sich bringt? Die Grundlage hierfür wurde bereits mit unserem Anwenderausschuss gelegt. Das hier vertretene Know-how zu den Besonderheiten im Unternehmen erlaubt es viele Klippen schadlos zu umschiffen, wenn es richtig eingebunden wird. Genauso wichtig ist hier aber externes Know-how, denn ohne die Erfahrungen aus vielen ähnlich gelagerten Projekten wird man sicher mindestens einige der Fehler wiederholen, die viele andere bereits vor einem gemacht haben.

Ganz besonders wichtig ist das interne Prozess-Know-how in den durchzuführenden Schulungen. Reine Tool-Schulungen durch den Tool-Hersteller sollten vermieden werden. Die Schulungen müssen vielmehr vermitteln wie der unternehmenseigene Prozess mit dem neuen Tool gelebt werden kann. In der Praxis bewährt sich die Ausbildung von internen Multiplikatoren, die das Know-how dann in die jeweiligen Bereiche tragen.

Kommunikation ist alles Das Nebeneinander von internem und externem Know-how funktioniert nicht immer konfliktfrei. Eine gute Möglichkeit, die beiden Seiten zusammen zu bringen ist es, das Projekt mit einem mehrtägigen Workshop zu starten. Hier sollten auch teambildende Methoden genutzt werden. Neben dem Projekt-Kernteam sollten alle Mitglieder des Anwenderausschusses an dieser Veranstaltung teilnehmen.

Solche Kickoff-Workshops fördern die Bereitschaft für Veränderungen ungemein. Die relativ hohen Kosten für die Workshops, werden von einem funktionierenden Team meist sehr schnell wieder eingespart.

Management Support  Aber alle diese Maßnahmen können eines nicht ersetzen: Ausreichende Unterstützung durch das Senior-Management. Ganz selten nur wird es so sein, dass alle Stakeholder bereit sind für die anstehenden Änderungen. Um hier endlose Diskussionen abzukürzen, sind klare Entscheidungen oft nicht nur hilfreich sondern sogar notwendig.

Das Vorgehensmodell in der Praxis Auf der Basis des beschriebenen Ansatzes konnten wir z.B. bei einem großen Kunden in nur fünf Monaten eine CMDB mit einer darauf aufbauenden Change-Management-Lösung einführen. In weiteren fünf Monaten wurden die Prozesse Incident- und Problem-Management auf die neue Plattform migriert. Heute arbeiten fast 1.000 Anwender mit dem Tool, erfassen täglich ca. 1.000 Incidents und setzen Sie in Beziehung zu den ca. 200.000 CIs.