Hilfe beim IT-Projekt
10 Symptome für brennende IT-Projekte
Alles ist seit langem fast fertig. Es fehlt nur noch eine Funktion.
Die Deadline ist nur zu schaffen, wenn Sie die Tests verkürzen.
Wichtige, gestresste Personen werden plötzlich krank.
Es treten im Projekt erstaunlich wenige Fragen auf.
Die gewählte Technologie wird mitten im Projekt in Frage gestellt.
Zu Projektende werden zusätzliche Entwickler:innen ins Team geholt.
Beim Testen werden keinerlei Fehler gefunden.
In Ihrer Kaffeeküche brodeln viele Gerüchte über das Projekt.
Es werden laufend Sündenböcke gesucht.
Es ist unsicher, ob alles bis zum geplanten Release-Termin fertig wird.
Kommt Ihnen das eine oder andere Symptom bekannt vor? Dann wird es Zeit, Hilfe zu holen!
Was zu tun ist
Wir empfehlen in einem solchen Fall folgendes Verhalten:
Ruhe bewahren
Ruhe bewahren
Alle Beteiligten mit ins Boot holen
Die Wahrheit über den Status finden und aussprechen
Kurzphasig arbeiten: Wenige, angefangene Dinge wählen und diese zu 100% fertigstellen
Schrittweise Release der restlichen Funktionalität in kurzen Abständen
Apropos Wahrheit: Ein Gedanken-Experiment
Machen Sie mit uns zunächst ein Gedanken-Experiment zum Thema Stress, Offenheit und Anforderungsdefinition:
Sie haben bereits seit mehreren Wochen starke Kopfschmerzen und entschließen sich, endlich zu einem Spezialisten zu gehen.
Der Arzt fragt Sie, wie Sie sich fühlen, wo genau und in welchen Situationen es Ihnen weh tut. Sie antworten ihm, dass das zu peinlich und zu persönlich sei, um mit einem Fremden darüber zu sprechen.
Sie haben den Fehler in diesem Beispiel bestimmt erkannt. Natürlich würden Sie dem Arzt alles über Ihre Kopfschmerzen erzählen! Sie erzählen dem Arzt so viel wie möglich, damit er eine richtige Diagnose stellen und die richtige Therapie für Sie finden kann. Er soll nicht erraten müssen, was Ihnen fehlt.
Die unangenehme Wahrheit
Aus ganz menschlichen Gründen ist es schwierig, bei Projekten, die schlecht laufen, einem Software-Dienstleister gegenüber ähnlich offen zu sein.
Es ist hart, etwaige Fehler oder ungeeignete Projektplanung einzugestehen. Man will das Projekt "so rasch wie möglich" und "ohne Staub aufzuwirbeln" wieder auf Schiene bringen.
Auf der anderen Seite ist es auch für den externen Dienstleister bequemer zu raten als unangenehme Fragen zu stellen (oder gar das Risiko einzugehen, als "der falsche Lieferant" eingestuft zu werden).
Truth & Trust in IT-Projekten
Wir beginnen in schwierigen Situationen mit einer "Truth & Trust"-Phase: Es gilt wieder Vertrauen aufzubauen und die Wahrheit über den aktuellen Projektstatus und die eigentlichen Ziele herauszufinden.
Dabei setzen wir auch Frage- und Analysetechniken aus der "Systemischen Beratung" ein, immer mit dem Ziel das Wesentliche in der jeweiligen Situation in den Vordergrund zu stellen. Oft finden wir dabei einen verdeckten Auftrag (sprich: ein Problem, das uns der Auftraggeber entweder nicht mitgeteilt oder selbst nicht erkannt hat).
Anschließend werden die wichtigsten Probleme gelöst bzw. wichtige Funktionen umgesetzt. Dafür eignet sich besonders eine agile Vorgehensweise mit mehreren aufeinanderfolgenden Umsetzungszyklen und schrittweiser Abnahme durch den Auftraggeber.
Ein Beispiel für ein Softwareprojekt, das wir retten konnten
Ein Unternehmen ließ bei einem Mitbewerber eine Individualsoftware entwickeln (Budget € 40.000). Das Projektende verzögerte sich um stattliche 6 Monate.
Eine unfertige Software wurde abgeliefert, viele Funktionen waren angefangen, aber keine war fertig und nutzbar. Auf einer Betriebssystem-Plattform stürzte die Software sogar bereits beim Start ab und war daher nicht einsetzbar.
Als das Unternehmen uns fragte, ob man hier noch etwas retten kann, taten wir folgendes: Wir wählten gemeinsam mit dem Kunden zwei kleine, aber extrem wichtige Funktionen aus, die zuvor für den Mitbewerber unlösbar waren.
Diese setzten wir in zwei einwöchigen Umsetzungszyklen um. In dieser Zeit konnten wir einander und das Projekt kennenlernen und Vertrauen aufbauen.
Wir boten unserem potentiellen neuen Kunden folgendes an: Am Ende der zwei Wochen sieht er, ob die Umsetzung der Funktionen seinen Erwartungen entspricht. Erst dann entscheidet er, ob er uns als seinen neuen Softwarepartner mit der Rettung des Projekts beauftragt.
Gleichzeitig konnten wir in diesen zwei Wochen auch herausfinden, ob das Projekt tatsächlich noch zu retten ist.
Schlimmer kann's nicht werden
Natürlich waren diese zwei Wochen sehr stressig für alle Beteiligten. Manche Fragen und Erkenntnisse waren dabei unangenehm.
Wer nun denkt, dass es in derartigen Situationen viel schwieriger zu arbeiten ist, als bei einem klassischen Projektstart, irrt jedoch: Es kann nämlich nicht mehr schlechter werden und es ist nicht mehr nötig, Beteiligte vom Ernst der Lage und der Notwendigkeit einschneidender Maßnahmen zu überzeugen.
Es muss erlaubt sein, alles auf den Kopf zu stellen, um das eigentliche Ziel – eine für den Kunden wertvolle und nachhaltige Lösung zu schaffen – zu verfolgen.
Die Geschichte nahm ein gutes Ende: Die beiden einwöchigen Zyklen waren erfolgreich und das Projekt wurde danach auf Basis aller Erkenntnisse mit ganz klar definierten Zielen und neuem Zeitplan gestartet. Wir konnten die Software wie geplant umsetzen und diese ist nun seit einiger Zeit beim Kunden im Einsatz.
Leider kämpfte unser Kunde längere Zeit um das Geld, das der Mitbewerber für das zuvor fehlgeschlagene Projekt schon erhalten hatte – was bei Individualsoftware-Projekten ein langwieriger Prozess inklusive Gutachter ist.
