Foto: Kaspar Grinvalds - shutterstock.com
Wenn ganze IT-Abteilungen auf den Abgrund zusteuern, kann das vielerlei Gründe haben - unter Umständen aber auch daran liegen, dass "Industry Best Practices" adaptiert wurden. Manche dieser Empfehlungen aus der Praxis sehen nämlich in einigen Fällen nur aus einem Kilometer Entfernung sinnvoll aus.
Je näher man jedoch kommt, desto offensichtlicher wird, dass statt IT-Erfolg ein saftiger Fail winkt. Wir haben 13 Worst Practices für Sie zusammengetragen, die IT-Abteilungen unter allen Umständen vermeiden sollten.
Kunde fällt aus
Wollen Sie einen Fail herausfordern? Dazu müssen Sie lediglich sicherstellen, dass sich jedes Mitglied Ihres IT-Teams gegenüber allen anderen Abteilungen als Dienstleister ausgibt, der versucht mit Sprüchen wie:
"Ich betrachte dich als meinen Kunden.";
"Mein Job ist es, deine Erwartungen zu übertreffen";
oder noch schlimmer: "Ich möchte dich glücklich machen";
Eindruck zu schinden. Mitarbeiter anderer Abteilungen sind nämlich keine Kunden der IT, sondern deren Kollegen. Darum sollten sie sich auch auf Augenhöhe begegnen.
Die Idee vom Internal Customer weist der IT eine unterwürfige Rolle zu. In der hat sie zu tun, was den "Kunden" glücklich macht - ganz egal, ob das nun Sinn ergibt oder auf Geschäftsziele einzahlt. Ganz davon zu schweigen, ob den als dienstbarer Dienstleister auftretenden IT-Spezialisten seine Rolle mit Glück erfüllt.
SLA-Contracting
Wollen Sie mal ein bisschen Schaden anrichten? Dann ziehen Sie formale Service Level Agreements auf. Anschließend bestehen Sie darauf, dass alle Internal Customer diese unterzeichnen. Fertig. Denn ist der Vertrag erstmal besiegelt, muss er auch zu jeder Zeit voll und ganz erfüllt werden.
Um die IT-Abteilung mit in den Abgrund zu reißen, empfiehlt es sich, Streitgespräche anzuregen. Im Idealfall darüber, ob die internen Kunden (schönes Wording, oder?) Recht damit haben, wenn Sie sich darüber beschweren, dass die IT nicht das tut was sie soll. Eine erquickende Art und Weise, Beziehungen sämtlicher Art auf maximaler Distanz zu halten.
Gute Beziehungen - beruflicher wie privater Natur - sollten auf Vertrauen basieren. Das wird im beruflichen Umfeld allerdings nicht dadurch erzeugt, die Kollegen nicht als Kollegen zu betrachten: Oder arbeiten Sie gerne mit Leuten zusammen, die ihnen unsympathisch sind? Dazu wird es nämlich kommen, wenn die Service Level Agreements als festes Vertragswerk verstanden werden, die die zwischenmenschlichen Beziehungen definieren. Stellen Sie einfach einmal vor, welche Folgen fehlendes Vertrauen im Fall eines ernsten IT-Notfalls nach sich ziehen kann.
DAU-Shaming
DAU-Stories kennt (und liest) wohl jeder gern. Auch wir:
Problematisch wird das Ganze, wenn die IT-Mannschaft solche Stories mit den Klarnamen der eigenen Kollegen verbreitet. Am besten Sie sorgen dafür, dass die Stories per E-Mail-Verteiler unter die Mitarbeiter gebracht werden. Schneller lassen Sie nicht erkennen, dass gegenseitiger Respekt in Ihrem Laden Mangelware ist.
Budget-Battle
Ein hervorragender Weg, die Inanspruchnahme der IT auszubremsen: Streit ums Budget. Dazu richten Sie idealerweise innerhalb der IT weitere Unterkostenstellen ein. Beispielsweise für CPU-Zyklen, SAN- und NAS-Storage-Nutzung, die Anzahl der Entwicklungsstunden oder Anrufe beim Helpdesk (Tipp: In 10-Minuten-Schritten abrechnen).
Schließlich existiert nichts, was die Collaboration mehr beflügeln würde als der Streit darüber, ob die Beträge auch akkurat in die richtigen Budgetbeutel geflossen sind.
ROI-Zwang
Wenn Sie erreichen wollen, dass erfolgskritische Projekte nicht finanziert werden, sollten Sie mit Nachdruck darauf bestehen, dass der IT-Governance-Prozess einen klaren, greifbaren ROI aufweisen muss. Das führt geradewegs in die Obsoleszenz - während Technologien, die den Fachbereichen dabei helfen könnten, die Kundenzufriedenheit zu steigern, nur belächelt werden. Ebenso wie die, die sich für deren Einsatz stark gemacht haben.
Nach mir die IT-Projekt-Sintflut
Eine weitere Erfolgsformel für IT-Fehlschläge besteht darin, den Projektabschluss so zu definieren, dass die IT-Arbeit getan ist, wenn die Software den Anforderungen und Spezifikationen entspricht. Wenn sich dann das Management beschweren sollte, dass die Software nicht so funktioniert, wie sie soll, sind Sie in einer traumhaften Position und können Sätze wie "Wenn die Software die Specs erfüllt, funktioniert sie auch so, wie sie soll." droppen.
Sollte das nicht zur erwünschten Wirkung führen, können Sie immer noch ausweichen auf: "Dann waren wohl die Anforderungen nicht richtig gewählt.". Der Fehler liegt jedenfalls nicht bei Ihnen, sondern ausschließlich bei denen, die die Spezifikationen abgesegnet haben.
Wenn Sie allerdings Interesse am Erfolg von IT-Projekten haben, sollten Sie diese am angestrebten Geschäftszweck ausrichten (beispielsweise die Sales-Effektivität erhöhen) und nicht an der Software selbst.
- 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.
Projekt-Sponsoren
In Projektmanagement-Kreisen gilt es als offenes Geheimnis, dass jedes Projekt einen Business Sponsor braucht, wenn es in Erfolg kulminieren soll. Wenn der Fail nur eine Frage der Zeit sein soll, bestimmen Sie einfach einen solchen Sponsor.
Projektsponsoren - also echte Sponsoren, nicht solche, die nur so heißen - brennen dafür, dass ihre Projekte erfolgreich sind und sind auch bereit, dafür Risiken einzugehen. Ein Mensch, dem diese Rolle zugewiesen oder unter Umständen sogar aufgezwungen wird, dürfte diese Motivationslage sehr wahrscheinlich vermissen lassen.
Head in the Clouds
Eine Cloud-Computing-Strategie kann ebenfalls den Pfad zu einem beachtlichen IT-Fail eröffnen. Zumindest wenn von der Strategie auf die Lösung geschlossen wird: Sie müssen ja in die Cloud, darum ist Sinn und Zweck der Strategie, dort hin zu kommen. Auf keinen Fall sollten Sie den Fehler begehen und über diesen Sachverhalt länger als nötig nachdenken. Verdrängen Sie einfach Dinge wie Architekturfragen oder Terms of Services. Das führt am Ende nur dazu, dass Sie irgendwann auf den Gedanken kommen, die Services wären das, was Sie brauchen und die Cloud nur der Weg zum Ziel.
Soll das mit der Cloud-Strategie hingegen etwas werden, gilt die alte Regel: Form follows function. Und Services sind in diesem Fall die "functions", die unter Umständen in cloudifizierter Form verwirklicht werden.
Agiles Offshoring
Agile Methoden haben viele Vorteile. Damit sie zum Erfolg führen, ist ein hohes Level an informeller User-Beteiligung unabdingbar, damit Kurskorrekturen zwar in hoher Frequenz möglich sind, aber klein ausfallen, die Entwickler jeden Tag Fortschritte sehen können und auch das User-Akzeptanz-Testing nicht zu kurz kommt. Offshoring bringt einen wesentlichen Benefit: geringere Kosten. Was allerdings nicht läuft, ist ein hohes Level an informeller User-Beteiligung.
Wenn Sie nun zwölf verschiedene Zeitzonen mit Sprachbarrieren, kulturellen Unterschieden und Videokonferenzen als einzige Interaktionsmöglichkeit kombinieren, wird es mit dem Agile-Erfolg diffizil.
Natürlich lässt sich auch Agiles Offshoring bewerkstelligen, aber das ist ein komplexes Unterfangen und keinesfalls für IT-Abteilungen geeignet, die im Agile Game noch neu sind. Ist das der Fall, sollten Sie sich zwischen Agile und Offshoring entscheiden.
Unterbrechungspotenzierung
Nachhaltige IT-Fails lassen sich auch erzeugen, indem Sie darauf bestehen, dass jeder im Team Multitasking betreibt. Schließlich ist die Fähigkeit, mehrere Dinge gleichzeitig zu tun, äußerst erstrebenswert.
In der Realität ist ausuferndes Multitasking lediglich der Produktivität und Qualität abträglich und erhöht das Stresslevel ungemein. Wann immer Sie die Versuchung verspüren, ein Mitglied Ihres Teams darum zu bitten, sich mit etwas anderem zu beschäftigen, sollten Sie daran denken, dass Menschen nicht wirklich Multitasking-fähig sind. Das Beste was sie tun können, ist von einem Task zum nächsten zu wechseln. Jedes Mal wenn Sie das tun, geht dabei Zeit verloren, um sich mental neu auszurichten. Je mehr Konzentration eine Aufgabe erfordert, desto mehr Zeit kostet das "Switchen" zwischen den Tasks.
Projektitis
Wenn Sie sich zum Ziel gesetzt haben, dass alle IT-Projekte substanziell mehr Zeit in Anspruch nehmen, dabei mehr kosten und unterirdische Ergebnisse zu Tage fördern sollen - dann empfiehlt sich folgende Vorgehensweise: Sie starten bei möglichst dünner Personallage jede Menge neuer Projekte, um einfach alles was gefordert wird, umzusetzen und schieben ihre IT-Experten von einem Projekt zum nächsten.
Wenn Ihnen dagegen etwas daran liegt, dass Ihre IT eine gute Reputation vorweisen kann, sollten Sie nur eine Regel umsetzen: Jedes Projekt, das gestartet wird, wird mit voller Mannschaft gefahren. Das heißt: Projekte, die warten, bis alle Beteiligten daran arbeiten können, gibt es nicht.
Ewiges Schattenboxen
Keine Frage: Wenn Fachabteilungen hinter dem Rücken der IT-Abteilungen ihre eigenen technischen Lösungen einziehen, kann das verheerende Folgen haben. Das ist allerdings nur ein Teil der Geschichte. Die Fachbereiche greifen nämlich in der Regel auf DIY-Lösungen zurück, weil die IT nicht genügend Manpower zur Verfügung hat.
Dennoch ist es schon rein logistisch ein unmögliches Unterfangen, jede Form der Schatten-IT aus Unternehmen zu verbannen. Ganz zu schweigen davon, dass der IT in diesem Fall die Rolle des allmächtigen Verhinderers einnimmt, was ihrer Reputation alles andere als zuträglich ist.
Schwarz vs. Weiß
Zum Abschluss noch ein Dauerbrenner, wenn es darum geht die IT zu versenken: Antworten Sie auf Anfragen einfach immer mit Ja oder Nein. Letzteres führt zu sinkender Reputation und der Beschädigung von Arbeitsbeziehungen. Ersteres dazu, dass Sie Dinge versprechen, die Sie am Ende nicht halten können.
Die richtige Antwort wäre: "Das können wir machen - und zwar unter folgenden Voraussetzungen…"
So klären Sie über die Erfordernisse auf, die nötig sind, um die Erwartungen zu erfüllen, ohne dabei zuviel zu versprechen. Im Anschluss folgt dann auch eher eine Diskussion als ein Streitgespräch. (fm)