Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03533.jsonl.gz/2239

In Diskussionen über Projekte wird meist so getan, als gäbe es das Phänomen „Projekt“ schlechthin. Manchmal kennen sich die Diskussionsteilnehmer aber nur in ihrer Projektart aus und schliessen dann aus ihren Erfahrungen unzulässig auf andere Projektarten.
Das ist auch nicht verwunderlich. Ein Projekt dauert oftmals mehrere Jahre. Wenn es erfolgreich war, wird der Projektmanager in einem ähnlichen wieder eingesetzt. Bis er um die zehn Projekte durchgeführt hat, sind 20 bis 30 Jahre vergangen. Dann hat er grosse Projekterfahrung, aber eben meist ausschliesslich in dieser einen Projektart.
Man kann Projekte nicht schubladisieren
Projekte so verschieden, wie Gebäude. Das Projektmanagement verschiedener Projekte unterscheidet sich, wie das Leben in verschiedenen Gebäuden. In einem Einfamilienhaus zu leben „fühlt“ sich ganz anders an, als in einem Hochregallager zu arbeiten. Für den Betrieb eines Spitals gilt das Augenmerk auf anderen Dingen, als es für den Betrieb einer Universität. Niemand käme auf die Idee, das Management einer Schule mit demjenigen eines Hochregallagers auf einen Nenner zu bringen, nur weil es in beiden z.B. eine Eingangstüre gibt.
Nur betreffs Projektmanagement ist man immer noch der Überzeugung, dass es einen gemeinsamen Nenner geben muss. Warum unterscheiden wir nicht deutlich zwischen so verschiedenen Dingen wie Strassen- und Hochbauprojekte oder IT-Entwicklungs- und Migrationsprojekten?
Es spielt eine Rolle, ob der Auftraggeber unter demselben Dach ist oder nicht
Allenfalls wird zwischen IT- und Bauprojekten unterschieden, obwohl es viele IT-Projekte gibt, die näher an Bauprojekten sind, als an anderen IT-Projekten. Ein IT Entwicklungsprojekt gehorcht ganz anderen Gesetzmässigkeiten als ein IT Migrationsprojekt. Diese Gesetzmässigkeiten werden noch viel zu wenig berücksichtigt, wenn es darum geht, ein Projekt zu beurteilen.
Kürzlich wurde im Fernsehen gezeigt, was es braucht, um einen Sender an den Olympischen Spielen zu installieren. Das Schweizer Fernsehen musste tonnenweise Kisten nach Sotchi verschicken, mit Dutzenden von Bildschirmen, elektronischen Geräten, Kabel, Stellwände, Kameras, etc. Material, das am Bestimmungsort angekommen ist, muss geprüft, installiert und getestet werden.
Das brauchte eine sehr professionelle Planung, Koordination und Projektleitung. Das Projekt ist eng verwandt mit einem IT Integrationsprojekt. Während für das TV-Projekt der Auftraggeber und der Projektführer zu derselben Unternehmung gehören, sind in einem IT-Projekt Auftraggeber und Projektführer zwei unterschiedliche Unternehmen, zwischen denen grundsätzlich Misstrauen herrscht.
Zwar haben in beiden Projekten die Auftraggeber Tausende von Endkunden, aber im TV-Projekt ist der Auftraggeber angestellt, während er im IT-Projekt eine Unternehmung ist, deren Existenz wesentlich vom Projekterfolg abhängt. Die Interessenlagen, Befindlichkeiten, organisatorischen Gegebenheiten, Machtstrukturen und Motivationen sind jeweils ganz verschieden.
IT heisst nicht einfach nur programmieren
Noch unterschiedlicher sind z.B. ein IT-Entwicklungsprojekt und ein IT-Migrationsprojekt. Auf ein Entwicklungsprojekt kommen hoffentlich 100 Integrations- und Migrationsprojekte, in welchen das einmal entwickelte Produkt ausgerollt und verkauft werden kann.
IT heisst nicht a priori entwickeln und programmieren. Der grössere Teil des „Kuchens“ nimmt eher der Betrieb ein. Obwohl Betrieb stetig und ohne Ende ist, wird er von vielen kleineren und grösseren Projekten begleitet. Jedes Mal, wenn ein System „end of life“ ist, muss es ersetzt werden. Das macht man in einem Migrationsprojekt. Da wird nichts entwickelt, sondern eingekauft, installiert, getestet und eingeführt. Das kann schon mal ein paar Monate dauern.
Fehler, die in den Tests manifest werden, müssen vom Produktemanagement wohl gefixt werden, aber das ist eher Produkteunterhalt und nicht mehr Entwicklung. Das Entwicklungsprojekt ist möglicherweise längst abgeschlossen, obwohl ihm die zutage geförderten Fehler angelastet werden müssten. Insofern weiss man beim Abschluss eines Entwicklungsprojekts nicht einmal, wie erfolgreich es war. Das ist in Bauprojekten völlig anders. Wenn die Brücke einstürzt, wir der Projektleiter zur Rechenschaft gezogen, während der Projektleiter eines Entwicklungsprojektes meist längst woanders arbeitet, wenn gravierende Produktefehler auskommen.
Die Umstände sind in jedem Projekt so verschieden, dass man nicht allgemeine Projektmanagementregeln aufstellen kann. Weder kann man behaupten, dass am Anfang eines jeden Projekts eine Breakdown Structure stehen müsse, noch dass jedes Projekt mit agilen Methoden durchgeführt werden kann. Das sind bloss undifferenzierte Betrachtungsweisen.