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

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

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­len­stein­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­len­stein­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 Releases 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 sinnfrei.

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

Über­ar­bei­te­te Mana­ger beschäf­ti­gen sich mit Din­gen, mit denen sie sich nicht beschäf­ti­gen sollten.
Tom de Marco

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

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

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

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.

19 Kommentare

Hal­lo Marcus,

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 aufgeschrieben.
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 unterscheiden?

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

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

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

Hal­lo zusammen,

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

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

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 zuschreibe?

Bes­te Grüße,
Conny

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 wollte ;-)

Ich habe mal ver­sucht das wei­ter zu hinterfragen.

War­um glau­ben wir an Best- Prac­ti­ce – Weil wir uns absi­chern wollen
War­um wol­len wir uns absi­chern – Weil die übli­che Unter­neh­mens­kul­tur das so erwartet
War­um ist die Unter­neh­mens­kul­tur so – Weil wir in zwei­wer­ti­ger Logik denken
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üssten.
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 auflösbar.
Aber wie ver­mei­den wir jetzt den unre­flek­tier­ten Ein­satz von Best-Practice?
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 hete­r­ar­chi­schen Struk­tur sei­ne könnten.

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 unerlässlich.

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

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- Practice?

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 werden?
Es ist eine Ansatz, den ich für mich aus Con­nys Beschrei­bun­gen abge­lei­tet habe. Mal sehen wo es hinführt.
Peter

Ich habe neu­lich auf dem Kon­gress der Best-Prac­ti­ce-User Group (frü­her PRIN­CE2-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 keiner.
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-Lock­ins 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­sto­nes 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 helfen.
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 erfinden.
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 Zeremonien :-)
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­lining 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 bashen 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. Dethl­offs Nega­tio­nen wären mir als Kun­de zu teuer.

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 bringen.
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 Rechtfertigungen.

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

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

Da hast Du recht, Thi­lo. Das ist gene­rell so. Wenn es irgend­wann im Pro­jekt oder Unter­neh­men nur noch um Cover-your-ass geht, dann läuft etwas ziem­lich schief. Oft ist es aber wirk­lich so wie Du schreibst. Leider.

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

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

Eini­ge aus der IT hat­ten wir schon. Also gehen wir (mal wie­der) in den Anlagenbau:
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 Manager“.

Bis hier­hin alles in Ord­nung und sinnvoll.

Mein Pro­blem bei der Geschich­te war die Motivation:
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 verbessern.
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ürfen.
Kein Nach­weis hieß: „Ange­bot abgelehnt“.

Wie also Peter auch schon schrieb: „Weil wir uns absi­chern wollen“
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 arbeiteten.

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

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

Ü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 gehalten.
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 wurden.
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 abbrechen.

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 abzubiegen?
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 practices:
Best Prac­ti­ces im agi­len Soft­ware Testing
„Embra­cing Dis­rup­ti­ve Testing“
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 miserably.“

Der Video­clip plus Foli­en unten auf der Sei­te ist auch zu empfehlen:
„Dis­rup­ti­ve Test­ing: 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 test­ing gibt. Die moder­nen buz­zwords sind alle da: Kom­ple­xi­tät, nicht pla­nen, Auto­no­my, Col­la­bo­ra­ti­on, Con­ti­nous Self Lear­ning, Empowerment.
:-)

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 wurde !

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) Projektmanager !

Schreibe einen Kommentar