In vielen meiner Beiträge habe ich beschrieben, welche Fehler bereits zu Beginn von Projekten fast schon zwangsläufig in Projekt-Krisen 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 vom Business, dem in der Verantwortung stehenden Fachbereich, 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! Seltsam daher, dass sich die Business-Verantwortlichen nach dem Absegnen des Projektauftrags und des Budgets in schöner Regelmäßigkeit dann 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 „klassisch“ 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 zunächst einmal ja 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/Budget verbrauchen, das an geplanter Stelle noch gebraucht wird, und damit vielleicht sogar den Business-Nutzen in Gefahr bringen.
Ein für alle verbindliches Change Control Verfahren kann das verhindern. Und wenn auch der bezahlt, der bestellt hat, dann werden die Business-Manager immer auch nachrechnen, ob die Änderung auch einen adäquaten Mehrwert erbringt. 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 Produktes 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, nicht an „alten Gewohnheiten“ festhält.
Den letzteren 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ührung und Anwendern durchführen lassen. Nur so kommt am Ende auch „Gummi auf die Straße“ und rechnet sich der Business Case. 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…!
Sehr geehrter Herr Zeumer,
ich habe gerade zum ersten Mal einen Artikel von Ihnen gelesen und bin sicher, es wird nicht bei dem Einen bleiben.
In den 15 Jahren im Bereich Projektmanagement habe ich sehr oft erlebt, dass der (fehlende) Management-Support der kritischste Erfolgsfaktor im Projekt ist. Diesen dauerhaft einzufordern ist meiner Erfahrung nach (leider) eine der Hauptaufgaben der Projektleitung. Für die Projektbeteiligten aus den Fachbereichen konkurriert das Projekt meistens mit den Aufgaben aus dem Tagesgeschäft.
Solange das Management dauerhaft eine wesentlich höhere Priorität auf die Ergebnisse aus dem Tagesgeschäft legt als auf die Ergebnisse aus der Projektarbeit, wird auch der Fachbereich seine Energie mehr in das Tagesgeschäft stecken als z. B. in die Tests eines noch sehr fremd wirkenden neuen Systems. Hier ist meiner Meinung nach ein gutes Risikomanagement hilfreich, welches dem Management frühzeitig die „Eintrittswahrscheinlichkeit“ und die „Schadenshöhe“ bei Einführung eines neuen IT-Systems transparent macht, welches die Prozesse des Unternehmens nicht vollständig oder nicht korrekt abbildet. Gleichzeitig würde es aus meiner Sicht helfen wenn wir mit einer gemeinsamen Sprache daran arbeiten würden, dass das Management und die Fachbereiche die Angst vor der IT verlieren. Nicht selten sprechen wir in der IT eine Sprache, die das Management und die Fachbereiche verunsichert. Damit ist es oft schwierig, die Leute für ein (IT-)Projekt zu begeistern.
Herzliche Grüße
Katja Scherer
Hallo,
durch den Newsletter bin ich auf den Artikel aufmerksam geworden.
Für mich spricht das sehr für die Rolle des „Business Owners“ aus der Scrum-Methodik – einem 100% verantwortlichen Anforderer aus dem Business. Egal, ob man nun nach Scrum arbeitet oder anders vorgeht.
Beim Lesen von Frau Scherers Kommentar war mein Gedanke, dass ich gespannt bin darauf, wie sich bei meinem Arbeitgeber die Einführung des Geschäftsprozessmanagements und der Aufbau eines Portfoliomgmts. auswirken werden. Für beide Themen habe ich die „Feder im Hut“, anzupacken, und beides wird in den nächsten 6, 12, 18… Monaten hoffentlich Schritt für Schritt Blätter und Blüten kriegen – und zunehmend Früchte. Beides soll die Transparenz deutlich erhöhen – und das BPM dafür sorgen, dass Fachbereiche und IT sich auf das Gleiche beziehen. Das ist ja das Ziel, bei dem BPMN-konforme Prozessbeschreibungen sicher nicht von allein wirken, aber unterstützen sollen.
Hallo Herr Zeumer,
ich habe Ihren Artikel mit großem Interesse gelesen. Und ja, es gibt (fast) KEINE IT-Projekte. Selbst ein Jahres, Quartals oder Monats ist inhaltlich durch einen Fachbereich zu verantworten.
Für mich gilt seit langen das die IT Dienstleister ist. Aber in der Tat gehört eine entsprechende Menthalität in die Köpfe der Unternehmensführung und das übrige Management.
Ich kann das durch Tätigkeiten in verschiedenen Unternehmen bestätigen. In einem gab es einen Kulturwandel, in einem anderen leider nicht mehr. In der Firma, in der ich heute beschäftigt bin ist das Verständnis zum Teil am wachsen aber in letzter Konsequenz noch nicht gelebt da es ja Arbeit für den Fachbereich bedeutet.
Danke
THS
Hallo Herr Zeumer,
ein schöner Artikel, der ein wichtiges Thema auf den Punkt bringt.
Das „richtige“ Zusammenwirken von Business und IT ist vielfach maßgeblich für den angestrebten Projekterfolg. Deshalb nennen wir uns ja auch „The Business And IT Architects“.
Eine Anmerkung möchte ich gerne ergänzen. Sie schreiben, dass die Business-Seite die Verantwortung dafür hat, dass ihre Vorstellungen richtig aufgenommen und verstanden werden. Dem stimme ich grundsätzlich zu. Gleichzeitig hat ein IT-Dienstleister Möglichkeiten, diesbezügliche Defizite zu erkennen und auf Besserung zu drängen oder dies durch geeignete Verfahren zu begünstigen. Speziell bei externen IT-Dienstleistern, die für ein Projekt beauftragt werden, ist es für mich ein Kriterium für die Qualität des Dienstleisters, wie er damit umgeht. Setzt er nur um, was man ihm vorlegt, oder sorgt er (im Rahmen seiner Möglichkeiten) dafür, dass tatsächlich ein Business-Nutzen entsteht? Die Möglichkeiten hängen sicherlich vom Einzelfall ab.
Ich will damit die Verantwortung des Business keinesfalls schmälern. Ich finde jedoch, dass sich die IT-Seite nicht zurücklehnen und darauf ausruhen sollte. Im Idealfall kümmern sich beide darum.
Grüße
Ingo Geppert
Hallo Herr Geppert,
da bin ich auch bei Ihnen. Als externer Dienstleister ist man jedenfalls erfolgsabhängig und wird schon deshalb, wenn man sein Metier versteht, hier große Sorgfalt walten lassen. Für interne IT-Abteilungen wünsche ich mir, dass sie über die reine „Dienstleistung“ und „Kostenstelle“ hinaus pro-aktiv das Business beraten und die zur Verfügung stehenden technischen Möglichkeiten mit diesem zusammen optimal zusammenstellen.
Beste Grüße
Henning Zeumer