Die Gartner Group fordert den verstärkten Einsatz von PMOs (Project Management Offices) zur besseren strategischen Ausrichtung der IT in Unternehmen (siehe CIO Magazine).

Der Begriff PMO wird häufig sehr unterschiedlich gebraucht: Vom einfachen Sekratariat bis hin zum strategischen Portfoliomanagement kann sich alles hinter dem Begriff PMO verbergen.

Nachdem ich schon in unterschiedlichsten Rollen in PMOs mitgewirkt habe, kann ich die Aussage von Gartner unterstreichen, allerdings gilt es auch hier Bodenhaftung zu bewahren. Portfolio-Management ist kein Selbstzweck und muss sowohl dem strategischen Auftrag als auch den einzelnen Projekten gerecht werden. PMO´s, die das vergessen, stellen bürokratische Anforderungen und blockieren die Projektarbeit.

Wer noch immer Zweifel über die wahre Bedeutung von Social Networking á la XING & Co hatte, wird endlich eines besseren belehrt:

Soziale Netzwerke wichtiger als Porno

Bill Tancer hat das Klick-Verhalten im Internet untersucht und dabei festgestellt, dass in jüngster Zeit verstärkt soziale Netzwerke angeklickt werden. Der Trend bei Seiten mit pornografischen Inhalten ist aber rückläufig, so berichtet es zumindest Spiegel online.

Mein XING-Profil finden Sie übrigens hier.

Die Computerwoche schreibt über IT-Marketing. Die Aussagen lassen sich allerdings problemlos verallgemeinern auf Projektmarketing. Auch Projekte wollen „vermarktet“ werden.

Stefan Hagen widmet sich ausführlich dem Berufsbild Projektmanager.

So schlüssig die Argumente auch sein mögen, mein Eindruck ist nach wie vor, dass es die „Projektkarriere“ zumindest in Deutschland eigentlich nicht gibt. Karriere macht man nach wie vor in der Linie. Wer sich in Projekten bewährt, steigt auf und verlässt die Welt der Projekte. Wer erfahrene und gute Projektmanager sucht, bedient sich lieber extern – ohne Karrierespielchen, denn wer gut ist, wechselt zurück in die Linie.

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.