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.

„Getting things done“ (oder kurz GTD) von David Allen ist ein Selbstmanagement-Ratgeber, der mittlerweile auch im Internet eine große Fan-Gemeinde gewonnen hat (so berichten diverse Blogs – beispielsweise Stephan List oder imgriff über GTD und selbst in Wikipedia haben sich die Anhänger einige Mühe gemacht). Die englische Paperback-Ausgabe (Amazon) kommt bis auf das Cover eher altbacken daher, kaum Grafiken und Illustrationen, fast nur Text. Bei der Lektüre überzeugt Allen dann aber durch Einfachheit und Konsequenz – und bekennt sich dazu. Einfachheit darf man hier aber nicht mit Trivialität verwechseln: David Allen hat ganz klar etwas zu sagen!
Das Erste, was überzeugt ist der Titel: Es geht nicht darum seine Zeit oder sich selbst zu managen, sondern Dinge zu regeln – Getting things done!
Allens zentrale Idee ist es den „Fluss dieser Dinge“ zu organisieren. Wir brauchen nicht Tag für Tag neue Listen, sondern einen kontinuierlichen Fluss, den wir systematisch Aufarbeiten und neue Dinge werden wieder oben in den Fluss reingekippt. Upps, plötzlich sind wir eigentlich in logistischen Fragestellungen: das Flussprinzip – und Allen zeigt wie man es auch für sich selbst und nicht nur für die Organisation von Produktionsketten gewinnbringend einsetzen kann.
Innerhalb des kontinuierlichen Flusses ist die Handlungsorientierung essentiell: What´s the next action? Was muss in dieser Sache für dieses Ding als nächstes getan werden?
Wer den Fluss am Laufen hält und einem regelmäßigen Review unterzieht hat schon fast die halbe Miete.
Auf dem Weg zu einer höheren Produktivität gibt Allen weiter Ratschläge, die durchaus simpel aber beachtenswert sind. Wir sollten uns nicht mit Priorisierungen in den Wahnsinn treiben, sondern durchaus auch unserer Intuition vertrauen. Wenn wir „kleine Dinge“ in der Hand halten, sollten wir sie nicht in irgendwelche Stapel einsortieren, sondern sofern sie weniger als 2 Minuten benötigen, sofort erledigen – unabhängig von ihrer Priorität, denn Ablegen und Wiederaufgreifen kostet uns noch mehr Produktivität. Handlungsorientierung und die 2-Minutenregel alleine können schon helfen ein Verzetteln zu verhindern.
Allen gibt keine Tool-Empfehlung. GTD funktioniert sowohl auf Papier als auch in Outlook.
Wer bereits gut organisiert ist, wird vieles wiederfinden, aber trotzdem noch Anregungen bekommen. Die Lektüre (egal ob und wie weit man Allen folgt) eignet sich sehr gut, um die eigene Selbstorganisation kritisch zu prüfen.

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…

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

Auch //SEIBERT/MEDIA setzt sich mit dem Einsatz von Microblogging in Unternehmen ein. Meine Vorbehalte aus dem vorangehenden Eintrag können Sie aber auch nicht ausräumen.

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.

Tomas Bohinc greift die Forderung des PMI auf, das Projektleiter Grundkenntnisse der wichtigsten Managementtheorien haben sollten und liefert gleich eine erste Übersicht. Seine Auswahlkriterien behält er dabei allerdings für sich. Es finden sich zwar Klassiker, wie Taylor , Maslow, Herzberg und Lewin, aber wo sind z.B. Transaktionskostentheorie, Principal-Agent & Co?