Fallen in IT-Projekten
Ein Beispiel aus dem Alltag...
...in dem gleich mehrere Fallen zuschnappen:
Ein Kunde stellte fest, dass sein Team Dokumente völlig chaotisch auf Netzlaufwerken ablegt. Daraufhin fragte er eine Lösung mit Microsoft SharePoint bei einer externen Software-Firma an. Da dieser Dienstleister ein Experte für Microsoft SharePoint ist, freute er sich natürlich über die Anfrage. Schnell wurde ein passendes Angebot erstellt, basierend auf Erfahrungen aus zahlreichen erfolgreichen Referenzprojekten.
Aber nach der Fertigstellung besserte sich die Qualität der Ablage nicht. Immer noch speicherten die Mitarbeiter:innen die Dokumente irgendwie und ohne Plan. Nur eben jetzt auf Microsoft SharePoint.
Die Fallen, die im Beispiel zuschnappten
Zuerst hatte der Kunde im obigen Beispiel eine Fehldiagnose gestellt. Das Problem lag offensichtlich nicht an der technischen Lösung.
Es lag daran, dass keine Regeln existieren, wie und wo Dokumente abgelegt werden sollten. Und es wurde nicht definiert, welchen Nutzen man sich von der Ablage erwartet. Der Kunde tappte damit in die Selbstdiagnose-Falle.
Zweitens ist der Software-Dienstleister ein Microsoft-SharePoint-Experte und überzeugt, dass es die perfekte Technologie für das Dokumenten-Management ist. Er fragt beim Kunden nicht nach, welchen Zweck die neue Lösung speziell für ihn erfüllen soll. Dem Kunden wurde eine Lösung auf Basis der eigenen Erfahrung unabsichtlich eingeredet, weil sie bei anderen Kunden gut funktioniert hat – die sogenannte Experten-Falle schnappt zu.
Und drittens tappen Kunde und Dienstleister gemeinsam in die Mehr-vom-Selben-Falle. Die Ablöse der Netzlaufwerke durch Microsoft SharePoint ersetzt nicht die fehlenden Regeln zur Dokumentenablage. Ein Technologiewechsel allein wird hier sicher keine Verbesserung der Situation bringen (die Problem-Ursache bleibt weiter bestehen).
Nicht raten sondern beraten!
Was in der Unternehmensberatung schon lange Standard ist, sollte auch jeder Software-Dienstleister beherrschen: Individuelle Software- bzw. IT-Lösungen erfordern bereits vor der Angebotslegung eine passende Beratung.
Der Dienstleister muss über ein breites Beratungs-Skillset verfügen. Er muss auch wissen, wie man eventuelle "verdeckte" Aufgabenstellungen und Probleme identifiziert.
Im obigen Beispiel wäre die eigentliche (verdeckte) Aufgabe gewesen: Die Entwicklung von Regeln (und einer Unternehmenskultur) zur Ablage und zum Wiederfinden von Dokumenten, um diese anschließend mit geeigneter Software zu digitalisieren. Diese Regeln müssen definiert werden, bevor die eigentliche Software-Lösung spezifiziert wird, da sonst am Ende die Anforderungen des Kunden nicht erfüllt werden.
Manchmal ist es auch erforderlich, weitere Expert:innen ganz anderer Fachgebiete einzubeziehen, wenn sich die Sache nicht allein durch Technologie beheben lässt.
Die gefährlichsten Fallen in IT-Projekten im Überblick
Neben den schon erwähnten drei Fallen gibt es noch weitere:
Hidden-Player-Falle
Es existiert im System ein Player, der nicht auf den ersten Blick erkennbar ist. Er ist aber für die Erklärung des Systemverhaltens oder die Lösungsfindung sehr wichtig oder sogar notwendig.
Ein Beispiel dafür: Die Kommunikationsabteilung bereitet alles für das neue Intranet vor; tolle neue Features sind geplant. Das Projekt läuft schon, als die bisher nicht involvierte IT-Abteilung sich meldet. Sie stellt klar, dass aus technischen Gründen (z.B. fehlende Schnittstellen) bestimmte Funktionen überhaupt nicht umgesetzt werden können – und schon beginnt die Planung wieder (teilweise) von vorne.
Öffentlichkeitsfalle
Mitarbeiter:innen sind oft zurückhaltend, wenn es darum geht, ihre Meinung im großen Team (und im speziellem vor dem/der Chef:in) zu sagen. Manchmal werden dadurch Informationen zurückgehalten, die für das Projekt wichtig sind. Es lohnt sich daher, Gespräche mit einzelnen Mitarbeiter:innen alleine bzw. ohne Beisein von Führungskräften zu führen.
Storchen-Perspektive-Falle
Aus der Storchen-Perspektive übersieht man leicht wichtige Details, weil man "zu weit weg" vom eigentlichen Problem ist. Das kann zum Beispiel passieren, wenn man nur mit Mitarbeiter:innen in Leitungspositionen über ein Projekt spricht. Sie wissen oft über die Details nicht Bescheid.
Frosch-Perspektive-Falle
Aus der Frosch-Perspektive sieht man meist wiederum nur die ganz naheliegenden Dinge und verliert leicht den Gesamtüberblick. In diese Falle tappt man, wenn man zum Beispiel nur in einer einzelnen Abteilung die Umsetzung einer Softwarelösung bespricht und nicht die Gesamtkonsequenzen für das Unternehmen beachtet.
Hoffnungsfalle
Die Falle ist besonders für Softwaredienstleister gefährlich, die neu in der Branche tätig sind, oder wenn es darum geht, einen wichtigen neuen Kunden zu gewinnen: Seien Sie vorsichtig, wenn Sie Sätze hören wie "Wenn Sie zum Einstieg sehr günstig sind, werden Sie unser Stammlieferant!". Oder es kommt zur "Selbst-Beruhigung" im Sales mit folgenden Annahmen: "Das holen wir uns dann schon bei Erweiterungen und in der Wartung zurück!" oder "Das ist ein strategisches Projekt für uns, das machen wir kostenlos!".
Nachhaltig und mit Mehrwert
Die Individualsoftware- und IT-Branche ist seit langem keine Spielwiese mehr für technische Nerds und Geeks. Vielmehr ist ein analytisches und zielgerichtetes Vorgehen gefragt.
Heutzutage reicht es nicht mehr, dass eine Individualsoftware die vorgegebene Spezifikation und die Bedingungen im Angebot zu 100% erfüllt.
Vielmehr ist es das Ziel, eine Lösung zu entwickeln, die dem Kunden und den Anwendern:innen einen wirklichen Mehrwert bringt und nachhaltig zu einer Verbesserung beiträgt. Auch wenn das bedeutet, die Spezifikation öfters zu verändern und den Weg zum Ziel laufend während des Projekts anzupassen.
Agile Vorgehensmodelle, deren Merkmal ein fest integrierter Change-Management-Prozess ist, haben sich dafür bewährt. Neben der Anwendung agiler Methoden stellen wir auch mit interdisziplinären Skillsets aus der "klassischen" Beratung bereits in der Vorprojekt- und Spezifikationsphase sicher, dass Kunden nicht in gefährliche Fallen tappen. Schließlich ist es unser Ziel, Software zu entwickeln, die glücklich macht!