Wie ein Projekt seiner Ausbaustufe das Leben schwer machen kann
Puh. Es war ein harter Weg, doch das Projekt steht endlich. Wir befinden uns in der Abnahmephase. Einige kleinere Findings und Nice-To-Have-Wünsche hat der Kunde noch. Wir haben noch etwas Budget in unserem Projekt und diese letzten Aufgaben werden gerade realisiert. Der Business Consultant hat das Ohr direkt am Kunden und wir erfüllen diese neuen Anforderungen quasi in Realtime. Ein kurzes Meeting mit dem Kunden, eine Mail an den Entwickler und los. Der Kunde testet jede neue Funktionalität direkt am System. Damit das knappe Restbudget für die Extras noch reit, machen wir sie schnell direkt auf dem System, welches bald live gehen soll. Der Code wird dann anschließend gesammelt in das Quellcodeverwaltungssystem eingecheckt. Der letzte Code, der letzte Test, Booya!
Der GoLive verläuft weitgehend problemlos. Die Codes sind JavaScript und andere Frontend-Logik, die wir in das Produktivsystem eingespielt haben. Damit musste die Seite nun nur noch öffentlich bekannt gemacht und die Rechte für die Benutzergruppen gesetzt werden. Alles läuft weitgehend glatt. Kleinere Bugfixes im Livesystem werden ebenfalls zeitnah gefixt. Die Akzeptanz ist hoch, die Stimmung gut.
Die Zeit vergeht. Das System läuft stabil, die Endnutzer arbeiten damit und entwickeln neue Ideen für Verbesserungen und neue Use Cases. Da das System wichtig ist, hat das Steering Board die wichtigsten Vorschläge und neuen Anforderungen gesammelt und ein neues Paket geschnürt. Das Projekt geht in Phase II und aufgrund der guten Leistung sind auch wir wieder als Entwicklungs- und Consultingmannschaft mit dabei.
Leider ist das damalige Entwicklungsteam inzwischen in anderen Projekten eingesetzt und nur sporadisch erreichbar. Daher wird ein neues Team eingesetzt. Der Business Consultant und Projektleiter konnten glücklicherweise aus anderen Projekten abgezogen werden und somit stehen zumindest an der Kundenfront die gleichen Ansprechpartner. Ein mehr oder weniger typisches Setting für eine Folgebeauftragung also.
Die Phase II
Und so beginnt es von Neuem. Doch schon bei Beginn liegt Ärger in der Luft. Die Entwicklermannschaft hat sich in die Dokumente der Anforderungsphase eingearbeitet und auch die INT- und QA-Maschine angesehen. Irgendwie ist es passiert, dass in den Anforderungs- und CR-Dokumenten etwas anderes steht, als im INT-System umgesetzt wurde. Das QA-System scheint sich außerdem ebenfalls in einzelnen Aspekten vom INT-System zu unterscheiden. Zudem geistern immer wieder E-Mails von dem letzten Entwicklerteam durch den Raum, die noch etwas anderes verkünden.
Klar, es war ja etwas hektisch zu Projektende. Aber im Quellcodesystem sind ja die aktuellsten Sources hinterlegt. Dann erneuern wir INT- und QA-System eben. Und schon tauchen die nächsten Fragen auf. Scheinbar wurden die Codes ohne oder unzureichendem Kommentar eingecheckt. Auch lassen sich daraus keine Pakete mehr erkennen weil gleich mehrere Pakete auf einmal eingecheckt wurden. Also lassen sich daraus keine Rückschlüsse auf Änderungen und Bugs schließen und auch der aktuelle Stand lässt sich so nicht eindeutig ermitteln. Na schön. Also installieren wir alles und schauen es uns an.
Der Business Consultant drängelt inzwischen etwas, da er für die neuen Anforderungen gerne einige Konzeptpapiere erstellen würde. Doch dazu braucht er Daten aus dem Bestandssystem und auch einige Screenshots.
Und nun wieder das Entwicklerteam, denn es ist leider wurden auch noch einige Konfigurationen nicht aktualisiert und nun funktionieren einige Funktionen nicht. Schließlich muss ein Entwickler der letzten Phase aus einem anderen Projekt losgeeist werden, damit dieser die Konfigurationen einstellen kann.
All das verzögert leider auch unsere Phase II immer weiter und der Anfangs gute Eindruck des Kunden wird leider getrübt. Natürlich kann man die Aufwände durch entsprechende Mehrarbeit wieder hereinholen, doch nun müssen auch die Dokumentationen aus Phase I noch nachbereitet werden. Und da nicht mehr alle Anforderungen vorhanden sind und man sich dem Kunden gegenüber natürlich auch keine Blöße geben will, wird man nie völlig aus dieser Klemme herauskommen und immer wieder gezwungen sein Dinge nach zu dokumentieren und durch Mehraufwände auszugleichen.
Was kann man tun?
Die Lösung ist natürlich offensichtlich und greift die Prinzipien aus dem ersten Teil der Serie auf. Nicht nur ein Projektplan muss sauber erstellt werden, sondern auch alle Änderungen im späteren Prozess müssen nachgetragen und aktualisiert werden. Man sollte bei der Umsetzung eines Projektes immer auch den gesamten Application Lifecycle im Blick haben. Was passiert, wenn eine Phase II kommt, oder ich die Applikation ablösen und auf eine neue Plattform heben will? Wir profitieren selbst davon, dass wir sauber dokumentieren und auch neue Anforderungen nachhalten. Denn wenn man gute Arbeit geleistet hat, ist es sehr wahrscheinlich, dass ein Kunde auch für den Folgeauftrag wieder den gleichen Dienstleister auswählt, anstatt sich der Gefahr auszusetzen mit einem etwas günstigeren Anbieter neues Lehrgeld zahlen zu müssen. Im Idealfall wirkt sich saubere Arbeit also sogar auf den Tagessatz aus, da man einen guten Ruf durchaus auch mal etwas höhere Kosten ausgleichen kann.
Und im Detail?
Soweit die Theorie. Aber was kann man denn nun ganz konkret tun? Nun, ich empfehle das ALM-Tool Visual Studio Online (ehem. Team Foundation Server). Durch geringe Kosten, hohe Verfügbarkeit und gute Skalierbarkeit bietet dieses Tool nahezu für jede Anwendung optimale Voraussetzungen. Außerdem bietet es diverse Werkzeuge für das ALM-Management. Zum Beispiel bei der Erfassung von Requirements, Tasks, Bugs, Issues, Testcases und ähnlichem, oder bei der Planung von Teams, Sprints und Kanban Boards. Aber auch für die Abbildung großer Projekte mit unterschiedlichen Epics, Features und User Stories ist es gut geeignet. Außerdem kann man die erstellen Dokumente oder auch Quellcode direkt zu jedem dieser Elemente direkt referenzieren. Die Vorteile sind so vielseitig, dass es für eine eigene Serie reicht. Deshalb soll dies nur als Anregung gedacht sein, sich selbst zu informieren. Oder natürlich auf ebenjene Serie zu warten. 🙂
Mehr zum Thema?
- Projekte in der Krise I – Warum Projektplanung wichtig ist
- Projekte in der Krise II – Über Testmanagement und Qualitätsansprüche
- Projekte in der Krise III – Die Krux mit der Entwicklungsmaschine
- Projekte in der Krise IV – Das Problem mit der Ausbaustufe
- Projekte in der Krise V – Übernahme von externen Fremdprojekten
- Projekte in der Krise VI – Übernahme von internen Fremdprojekten
- Projekt Kick-Off
- Projektabschluss
ALM Tech Blog 
Für das Phase 2 Szenario gibt es definitiv noch eine Steigerung: Der Kunde hat Phase 1 selbst entwickelt und wirft einem dann sozusagen das halbgare Produkt mit einer „Bugliste“ – in IT-Sprache, ein Anforderungskatalog – über den Zaun. Das Produkt funktioniert zwar irgendwie, aber schon beim Aufbau der Lösung wurden wichtige Aspekte wie Skalierbarkeit, Wartbarkeit und Erweiterbarkeit einfach nicht berücksichtigt, weil die Ersteller von Phase 1 keine IT-Fachleute waren und daher von diesen Dingen nichts wissen. Der Kennsatz für solche Produkte ist „wir haben da schon was aufgebaut, das müsst ihr nur noch ein bisschen anpassen“. Bei dem Satz gehen bei mir alle Alarmglocken an. Denn, das Produkt ist ja schon „so gut wie fertig“ also müssen ja „nur noch ein paar Kleinigkeiten“ gemacht werden. Dafür braucht man ja dann auch nicht viel Budget oder gar Zeit… Diese „Übernahmeprojekte“ sind ein Garant für schlechte Stimmung sowohl beim Kunden, als auch im eigenen Team. Ich bin nicht bei einem Beratungsunternehmen angestellt, sondern bei einer unternehmensinternen IT-Abteilung und kämpfe immer wieder mit solchen Phase 2-Projekten. Oftmals ist die einzige Lösung dann die komplette Re-Implementierung, die zumindest die Stimmung im Team wieder hebt, allerdings nicht beim Kunden, denn er erkennt den Fortschritt unter der Haube zunächst nicht, bzw erst dann, wenn wieder schnell „ein paar kleine Änderungen“ gemacht werden sollen und diese tatsächlich schnell erledigt sind, oder er die Änderungen in einer Konfiguration selbst im laufenden Betrieb vornehmen kann. Bei einem Beratungsunternehmen ist das aber wahrscheinlich oft zu spät so dass der Todesstoß für die Geschäftsbeziehung zum Kunden bereits passiert ist. Wir in der internen IT können aber doch meist die späten Früchte einer wirklich professionellen Umsetzung ernten. Ich glaube zumindest fest daran. 😃
LikeGefällt 1 Person
Danke für die gute Anmerkungen. Mir derartige Projekte auch zur Genüge bekannt. Grundsätzlich müssen solche Projekte sehr behutsam angefasst werden. Beziehungsweise vor allem die Ersteller dieser Lösungen, da dort natürlich viel Schweiß und Arbeit hinein geflossen sind. Uns ist einmal der Fehler passiert, dass wir zu früh in der Projektübernahme von „Refactoring“ gesprochen haben. Das war für den Kunden ab da an ein rotes Tuch und er wollte davon gar nichts mehr hören weil „Das funktioniert doch Großteils und Refactoring ist viel, viel zu teuer!“
Da dieses Thema aber mit derartig vielen Fallstricken gespickt ist, würde ich es gerne in einem eigenen Beitrag behandeln. Ich freue mich auch da dann auf Erfahrungen und Anmerkungen! 🙂
LikeLike