Gantt Chart, ruhe in Frieden!

Es macht richtig Spaß, alte Blog Posts zu lesen. In diesem Fall heißt der Post Gantt Charts considered uncool und stammt von April 2006, damit ist er fast sieben Jahre alt. Autor war ein gewisser Matthias Bohlen. Er machte dieselbe Aussage auf einer Konferenz 2006 und wurde dafür schief angesehen (zumindest von professionellen Projektmanagern). Ich habe Sympathie für ihn. Er war einfach seiner Zeit voraus.

Gestern stolperte ich nun über eine Website, die heißt projectmanagement.com. Auf der About-Seite dieser Website fand ich folgendes:

This is why we built ProjectManagement.com. Our mission is simple: To make project managers more successful. … You might remember us as gantthead, which launched in 2000. At that time, every project worth managing was run using a gantt chart. However, times changed and many project leaders were more focused on their KanBan Boards than on a linear schedule.

Oh Du liebes Gantt-Chart, Matthias Bohlen hat also Deinen Tod mindestens sieben Jahre zu früh vorausgesagt. Entschuldige bitte herzlich!

Was er vor sieben Jahren noch nicht sagte, sage ich Ihnen heute:

  1. Aus Gantt-Charts lernen Sie nichts über die Fähigkeiten Ihres Teams.
  2. Sie lernen auch nichts über die Probleme, die in Ihrem Prozess stecken.
  3. Sie lernen auch nichts darüber, wie sich die Ankunftsrate neuer Anforderungen zur Abarbeitungsrate alter Anforderungen verhält und ob Ihr Projekt deshalb im Gleichgewicht steht.

All das, was Sie heute wie selbstverständlich aus einem Cumulative Flow Diagram entnehmen, haben Sie in einem Gantt Chart nicht. Möge dieser Diagrammtyp ruhen in Frieden!

Diese Beiträge könnten Sie noch interessieren:

Kommentare

  1. meint

    Danke, Herr Fischbach, für den interessanten Link mit viel Hintergrundinformationen zu Gantt.

    Es ist gut, die Themen bis zur eigentlichen Quelle zurückzuverfolgen, dann sieht man, was der ursprüngliche Autor (in dem Fall Gantt) eigentlich erreichen wollte: Maschinen hoch auszulasten, ein ganz anderes Problem als ein Projekt oder einen Service zu managen. Kein Wunder, dass Gantt-Charts dort nicht funktionieren, denn in Projekten oder Services geht es nicht um Auslastung, sondern um viele andere Qualitäten, die wichtiger sind.

    Sehr erhellend, vielen Dank!

  2. meint

    Hallo Herr Bohlen, ja, stimmt. Und ich dachte immer, ich sei zu blöd, um mit Gantt-Charts richtig umzugehen. Deswegen gefallen mir Methoden wie PRINCE2 oder Scrum so gut, weil es da immer um Ergebnisse geht, die produziert werden sollen (und nicht um Aktivitäten). Beste Grüße, Jan Fischbach

  3. Guido Zockoll meint

    Hallo Herr Bohlen, auch wenn ich grundsätzlich kein Freund von Gantt Diagrammen bin (weil sie meist falsch eingesetzt werden), so kommt mir ihre Kritik so etwas so vor, wie der, der sagt: “Ein Globus ist nutzlos, weil er mir ja gar nicht zeigt, wo ich an der nächsten Kreuzung abbiegen muss!”

    Wo in den CFD finde ich den Pufferzeiten im Projekt? Es gibt Projekte, die müssen zu einem bestimmten Tag X abgeschlossen sein (Mehrwertsteuerumstellung, …). Hier ist eine Rückwärtsplanung ein wertvolles Hilfsmittel, um kritische Meilensteine zu erkennen und den Projektleiter (oder das Team, den PO, den SM) in die Lage zu versetzen, Maßnahmen zu ergreifen und ggf. nochmal den Scope zu überprüfen.

    Ich habe schon viele agile Projekte gesehen – das Thema Rückwärtsplanung kommt meist nicht vor – und der agile Werkzeugkasten sieht dazu auch wenig Nützliches vor – außer der Aussage, dass Rückwärtsplanung ja sowas von unagil ist ;)

    Leider kommt Rückwärtsplanung auch in Gantt gesteuerten Projekten nur selten vor – aber die Netzplantechnik bietet hier gute Möglichkeiten, um zu sehen, ob man noch “on track” ist oder nicht. Viele PM kennen allerdings nur Gantt und haben dann 400 Aufgaben im Gantt Chart und verbringen mehr Zeit damit, die Charts zu aktualisieren, als aktiv ihr Projekt zu steuern (das meine ich mit falschem Einsatz).

    In meinem letzten Projekt hatten wir ein Gantt-Chart mit den wichtigsten Meilensteinen <=10 Tasks und CFD und Burn-Down für die Sprints. Eine super Kombination. Viele Grüße, Guido Zockoll

  4. meint

    Hallo Herr Zockoll,

    danke für die schöne pointierte Antwort! Ich habe erst einmal lachen müssen über das schöne Bild mit dem Globus.

    Ich könnte Ihnen jetzt Recht geben: Gantt kann bei SEHR grobgranularer Einteilung nützlich sein. Ich will aber lieber mal weiter provozieren und sehen, wohin wir damit kommen.

    Zunächst zum Projekt-Setup: Warum stellen wir uns nicht so auf, dass wir sagen: Wir gehen morgen live! Mit Null Features, wirklich ein System, das nahezu nichts tut. Nur um zu sehen, ob unser Setup stimmt und wir in der Lage sind, innerhalb von 5 Minuten ein Feature zu releasen. Dann kann es also schon mal keine “kritischen Meilensteine” namens Deployment und GoLive (Inbetriebnahme) geben, denn die sind bereits heute erfolgt.

    Als nächstes verstehen, entwickeln, testen und releasen wir ein Feature nach dem anderen und messen, wie schnell wir sind (Durchsatz). Das CFD zeigt ja die Steigung des Übergangs in den letzten Zustand.

    Dann extrapolieren wir diese Schnelligkeit und schauen, wie viel Scope wir uns bis zum Endtermin erlauben können.

    Dann schauen wir, wie viel Zykluszeit ein Feature im Durchschnitt braucht und machen daraus ein Control Chart mit Lower Control Limit und Upper Control Limit. Wir schedulen die Features dann so, dass vor dem Endtermin die kritischsten Features drin sind – so ein Feature muss ja spätestens am Endtermin minus UCL(Zykluszeit) begonnen werden, um sicher drin zu sein.

    So, wozu brauchen wir jetzt noch Meilensteine und Aktivitäten auf einem Zeitstrahl? Nein, wir brauchen nur Fluss von Ergebnissen, keine Aktivitäten.

    Sach ich heute mal so. Heut habe ich mal Lust auf Schwarzweiß-Malerei. Mal sehen, wie weit wir damit kommen.

    Schöne Grüße
    Matthias Bohlen

  5. Guido Zockoll meint

    Ok, da ein Projekt ja nicht nur aus Softwareentwicklung besteht, spinnen wir das Problem mal weiter …

    Anwenderschulung: Wir halten am ersten Tag mal 1h Anwenderschulung mit etwas Inhalt und messen, wieviel der Anwender davon kapiert. Daraus extrapolieren wir, wann wir mit den Anwenderschulungen für unsere 300 User anfangen müssen ;)

    Ich bestreite ja gar nicht, das agile Verfahren die beste und genaueste Vorwärtsplanung für ein Projekt liefern. Was aber fehlt ist die Rückwärtsplanung, und vor allem der Abgleich zwischen Vorwärts- und Rückwärtsplanung. Dazu gehören eben auch Aufgaben wie Anwenderschulung, Beschaffung von Hard- und Software, Steuerung von Dritten. Mit Meilensteinen meinte ich nicht Deploy und GoLive!

    Und da sind agile Verfahren im Moment noch auf Unterstützung aus dem klassischen Projektmanagement angewiesen. Werder CFD noch Burn-Down-Chart helfen hier weiter.

  6. meint

    Synchronisation mit Aktivitäten, die außerhalb der Entwicklung liegen, ist immer wieder ein Grund, Rückwärtsplanung machen zu müssen, das stimmt. Marketing hat lange Vorlaufzeiten. Anwenderschulungen mit 300 Leuten sind ebenfalls nicht von heute auf morgen vorzubereiten. Hardwarebeschaffung kann in Großunternehmen Monate dauern, das habe ich auch schon erlebt. (Warum diese Unternehmen sich dann immer noch keine In-house Private Cloud anschaffen, ist mir ein Rätsel).

    Solche Meilensteine aus einer Rückwärtsplanung zu gewinnen, ist völlig in Ordnung. Deren Zahl ist ja auch übersichtlich, so dass sie notfalls sogar in ein Gantt-Chart passen. :-)

    Anschließend mit einer schlanken Vorwärtsplanung auf so einen Meilenstein hinzuarbeiten und dabei den Wert der früh gelieferten Features so zu maximieren, dass am Ende auch etwas “hinten runter” fallen darf, ist m.E. die eigentliche Kunst. Und zwar nicht, weil er keine Verfahren dafür gäbe, sondern weil es gilt, die Menschen im Projekt zu dieser Denkweise zu bringen. “Was, wir im Fachbereich sollen JETZT schon testen? Das machen wir doch immer erst kurz vor Projektende, also etwa heute in zwei Jahren!”

    Da habe ich als Coach dann jeweils meine Aufgaben… :-)

  7. meint

    Hallo,
    für meine IT-Projekte setzte ich jahrelang auch auf GANT-Diagramme. Mittlerweile finde ich die Storys aus den agilen Methoden geeigneter.

    Und die Rückwärtsplanung muss sein. Welchen Nutzen hat der User / Kunden / Auftraggeber am Ende des Projektes? Wenn diese Frage nicht beantwortet ist, darf ich doch gar nicht erst anfangen, oder?

    Übrigens nutze ich die Rückwärtsplanung auch für meine anderen Lebens-Projekte wie Abnehmen. Wie soll das Endergebnis aussehen? Mit diesem klaren Ziel vor Augen, kann ich mir jeden Tag die richtigen Entscheidungen heraussuchen.

    Viele Grüße,
    David Goebel

  8. meint

    Hallo Herr Goebel,

    ich habe ein wenig in Ihrem Blog gestöbert. Was Sie mit Rückwärtsplanung meinen, ist etwas ganz anderes – nämlich etwas, das ich voll unterstütze! Zuerst wissen, was das Endergebnis sein soll, dann den Weg dahin planen, das ist gesund.

    Bei einer anderen Art der Rückwärtsplanung habe ich oft gesehen, dass sie nicht funktioniert, und die geht so: 1. Wir wissen, am 1.5. muss alles fertig sein. 2. Wir schätzen, dass es so und so viele Aktivitäten à so und so viele Personentage sind und planen das auf dem Zeitstrahl, und zwar rückwärts vom Endtermin aus. 3. Wir bekommen einen Starttermin und legen los. Wenn wir auf dem Zeitstrahl nicht so schnell vorwärts kommen wie gedacht, machen wir halt schneller.

    Diese Art meinte ich in meinen vorigen Kommentaren.

    Schöne Grüße
    Matthias Bohlen

Hinterlassen Sie eine Antwort

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Sie können folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>