Im Editorial der aktuellen Ausgabe von Projektmanagement aktuell, nimmt Heinz Schelle in bemerkenswerterweise Stellung zur projektbezogenen Einsatzmittelplanung:

„… Wie auf dem Gebiet der projektbezogenen Einsatzmittelplanung, wo man sich leider wieder auf  ‚dumme‘ Algorithmen besinnt, statt einzusehen, dass die auf Vorgängen und Arbeitspaketen basierende Planung ein Irrweg war, feiert Operations Research, meiner Meinung nach im Projektmanagement längst glorreich gescheitert, fröhliche Auferstehung. Geboten wird nicht, was das Projektmanagement braucht (Nachfrageorientierung), sondern was die Mathematik hergibt (Angebotsorientierung).“

Andreas Heilwagen greift die Diskussion von Meilensteinen und Stage Gates von Glen Alleman auf, der stattdessen für die Verwendung von klar definierten Metriken für die Fertigstellung plädiert. Unter Hinweis auf den häufig vertraglichen Charakter von Meilensteinen und Stage Gates plädiert Andreas Heilwagen für die Nutzung solcher Metriken im Rahmen von Meilenstein- und Stage Gate-Konzepten.

Theoretisch kann ich dem voll und ganz zustimmen. Praktisch sieht es aber leider etwas anders aus, denn eigentlich erfordert das Reissen eines Meilensteins oder das Verpassen eines Stage Gates klare Konsequenzen, die im Projektalltag so häufig gar nicht gewünscht sind – von allen Beteiligten!! Wenn eine Testphase nur zu 80% abgeschlossen ist, der gewünschte GoLive-Termin aber verschoben werden müsste, werden sich i.d.R. Auftraggeber und Projektteam tief in die Augen schauen und eine Risikoabwägung vornehmen, die so in keinem Projektplan vorgesehen war. Es ist illusorisch anzunehmen, dass alle Unabwägbarkeiten eines Projekts in den vertraglichen Beziehungen eindeutig vorab geklärt werden können. Voraussetzung, dass solche AdHoc-Anpassungen nicht ein reines Hasardeurspiel werden, ist ein höchstes Mass an Transparenz und Vertrauen zwischen den Beteiligten. Vertragliche Regelungen und theoretische Konzepte können wieder einmal keine Projektkultur ersetzen, sondern setzen diese voraus.

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.

Übersetzungsprobleme sind zugegebenermaßen ein Lieblingsthema von mir. Aktuell wieder zu finden in einem Interview im CIO-Magazin mit Klaus Rausch (Ex-HypoVereinsbank-CIO, heute CTO beim Schweizer Dienstleister Avaloq) mit dem passenden Titel:

Wenn Anwender der IT das Programmieren erklären

Siehe auch:
#144 Übersetzungsprobleme: IT und Business
#131 IT versteht Business nicht

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.

Passend zum Thema Kommunikation in Projekten hat auch Stefan Hagen einen interessanten Artikel von Ulrike Wikner auf perspektive-mittelstand.de ausgegraben. Sie befasst sich mit der Moderation und Vorbereitung von Meetings im Projekt. Kommunikation ist selbstverständlich noch viel mehr als das, was in Projektmeetings passiert, aber ein bisschen Disziplin hilft hier schon ein gutes Stück weiter und über die Bedeutung von Kommunikation habe ich mich bereits im letzten Beitrag ausgelassen.

Przemysław Bielicki berichtet auf AgilSoftwareDevelopment.com über den Einsatz agiler Methoden in einer vom Wasserfallmodell geprägten Umgebung und insbesondere wie direkte Kommunikation zum Rettungsanker für ein bereits halb-totes Projekt wurde (Englisch).

Agil hin oder her – unabhängig von der Diskussion über agile Vorgehensweisen unterstreicht das Beispiel vor allem eines: Die Bedeutung von Kommunikation in der Projektarbeit.

Meine These: Stimmt die Kommunikation in einem Projekt, dann ist die Vorgehensweise „fast schon egal“…

Nachtrag (22.05.09): Hier die Fortsetzung des Kollegen Bielicki.

Andreas Heilwagen hat in einem Post 9 Denkschulen des Projektmangements nach Rodney Turner, Cristophe Bredillet und Frank Anbari ausgegraben, nämlich:

1. Optimierung: Das Projekt als Maschine
2. Modellierung: Das Projekt als Spiegel
3. Governance: Das Projekt als Rechtssubjekt
4. Verhalten: Das Projekt als soziales System
5. Erfolg: Das Projekt als Geschäftsziel
6. Entscheidung: Das Projekt als Computer
7. Prozesse: Das Projekt als Algorithmus
8. Umstände: Das Projekt als Chamäleon
9. Marketing: Das Projekt als Plakatwand

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.

Projektmanagement ist eine Technik und keine Wissenschaft. Das Verhältnis von Wissenschaft und Technik ist wechselseitig befruchtend. Während Wissenschaft vor allem beschreibend und erklärend wirkt, ist Technik (und so auch Projektmanagement) vor allem nutzenstiftend. Böse gesagt könnte man auch formulieren: Projektmanagement ist nie Selbstzweck, Wissenschaft mitunter schon.

Natürlich kann man auch Projekte wissenschaftlich betrachten.

Richard Joerges tut dies in einem Beitrag in dem er versucht von der Chaostheorie Rückschlüsse auf Projekte zu ziehen. Ähnlich könnte man auch versuchen von kybernetischen Modellen oder Organisationstheorien Rückschlüsse auf Projekte zu ziehen. Einen sehr interessanten Ansatz finde ich dabei die Theorie sozialer Systeme nach Luhmann – auch wenn ich noch keine spezielle Ausarbeitung über Projekte finden konnte. Luhmanns zugegebenermaßen abstrakter Ansatz, dass sich soziale Systeme über Kommunikationen konstituieren (und nicht über die teilnehmenden Individuen), rückt das Thema Kommunikation in den Vordergrund und da gehört es auch im Projektmanagement m.E. nach hin! Mit einer solchen Theorie liessen sich Phänomene, wie wir sie aus dem Projektalltag hinreichend kennen, von sich wandelnden Projektaufträgen, politischen Spielchen und Projektdynamiken, erklären, die in den klassischen PM-Methodologien nur ein Schattendasein fristen.