Selbstwahrnehmung

Wie CIOs sich selbst belügen

Kommentar  28.08.2017
Bob Lewis ist Management- und IT-Berater bei einem großen globalen IT-Dienstleistungsunternehmen. Die in dieser Kolumne geäußerten Ideen und Meinungen sind ausschließlich seine eigenen.
Wäre Achilles CIO gewesen - Selbstwahrnehmung wäre seine Ferse gewesen. Wir sagen Ihnen, wie IT-Entscheider das Unglück heraufbeschwören, indem sie 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.

Lügen ist menschlich. So belügen sich Chief Information Officer.
Lügen ist menschlich. So belügen sich Chief Information Officer.
Foto: Ollyy - shutterstock.com

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.

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.

Zur Startseite