Hallo @Klenner95!
Etwas grundsätzliches zur Unterscheidung zwischen Projekt und Prozess. Es ist ein bisschen was zu lesen, aber für alle zukünftigen Probleme und deren Analyse relevant.
Ein Projekt ist durch seine Einmaligkeit gekennzeichnet. Es enthält überwiegend komplexe Merkmale, also potentielle Überraschungen und Wendungen, denen man mit neuem Können begegnen muss. Für das Problem gibt es noch kein verfügbares Wissen, weder in der eigenen Firma, noch außerhalb.
Ein Prozess zeichnet sich durch seine für den Kontext gegebene Gültigkeit und Wiederholbarkeit aus. Er ist durch Wissen beschrieben, also nicht komplex sondern kompliziert. Ist das Wissen noch nicht im eigenen Unternehmen vorhanden, benötigt es neben der Beschaffung des Wissens einen neuen Prozess, aber kein Projekt.
Zur Unterscheidung "komplex" vs "kompliziert" gibt es hier ein sehr schönes, circa 15-minütiges Video von Harald Lesch in der ZDF-Mediathek.
Es handelt sich bei dem hier beschriebenen Problem nicht um ein "ungelöstes" Thema. Nur weil ihr das Wissen (noch) nicht in der Organisation habt, heißt das nicht, dass es ein neues Problem ist, für das es ein Projekt benötigt. Wenn sich jemand das Wissen aneignet, kann er den Prozess zur Umstellung befolgen, dafür benötigt es kein Projekt.
Für viele Probleme werden Projekte aufgesetzt, obwohl es das Wissen zur Lösung bereits gibt, nur eben noch nicht in der Firma. Ein Projekt ist für so einen Fall "mit Kanonen auf Spatzen schießen". Am anderen Ende des Spektrums hast du dann Leute, die tatsächliche neue Probleme mit vorhandenem Wissen lösen wollen, was ebenso schlecht funktioniert.
In deinem Fall sind sowohl die Ausgangslage als auch das angestrebte Arbeitsergebnis schon vor Beginn deiner Tätigkeit definiert. Das von dir angesprochene Risiko erhöht in einer "normalen" IT-Infrastruktur nur den Grad der Kompliziertheit und bringt keine echte Komplexität. Es ist in der Regel überschau- und planbar.
Die Komplexität kommt ggfs. bei einer gewachsenen Konzern-Infrastruktur mit Legacy-Systemen ohne Dokumentation und so vielen Wirkzusammenhängen, dass die Kompliziertheit nicht mehr von Menschen überschaubar ist. In so einem Fall, der ein Grenzbereich ist, könnte auch bei IT-Systemen imho von "echter" Komplexität sprechen.
TL;DR:
Verwendest du Methoden aus der Domäne "Projekt" für einen Prozess, verschwendest du im günstigsten Fall nur Zeit.
Verwendest du Methoden aus der Domäne "Prozess" für ein Projekt, riskierst du, das Problem nicht richtig zu identifizieren und die Ursache nicht zu lösen.
Gruß, Goulasz
P.S.: Die meisten Probleme sind nicht rein binär "komplex" oder "kompliziert", sondern haben Anteile beider Domänen. Hier ist es wichtig, vor Beginn der Bearbeitung durch eine Problemtransformation die Anteile klar zu trennen, um sich einen Überblick zu verschaffen. Dazu gibt es hier einen schönen Denkzettel auf dem Blog von Gerhard Wohland, dessen Buch "Denkwerkzeuge der Höchstleister" ich hier auf dem Blog schon vorgestellt habe.