Josh Nankivel bringt es auf PM-Student auf den Punkt:

Project Managers Focus Too Much On Tools.

Tools Don’t Manage Projects. You Do.

Agile Softwareentwicklung hat auch bei Microsoft Einzug erhalten. Ein Bericht in Spiegel online hat zahlreiche Reaktionen in den einschlägigen PM- und Sofftwareentwicklungs-Blogs gefunden, z.B. bei Jens Coldewey, Danny Quick und last but not least Andreas Heilwagen.

Hier war schon von einer Rückbesinnung auf das Wesentliche im Projektmanagement im Sinne eines Simplify your projects die Rede. Ähnlich fällt mitunter das Stichwort von einem Lean Project Management, was man gerne mit „schlankem Projektmanagement“ übersetzen möchte. Aber klassisches Lean Management hat einige Konotationen. In der Zweiten Revolution in der Automobilindustrie (Amazon Affiliate Link) von Womack, Jones und Roos werden nämlich 5 Grundsätze eingefordert:

1. Den Wert aus Sicht des Kunden definieren
2. Den Wertstrom identifizieren
3. Das Fluss-Prinzip umsetzen
4. Das Pull-Prinzip einführen
5. Perfektion anstreben

Das mag ja alles irgendwie richtig sein, trifft aber nicht den Kern dessen, was ich unter einem schlanken Projektmangement verstehen möchte. Ich würde vor allem auf zwei Aspekte fokussieren:

1. Transparenz
2. Kommunikation

Transparenz schließt nicht nur die Vorgehensweise im Projekt und die Projektergebnisse mit ein, sondern zuallererst den Projektauftrag.
Innerhalb des Projekts und zwischen Projekt und Stakeholdern spielt die Kommunikation die entscheidende Rolle, um die erforderliche Transparenz zu schaffen.
Kommunikation spielt aber darüber hinaus auch im sozialen System „Projekt“ einen wesentlichen Part. Deshalb kann beispielsweise Dokumentation Kommunikation nicht ersetzen. Dokumentation sorgt zwar ebenfalls für Transparenz, unterstützt aber nur nachrangig die Interaktion der Projektbeteiligten.

Auf diese zwei Aspekte zu fokussieren heißt natürlich nicht, alles, was im Projektmanagement an Werkzeugen und Theorien entstanden ist, einfach über Bord zu werfen. Vor dem Methoden-Overkill ist der Einsatz einer Methode aber immer zu hinterfragen:

Inwieweit trägt eine Maßnahme, Methode, Theorie oder Tool im Projekt zu Transparenz und Kommunikation bei?
Und natürlich: Inwieweit trägt sie zum Projektziel bei?

Lynda Bourne setzt sich mit der Neuauflage von PRINCE2 auseinander und zieht einen Vergleich zum PMBOK des PMI:

PRINCE2 sees the project starting much earlier and continuing through to the realisation of value by the organisation. This is quite likely correct from the perspective of an organisation initiating and managing internal projects.

There is very little difference in terms of the processes used to run a project between PRINCE2 and the PMBOK. What is different is PRINCE2 is totally focused on managing internal projects with organisational managers having a direct say in the management of the overall process and it provides an effective methodology for this circumstance. The PMBOK® Guide is a pure PM standard and has a more generic set of processes that can be adapted to a much wider range of circumstances and used in any situation (eg, a traditional project where the client contracts the project delivery organisation).

Das Scheitern von Projekten hatten wir hier schon wiederholt als Thema. Jahr für Jahr analysiert die Standish Group mit dem CHAOS-Report mögliche Ursachen. Wie Richard Joerges  und Eberhard Huber zurecht anmerken, unterscheiden sich die Ergebnisse (unabhängig von der Wirtschaftskrise) kaum von den Vorjahren. In einem anderen Beitrag weist Eberhard Huber auch darauf hin, dass es gar nicht so einfach ist, zu beurteilen, ob ein Projekt erfolgreich war oder nicht.

Passend dazu auch eine aktuelle Umfrage von Stefan Hagen, warum Projekte scheitern. Ursache Nummer 1 ist demnach vor allem mangelnde Kommunikation. Diese Aussage kann ich nur unterstreichen. Der zweite wesentliche Grund fehlt allerdings in der Aufzählung, bzw. versteckt sich hinter einer Reihe anderer Gründe: mangelhafte Projektaufträge/Auftragsklärung. Weitere Kommentare zu Stefan Hagens Umfrage finden sich bei Andreas Heilwagen oder wieder bei Richard Joerges.

Um die Diskussion hier fortzuführen noch zwei weitere kritische Anmerkungen:

(1) Die 90-9-1 Regel gilt auch für Microblogging

//SEIBERT/MEDIA zitiert die 90-9-1 Regel für Wikis im Wissensmanagement. Sie dürfte sich aber analog auch auf das Microblogging übertragen lassen.

Im Internet (…) steuert lediglich ein Prozent der User den Großteil der nutzergenerierten Inhalte bei, neun Prozent beteiligen sich gelegentlich an der Content-Produktion und neun von zehn Nutzern erstellen niemals Web-Inhalte, sondern konsumieren ausschließlich.

Vollständigkeit und Zuverlässigkeit sind somit fraglich.

(2) Kommunikation ist zielgerichtet, Microblogging nicht

Kommunikation ist im Idealfall ein bewußter, zielgerichteter Akt zwischen Sender und Empfänger. Microblogging ist mir an dieser Stelle viel zu unspezifisch. Jetzt könnte man kritisch anmerken, dass dies auch für jeden Blog (also auch für diesen hier) gilt. Dem ist sicher auch so, wenn nicht (wie ich es hier versuche) die Inhalte in einen konkreten Kontext gestellt werden.

Auf ARMERKATER.de findet sich die lesenswerte Zusammenfassung zu einem Vortrag von Stefan G. Gfrörer, in dem er sich mit der Frage auseinandersetzt, wie agile Vorgehensweisen und klasssisches Projektmanagement á la PMBOK zusammenpassen.

Um die Diskussion über den sinnvollen Einsatz von Microblogging á la Twitter in Projekten noch einmal aufzunehmen:

Ist es nicht bemerkenswert, dass uns ausgerechnet aus der SCRUM-Ecke eine solche Forderung noch nicht untergekommen ist? Gerade unsere agilen Freunde besinnen sich im Daily Scrum Meeting auf klassische Face-to-Face-Kommunikation und auch in puncto Dokumentation sind ganz gezielt Artefakte im Einsatz. Eine mangelnde Technik-Affinitiät kann man den Kollegen sicher nicht unterstellen.

Eberhard Huber weist zurecht darauf hin, dass wir im Verhältnis von Projektkultur zu Projekterfolg das alte „Henne und Ei“-Problem wiederfinden. Einerseits ist Projektkultur ein Erfolgsfaktor für Projekte, andererseits prägen und entwickeln Projekterfolge unsere Projektkultur. Allerdings können auch Misserfolge wesentlichen Einfluss ausüben, aber über Misserfolg spricht man in unserer Gesellschaft halt meist nicht gerne…

Dirk Röhrborn und Martin Böhringer machen sich in ihrer Präsentation stark für Mikroblogging (á la Twitter) im Projektmanagement:

Sie verweisen auf die Vorteile einer Peer-to-Peer-Kommunikation (alle haben alle Informationen) und sehen dies als Ansatz für eine nachvollziehbare Projekthistorie und Basis für die Dokumentation.
Um ehrlich zu sein, geht mir diese Sichtweise viel zu weit: Peer-to-Peer Kommunikation läuft Gefahr zu einem „Mail an alle“ zu verkommen. Natürlich hat dann jeder jede Information, aber ist das überhaupt sinnvoll? Ich bin kein Geheimniskrämer und auch in Großprojekten predige ich immer wieder für Transparenz und Offenheit, aber die Komplexität von Projekten ist häufig erschlagend. Zwar sollte jeder Zugang zu allen relevanten Infromationen haben, aber die Projektmitarbeiter sind auch vor einem Information Overkill zu bewahren, denn sonst sehen sie im sprichwörtlichen Sinn den Wald vor lauter Bäumen nicht mehr.
Ein weiteres Manko sehe ich in der strikten Limitierung des Umfangs auf 140 Zeichen. Zurecht kritisieren viele die Trivialisierung unserer Projektwelt durch die Powerpoint-Manie. Eine Reduktion auf 140 Zeichen je Botschaft treibt dies aber möglicherweise auf die Spitze.
Im Einzelfall kann ich mir aber durchaus auch den Einsatz von Microblogging vorstellen: In einem Umfeld mit sehr hoher Affinität zu solchen Kommunikationsmedien, aber auch dann sollten wir uns stets der Grenzen dieses Mediums bewusst sein.