Grundsätzlich sind Standards als Pauschalkonzept erstmal nicht zielführend.
Die allererste Frage muß aber sein: Welche Projekte habe ich denn zu betrachten?
Und: Wenn überhaupt, was soll denn auf welcher Ebene standardisiert werden?

Implizit schwingt immer der Gedanke vom „Standardprojekt“ mit. Das gibt es aber nicht. Es gibt Projekte, die sind in jeder Hinsicht einmalig, und erfordern Prozesse, die vorher niemand kennt. Andere Projekte haben eine sich wiederholende Grundkonstruktion, und werden erst durch die Umstände zum Projekt.

Bei letzteren gibt es aus meiner Sicht (Großanlagenbau) einen hohen Bedarf für Standards auf der PM-Ebene.

Projekte im Anlagenbau, wie ich sie kenne, ähneln einander sehr stark, wenn man mal unter die Motorhaube schaut.
Die technische Struktur variiert zwischen den Projekten nur insoweit sie das Endprodukt betrifft und wird ansonsten eher auf- und abskaliert. (Allerdings nicht linear; wichtiger Punkt aus den Lessons Learned)

Die kommerzielle Struktur ist meist vollkommen identisch, wenn man von den Eigenheiten des Exportgeschäftes mal absieht (und hier meine ich nur die finanzrechtlichen Vorgaben der betroffenen Länder, und noch nicht mal das Thema Compliance/Nützliche Aufwendungen).

Große Unterschiede gibt es dann aber im Projektumfeld (Land, Klima, Logistik, Kultur, Onshoreanteil (also Beschaffungsvorgabe für das Projektland)) und bei den Beteiligten (z.B. Claimfreudigkeit der Lieferanten, Umgang mit dem Kunden, Anzahl der Lieferanten, Anzahl der Baustellen, auch Anzahl der Kunden etc.)

Ein ausführlich geschriebener Projektauftrag mit vorgegebenen Inhalten z.B. ist extrem sinnvoll, wenn sich ein anderer Projektleiter einarbeiten muß. Hier hatte ich oft Probleme, wenn der Vorgänger gekündigt hatte (also zumindest vereinzelt noch erreichbar war) oder verstorben war (hier stellt sich die Kontaktaufnahme erheblich schwieriger dar).

Eine einheitliche Vorgabe für den PSP und standardisierte Ablagestrukturen, die sich an eben diesem PSP orientieren, erleichtern ebenfalls den Einstieg enorm, insbesondere bei Vertretungen.
Es hilft einfach, wenn alles da ist, wo es bei allen liegt.

Und vorgegebene Rahmenprozesse in Anlehnung an etablierte Standards helfen, auch Jung-Projektleiter in das Projekt zu bringen. (Das früher geläufige „Mitlaufen“, also das eigentliche „Training on the Job“ entfällt ja heutzutage aus Kostengründen)

Insofern sehe ich hier an Standardprozessen und Standardschnittstellen (zwischen Abteilungen, zum Rechnungswesen, zum Controlling, zum Lenkungsausschuß) überhaupt nichts Verwerfliches.
Ganz im Gegenteil bin ich der Meinung, daß das in unserem Geschäft hilft, sich auf das Wesentliche zu konzentrieren, nämlich die Arbeit mit dem Kunden und den Partnern, auf das Contract Change Management und nicht zuletzt auf das Risk Management.
Werden dann noch von zentraler Stelle (z.B. vom PMO) geeignete Vorlagen und Methoden angeboten, die der Projektleiter bzw. das Projektteam nutzen kann (!), dann wird das ein rundes Paket, in dem man einen weiten Bereich von Projekten gut und vor allem transparent abwickeln kann.

Ob ich ein Kraftwerk baue, eine Raffinerieanlage oder einen Solarpark – alle laufen bis zu einem gewissen Grad ungefähr nach dem selben Muster ab.
Ab da werden sie individuell und genau dort brauche ich im Projektteam die Aufmerksamkeit. Alles darunter muß laufen.

Gefährlich werden die Standards, wenn ich mich an ganz andere Projekttypen wage:
Wer bisher Chemieanlagen gebaut hat, wird kaum in der Lage sein, eine Softwareeinführung, geschweige denn ‑entwicklung zu betreuen.
Und wer Projektleiter im Automobilbau war, wird an Kraftwerken verzweifeln.

Hier sind andere Methoden und Prozesse gefragt. Damit verändern sich auch Möglichkeit wie Sinnhaftigkeit von Standards vollkommen.

Wo wir im Anlagenbau über ein gut ausgearbeitetes und praxistaugliches PM-Framework sprechen, kommen wir hier in den Bereich sehr weiter und vom Projektteam zu gestaltender Spielräume.

Letztlich ist hier die Frage, wie z.B. der Projektauftrag überhaupt aussieht:
Im Anlagenbau bekomme ich einen Stapel Spezifikationen, eine Summe Geld und ein Zeitfenster. Damit muß ich klar kommen, und im Laufe des Projektes an den Zielen, Anforderungen und Vereinbarungen feilen, bis ich am Ende einen Haken dran machen kann. Falls etwas gar nicht paßt, muß ich zum Kunden und mit ihm den Vertrag anpassen (Stichwort Contract Change Management)

Also ist meiner Meinung nach die Frage der Standardisierung genauso mit einer Gegenfrage zu beantworten, wie die Frage nach der PM-Methode:

Welche Variante paßt zu den Projekten, die wir durchführen?

Eine Pauschalantwort wird man nicht finden können, so sehr sich das die Vorstände auch wünschen.

Da hast Du leider recht: Eingeführt wird viel und abgeschafft nichts. Die Bürokratie wird irgendwann zum Selbstzweck. Vielleicht sollten wir in modernen Organisationen nur emergente Standards erlauben, also solche die aus der praktischen Arbeit in den Teams entstehen und sich durchsetzen, weil sie bei der Arbeit helfen. Schwierig wird es immer wenn Standards im Elfenbeinturm erdacht werden, nicht der Arbeit sondern der Administration nutzen und Vorgabecharakter haben.

Ich möchte trotz persönlicher Präferenzen nicht gleich das Kind mit dem Bade ausschütten. Daher hinterfrage ich gerne, ob Standards uns helfen unser System besser zu betreiben, welche konkrete Auswirkung die Einführung / Veränderung von Standards auf unser System hat. Das bedingt meistens, dass wir unser System überhaupt mal verstehen. Auf dieser Basis können Standards schon mal nicht in Eisen gegossen verstanden werden. Denn wir wollen ja das System immer effektiver gestalten – daher wollen wir es nicht mit Standards zumüllen, sondern sinnvolle Standards (z.B. hinsichtlich Qualitätsverständnis) fortlaufend weiter bewegen.

Ein Blick auf unser System (z.B. auf Lead Time Distributions, Durchsatz, Flow Efficiency, etc) hilft uns zu sehen, welche Auswirkungen Standards / Änderungen mit sich bringen. Aber wie gesagt: idealerweise nicht von oben aufgedrängt, sondern von möglichst autonom agierenden Teams / Mitarbeitern intrinsisch motiviert zum Einsatz gebracht und wieder hinterfragt.

Übrigens lässt sich hier eine gute Parallele zum Thema „Metriken“ ziehen. Diese werden idealerweise ebenso von Teams selbst entlang gemeinsamer Ziele gesetzt (siehe: Objectives & Key Results), dienen der Verbesserung des Systems und nicht der Angstbeschwichtigung der Führung, sind nicht leicht zu erreichen (also auch herausfordernd) und werden immer wieder hinterfragt, erneuert und auch verworfen.

Und ebenso wie bei den Standards tendieren bürokratische Organisationen dazu, Metriken nie zu verwerfen, sondern zu kumulieren und über die Jahre immer mehr und mehr zu messen, zu reporten, ohne sich noch daran erinnern zu können, warum eigentlich.

Aus meiner Erfahrung muss ich Dir leider recht geben. Wehret den Anfängen trifft es recht gut. Dem Projekt und dem Ergebnis nutzt der standardisierte Projektauftrag nicht, nur der Administration und Bürokratie. Und natürlich steht dahinter ein im Kontext von Projekten in der Wissensarbeit utopisches Bedürfnis nach Sicherheit und Stabilität einhergehend mit fehlendem Vertrauen in die Akteure. Im Prinzip sind wir ja einer Meinung, die Frage ist nur ob man ein bisschen Standard zulassen will, der Bürokratie wegen, oder lieber den Blödsinn ganz vermeidet.

Ich habe das Beispiel Spotify gebracht, weil sie sehr aktuell genau damit gebrochen haben. Ja, sie haben Standards. Aber diese sind dauernd in Bewegung und werden zwischen Teams „ausgehandelt“. Die machen z.B. Dinge wie Scrum, Kanban und beliebige Mischungen daraus. Allerdings entscheidet das Team, wonach es wirklich arbeiten will. Und dementsprechend gibt es beliebige Mischungen. Und das Unternehmen besteht auch aus 1600 Mitarbeitern, die global verteilt nach diesen Prinzipien arbeiten. Es gibt nämlich sehr wohl hohes Alignment – aber nicht auf der Ebene von Methoden, sondern auf der Ebene des Produkts.

Es gibt weitere nachhaltige Beispiele, die heute so zu arbeiten begonnen haben oder dies seit Jahren tun. Und ich glaube mittlerweile, dass es in der Wissensarbeit, in dynamischen und komplexen Umfeldern einer jener Erfolgsbausteine ist, der wesentlich dazu beiträgt die Schnelleren von den Langsameren zu unterscheiden.

Es gibt genug Ideen, was man alles standardisieren kann. Und wie wir wissen, ist das Repertoire nicht enden wollen, wenn man mal mit dem Projektauftrag beginnt. Aber abgesehen von den erhofften Erleichterungen, die ich oben ausgeführt habe, geht es nicht um etwas völlig anderes? Geht es nicht um die Befürchtung, dass hohe Autonomie zu Fehlern, zu Missbrauch, zu Misserfolg führt? Geht es nicht darum, dass eine Steering Committee oder ein PMO einem Projektleiter mangels Einhaltung von Standards nicht über den Weg traut? Und geht es dem Projektleiter, der Organisation nicht genauso mit den Teams, mit den Lieferanten? Geht es nicht eigentlich um den Mangel an Vertrauen in Menschen und selbstgesteuerte Prozesse, ggf. völlig unzureichend implementierte Feedbackschleifen? Und ist nicht gerade der Standard jenes verstärkende Element, auf das sich Mitarbeiter letztlich zurückziehen und mangels Autonomie ihre Begeisterung und ihre Verantwortlichkeit am Werkstor abgeben?

Ich bin heute auf Grund der langen Erfahrung in beiden Lagern zur festen Überzeugung gelangt, dass der Begriff „Standard“ in der Wissensarbeit möglichst zugunsten effektiverer Prinzipien verbannt gehört. Ich glaube sogar, dass es genau dort beginnt, dass Organisationen beginnen sich förmlich bis zur Unbeweglichkeit in ihrem Status Quo einzubunkern und dabei übersehen, dass sie sich dem Überleben im Wettbewerb entziehen. Daher: wehret den Anfängen!

Da sind wir vollkommen einer Meinung, Mike! Bis zu einem gewissen Grad gibt es in der Durchführung von Projekten allerdings schon so was wie einen gemeinsamen Nenner. Und wenn man in der Organisation viele Projekte macht, dann will man vielleicht nicht, dass jeder Projektauftrag anders aussieht. Wenn es aber um die konkrete Durchführung oder sogar um Werkzeuge geht bin ich auch für maximale Autonomie und Experimentierfreude. Leider neigen große Organisationen und insbesondere solche die im Kerngeschäft auf stabile Prozesse setzen wie zum Beispiel die produzierende Industrie definitiv zur Überstandardisierung. Dann wird es starr, bürokratisch und gefährlich, weil dann zwar Projekte formal dem Prozess entsprechen, aber trotzdem scheiße laufen.

Worauf es aber stattdessen ankommt:
– Hohe Autonomie der Leistenden über was und wie und mit wem zu standardisieren
– gleichzeitiges Alignment (warum tun wir was?)
– Transprenz, was wir tun, wo wir stehen, was besser sein kann
– Effektive Feedbackschleifen
– die Fähigkeit rasch und nachhaltig zu lernen

Dies ist der Nährboden, auf Basis dessen viele Wendigere den Standardisierern den Rang ablaufen (werden).

Spotify machts im Grunde vor – jedes Team entscheidet selbst über seine Methoden. Keine Vorgaben. Diverse Standards werden emergent entwickelt und auch wieder in Frage gestellt. Hohe Autonomie bei hohem Alignment. Und das Produkt funktioniert auch nicht so schlecht. Tw besser, als jenes von manch Großen.

Conclusio: Wissensarbeit, die von hoher Dynamik der Veränderung begleitet ist, repräsentiert ihre Standards durch effektive Arbeitsprinzipien quasi selbst. Und diese Standards sind laufend in Weiterbewegung.