Projektmanagement
Kommentare 4

Projektplanung 101: Fortschritt

»Planung ersetzt Zufall durch Irrtum.« soll Albert Einstein gesagt haben und Feldmarschall Helmuth von Moltke meinte dazu nüchtern-realistisch: »Kein Plan überlebt die erste Feindberührung.« Ein Plan ist nur eine Richtschnur, die Messlatte mit der Abweichungen festgestellt werden. Der Plan muss deshalb regelmäßig an der Realität gemessen und korrigiert werden. Nichts schlimmer als ein veralteter Plan, heuchelt er doch trügerische Sicherheit, wo schon Blindflug herrscht.

Handhabbarkeit von Beginn an

Die Qualität eines Plans und die Erfahrung des Planenden zeigt sich besonders daran, wie leicht die Aktualisierung fällt. In den vorangegangenen Teilen dieser Serie wurde auf die Handhabbarkeit des Planes bereits eingegangen. Arbeitspakete sollten beispielsweise nicht zu klein gewählt werden, weil ihre Aktualisierung sonst sehr mühsam werden kann. Selbst wenn es zunächst keinen Unterschied im Ablauf macht, sollten logische Abhängigkeiten explizit im Plan eingetragen werden, weil es bei einer späteren Verschiebung einen Unterschied machen könnte. Ein gut aktualisierbarer mittelmäßiger Plan ist besser als ein schlecht aktualisierbarer perfekter Plan.

Wer viel misst, misst viel Mist

Es steht außer Frage, dass wir in der Lage sein müssen, Auskunft über den Zustand und den Fortschritt des Projekts zu geben. Aber welche Informationen sollte man dazu regelmäßig einsammeln? Gängige Planungssoftware verleitet uns dazu, je Arbeitspaket den Fortschritt in Prozent einzutragen. Das ist aber nicht ganz ungefährlich.

Betrachten wir die einfach scheinende Frage, was ein Fortschritt von 20% bedeutet. Die Software und der Projektleiter verstehen darunter meistens, dass 20% der Arbeit geleistet wurden und noch 80% zu leisten sind. Der Bearbeitende versteht darunter aber oft, dass die Ergebnisse zu 20% fertig gestellt sind. Leider ist das nicht immer identisch. Ersteres macht eine Aussage über den Aufwand, letzteres über den durch den Aufwand erzielten Gegenwert. Oft gilt nämlich das bekannte Pareto-Prinzip: es besagt, dass 80% der Ergebnisse mit 20% des Aufwands erreicht werden, während die restlichen 20% der Ergebnisse 80% des Aufwands verursachen. (vgl. Wikipedia)

Einfach nach dem Grad des Fortschritts zu fragen birgt also die Gefahr eines Missverständnisses, wenn man nicht explizit betont, dass das Verhältnis von bereits geleisteter zu insgesamt zu leistender Arbeit gemeint ist.

Restaufwände

Stattdessen empfiehlt es sich also, nach dem Restaufwand für das Arbeitspaket zu fragen. Die bereits geleistete Arbeit (Ist-Aufwand) hat man in der Regel ohnehin in irgendeiner Art von Zeiterfassung verfügbar und so ergibt sich der Fortschritt dann automatisch als Verhältnis von Ist-Aufwand zu der Summe von Ist- und Restaufwand. Gleichzeitig hat man damit auch den Gesamtaufwand für dieses Arbeitspaket aktualisiert, denn es wird oft so sein, dass der geschätzte Restaufwand zusammen mit dem Ist-Aufwand nicht dem ursprünglich geschätzten Gesamtaufwand passt.

Nehmen wir an, wir stecken mitten in der Bearbeitung eines Arbeitspakets »IT-Konzept erstellen«. Der Aufwand war mit vier Wochen geschätzt und der Kollege Meier arbeitet nun seit zwei Wochen an diesem Paket. In einer idealen Welt müsste das Paket zu 50% fertig gestellt sein. Meldet der Kollege Meier nun aber einen Restaufwand von drei Wochen, ist klar, dass einerseits die ursprüngliche Schätzung falsch und dass andererseits das Paket nun fünf Wochen dauern wird, weil der Kollege Meier alleine daran arbeitet. Wir haben nun zwei Erkenntnisse gewonnen: erstens hat das Paket »IT-Konzept erstellen« einen Fortschrittsgrad von 40% und zweitens wird es eine Woche später fertig. Mit entsprechenden Auswirkungen auf den Terminplan oder das Überstundenkonto von Kollegen Meier.

Der umgekehrte Fall, also dass eine Woche weniger als ursprünglich geschätzt benötigt wird, kommt leider in der Praxis nie vor. Hier gilt das erste Parkinsonsche Gesetz, wonach die Arbeit sich immer auf die zur Verfügung stehende Zeit ausdehnt.

Work expands so as to fill the time available for its completion.

C. Northcote Parkinson

90%-Syndrom

Gerade weil man anfangs gefühlt gut vorankommt (Pareto-Prinzip), wird der Restaufwand zur Fertigstellung gerne unterschätzt und damit ein zu hoher Fortschritt ermittelt. Dieses Phänomen wird gerne als 90%-Syndrom bezeichnet, weil recht schnell 90% erreicht werden um dann recht lange auf diesem Niveau zu verharren.

Miteinander reden

Auch wenn die Ermittlung des Fortschritts prinzipiell unscharf bleibt, ist die Zeit zur gemeinsamen Aktualisierung doch gut investiert. Es wird nämlich über den Plan, die laufenden Aktivitäten, Fortschritt und Restaufwände, Probleme und Abhängigkeiten geredet. Diese Kommunikation anhand des Plans, macht den Plan zu einem gemeinsamen, gibt Orientierung und Ziel. Daraus folgt, dass die Aktualisierung des Plans im Dialog erfolgen sollte, auch wenn das mehr Zeit erfordert. Von einem simplen Einholen der benötigten Informationen über E-Mail oder Projektmanagement-Software ist eher abzuraten.

Fazit

Den Fortschritt im Projekt zu erfassen ist nicht einfach. Durch ungeeignete Wahl von Arbeitspaketen und unkluges Vorgehen bei der Erfassung wird es sogar noch schwieriger. Umgekehrt ist das regelmäßige gemeinsame Durchgehen des Plans ein ausgezeichnetes Mittel den Plan im Team zu verankern.

Bisher erschienene Teile der Serie »Projektplanung 101«

  1. Arbeitspakete richtig schneiden
  2. Verknüpfungen setzen
  3. Ressourcen zuteilen
  4. Meilensteine setzen
  5. Fortschritt messen (dieser Artikel)
  6. Plan optimieren
  7. Exkurs: Shu-Ha-Ri

Bildnachweis: Das Artikelbild wurde von Håvar og Solveig unter dem Titel „Ruler“ auf Flickr unter einer Creative Commons Lizenz (CC BY 2.0) veröffentlicht.

Neu: Das Buch zum Manifest für menschliche Führung

Anlässlich des ersten Jahrestag gibt es das Manifest für menschliche Führung in ausführlicher Fassung als Buch bei Leanpub. Und das beste: Den Preis für kann jeder selbst festlegen! Ich freue mich über Feedback und Impulse einerseits und natürlich über große Verbreitung andererseits.

Buch Kaufen

Dir hat dieser Beitrag gefallen? Dieses Blog ist bewusst werbefrei, weil nur der Inhalt zählt. Wenn du deine Wertschätzung für diesen Beitrag zeigen willst, dann teile ihn wo auch immer. Und ich freue mich, wenn du mir einen Kaffee ausgibst! Denn in Anlehnung an das Zitat der Mathematiker Paul Erdős und Alfréd Rényi bin ich als Blogger auch nur eine Vorrichtung, um Kaffee in Artikel zu verwandeln!

Einen Kaffee ausgeben

4 Kommentare

  1. Erwin sagt

    Immer selber den Fortschritt überprüfen , dann sehen wie es die Kollegen sehen damit hält man das subjektive relativ klein

  2. Aber welche Informationen sollte man dazu regelmäßig einsammeln?
    – Kosten
    – Zeit
    – Qualität
    – Risiken
    – Ressourcenbezogene Daten
    – Scope (scope creep, hope creep, effort creep ;) )

    Mir reichen diese sechs Datenquellen, um eine integrierte Leistungsbewertung zwischen gestern und heute zu machen sowie eine Prognose ab heute bis Projektende zu erstellen.

    • Marcus Raitner sagt

      Eine gute Frage, auf die es mindestens so viele Antworten gibt, wie Projekte, Projektleiter und Organisationen. Meine Erfahrung bezieht sich größtenteils auf Software-Entwicklungs- oder andere IT-Projekte. Ziel ist es doch in Bezug auf die drei Dimensionen Kosten, Termin und Qualität den momentanen Standpunkt zu bestimmen. In Bezug auf den vereinbarten Scope, der sich im Laufe des Projekts ja bekanntlich ändert. Insofern ist die Basis, dass es immer eine aktuelle Aufstellung des vereinbarten oder noch zu vereinbarenden Umfangs gibt. Der Hauptkostenfaktor ist bei mir fast immer die Arbeit der Mitarbeiter, also erhebe ich immer Ist-Aufwand und Rest-Aufwand, damit ergibt sich einerseits eine Aussage über Kosten und Kostenabweichung und andererseits über die Restaufwände auch eine Aussage über die Abweichung in der Zeit. In vielen Fällen ist das schon ein guter Start und mehr oder weniger ausreichend. Meist messe ich noch die Wertschöpfung in Form von fertiggestellten Anforderungen / User Stories (ähnlich einem Burndown-Chart in Scrum). Die Qualität von Software zu messen ist ein Kapitel für sich. Am liebsten ist mir ein Testdriven-Development, d.h. die Testfälle entstehen als Teil der Spezifikation vor der Implementierung und es wird sozusagen gegen die Testfälle programmiert. Für Risiken sollte man bei allem sensibel sein, sie festhalten und systematisch bearbeiten.

Schreibe einen Kommentar

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