Dekonstruktion des Projektmanagements

Men­schen machen Pro­jek­te. Viel län­ger schon als Pro­jekt­ma­nage­ment stan­dar­di­siert und zer­ti­fi­ziert wird. Weder für die Pyra­mi­den noch für die chi­ne­si­sche Mau­er waren ein PMBOK oder eine ICB not­wen­dig. Über die letz­ten Jahr­zehn­te hin­weg sam­mel­ten ver­schie­de­ne Insti­tu­tio­nen das vor­han­de­ne ange­wand­te Wis­sen im Pro­jekt­ma­nage­ment und ver­dich­te­ten es zu dicken Büchern. Das alles unter dem Ein­fluss der aus heu­ti­ger Sicht frag­wür­di­gen und teil­wei­se unpas­sen­den Para­dig­men von Fre­de­rick Winslow Tay­lor. Peter F. Dru­cker erkann­te bereits, dass im Zeit­al­ter der Wis­sens­ar­beit die Zusam­men­ar­beit von Wis­sens­ar­bei­tern neu zu orga­ni­sie­ren sein wird. Ent­spre­chend erle­ben wir der­zeit neue For­men und Expe­ri­men­te der Unter­neh­mens­füh­rung (Sem­co, Gore, Whole­Foods, etc.) und eben­so alter­na­ti­ve For­men der Pro­jekt­durch­füh­rung (Scrum und ande­re agi­le Model­le). Anstatt nun ver­geb­lich über die eine rich­ti­ge Metho­de zu strei­ten, soll­ten wir eini­ge Schrit­te zurück tre­ten und sau­ber zwi­schen Anfor­de­rung und Umset­zung unter­schei­den.

Eine Anfor­de­rung könn­te zum Bei­spiel sein: „Ich will jeder­zeit über den Fort­schritt des Pro­jekts infor­miert sein.“ Umset­zen lässt sich das mit Pro­jekt­struk­tur­plan, Ablauf­plan und das Ver­fol­gen der Abar­bei­tung des Plans. Oder über Pro­duct-Back­log und Burn­down-Chart. Oder nach einer Metho­de die wir noch nicht ken­nen und ver­sucht haben.

Eine ande­re Anfor­de­rung wäre: „Die Arbeits­kraft und Krea­ti­vi­tät der Mit­ar­bei­ter soll best­mög­lich genutzt wer­den.“ Wie­der­rum kann man das durch einen detail­lier­ten Res­sour­cen­plan (ein schreck­li­ches Wort) machen. Oder auf die Selbst­or­ga­ni­sa­ti­on von Teams ver­trau­en.

Ähn­lich lie­ßen sich mei­ner Mei­nung nach alle Metho­den und Pro­zes­se im Pro­jekt­ma­nage­ment auf ihre eigent­li­che Anfor­de­rung zurück­füh­ren. Die bekann­ten, stan­dar­di­sier­ten und zer­ti­fi­zier­ba­ren Metho­den wären dann nur eine Aus­prä­gung im Lösungs­raum mög­li­cher Umset­zun­gen.

Anstatt über die eine bes­te Lösung zu dis­ku­tie­ren oder die­se sogar zu stan­dar­di­sie­ren (ein durch und durch tay­lo­ris­ti­sches Ansin­nen), wür­de ich lie­ber einen Schritt zurück tre­ten und in Anfor­de­run­gen den­ken wol­len. Zu die­sem Fächer an Anfor­de­run­gen gäbe es dann ver­schie­de­ne Umset­zun­gen mit jeweils spe­zi­fi­schen Bedin­gun­gen zum Ein­satz, mit Wech­sel­wir­kun­gen (posi­tiv oder nega­tiv) und mit Erfah­rungs­be­rich­ten. Jedes neue Expe­ri­ment in der Umset­zung einer Anfor­de­rung, jede Varia­ti­on wäre dann kei­ne Abwei­chung von der Norm, son­dern eine will­kom­me­ne Berei­che­rung des Lösungs­raums.

Genau dafür könn­ten wir openPM nut­zen.

Was wir brau­chen, sind ein paar ver­rück­te Leu­te; seht euch an, wohin uns die Nor­ma­len gebracht haben.
Geor­ge Ber­nard Shaw (via @lazyNadja)

Weiterlesen

Arti­kel­bild: Chris­toph Michels auf Wiki­me­dia (CC BY-SA 2.5).

Auf dem Laufenden bleiben

Du willst kei­nen Arti­kel mehr ver­pas­sen? Mit mei­nem News­let­ter bekommst du in der Regel ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Ein­gangs­korb.

13 Kommentare

Hal­lo Mar­cus,
dei­ne Anfor­de­rungs­bei­spie­le fin­de ich unglück­lich, weil sie sich auf der Meta­ebe­ne befin­den. Ver­mut­lich müs­sen wir neben Anfor­de­rung und Umset­zung noch die Sach­ebe­ne und eine Meta­ebe­ne unter­schei­den. Unter Sach­ebe­ne ver­ste­he ich die kon­kre­te Problemstellung/den Pro­jekt­auf­trag. Das Pro­blem mit der Meta­ebe­ne ist, dass sie schnell zum Selbst­zweck wird. Wol­len wir unse­re Mit­ar­bei­ter aus­las­ten, den Fort­schritt tra­cken oder das Pro­blem lösen?
Gruß
Bern­hard

Die Bei­spie­le befin­den sich ganz bewusst auf der Meta­ebe­ne. Denn dort­hin möch­te ich zurück. Nicht zum Selbst­zweck, son­dern als Fun­da­ment und Rah­men. Natür­lich will jedes Pro­jekt ein kon­kre­tes Ziel errei­chen oder ein kon­kre­tes Pro­blem lösen. Ich glau­be aber, dass das es dafür all­ge­mein gül­ti­ge Anfor­de­run­gen gibt, z.B. eben die Fest­le­gung des Umfang, Pla­nung, Ver­fol­gung der Abar­bei­tung. Und die wür­de ich ger­ne von der kon­kre­ten Umset­zung und Aus­prä­gung tren­nen wol­len. Nicht um dann auf der Meta­ebe­ne ein Glas­per­len­spiel zu betrei­ben, son­dern um im zwei­ten Schritt sau­ber über ver­schie­de­ne Umset­zun­gen reden zu kön­nen, über deren Eig­nung für bestimm­te Pro­ble­me und über Abhän­gig­kei­ten und Aus­schlüs­se.

Ich fin­de die Idee sehr erfri­schend und mir kürz­lich in punc­to Stan­dards einen ähn­li­chen Blog-Post vor­ge­nom­men, der aller­dings noch in der Schub­la­de schlum­mert.

Dei­ne Aus­füh­run­gen haben aber schon mal viel inter­es­san­ten Zünd­stoff in sich ;)

Zunächst passt sicher wie immer der Spruch von G. Box: „„Alle Model­le sind falsch, man­che sind nütz­lich“. Also, wie immer wir die (soge­nann­te) „Rea­li­tät“ – ich bin Kon­struk­ti­vist – zu fas­sen ver­su­chen – es kann ggf. immer nur in sehr ein­ge­schränk­ter Form hilf­reich sein.

Ich glau­be auch, dass die For­mie­rung von PM als Dis­zi­plin, erst eine Errun­gen­schaft des letz­ten Jahr­hun­derts war, als zahl­rei­che Inge­nieu­re dar­an schei­ter­ten ihre Engi­nee­ring-Pro­jek­te (vor­ran­gig mili­tä­ri­scher Natur) geord­net und vor allem in Erwar­tung der Spon­so­ren ins Ziel zu brin­gen. Dies ist – wie Du es andeu­test – aber lei­der recht spät erfolgt. In einem Zeit­al­ter, wo Com­mand-und-Con­trol immer weni­ger funk­tio­niert, mecha­nis­ti­sches Den­ken kaum mehr in Abgleich mit den Inno­va­tio­nen und Dienst­leis­tun­gen der Zukunft zu brin­gen sind. Wenn Wett­be­werbs­vor­tei­le durch selbst­or­ga­ni­sier­te Teams, durch Co-Crea­ti­on, durch emer­gen­te Pro­zes­se und Pro­duk­te ent­ste­hen, dann sind all­zu star­re Model­le schnell im Weg.

Unter die­sem Licht wären Anfor­de­run­gen ein hilf­rei­cher Ansatz, die Unter­schie­de im Bedarf der Welt von heu­te und mor­gen gegen­über dem zu ver­ste­hen, was uns noch vor Jahr­zehn­ten getrie­ben hat, dicke Stan­dards zu ver­fas­sen. Dei­ne ange­führ­ten Bei­spie­le lie­fern dazu bereits sehr gute Anre­gun­gen. Wie kann mich der Pro­jekttfor­schritt ent­lang eines Plans inter­es­sie­ren, wo der Plan – in Unkennt­nis der künf­ti­gen Optio­nen – ein bereits über­hol­tes Kon­strukt dar­stellt? Wie könn­te ich anhand von Plä­nen die Krea­ti­vi­tät för­dern oder gar zu erzwin­gen ver­su­chen (obwohl ich glau­be, man­che haben es ver­sucht und sind heu­te „out of busi­ness“)?

Es drängt sich die Hoff­nung auf, dass ein der­ar­ti­ger Ver­such nicht dort endet, dass die Anfor­de­run­gen an das Unter­fan­gen kom­ple­xer wer­den, als das Unter­fan­gen selbst (wäre das eine Recht­fer­ti­gung der Taylor’schen Idee oder gar der PM-Abtei­lun­gen=). Und es liegt die Ver­mu­tung nahe, dass man so zu situa­ti­ven Kon­stel­la­tio­nen gelangt, wo umfang­rei­che­re Pro­zes­se und Metho­den mög­li­cher­wei­se bei eher repe­ti­ti­ven „Pro­jek­ten“ zumin­dest zu Aus­sa­gen gelan­gen. Ja, und dann könn­te noch die Fra­ge auf­kom­men, ob denn die­se repe­ti­ti­ven Auf­ga­ben über­haupt den Kern­ge­dan­ken des PM genü­gen: Ein­zig­ar­tig­keit, Ein­ma­lig­keit, Neu­ar­tig­keit … Ich glau­be z.B., dass sich vie­le Orga­ni­sa­tio­nen im Pro­jekt­ge­schäft wäh­nen, obwohl ihre „Pro­jek­te“ immer wie­der das­sel­be Geschäft mit gewis­sen Abwand­lun­gen brin­gen.
Die Fra­ge wäre nur: wenn auf Grund der Wie­der­ho­lung die Vor­her­sag­bar­keit wesent­lich höher ist, wozu brau­chen wir dann den gan­zen Over­head? Gut, viel­leicht kann man dann end­lich guten Gewis­sens eine EVA ein­set­zen ☺

Und das bringt mich wie­der zu mei­nem Aus­gangs­ge­dan­ken über die „Kon­struk­ti­on“ von Model­len zurück. Näm­lich mit der Fra­ge, ob es bloss um den Ein­satz der pas­sen­den Metho­de in der geeig­ne­ten Situa­ti­on geht, oder ob da noch mehr dahin­ter steckt? Ich glau­be an Let­ze­res – wie wir es in den Scrum Trai­nings ver­mit­teln … es geht eben nicht um den Scrum-Pro­zess, um die Arte­fak­te, die Zere­mo­nien … es geht um das Mind­set … das Mind­set als Grund­la­ge für Ler­nen, für Ver­än­de­rung, für Emer­genz. Und in die­sem Licht wird es mit gros­ser Wahr­schein­lich­keit auch in einem Scrum-Team gesche­hen, dass der ursprüng­li­che Pro­zess ver­än­dert wird, dass Arte­fak­te über Bord gewor­fen wer­den, dass dem „Wun­der­ba­ren“, dem Poten­ti­al der Teams, der Co-Crea­ti­on, dem Pro­dukt der Weg geeb­net wird. Ein brei­ter Spruch aus der Com­mu­ni­ty lau­tet: es geht nicht um „Doing Agi­le“, son­dern um „Being Agi­le“. Aber das ist eine ande­re Geschich­te.

Inter­es­san­te Gedan­ken! Ich picke mir Mal zwei raus.

Unter die­sem Licht wären Anfor­de­run­gen ein hilf­rei­cher Ansatz, die Unter­schie­de im Bedarf der Welt von heu­te und mor­gen gegen­über dem zu ver­ste­hen, was uns noch vor Jahr­zehn­ten getrie­ben hat, dicke Stan­dards zu ver­fas­sen

Ich glau­be, dass Anfor­de­run­gen an das Manage­ment von Pro­jek­ten zeit­los sein kön­nen und soll­ten. Jedes Pro­jekt braucht ein gewis­ses Maß an Pla­nung und Ver­fol­gung bei­spiels­wei­se. Wie das umge­setzt wird, in wel­chem Kon­text sich die spe­zi­fi­sche Umset­zung eig­net und in wel­chem nicht, das wäre zu unter­su­chen. Da kann es dann auch his­to­ri­sche Arte­fak­te geben, also Umset­zun­gen die zwar frü­her funk­tio­nier­ten, aber heu­te nur in Aus­nah­me­fäl­len anwend­bar sind.

Und das bringt mich wie­der zu mei­nem Aus­gangs­ge­dan­ken über die “Kon­struk­ti­on” von Model­len zurück. Näm­lich mit der Fra­ge, ob es bloss um den Ein­satz der pas­sen­den Metho­de in der geeig­ne­ten Situa­ti­on geht, oder ob da noch mehr dahin­ter steckt? Ich glau­be an Let­ze­res – wie wir es in den Scrum Trai­nings ver­mit­teln … es geht eben nicht um den Scrum-Pro­zess, um die Arte­fak­te, die Zere­mo­nien … es geht um das Mind­set … das Mind­set als Grund­la­ge für Ler­nen, für Ver­än­de­rung, für Emer­genz.

Dem stim­me ich zu. Es geht sicher­lich um mehr als bloß einen mög­lichst vol­len Werk­zeug­kas­ten bereit­zu­stel­len. Den­noch könn­te ich mir vor­stel­len, dass ein Cross-over einen gewis­sen Charme hät­te: wenn die ver­schie­de­nen Umset­zun­gen und Metho­den neben­ein­an­der stün­den, könn­ten eigent­lich agi­le Metho­den in klas­si­schen Pro­jek­ten Anwen­dung fin­den und umge­kehrt. Wir könn­ten ja für jede Umset­zung einer Anfor­de­rung defi­nie­ren / erfor­schen, wel­che Para­dig­men im Unter­neh­men bzw. im Umfeld gege­ben sein müs­sen, damit eine Anwen­dung mög­lich ist.

Moin Mar­cus,

End­lich kommt man schein­bar doch auf des Pudels Kern :-)

Metho­di­ken sind Leit­fä­den und kei­ne Para­dig­men. Das wird zu oft außer Acht gelas­sen. Inter­es­san­te Samm­lun­gen von Erfah­run­gen. Aber Ihr Ein­satz muss ange­passt wer­den an das Umfeld, die Auf­ga­be, das Team.
Aber das Pro­blem in der „Wirt­schaft“ ist, dass man der­ar­ti­ger krea­ti­ver Arbeits­wei­se nicht traut und lie­ber dem „Stan­dard“ sehen will. Ich mag das PMBOK, ein­fach weil es gute Ideen ent­hält. Anwen­den kann man es aber nur unter star­kem Tailo­ring. Ich mag auch agi­les vor­ge­hen, aber SCRUM ist zu sta­tisch in der Metho­dik, lässt also die oben genann­ten nöti­gen Anpas­sun­gen nicht zu.
Hin­fort mit Metho­den ist genau­so falsch wie bedin­gungs­lo­ses dar­an fest­hal­ten. An sich ist es die Auf­ga­be eines jeden Pro­jekts sich an sein Umfeld anzu­pas­sen (steht auch im PMBOK, wenn auch ver­klau­su­liert).
openPM ist ein tol­ler Ansatz, droht aber in der Agi­li­täts­af­fi­ni­tät unter­zu­ge­hen. Denn so wie PM Ver­fech­ter in den 90er sind heu­te die Agi­los am Werk.
„Open your (PM) mind“ wür­de ich allen Metho­den-Freaks ger­ne zuru­fen … aber ich weiss nicht, ob das ankommt :-)
Jens

Du hast voll­kom­men recht: jeder Stan­dard, jedes Modell muss ange­passt wer­den. Stur nach Vor­schrift ange­wen­det, ist alles gleich schlecht geeig­net.

openPM ist ein tol­ler Ansatz, droht aber in der Agi­li­täts­af­fi­ni­tät unter­zu­ge­hen. Denn so wie PM Ver­fech­ter in den 90er sind heu­te die Agi­los am Werk.
“Open your (PM) mind” wür­de ich allen Metho­den-Freaks ger­ne zuru­fen … aber ich weiss nicht, ob das ankommt :-)

Doch das kommt an. Im Mis­si­on-State­ment von openPM gibt es ein ganz wich­ti­ges Wort: Viel­falt. Im Moment fehlt uns aller­dings noch ein wenig Struk­tur, um die­se Viel­falt abzu­bil­den. Dazu möch­te ich ger­ne zurück zu abs­trak­ten, all­ge­mein gül­ti­gen Anfor­de­run­gen, um dann über Umset­zun­gen der Anfor­de­run­gen mit spe­zi­fi­schen Vor­aus­set­zun­gen, Para­dig­men und Rah­men­be­din­gun­gen.

Gera­de bei Scrum kommt dann aber nichts mehr Ver­nünf­ti­ges dabei raus. Scrum ist bereits auf das Wesent­li­che zusam­men­ge­dampft wor­den, so daß man nichts mehr weg­las­sen kann vom Frame­work. Dazwi­schen bie­tet es aller­dings eine Men­ge Raum für krea­ti­ve Aus­ge­stal­tung ;-).

Scrum ist eine Mög­lich­keit Pro­jek­te durch­zu­füh­ren. Ich will nicht Scrum abs­tra­hie­ren, son­dern den gemein­sa­men Nen­ner aller Mög­lich­kei­ten Pro­jek­te durch­zu­füh­ren fin­den. Es gibt Din­ge (ich habe sie Anfor­de­run­gen genannt) die in jedem Pro­jekt so oder eben anders gemacht wer­den müs­sen. Die­se Anfor­de­run­gen bil­den den Rah­men in den sich die kon­kre­ten Metho­den, wie z.B. ein Pro­duct Back­log zur Ver­wal­tung des Umfangs eines Pro­jekts, ein­sor­tie­ren las­sen müss­ten.

Ich bin mal ganz ket­ze­risch und drü­cke mal alles bis­her geäu­ßer­te platt:
Ein Unter­neh­men im 21 Jahr­hun­dert, das erfolg­reich ist, hat erfolg­rei­che Mit­ar­bei­ter (und damit mei­ne ich alle Mit­ar­bei­ter), die sich die Metho­den, die am bes­ten zu ihnen pas­sen, selbst aus­su­chen und sich ihren eige­nen erfolg­rei­chen Rah­men schaf­fen. Sie suchen sich, was sie benö­ti­gen, um erfolg­reich zu sein, egal wel­ches Eti­kett drauf steht.

Alles ande­re spielt aus mei­ner Sicht kei­ne Rol­le.

Nur ist die­se Suche nach den geeig­ne­ten Metho­den der­zeit müh­sam. Es gibt zu vie­le Metho­den, die als „sil­ver-bul­let“ geprie­sen wer­den ohne je dar­über nach­ge­dacht zu haben, wel­che Anfor­de­rung sie lösen, unter wel­chen Umstän­den sie anwend­bar sind und wel­che Wech­sel­wir­kun­gen sie mit ande­ren Metho­den haben. Eigent­lich müss­te jede kon­kre­te Umset­zung einer Anfor­de­rung wie ein Medi­ka­ment einen Bei­pack­zet­tel bekom­men.

Ist tat­säch­lich etwas ket­ze­risch, aber im Kern auch wahr. Ich wür­de sogar soweit gehen, wenn die Mit­ar­bei­ter Spaß an dem haben, was Sie arbei­ten, stellt sich Erfolg auch ein. Ich zie­he einen Ver­gleich mit der Rea­li­sie­rung von openPM. Es gab kein detail­lier­tes Anfor­de­rungs­pa­pier, kei­nen CEO/kein Mgmt. Board, geschwei­ge denn Bud­gets. Trotz­dem gibt es die Platt­form jetzt. Und alle hat­ten Spaß dar­an, das Pro­jekt openPM zu rea­li­sie­ren.

Wobei wir viel­leicht in der Dis­kus­si­on etwas dif­fe­ren­zie­ren müs­sen, von wel­chen Arbeiten/Unternehmen/Märkten wir spre­chen. Ich den­ke bei Pro­jek­ten und Pro­jektmgmt. z.B. immer gleich an IT Pro­jek­te :)

Am meis­ten zu einem Kom­men­tar pro­vo­ziert hat mich die Replik von Jens von Gers­dorff. Auf der einen Sei­te schreibt er, er möge das PMBOK, weil es gute Ideen ent­hal­te. Dabei ist das PMBOK die Bibel der PM Ver­fech­ter nicht nur der 90ern, son­dern eher der 70er Jah­re mit ihren unre­flek­tier­ten Begrif­fen wie Ear­ned Value Ana­ly­sis, Cri­ti­cal Path, work Break­down struc­tu­re, etc. Auf der ande­ren Sei­te sieht er in der Agi­li­täts­af­fi­ni­tät eine Gefahr für openPM (der eigent­li­che Grund, wes­halb ich mich von openPM fern­hal­te). Für den Hin­weis auf die­ses Risi­ko dan­ke ich ihm sehr.
Die Metho­de inter­es­siert mich wirk­lich erst in zwei­ter Linie und hängt sehr von der Pro­jekt­art ab. Mich nervt die For­de­rung nach Stan­dar­di­sie­rung mit dem Hin­weis, dass jede (Dienst)Leistung immer gleich sein müs­se. Ich will gar nicht gleich­ge­schal­te­te und stan­dar­di­sier­te Pro­jekt­ma­na­ger.
Viel­mehr müss­te man sich end­lich über­le­gen, zu was ein Pro­jekt­ma­na­ger über­haupt fähig ist. Wolf Sin­ger sagt: „Wir sind unfä­hig, nicht­li­nea­re Phä­no­me­ne zu erfas­sen. Das klingt zwar abs­trakt, erklärt sich aber aus der Evo­lu­ti­on: Im Klei­nen, und nur dar­auf ist unser Gehirn ein­ge­stellt und nur dar­an ist es ange­passt, ver­hält sich die Welt line­ar. Die­se Unfä­hig­keit sei auch kein Wun­der, denn nicht­li­nea­re Vor­gän­ge sind nicht vor­her­sag­bar, das Hirn als prä­dik­ti­ves Sys­tem wäre also über­for­dert“.
Anstatt (unrea­lis­ti­sche) Prak­ti­ken zu dis­ku­tie­ren, wäre es wich­ti­ger, ein paar Schrit­te zurück­zu­tre­ten. Aber über Metho­den und agi­lem Vor­ge­hen zu dis­ku­tie­ren geht mit kogni­ti­ver Leich­tig­keit ein­her. Das erklärt viel­leicht auch, war­um die For­schungs­werk­statt der GPM über Theo­rien des Pro­jekt­ma­nage­ments, die im Novem­ber in Ber­lin statt­fin­det, so wenig Beach­tung fin­det.

Dan­ke für Dei­nen Kom­men­tar! Die Gefahr der Ver­ein­nah­mung von openPM in eine Glau­bens­rich­tung ist mir bewusst.

Mich nervt die For­de­rung nach Stan­dar­di­sie­rung mit dem Hin­weis, dass jede (Dienst)Leistung immer gleich sein müs­se. Ich will gar nicht gleich­ge­schal­te­te und stan­dar­di­sier­te Pro­jekt­ma­na­ger.

Da stim­me ich Dir voll und ganz zu: Stan­dar­di­sie­rung an sich ist ein durch und durch tay­lo­ris­ti­sches Ansin­nen und macht für anspruchs­vol­le Füh­rungs­auf­ga­ben in Pro­jek­ten kei­nen Sinn.

Viel­mehr müss­te man sich end­lich über­le­gen, zu was ein Pro­jekt­ma­na­ger über­haupt fähig ist. Wolf Sin­ger sagt: “Wir sind unfä­hig, nicht­li­nea­re Phä­no­me­ne zu erfas­sen. Das klingt zwar abs­trakt, erklärt sich aber aus der Evo­lu­ti­on: Im Klei­nen, und nur dar­auf ist unser Gehirn ein­ge­stellt und nur dar­an ist es ange­passt, ver­hält sich die Welt line­ar. Die­se Unfä­hig­keit sei auch kein Wun­der, denn nicht­li­nea­re Vor­gän­ge sind nicht vor­her­sag­bar, das Hirn als prä­dik­ti­ves Sys­tem wäre also über­for­dert”. Anstatt (unrea­lis­ti­sche) Prak­ti­ken zu dis­ku­tie­ren, wäre es wich­ti­ger, ein paar Schrit­te zurück­zu­tre­ten.

Auch das fin­de ich eine loh­nen­de Denk­rich­tung. Um zu ver­ste­hen zu was ein Pro­jekt­ma­na­ger fähig sein müss­te, wäre es mei­ner Mei­nung nach sinn­voll erst Mal die paar Schrit­te von der kon­kre­ten Metho­dik zurück­zu­tre­ten und zu ver­ste­hen was ein Pro­jekt aus­macht, wel­che Anfor­de­run­gen man dort fin­det und wie die­se zusam­men­hän­gen.

Schreibe einen Kommentar