Best Practice: organisierte Verantwortungslosigkeit

Wann immer Pro­jek­te nicht opti­mal lau­fen oder sogar gran­di­os schei­tern, schlägt die Stun­de der Apo­lo­ge­ten des bedin­gungs­lo­sen Glau­bens an Best Prac­ti­ce. „Bewähr­te, opti­ma­le bzw. vor­bild­li­che Metho­den, Prak­ti­ken oder Vor­ge­hens­wei­sen im Unter­neh­men“ (Defi­ni­ti­on: Wiki­pe­dia) müs­sen her, um künf­ti­ges Unge­mach abzu­wen­den – so die gän­gi­ge Logik. Nun ist nichts ein­zu­wen­den gegen die Anwen­dung von bewähr­ten Prak­ti­ken, nur eben nicht bedin­gungs­los, blind und dog­ma­tisch, son­dern situa­tiv, über­legt und ange­passt.

Sicher­lich lässt sich über den rich­ti­gen Gebrauch eines Ham­mers im Sin­ne einer Best Prac­ti­ce viel schrei­ben, aber was nützt das schon, wenn die kon­kre­te Situa­ti­on die Ver­wen­dung von Schrau­ben und Dübeln erfor­dert? Es nützt nichts und meis­tens scha­det es sogar, weil das Hin­ter­fra­gen der Anwend­bar­keit der Metho­de auf das jewei­li­ge Pro­blem aus­bleibt.

Wer als Werk­zeug nur einen Ham­mer hat, sieht in jedem Pro­blem einen Nagel.
Paul Watz­la­wick

In dem bana­len Bei­spiel ist das Pro­blem der bedin­gungs- und kon­text­lo­sen Emp­feh­lung und folg­lich unhin­ter­frag­ten Anwen­dung von Best Prac­ti­ce sofort jedem ersicht­lich. Den­noch pas­siert genau das in vie­len Unter­neh­men wenn es um die Nut­zung von Best Prac­ti­ce im Pro­jekt­ma­nage­ment und kon­se­quent wei­ter gedacht um die Stan­dar­di­sie­rung der Durch­füh­rung von Pro­jek­ten geht. Aus der mehr­ma­li­gen erfolg­rei­chen Anwen­dung eines Werk­zeugs oder einer Vor­ge­hens­wei­se wird unter Ver­nach­läs­si­gung des spe­zi­fi­schen Kon­texts per Inge­nieurs-Induk­ti­on geschlos­sen, dass die­ses Werk­zeug oder die­se Vor­ge­hens­wei­se immer nütz­lich sei.

Eine Mei­len­stein-Trend­ana­ly­se (MTA) bei­spiels­wei­se ist eine fei­ne Sache. Anstatt immer nur die aktu­el­len Mei­lenstein­ter­mi­ne zu berich­ten, zeigt eine MTA Trends in der Ent­wick­lung die­ser Mei­len­stei­ne und lässt so Rück­schlüs­se auf die Lage des Pro­jekts zu. Dazu müs­sen die Mei­lenstein­ter­mi­ne aber auch ver­än­der­lich sein. Das sind sie aber nicht immer. In vie­len Pro­jek­ten sind die Ter­mi­ne starr vor­ge­ge­ben, bei­spiels­wei­se in Form von zwei oder drei fes­ten Relea­ses im Jahr, aber der Umfang dafür fle­xi­bel. Natür­lich kann man trotz­dem eine MTA machen, nur ist die­se dann eben völ­lig sinn­frei.

Einen schö­nen gra­fi­schen Ablauf­plan (sie­he die Arti­kel­se­riePro­jekt­pla­nung 101), nicht zu kom­pli­ziert und groß, man­ga­ge­ment­taug­lich auf einer Folie dar­stell­bar (die Schrift­grö­ße ist ja zum Glück ein­stell­bar), wird aber doch wohl jedes Pro­jekt brau­chen, oder? Wie die MTA kann man einen sol­chen Plan in jedem Pro­jekt machen, nur vari­iert eben sei­ne Aus­sa­ge­kraft und sein Nut­zen. Beson­ders in agi­len Pro­jek­ten wird ein sol­cher Plan schnell zur läs­ti­gen Pflicht­übung. Die Ablauf­pla­nung in agi­len Pro­jek­ten ist recht tri­vi­al: Es fol­gen Sprint auf Sprint bis zu einem defi­nier­ten End­ter­min. Das span­nen­de ist nur der Umfang der Sprints, der aber prin­zi­pi­ell erst unmit­tel­bar vor jedem Sprint fest­ge­legt wird.

Das waren nur zwei Bei­spie­le für die Sinn­lo­sig­keit bedin­gungs- und kon­text­lo­ser Anwen­dung von Best Prac­ti­ce. Man mag nun ein­wen­den, das alles sei zwar unschön, aber scha­den wür­de es ja auch nicht, die­se Werk­zeu­ge der Stan­dar­di­sie­rung wegen trotz­dem anzu­wen­den. Solan­ge das bewusst geschieht und dem Pro­jekt­lei­ter dane­ben noch genü­gend Zeit für die­je­ni­ge Auf­ga­ben bleibt, die tat­säch­lich einen Unter­schied machen, ist dage­gen auch nichts ein­zu­wen­den.

Über­ar­bei­te­te Mana­ger beschäf­ti­gen sich mit Din­gen, mit denen sie sich nicht beschäf­ti­gen soll­ten.
Tom de Mar­co

In der Pra­xis ist mit Best Prac­ti­ce und ihrer Zusam­men­fas­sung als Vor­ge­hens­mo­del­le aller­dings fast immer ein trü­ge­ri­sches Heils­ver­spre­chen ver­bun­den: Erfolg­reich wird sein, wer alles nach Vor­schrift umsetzt. Die Anwen­dung der ohne Fra­ge guten Werk­zeu­ge und Metho­den geschieht dann meist unre­flek­tiert und ohne den indi­vi­du­el­len Kon­text des jewei­li­gen Pro­jekts zu berück­sich­ti­gen. Die Ver­ant­wor­tung für die pas­sen­de Gestal­tung des Pro­jekts und sei­ner Abläu­fe wird so an das Vor­ge­hens­mo­dell und sei­ne Samm­lung an Best Prac­ti­ce dele­giert. Es lebe die orga­ni­sier­te Ver­ant­wor­tungs­lo­sig­keit: alles ordent­lich gere­gelt und stan­dar­di­siert und trotz­dem geschei­tert.

Best Prac­ti­ce ent­he­ben den Pro­jekt­lei­ter nicht von der Ver­ant­wor­tung das Pro­jekt selbst zu gestal­ten. Im Gegen­teil ist es gera­de die krea­ti­ve Umset­zung und Anpas­sung von Stan­dards und die pass­ge­naue Nut­zung von Best Prac­ti­ce die erfolg­rei­ches Pro­jekt­ma­nage­ment aus­ma­chen. Und manch­mal passt auch kei­nes der Werk­zeu­ge und man muss ein neu­es bas­teln, das dann viel­leicht mor­gen zur Best Prac­ti­ce erho­ben wird. Pro­jek­te haben immer etwas Unge­wis­ses und sind daher auch immer Expe­ri­men­te, nicht nur in Bezug auf den Pro­jekt­ge­gen­stand son­dern eben auch in Bezug auf die Vor­ge­hens­wei­se und die ein­ge­setz­ten Metho­den und Werk­zeu­ge.

I’m as proud of what we don’t do as I am of what we do.
Ste­ve Jobs

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.

19 Kommentare

Hal­lo Mar­cus,

Dein Bei­trag spricht mir aus dem Her­zen! Schön auf den Punkt gebracht.

Die Best-Prac­ti­ce-Gläu­big­keit zieht sich inzwi­schen durch vie­le Lebens­la­gen. In mei­nem Bereich (IT-Ser­vice-Manage­ment) ist dies auch beson­ders aus­ge­prägt. Wir spre­chen da ja von ITIL ein­füh­ren, was mei­ner Mei­nung nach mit Best Prac­ti­ces nicht geht. Ich habe mir dazu vor gerau­mer mei­ne Gedan­ken in einem Blog­post auf­ge­schrie­ben.
Etwas ähn­li­ches pas­siert mei­ner Beob­ach­tung nach mit den „agi­len Metho­den“. Die schei­nen mir momen­tan der hei­li­ge Gral im Pro­jekt­ma­nage­ment zu sein.

Lars Voll­mer hat in sei­nem Buch Wrong Turn die­ses und ande­re Pro­ble­me in Bezug auf das gedan­ken­lo­se Umset­zen von Din­gen, die irgend­wo mal funk­tio­niert haben, sehr gut beschrie­ben. Das Lesen lohnt sich.

Mich bewegt die Fra­ge: War­um ist das so? Sind wir Men­schen anfäl­lig für ein­fa­che Rezep­te? Ist es der Gedan­ke der Absi­che­rung: „Wir haben alles nach Best Prac­ti­ces gemacht und kön­nen uns nicht erklä­ren, war­um das trotz­dem schief gegan­gen ist“? Oder ist es Faul­heit? Zu viel zu tun und wir wäh­len die Abkür­zung? Oder kön­nen wir das wich­ti­ge nicht vom drin­gen­den unter­schei­den?

Ich per­sön­lich ten­die­re ja vor allem zur Vari­an­te 2: Absi­che­rung – was ist Dein Ein­druck?

Robert

Hal­lo Robert, vie­len Dank für Dei­nen Kom­men­tar und Dei­ne Aner­ken­nung! Ich habe das Gefühl, dass die Best-Prac­ti­ce-Gläu­big­keit sich direkt pro­por­tio­nal zur Kom­ple­xi­tät der Her­aus­for­de­run­gen ver­hält. In mei­ner Wahr­neh­mung leben wir in tur­bu­len­ten Zei­ten mit sehr kom­ple­xen Her­aus­for­de­run­gen und Pro­blem­stel­lun­gen. Der Mensch braucht Mus­ter, Ritua­le und Patent­re­zep­te damit er nicht über jeden Schritt nach­den­ken muss und das ist meis­tens auch gut so. Wenn nun so viel im Wan­del ist, dann macht das Angst, weil noch kei­ne adäqua­ten Ver­hal­tens­mus­ter bekannt sind. In die­ser Angst ist man anfäl­li­ger für Wun­der­hei­ler und Wun­der­mit­tel.

Letzt­lich ist der Grund mei­ner Mei­nung nach also Ver­un­si­che­rung und Angst gepaart mit einer gewis­sen Faul­heit des eige­nen Den­kens sowie einer Unter­neh­mens­kul­tur, die das Expe­ri­men­tie­ren durch einen nicht kon­struk­ti­ven Umgang mit Feh­lern effek­tiv ver­hin­dert.

Hal­lo zusam­men,

wahr­lich wich­ti­ge und rich­ti­ge Gedan­ken zum Mythos Best Prac­ti­ce.

Für mich per­sön­lich ist Best Prac­ti­ce das Ergeb­nis ver­zwei­fel­ter Tri­via­li­sie­rung. Die Begrün­dung dazu habe ich vor ein paar Jah­ren in der Zeit­schrift „SEM Radar“ als Arti­kel ver­fasst. Der Link zum Arti­kel ist hier.

http://blog-conny-dethloff.de/wp-content/uploads/2014/02/Best-Practice-ist-das-Ergebnis-verzweifelter-Trivialisierung.pdf

Aber Vor­sicht. Er ist ein biss­chen län­ger gewor­den.

Was man sich zusätz­lich immer wie­der vor Augen hal­ten soll­te, ist, dass Best Prac­ti­ce genau des­halb so heißt, weil Jemand vor mir dies schon ein­mal erfolg­reich ein­ge­setzt hat. Het­ze ich dem also hin­ter­her kann ich Den­je­ni­gen wohl bes­ten­falls adap­tie­ren. Aber wo bleibt da die Ein­zig­ar­tig­keit und Iden­ti­tät, die ich mir sel­ber zuschrei­be?

Bes­te Grü­ße,
Con­ny

Vie­len Dank für Dei­nen ergän­zen­den Kom­men­tar und den Hin­weis auf Dei­nen sehr aus­führ­li­chen Arti­kel, Con­ny! „Ver­zwei­fel­te Tri­via­li­sie­rung“, das war’s was ich in mei­ner Ant­wort an Robert aus­drü­cken woll­te ;-)

Ich habe mal ver­sucht das wei­ter zu hin­ter­fra­gen.

War­um glau­ben wir an Best- Prac­ti­ce – Weil wir uns absi­chern wol­len
War­um wol­len wir uns absi­chern – Weil die übli­che Unter­neh­mens­kul­tur das so erwar­tet
War­um ist die Unter­neh­mens­kul­tur so – Weil wir in zwei­wer­ti­ger Logik den­ken
War­um den­ken wir zwei­wer­tig – Weil die wirk­li­che Kom­ple­xi­tät nicht beherrsch­bar ist und andern­falls wir die­ses auch zuge­ben müss­ten.
War­um kön­ne wir es nicht zuge­ben – Weil das Zuge­ben einer sol­chen Unsi­cher­heit wie­der­um nicht in die übli­che Unter­neh­mens­kul­tur passt.
Wenn ich es rich­tig ver­stan­den habe ist das jetzt ein Zir­kel­schluss und in einer rei­nen Hier­ar­chie nicht auf­lös­bar.
Aber wie ver­mei­den wir jetzt den unre­flek­tier­ten Ein­satz von Best-Prac­ti­ce?
Ich den­ke, das kann nur in gegen­sei­ti­gem Ver­trau­en und bei einem Umgang auf Augen­hö­he funk­tio­nie­ren. Einer Ver­trau­ens­vol­len Umge­bung also, die das Zuge­ben von Unsi­cher­hei­ten mit bes­se­ren Lösun­gen belohnt und eben nicht bestraft. Was aus mei­ner Sicht Eigen­schaf­ten einer heterar­chi­schen Struk­tur sei­ne könn­ten.

Dan­ke für Dei­ne Aus­füh­run­gen, Peter. Der Schlüs­sel liegt für mich auch im rich­ti­gen Umgang mit Kom­ple­xi­tät bzw. eigent­lich schon im Ein­ge­ständ­nis, dass unse­re Pro­ble­me und Pro­jek­te kom­plex sind. Dem ent­ge­gen ste­hen die tra­dier­ten Unter­neh­mens­struk­tu­ren, die stark auf Plan­bar­keit basie­ren. Das passt tat­säch­lich nicht. Ver­trau­ens­vol­ler Umgang mit Feh­lern und das Akzep­tie­ren von Unsi­cher­heit ist daher mei­ner Mei­nung nach uner­läss­lich.

Huh,

der Arti­kel von Con­ny ist ein har­tes Stück zum Lesen. Lohnt sich aber. Und da „neue Lösun­gen erdenken weh tut“, gefällt mir beson­ders der letz­te Absatz ;-)

@Peter: Klap­pen die Schlüs­se wirk­lich so gut? Oder ist das ein ein­fa­ches Modell der Rea­li­tät – oder bin ich nur ein­fach nur naiv und glau­be an das Gute?

Wie kom­men wir zu einer ver­trau­ens­vol­len Umge­bung im Unter­neh­men? Ich mei­ne in einem bestehen­den.

Robert

Hal­lo Robert,
ja, das ist natür­lich nur ein ein­fa­ches Modell von dem wie es zusam­men­hän­gen könn­te. Jemand ande­res wird auch ganz ande­re Ant­wor­ten fin­den. Wis­sen kann ich es nicht. In dem Moment wo ich davon aus­ge­he es zu Wis­sen, ist es dann nicht so etwas wie wie mei­ne eige­ne Best- Prac­ti­ce?

Wenn wir mög­lichst vie­le ver­schie­de­ne sol­che Zusam­men­hän­ge (Model­le) neben­ein­an­der legen und dar­in nach ähn­li­chen Kon­tex­tu­ren und Zir­kel­schlüs­sen suchen, müss­ten doch Mus­ter erkenn­bar wer­den?
Es ist eine Ansatz, den ich für mich aus Con­nys Beschrei­bun­gen abge­lei­tet habe. Mal sehen wo es hin­führt.
Peter

Ich habe neu­lich auf dem Kon­gress der Best-Prac­ti­ce-User Group (frü­her PRINCE2-Ver­ein) einen Vor­trag über das Span­nungs­feld zwi­schen PRINCE2 und Agi­lem wie SCRUM gehal­ten. Von den Leu­ten da hat­ten nur weni­ge Pro­ble­me mit einer MTA. Ich glau­be kei­ner.
Wenn man aber eine machen will und die Ent­schei­dung ob ist schon gefal­len, dann ist m.E. die Best Prac­ti­ce immer eine gute Hil­fe­stel­lung, wie man sie macht.
Nennt man das Kind nicht Best Prac­ti­ce son­dern Stan­dard, dann wer­den noch ande­re Din­ge sicht­bar. Seit Jahr­zehn­ten höre ich immer wie­der, war­um man gera­de aktu­ell kei­nen Stan­dard nut­zen kön­ne. Bei­spiel: bei einer Migra­ti­on Main­frame zu Cli­ent-Ser­ver hat­ten wir uns für Unix-Maschi­nen geei­nigt, X‑Windows zu neh­men. Dann kam Apol­lo Domain, die hat­ten eine Tas­te für neue Fens­ter. Woll­te der Pro­gram­mie­rer unbe­dingt haben. Wir haben uns dann geei­nigt, kei­ne Her­stel­ler-Lockins zu ver­wen­den son­dern offe­ne Stan­dards. Mei­ne Erfah­rung ist, es kos­tet Kraft, Stan­dards erfolg­reich umzu­set­zen, wäh­rend dage­gen „Es ist alles eitel!“ leich­ter von den Lip­pen geht :-)
Bei der MTA ist dann doch die Fra­ge, wel­che Metho­de bes­ser ist, Pla­nung von Mile­stones näher an die Rea­li­tät zu brin­gen, wenn man das braucht und zwei­tens, war­um man das braucht, wenn einem Best Prac­ti­ces nicht hel­fen.
Ich nei­ge dazu, bei Ein­satz von bestimm­ten Metho­den mich immer auch an Best Prac­ti­ces zu ori­en­tie­ren statt bei allem das Rad neu zu erfin­den.
Aber das ist auch eine kul­tu­rel­le Fra­ge. Jemand, der alles selbst und neu bei jedem Pro­jekt erfin­det, braucht auch kei­ne Rei­fe­grad­mo­del­le. Ande­ren liegt aber manch­mal dar­an, Rei­fe zu erhö­hen, wenn Pro­jek­te dann doch oft gleich­ar­tig ver­lau­fen. Selbst die SCRUM-Leu­te ver­fol­gen Satndards, Zer­ti­fi­zie­run­gen, Best Prac­ti­ces in ihren Zere­mo­nien :-)
Schwie­rig wird es auch in Kun­den-Lie­fe­ran­ten-Bezie­hun­gen, wenn man kei­ne Best-Prac­ti­ces als Base­li­ning setzt und der Lie­fe­rant sagt, Ihr Pro­jekt ist so spe­zi­ell, so kom­plex: wir erfin­den alles neu und grei­fen nicht auf Bewähr­tes zurück.
Span­nen­der und rea­lis­ti­scher als BP zu bas­hen fän­de ich, Stan­dards zu ent­wi­ckeln, wann denn etwas als „Best“ defi­niert wer­den kann, um es nicht als Mar­ke­ting­hül­se ver­kom­men zu las­sen. Deth­l­offs Nega­tio­nen wären mir als Kun­de zu teu­er.

Dan­ke für Dei­nen aus­führ­li­chen Kom­men­tar, Wolf­gang. Ich habe auch gar nichts gegen Best Prac­ti­ce im Sin­ne eines Werk­zeug­kas­tens. Ich sehe einen gro­ßen Wert dar­in, dass die Metho­den sau­ber beschrie­ben sind und ich das Rad nicht neu erfin­den muss. Die Fra­ge, ob ich eine Metho­de ein­set­ze liegt aber immer noch bei mir als Pro­jekt­lei­ter. In dem Moment wo alle Pro­jek­te über einen Kamm gescho­ren wer­den und Werk­zeu­ge ver­pflich­tend wer­den wird es gefähr­lich. Und ja: auch und gera­de bei Scrum wird es hier gefähr­lich. Scrum ist viel mehr als das schein­bar ein­fach Koch­re­zept als das es oft dar­ge­stellt wird. Ohne die pas­sen­den Wer­te und die pas­sen­de Kul­tur geht das gran­di­os schief.

Ohne die pas­sen­den Wer­te und die pas­sen­de Kul­tur geht das gran­di­os schief.“

Ist das nicht gene­rell so?
Auch im klas­si­schen PM (immer noch ein däm­li­cher Begriff, aber las­sen wir das), also im Wesent­li­chen dem Anla­gen­bau, habe ich immer wie­der fest­ge­stellt, daß viel Zeit dar­auf ver­schwen­det wird, Schuld­zu­wei­sun­gen zu deflek­tie­ren und die Kehr­sei­te zur Wand zu brin­gen.
Das ging so weit, daß ich teil­wei­se 75% des pro­jekt­in­ter­nen Schrift­ver­kehrs direkt in den Ord­ner „Nicht mein Tisch“ ver­scho­ben habe, weil es da um nichts sach­dien­li­ches mehr ging, son­dern nur noch um teils hef­tig for­mu­lier­te Schuld­zu­wei­sun­gen und sinn­lo­se Recht­fer­ti­gun­gen.

Wer­te im Sin­ne von gegen­sei­ti­gem Ver­trau­en (zumin­dest ein gewis­ser Teil davon ist ein Vor­schuß und unter­neh­me­ri­sches Risi­ko) und Kul­tur im Sin­ne von offe­nem Umgang mit Feh­lern, Ver­säum­nis­sen und Risi­ken sind so oder so essen­ti­ell.

Mei­ne per­sön­li­che Mei­nung ist, daß unterm Strich gera­de die­se Aspek­te eine gro­ße Rol­le bei den pro­mi­nen­ten Kata­stro­phen­pro­jek­ten spie­len.

Vie­len Dank für die­sen Bei­trag, Mar­cus!

Für sich genom­men ist das The­ma „Best Prac­ti­ce“ schon eine Mar­ke für sich. Rich­tig span­nend wird das aber wie immer durch Bei­spie­le.

Eini­ge aus der IT hat­ten wir schon. Also gehen wir (mal wie­der) in den Anla­gen­bau:
Bei einer mir bekann­ten Fir­ma wur­de vor ein paar Jah­ren eine Pro­jekt­lei­ter­zer­ti­fi­zie­rung ein­ge­führt. Das ist ja an sich nichts Schlech­tes, zumal in die­ser Fir­ma (anders als in einer ande­ren) ent­spre­chend auf­wän­di­ge, dem PMP ent­lehn­te Schu­lun­gen und Pra­xis­übun­gen sowie ein Nach­weis über die in den ein­zel­nen Kom­pe­tenz­fel­dern erbrach­ten Tätig­kei­ten im Pro­gramm ent­hal­ten waren.
Nach ins­ge­samt knapp 14 Tagen Prä­senz­schu­lung, ein paar Tagen E‑Learning, und noch ein paar Tagen Doku­men­ta­ti­on des Lebens­lau­fes war man dann „Cer­ti­fied Pro­ject Mana­ger“.

Bis hier­hin alles in Ord­nung und sinn­voll.

Mein Pro­blem bei der Geschich­te war die Moti­va­ti­on:
Es ging nicht etwa dar­um, Pro­jekt­lei­ter zu schu­len, für Risi­ko­ma­nage­ment zu sen­si­bi­li­sie­ren, und unterm Strich die Pro­jek­te zu ver­bes­sern.
Viel­mehr ging es um eine For­de­rung der Kun­den: Die hat­ten näm­lich (um ihre Pro­jekt­ab­wick­lung zu ver­bes­sern und weni­ger Geld und Zeit zu ver­lie­ren) in ihre Las­ten­hef­te bzw. Anfra­gen geschrie­ben, daß die Pro­jekt­lei­ter der Lie­fe­ran­ten ihre Qua­li­fi­ka­ti­on im Pro­jekt­ma­nage­ment nach­wei­sen müs­sen, um die Pro­jek­te auch abwi­ckeln zu dür­fen.
Kein Nach­weis hieß: „Ange­bot abge­lehnt“.

Wie also Peter auch schon schrieb: „Weil wir uns absi­chern wol­len“
Also wir mer­ken uns: Ziel ist in die­sem Bei­spiel die Absi­che­rung gegen­über wem auch immer.

Wie wei­se ich also Qua­li­fi­ka­ti­on nach?
Naja, die „Best Prac­ti­ce“ ist ein Zer­ti­fi­kat. Egal, ob PRINCE2, PMI/PMP oder was auch immer – ein Zer­ti­fi­kat muß her.

Da man ja auch der ISO 9001 ver­pflich­tet ist, und zudem noch vom Vor­stand einen auf den Deckel bekom­men hat­te (sie­he oben: Ver­bes­se­rung der Abwick­lungs­qua­li­tät), wur­den also alle PMs durch die Bank ver­pflich­tet, egal ob sie an Pro­jek­ten, im Sys­tem­ge­schäft oder ganz wo anders arbei­te­ten.

Das Ziel, wei­ter anbie­ten zu dür­fen, hat man tat­säch­lich erreicht. Den Neben­ef­fekt der bes­se­ren Pro­jekt­ab­wick­lung lei­der nicht.
Macht aber nix. War ja nicht die Ziel­vor­ga­be.

Ich fin­de, das ist ein Klas­si­ker in der „Best-Prac­ti­ce-Hörig­keit“, wie man ihn kaum noch top­pen kann.
Neben­bei erschlägt das übri­gens auch gleich noch­mal das The­ma „Ziel­de­fi­ni­ti­on“:
Hät­te man durch alle Ebe­nen ver­stan­den, war­um die omi­nö­se For­de­rung nach der Qua­li­fi­ka­ti­on über­haupt erst auf­ge­kom­men ist, hät­te man aus dem gan­zen Pro­gramm einen rie­si­gen Bene­fit für alle Betei­lig­ten ern­ten kön­nen.

Übri­gens war der ent­hal­te­ne Ansatz zur glo­ba­len Ver­ein­heit­li­chung des Pro­jekt­ma­nage­ment gar nicht mal ver­kehrt, hät­ten sich alle dran gehal­ten.
Die­ser Ansatz war gut durch­dacht, und ent­hielt etli­ches an Werk­zeu­gen, die nach dem Mot­to „Müßt Ihr nicht, aber wenn, dann so“ bereit­ge­stellt wur­den.
Lei­der wur­de das aber nicht aus­rei­chend durch die Ziel­de­fi­ni­ti­on gestärkt, so daß die Umset­zung z.B. in Deutsch­land dort hän­gen blieb.

Schön (oder schreck­lich), dass es auch in ande­ren Bran­chen nicht anders geht. Was da an Zeit und Geld ver­senkt wird, ohne davon durch die Pro­jek­te Pro­fit zu machen. Das tut mir immer weh.

Im IT Bereich geschieht da regel­mä­ßig mit der ITIL Foun­da­ti­on Zer­ti­fi­zie­rung. Eine gesam­te IT-Abtei­lung muss da durch, ob es den AS/400 Admin inter­es­siert oder nicht. An ande­re Wege wird da gar nicht gedacht.

Dan­ke für die­ses Bei­spiel, Thi­lo! Aus dem Impuls der Auf­trag­ge­ber, näm­lich der ziem­lich nai­ven For­de­rung alle müs­sen zer­ti­fi­ziert sein, hät­te man mit der rich­ti­gen Moti­va­ti­on tat­säch­lich viel mehr her­aus­ho­len kön­nen. So war das bes­ten­falls halb­her­zig. Das Mus­ter ken­ne ich aber auch aus der IT … 

Ist halt ein Klas­si­ker. Aus einer fal­schen (oder zumin­dest unge­nau for­mu­lier­ten) Moti­va­ti­on her­aus das Rich­ti­ge anfan­gen und dann mit­ten­drin abbre­chen.

Da steckt übri­gens für mich ein Körn­chen „Agi­le“ drin:
Wenn ich mit­ten im Pro­zeß fest­stel­le, daß ich trotz der fal­schen Ursprungs­mo­ti­va­ti­on etwas Gutes errei­chen kann – was hin­dert mich dar­an, die Ziel­de­fi­ni­ti­on und die Regeln zu ändern und auf die rich­ti­ge Stra­ße abzu­bie­gen?
Selbst im Pha­se-Gate-Modell habe ich genug Punk­te, an denen ich die Zie­le hin­ter­fra­gen und jus­tie­ren kann.

Letzt­lich ist das aber immer eine Fra­ge der mensch­li­chen Varia­blen. Habe ich Vor­ge­setz­te und ein Team, die tat­säch­lich zusam­men an einem gemein­sa­men Ziel arbei­ten, kommt so eine Ver­fei­ne­rung bzw. Ver­bes­se­rung eher vor, als in klas­sisch hier­ar­chi­schen Struk­tu­ren, wo alle machen, was der Chef sagt (oder zumin­dest das, was sie davon ver­ste­hen) und nie­mand einen Ein­spruch wagt.

Und hier noch was für die Freun­de von best prac­ti­ces:
Best Prac­ti­ces im agi­len Soft­ware Tes­ting
„Embra­cing Dis­rup­ti­ve Tes­ting“
http://tyro.com/embracing-disruptive-testing/

My aver­si­on to the con­cept of best prac­ti­ce has grown over the years as in rea­li­ty it fails mise­r­a­b­ly.“

Der Video­clip plus Foli­en unten auf der Sei­te ist auch zu emp­feh­len:
„Dis­rup­ti­ve Tes­ting: The Hunt for Black Swans“
Best Prac­ti­ces für alles was das moder­ne Herz begehrt, inklu­si­ve der Jagd nach den Schwar­zen Schwä­nen :-)
http://www.infoq.com/presentations/embrace-disruption-testing

Wir dür­fen gespannt sein, wann es zer­ti­fi­zier­te Schu­lun­gen für die best prac­ti­ces des dis­rup­ti­ve tes­ting gibt. Die moder­nen buz­z­words sind alle da: Kom­ple­xi­tät, nicht pla­nen, Auto­no­my, Col­la­bo­ra­ti­on, Con­tin­ous Self Lear­ning, Empower­ment.
:-)

Dan­ke für all die sehr ein­mü­ti­gen Kom­men­ta­re, die letzt­lich auf den Punkt gebracht bedeu­ten: Best Prac­ti­ce ent­he­ben den Pro­jekt­lei­ter nicht von der Ver­ant­wor­tung das Pro­jekt selbst zu gestal­ten. Es ist noch kein Pro­jekt erfolg­reich gewor­den, nur weil es mit Best Prac­ti­ces durch­ge­führt wur­de !

Das bedeu­tet im Umkehr­schluss für alle, die (weil nie gelernt) von Best Prac­ti­ces wenig Ahnung haben und die selbst­ver­ant­wort­li­che Füh­rung ihrer Pro­jek­te scheu­en: Lass die Fin­ger vom Pro­jekt­ma­nage­ment und nen­ne (bzw. ver­kau­fe) Dich bit­te auch nicht (als) Pro­jekt­ma­na­ger !

Schreibe einen Kommentar