Alle Organisationen die viele Projekte durchführen kommen früher oder später einen Punkt, an dem die Rufe nach einer Standardisierung der Projektdurchführung nicht mehr ignoriert werden können. Die Logik dahinter ist einfach: wo immer gleichartiges in großer Menge über verschiedene Schritte arbeitsteilig abgearbeitet wird, braucht es eine verbindliche Beschreibung der Schritte und der jeweiligen Akteure mit ihrer Verantwortung. Was kann also falsch daran sein, den Wildwuchs in der Projektdurchführung einzudämmen und ein für alle verbindliches Prozessmodell für Projekte auszurollen?
Die DIN 69901 definiert ein Projekt als ein „Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist“. Auch andere Definitionen sehen in dieser Einmaligkeit ein wesentliches Charakteristikum eines Projekts. Wiederkehrende Tätigkeiten in konstantem Umfeld mit denselben Ressourcen sind also keine Projekte.
Das heißt aber nicht, dass jedes Projekt in allen seinen Details einzigartig ist. Im Gegenteil gibt es sehr wohl Aspekte und Artefakte die in allen Projekten vorhanden sein sollten. Beispielsweise einen Projektauftrag mit Umfang, Zielen und Ressourcen unterschrieben von einem Projektauftraggeber. Gut wäre auch ein Prozess zum Umgang mit Änderungen des Projektumfangs. Statusberichte an den Lenkungskreis und überhaupt ein Lenkungskreis als Steuerungsgremium sind auch Teil des gemeinsamen Nenners aller Projekte.
Von weit oben betrachtet weist die Projektdurchführung also durchaus einige wiederkehrende Elemente auf, die es auch lohnt zu standardisieren. Nur zu tief sollte der Standardisierungseifer nicht gehen. Der Gestaltungsspielraum des Projektleiters muss groß genug bleiben, dass der Einzigartigkeit des Projekts noch ausreichend Rechnung getragen werden kann. Es sollte nicht passieren, dass Projekte unnötige Artefakte anlegen und führen müssen, nur um die Prozesse zu befriedigen.
Im klassischen Wasserfallmodell kennt man in Softwareprojekten typischerweise das sogenannte IT-Konzept, in dem basierend auf dem „Was“ der fachlichen Anforderungen das „Wie“ der Umsetzung beschrieben wird, bevor dann die Programmierung auf dieser Grundlage beginnen darf. Ein solches Artefakt für alle Projekte vorzuschreiben wäre allerdings eher hinderlich. Für agile Projekte ist es in weiten Teilen nämlich unnötiger Ballast, weil für die kurzen Iterationen von zwei bis vier Wochen in recht kleinen Teams das Aufschreiben des „Wie“ zugunsten einer direkten Umsetzung weitestgehend entfallen kann. Natürlich gibt es Aspekte der Umsetzung, zum Beispiel die IT-Architektur, die es sich lohnt zu dokumentieren für den Betrieb und die spätere Wartung, aber das geschieht parallel zur Umsetzung und nicht vorher, wie es im Wasserfall vorgesehen wäre.
Führt ein Unternehmen viele Projekte durch lohnt es sich, den gemeinsamen Nenner dabei in Form eines verbindlichen Prozess- und Vorgehensmodell zu kondensieren. Keinesfalls darf dieses Modell dann aber so starr sein, dass es an die Einzigartigkeit der Projekte nicht mehr angepasst werden kann. Um den einmal definierten Standard lebendig zu halten, müssen zudem Experimente und Weiterentwicklungen gezielt gefördert werden, anstatt nur als unerwünschte Abweichung angemahnt zu werden. Stillstand ist auch hier Rückschritt.
If you think of standardization as the best that you know today, but which is to be improved tomorrow; you get somewhere.
Henry Ford
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
7 Kommentare
Ich glaube, dass Standardisierung in der hohes Verirrungspotential hat. Vor allem, wenn es erzwungen wird, was ja gerade bei klassischen Vorgaben aus PMOs etc der Fall ist. Wissensarbeit lässt sich nicht auf economies of scale begründen und zieht aus Standardisierung nur recht bedingt Vorteile.
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.
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.
Ich kenne die Tendenzen zur Standardisierung recht gut, habe auch 10 Jahre in einem deutchen Automotive Unternehmen „zugebracht“ (quasi bei Eurer Konkurrenz). Aber dennoch mal laut gedacht, warum müssen Projektaufträge denn standardisiert werden? Damit die Begutachtung, die Definition, die Genehmigung und die Ablage leichter zu administrieren sind. Ja und ist das wirklich „kriegsentscheidend“ (wohlgermerkt: in der Wissensarbeit!)? Ist es das, wodurch wir die richtigeren Projekte starten? Kommen die Projekte dadurch besser ans Ziel? Und werden das unsere Kunden (intern, aber vor allem auch extern) besser spüren?
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!
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 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.
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.
Zum Thema Standards habe ich mittlerweile eine stark abgestufte Meinung.
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.