COMPUTERWOCHE-Kommentar
Foto: Karin Quack
Was ist eigentlich ein erfolgreiches IT-Projekt? Die naheliegende Antwort: ein Projekt, das seinen Zeit- und Budgetrahmen einhält. Wirklich? Nein, selbstverständlich nicht. Das ist zwar schon sehr löblich - vor allem, wenn es sich um ein naturgemäß zur Proliferation neigendes IT-Projekt handelt. Aber ein Kongressvortrag ist ja auch nicht schon deshalb gelungen, weil der Redner exakt 45 Minuten gesprochen und in dieser Zeit den Raum nicht verlassen hat.
Wenn der Sprecher das Thema verfehlt oder ständig abschweift, sind die Zuhörer genervt und am Ende unzufrieden. Analog dazu ist ein erfolgreiches Projekt eins, das sich ans Thema hält, sprich: die Spezifikationen einhält. Das ist ja wohl das mindeste, werden Einige jetzt einwenden. Aber sie verkennen, dass sich vor allem in langfristigen Projekten die Anforderungen häufig ändern. Ein Projekt, das hier up to date bleibt, hat zumindest einen Teilerfolg errungen.
Doch es gibt durchaus Projekte, die formal alle Anforderungen erfüllen - auch die nachträglich gestellten - und trotzdem als gescheitert gelten müssen. Warum? Weil ihr Produkt nicht genutzt wird. Erst in der Anwendung des aus dem Projekt entstandenen Systems entscheidet sich, ob das Vorhaben seine Kosten wert gewesen ist. Das macht die "Wertbetrachtung" so schwierig.
McKinsey rät jedem Unternehmen, explizit einen Zuständigen für den Wertbeitrag der IT zu bestimmen. Aber wer sollte das sein? Ein Controller wird nur die messbaren Fakten betrachten. Eine strategische Erörterung à la "Wo stünde das Unternehmen ohne dieses Projekt"? liegt außerhalb seines Zuständigkeitsbereichs. Die Perspektive eines Fachbereichs-Managers ist naturgemäß durch den Abteilungshorizont eingeengt.
Der Wertbeitrags-Manager müsste eine Person sein, die genug technisches Know-how hat, um Projekte beurteilen zu können, aber gleichzeitig so viel vom Business versteht, dass sie die für das Unternehmen relevanten Verbesserungen wahrnehmen kann. Das klingt verdächtig nach der Definition eines guten CIOs. Der kann diese Aufgabe allerdings nur erfüllen, wenn er unbefangen an die Projekte herangeht. Voraussetzung dafür ist also eine strikte Trennung zwischen der Demand- und Supply-Seite der IT. (qua)