Das bedeutet im Umkehrschluss für alle, die (weil nie gelernt) von Best Practices wenig Ahnung haben und die selbstverantwortliche Führung ihrer Projekte scheuen: Lass die Finger vom Projektmanagement und nenne (bzw. verkaufe) Dich bitte auch nicht (als) Projektmanager !

Da hast Du recht, Thilo. Das ist generell so. Wenn es irgendwann im Projekt oder Unternehmen nur noch um Cover-your-ass geht, dann läuft etwas ziemlich schief. Oft ist es aber wirklich so wie Du schreibst. Leider.

„My aversion to the concept of best practice has grown over the years as in reality it fails miserably.“

Der Videoclip plus Folien unten auf der Seite ist auch zu empfehlen:
„Disruptive Testing: The Hunt for Black Swans“
Best Practices für alles was das moderne Herz begehrt, inklusive der Jagd nach den Schwarzen Schwänen :-)
http://www.infoq.com/presentations/embrace-disruption-testing

Wir dürfen gespannt sein, wann es zertifizierte Schulungen für die best practices des disruptive testing gibt. Die modernen buzzwords sind alle da: Komplexität, nicht planen, Autonomy, Collaboration, Continous Self Learning, Empowerment.
:-)

Ist halt ein Klassiker. Aus einer falschen (oder zumindest ungenau formulierten) Motivation heraus das Richtige anfangen und dann mittendrin abbrechen.

Da steckt übrigens für mich ein Körnchen „Agile“ drin:
Wenn ich mitten im Prozeß feststelle, daß ich trotz der falschen Ursprungsmotivation etwas Gutes erreichen kann – was hindert mich daran, die Zieldefinition und die Regeln zu ändern und auf die richtige Straße abzubiegen?
Selbst im Phase-Gate-Modell habe ich genug Punkte, an denen ich die Ziele hinterfragen und justieren kann.

Letztlich ist das aber immer eine Frage der menschlichen Variablen. Habe ich Vorgesetzte und ein Team, die tatsächlich zusammen an einem gemeinsamen Ziel arbeiten, kommt so eine Verfeinerung bzw. Verbesserung eher vor, als in klassisch hierarchischen Strukturen, wo alle machen, was der Chef sagt (oder zumindest das, was sie davon verstehen) und niemand einen Einspruch wagt.

„Ohne die passenden Werte und die passende Kultur geht das grandios schief.“

Ist das nicht generell so?
Auch im klassischen PM (immer noch ein dämlicher Begriff, aber lassen wir das), also im Wesentlichen dem Anlagenbau, habe ich immer wieder festgestellt, daß viel Zeit darauf verschwendet wird, Schuldzuweisungen zu deflektieren und die Kehrseite zur Wand zu bringen.
Das ging so weit, daß ich teilweise 75% des projektinternen Schriftverkehrs direkt in den Ordner „Nicht mein Tisch“ verschoben habe, weil es da um nichts sachdienliches mehr ging, sondern nur noch um teils heftig formulierte Schuldzuweisungen und sinnlose Rechtfertigungen.

Werte im Sinne von gegenseitigem Vertrauen (zumindest ein gewisser Teil davon ist ein Vorschuß und unternehmerisches Risiko) und Kultur im Sinne von offenem Umgang mit Fehlern, Versäumnissen und Risiken sind so oder so essentiell.

Meine persönliche Meinung ist, daß unterm Strich gerade diese Aspekte eine große Rolle bei den prominenten Katastrophenprojekten spielen.

Danke für dieses Beispiel, Thilo! Aus dem Impuls der Auftraggeber, nämlich der ziemlich naiven Forderung alle müssen zertifiziert sein, hätte man mit der richtigen Motivation tatsächlich viel mehr herausholen können. So war das bestenfalls halbherzig. Das Muster kenne ich aber auch aus der IT … 

Schön (oder schrecklich), dass es auch in anderen Branchen nicht anders geht. Was da an Zeit und Geld versenkt wird, ohne davon durch die Projekte Profit zu machen. Das tut mir immer weh.

Im IT Bereich geschieht da regelmäßig mit der ITIL Foundation Zertifizierung. Eine gesamte IT-Abteilung muss da durch, ob es den AS/400 Admin interessiert oder nicht. An andere Wege wird da gar nicht gedacht.

Hallo Peter,

guter Ansatz! Wir sind da zumindest schon weitgehend deckungsgleich!

Robert

Für sich genommen ist das Thema „Best Practice“ schon eine Marke für sich. Richtig spannend wird das aber wie immer durch Beispiele.

Einige aus der IT hatten wir schon. Also gehen wir (mal wieder) in den Anlagenbau:
Bei einer mir bekannten Firma wurde vor ein paar Jahren eine Projektleiterzertifizierung eingeführt. Das ist ja an sich nichts Schlechtes, zumal in dieser Firma (anders als in einer anderen) entsprechend aufwändige, dem PMP entlehnte Schulungen und Praxisübungen sowie ein Nachweis über die in den einzelnen Kompetenzfeldern erbrachten Tätigkeiten im Programm enthalten waren.
Nach insgesamt knapp 14 Tagen Präsenzschulung, ein paar Tagen E‑Learning, und noch ein paar Tagen Dokumentation des Lebenslaufes war man dann „Certified Project Manager“.

Bis hierhin alles in Ordnung und sinnvoll.

Mein Problem bei der Geschichte war die Motivation:
Es ging nicht etwa darum, Projektleiter zu schulen, für Risikomanagement zu sensibilisieren, und unterm Strich die Projekte zu verbessern.
Vielmehr ging es um eine Forderung der Kunden: Die hatten nämlich (um ihre Projektabwicklung zu verbessern und weniger Geld und Zeit zu verlieren) in ihre Lastenhefte bzw. Anfragen geschrieben, daß die Projektleiter der Lieferanten ihre Qualifikation im Projektmanagement nachweisen müssen, um die Projekte auch abwickeln zu dürfen.
Kein Nachweis hieß: „Angebot abgelehnt“.

Wie also Peter auch schon schrieb: „Weil wir uns absichern wollen“
Also wir merken uns: Ziel ist in diesem Beispiel die Absicherung gegenüber wem auch immer.

Wie weise ich also Qualifikation nach?
Naja, die „Best Practice“ ist ein Zertifikat. Egal, ob PRINCE2, PMI/PMP oder was auch immer – ein Zertifikat muß her.

Da man ja auch der ISO 9001 verpflichtet ist, und zudem noch vom Vorstand einen auf den Deckel bekommen hatte (siehe oben: Verbesserung der Abwicklungsqualität), wurden also alle PMs durch die Bank verpflichtet, egal ob sie an Projekten, im Systemgeschäft oder ganz wo anders arbeiteten.

Das Ziel, weiter anbieten zu dürfen, hat man tatsächlich erreicht. Den Nebeneffekt der besseren Projektabwicklung leider nicht.
Macht aber nix. War ja nicht die Zielvorgabe.

Ich finde, das ist ein Klassiker in der „Best-Practice-Hörigkeit“, wie man ihn kaum noch toppen kann.
Nebenbei erschlägt das übrigens auch gleich nochmal das Thema „Zieldefinition“:
Hätte man durch alle Ebenen verstanden, warum die ominöse Forderung nach der Qualifikation überhaupt erst aufgekommen ist, hätte man aus dem ganzen Programm einen riesigen Benefit für alle Beteiligten ernten können.

Übrigens war der enthaltene Ansatz zur globalen Vereinheitlichung des Projektmanagement gar nicht mal verkehrt, hätten sich alle dran gehalten.
Dieser Ansatz war gut durchdacht, und enthielt etliches an Werkzeugen, die nach dem Motto „Müßt Ihr nicht, aber wenn, dann so“ bereitgestellt wurden.
Leider wurde das aber nicht ausreichend durch die Zieldefinition gestärkt, so daß die Umsetzung z.B. in Deutschland dort hängen blieb.

Danke für Deinen ausführlichen Kommentar, Wolfgang. Ich habe auch gar nichts gegen Best Practice im Sinne eines Werkzeugkastens. Ich sehe einen großen Wert darin, dass die Methoden sauber beschrieben sind und ich das Rad nicht neu erfinden muss. Die Frage, ob ich eine Methode einsetze liegt aber immer noch bei mir als Projektleiter. In dem Moment wo alle Projekte über einen Kamm geschoren werden und Werkzeuge verpflichtend werden wird es gefährlich. Und ja: auch und gerade bei Scrum wird es hier gefährlich. Scrum ist viel mehr als das scheinbar einfach Kochrezept als das es oft dargestellt wird. Ohne die passenden Werte und die passende Kultur geht das grandios schief.