Die Multiprojekt-Eskalationsspirale

Als ver­ant­wor­tungs­vol­ler Pro­jekt­ma­na­ger ist man immer bemüht um das rich­ti­ge Maß an Span­nung und Anfor­de­rung im Pro­jekt­team. Nicht zu viel, jeden­falls nicht zu lan­ge zu viel, aber auch nicht zu wenig. Ein Zustand des Flie­ßens, in dem kon­zen­triert und ruhig gear­bei­tet wer­den kann. Das Gefühl im Team alles schaf­fen zu kön­nen. Gelingt natür­lich nicht immer und wenn es gelingt, ist die­ser Gleich­ge­wichts­zu­stand stän­dig bedroht. Auch und gera­de durch die umge­ben­de Mul­ti­pro­jekt-Orga­ni­sa­ti­on, die sta­bil lau­fen­de Pro­jek­te als Res­sour­cen­puf­fer für weni­ger gut auf­ge­stell­te Pro­jek­te betrachtet.

Mul­ti­pro­jekt-Orga­ni­sa­tio­nen füh­ren mit einer gemein­sa­men Men­ge an Mit­ar­bei­tern gleich­zei­tig von­ein­an­der unab­hän­gi­ge Pro­jek­te durch. Das hat ohne Fra­ge Vor­tei­le. Hoch­spe­zia­li­sier­te Exper­ten, die jedes Pro­jekt braucht, aber eben nur zu einem Bruch­teil, kön­nen ihre Kapa­zi­tät meh­re­ren Pro­jek­ten zur Ver­fü­gung stel­len und so effi­zi­ent ein­ge­setzt wer­den. Außer­dem erreicht man durch die gleich­zei­ti­ge Bear­bei­tung von meh­re­ren Pro­jek­ten in der Regel eine höhe­re Aus­las­tung der Mit­ar­bei­ter wie bei rein sequen­ti­el­ler Bear­bei­tung der Pro­jek­te, weil Schwan­kun­gen der Team­stär­ke bes­ser kom­pen­siert wer­den können. 

In einer sol­chen Mul­ti­pro­jekt-Orga­ni­sa­ti­on ist es also nicht unge­wöhn­lich, son­dern sogar prin­zi­pi­ell gewünscht, dass Mit­ar­bei­ter zwi­schen den Pro­jek­ten wäh­rend der Pro­jekt­lauf­zeit wech­seln. Wenn bei­spiels­wei­se in Pro­jekt A die wesent­li­chen Wei­chen schon gestellt sind und der Weg bis zur Abnah­me eigent­lich klar erscheint, kann es gut sein, dass der erfah­re­ne Sys­tem­ar­chi­tekt schon in Pro­jekt B wech­selt, das gera­de in der Kon­zep­ti­ons­pha­se die Archi­tek­tur fest­legt und die­se Wei­chen erst stel­len muss. Klingt gut. Jeden­falls so lan­ge es in Pro­jekt A nicht zu einer grö­ße­ren Ände­rung oder Kata­stro­phe kommt. Dann geht der Kampf um die Kapa­zi­tät die­ses einen Sys­tem­ar­chi­tek­ten los.

In die­sem Kampf kommt es in ers­ter Linie dar­auf an, wel­cher Pro­jekt­ma­na­ger die schlim­me­ren Fol­gen eines Abzugs des umkämpf­ten Mit­ar­bei­ters dar­stel­len kann. Wenn ich nun mein Pro­jekt in den ein­gangs beschrie­be­nen Gleich­ge­wichts­zu­stand gebracht habe, dann habe ich in der Regel in die­sem Kampf die schlech­te­ren Kar­ten. Cha­rak­te­ris­tisch für die­sen Zustand ist ja gera­de eine ver­nünf­ti­ge Aus­las­tung und damit ein gewis­ser Puf­fer um Unvor­her­ge­se­he­nes abzu­fe­dern. Inso­fern kann man den Abzug eines woan­ders drin­gen­der benö­tig­ten Mit­ar­bei­ters schon kompensieren. 

In einer Mul­ti­pro­jekt-Orga­ni­sa­ti­on gewin­nen also die­se Res­sour­cen­kon­flik­te ten­den­zi­ell die­je­ni­gen Pro­jek­te die weni­ger gut auf­ge­stellt sind. Solan­ge bis es kei­ne Pro­jek­te in einem gesun­den Gleich­ge­wichts­zu­stand mehr gibt und alle hek­tisch und über­las­tet arbei­ten, weil jeg­li­che Puf­fer zur Kom­pen­sa­ti­on umver­teilt wur­den. Die Mul­ti­pro­jekt-Eska­la­ti­ons­spi­ra­le hat ihren obe­ren End­punkt erreicht. Folg­lich ten­die­ren auf­grund die­ser Umver­tei­lungs­pra­xis alle Pro­jek­te einer Mul­ti­pro­jekt-Orga­ni­sa­ti­on Rich­tung Mit­tel­maß und alle Teams Rich­tung Überlast.

(Bild­nach­weis: Das Arti­kel­bild wur­de von ZeroO­ne unter dem Titel „Spi­ral stair­ca­se“ auf Flickr unter einer Crea­ti­ve Com­mons Lizenz (CC BY-SA 2.0) ver­öf­fent­licht.)

Share This Post

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.

27 Kommentare

Hal­lo Marcus,
dei­ne sys­te­mi­sche Beschrei­bung der Eska­la­ti­ons­spi­ra­le ist sehr gut getrof­fen – die­se Situa­ti­on sehen wir (als Bera­ter) in fast jedem Unter­neh­men zu dem wir geru­fen wer­den. Und irgend­wie fehlt in dei­nem Blog-Arti­kel die Lösung für die Eskalationsspirale…

Aber wenn man ein sys­te­mi­sches Pro­blem lösen will muss man an die grund­le­gen­den Glau­bens­sät­ze ran. Hier mal ein paar Bei­spie­le, wie man die Mul­ti­pro­jekt­steue­rung noch den­ken kann – näm­lich nicht als loka­le Opti­mie­rung von drei Rol­len – son­dern als abge­stimm­tes Kon­zert aller drei Beteiligten:

#1 man könn­te die Rol­le des Pro­jekt­ma­na­ger auch anders defi­nie­ren. Der Pro­jekt­ma­na­ger als der­je­ni­ge, der einen guten steu­er­ba­ren Pro­jekt­plan ver­ant­wor­tet – also gute Auf­trags­klä­rung, gute Struk­tu­rie­rung und Klä­rung der Ver­ant­wort­lich­kei­ten. Nix mit Kampf um Ressourcen.

#2 man könn­te (oder ist er das nicht schon) den Team­lei­ter für den unge­stör­ten Fluss ver­ant­wort­lich machen? Er wäre dann ver­ant­wort­lich, dass sei­ne Leu­te top befä­higt sind und unge­stört arbei­ten dür­fen! Er wür­de sei­ne Res­sour­cen immer dem Pro­jekt geben, das es am nötigs­ten hat.

#3 das obe­re Manage­ment ist dafür ver­ant­wort­lich, dass kein Team (z.B. gera­de die Exper­ten) über­las­tet ist. So dass alle im Fluss arbei­ten kön­nen und der bes­te Out­put (Durch­satz) entsteht.

Wenn man dann das Prin­zip ein­führt, dass das Pro­jekt mit der größ­ten Schief­la­ge – alle not­wen­di­ge Auf­merk­sam­keit bekommt – was übri­gens super sinn­voll ist, da ja am Schluss nur der Erfolg des gan­zen Port­fo­lio zählt – funk­tio­niert das gan­ze ohne Eskalationsspirale.

Die Knack­punkt sind a) wie macht man das, dass kein Team über­las­tet ist? und b) wor­an erkennt ich die ope­ra­ti­ve Schief­la­ge eines Projektes?
a) ist ein­fach wenn man am Eng­pass (z.B. den Exper­ten) die Pro­jek­te wie auf einer Per­len­schnur auf­reiht (staf­felt). Das obe­re Manage­ment sieht ob sie die Auf­ga­be rich­tig gemacht haben, wenn weni­ger als 10% der Pro­jek­te „rot“ (in Schief­la­ge) sind.
b) ist auch ein­fach, wenn man die gan­zen ver­steck­ten Puf­fer aus den Arbeits­pa­ke­ten nach hin­ten packt, kann man die Schief­la­ge über das Ver­hält­nis von Fort­schritt (auf der kri­ti­schen Ket­te) zu Puf­fer­ver­brauch jeden Tag ermit­teln. Mehr Puf­fer­ver­brauch als Fort­schritt = rot.

… das hört sich jetzt alles viel­leicht ver­rückt an – ist aber seit ca. 20 Jah­ren als Cri­ti­cal Chain bekannt (auf Open-PM gibt es einen ent­spre­chen­den Arti­kel https://www.openpm.info/display/openPM/Critical+Chain ). Es gibt immer mehr Unter­neh­men, die dar­auf umstel­len – ein­fach weil der Kampf zu viel Ener­gie kos­tet und die Men­schen beschä­digt. Der letz­te Erfolgs­be­richt für Cri­ti­cal Chain ist Maz­da – die haben durch die Umstel­lung 50% Pro­jekt­lauf­zeit und 30 – 40% Auf­wand im Pro­jekt gespart.

Cu Wolf­ram

p.s.: die Ein­füh­rung von Cri­ti­cal Chain ist dann nicht ganz so ein­fach – hier gilt es die alten „Kämpfer“-Glaubenssätze aus den Köp­fen des mitt­le­ren Manage­ments zu ent­ler­nen und die neue zu eta­blie­ren. Aber das ist ja unser Geschäft!

Wie Du schon rich­tig fest­stellst, ging es mir weni­ger um eine Lösungs­fin­dung und mehr um die Beschrei­bung des Pro­blems. Dan­ke, dass Du auf Cri­ti­cal Chain als eine mög­li­che Lösung hin­weist. Ich kann nicht beur­tei­len, inwie­weit das tat­säch­lich hilf­reich ist, will Dir das aber ger­ne glau­ben. Aber nicht als Patent­re­zept, son­dern als eine Lösung in einem gro­ßen Lösungs­raum. Dei­nen Enthu­si­as­mus für Cri­ti­cal Chain in Ehren, aber Dei­ne Kom­men­ta­re und Arti­kel haben für mich immer ein klein wenig zu sehr den Ton eines Sales-Pitch. Das macht es mir (und ver­mut­lich auch eini­gen ande­ren) schwie­rig sich auf eine Dis­kus­si­on einzulassen.

ooops ich woll­te sicher nichts verkaufen …

… nur ein­la­den mal über den Tel­ler­rand hin­aus­zu­schau­en. Die meis­ten Pro­ble­me, die wir im Mul­ti­pro­jekt­ma­nage­ment sehen (z.B. die Eska­la­ti­ons­spi­ra­le) hän­gen mit unse­rer Idee wie die Rol­le des Pro­jekt­ma­na­ger gestal­tet ist zusam­men – loka­le Opti­mie­rung – mein Sohn wür­de „Over Powered“ dazu sagen. Die meis­ten Lösun­gen, die ich sehe (u.a. agi­le Metho­den) sind lei­der nur Symptombehandlungen.

@Marcus – hast du eine Idee wie wir das mal dis­ku­tie­ren könn­ten – ohne, dass ich jemand auf die Füße tre­te? Auf­rüt­teln ohne vor den Kopf zu stoßen?

Ich bin hier sehr inter­es­siert – ein­fach wegen mei­nem Enthu­si­as­mus, der dadurch genährt ist, dass ich das halt schon bei einer gan­zen Rei­he Fir­men gese­hen habe wie es funk­tio­niert und das Leuch­ten in die Augen der Mit­ar­bei­ter zurück kommt …

Es klingt bei Dir lei­der meist so als woll­test Du etwas ver­kau­fen. Für den Blick über den Tel­ler­rand und den Link zu Cri­ti­cal Chain, das ja wirk­lich eine Lösung für das Pro­blem sein könn­te. Wenn Du aber so lei­den­schaft­lich mit nur die­sem einen The­ma argu­men­tierst, dann füh­le ich mich immer an das Sprich­wort erin­nert, dass alles wie ein Nagel aus­sieht, wenn man nur einen Ham­mer als Werk­zeug hat. Ist nicht böse gemeint, son­dern als Feed­back, wie das bei mir (und ande­ren ver­mut­lich auch) ankommt. Wir kön­nen die­se The­ma­tik (also die Mul­ti­pro­jekt­the­ma­tik) ger­ne auf openPM oder noch bes­ser in einer Ses­si­on auf dem PM Camp in Dorn­birn diskutieren.

Ich glau­be, es greift zu kurz, nur auf den Res­sour­cen­kon­flikt abzu­zie­len. Das ein­zel­ne Pro­jekt im Kon­text eines Pro­jekt­port­fo­li­os ist voll­kom­men anders zu bewer­ten, als aus Port­fo­lio Sicht: Das Schei­tern eines ein­zel­nen Pro­jekts ist aus Sicht des Pro­jekts eine Kata­stro­phe, aus Sicht des Port­fo­li­os aber viel­leicht ein Schritt auf einer Lernkurve.

Nach­dem wir nicht in einer idea­len Welt leben, müs­sen wir auch ler­nen Wider­sprü­che und Kon­flik­te zu akzeptieren. 

@Wolfram: Opti­mie­rungs­lö­sun­gen, wie Cri­ti­cal Chain sug­ge­rie­ren ein kom­plett ande­res Welt­bild und kön­nen auf­grund ihrer Effi­zi­enz mit­un­ter gra­vie­ren­de Schä­den anrich­ten. Wer Opti­mie­rungs­lö­sun­gen anpreist, gibt vor, zu wis­sen, was das Bes­te ist. In unse­rer kom­ple­xen Welt wür­de ich mir solch ein Wis­sen nicht anmaßen.

@Bernhard – das musst du mir mal erklä­ren, war­um man in einer nicht so idea­len Welt mit Wider­sprü­chen oder Kon­flik­ten leben muss – Sub­op­ti­ma wegen mir aber gleich Wider­sprü­che und Kon­flik­te … bald ist ja wie­der PM-Camp in Dornbirn :-)

Und ja du hast Recht – Cri­ti­cal Chain Ein­füh­run­gen kön­nen „auf­grund ihrer Effi­zi­enz mit­un­ter gra­vie­ren­de Schä­den anrich­ten“. Daher bit­te Ach­tung – nicht selbst ver­su­chen! Sys­te­mi­sche Ver­än­de­run­gen set­zen ganz schön Ener­gie frei – da muss man wis­sen was passiert …

… um Schä­den zu ver­mei­den ist eben ein gewis­sen Men­ge Vor­be­rei­tung not­wen­dig. Als ers­tes wird gecheckt ob Cri­ti­cal Chain über­haupt das Pro­blem löst – ja wir wis­sen auch, dass es nicht immer und über­all passt. Dann muss man che­cken, ob man die Effi­zi­enz über­haupt ver­kau­fen kann – ohne Markt – Fin­ger weg! Des wei­te­ren Muss man die Mana­ger abho­len – erst die obe­ren, dann die Pro­jekt­lei­ter und Team­lei­ter. Jeder muss ver­ste­hen, was in wel­cher Rei­hen­fol­ge pas­siert und wie er sich in den neu­en Rol­len wie­der fin­det. Last but not least – wird kon­se­quent schritt­wei­se vor­ge­gan­gen – bei jedem Schritt wird gecheckt ob der Erfolg da ist und dann erst kommt der nächste.

Aber wenn man Pro­blem im Mul­ti­pro­jekt­ma­nage­ment hat (und wer hat das nicht) – dann sind mas­siv kür­zer Pro­jekt­lauf­zei­ten (25%-50%), hohe Zuver­läs­sig­keit (>90%) und mehr Durch­satz (+50.…%) ohne neue Kos­ten ein­fach nicht von der Hand zu wei­sen – dafür kann man dann auch mal einen anspruchs­vol­le­ren Chan­ge wagen :-)

cu Wolf­ram

p.s.: die Sys­tem­theo­rie besagt, dass kom­ple­xe Sys­te­me dadurch beherrsch­bar wer­den, dass wir sie in ihren Frei­heits­gra­den beschrän­ken – sprich ein „Cons­traint auf­prä­gen“ … das Mul­ti­pro­jekt­ma­nage­ment erscheint uns aktu­ell so kom­plex, weil es zu vie­le Frei­heits­gra­de hat (die frei rum­ren­nen­den Pro­jekt­ma­na­ger) – sobald man die­se Frei­heit begrenzt ent­steht Sta­bi­li­tät und neben­bei noch neue emer­gen­te Eigen­schaf­ten – wie Flow :-) und Kom­pa­ti­bi­li­tät zu agi­len Methoden …

Der Res­sour­cen­kon­flikt ist natür­lich nur einer von meh­re­ren mög­li­chen in einer kom­ple­xen Mul­ti­pro­jekt­land­schaft, wenn­gleich der pro­mi­nen­tes­te. Mir ist objek­tiv voll­kom­men klar, dass das Pro­jekt im Pro­jekt­port­fo­lio anders zu bewer­ten ist und den­noch füh­le ich mich als Pro­jekt­lei­ter „bestraft“, wenn ich mein Pro­jekt sau­ber auf­stel­le und dann von Außen durch ande­re Pro­jek­te in Bedräng­nis gebracht wer­de. Ich habe oft das Gefühl, dass ein­fach die Pro­jek­te die am schlech­tes­ten daste­hen die meis­te Auf­merk­sam­keit bekom­men und ten­den­zi­ell auch die Res­sour­cen. In letz­ter Kon­se­quenz führt das mei­ner Mei­nung nach zu einer Ver­schlech­te­rung für alle Pro­jek­te des Portfolios.

Das „Basis­übel“ von all dem ist auch, dass alles als „Pro­jekts“ betrie­ben wird. Wir soll­ten mal dar­über nach­den­ken, die Men­ge an Pro­jek­ten radi­kal zu beschrän­ken. Mehr dazu im Kapi­tel „Kon­ti­nu­ier­li­che statt pro­jekt­spe­zifsch frag­men­tier­te Lie­fe­run­gen von Pro­dukt- und Ser­vice­inkre­men­ten“ in http://www.symposion.de/kapitel40600101_WERK0003442.html

Die Pro­jekt­in­fla­ti­on ist sicher­lich eine Ursa­che die hier mit hin­ein spielt. Sie­he auch Und hin­ter tau­send Pro­jek­ten kei­ne Welt

Hal­lo Mar­cus und alle Kommentatoren,
die Spi­ra­le ist prä­zi­se und zutref­fend beschrie­ben, ich habe sie lei­der häu­fi­ger als mir lieb war erle­ben „dür­fen“.
Lei­der habe auch ich kein Patent­re­zept, nach dem Mot­to „ man neh­me … und dann wird es schon“. Aber es gibt eini­ge Ansät­ze, mit deren Hil­fe das Leben leich­ter wird.
1. „Viel hilft viel“.
Häu­fig han­deln Füh­rungs­kräf­te nach dem Mot­to: „Ein Pro­jekt geht immer noch rein“. Damit haben sie sogar recht, aber Effi­zi­enz und Moti­va­ti­on der Pro­jekt­mit­ar­bei­ter sin­ken regel­mä­ßig und die Ergeb­nis­se ver­schlech­tern sich häu­fig auch.
2. „Bei uns sind alle Pro­jek­te gleich wichtig.“
Die­sen Sager höre ich oft von ver­ant­wort­li­chen Füh­rungs­kräf­ten, die bei ihren Pro­jek­ten kei­ne Prio­ri­tä­ten set­zen kön­nen oder wollen.
Durch bei­de Punk­te wird die Eska­la­ti­ons­spi­ra­le sicher und zuver­läs­sig gestar­tet. Meist geht es sogar eini­ge Zeit gut, bis dann die ers­ten Pro­jek­te anfan­gen zu rau­chen und zu bren­nen und plötz­lich und uner­war­tet gibt es eine Form der Pro­jekt-Prio­ri­sie­rung – wenn auch nicht immer die eigent­lich sinn­vol­le und erwünsch­te. Und dann begin­nen die Feu­er­wehr­ak­tio­nen für die­se Pro­jek­te und die Kol­la­te­ral­schä­den tref­fen die ande­ren Projekte.
Dabei ist die Prio­ri­sie­rung von Pro­jek­ten ist gar nicht so schwie­rig – sogar ohne kom­ple­xe Tools. Eine Mischung aus sys­te­mi­schen Den­ken und gesun­dem Men­schen­ver­stand reicht aus. Wenn alle Pro­jek­te regel­mä­ßig unter dem Gesichts­punkt der Dring­lich­keit, der Wich­tig­keit, des finan­zi­el­len und per­so­nel­len Auf­wands und des (rea­lis­tisch) zu erwar­ten­den Nut­zen betrach­tet wer­den, ergibt sich leicht eine sinn­vol­le Reihung.
Und nach dem Mot­to „weni­ger ist mehr“ soll­ten dann nur die Pro­jek­te mit der höchs­ten Prio­ri­tät gestar­tet und umge­setzt wer­den, die Zahl ergbt sich dann aus den ver­füg­ba­ren Res­sour­cen. Dabei set­ze ich natür­lich eine eini­ger­ma­ßen ehr­li­che und rea­lis­ti­sche Pla­nung der Pro­jekt vor­aus, sonst wird das nichts.
Mei­ne Erfah­rung: die Kon­zen­tra­ti­on auf eini­ge weni­ge Pro­jek­te ist auf Dau­er immer erfolg­rei­cher als zu vie­le Pro­jek­te gleichzeitig.

JA!!! Und bei der Kon­zen­tra­ti­on auf WENIGE Pro­jek­te als „Pro­jek­te“ nur das bear­bei­ten, was TATSÄCHLICH eine zeit­lich befris­te­te, rela­tiv inno­va­ti­ve und risi­ko­be­haf­te­te Auf­ga­be von erheb­li­cher Kom­ple­xi­tät mit beacht­li­cher Schwie­rig­keit und Bedeu­tung darstellt.
Sehr vie­le „Kun­den­pro­jek­te“ etwa sind dann gar kei­ne sol­chen „Pro­jek­te“ son­dern „Auf­trags­ab­wick­lun­gen“, deren Manage­ment (auch der Res­sour­cen) – weil sie über­ra­schungs­frei­er sind – weit­aus mehr stan­dar­di­sier­bar als jenes von Pro­jek­ten ist.

Ja, da stim­me ich sofort zu. Wenn im Unter­neh­men bzw. in der Orga­ni­sa­ti­on nie­mand wis­sen kann oder wis­sen will, wel­che Auf­ga­ben Pro­jek­te sind und wel­che nicht, dann gibt es gro­ße Pro­ble­me. Das reicht von „hur­ra, bei uns gibt es nur noch Pro­jek­te“ bis hin zu “ wir brau­chen kei­ne Pro­jek­te, eine Arbeits­grup­pe oder eine Task Force rei­chen doch aus“ – bei­de Ansät­ze sind weder ziel­füh­rend und noch erfol­reich. Hier sehe ich, wie auch Wolf­ram Mül­ler in sei­nem #3, das obe­re Manage­ment in der Pflicht und Ver­ant­wor­tung die Pro­jek­te von den „Nicht-Pro­jek­ten“ abzu­gren­zen, mög­lichst ein­fach und ver­ständ­lich. Dabei geht es pri­mär nicht um die wiss­ent­schaft­li­che rich­ti­ge, son­dern eine für das Unter­neh­men bzw. die Orga­ni­sa­ti­on erfolg­ver­spre­chen­de Lösung.

Hal­lo Klaus, vie­len Dank für Dei­nen Kom­men­tar. Das glau­be ich Dir ger­ne, dass Du die­se Situa­ti­on schon viel zu oft erle­ben muss­test. Mit der ent­spre­chen­den Aus­wir­kung auf die Moti­va­ti­on der betrof­fe­nen „Res­sour­cen“ …

Die bei­den von Dir aus­ge­mach­ten Indi­ka­to­ren, „Viel hilft viel“ und „Bei uns sind alle Pro­jek­te gleich wich­tig“, hal­te ich auch für maß­geb­lich betei­ligt am Ent­ste­hen der Eska­la­ti­ons­spi­ra­le. Die Kunst bei der Prio­ri­sie­rung der Pro­jek­te liegt tat­säch­lich in der Kon­zen­tra­ti­on auf eine beherrsch­ba­re Men­ge. Wenn wir nun aber, wie bei vie­len IT-Dienst­leis­tern üblich, das Manage­ment haupt­säch­lich an der Aus­las­tung ihrer Mann­schaft mes­sen und viel­leicht noch – es lebe das Manage­ment by Objec­ti­ves – ent­spre­chend die­ses Ziels ent­loh­nen, dann nimmt das Unheil sei­nen Lauf … 

Dan­ke für die­ses span­nen­de The­ma, Marcus.

Ich den­ke, die Pro­ble­ma­tik ist so viel­fäl­tig, dass wir hier kei­ne Lösung fin­den wer­den. Denn es wur­de schon mehr­fach ange­spro­chen: In kom­ple­xen sozia­len Sys­te­men gibt es kei­ne Patent­re­zep­te, die zum Gelin­gen beitragen.

Sehr wohl aber gibt es PRINZIPIEN, die man ein­hal­ten soll­te. Wenn wir bei­spiels­wei­se TOC nicht nur als Metho­de und Ansatz ver­ste­hen, son­dern die Prin­zi­pi­en dahin­ter ver­stan­den haben, stim­me ich Wolf­ram zu, dass dies ein Weg sein kann.

Grund­sätz­lich aber unter­stüt­ze ich Mar­cus Her­an­ge­hens­wei­se, nicht sofort in Lösun­gen zu den­ken, son­dern zuerst mal das Pro­blem gemein­sam zu ela­bo­rie­ren. Ein­stein hat es damals sehr tref­fend formuliert:

Die rei­ne For­mu­lie­rung eines Pro­blems ist oft­mals weit wich­ti­ger als sei­ne Lösung. Neue Fra­gen auf­zu­wer­fen, neue Mög­lich­kei­ten zu fin­den, alte Pro­ble­me aus einem neu­en Blick­win­kel zu betrach­ten, erfor­dert schöp­fe­ri­sche Vor­stel­lungs­kraft und macht die wirk­li­chen Fort­schrit­te in der Wis­sen­schaft aus.“

Denn wenn Wolf­ram schon mehr­fach den Begriff „sys­te­misch“ ver­wen­det, so bin ich der Ansicht, dass ein sys­te­mi­sches Her­an­ge­hen zuerst erfor­dert, das Pro­blem und die damit ver­bun­de­nen Fra­ge­stel­lun­gen rich­tig zu ver­ste­hen. Hier soll­ten wir aus mei­ner Sicht in jeder Dis­kus­si­on begin­nen, wenn es um kom­ple­xe Zusam­men­hän­ge und Phä­no­me­ne geht.

Kann ich alles nur unterschreiben :-)

Kom­ple­xe Sys­te­me haben einen ganz beson­de­ren Reiz – man kann mit weni­gen Maß­nah­men dras­ti­sche Ver­än­de­run­gen (Ver­bes­se­run­gen) erzie­len. Das ist das, was ich manch­mal etwas zu stark her­vor­he­be – die super Erfolge!

Gleich­zei­tig steigt aber der Anspruch/Aufwand, das Sys­tem zuvor zu ver­ste­hen „das Pro­blem zu for­mu­lie­ren“. Also genau die ein/zwei Maß­nah­men zu iden­ti­fi­zie­ren, die dann die gewünsch­te neue Sys­tem­ei­gen­schaft hervorbringen. 

Ganz wich­tig ist auch, dass hier ein Bera­ter gar nicht rich­tig hel­fen kann – die Erkennt­nis­se müs­sen aus den Leu­ten selbst her­aus­kom­men – „sie müs­sen die Lösung sehen“. Daher gilt es die Prin­zi­pi­en (sys­tem thin­king u.a.) zuvor zu transportieren/übergeben. Aber genau hier­zu müs­sen wir „Bera­ter“ ebe­ne eine gan­ze Fül­le von Wis­sen um Sys­te­me und auch über Lösun­gen mitbringen. 

Ich fin­de es schön, dass hier die TOC ange­spro­chen wird – hier sind ganz vie­le hilf­rei­che sys­te­misch Ideen zu fin­den, die „manch­mal“ ganz erstaun­li­che Ver­ein­fa­chun­gen ermöglichen :-)

p.s.: die Idee von Ste­fan über die kom­ple­xen Zusam­men­hän­ge und Phä­no­me­ne zu dis­ku­tie­ren hal­te ich für super span­nend … das sind übri­gens die Cur­rent-Rea­li­ty-Trees der TOC

cu Wolf­ram

Dan­ke für Dei­nen Kom­men­tar, Ste­fan. Allein die Anzahl und Viel­falt der Kom­men­ta­re zeigt mir, dass es einer­seits ein wich­ti­ges Pro­blem ist, es aber ande­rer­seits kein Patent­re­zept geben kann. Inso­fern bin ich Dei­ner Mei­nung, dass wir erst Mal das Pro­blem ver­ste­hen soll­ten bevor wir in Lösun­gen den­ken. Ich mer­ke mir das The­ma auf jeden Fall Mal vor für das PM Camp 13 im November.

Das möch­te ich hinterfragen:
„nicht sofort in Lösun­gen zu den­ken, son­dern zuerst mal das Pro­blem gemein­sam zu ela­bo­rie­ren .… Die rei­ne For­mu­lie­rung eines Pro­blems ist oft­mals weit wich­ti­ger als sei­ne Lösung … dass ein sys­te­mi­sches Her­an­ge­hen zuerst erfor­dert, das Pro­blem und die damit ver­bun­de­nen Fra­ge­stel­lun­gen rich­tig zu verstehen“

Die Idee, zuerst das Pro­blem ver­ste­hen zu müs­sen ehe man Lösun­gen ent­wi­ckeln kann, passt nicht zu jeder Art von Pro­blem­stel­lun­gen. Ich gehe mal (gemäss C. Kurtz, D. Snow­den: The New Dyna­mics of Stra­tegy: Sen­se-making in a Com­plex-Com­pli­ca­ted World. In: IBM Sys­tems Jour­nal. vol. 42, no. 3 2003, S. 462 – 83) davon aus, dass es die­se Sicht­wei­sen von Pro­blem­stel­lun­gen gibt:
„“
Das Cyne­fin-Frame­work hat fünf Domä­nen. Die ers­ten vier davon sind:
o Simp­le, in der die Bezie­hung zwi­schen Ursa­che und Wir­kung für alle offen­sicht­lich ist. Die Her­ans­ge­hens­wei­se ist hier Sen­se – Cate­go­ri­se – Respond, und wir kön­nen bewähr­te Prak­ti­ken (best prac­ti­ce) anwenden.
o Com­pli­ca­ted, in der die Bezie­hung zwi­schen Ursa­che und Wir­kung Ana­ly­se oder eine ande­re Form der Prü­fung erfor­dert und/oder die Anwen­dung von Fach­wis­sen. Hier geht man mit­tels Sen­se – Ana­ly­ze – Respond her­an, und man kann gute Prak­ti­ken (good prac­ti­ce) anwenden.
o Com­plex, in der die Bezie­hung zwi­schen Ursa­che und Wir­kung nur im Nach­hin­ein wahr­ge­nom­men wer­den kann, aber nicht im Vor­aus. Hier ist der Ansatz Pro­be – Sen­se – Respond, und wir kön­nen emer­gen­te Prak­ti­ken (emer­gent prac­ti­ce) feststellen.
o Chao­tic, in der es kei­ne Bezie­hung zwi­schen Ursa­che und Wir­kung auf Sys­tem­ebe­ne gibt. Hier ist der Ansatz Act – Sen­se – Respond, und wir kön­nen inno­va­ti­ve Prak­ti­ken entdecken.
Die fünf­te Domä­ne ist Dis­or­der, der Zustand des Nicht-Wis­sens, wel­che Art von Kau­sa­li­tät besteht. In die­sem Zustand gehen die Leu­te in ihre eige­ne Kom­fort-Zone zurück, wenn sie eine Ent­schei­dung fällen.
„“
Vor die­sem Hin­ter­grund macht eine aus­gie­bi­ge Pro­blem­ana­ly­se nur bei als sim­pel oder kom­pli­ziert erschei­nen­den Fra­ge­stel­lun­gen Sinn. Das sind u.a. Fra­ge­stel­lun­gen im tech­nisch-natur­wis­sen­schaft­li­chen Bereich (und dar­auf bezog sich Ein­stein). Bei „kom­plex-adap­ti­ven“ Sys­te­men jedoch, so etwa sozia­len Hand­lungs­sys­te­men (und dazu gehö­ren auch Pro­jek­te), ist die aus­gie­bi­ge Pro­blem­ana­ly­se nicht ange­mes­sen. Im Gegen­teil: Sie führt vom Hun­derts­ten ins Tau­sends­te .… und schluss­end­lich zu einer alles wei­te­re Den­ken blo­ckie­ren­den „Pro­blem­trance“. Im Pro­jekt­kon­text sind das z.B. jene Mee­tings, die mona­te­lang alle mög­li­chen „wenn und aber“ pro­du­zie­ren … aber kei­ner­lei Fortschritt. 

Bei kom­plex erschei­nen­den Situa­tio­nen ist es bes­ser, statt das Pro­blem „wirk­lich“ ver­ste­hen zu wol­len so rasch als mög­lich mit einem ers­ten Lösungs­schritt zu begin­nen, also „inkre­men­tell-adap­tiv“ vorzugehen. 

Von Ste­ve de Shazer stam­men dazu die­se „irri­tie­ren­den“ Aussagen:
„Pro­blem talk crea­tes pro­blems, solu­ti­on talk crea­tes solution.“
„Die detail­lier­te Unter­su­chung und Ana­ly­se des Pro­blems hat auf die Lösungs­fin­dung kei­nen Einfluss“
„Pro­ble­me sind Pro­ble­me weil wir sie „Pro­ble­me“ nennen“ 

Mehr dazu hier:
http://www.solworld.org/notes/Jumpstart_into_Solution_Focus

Hi, der Thread wird ja immer bes­ser … das Cyne­fin-Frame­work is IMHO sehr inter­es­sant und hebt sich wohl­tu­end von den ande­ren Kom­ple­xi­tät-Cha­os-Abgren­zun­gen ab, in dem es 5 Fel­der defi­niert und somit die Welt, wie ich sie wahr­neh­me, bes­ser abbildet.

Auf der TOCICO 2013 in Bad Nau­heim wur­de noch eine wei­te­re Mög­lich­kei­ten dis­ku­tiert den kom­ple­xen Bereich zu adres­sie­ren. In der Tat ist der Ver­such das kom­ple­xe Sys­tem in all sei­nen Über­tra­gungs­funk­tio­nen vor­her­zu­se­hen frucht­los (das ist wie Wet­ter­vor­her­sa­ge). Was aber auch in kom­ple­xen Sys­te­men geht ist – die Cha­rak­te­ris­tik und die Wirk­zu­sam­men hän­ge zu ver­ste­hen – ohne die­ses Ver­ste­hen kann man kei­ne Ein­grif­fe in das Sys­tem vor­neh­men ohne es zu gefäh­ren und ins Cho­as zu trei­ben. Die TOCler reden daher nicht von Pro­blem-Talks – son­dern von Cur­rent-Rea­li­ty-Tree. Also wie sieht unse­re Wirk­lich­keit gera­de aus – wobei nur die Wirk­zu­sam­men­hän­ge von Rele­vanz sind.

Ste­ve Holt (Asso­cia­te Tech­ni­cal Fel­low Boe­ing und Board Mem­ber Theo­ry of Cons­traints Inter­na­tio­nal Cer­ti­fi­ca­ti­on Orga­niza­ti­on (TOCICO)) hat auf der TOCICO einen super Vor­trag gehal­ten wie die alter­na­ti­ve zu „rum­pro­bie­ren – ali­as inspect and adapt“ bei kom­ple­xen sys­te­men aus­se­hen kann. Die Sys­te­me erschei­nen uns so kom­plex weil sie zu vie­le Frei­heits­gra­de haben – der Trick ist also – die Frei­heits­gra­de zu begren­zen (ein „Cons­traint“ auf­zu­prä­gen) – an dem kann sich dann wie­der all­s­es aus­rich­ten – der Cons­traint lie­fert das Steu­er­si­gnal und ermög­lich stra­te­gi­sche Entscheidungen.

z.B. ein Flug­ha­fen ist defi­ni­tiv ein kom­ple­xes Sys­tem – die Lan­de­bahn ist der auf­ge­präg­te Cons­traint … oder im Auto­mo­bil­bau – die „Hoch­zeit“ ist der Cons­traint nach dem sich alles rich­tet … oder im Anla­gen­bau ist es die Inbe­trieb­nah­me … oder in „nor­ma­len“ Unter­neh­men die Pro­duk­te ent­wick­len und pro­du­zie­ren ist es der Über­gang in die Produktion … 

alle gro­ßen kom­ple­xe Sys­te­me haben einen Cons­traint um die Frei­heits­gra­de zu redu­zie­ren – ansons­ten wären sie Cha­os und damit auf Dau­er nicht lebensfähig.

Emer­gen­te Sys­tem­ei­gen­schaf­ten ent­ste­hen übri­gends nur und genau in dem Moment in dem das Sys­tem in den Frei­heits­gra­den begrenzt wird – von allei­ne emer­giert tat­säch­lich auch nichts. Die­se Erkennt­nis kommt aus der Ther­mo­dy­na­mik und ist noch älter als TOC. In dem Moment in dem man nicht mehr die Bewe­gung aller Ato­me berech­nen will – hat man Ther­mo­dy­na­mi­sche Glei­chun­gen auf eine höhe­ren Abs­trak­ti­ons­ebe­ne ein­ge­führt (Tem­pe­ra­tur) – damit das Gan­ze aber wie­der stim­mig wird muss­te man die Entro­pie ein­füh­ren. Sprich nur durch die Begren­zung der Kom­ple­xi­tät ist die neue Eigen­schaft entstanden.

cu Wolf­ram

p.s.: ich darf kein Link auf die Prä­sen­ta­ti­on raus­ge­ben – auf Anfra­ge eine raus­schi­cken ist ok Ste­ve hat da nichts dagegen …

Hans-Peter,

dan­ke für Dei­nen tol­len Input. Du hast voll­kom­men recht – ich war in der Wahl der Spra­che zu unpräzise. 

…das Pro­blem und die damit ver­bun­de­nen Fra­ge­stel­lun­gen rich­tig zu ver­ste­hen…“ ist für kom­ple­xe Sys­te­me nicht kor­rekt. Denn kom­ple­xe Sys­te­me / Pro­ble­me kann man nicht verstehen.

Eben­falls stim­me ich Dir zu, dass für kom­ple­xe Pro­ble­me nach dem Cyne­fin Modell der Lösungs­fo­kus ange­wen­det wer­den soll­te (sie­he hier­zu z.B. die Beschrei­bung von Paul Bay­er: http://www.wandelweb.de/blog/?p=1110)

Aller­dings gibt es auch ande­re Ansät­ze, Model­le und Theo­rien, die mei­nes Erach­tens nicht weni­ger rele­vant sind. Aber wir soll­ten tat­säch­lich beim PM Camp eine oder zwei Ses­si­ons dazu machen ;-)

Vie­le Grü­ße, Stefan

Das Pro­blem ist doch, was ist eine ange­mes­se­ne Aus­ein­an­der­set­zung mit der Pro­blem­stel­lung: Auch bei kom­ple­xen Situa­tio­nen soll­te ein Pro­blem­be­wusst­sein vor­han­den sein, sonst mutiert die Lösungs­fin­dung zum rei­nen Aktio­nis­mus. Also zumin­dest um eine rudi­men­tä­re Aus­ein­an­der­set­zung mit der Pro­blem­stel­lung wird man in kei­nem Fall umhin kommen.

Was bringt eine Aus­ein­an­der­set­zung mit der Pro­blem­stel­lung vor die­sem Hintergrund:

Com­plex, in der die Bezie­hung zwi­schen Ursa­che und Wir­kung nur im Nach­hin­ein wahr­ge­nom­men wer­den kann, aber nicht im Vor­aus. Hier ist der Ansatz Pro­be – Sen­se – Respond, und wir kön­nen emer­gen­te Prak­ti­ken (emer­gent prac­ti­ce) feststellen.

UND:
“Pro­blem talk crea­tes pro­blems, solu­ti­on talk crea­tes solution.”
“Pro­ble­me sind Pro­ble­me weil wir sie “Pro­ble­me” nennen”

??

Das Über­tra­gen von pro­blem­ori­en­tier­ten Lösungs­stra­te­gien, die im tech­nisch-natur­wis­sen­schaft­f­li­chen (= kom­pli­zier­ten) Bereich ange­mes­sen sind auf kom­ple­xe Situa­tio­nen ist eine „schlech­te Gewohnheit“!

Hi,

WENN: Com­plex, in der die Bezie­hung zwi­schen Ursa­che und Wir­kung nur im Nach­hin­ein wahr­ge­nom­men wer­den kann, aber nicht im Voraus. 

Dann hat man zwei Mög­lich­kei­ten (nicht nur eine)
a) Hier ist der Ansatz Pro­be – Sen­se – Respond, und wir kön­nen emer­gen­te Prak­ti­ken (emer­gent prac­ti­ce) feststellen.
b) man ver­än­dert das kom­ple­xe Sys­tem so dass es wie­der beherrsch­bar wird

Ich woll­te nur ein biss­chen den Tel­ler­rand öff­nen, dass es noch mehr Mög­lich­kei­ten gibt – als sich der Kom­ple­xi­tät erge­ben. By-the-way Scrum, Kan­ban nut­zen die­sen Mecha­nis­mus mas­siv in dem sie das Sys­tem Begren­zen (Time­bo­xes oder WIP-Limits)

Ach so man hat auch noch eine drit­te – in Hoch­in­no­va­ti­ons­sys­te­men (ten­die­ren zum Cha­os) macht weder a) noch b) Sinn … hier kön­nen c) hoch­it­te­ra­ti­ve Design Thin­king o.a. Inno­va­ti­ons­tech­ni­ken zum Zug kommen

cu Wolf­ram

p.s.: dein State­ment find ich sym­pa­thisch „Das Über­tra­gen von pro­blem­ori­en­tier­ten Lösungs­stra­te­gien, die im tech­nisch-natur­wis­sen­schaft­f­li­chen (= kom­pli­zier­ten) Bereich ange­mes­sen sind auf kom­ple­xe Situa­tio­nen ist eine “schlech­te Gewohn­heit”!“ … wür­de es aber trotz dem als per­sön­li­ches State­ment von dir ste­hen las­sen – es ent­hält kei­ne sys­te­misch Begrün­de­ten Argu­men­te, Annah­men und per­sön­li­che Wertungen ;-)

Zu dem:
„man ver­än­dert das kom­ple­xe Sys­tem so dass es wie­der beherrsch­bar wird“
1)
Ein Sys­tem kann kann ich nur dann ver­än­dern, wenn es von mir in der von mir gewünsch­ten Wei­se ver­än­der­bar ist. Bei von mir als kom­plex gese­he­nen Sys­te­men ist das lei­der nicht der Fall .… sonst wären sie ja nicht kom­plex son­dern kompliziert.
2)
Weder „Sys­te­me“ noch deren deren Merk­ma­le (kom­pli­ziert, kom­plex, …) sind „objek­ti­ve Tat­sa­chen“ son­dern mei­ne / unse­re Kon­struk­tio­nen und Zuschrei­bun­gen auf Basis des­sen, war wir wahr­neh­men (oder, bes­ser, „wahr­ge­ben“) und den­ken können.
3)
Mög­lich ist es, ein zunächst als „kom­plex“ betrach­te­tes „Sys­tem“ anders zu betrach­ten, näm­lich so, dass ich das, was ich als „Sys­tem“ betrach­te (z.B. sei­nen Gren­zen anders set­ze) oder mich ent­schei­de, den Ansatz Pro­be – Sen­se – Respond und die emer­gen­ten Prak­ti­ken auf­zu­ge­ben und mich statt des­sen dafür ent­schei­de, mit Sen­se – Ana­ly­ze – Respond her­an­zu­ge­hen, also gute Prak­ti­ken (good prac­ti­ce) anzuwenden.

ALSO:
Es liegt an mir/uns, was wir als „Sys­tem“ betrach­ten und wel­che Cha­rak­te­ris­tik wir ihm zuschrei­ben und mit ihm dem­entspre­chend umgehen.
Es gibt kei­ne „objek­ti­ven“ Kri­te­ri­en für „kom­pli­ziert“ oder „kom­plex“. Ob etwas kom­pli­ziert oder kom­plex ist, ist eine „unent­scheid­ba­re Fra­ge“, sie­he Heinz von Förs­ter. Und nur die „unent­scheid­ba­re Fra­gen“ sind – nach ihm – „ech­te“ Fra­gen. So etwa die Fra­ge: „Gibt es eine Leben nach dem Tod?“
Die Ant­wor­ten kön­nen wir nicht „wis­sen­schaft­lich ent­schei­den“, aber wir müs­sen uns für eine Ant­wort ent­schei­den – und Ver­ant­wor­tung gegen­über uns und der Welt für unse­re Ent­schei­dung übernehmen.

Wenn wir und also ent­schei­den, etwas „kom­pli­ziert“ zu sehen und es mit­tels Sen­se – Ana­ly­ze – Respond behan­deln, dann tra­gen wir auch die Ver­ant­wor­tung die dar­aus ent­ste­hen­den Folgen.
Bei Pro­jek­ten etwa die Ver­ant­wor­tung dafür, dass es klappt – oder in die Hosen geht.… 

Zu dem:
„es ent­hält kei­ne sys­te­misch Begrün­de­ten Argumente“
Was, bit­te, sind „sys­te­misch begrün­de­te Argu­men­te“? Ins­be­son­de­re im Unter­schied zu „nicht sys­te­misch begründete“?
Was genau meinst du mit „sys­te­misch“?
(Ich fra­ge das vor dem Hin­ter­gund mei­nes vor vie­len Jah­ren absol­vier­ten post­gra­dua­te Stu­di­ums zu „sys­te­mi­sches Manag­ment kom­ple­xer Pro­jek­te“ an der Uni Zürich… dank des­sen ich immer noch nicht genau weiss, was „sys­te­misch“ bedeutet…)

Dan­ke Hans-Peter für die letz­te Aus­füh­rung – ich hab nichts mehr hin­zu­zu­fü­gen – ich hab gera­de vie gelernt :-)

a) z.B. ich bevor­zu­ge wohl Sys­te­me, die ich ver­än­dern kann (ist wohl in mei­ner Per­sön­lich­keit – ich bin Macher) – daher sehe ich Sys­te­me of als kom­pli­ziert – ent­schei­de mich für enspre­chen­de Metho­den und ern­te dann die ent­spre­chen­den Erfolge :-)

b) „Am Schluss geht es dar­um sich für eine Ant­wort zu ent­schei­den und die Ver­ant­wor­tung zu über­neh­men …“ das ist zitier­fä­hig – darf ich das verwenden?

Wolf­ram

p.s.: das mit dem „nicht sys­te­misch begrün­det“ war nicht son­der­lich ernst gemeint – aber dei­ne Ant­wort ist klas­se „… dank des­sen [Stu­di­um] ich immer noch nicht genau weiss, was “sys­te­misch” bedeu­tet …“ – das trifft es gut – je tie­fer man sich mit etwas befasst des­to mehr­schich­ti­ger stellt sich oft die Situa­ti­on dar :-)

Zu dem:
“ “Am Schluss geht es dar­um sich für eine Ant­wort zu ent­schei­den und die Ver­ant­wor­tung zu über­neh­men …” das ist zitier­fä­hig – darf ich das verwenden?“

Du kannst das Ori­gi­nal zitieren:
„“
H.F. Eine ent­scheid­ba­re Fra­ge wird immer inner­halb eines Rah­mens ent­schie­den, der die mög­li­che und jeweils rich­ti­ge Ant­wort bereits vorgibt.
B. P. Was sind unent­scheid­ba­re Fragen?
H.F. Das sind Fra­gen, die etwa von der Exis­tenz höhe­rer Wesen­hei­ten, dem Sinn des Lebens, der Ent­ste­hung der Welt und dem Wei­ter­le­ben nach dem Tod han­deln. … Ich wür­de sogar sagen, daß die Fra­ge unent­scheid­bar ist, ob sich ein Expe­ri­ment fin­den läßt, das ein­deu­tig erweist, ob es sich um eine unent­scheid-bare Fra­ge han­delt. … Und in dem Moment, in dem ich eine unent­scheid­ba­re Fra­ge ent­schie­den habe, kommt die Ver­ant­wor­tung ins Spiel. Man ent­schließt sich, die Din­ge, die Welt und sei­ne Mit­men­schen auf eine beson­de­re Wei­se zu betrach­ten und ent­spre­chend zu han­deln. Man wird ver­ant­wort­lich für die Ent­schei­dung, die man getrof­fen hat und die einem nie­mand abneh­men kann.
„“
Quel­le: Wahr­heit ist die Erfin­dung eines Lügners
Heinz von Foers­ter (H.F.) /Bernhard Pörk­sen (B.P.)
Gesprä­che für Skeptiker
Carl-Auer-Sys­te­me Verlag

Sehr unter­halt­sam zu lesen !!!!! Und ein nur dün­nes Buch .…

Vie­len Dank für die rege und unglaub­lich anre­gen­de Dis­kus­si­on. Ich schlie­ße mich Wolf­ram an: Ich habe viel gelernt! Ins­be­son­de­re erhel­lend war die Erin­ne­rung, dass es kei­ne objek­ti­ven Maß­stä­be gibt son­dern letzt­lich alles mei­ne Kon­struk­ti­on ist. Auf Basis des­sen ent­schei­den wir und dafür müs­sen wir die Ver­ant­wor­tung tragen.

Ich habe mir erlaubt die­ses The­ma zur Dis­kus­si­on nach openPM zu über­tra­gen. Eure Kom­men­ta­re sind zu wich­tig, so dass ich es scha­de fän­de, wenn sie hier im Blog blie­ben. Viel­leicht fin­det ja der eine oder ande­re die Zeit und Muße einen Extrakt sei­ner Bei­trä­ge hier in den ent­spre­chen­den Arti­kel auf openPM ein­zu­ar­bei­ten (Kom­men­ta­re gehen auch, aber ein­ar­bei­ten in einen Arti­kel wäre schöner).

Schreibe einen Kommentar