Das Teamwork-Blog

"Projektmensch" Holger Zimmermann will in einem Beitrag in seinem lesenswerten Blog eine Lanze für klassisches Projektmanagement brechen /1/. Er stört sich - wie ich finde zurecht - daran, dass jetzt in der Projektarbeit nur noch Agilität das letzte Wort hat. Seine These: " Es gibt kein nicht-agiles Projektmanagement. Wer sich intensiv mit der Methode auseinandersetzt, merkt schnell, dass ein paar Anwender irgendwann falsch abgebogen sein müssen. " /1/ Dann wollen wir uns mal auf die Suche machen, wo die paar Anwender falsch abgebogen sein könnten.

Ab und zu stellen wir in unseren Beratungsprojekten fest, dass ein Team ein Projekthandbuch zu erstellen hat. Braucht man aus agiler Sicht überhaupt noch ein Projekthandbuch? In dieser Woche gibt es eine kleine Serie zu diesem Thema.

Es ist doch schön, wenn ein Unternehmen viele Ideen hat: neue Produkte entwickeln, bestehende Produkte verbessern, Prozesse ändern, Dinge aufräumen, an die Zukunft denken. Wenn wir Kunden beraten, merken wir, dass unsere Kunden unter der Qual der Wahl leiden: alle hat die höchste Priorität, ständig werden Entscheidungen überschrieben, es laufen zu viele Projekte gleichzeitig. Aus agiler Sicht wäre ein Vorschlag, ein Company Backlog anzulegen. Doch was kommt da eigentlich genau hinein und wie geht man damit um, damit es nicht wieder zum Streit kommt?

Vor 2 Jahren haben wir unser E-Book "Projektablage" veröffentlicht. Mittlerweile verkaufen wir mehr als 20 E-Books pro Monat. Aus diesem Anlass verschenken wir 5 Stück.

Eigentlich weiß jeder, dass man für wichtige Investitionen Aufwand und Nutzen abwägen soll. Lohnt sich der Spass oder lasse ich es besser bleiben? Bei vielen Unternehmen ist es sogar Pflicht, einen sog. Business Case vorzulegen, wenn man ein Projekt beantragt. In der Praxis funktioniert das leider gar nicht gut. Es werden zu viele Projekte gestartet. Was ist also der Business Case für Business Cases?

Es gibt unterschiedliche Projektumgebungen, bei denen ein Projektmanager ganz andere Schwerpunkte setzen muss. Das wird schnell übersehen, wenn man nicht weiß, dass es so etwas wie Unsicherheitsprofile gibt.

Es gibt viel Literatur über Projektmanagement und benachbarte Managementdisziplinen. Um konkret zu verstehen, was Projektarbeit wirklich bedeutet, empfehle ich folgende Bücher.

Viel zu oft wird Projektmanagement als eine sehr komplizierte Angelegenheit dargestellt. Wenn man verschiedene Bücher durchliest, wird einem ganz schwindelig bei den ganzen Management-Disziplinen, die ein guter Projektleiter beherrschen soll. Aus meiner Sicht muss man nur ein paar Regeln beachten und selbst denken.

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Meine wichtigste Regel zum Thema Projektmanagement lautet: Projektarbeit bedeutet, Ergebnisse unter Unsicherheit liefern. Warum ist das eigentlich so wichtig?

Die Verbreitung und Nutzung von Techniken des Projektmanagements ist zu gering. Das verwundert, da doch viele Teams eher mehr als weniger Projekte starten. Mangelndes Projektmanagement wird oft als Führungsschwäche der Projektmanager eingestuft. Um ein Projekt doch noch zu retten, wird der Druck auf die Mitarbeiter erhöht. So funktioniert das nicht. Lassen Sie uns lieber auf die wirklichen Gründe schauen.

Ich habe mich vor kurzem an einer Umfrage zum Thema Projektmarketing beteiligt. Beim Beantworten der Fragen habe ich überlegt, was ich von Projektmarketing halte. Sicherlich wird im Projekt immer zu wenig kommuniziert. Aber brauchen wir wirklich ein eigenes Marketing? Ich denke, im Moment haben wir in Projekten andere Probleme, um die wir uns erst kümmern sollten.

Ein beliebtes Diskussionsthema bei Prozessänderungen ist die Frage, ob man sich wirklich an alle Regeln der vereinbarten Methoden halten muss. Die Frage ist nicht einfach zu beantworten. Ich denke, dass es im Zweifelsfall einfacher ist, wenn Teams es tun .

Wolf und ich (Jan) haben ein Buch über den Umgang mit Dokumenten in Projekten geschrieben. Nun ist es bei Amazon.de und bei Leanpub erhältlich. Wer es schon gelesen hat, kann uns mit einer Rezension bei Amazon helfen.

Wolf und ich haben lange daran gefeilt. Wir haben einen Leitfaden für den Umgang mit Dokumenten in Projekten geschrieben. Wer möchte, kann sich schon eine Leseprobe bei Leanpub herunterladen: https://leanpub.com/projektablage/  

Der Newsletter von 37Signals hat mich auf das Thema "Lernen" aufmerksam gemacht (/1/). Dort wird auf einen Beitrag hingewiesen (/2/), in dem Shane Parrish etwas über Warren Buffet und seinen Anspruch "Jeden Tag etwas schlauer zu werden" schreibt. Grund genug, mal auf die Lern-Rituale von Teams zu blicken. Scrum, Kanban und PRINCE2 machen Vorschläge. 

Vor kurzem wurde ich gefragt, was ich so als Berater mache. Ich erzählte von Scrum, PRINCE2 und Co. Was passierte? Meine leuchtenden Augen blickten in verständnislose Augen. Wieso sei denn das so schwierig mit den Projekten? Und außerdem sei das doch wie beim Hausbau. Man müsse halt einen Plan machen und den durchziehen. Ja, warum brauchen wir eigentlich einen methodischen Umgang mit Projekten? Gute Frage.

Auf verschiedenen Plattformen ist eine Diskussion darüber entbrannt, was überhaupt ein Projekt ist, ob es z. B. Sinn macht, von „agilem Projektmanagement“ zu reden und ob es nicht besser wäre, das Wort „Projekt“ überhaupt aus dem Vokabular zu streichen. /1/ Wir möchten gerne unsere Überlegungen zu dieser Diskussion beisteuern. Denn es geht darum, Begriffe so zu wählen, dass sie uns bei der Verständigung in unserer Projektmanagementpraxis optimal unterstützen.

Neben Fachwissen brauchen Teams auch Methodenwissen. Nun herrscht aber kein Mangel an Methoden. Wie soll ein Team damit umgehen, wenn einzelne Mitglieder unterschiedliche Methoden propagieren? Im ersten Teil haben wir uns drei Möglichkeiten angesehen. Hier folgt ein weiterer Vorschlag.

Neben Fachwissen brauchen Teams auch Methodenwissen. Nun herrscht aber kein Mangel an Methoden. Wie soll ein Team damit umgehen, wenn einzelne Mitglieder unterschiedliche Methoden propagieren? Kann man über Methoden streiten? Wie kann man einen Streit umgehen?