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 Win­slow 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, Who­le­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 unterscheiden.

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 vertrauen.

Ä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 Umsetzungen.

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ösungsraums.

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

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).

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.

13 Kommentare

Hal­lo Marcus,
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ß
Bernhard

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 Ausschlüsse.

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 schlummert.

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­jektt­for­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 business“)?

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 Tay­lor’­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 bringen.
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 einsetzen ☺

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 Geschichte.

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 verfassen

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 Emergenz. 

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 Tail­oring. 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 verklausuliert).
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 geeignet.

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 Rahmenbedingungen.

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 Ausgestaltung ;-).

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üssten.

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 Rolle.

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 bekommen.

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 realisieren.

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 Projekte :)

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 Projektmanager.
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 überfordert“.
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 findet.

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 Projektmanager.

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ückzutreten.

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 zusammenhängen.

Schreibe einen Kommentar