Der CIO muss sich mehr um die Fachbereiche kümmern

Obwohl eine gute Zusammenarbeit von IT und Fachbereichen noch nie so wichtig war wie heute, knirscht es oft zwischen den Abteilungen. Scheitern teure Projekte (oder werden diese aus Zeitmangel gar nicht erst angefangen), wird dies häufig der IT angelastet. Als echte Business Partner angesehen zu werden, wünschen sich etliche CIOs. Projektmanager und Berater Mario Neumann hat ein paar Ideen, wie ein CIO auf Augenhöhe agieren kann und was zu tun ist, um endlich aus der leidigen Kostenfalle auszukommen.

COMPUTERWOCHE.de: Die IT wird oft nicht als Business Partner ernst genommen. Woran liegt das?

Mario Neumann: Als CIO ist man oft in einem Fahrwasser, in dem man nur als Kostencenter gesehen wird und nicht als jemand, der das Unternehmen voranbringen kann. Der CIO steht unter ständigem Rechtfertigungsdruck für die Kosten, die er verursacht. Gleichzeitig ist der ständige Ressourcenmangel ein Problem. Da wird der Ruf nach Outsourcing laut, wenn die IT überfordert ist. Aber das ist auch kein Wunder: Die IT hat nicht die besten Leute.

COMPUTERWOCHE.de: Das hören unsere CIOs aber nicht gern und einige widersprechen da vehement.

Neumann: Nun, was das Fachwissen angeht, stimmt es häufig. Die IT hat eher Mittelfeldleute, denn die Topleute sind in der Unternehmensberatung oder auf dem freien Markt. Jemand, der sich ein spezialisiertes Fachwissen angeeignet hat, wird nicht in den IT-Bereich eines Unternehmens gehen, wo er höchstens ein Projekt zu seinem Thema betreuen kann. Wer sich intensiv mit einer Thematik befassen will, geht nicht in die IT-Abteilung eines Unternehmens. Das merkt man einigen IT-Abteilungen auch an. Zudem fehlt oft ein Überblick über das Projektportfolio im gesamten Unternehmen oder dessen Strukturen.

COMPUTERWOCHE.de: Wie kann man das Problem lösen?

Neumann: Vor allem müsste sich die IT intensiver um die Fachbereiche kümmern. Wenn ich als CIO Business Partner werden will, muss ich raus aus der Komfortzone und mir Gestaltungsspielräume erarbeiten.

COMPUTERWOCHE.de: Und wie soll das gehen? Dafür ist doch kein Budget da.

Neumann: Eben aus diesem Kostendruck muss der CIO raus. Normalerweise ist es so, dass alle Fachbereiche die IT für Support, Maintenance und Applikations-Betreuung bezahlen. Die IT wird deshalb wahrgenommen als diejenigen, die dafür sorgen, dass die Emails ankommen. Für Projekte bleibt meist nur wenig Luft, alle Wünsche kann ein CIO nicht erfüllen. Oft bekommt derjenige Fachbereich, der am lautesten schreit, den Zuschlag. Nicht jedes Projekt, das der Fachbereich will, funktioniert - wegen des Kostendrucks. Das ist nicht ideal. Schöner wäre es doch, zu den Fachbereichen zu sagen: Der Support ist gesichert - alles, was on top kommt, muss gezahlt werden.

COMPUTERWOCHE.de: Das klingt jetzt so einfach ...

Neumann: Man kommt nur aus dem Kostendruck raus, wenn man Bedarf generiert. Der Fachbereich muss denken, dass er die IT braucht, um ein Projekt zu stemmen. Oft konzentrieren sich CIOs zu sehr auf das Grundrauschen. Die IT sollte aber als internes Beratungsunternehmen auftreten und die Fachbereiche ganz anders betreuen. Sie muss sich für die Fachbereiche attraktiv machen und sich so aufstellen, als wären jene die Kunden.

COMPUTERWOCHE.de: Wie funktioniert diese Aufstellung?

Neumann: Dafür brauche ich als CIO Mitarbeiter, die dezidiert für einen Fachbereich zuständig sind. Ein solcher Mitarbeiter muss die Prozesse des Fachbereichs verstehen und beherrschen, und in den relevanten Meetings sitzen. Vom Typ Mensch her sollte es ein Berater sein, der in der Lage ist, mitzudiskutieren. Es dauert sicherlich ein paar Monate, bis der Fachberater sich etabliert hat. Aber meist ist der Fachbereich ihm gegenüber sehr offen. Die Fachbereiche sind typischerweise dankbar, denn häufig haben sie keinen IT-Ansprechpartner. Gemeinsam werden IT-Projekte erarbeitet. Die bringt der Fachberater zurück in die IT, die sie plant und eine Kostenaufstellung macht. Will der Fachbereich dann zum Beispiel SAP einführen, dann kostet das. So tritt die IT wie ein gleichberechtigter Partner auf. Und der Fachbereich wird das Projekt zahlen.

COMPUTERWOCHE.de: Das hat sicherlich Konsequenzen für die Aufstellung im Team. Wie würde so ein IT-Team aussehen?

Neumann: Die IT muss sich so aufstellen, dass sie in der Lage ist, viele Projekte zu stemmen. Aber der CIO kann nicht die komplette Mannschaft vorhalten, das wäre zu teuer. Stattdessen bräuchte er eine "atmende Mannschaft", wie ich es nenne: Je nach Bedarf stellt man Externe ein, die meine Stammmitarbeiter ergänzen. Und eine entscheidende Rolle spielen die Fachbetreuer, die den Bedarf erst schaffen. Trotzdem ist so eine Aufstellung ein unternehmerisches Risiko: Wenn die IT keine Projekte an Land zieht, dann müssen Leute entlassen werden.

1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen.

2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia.

3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv.

4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt.

5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet.

6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann.

7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht.

8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software.

9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist.

10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat.

11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3.

12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen.

13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren.

14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes.

15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden.

15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.

COMPUTERWOCHE.de: Wie funktioniert das in der Praxis?

Neumann: Ich gebe Ihnen mal ein Beispiel, wo wir das umgesetzt haben: Ein großer Anlagenbauer aus dem Mittelstand mit ein paar tausend Mitarbeitern hat die IT derartig umgestellt. Die Firma hatte das Problem, dass Anlagenbau und IT noch nicht miteinander verschmolzen waren. Die IT wurde zweigeteilt: Etwa 30 Leute waren für Support und Maintenance zuständig, bis hin zur Applikation-Betreuung. Die anderen 20 wurden wie eine Beratungsmannschaft aufgebaut. Vier Fachbereichsbetreuer wurden über mehrere Wochen eingearbeitet und machten ein "Shadowing" mit verschiedensten Leuten. Dazu gab es noch einige Führungskräfte, sechs Projektmanager und vier Lösungsarchitekten. Die Projektmanager und Lösungsarchitekten beherrschen bestimmte Technologien. Genau dafür findet man übrigens auf einmal auch als Unternehmen die Top-Leute. Denn das Arbeitsumfeld ist motivierend.

COMPUTERWOCHE.de: Was sagte die Firma dazu? Wie ist das in den Fachbereichen angekommen?

Neumann: In der Firma hatte die Idee einen positiven Effekt. Weil die Fachbereiche für eine konkrete Leistung zahlten, von der sie auch etwas hatten, und nicht nur die Flatsumme X. Das fühlt sich für den Fachbereich gerechter an. Damit steigt auch die Qualität: Die IT kann ein Projekt so besetzen und kalkulieren, wie es gebraucht wird und nicht mit zu wenig Ressourcen arbeiten.

COMPUTERWOCHE.de: Eignet sich das Modell für jedes Unternehmen?

Neumann: Bedingt. Damit es funktioniert, gibt es mehrere Voraussetzungen: Der CIO muss dahinter stehen und die Mannschaft muss beraten können. Wenn der CIO eine Mannschaft hat, die nur IT-Betreuung macht und ambitionslos ist, sollte er sich das gut überlegen - oder sich vorher eine passende Mannschaft zusammen bauen. Daneben braucht der CIO auch Risikobereitschaft, denn das muss er sich auch trauen. Außerdem muss die Geschäftsführung dahinter stehen. Wird die IT als Nebenkriegsschauplatz gesehen, die keinen Beitrag leistet, dann kann man die Diskussion abbrechen. Wenn aber die Geschäftsführung und der CIO zusammenarbeiten, dann kann das System funktionieren. Und der CIO ist ein Business-Partner.