Projekt und Prozess

Alle Orga­ni­sa­tio­nen die vie­le Pro­jek­te durch­füh­ren kom­men frü­her oder spä­ter einen Punkt, an dem die Rufe nach einer Stan­dar­di­sie­rung der Pro­jekt­durch­füh­rung nicht mehr igno­riert wer­den kön­nen. Die Logik dahin­ter ist ein­fach: wo immer gleich­ar­ti­ges in gro­ßer Men­ge über ver­schie­de­ne Schrit­te arbeits­tei­lig abge­ar­bei­tet wird, braucht es eine ver­bind­li­che Beschrei­bung der Schrit­te und der jewei­li­gen Akteu­re mit ihrer Ver­ant­wor­tung. Was kann also falsch dar­an sein, den Wild­wuchs in der Pro­jekt­durch­füh­rung ein­zu­däm­men und ein für alle ver­bind­li­ches Pro­zess­mo­dell für Pro­jek­te auszurollen?

Die DIN 69901 defi­niert ein Pro­jekt als ein „Vor­ha­ben, das im Wesent­li­chen durch die Ein­ma­lig­keit der Bedin­gun­gen in ihrer Gesamt­heit gekenn­zeich­net ist“. Auch ande­re Defi­ni­tio­nen sehen in die­ser Ein­ma­lig­keit ein wesent­li­ches Cha­rak­te­ris­ti­kum eines Pro­jekts. Wie­der­keh­ren­de Tätig­kei­ten in kon­stan­tem Umfeld mit den­sel­ben Res­sour­cen sind also kei­ne Projekte.

Das heißt aber nicht, dass jedes Pro­jekt in allen sei­nen Details ein­zig­ar­tig ist. Im Gegen­teil gibt es sehr wohl Aspek­te und Arte­fak­te die in allen Pro­jek­ten vor­han­den sein soll­ten. Bei­spiels­wei­se einen Pro­jekt­auf­trag mit Umfang, Zie­len und Res­sour­cen unter­schrie­ben von einem Pro­jekt­auf­trag­ge­ber. Gut wäre auch ein Pro­zess zum Umgang mit Ände­run­gen des Pro­jekt­um­fangs. Sta­tus­be­rich­te an den Len­kungs­kreis und über­haupt ein Len­kungs­kreis als Steue­rungs­gre­mi­um sind auch Teil des gemein­sa­men Nen­ners aller Projekte.

Von weit oben betrach­tet weist die Pro­jekt­durch­füh­rung also durch­aus eini­ge wie­der­keh­ren­de Ele­men­te auf, die es auch lohnt zu stan­dar­di­sie­ren. Nur zu tief soll­te der Stan­dar­di­sie­rungs­ei­fer nicht gehen. Der Gestal­tungs­spiel­raum des Pro­jekt­lei­ters muss groß genug blei­ben, dass der Ein­zig­ar­tig­keit des Pro­jekts noch aus­rei­chend Rech­nung getra­gen wer­den kann. Es soll­te nicht pas­sie­ren, dass Pro­jek­te unnö­ti­ge Arte­fak­te anle­gen und füh­ren müs­sen, nur um die Pro­zes­se zu befriedigen.

Im klas­si­schen Was­ser­fall­mo­dell kennt man in Soft­ware­pro­jek­ten typi­scher­wei­se das soge­nann­te IT-Kon­zept, in dem basie­rend auf dem „Was“ der fach­li­chen Anfor­de­run­gen das „Wie“ der Umset­zung beschrie­ben wird, bevor dann die Pro­gram­mie­rung auf die­ser Grund­la­ge begin­nen darf. Ein sol­ches Arte­fakt für alle Pro­jek­te vor­zu­schrei­ben wäre aller­dings eher hin­der­lich. Für agi­le Pro­jek­te ist es in wei­ten Tei­len näm­lich unnö­ti­ger Bal­last, weil für die kur­zen Ite­ra­tio­nen von zwei bis vier Wochen in recht klei­nen Teams das Auf­schrei­ben des „Wie“ zuguns­ten einer direk­ten Umset­zung wei­test­ge­hend ent­fal­len kann. Natür­lich gibt es Aspek­te der Umset­zung, zum Bei­spiel die IT-Archi­tek­tur, die es sich lohnt zu doku­men­tie­ren für den Betrieb und die spä­te­re War­tung, aber das geschieht par­al­lel zur Umset­zung und nicht vor­her, wie es im Was­ser­fall vor­ge­se­hen wäre.

Führt ein Unter­neh­men vie­le Pro­jek­te durch lohnt es sich, den gemein­sa­men Nen­ner dabei in Form eines ver­bind­li­chen Pro­zess- und Vor­ge­hens­mo­dell zu kon­den­sie­ren. Kei­nes­falls darf die­ses Modell dann aber so starr sein, dass es an die Ein­zig­ar­tig­keit der Pro­jek­te nicht mehr ange­passt wer­den kann. Um den ein­mal defi­nier­ten Stan­dard leben­dig zu hal­ten, müs­sen zudem Expe­ri­men­te und Wei­ter­ent­wick­lun­gen gezielt geför­dert wer­den, anstatt nur als uner­wünsch­te Abwei­chung ange­mahnt zu wer­den. Still­stand ist auch hier Rückschritt.

If you think of stan­dar­di­z­a­ti­on as the best that you know today, but which is to be impro­ved tomor­row; you get somewhere.
Hen­ry Ford

Teile diesen Beitrag

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

7 Kommentare

Ich glau­be, dass Stan­dar­di­sie­rung in der hohes Ver­ir­rungs­po­ten­ti­al hat. Vor allem, wenn es erzwun­gen wird, was ja gera­de bei klas­si­schen Vor­ga­ben aus PMOs etc der Fall ist. Wis­sens­ar­beit lässt sich nicht auf eco­no­mies of sca­le begrün­den und zieht aus Stan­dar­di­sie­rung nur recht bedingt Vorteile.

Wor­auf es aber statt­des­sen ankommt:
– Hohe Auto­no­mie der Leis­ten­den über was und wie und mit wem zu standardisieren
– gleich­zei­ti­ges Align­ment (war­um tun wir was?)
– Tran­sprenz, was wir tun, wo wir ste­hen, was bes­ser sein kann
– Effek­ti­ve Feedbackschleifen
– die Fähig­keit rasch und nach­hal­tig zu lernen

Dies ist der Nähr­bo­den, auf Basis des­sen vie­le Wen­di­ge­re den Stan­dar­di­sie­rern den Rang ablau­fen (wer­den).

Spo­ti­fy machts im Grun­de vor – jedes Team ent­schei­det selbst über sei­ne Metho­den. Kei­ne Vor­ga­ben. Diver­se Stan­dards wer­den emer­gent ent­wi­ckelt und auch wie­der in Fra­ge gestellt. Hohe Auto­no­mie bei hohem Align­ment. Und das Pro­dukt funk­tio­niert auch nicht so schlecht. Tw bes­ser, als jenes von manch Großen.

Con­clu­sio: Wis­sens­ar­beit, die von hoher Dyna­mik der Ver­än­de­rung beglei­tet ist, reprä­sen­tiert ihre Stan­dards durch effek­ti­ve Arbeits­prin­zi­pi­en qua­si selbst. Und die­se Stan­dards sind lau­fend in Weiterbewegung.

Da sind wir voll­kom­men einer Mei­nung, Mike! Bis zu einem gewis­sen Grad gibt es in der Durch­füh­rung von Pro­jek­ten aller­dings schon so was wie einen gemein­sa­men Nen­ner. Und wenn man in der Orga­ni­sa­ti­on vie­le Pro­jek­te macht, dann will man viel­leicht nicht, dass jeder Pro­jekt­auf­trag anders aus­sieht. Wenn es aber um die kon­kre­te Durch­füh­rung oder sogar um Werk­zeu­ge geht bin ich auch für maxi­ma­le Auto­no­mie und Expe­ri­men­tier­freu­de. Lei­der nei­gen gro­ße Orga­ni­sa­tio­nen und ins­be­son­de­re sol­che die im Kern­ge­schäft auf sta­bi­le Pro­zes­se set­zen wie zum Bei­spiel die pro­du­zie­ren­de Indus­trie defi­ni­tiv zur Über­stan­dar­di­sie­rung. Dann wird es starr, büro­kra­tisch und gefähr­lich, weil dann zwar Pro­jek­te for­mal dem Pro­zess ent­spre­chen, aber trotz­dem schei­ße laufen.

Ich ken­ne die Ten­den­zen zur Stan­dar­di­sie­rung recht gut, habe auch 10 Jah­re in einem deut­chen Auto­mo­ti­ve Unter­neh­men „zuge­bracht“ (qua­si bei Eurer Kon­kur­renz). Aber den­noch mal laut gedacht, war­um müs­sen Pro­jekt­auf­trä­ge denn stan­dar­di­siert wer­den? Damit die Begut­ach­tung, die Defi­ni­ti­on, die Geneh­mi­gung und die Abla­ge leich­ter zu admi­nis­trie­ren sind. Ja und ist das wirk­lich „kriegs­ent­schei­dend“ (wohl­ger­merkt: in der Wis­sens­ar­beit!)? Ist es das, wodurch wir die rich­ti­ge­ren Pro­jek­te star­ten? Kom­men die Pro­jek­te dadurch bes­ser ans Ziel? Und wer­den das unse­re Kun­den (intern, aber vor allem auch extern) bes­ser spüren?

Ich habe das Bei­spiel Spo­ti­fy gebracht, weil sie sehr aktu­ell genau damit gebro­chen haben. Ja, sie haben Stan­dards. Aber die­se sind dau­ernd in Bewe­gung und wer­den zwi­schen Teams „aus­ge­han­delt“. Die machen z.B. Din­ge wie Scrum, Kan­ban und belie­bi­ge Mischun­gen dar­aus. Aller­dings ent­schei­det das Team, wonach es wirk­lich arbei­ten will. Und dem­entspre­chend gibt es belie­bi­ge Mischun­gen. Und das Unter­neh­men besteht auch aus 1600 Mit­ar­bei­tern, die glo­bal ver­teilt nach die­sen Prin­zi­pi­en arbei­ten. Es gibt näm­lich sehr wohl hohes Align­ment – aber nicht auf der Ebe­ne von Metho­den, son­dern auf der Ebe­ne des Produkts.

Es gibt wei­te­re nach­hal­ti­ge Bei­spie­le, die heu­te so zu arbei­ten begon­nen haben oder dies seit Jah­ren tun. Und ich glau­be mitt­ler­wei­le, dass es in der Wis­sens­ar­beit, in dyna­mi­schen und kom­ple­xen Umfel­dern einer jener Erfolgs­bau­stei­ne ist, der wesent­lich dazu bei­trägt die Schnel­le­ren von den Lang­sa­me­ren zu unterscheiden.

Es gibt genug Ideen, was man alles stan­dar­di­sie­ren kann. Und wie wir wis­sen, ist das Reper­toire nicht enden wol­len, wenn man mal mit dem Pro­jekt­auf­trag beginnt. Aber abge­se­hen von den erhoff­ten Erleich­te­run­gen, die ich oben aus­ge­führt habe, geht es nicht um etwas völ­lig ande­res? Geht es nicht um die Befürch­tung, dass hohe Auto­no­mie zu Feh­lern, zu Miss­brauch, zu Miss­erfolg führt? Geht es nicht dar­um, dass eine Stee­ring Com­mit­tee oder ein PMO einem Pro­jekt­lei­ter man­gels Ein­hal­tung von Stan­dards nicht über den Weg traut? Und geht es dem Pro­jekt­lei­ter, der Orga­ni­sa­ti­on nicht genau­so mit den Teams, mit den Lie­fe­ran­ten? Geht es nicht eigent­lich um den Man­gel an Ver­trau­en in Men­schen und selbst­ge­steu­er­te Pro­zes­se, ggf. völ­lig unzu­rei­chend imple­men­tier­te Feed­back­schlei­fen? Und ist nicht gera­de der Stan­dard jenes ver­stär­ken­de Ele­ment, auf das sich Mit­ar­bei­ter letzt­lich zurück­zie­hen und man­gels Auto­no­mie ihre Begeis­te­rung und ihre Ver­ant­wort­lich­keit am Werks­tor abgeben?

Ich bin heu­te auf Grund der lan­gen Erfah­rung in bei­den Lagern zur fes­ten Über­zeu­gung gelangt, dass der Begriff „Stan­dard“ in der Wis­sens­ar­beit mög­lichst zuguns­ten effek­ti­ve­rer Prin­zi­pi­en ver­bannt gehört. Ich glau­be sogar, dass es genau dort beginnt, dass Orga­ni­sa­tio­nen begin­nen sich förm­lich bis zur Unbe­weg­lich­keit in ihrem Sta­tus Quo ein­zu­bun­kern und dabei über­se­hen, dass sie sich dem Über­le­ben im Wett­be­werb ent­zie­hen. Daher: weh­ret den Anfängen!

Aus mei­ner Erfah­rung muss ich Dir lei­der recht geben. Weh­ret den Anfän­gen trifft es recht gut. Dem Pro­jekt und dem Ergeb­nis nutzt der stan­dar­di­sier­te Pro­jekt­auf­trag nicht, nur der Admi­nis­tra­ti­on und Büro­kra­tie. Und natür­lich steht dahin­ter ein im Kon­text von Pro­jek­ten in der Wis­sens­ar­beit uto­pi­sches Bedürf­nis nach Sicher­heit und Sta­bi­li­tät ein­her­ge­hend mit feh­len­dem Ver­trau­en in die Akteu­re. Im Prin­zip sind wir ja einer Mei­nung, die Fra­ge ist nur ob man ein biss­chen Stan­dard zulas­sen will, der Büro­kra­tie wegen, oder lie­ber den Blöd­sinn ganz vermeidet.

Ich möch­te trotz per­sön­li­cher Prä­fe­ren­zen nicht gleich das Kind mit dem Bade aus­schüt­ten. Daher hin­ter­fra­ge ich ger­ne, ob Stan­dards uns hel­fen unser Sys­tem bes­ser zu betrei­ben, wel­che kon­kre­te Aus­wir­kung die Ein­füh­rung / Ver­än­de­rung von Stan­dards auf unser Sys­tem hat. Das bedingt meis­tens, dass wir unser Sys­tem über­haupt mal ver­ste­hen. Auf die­ser Basis kön­nen Stan­dards schon mal nicht in Eisen gegos­sen ver­stan­den wer­den. Denn wir wol­len ja das Sys­tem immer effek­ti­ver gestal­ten – daher wol­len wir es nicht mit Stan­dards zumül­len, son­dern sinn­vol­le Stan­dards (z.B. hin­sicht­lich Qua­li­täts­ver­ständ­nis) fort­lau­fend wei­ter bewegen.

Ein Blick auf unser Sys­tem (z.B. auf Lead Time Dis­tri­bu­ti­ons, Durch­satz, Flow Effi­ci­en­cy, etc) hilft uns zu sehen, wel­che Aus­wir­kun­gen Stan­dards / Ände­run­gen mit sich brin­gen. Aber wie gesagt: idea­ler­wei­se nicht von oben auf­ge­drängt, son­dern von mög­lichst auto­nom agie­ren­den Teams / Mit­ar­bei­tern intrinsisch moti­viert zum Ein­satz gebracht und wie­der hinterfragt.

Übri­gens lässt sich hier eine gute Par­al­le­le zum The­ma „Metri­ken“ zie­hen. Die­se wer­den idea­ler­wei­se eben­so von Teams selbst ent­lang gemein­sa­mer Zie­le gesetzt (sie­he: Objec­ti­ves & Key Results), die­nen der Ver­bes­se­rung des Sys­tems und nicht der Angst­be­schwich­ti­gung der Füh­rung, sind nicht leicht zu errei­chen (also auch her­aus­for­dernd) und wer­den immer wie­der hin­ter­fragt, erneu­ert und auch verworfen.

Und eben­so wie bei den Stan­dards ten­die­ren büro­kra­ti­sche Orga­ni­sa­tio­nen dazu, Metri­ken nie zu ver­wer­fen, son­dern zu kumu­lie­ren und über die Jah­re immer mehr und mehr zu mes­sen, zu repor­ten, ohne sich noch dar­an erin­nern zu kön­nen, war­um eigentlich.

Da hast Du lei­der recht: Ein­ge­führt wird viel und abge­schafft nichts. Die Büro­kra­tie wird irgend­wann zum Selbst­zweck. Viel­leicht soll­ten wir in moder­nen Orga­ni­sa­tio­nen nur emer­gen­te Stan­dards erlau­ben, also sol­che die aus der prak­ti­schen Arbeit in den Teams ent­ste­hen und sich durch­set­zen, weil sie bei der Arbeit hel­fen. Schwie­rig wird es immer wenn Stan­dards im Elfen­bein­turm erdacht wer­den, nicht der Arbeit son­dern der Admi­nis­tra­ti­on nut­zen und Vor­ga­be­cha­rak­ter haben.

Zum The­ma Stan­dards habe ich mitt­ler­wei­le eine stark abge­stuf­te Meinung.

Grund­sätz­lich sind Stan­dards als Pau­schal­kon­zept erst­mal nicht zielführend.
Die aller­ers­te Fra­ge muß aber sein: Wel­che Pro­jek­te habe ich denn zu betrachten?
Und: Wenn über­haupt, was soll denn auf wel­cher Ebe­ne stan­dar­di­siert werden?

Impli­zit schwingt immer der Gedan­ke vom „Stan­dard­pro­jekt“ mit. Das gibt es aber nicht. Es gibt Pro­jek­te, die sind in jeder Hin­sicht ein­ma­lig, und erfor­dern Pro­zes­se, die vor­her nie­mand kennt. Ande­re Pro­jek­te haben eine sich wie­der­ho­len­de Grund­kon­struk­ti­on, und wer­den erst durch die Umstän­de zum Projekt.

Bei letz­te­ren gibt es aus mei­ner Sicht (Groß­an­la­gen­bau) einen hohen Bedarf für Stan­dards auf der PM-Ebene.

Pro­jek­te im Anla­gen­bau, wie ich sie ken­ne, ähneln ein­an­der sehr stark, wenn man mal unter die Motor­hau­be schaut.
Die tech­ni­sche Struk­tur vari­iert zwi­schen den Pro­jek­ten nur inso­weit sie das End­pro­dukt betrifft und wird ansons­ten eher auf- und abska­liert. (Aller­dings nicht line­ar; wich­ti­ger Punkt aus den Les­sons Learned)

Die kom­mer­zi­el­le Struk­tur ist meist voll­kom­men iden­tisch, wenn man von den Eigen­hei­ten des Export­ge­schäf­tes mal absieht (und hier mei­ne ich nur die finanz­recht­li­chen Vor­ga­ben der betrof­fe­nen Län­der, und noch nicht mal das The­ma Compliance/Nützliche Aufwendungen).

Gro­ße Unter­schie­de gibt es dann aber im Pro­jekt­um­feld (Land, Kli­ma, Logis­tik, Kul­tur, Onshore­an­teil (also Beschaf­fungs­vor­ga­be für das Pro­jekt­land)) und bei den Betei­lig­ten (z.B. Claim­freu­dig­keit der Lie­fe­ran­ten, Umgang mit dem Kun­den, Anzahl der Lie­fe­ran­ten, Anzahl der Bau­stel­len, auch Anzahl der Kun­den etc.)

Ein aus­führ­lich geschrie­be­ner Pro­jekt­auf­trag mit vor­ge­ge­be­nen Inhal­ten z.B. ist extrem sinn­voll, wenn sich ein ande­rer Pro­jekt­lei­ter ein­ar­bei­ten muß. Hier hat­te ich oft Pro­ble­me, wenn der Vor­gän­ger gekün­digt hat­te (also zumin­dest ver­ein­zelt noch erreich­bar war) oder ver­stor­ben war (hier stellt sich die Kon­takt­auf­nah­me erheb­lich schwie­ri­ger dar).

Eine ein­heit­li­che Vor­ga­be für den PSP und stan­dar­di­sier­te Abla­ge­struk­tu­ren, die sich an eben die­sem PSP ori­en­tie­ren, erleich­tern eben­falls den Ein­stieg enorm, ins­be­son­de­re bei Vertretungen.
Es hilft ein­fach, wenn alles da ist, wo es bei allen liegt.

Und vor­ge­ge­be­ne Rah­men­pro­zes­se in Anleh­nung an eta­blier­te Stan­dards hel­fen, auch Jung-Pro­jekt­lei­ter in das Pro­jekt zu brin­gen. (Das frü­her geläu­fi­ge „Mit­lau­fen“, also das eigent­li­che „Trai­ning on the Job“ ent­fällt ja heut­zu­ta­ge aus Kostengründen)

Inso­fern sehe ich hier an Stan­dard­pro­zes­sen und Stan­dard­schnitt­stel­len (zwi­schen Abtei­lun­gen, zum Rech­nungs­we­sen, zum Con­trol­ling, zum Len­kungs­aus­schuß) über­haupt nichts Verwerfliches.
Ganz im Gegen­teil bin ich der Mei­nung, daß das in unse­rem Geschäft hilft, sich auf das Wesent­li­che zu kon­zen­trie­ren, näm­lich die Arbeit mit dem Kun­den und den Part­nern, auf das Con­tract Chan­ge Manage­ment und nicht zuletzt auf das Risk Management.
Wer­den dann noch von zen­tra­ler Stel­le (z.B. vom PMO) geeig­ne­te Vor­la­gen und Metho­den ange­bo­ten, die der Pro­jekt­lei­ter bzw. das Pro­jekt­team nut­zen kann (!), dann wird das ein run­des Paket, in dem man einen wei­ten Bereich von Pro­jek­ten gut und vor allem trans­pa­rent abwi­ckeln kann.

Ob ich ein Kraft­werk baue, eine Raf­fi­ne­rie­an­la­ge oder einen Solar­park – alle lau­fen bis zu einem gewis­sen Grad unge­fähr nach dem sel­ben Mus­ter ab.
Ab da wer­den sie indi­vi­du­ell und genau dort brau­che ich im Pro­jekt­team die Auf­merk­sam­keit. Alles dar­un­ter muß laufen.

Gefähr­lich wer­den die Stan­dards, wenn ich mich an ganz ande­re Pro­jekt­ty­pen wage:
Wer bis­her Che­mie­an­la­gen gebaut hat, wird kaum in der Lage sein, eine Soft­ware­ein­füh­rung, geschwei­ge denn ‑ent­wick­lung zu betreuen.
Und wer Pro­jekt­lei­ter im Auto­mo­bil­bau war, wird an Kraft­wer­ken verzweifeln.

Hier sind ande­re Metho­den und Pro­zes­se gefragt. Damit ver­än­dern sich auch Mög­lich­keit wie Sinn­haf­tig­keit von Stan­dards vollkommen.

Wo wir im Anla­gen­bau über ein gut aus­ge­ar­bei­te­tes und pra­xis­taug­li­ches PM-Frame­work spre­chen, kom­men wir hier in den Bereich sehr wei­ter und vom Pro­jekt­team zu gestal­ten­der Spielräume.

Letzt­lich ist hier die Fra­ge, wie z.B. der Pro­jekt­auf­trag über­haupt aussieht:
Im Anla­gen­bau bekom­me ich einen Sta­pel Spe­zi­fi­ka­tio­nen, eine Sum­me Geld und ein Zeit­fens­ter. Damit muß ich klar kom­men, und im Lau­fe des Pro­jek­tes an den Zie­len, Anfor­de­run­gen und Ver­ein­ba­run­gen fei­len, bis ich am Ende einen Haken dran machen kann. Falls etwas gar nicht paßt, muß ich zum Kun­den und mit ihm den Ver­trag anpas­sen (Stich­wort Con­tract Chan­ge Management)

Also ist mei­ner Mei­nung nach die Fra­ge der Stan­dar­di­sie­rung genau­so mit einer Gegen­fra­ge zu beant­wor­ten, wie die Fra­ge nach der PM-Methode:

Wel­che Vari­an­te paßt zu den Pro­jek­ten, die wir durchführen?

Eine Pau­schal­ant­wort wird man nicht fin­den kön­nen, so sehr sich das die Vor­stän­de auch wünschen.

Schreibe einen Kommentar