Insbesondere große Unternehmen betreiben in der Regel parallel eine Vielzahl von Projekten. Erfahrungen zeigen, dass sie mit einer konsequenten Priorisierung, Straffung und gegebenenfalls Bereinigung ihres Portfolios bis zu 30 Prozent ihrer Kosten einsparen können. Die Anlässe zur Initiierung von Projekten sind unterschiedlich: neue Technologien, gesetzliche Änderungen oder neue fachliche Anforderungen der Business-Seite (siehe Grafik). Entsprechend unterschiedlich muss die Bewertung vorgenommen werden.
Projekte zur technologischen Anpassung
Rund ein Fünftel aller Projekte wird aufgrund technologischer Veränderungen ins Leben gerufen: neue Server, eine neue Netzinfrastruktur oder ein neues Betriebssystem. Sie befassen sich mit der Einführung dieser Technologie, der Anpassung von Anwendungen, der Schulung der Support-Mitarbeiter und Nutzer und vielem mehr. Hier ist eine konsequente betriebswirtschaftliche Betrachtung notwendig: Hat das Projekt wirklich einen geschäftlichen Mehrwert - zum Beispiel reduzierte Kosten - oder geht es primär darum, die neueste oder schönste Technologie anzuwenden? Gerade IT-Verantwortliche neigen immer wieder dazu, die Technik als Selbstzweck anzusehen.
Oft steht natürlich auch eine Zwangslage im Hintergrund, etwa wenn ein Software-Anbieter den Support für ältere Versionen eines Betriebssystems oder einer Standardlösung einstellt. Aber auch dann sollten die Verantwortlichen nicht automatisch nachziehen, sondern zuerst ihren Handlungsspielraum prüfen.
Ist das Risiko, keine Anpassung vorzunehmen, kalkulierbar - übertreffen die gesparten Aufwendungen möglicherweise den potenziellen Schaden? Gibt es einen Drittanbieter, der den Support übernehmen könnte? Oder kann es sinnvoll sein, angesichts der oft recht kurzen Zyklen erst auf die übernächste Version dieses Systems zu migrieren? (Viele Microsoft-Anwender werden beispielsweise von XP direkt auf Windows 7 wechseln). Generell gilt also: nicht technischen Trends einfach folgen, sondern jede Entscheidung wirtschaftlich prüfen.
Anforderungen an IT-Projekte ändern sich permanent
Rund fünfzehn Prozent aller Projekte werden aufgrund neuer gesetzlicher Rahmenbedingungen, Richtlinien und Arbeitsanweisungen gestartet. Das gilt insbesondere im ERP-Bereich, etwa bei Mehrwertsteuer-Erhöhungen, geänderter Abschreibungsdauer, längeren Aufbewahrungspflichten etc. Wenn die Systeme nicht konfigurierbar sind, muss der Code der Anwendungen geändert werden.
Auch wenn hier die äußeren Zwänge noch stärker sind als bei technologischen Veränderungen, gilt trotzdem der Grundsatz: Erst prüfen, dann handeln. Oft sind die Spielräume größer, als zunächst gedacht. Was sind tatsächlich die Fakten? Welche Zeitachsen müssen eingehalten werden? Welche Alternativen bestehen?
Ein Beispiel ist das neue Bilanzrechtsmodernisierungsgesetz (BilMoG), das ursprünglich für Anfang 2009 geplant war. Wegen der aktuellen Wirtschaftskrise wurde das Gesetzgebungsverfahren jedoch verschoben, so dass die meisten Vorschriften erstmals für Geschäftsjahre angewandt werden, die nach dem 31.12.2009 beginnen. Wer hier zu schnell war, hat zu früh investiert und letztendlich auch mehr Arbeit.
Projekte aufgrund neuer Business-Anforderungen
Bei den bisher genannten Projekttypen geht es vor allem darum, den Handlungsspielraum des Unternehmens zu prüfen. Bei fachlich begründeten Projekten hingegen steht der Mehrwert der Veränderung oder der Erweiterung im Mittelpunkt. Da rund zwei Drittel aller Projekte dieser Kategorie zuzurechnen sind, enthält eine solche konsequente ökonomische Bewertung das größte Optimierungspotenzial.
Ziel ist es in diesem Fall, fachliche Anforderungen zu implementieren und neue oder veränderte Geschäftsprozesse zu unterstützen beziehungsweise überhaupt erst möglich machen. Deshalb muss der Mehrwert auch eindeutig in diesen Kategorien definiert werden. Das heißt konkret: Die Business-Seite muss den angestrebten Nutzen klar darstellen.
Anforderungen im Projektverlauf ständig kontrollieren
Geschäftlich induzierte Projekte müssen deshalb einen Genehmigungsprozess durchlaufen. Das ist in den meisten Unternehmen heute auch Konsens. Das Problem besteht aber darin, dass dieser Prozess in den meisten Fällen viel zu kurz greift: Zwar haben 60 bis 70 Prozent der Großunternehmen einen klaren Anforderungsprozess definiert, um neue Projekte zu bewilligen. Dabei muss die Fachseite durchaus den Mehrwert nachweisen. Aber maximal 20 Prozent der Unternehmen halten dies auch im Projektverlauf nach und messen nach Abschluss konkret den Erfolg.
Diese Inkonsequenz hat gravierende Folgen. Der betriebswirtschaftliche Nutzen von Projekten ist oft geringer, als am Anfang vorgesehen, insbesondere wenn sich zwischenzeitlich die Rahmenbedingungen ändern. Vor allem aber werden viele Projekte bei der Antragstellung durch zu optimistische Prognosen "gepusht" - während umgekehrt die realistischeren Vorhaben bei der Priorisierung durchfallen. Wird am Ende nicht kontrolliert, ob der erwartete Mehrwert auch eingetreten ist, bleibt auch hier der Ehrliche der Dumme.
Der ideale Anforderungsprozess
Zu empfehlen ist ein dreistufiger Prozess:
Erstens: Bei der Beauftragung definiert die Business-Seite konkret die geschäftlichen Ziele, die das Projekt erreichen soll.
Zweitens: Während der Laufzeit wird regelmäßig überprüft: Gelten die zu Beginn aufgestellten Parameter noch? Haben sich die Rahmenbedingungen verändert? Ist die Prognose noch richtig?
Drittens: Am Ende des Projekts wird der Erfolg gemessen. Das heißt: Die Business-Seite muss sich danach beurteilen lassen, ob die Verbesserungen, mit denen sie den Aufwand für das Projekt begründet hat, auch tatsächlich eingetreten sind. Die Erfahrung zeigt: Wird die Verantwortung konsequent zugeordnet, ziehen die Initiatoren zu optimistisch angelegte Anträge oft wieder zurück.
Dieser Prozess dient auch als Steuerungsinstrument, falls durch externe Einflüsse das Projektportfolio verändert werden muss. Nehmen wir ein Beispiel aus der Automobilindustrie: Eine neue Internet-Plattform zum Online-Verkauf von gebrauchten PKW soll entwickelt und implementiert werden. Durch die Abwrackprämie ist der Markt für gebrauchte Fahrzeuge jedoch stark geschrumpft.
Das Unternehmen muss deshalb während der Laufzeit prüfen: Braucht es die Plattform nicht mehr? Oder benötigt es sie sogar umso dringender? (Dann sollte es vielleicht dem Projekt mehr Ressourcen zuweisen.) Auch während des Projektverlaufs müssen die Verantwortlichen also immer nach dem Snapshot-Prinzip die Priorisierungs-Entscheidung überprüfen und gegebenenfalls verändern können.
Trigger für IT-Projekte
Um Projekte effizient zu steuern, empfiehlt es sich, konkrete "Benefit-Trigger" sowohl für das Gesamtprojekt als auch die einzelnen Phasen zu definieren. So gibt etwa der Projektleiter als Ziel nicht vor, dass eine bestimmte Software zu implementieren ist, sondern welcher ökonomische Nutzen damit erreicht werden soll: die Auswirkungen auf den Business-Prozess, schnellere Durchlaufzeit, geringere Fehlerquote etc. Dann werden Trigger für die einzelnen Phasen festgelegt; erst wenn diese Ergebnisse erreicht sind, ist die jeweilige Projektphase erfolgreich abgeschlossen.
Der Gesamtprojekt-Trigger wird nach Abschluss des Projekts gemessen, denn der angestrebte Effekt kann natürlich erst eintreten, nachdem die Software in Betrieb genommen wurde. Dann ist eine Nachkalkulation samt Bewertung notwendig. Das kann kurzfristig passieren oder nach Ablauf eines angemessenen Zeitraums, wenn die Maßnahmen Gelegenheit hatten, zu greifen. Auf jeden Fall aber wird die Business-Seite daran gemessen - nur so wird sichergestellt, dass sie die Initiierung von Projekten wirklich ernsthaft betreibt.
Ein durchgängiger Anforderungsprozess hilft zudem, Redundanzen und Widersprüche zu vermeiden. Business und IT haben von Anfang an einen Überblick über alle Projekte. Abhängigkeiten werden schnell erkannt, da Anwendungen Kundenstammdaten, die Produktion etc. verändern. So können die Verantwortlichen entsprechende Lösungen zusammenfassen und gegenläufige Bewegungen ausschließen.
Unternehmen, die einen Prozess der Anforderungsverifizierung nicht implementiert haben, werden von veränderten Rahmenbedingungen oft kalt erwischt. Ihnen bliebt dann zunächst nur ein "Notprogramm": Sie müssen ihr Projektportfolio zusammenstellen, die Ziele, den Nutzen und den Aufwand (Kosten) klären, Abhängigkeiten zu anderen Projekten herausfinden und darauf eine Priorisierung vornehmen.
IT-Projekte beenden
Eine systematische Betrachtung nach dem skizzierten Muster prüft nicht nur - wie beim üblichen Projektmanagement - die Effizienz der Projekte, sondern auch ihre Effektivität. Es ist kein Gewinn, ein Vorhaben zügig und mit angemessenen Mitteln durchzuführen, das dem Geschäft keinen Mehrwert bringt. Hier müssen Projekte konsequent beendet werden, auch wenn es schmerzhaft ist!
IT-Verantwortliche sind schon aufgrund ihrer Ausbildung oft sehr stark auf die Technik fixiert. Deshalb kommt es immer wieder vor, dass sie Projekte favorisieren, deren Business-Nutzen nicht klar ist. So werden zu Beispiel Tablet-PCs installiert, ohne dass tatsächlich vor Ort Unterschriften geleistet werden müssen. Support-Mitarbeiter können mit mobilen Geräten stets alle Systeme überwachen, ohne dass dies einen Vorteil bringt.
Oder der CIO glaubt, dass ein Projekt einem Business-Nutzen dient, während sich das Geschäft zwischenzeitlich verändert hat: Etwa wenn modernste Handhelds eingeführt werden - doch die Fachseite hat bereits beschlossen, die Zahl der mobilen Außendienst-Mitarbeiter drastisch zu reduzieren. Dann lautet nach einer systematischen Bewertung und Priorisierung die Empfehlung an den CIO oftmals: Lassen Sie Ihr Lieblingsprojekt sterben!
Jörg Hild ist Geschäftsführer der Compass Deutschland GmbH.