Über den Einsatz sozialer Medien (Wikis, Twitter & Co) wurde hier schon fleissig berichtet und diskutiert. Ein Beispiel für die Qualitätsmängel findet sich gerade bei XING (Abo-Dienst). Anläßlich der Bundesatgswahl gibt es dort eine Wahlbarometer samt Online-Umfrage. Wenn am nächsten Sonntag Wahl wäre, dann käme CDU/CSU aktuell z.B. auf 3,14% der Stimmen (nein, das Komma ist nicht verrutscht). Großer Sieger würde die Piratenpartei mit 75,8% der Stimmen!

Quelle: XING

Bei aller Sympathie für die Piraten, fürchte ich, dass uns dieses Beispiel nur zeigt, auf welch wackeligen Füßen soziale Medien mitunter stehen und wie sehr sie von den partizipierenden Teilnehmern abhängen. Im politischen Umfeld mag so etwas aufgrund der Emotionalität noch verstärkt sein, aber tendenziell fürchte ich, müssen wir auch im Business-Einsatz solcher Medien mit diesen Effekten leben.

Um Missverständnissen vorzubeugen: Den Versuch von XING eine Plattform für die politische Diskussion bereitzustellen finde ich durchaus begrüßenswert! Beim kritischen Umgang mit den Inhalten ist nur wieder jeder einzelne gefordert.

Lessons Learned, Projektretrospektiven werden häufig zitiert, gelegentlich sogar umgesetzt (in agilen Projekten angeblich sogar regelmäßig), miunter werden sie pro forma abgewickelt und gelernt wird doch noch zu wenig.

Ron Rosenhead berichtet über den Psychologen Peter Honey (Original in Englisch), der darüber philosophiert, ob wir unsere Lektionen jemals wirklich lernen und darauf hinweist, wie wichtig es ist auch zu artikulieren, was wir gelernt haben. Angesicht der im Projektalltag oft traurigen Praxis (siehe Einleitung) fordert Rosehead dazu zu auf :

to build into projects a much stronger process to capture and share learning. […] No learning and the same mistakes will be made…… over and over again?

Passend zum Thema Lessons Learned hat Stefan Hagen das Agile Retrospective Resource Wiki ausgegraben. Das Wiki scheint noch im Aufbau, verspricht aber ein interessanter Methodenbaukasten zu werden.

Die Zusammenfassung meiner beiden Beiträge für das Projektmagazin von Anfang des Jahres gibt es jetzt als Präsentation:

Oder im Original beim Projektmagazin (Abodienst):
Teil 1: Ablauf und Organisation
Teil 2: Das Excel-Toolset

Es klingt fast nach Slapstick oder Comedy, was Sven Rimbach zu berichten weiss. Er hat uns einen Dialog  über abnahmerelevante Fehler gebloggt. Komik und Tragik liegen nahe beieinander. Leider kann ich mir nur zu gut vorstellen, dass dieser Dialog so auch stattgefunden hat. Da werden die Testergebnisse und ggf. auch die Abnahmekriterien und Fehlerklassen solange umgedeutet, bis das herauskommt, was man eh wollte. Süffisant möchte man da anmerken: Wozu noch testen…

Felix Rüssel von armerkater.de fasst einen Beitrag auf PMhut (Teil1, Teil2) über das Scheitern von Projekten zusammen, der 11 Symptome für das Scheitern von Projekten aufzählt.

Ja, selbstverständlich sind die üblichen Verdächtigen darunter und Felix schreibt:

Es ist für mich immer wieder erstaunlich wie sich bekannte Probleme immer wieder wiederholen.

So richtig solche Aufzählungen sein mögen, ich mag sie trotzdem nicht, weil die Symptome von den grundlegenden Krankeiten fehlende Projektkultur und mangelhafte Kommunikation ablenken. Zum Beispiel an einem Risikomanagement kann ich beliebig rumdoktern und mir ein Risikoinventar und Risk Assessments um die Ohren schlagen, wenn die Einstellung dahinter nicht stimmt, bleibt die Veranstaltung relativ sinnlos, dann geht es nur mehr um reine Absicherung und Schuldzuweisung, was noch kein Projekt zum Erfolg geführt hat.

Persönlich stehe ich mit Zertifizierungen (nicht nur im PM) auf dem Kriegsfuss. Die meisten Zertifizierungen driften ins formale ab und vernachläsigen die Praxis. Darüber hinaus hat man das Gefühl, dass weniger das hehre Wissen als das Geschäft mit der Zertifizierung und dann das Folgegeschäft mit der Rezertifizierung, usw. im Vordergrund steht. Ich bin durchaus ein Freund des lebenslangen Lernens, aber das hat mit Zertifizierungen wenig zu tun (zumindest habe ich ein solches Zertifikat noch nicht gefunden).

Bernd Oestereich zusammen mit Prof. Dr. Michael Gessler (GPM/IPMA) und Oliver F. Lehmann (PMI) setzen sich aktuell in einem Beitrag für ObjektSpektrum mit den PM-Zertifikaten auseinander. Die Kollegen sehen durchaus auch die Vorbehalte gegen die Zertifizierungen und führen sie in ihrem Artikel auch mit auf. Schwerpunktmäßig setzen sie sich mit den Zertifizierungen nach PMI und GPM/IPMA auseinander. Weitere Zertifizierungen und Standards werden zumindest kurz erwähnt. Beispielsweise PRINCE2 (dem britischen Standard), der vor allem daher im Kommen ist, da die OGC als Herausgeber auch den ITIL-Standard für das IT-Servicemanagement entwickelt hat und man vermehrt im IT-Umfeld deshalb immer wieder über PRINCE2 stolpert.

Wie sich die Inhalte der Standards, die sich hinter den Zertifizierungen verbergen, unterscheiden, hat bereits vor einer Weile Andreas Heilwagen zusammengefasst. Von ihm gibt es ganz aktuell auch Tipps für eine erfolgreiche PMP-Zertifizierung (PMI) als Podcast.

Nachtrag 22.05.2009: Und nochmal Andreas Heilwagen, der auf PMHut eine Lernhilfe für die PMP-Zertifizierung ausgegraben hat.

Im Beitrag #162 PM und Wissenschaft wurde bereits die Theorie sozialer Systeme von Luhmann angesprochen. Auf zwei sehr zentrale Facetten dieser Theorie möchte ich für das Projektmanagement hier gerne noch eingehen:

(1) Selbstorganisation/autopoietische Systeme

Projektorganisationen entwickeln oft eine Eigendynamik. Projekte organisieren sich selbst. Manchmal konstituieren Projekte sogar sich selbst. Auch ohne Projektauftrag entwicklen sich mitunter informelle Strukturen, die man dann als Projekt bezeichnen könnte. Mit der Theorie autopoietischer Systeme haben wir hierfür einen Erklärungsansatz. Für das Projektmanagement liegt die Kunst darin, solche Tendenzen zur Selbstorganiation zu nutzen. Bei einem komplexen Projektgegenstand ist eine vollständige durchdringende Planung nie möglich, aber wenn wir Selbstorganisation zulassen und in gewisse Bahnen leiten ( – ein gewisses Maß an Planung braucht es also doch), so ist dies durchaus zielführend.

(2) Beobachtung und Selbstbeobachtung

Ein soziales System kann sich selbst beobachten und über sich selbst reflektieren. Freilich in gewissen Grenzen bedingt durch die Selbstbezüglichkeit und Subjektivität. Es gibt neben der Beobachtung der Umwelt auch die Beobachtung zweiten Grades (die Beobachtung des Beobachters). Auch hier gibt es wieser selbstbezügliche Grenzen. Übertragen auf Projekte sind wir plötzlich mitten in der Stakeholder Analyse, der Umweltanalyse, im Projektmarketing, im Lessons Learned, im Review, im Qualitätsmanagement oder in der Projektretrospektive.

Hier nur kurz angerissen, zeigen sich bereits vielversprechende wechselseitige Einflüsse und Interpretationen.

Bereits vor einer Weile wurde an dieser Stelle über ein neues PM-Portal von Computerwoche und CIO-Magazin hingewiesen: 10projects.

Die Idee, dort Projektsteckbriefe zu hinterlegen, Projekterfolg und Dienstleister standardisiert zu bewerten und fachliche Diskussionsforen zu schaffen, klingt zunächst vielversprechend, aber bereits damals stimmte mich die überschwengliche Bewertung der hinterlegte Projekte eher skeptisch. Hier wird eher der Eitelkeit von Projektleitern gehuldigt als der Objektivität in der Sache.

Aber man soll ja nicht vorschnell urteilen. Also Zeit noch einmal auf 10projects zurückzukehren. Hat sich mittlerweile alles zum Guten gewandelt?

Leider nein. Die Projektsteckbriefe sind noch immer Werbetexte. Die Bewertungen stammen i.d.R. von einem einzigen Projektmitarbeiter und sind bis auf eine einzige Ausnahme, die ich finden konnte, immer weitgehend positiv. In den Diskussionsforen  ist auch nicht gerade die Hölle los. Bei einem schnellen Scan war der jüngste Beitrag, den ich finden konnte von Anfang März, der Rest aus dem letzten Jahr.

Schade, aber 10projects kann man aufgrund mangelnder Akzeptanz wohl abhaken.

Heute erschienen in der neuen Ausgabe des Projektmagazins ist Teil 2 meines Artikels über Testmanagement in IT-Projekten. Während es in Teil 1 noch um die Grundlagen ging, beinhaltet Teil 2 vor allem eine Excel-Vorlage. Kommerzielle Test-Suiten sind als Test-Werkzeug häufig überdimensioniert, da ihr Leistungsumfang die Anforderungen vieler IT-Projekte übersteigt und ihre Nutzung meist nur rudimentär erfolgt. Die vorgestellte einfache Excel-Lösung kann der Anwender leicht an seine spezifischen Fragestellungen anpassen und weiterentwickeln.

Janusz Gorycki setzt sich bei AgileSoftwareDevelopment.com (Englisch) mit den Tücken und Fallstricken des Unit Tests auseinander:

(1)  Unit Test dienen nicht zur Systemdokumentation!
(2) Ein erfolgreicher Unittest sagt nichts darüber, ob das Gesamtsystem auch „gesund“ ist.
(3) Testmodellen zu vertrauen ist falsch.
(4) Zu langsame Unit-Tests sind wertlos.