In vielen meiner Beiträge habe ich beschrieben, welche Fehler bereits zu Beginn von Projekten fast schon zwangsläufig in Projektkrisen führen. Natürlich habe ich aber in den vielen Jahren meiner Praxis auch häufig Dinge erlebt, die auch noch so gut gemeinte und auf den Weg geschickte Initiativen schließlich wackeln oder gar scheitern ließen.

Es gibt (fast) keine IT-Projekte!

Projekte werden wohl kaum zum Selbstzweck oder als Beschäftigungstherapie für die Mitarbeiter durchgeführt. Fast immer steckt doch ein ganz bestimmtes Interesse der Geschäftsbereiche dahinter. Entweder soll den Mitarbeitern die Arbeit erleichtert, Kosten und Fehlerquellen eliminiert oder gar neue oder bessere Umsätze ermöglicht werden. Die IT ist dabei meist nur Mittel zum Zweck, soll den fachlichen Vorgang mit geeigneten Prozessen und Automatisierungen unterstützen. Der Wertzuwachs kommt damit nicht aus der Technik, sondern aus deren Anwendung im Business.

IT-Projekte sind deshalb fast immer Business-Projekte! Allerdings seltsam, dass sich die Business-Verantwortlichen nach dem Absegnen des Projektauftrags und des Budgets dann in schöner Regelmäßigkeit aus dem Projekt verabschieden. Jetzt soll die IT liefern. Was dem Projekt dadurch fehlt, ist der fachliche Sachverstand, dass die Anwendung nachher so aussieht, wie sie dem Business-Zweck auch am besten nutzt. Die "abkommandierten" Fachspezialisten geben ihre Wunschlisten ab, und die Techniker oder eingekaufte Berater sollen dann machen.

Oft ein Kommunikationsproblem

Jedem Manager ist sicher schon mal aufgefallen, dass Business und IT oftmals ein sehr unterschiedliches Verständnis davon haben, was die Lösung für ein Business-Anliegen sein könnte. Auf der Anwenderseite geht man nicht selten nach der Devise "Do what I mean, not what I say" von einer trivialen Klarheit der Anforderungen aus. Schließlich weiß "man" doch, wie der Geschäftsprozess idealerweise ablaufen soll und wie das alles aussehen muss, damit es gut bedienbar ist.

Oder aber die Praktiker haben zwar ein Problem, aber noch keine klare Vorstellung von der Lösung. Von den Technikern wird erwartet, dass sie ebenso tief im Geschäft drin sind und dass sie "nur noch ein wenig" mit Technik nachhelfen müssen. Deren Problemstellung ist aber halt primär technischer Natur, und was sie für praktisch halten, wird sich nicht immer mit den Erwartungen der Anwender decken.

Dagegen hilft nur, immer wieder miteinander – Business und IT – über die Anforderungen und die Ausgestaltung der Umsetzung zu sprechen. Das Business ist in der Pflicht und Verantwortung dafür, dass seine Vorstellungen richtig aufgenommen und verstanden werden – niemand sonst! Und zwar von den Umsetzern aus der Technik wie auch von denen, die es nachher nutzen sollen. Da muss der Fachabteilungsleiter auch die Erwartungen seiner Leute managen, nicht der Projektleiter oder die IT.

Alles andere führt fast immer zu Enttäuschungen, Zeitverzug und höheren Kosten, denn Nachbessern ist immer schwieriger als es gleich richtig zu machen. Agile Projektansätze tragen dem bewusst Rechnung, aber auch in "klassischen" Projekten ist die Zusammenarbeit und Unterstützung durch die Business-Verantwortlichen ein Muss!

Änderungen sind nicht per se etwas Schlechtes

Wenn also Fehlentwicklungen durch gute Kommunikation und Interaktion frühzeitig auffallen oder man dadurch zu besserer Erkenntnis und geänderten Anforderungen gelangt, dann kann das zu einem höheren Aufkommen an Change Requests, aber auch zu einem gesteigerten Business-Nutzen führen.

Das ist ja zunächst einmal nichts Schlimmes, denn in einem frühen Stadium sind diese leichter einzuplanen und umzusetzen als später, wenn man ein vermeintlich fertiges Produkt präsentiert. Änderungen dürfen sich nur nicht unkontrolliert einschleichen und damit Zeit bzw. Budget verbrauchen, das an anderer Stelle noch eingeplant ist. Am Ende gerät dadurch evtl. sogar der Business-Nutzen in Gefahr.

Ein für alle verbindliches Change-Control-Verfahren kann das verhindern. Und wenn der bezahlt, der bestellt hat, dann werden die Business-Manager auch immer nachrechnen, ob die Änderung auch einen adäquaten Mehrwert bringt. Gegen "politisches Schönrechnen" hilft das allerdings nicht, wohl aber gegen Wunschlisten mit vielen "Nice-to-haves" und gegen pedantisches "Rundfeilen von i-Punkten".

Den Business-Nutzen auch realisieren

Wenn alle richtig zusammen gearbeitet und kommuniziert haben, und wenn auch nicht zuletzt dadurch die Schätzungen und Planungen realistisch waren, dann sollte einem erfolgreichen Projekt eigentlich nichts im Wege stehen. Doch das Projekt muss nicht nur planmäßig abgeschlossen werden, um ein erfolgreiches zu sein, sondern der daraus angestrebte Nutzen muss auch realisiert werden. Und das geschieht in aller Regel wieder im Business durch die Anwendung des im Projekt erstellten Produkts oder Ergebnisses.

Das Business-Management ist also dafür verantwortlich, dass das Projektprodukt auch so wie gedacht eingesetzt wird, dass also erstens das Produkt so konzipiert und ausgeführt wurde, wie es das Business braucht, und zweitens dass die Fachorganisation es auch zum Gebrauch annimmt und nicht an "alten Gewohnheiten" festhält.

Den letzten Aspekt sichert man am besten mit guten Trainings der Anwender ab. In den Fällen, wo ein Projekt weitgreifende Auswirkungen im Alltag und in der Organisation hat, sollten die Projektverantwortlichen ein begleitendes, intensives Veränderungsmanagement einplanen und auch mit Führungskräften und Anwendern durchführen lassen. Nur so kommt am Ende auch "Gummi auf die Straße" und der Business Case rechnet sich. Sie sehen: Es war tatsächlich ein Business-Projekt!

Gilt nicht nur für IT-Projekte

Die hier gezeigten Beispiele sollen aber keinen Manager oder Executive in Sicherheit wiegen, der gerade kein "IT-Projekt" in seiner Verantwortung hat. Die gleichen Fehler passieren in nahezu allen anderen Projektarten ebenso. Ob nun das Produktmanagement seine F&E-Projekte nicht mit der gebührenden Fürsorge behandelt, bei einem Merger nur an das Umsatz- und Gewinn-Potenzial, nicht aber an die saubere Integration der Backoffice-Prozesse, Anwendungen und der Menschen gedacht wird, oder beim Bauprojekt die einzelnen Gewerke nicht ausreichend und laufend mit- und aufeinander abgestimmt werden – das Ergebnis wird immer so oder so ähnlich aussehen.

Das bedeutet nichts anderes als dass diejenigen, die den letztlichen Nutzen aus einem Projekt oder Programm, einer Initiative oder Investition ziehen wollen – für deren Geschäft also das ganze Geld ausgegeben wird –, sich ihrer Verantwortung für den Erfolg sehr bewusst sein müssen.

Wenn sie diese jedoch auf andere wegdelegieren und sich nicht ihrer Rolle entsprechend einbringen (wollen), dann werden Business-Projekte immer wieder aus dem Ruder laufen, länger dauern, viel mehr kosten und zu mehr oder weniger großer Enttäuschung führen. Mein Rat an deren Chefs: Karrieren brauchen nachweisbare Erfolge, nicht schief gelaufene oder gar abgeschriebene Projekte…!