Es gibt eine neue PM-Disziplin:

Project Blame Management.

oder hier:

Ausgegraben im PMPodcast via PJBM.

Mein Favorit: Blamestorming. Ein Spiel, das sich um die zwei essentiellen Fragen dreht: Was könnte schief gehen und wem können wir das in die Schuhe schieben.

Planungspoker ist ein „Spiel“, das mir erstmalig in der Auseinandersetzung mit agiler Softwareentwicklung über den Weg gelaufen ist. Um zu möglichst unvoreingeommenen Aufwandsschätzungen zu gelangen wird ein Spiel unter Experten initiiert. Jeder muss spontan mittels Pokerkarten den mir einem Funktionsbaustein/einer Use story verbundenen Aufwand schätzen. Alle Experten legen ihre Schätzung gleichzeitig auf den Tisch, damit sie sich nicht gegenseitig beeinflussen können.

Wie Aufwandsschätzungen mit und ohne Planungspoker ablaufen können beschreibt der agile Software-Blog

Christian Henner-Fehr versucht sich in einer Annäherung an den Begriff „Strategie“:

Was verstehen wir eigentlich unter Strategie?

Er zititiert Klaus Backhaus und Helmut Schneider, die allerdings mit ihren Belegen (zumindest mit den zitierten Belegen) in den 80gern stehen bleiben. Dennoch ist der Beitrag von Christian Henner-Fehr lesenswert.

Der agile software-Blog hat einige Aussagen von Steve Ballmer zum Thema agile Softwareentwicklung/Agilität bei Microsoft ausgegraben:

„…. [What we] are working hardest on now is agility. What does it mean to be agile in the marketplace? Agility means that you are able to turn things around, that you can invent new things and yet you can still do things that require scale, discipline and execution.“

Er verweist insbesondere auf die Herausforderung des Changemanagement einen Konzern wie Microsoft agiler werden zu lassen.

Kevin Rutherford philosophiert in seinem Blog silk and spinach darüber, wie sich Programmierer auf „ihre“ Tester verlassen und ihnen die gesamte Qualitätssicherung überlassen, wenn sie um die Qualität des Testteams wissen. Dies kann dazu führen, dass – überspitzt gesagt – ein gutes Testteam dazu führt, dass die Qualität des Quellcodes nachlässt.

Hört sich zunächst abstrus an, aber kennen wir nicht alle Fälle von Nachlässigkeiten, wenn z.B. die Entwickler vergessen die Berechtigungen mitzutesten, weil sie mit ihren eigenen Berechtigungen eh alles können oder dass sie mal schnell den einen oder anderen Transport übersehen. Je mehr man sich auf andere verlassen kann, umso mehr schleichen sich auch solche Nachlässigkeiten ein. Liegt wohl in der menschlichen Natur. Ein schlechtes Testteam oder gar der Verzicht auf Tests stellen keine wirkliche Alternative dar.

Die Computerwoche berichtet, wie sich in New Orleans Unternehmen auf den Hurrikan ‚Gustav‘ vorbereitet haben und wie aus den Erfahrungen von ‚Katarina‘ und ‚Rita‘ gelernt wurde. Der Schwerpunkt liegt mal wieder bei der phyisischen Datensicherung. In einem Fall wird berichtet:

Im Notfall nimmt der letzte Mitarbeiter das mobile Gerät samt einer „Notfall“-Box mit zusätzlichen Backups auf DVD mit, um alle Daten zu retten.

So lobenswert die Ansätze im Einzelnen auch sein mögen, sie täuschen mal wieder über einen wesentlichen Aspekt hinweg: Naturkatastrophen sind nur ein sehr kleiner Teil, um den es beim Thema Business Continuity gehen sollte. Die weit größere Gefahr ist wie immer der Mensch, sei es durch Missbrauch oder durch Nachlässigkeit.

Ein paar Psychologie-Links:

PsychSpider – eine deutschsprachige Suchmaschine für Psychologie vom Zentrum für Psychologische Information und Dokumentation des Leibniz-Instituts der Universität Trier.

lexikon-psychologie.de ist ein online-Lexikon mit dem Anspruch, die grundlgenden Begriffe der Psychologie zu erläutern.

Wahrscheinlich wird man mich jetzt lynchen, wenn ich einen NLP-Link unter der Überschrift Psychologie poste – ich tue es trotzdem: Die NLPedia ist ein vielversprechendes Wiki rund um die Neurolinguistische Programmierung.