Selbstwahrnehmung
Wie CIOs sich selbst belügen
Die Errichtung und rücksichtslose Verteidigung raffinierter Realitäts-Konstrukte gehört für den Menschen nicht erst seit dem Beginn des Fake-News-Zeitalters zum guten Ton. Ganz besonders kreativ werden wir allerdings, wenn es darum geht, uns selbst in die Tasche zu lügen. Nicht weil wir die falschen Prioritäten setzen oder die falschen Entscheidungen treffen wollen, sondern weil Wunschdenken in der Regel bequemer ist, als ein Blick durch das eisbeschlagene Fenster der Realität.
IT-Entscheider bilden hier keine Ausnahme - im Gegenteil. Kolumnist Bob Lewis von unserer US-Schwesterpublikation CIO.com zeigt Ihnen in Form einer launigen Betrachtung neun typische Situationen, in denen CIOs sich regelmäßig selbst belügen. So, dass sich die Balken biegen.
1. "Wir sind mit dem Business verzahnt"
Das Prinzip des IT Alignment klingt nach einer so wunderbaren Sache, dass viele CIOs enorme Ressourcen dafür aufwenden, es Wirklichkeit werden zu lassen. Blöd ist nur, dass die meisten Unternehmen - unabhängig von ihrer Größe - nicht einmal mit sich selbst verzahnt sind. Die Verzahnung mit dem Business lässt sich im Regelfall darauf herunterbrechen, dass entweder alle Beteiligten Kompromisse eingehen oder ein Chargeback-System zum Ausgleich installiert wird - quasi IT als Handlanger: "Sie bekommen alles was sie wollen, solange Sie es bezahlen."
So ist die IT vielleicht nicht unbedingt mit dem Business verzahnt, dafür aber mit dem Business Budget. Das sollte ausreichend Verzahnung gewährleisten. Wenn nicht, ist das das Problem von jemand anderem.
2. "Software-Update nur bei Business-Mehrwert"
Klingt überzeugend oder? Und nach Executive Level. Ein CIO, dem ein solches Statement entfährt, ist klar auf das Business fokussiert (und das IT Alignment). So kann man ihm auch niemals vorwerfen, er würde in Technologie nur um der Technologie willen investieren. Und das Allerbeste: Das IT Budget kann schrumpfen, schließlich muss man die Dinge nicht mehr auf dem aktuellen Stand halten.
Solche CIOs haben entweder niemals zuvor ein "Dauert-jetzt-ein-bisschen-nachdem-das-letzte-Update-drei-Jahre-her-ist"-Szeanrio durchlebt - oder sich erfolgreich um ein solches (beziehungsweise die Verantwortung dafür) drücken können.
Software Updates sind präventive Wartungsmaßnahmen. Entweder zahlen Sie jetzt dafür oder eben später. In letzterem Fall allerdings unter dem Strich oft deutlich mehr.
3. "Klar schaffen wir das noch mit dem Projekt"
Hier der übliche Ablauf eines solchen Dilemmas:
Business Case: In der Regel äußerst dünn. Wer auch immer geistiger Vater dieses Desasters ist, tut, was bestimmte Manager eben seit Anbeginn der Zeit tun: Sie jonglieren solange, bis der ROIROI stimmt und überzeugen sich dann erst einmal selbst, dass ihre Berechnungen angemessen und vernünftig sind. Oder spätestens dann realistisch, wenn man Glück und etwas Rückenwind mit einberechnet. Alles zu ROI auf CIO.de
Anforderungen: Die Einschätzung der Anforderungen und Spezifikationen eines Projekts wird mit steigender Projektgröße durch immer mehr unbekannte Variablen erschwert - von denen jede Einzelne die ganze Sache noch komplizierter macht. Diese Phase zieht sich in der Regel entsprechend. Aber schon okay, schließlich weiß ja jeder: Je durchdachter das Design, umso weniger Zeitaufwand braucht man für Coding und Testing. Da holen wir dann alles wieder auf.
Planung: Da das mit dem IT Alignment alles erste Sahne funktioniert, läuft auch die Planung verkehrt herum: Man beginnt also mit dem Auslieferungsdatum und erarbeitet sich dann im Rückwärtsgang den Plan, der alles zum Laufen bringen soll. Dieses Mal ist es der Projektmanager, der jongliert. Solange bis der Zeitplan plausibel aussieht. Zumindest solange niemand genauer hinsieht. Das wiederum wird aber keinesfalls passieren, schließlich bekommen die anderen Beteiligten genau das zu hören, was sie hören wollen.
Gelbphase: Der Projektstatus, in dem man dem Zeitplan bereits aussichtslos hinterherhinkt, vor der Deadline aber noch so viel Zeit ist, dass die Verleugnung der Realität noch den Schneid abkauft. Gewandte Projektmanager greifen in diesem Stadium zu zweierlei Maßnahmen: 1. Sie ziehen die Testing-Phase in die Länge, was die Projektampel auf grün springen lässt; 2. Sie machen sich auf die Suche nach einem neuen Job, bevor das Projekt ihre Reputation versenken kann.
- 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.
Level 1 Testing: Diese Phase besteht darin, das Niveau von "gut genug" weit nach unten hin abzusenken. Sind die Standards lax und der politische Einfluss groß genug, kann schließlich auch das erschreckendste Stück Code in die Produktion gezwungen werden.
Level 2 Testing: Sie testen und testen und testen. Gründlich und sorgfältig. Die Frage ist nur, ob sich das abspielt, bevor oder nachdem die Software in die Produktion geht.
Das Ende vom Lied: Der neue CIO bereinigt das Trümmerfeld. Sein Vorgänger schiebt die Schuld auf den Projektmanager. Der besucht unterdessen PMI-Meetings in Dauerschleife.