12 Fehler: Best Practices, die IT-Manager vermeiden sollten

 

 

Woran scheitern IT-Organisationen? Oft liegt es daran, dass IT-Entscheider sogenannte Best Practices übernehmen, die es eigentlich besser wissen müssten, es aber nicht tun – wahrscheinlich, weil sie die Aufgabe noch nie zu erledigen hatten. Vom Fokus auf interne Kunden über die Einführung von Verrechnungsmodellen bis hin zum Insistieren auf dem ROI sehen viele dieser Vorgehensweisen aus einer großen Flughöhe bisweilen plausibel aus. Wenn man jedoch unter die Oberfläche blickt, stellt man fest, dass diese todsicheren Erfolgsrezepte für die IT oft direkt in den Misserfolg führen.

Sie wollen scheitern? Stellen Sie sicher, dass jeder in der IT zu jedem außerhalb der IT sagt: “Du bist mein Kunde. Meine Aufgabe ist es, Deine Erwartungen zu übertreffen.” Oder noch schlimmer: “Dich glücklich zu machen.” Die Mitarbeiter außerhalb der IT sind nicht die Kunden der IT. Sie sind Kollegen der Menschen in der IT-Abteilung, mit denen sie auf Augenhöhe zusammenarbeiten sollten, wenn etwas Gutes für das Unternehmen als Ganzes herauskommen soll.

Da sich “digital” zum Mainstream entwickelt hat, ist die Informationstechnologie allgegenwärtig und in fast jeden Winkel des Unternehmens eingebettet. Daher haben smarte Führungskräfte den Glauben an die Metapher des internen Kunden verloren. Für sie ist die IT-Organisation ein integraler Bestandteil des Unternehmens, wie auch die Informationstechnologie selbst ein integraler Bestandteil der Produkte und Dienstleistungen ist.

Sie wollen Schaden anrichten? Stellen Sie formale Service Level Agreements (SLAs) auf, bestehen Sie auf der schriftlichen Zustimmung Ihrer “internen Kunden” und behandeln Sie diese SLAs wie Verträge. Jedes Mal, wenn ein interner Kunde dann behauptet, dass die IT nicht das tut, was sie tun sollte, wird darüber gestritten, ob das Service Level erfüllt wurde. Das ist der beste Weg, um die Beziehungen zum Business zu belasten. Wenn die IT ihre Service Level nicht erfüllt hat, was soll der interne Kunde dann tun: Sie verklagen?

IT-Manager sollten sich daran erinnern, dass Beziehungen Vertrauen voraussetzen. Dieses Vertrauen kann nur dann entstehen, wenn Sie Ihre Kollegen als echte Menschen anerkennen. Ist die Beziehung gut, werden sie mit Ihnen zusammenarbeiten, um alles, was schief läuft, in Ordnung zu bringen. Der Zweck von Verträgen besteht nicht darin, Beziehungen zu definieren – SLAs sollen festlegen, was passiert, wenn kein Vertrauen besteht und etwas ernsthaft schief läuft.

Dieser Ansatz ist ein hervorragendes Mittel, um IT-Anwender und Stakeholder abzuschrecken: Stellen Sie alle IT-Leistungen akribisch in Rechnung. Denn nichts fördert die Zusammenarbeit so sehr wie ein Streit über die Korrektheit von Rechnungen. Nur so lässt sich zweifelsfrei bestimmen, in welche Tasche des Unternehmens das Geld fließen soll.

IT-Manager haben zwei Alternativen: Einmal werden alle Kostenarten, die in den einzelnen Kostenstellen entstanden sind, sorgfältig aufgeschlüsselt – von CPU-Zyklen über SAN- und NAS-Speicher (natürlich getrennt) bis hin zu Entwicklerstunden und Helpdesk-Anrufen. Bei der zweiten Art der Kostenverrechnung werden die gesamten IT-Ausgaben des Unternehmens auf Pro-Kopf-Basis umgelegt, so dass es keinen Grund zum Streiten gibt.

Sicher, es ist schön, wenn ein vorgeschlagenes Projekt von sich aus eine positive finanzielle Rendite erzielt. Aber da die IT allgegenwärtig geworden ist, ist die Moral der ROI-Geschichte, dass die alte Denkweise über IT-Entscheidungen auf den Kopf gestellt werden muss: Informationstechnologie wird nicht mehr von Fall zu Fall genehmigt. Was von Fall zu Fall genehmigt werden muss, ist die manuelle Durchführung von Aufgaben. Hingegen sollte es als gegeben vorausgesetzt werden, wenn mit der IT automatisiert wird.

Sie wollen starke Reibungspunkte zwischen Business und IT schaffen? Definieren Sie Projekte zur Bereitstellung von Software so, dass die Aufgabe der IT-Abteilung erledigt ist, sobald die Software die Anforderungen und Spezifikationen erfüllt. Wenn sich Stakeholder darüber beschweren, dass die Software nicht das tut, was sie tun soll, sind Sie in einer perfekten Position: Sie können einfach argumentieren, dass die Applikation genau das tut, was “das Business” von ihr verlangt hat. Sie erfüllt schließlich die Spezifikationen.

Dass die IT allgegenwärtig geworden ist, bedeutet nicht nur, dass jeder die Produkte der IT nutzt. Es bedeutet, dass jeder, der IT-Produkte einsetzt, darüber nachdenkt, wie er die Informationstechnologie nutzen kann, um seinen Bereich des Unternehmens anders und besser zu gestalten.

Im Projektmanagement ist es allgemein bekannt, dass jedes Vorhaben einen Business-Sponsor haben muss, sonst hat es kaum eine Chance auf Erfolg. Aber meist ist das Gegenteil der Fall.

Echte Sponsoren, keine SINOs (“Sponsors in name only” – dem Namen nach), wollen aus tiefstem Herzen, dass ihr Projekt erfolgreich ist. Sie sind bereit, notfalls Risiken einzugehen, um den Erfolg ihres Projekts sicherzustellen, und setzen ihren Ruf für den geschäftlichen Nutzen aufs Spiel. Glauben Sie, dass jemand, dem die Rolle eines Sponsors zugewiesen wurde, dieses Risiko tatsächlich eingehen wird? Ich auch nicht.

Cloud Computing ist keine Strategie. Daraus wird oft gefolgert, dass jede Anwendung in der Cloud ausgeführt werden sollte, anstatt eine Entscheidung über Ihre technische Architektur zu treffen.

Eine gute technische Architektur sollte in Form von Services definiert werden. Die Dienste sind das, was Sie brauchen. Sicher, die Cloud könnte ein guter Weg sein, um einige von ihnen bereitzustellen. Aber alle? Vielleicht, vielleicht auch nicht. Die Form folgt der Funktion. IT-Services sind die Funktionen und die Cloud ist eine Form, die einige der von Ihnen benötigten Dienste annehmen könnten.

Agile Methoden haben viel zu bieten. Eine Voraussetzung für den Erfolg ist ein hohes Maß an informeller Beteiligung der Anwender, so dass geringfügige Kurskorrekturen häufig vorgenommen werden können, die Entwickler jeden Tag Fortschritte sehen und Benutzerakzeptanztests an der Tagesordnung sind.

Offshore hat einen klaren Vorteil: niedrigere Arbeitskosten pro Stunde. Was jedoch nicht für Offshore spricht, ist die Möglichkeit, den hohen Grad an informeller Beteiligung der Benutzer zu erreichen, auf den agile Arbeitsweisen angewiesen sind.

Berücksichtigt man mehrere Zeitzonen, Sprachbarrieren, eine kulturelle Kluft sowie Austausch in Webkonferenzen, dann erscheint Agile als eine noch größere Herausforderung. Es ist möglich, die Kombination zum Fliegen zu bringen, aber es ist nichts für schwache Nerven und ganz sicher nichts für IT-Organisationen, die Agile-Neulinge sind. Entscheiden Sie sich für einen Weg.

Bestehen Sie unbedingt darauf, dass alle Mitarbeiter Multitasking betreiben. Schließlich ist das eine höchst wünschenswerte Fähigkeit. Was Multitasking jedoch tatsächlich bewirkt: Produktivität und Qualität gehen runter, gleichzeitig steigt das Stress-Level beim Versuch, mehr zu schaffen.

Wenn Sie jemanden bitten wollen, seine Arbeit zu unterbrechen, um sich mit etwas anderem zu beschäftigen, denken Sie daran: Das Beste, was Menschen leisten können, ist der Sprung von einer Aufgabe zur nächsten. Jedes Mal, wenn sie das tun, verschwenden sie Zeit für das Um- und Hineindenken. Je mehr Konzentration eine Aufgabe erfordert, desto mehr Zeit wird bei einer Unterbrechung vergeudet. Wollen Sie, dass die IT-Abteilung erfolgreich ist? Lassen Sie die Mitarbeiter ihre Arbeit zu Ende bringen, bevor sie zu etwas anderem übergehen.

Die IT-Abteilung hat nie genug Personal, um das zu schaffen, was alle Fachbereiche wollen. Der normale Ansatz: Alles zu versuchen, um es trotzdem zu schaffen, indem man viele Projekte startet und Mitarbeiter zwischen ihnen hin- und herschiebt. Dies führt dazu, dass alle Projekte viel länger dauern, viel mehr kosten und minderwertige Ergebnisse liefern.

Wenn Sie wollen, dass die IT-Abteilung einen guten Ruf erwirbt, sollten Sie diese Regel aufstellen: Jedes Projekt, das gestartet wird, wird vollständig besetzt. Wobei “vollständig besetzt” bedeutet, dass das Projekt nicht darauf warten muss, dass ein Teammitglied verfügbar wird. Wenn Sie dies tun, wird jedes Ihrer Projekte abgeschlossen sein, während die anderen noch “viele Bälle in der Luft haben”.

Es steht außer Frage, dass schlechte Dinge passieren können, wenn Fachabteilungen ihre eigene IT einführen. Das scheint ein überzeugendes Argument zu sein, um Schatten-IT zu unterbinden, aber es ist nur ein Drittel der Geschichte. Das zweite Drittel: Die Fachabteilungen machen es selbst, weil die IT-Abteilung nicht genug Personal hat, um die (meist) kleinen Geschäftsprobleme zu lösen. Das bringt die IT-Abteilung in die unangenehme Lage, die Fachabteilungen zu zwingen, vieles in Excel zu erledigen, selbst wenn es bessere Alternativen gibt.

Das dritte Drittel? Viel Glück beim Versuch, den Sumpf der Schatten-IT trockenzulegen. Es ist schwer, den geheimen Einsatz von Cloud-Anwendungen zu erkennen. Sollte es der IT gelingen, die Schatten-IT auszurotten? Höchstwahrscheinlich wird die von der IT verhinderte Schatten-Funktionalität dann in einem anderen Projekt als “Scope Creep” angefordert.

Der letzte und beste Weg, die IT vor die Wand zu fahren, besteht darin, unabhängig von der Anfrage “Nein” oder “Ja” zu sagen. Wenn Sie verneinen, schaden Sie Ihren Beziehungen. Wenn Sie zustimmen, machen Sie Versprechungen, die Sie nicht halten können. Schließlich sind Sie und alle anderen in der IT bereits voll im Einsatz, weil Sie immer Ja sagen. Die richtige Antwort, wenn Sie erfolgreich sein wollen, lautet stattdessen: “Wir können das schaffen. Der Aufwand dafür ist… .”

Es gibt eine unumstößliche Regel für das Request-Management, ganz gleich, ob es sich um eine Änderung des Projektumfangs, eine Softwareerweiterung oder die Bereitstellung eines Tablets für jemanden handelt, der eigentlich kein Tablet erhalten sollte: Nichts ist umsonst. Sagen Sie nicht nein, sagen Sie nicht ja. Erklären Sie, was Sie tun müssen, um die Anforderung zu erfüllen. Was dann folgt, ist eher ein Gespräch als eine Auseinandersetzung. Und das ist strategisch wesentlich sinnvoller. (ajf/jd)