5 Fragen zum Projektmanagement
an Jan Fischbach

Kurz vor dem Wochenende machen wir einen kleinen Stopp in der Kaffeeküche und tauschen uns unter Kollegen aus. So verstehen wir unsere „5 Fragen an“-Artikelserie, in der wir erfahrene Projektmanager zu ihren Best Practices befragen.

Heute treffen wir Jan Fischbach. Er ist Geschäftsführer der Organisationsberatung CommonSense, Trainer für Scrum Events und Mitorganisator des freiräume.camp für neue Arbeitskultur.

1. Herr Fischbach, was ist Ihre bevorzugte Projektmanagement-Methode?

Unsere Kunden bitten uns meist aus zwei Gründen um Unterstützung: Organisationsprojekte (z. B. Einführen von ERP-Software oder eines Dokumentenmanagementsystems) oder Einführen von agilen Arbeitsstrukturen (Scrum etc.), was natürlich auch ein Organisationsprojekt ist. In beiden Bereichen nutzen wir überwiegend Scrum.

Die Community sieht Scrum nicht als Projektmanagementmethode, sondern als Teamprozess und als Mittel, um gute Produkte zu entwickeln. Und darum geht es in unseren Projekten: Teams bilden, die anfangen, ein Produkt zu liefern und dies stetig zu verbessern. Projektarbeit bedeutet für uns, Ergebnisse unter Unsicherheit zu liefern. Projekte werden nicht genehmigt, sondern finanziert. Bevor wir über Aufgaben- und Zeitplanung sprechen, brauchen wir im Team ein gutes Verständnis davon, welche Ergebnisse eigentlich geliefert werden sollen. Da bedienen wir uns bei der Produktbasierten Planung von PRINCE2, bei Earned Value Management (ANSI 748), Benefits Management (Ward/Daniel), Performance Based Project Management (Alleman), User Story Mapping (Patton) oder Impact Mapping (Adzic).

Wie hoch die Unsicherheit tatsächlich ist, unterschätzen Führungskräfte und Teams oft. Daher nutzen wir das Rautenmodell von Shenhar/Dvir, um Unsicherheit in Projekten zu erklären. Bei wichtigen Projekten empfehlen wir, mit einer Monte-Carlo-Simulation die Wahrscheinlichkeit von Terminen und Kosten zu prüfen. Wer für seine wichtigsten Arbeitspakete mit Dreipunktschätzungen arbeitet und sich mit Zufallszahlen einmal 1.000 Szenarien ansieht, stellt oft fest, dass die ersten Pläne doch sehr unwahrscheinlich sind.

Übrigens haben Ken Schwaber und Jeff Sutherland im November 2017 die neue Version des Scrum Guides veröffentlicht.

2. Setzen Sie für größere Projekte Software ein und falls ja, welche?

Wir sind keine großen Freunde von Software. Das liegt nicht an der Software, sondern daran, wie sie benutzt wird. Unser Ziel sind stabile Teams, die an einem Ort zusammen arbeiten. Da reichen oft eine freie Wand, Haftnotizzettel und Flipcharts. Wenn die Teammitglieder an mehreren Standorten sitzen, ist eine elektronische Unterstützung nützlich. Aber auch da bevorzugen wir es, Boards zu fotografieren und in der gemeinsamen Ablage zu speichern.

Unsere Kunden nutzen häufig JIRA und Trello. Allerdings nimmt die Datenmenge in diesen Tools schneller zu, als die Teams abarbeiten können. Es werden fleißig Daten eingegeben und die Pflege wird immer aufwändiger, weil mehr und mehr Pflichtfelder dazukommen. Irgendwann blickt keiner mehr durch, was geliefert wurde und welche Arbeit noch ansteht. Das Laden der Seiten und die Suche dauern länger. Einzelne Teammitglieder umgehen die Software, um die Arbeit erledigt zu bekommen. In solchen Fällen ist es gut, die Benutzung zunächst zu stoppen und inne zu halten: Was wollten wir eigentlich mit der Software erreichen? Natürlich kann man mit vielen Produkten auch offene Punkte verwalten und Stunden abrechnen. Aber soll die Software wirklich dabei helfen?

3. Was ist Ihr Lieblingsritual im Projekt?

Ich nutze sehr gern Story Mapping. Wir treffen immer auf sehr gute Mitarbeiter bei unseren Kunden. Was häufig fehlt, ist die gemeinsame Sicht auf die Dinge. Da finde ich Story Mapping wirklich hilfreich. Wir nehmen uns ein, zwei Stunden Zeit, um einen Prozess oder die Produktstruktur besser zu verstehen und um Arbeitsschwerpunkte daraus abzuleiten. In den folgenden Refinement- und Planungsereignissen greifen wir auf die Maps zurück.

4. Was ist aus Ihrer Sicht einer der meistunterschätzten Faktoren für den Projekterfolg?

a) Denken in Ergebnissen: Wenn ich mir verschiedene Studien über Projektmanagement ansehe (z. B. von PWC: Insights and Trends: Current Portfolio, Programme, and Project Management Practices, The third global survey on management), komme ich zu dem Schluss, dass Projekte nicht an mangelndem PM-Wissen scheitern. Ich glaube, zu oft steht uns unser Verständnis von Projektarbeit im Weg. Projektarbeit ist mehr als das Aufstellen und Verwalten von Aufgabenlisten und Kostenplänen. Projektarbeit bedeutet, Ergebnisse unter Unsicherheit zu liefern. Die wichtigste Frage ist immer: Was wollen wir liefern oder ändern? Bei ERP-Projekten ist nicht das Bereitstellen der technischen Systeme das Projektziel. Die Nutzer brauchen bestimmte Funktionen. Sie wollen Lieferscheine oder Rechnungen drucken. Bei DMS-Projekten geht es nicht um die Ablage von Dokumenten. Es geht um das Abschließen von Vorgängen im Team. Und dazu brauchen wir Dokumente. Welche Kompetenzen wollen wir nach dem Projekt beherrschen oder besser können als vorher?

b) Projekte werden finanziert und nicht genehmigt: Zu oft werden Projekte als Kostenverursacher betrachtet. Die agile Community hat ihre Sichtweise hier angepasst. Aus ihrer Sicht werden nicht Projekte durchgeführt, sondern Produkte (vor-)finanziert, mit denen man Geld verdient (oder einspart). Aus agiler Sicht und übrigens auch aus PRINCE2-Sicht steht die Wirtschaftlichkeit (Business Value, Business Case) im Vordergrund. Nachdem unsere Kunden die Projektkosten abgeschätzt haben, frage ich sie oft, welche Arbeitsweisen sich konkret ändern müssen, damit das Unternehmen des zwei- bis dreifache daran verdient. Das sind ganz spannende Diskussionen. In einem wirklich agilen Kontext ist ein Product Owner kein Projektleiter sondern ein Unternehmer.

5. Was ist Ihr größter Zeitkiller?

Unfokussierte Meetings: Ich schätze Scrum, weil aus Zeremonien wieder Ereignisse werden. Jedes Scrum-Ereignis hat einen klaren Fokus, entweder planen wir etwas oder wir sehen uns die Ergebnisse an. Es geht nicht darum, was eine Person schon alles getan hat. Bewertet werden nur die Ergebnisse. Das setzt Energien frei. In schlechten Projekten gibt es Statusbesprechungen, in denen viel zu lange Listen durchgekaut werden. Aus erwachsenen Menschen werden wieder Grundschüler, die dem Lehrer erklären, warum sie ihre Hausaufgaben nicht gemacht haben. Schrecklich. Statt die Ursachen unrealistischer Planung abzustellen, werden Menschen unter Druck gesetzt. Dieses System funktioniert nicht.

Überlastung: Bei allen unseren Kunden ist die Liste der laufenden Vorgänge zu lang. Sie nehmen sich viel zu viel vor. Alles soll gleichzeitig bedient werden. Das Wechseln zwischen den Baustellen kostet viel Zeit. Bei 5 gleichzeitigen Projekten ist ein Mitarbeiter 3/4 seiner Zeit mit dem Wechseln zwischen den Projekten beschäftigt: Es werden Projektstatussitzungen besucht, Protokolle geschrieben und gelesen. Es werden Übergaben gemacht. Das ist alles Arbeit, die dem Ergebnis keinen Wert hinzufügt, aber enorm Kraft kostet.

Vielen Dank für Ihre Zeit und viel Erfolg im nächsten Projet.