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 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 