Projekte in der Krise VI

Die Übernahme von internen Fremdprojekten

Nachdem wir uns im letzten Beitrag damit beschäftigt haben, was alles bei externen Fremdprojekten schiefgehen kann, kommen wir nun zu den internen. Wo der Unterschied ist? Nun, zum einen sind die Kollegen meist noch greifbar. Zum anderen spielt hier aber auch ein gutes Stück Politik mit hinein und die Gefahr einem Kollegen auf die Füße zu treten.

Das Szenario

Gehen wir von folgendem Szenario aus. Eine Abteilung innerhalb des Unternehmens hat seit einigen Jahren bereits einen SharePoint im Einsatz. Es gibt jemanden, der sich recht gut damit auskennt. Das meiste hat er sich autodidaktisch beigebracht und auch für viele Probleme seiner Kollegen eine schnelle Lösung gefunden. Nicht immer ganz sauber, aber immer so, dass es weitergeholfen hat. Nun ist er jedoch an einem Punkt angelangt, indem die weitere Pflege dieser Plattform sich zeitlich nicht mehr mit seinen anderen Aufgaben vereinbaren lässt. Also soll die Site Collection (sprich die Webseite, auf der die Lösung betrieben wird) nun in die Obhut der internen IT übergeben werden. Wir als externe Consultants werden genau von dieser IT-Abteilung als Ratgeber mit dazu gezogen.

Die Herausforderung

Nun beginnt die eigentliche Aufgabe. Denn oft sind solche Projekte nur sehr schwer zu administrieren und zu erweitern. Wieso? Nunja, derjenige, der bisher den SharePoint erweitert und die Änderungen vorgenommen hat war kein IT-Spezialist, sondern ist in diese Rolle hineingewachsen. Für unser Beispiel war es ein Mitarbeiter der Buchhaltung und hat kleinere Tools und Lösungen für ebenjene Abteilung erstellt. Das Problem dabei ist jedoch, dass ihm damit auch das Handwerkszeug eines IT-Spezialisten fehlt. Das bedeutet, dass in der Regel alle Änderungen „mal schnell“ durchgeführt wurden und damit nichts dokumentiert wurde. Es gibt also keine Architekturübersicht, Anforderungsdokumente, Änderungshistorie oder dergleichen. Alles, was man vermutlich hat sind ein paar Änderungswünsche oder Fehlerbeschreibungen von der Abteilung.

Gut, immerhin ist der Kollege, der das Tool erstellt hat, noch verfügbar. Doch er hat diese Anwendung über Jahre erstellt und weiß selbst nicht mehr genau, wo er was nun gemacht hat. Das war ja schließlich auch der Grund wieso er es letztlich abgegeben hat. Denn all dies wird ihm zu viel und es würde die Abteilung inzwischen billiger kommen, wenn es durch den IT-Support betreut wird, als wenn man einen weiteren Kollegen ausschließlich für diese Seite beschäftigen würde. Das Problem des Beraters und der IT-Abteilung hier ist offensichtlich. Man muss versuchen möglichst viel Informationen abzugreifen und durch möglichst gezielte Fragen der Erinnerung des Abteilungskollegen auf die Sprünge helfen. Doch man sollte unter allen Umständen vermeiden den Kollegen zu sehr vor den Kopf zu stoßen oder seine Arbeit zu hart zu kritisieren. Das würde für Verdruss auf beiden Seiten sorgen und im Notfall zieht der Kollege die Reißleine und beschränkt seine Zusammenarbeit nur noch auf das Nötigste

Die Herangehensweise

Tatsächlich weiß der Kollege in der Regel selbst, dass er hier nicht das Gelbe vom Ei produziert hat. Schließlich kommt er selbst nicht mehr damit zurecht. Daher sollte man versuchen eine positive Art zu dem Kollegen zu finden. Ja, das Projekt ist nicht gut, aber die Aufgabe ist nun einmal gestellt und nun gilt es erst einmal eine Bestandsaufnahme zu machen. Anschließend muss man dann entscheiden wie es weitergeht. Wichtig ist vor allem, dass man hier nicht in schlechte Stimmung verfällt. Nur allzu leicht kann dies passieren, wenn man das Projekt zu nah an sich heran lässt oder es mit dem gewohnten Maßstab vergleicht. Entscheidend ist tatsächlich hier, dass man sich klar macht, dass es ein Hobbyprojekt war und der Kollege es gut gemeint hat. Nur mit dieser Einstellung kann man ein solches Projekt stemmen ohne sich selbst zu verschleißen.

Okay, wir gehen also positiv an die Sache heran (Tschakka!). Also machen wir als erstes mal eine Bestandsaufnahme um herauszufinden was überhaupt möglich ist. Welche Version ist im Einsatz, welche Features sind aktiviert, welche Third-Party-Tools finden Verwendung und wo hatte der Kollege welche Rechte. Mit diesen Fragen lässt sich das Tätigkeitsfeld erst einmal einschränken. Anschließend schauen wir uns die Probleme an, die mit der Anwendung gemeldet wurden. All diese Informationen erfassen wir jetzt natürlich sauber in unsere ALM Tool (z.B. dem TFS oder VSTS), damit die Erkenntnisse künftig sauber dokumentiert an einem Ort abgelegt sind.

Nachdem wir nun das Gefühl haben, dass wir zumindest die Rahmenparameter kennen und uns auch die Anwendung schon einmal angeschaut haben, reden wir mit dem Kollegen. Welche Probleme hat er mit seiner Anwendung behoben, an welche Änderungen kann er sich noch erinnern, wo sind die Knackpunkte an denen er gescheitert ist. Ich denke, in einem positiven (!) Gespräch kann man etwa 70-80 % der Applikation in Erfahrung bringen und die häufigsten Anwendungsfälle identifizieren. Natürlich schreiben wir auch hier wieder alles mit was wir erfahren und bringen es anschließend in eine geeignete Form, sodass wir auch künftig damit arbeiten können.

Gut, damit sollten wir jetzt zumindest schon einmal die wesentlichen Rahmendaten kennen. Wir wissen über die Technologie, die groben Strukturen der Applikation, die Probleme und auch über den Wissensstand des Kollegen bescheid. Daraus können wir also schon einmal herleiten, was er vermutlich getan hat und wozu er einfach nicht in der Lage war. Wenn wir dieses Wissen nun mit der Applikation und den aufgetretenen Problemen abgleichen können wir vielleicht schon das meiste identifizieren und benennen.

Die Übernahme

Der nächste Punkt ist dann der eigentlich Entscheidende. Ist das Projekt geeignet um die Probleme zu lösen, die es aktuell gibt und ist es möglich das Projekt auch in Zukunft sauber zu warten? Wenn nicht, macht es Sinn das Projekt neu aufzusetzen? Das wäre auch dann sinnvoll, wenn es ausreichend Änderungsvorschläge und Verbesserungspotenzial gibt, damit die Abteilung einen echten Mehrwert von der Weiterentwicklung hat. Gibt es dafür entsprechendes Budget und die Bereitschaft, dann ist dieser Weg zu bevorzugen. In der Regel ist es jedoch so, dass genau dieses Budget eben fehlt. Deshalb hat der Kollege ja angefangen alles in Eigenregie umzusetzen. Also was jetzt?

Die Lösung ist ähnlich wie auch bei externen Projekten. Man muss eine Kostenaufstellung machen. Dazu sollte man sich fragen, welche Laufzeit für das Projekt erwartet werden kann. Sind solche Zahlen nicht lieferbar würde ich von einer geschätzten Laufzeit von 5 Jahren ausgehen. Denn in der Regel wird eine Plattform innerhalb dieser Zeit durch ihren Nachfolger abgelöst und auch ansonsten ist der Zeitraum groß genug um zu zeigen wie groß die Initialen und die Folgekosten sind. Nun stellt man also die Initialen Kosten für die Übernahme bzw. für die Neuerstellung und den Betrieb für die nächsten Jahre gegenüber. Man nennt die Risiken bewertet diese mit Multiplikatoren. Am Ende werden 2 Zahlen herauskommen. Welche Kosten entstehen für die Übernahme bzw. Neuentwicklung des Projektes im vermuteten Zeitraum. Natürlich gibt es dort immer etwas Spielraum und die Zahlen sind nicht final. Dennoch bieten sie einen guten Einblick mit welcher Größenordnung gerechnet werden muss.

Ist diese Zahl weit jenseits der erwarteten und veranschlagten Kosten für das Projekt sollte man auch als IT-Abteilung bereit sein ein Projekt abzulehnen oder zumindest an die nächste Instanz zu eskalieren. Was passiert, wenn es zur Eskalation kommt, darüber werden wir uns in einem anderen Beitrag unterhalten.

Mehr zum Thema?

Projekte in der Krise IV

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?