«Projekte sind wie Handwerker und Familienbesuch:
Es freut einen schon, wenn sie kommen – und doch halt noch mehr, wenn sie endlich wieder gehen.» Alte Projektleitungsweisheit.
Dafür gibt es diverse Gründe. Hier ein paar nicht abschliessende Beispiele:
Störfaktor Projekt – Projekte sind Fremdkörper in den Zahnrädchen der Organisation. Sie verfolgen eigene Ziele, haben eine eigene Methodik und eine eigene Auftragslage.
Genau dafür gibt es sie – wenn sie nicht etwas anderes als was und wie die gewohnten Strukturen Themen angehen brächten, bräuchte man kein Projekt. Bequeme Nachbarn sind sie dabei für die Regelstruktur aber nicht.
Stiefkind Projekt – Viele Projekte erblicken nur das Licht der Welt,
– weil es mit „Dann nennen wir es halt Projekt“-Etikett eventuell ausser der Reihe ein zusätzliches Budget gibt,
– weil das Thema unangenehm ist, ein Risiko des Scheiterns besteht oder Geliebtes/Bestehendes in Frage gesetellt wird und niemand aus der Linie sich das auf die Fahne schreiben und zuständig sein möchte oder
– weil im Regelsystem relevantes KnowHow fehlt.
Schon bevor so ein Projekt geboren ist, will es eher eine Mehrheit gar nicht haben.
Bedrohung Projekt – die Geschichte mit der Zuständigkeitsfalle. Was ein Projekt darf und wo die Regelhierarchie entscheidet, ist oft eine ungeklärte Grauzone mit Potential zum dauerschwelenden Konflikt.
Stresstreiber Projekt – Projektteams haben eigene Deadlines. Die Teammitglieder arbeiten oft teils im Projekt und teils an ihren Regelaufgaben. Und rund um Projekttermine ist der Spagat der Einzelnen zwischen Projekt und Stammorganisation besonders heftig und für die Personen und beide Systeme belastend – Schuld ist dann das jeweils andere, zumindest in der Wahrnehmung.
Start-up-Gründung ‘Projekt’ – ein Projekt ist eine temporäre eigene Organisation in der Organisation
Ein „echtes“ Projekt hat eine eigene Zielsetzung, eine eigene Leitung, eigene (Entscheid-) Strukturen, eigenes Personal, eigene Hierarchien, eigenes Budget, eigene Methoden, eine eigene Zeitrechnung. Ein eigenes Management – ‘Projektmanagement’ nämlich. Und einen Anfang und ein Ende.
Das ist Aufwand. Wenn man es wirklich ernst nimmt und macht, ist das sogar richtig viel Aufwand.
Merke: ein Projekt lohnt nur, wenn all dieser Aufwand sich lohnt – und echte Vorteile bringt.

Diese Vorteile sollten formuliert werden und nennen sich ‘Projektauftrag’ :-D.
All das unterscheidet es von der es umgebenden Organisation. Das bedeutet auch, es muss sich gegen sie schützen. Und gleichzeitig natürlich mit ihr zusammenarbeiten. Das nachstehende Bild kann dabei vielleicht helfen:

Eins nach dem anderen:

Ein Projekt braucht, insbesondere zu Beginn, eine eigene Teambildung, eigene Regeln und Strukturen, eine eigene Identität, die eng mit dem Projektprodukt zusammenhängt – und Freiraum. In der Regel wird ein Projekt einberufen, um etwas zu tun, zu erfinden, umzusetzen, einzuführen etc. wozu das Regelsystem nicht in der Lage ist. Oder etwas, das die Regelstruktur nicht abbilden kann, weil das Thema zwischen den Zuständigkeiten liegt. Und/oder, weil etwas entwickelt werden soll, das es so noch gar nicht gibt und von dem noch nicht genau klar ist, wie genau es aussehen word und wie der Weg dahin sein könnte. So etwas kann die Stammorganisation oft nicht einfach so leisten – ein Projekt hat (oder sollte haben) da mehr Bewwegungsspielräume.
Das heisst, das Projekt muss «aufmachen», aus dem Alltag und dem engen Rahmen heraustreten, sich als schlagkräftige Organisationseinheit aufstellen, ergebnisoffen Ideen, Potentiale, Möglichkeiten und Varianten entwickeln, sich zielgerichtet spezifisch schlau machen. Diesen Startfreiraum muss es schützen, nützen und notfalls zu verteidigen bereit sein.

Gleichzeitig ist es so, dass das Projekt ein Produkt «baut», das, wenn es denn gebaut ist, das Ende des Projektes markiert. Und das Produkt dann dem Regelsystem gehören wird. Das heisst, das Projekt darf das Zielsystem nicht aus den Augen verlieren, muss dessen zukünftige (und nicht etwa die derzeitigen….) Produktbedürfnisse zusammen mit der Stammorganisation also herausfinden, kennen(lernen) und darf sicher nicht an ihr vorbei arbeiten.
Bei allen Projekten – und bei agilen ganz besonders – spielt die Musik in der Bewirtschaftung des blauschraffierten Bereichs:

Nach dem eher vehementen Freiraum ganz links kommt der Moment, wo das Projekt sich dem Regelsystem wieder annähern muss und auf es zu arbeitet – bis hin zu dem Punkt, wo die Stammorganisation immer mehr den Stab übernimmt. Im Bild oben wird dieser Moment schön durch die orangenen Linien gezeigt, an denen jeweils die beiden Wirkdreiecke produzierendes Projekt > und abnehmende Organisation < sich treffen und Verantwortungen und Gestaltungsmächte neu organisiert werden. In der Realität sieht man solche farbigen Linien leider keine und ist es hohe Kunst des Projektmanagements und braucht viel Projekterfahrung, diese Zeitpunkte der Bedeutungswenden zu erkennen. Und entsprechend adäquat zu handeln.
Matchentscheidend und wichtig (vielleicht DER wichtigste Moment in der Lebensdauer und Reifekurve eines Projektes) ist an der ersten orangenen Line: der Moment, an dem das Projekt der Stammorganisation aufzeigen muss, dass bezüglich des Projektproduktes das Leitmotiv des Geltenden endet und die begleitete Trauerarbeit beginnt – auch wenn das zukünftige Baby noch gar nicht geboren ist.
Wie es im Moment getan wird beeinflusst nicht automatisch die Produktentwicklung. Der Abschied vom Alten hat bereits begonnen…
Selbst wenn man den Moment erwischt: Eine sehr schwierige Zeit für Projekte und ihre Leitung. Eben zurück aus dem projekteigenen Freiraum, dem Zielsystem das Ende des bekannten und sicheren ankündigen, dessen Trauerarbeit begleiten, das Neue erst entwickeln mit einer noch jungen Projektorganisation. Und dem eigenen Ende dabei immer ins Auge blicken.

Was Projekt und Umsystem hier hilft, ist ein formuliertes «Übergangsreglement» – mit Verfallsdatum: Wenn alle Beteiligten wissen, dass für eine zeitlich befristete, überschaubare Weile mit eigens gemeinsam von Projekt und beteiligtem Regelsystem formulierten Übergangsregeln, die situationsangepasst und adaptiv oder gar agil sind, gelten, bietet das die von allen Beteiligten dringend benötigte Sicherheit, Klarheit, Orientierung …. Bei manchen allfällig sogar Freude am Ausprobieren und Erfahrungen sammeln – weil es ja automatisch wieder aufhört. Und erleichtert die temporäre Koexistenz zwischen Projekt und Regelorganisation immens.
Liebe Veronika, das ist wunderbar treffend auf den Punkt gebracht. Genau diese Erfahrungen haben wir auch gemacht und das aktuelle Großprojekt – Einführung der eAkte – steht gerade an dieser Nahtstelle zwischen Projekt und Linie und wir suchen aktuell nach der richtigen Stelle und den richtigen Ansatz, den Übergang von Prozessen, die das Projekt aufgesetzt hat und noch aufsetzt, in die Linie zu übernehmen, sie weiterzugestalten bzw. qualitätszusichern. Das ist wirklich nicht leicht. Das Ende muss laufend mitgedacht und auch in der Linie dafür gesorgt werden, dass jemand den „Ball“ gut übernehmen und weiterspielen kann. Das Projekt wiederum stößt an die teils zurückgelehnten Erwartungshaltung der Praxis, nach dem Motto, das Projekt wird schon alles mundgerecht anreichen… Natürlich ist auch die Praxis neben dem Alltagsgeschäft kaum in der Lage, sich den Neuerungen zu widmen und mitzulaufen. Diese eAkten-Projekte, egal wo, sind ja immer Operationen am offenen Herzen einer Organisation und beschleunigen zudem einen Kulturwandel, den wir so einfach nicht zeitgleich erzwingen oder großartig beschleunigen können, damit alles hübsch zusammenpasst.
Dein Beitrag beschreibt unsere Lage und das Dilemma von Projektarbeit wirklich sehr gut und vor allem anschaulich, dank deiner Grafiken – ich werde damit in meinem Bereich noch ein paar Kolleg*inn*en beglücken.
Danke für diesen Beitrag!
LikeGefällt 1 Person