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 aus­zu­rol­len?

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 Pro­jek­te.

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 Pro­jek­te.

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 befrie­di­gen.

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ück­schritt.

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 some­whe­re.
Hen­ry Ford

Du willst keinen Artikel mehr verpassen?

Mit mei­nem News­let­ter bekommst du ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Ein­gangs­korb.

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 Vor­tei­le.

Wor­auf es aber statt­des­sen ankommt:
– Hohe Auto­no­mie der Leis­ten­den über was und wie und mit wem zu stan­dar­di­sie­ren
– 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 Feed­back­schlei­fen
– die Fähig­keit rasch und nach­hal­tig zu ler­nen

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 Wei­ter­be­we­gung.

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 lau­fen.

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 Pro­dukts.

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 unter­schei­den.

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 abge­ben?

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än­gen!

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 ver­mei­det.

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 bewe­gen.

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 hin­ter­fragt.

Ü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 ver­wor­fen.

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 eigent­lich.

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 Mei­nung.

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

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 Pro­jekt.

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-Ebe­ne.

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 Lear­ned)

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 Auf­wen­dun­gen).

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 Ver­tre­tun­gen.
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 Kos­ten­grün­den)

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 Ver­werf­li­ches.
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 Manage­ment.
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ß lau­fen.

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 betreu­en.
Und wer Pro­jekt­lei­ter im Auto­mo­bil­bau war, wird an Kraft­wer­ken ver­zwei­feln.

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 voll­kom­men.

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 Spiel­räu­me.

Letzt­lich ist hier die Fra­ge, wie z.B. der Pro­jekt­auf­trag über­haupt aus­sieht:
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 Manage­ment)

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-Metho­de:

Wel­che Vari­an­te paßt zu den Pro­jek­ten, die wir durch­füh­ren?

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

Schreibe einen Kommentar