Task-Controlling

Wie misst man den Fortschritt von Arbeitspaketen?

Bis zum Release 4.08 konnte mit PQFORCE der Fortschritt eines Tasks in Prozenten gemessen werden – entweder manuell durch Eingabe einer Prozentzahl oder automatisch, wobei das System dann die verstrichene Zeit seit Startdatum des Tasks als Grundlage nahm. Der Ausstand, also 100% minus Fortschritt, wurde dann zur Berechnung der ausstehenden Arbeit auf dem Task verwendet. Die auf dem Task effektiv verrichtete und rapportierte Arbeit wurde vom System jedoch nicht berücksichtigt. Ab Release 4.09 ermöglicht PQFORCE nun, die erfassten Ist-Zeit mit zu berücksichtigen und zudem statt des Fortschritts auch den geschätzten Restaufwand zu erfassen. Wie dies alles zusammenspielt, erklären wir in diesem Tutorial.

Beginnen wir mit den Grundlagen und wichtigsten Begriffen

Ein Projekt wird in PQFORCE in eine Arbeitspaketsstruktur zerlegt. Jedes Element wird hier als Task bezeichnet und kann aus Unterelementen (Subtasks) bestehen. Dadurch entsteht eine Baumstruktur von Tasks, welche auch als Projektstrukturplan (engl. Work-Breakdown Structure) bezeichnet wird. Auf den Tasks werden dann die Ressourcen zugewiesen, welche an diesen Tasks arbeiten sollen. Die Verknüpfung eines Tasks und einer Ressource nennen wir Allokation. Die Allokation ist ein initialer Planwert zu Projektbeginn und bestimmt, wieviel Arbeit die Ressource auf dem Tasks zu verrichten hat. Das Start- und das Enddatum des Tasks legen fest, in welchem Zeitraum die Arbeit zu leisten ist. Wenn das Projekt und insbesondere der Task dann einmal gestartet wird und die Ressource am Task arbeitet, werden die effektiv geleisteten Arbeiten im System zurückgemeldet, sodass jederzeit eine Beurteilung des Fortschritts gemacht werden kann. Im Folgenden schauen wir uns an, wie dies alles zusammenspielt.

Berechnungslogik bis PQFORCE 4.08

Schauen wir uns zuerst an, wie das in PQFORCE bis zum Release 4.08 funktionierte. Dies lässt sich am Besten anhand von Illustrationen erläutern, auf welche wir im Folgenden verweisen. In der folgenden Illustration ist oben links beispielhaft die Verfügbarkeit  einer Ressource «Paul Müller» in einem gewählten Zeitfenster ersichtlich. Die Verfügbarkeit bildet eine wesentliche Grundlage für die Berechnung der Auslastung einer Ressource und deren Verteilung über die Zeit.

Nehmen wir nun an, dass die Ressource auf einen Task alloziert wurde, welcher sich über 3 Wochen erstreckt (z.B. vom 30. Mai bis zum 17. Juni). Auch diese Allokation der Ressource auf dem Task hat eine wichtige Bedeutung. Die Allokation ist der von der Ressource auf dem Task zu leistende Aufwand bzw. die zu verrichtende Arbeit. Sie wird erfasst und gemessen in Anzahl Stunden (oder einer anderen Zeiteinheit wie z.B. Arbeitstagen oder -wochen). In der Annahme, dass mit dem Task ein definiertes Ergebnis (z.B. ein Lieferobjekt wie ein Konzeptdokument oder ein Stück Software) zu erarbeiten ist, kann die Allokation als Gegenwert des Ergebnisses interpretiert werden: Der Aufwand der Ressource multipliziert mit deren Stundensatz ergibt die Kosten des Ergebnisses. Wenn mehrere Ressourcen auf dem Task alloziert werden, so gilt entsprechend die Summe der Allokationen als der Wert des Ergebnisses.

Eine weitere zentrale Rolle spielen das Start- und das Enddatum des Tasks. Die Allokation wird vom System gleichmässig und tagesgenau über die Taskdauer, also zwischen Start- und Enddatum verteilt, wobei an jenen Tagen mehr Aufwand eingeplant wird, an denen die Ressource mehr Verfügbarkeit hat. Genau genommen wird der Aufwand proportional zur Tagesverfügbarkeit verteilt. Insbesondere wird also an Tagen, an denen die Ressource gar nicht verfügbar ist, kein Aufwand eingeplant. So entstehen entlang des Tasks gewisse Auslastungsschwankungen, wie in der obigen Illustration unten links zu sehen ist. Die Schwankungen können unterschiedlich stark erscheinen, abhängig von der gewählten Skalierung der zeitlichen Auflösung – z.B. Tag, Woche oder Monat. Dieselbe Allokation sieht dadurch unterschiedlich aus, je nachdem, welche Skalierung gewählt wird. Das System rechnet die Tagesauslastungen dann entsprechend auf die Woche, den Monat etc. um, siehe das Beispiel «Woche» in obiger Illustration unten. Die so generierten Auslastungen pro Zeiteinheit sind gemäss Plan zu leistenden Arbeiten. Die Allokation ist ein Planwert und entspricht dem initialen Planaufwand, welcher als Referenz für die Fortschrittsbeurteilung bzw. die geleisteten Ist-Aufwänden beigezogen wird.

Schauen wir uns nun an, wie der Fortschritt erfasst wird und was seine Auswirkungen sind, wenn keine Ist-Aufwände auf dem Task rapportiert werden. Dazu verweisen wir nun auf die nachfolgende Illustration. Der Fortschritt wird in Prozent gemessen. 0% Fortschritt bedeutet, dass auf dem Task bzw. am Lieferobjekt noch nicht gearbeitet wurde. Ein Task mit 100% Fortschritt wurde vollständig abgearbeitet bzw. das Lieferobjekt wurde fertiggestellt. PQFORCE bietet nun die Möglichkeit, den Fortschritt eines Tasks automatisch zu berechnen, oder ihn manuell zu setzen. Bei letzterer Variante wird vom Anwender einfach eine Prozentzahl zwischen 0% und 100% eingetragen. Die Auswirkungen des erfassten Fortschritts auf die Allokationen sind in dieser Illustration dargestellt:

Zuerst berechnet das System den angenommenen von der Ressource geleisteten Aufwand als Fortschritt mal Allokation, also z.B. 36% x 44h = 16h. Diesen Aufwand nennen wir in PQFORCE den provisorischen Aufwand, weil das System nicht weiss, ob er auch tatsächlich geleistet wurde. Aus Mangel an weiterem Wissen (da die Ist-Aufwände im betrachteten Fall ja nicht rapportiert werden), scheint das die einzig sinnvolle Annahme zu sein. Dieser provisorische Aufwand wird dann ev., wenn einmal tatsächlich Ist-Leistungen auf dem Task verbucht werden, durch den Ist-Aufwand ersetzt (mehr dazu unten). Der provisorische Aufwand entspricht auch dem sogenannten Earned Value (EV). Es ist der Anteil des Lieferobjektwerts, welcher bereits erzielt wurde. Der provisorische Aufwand wird vom System in der Vergangenheit des Task, also zwischen Startdatum und dem Heute-Datum, proportional zur Verfügbarkeit der Ressource verteilt. Das System geht wiederum aus Mangel besseren Wissens davon aus, dass dieser Aufwand gleichmässig in der Verangenheit geleistet wurde. Der ausstehende Aufwand (Restaufwand), welcher sich ergibt aus Allokation minus provisorischer Aufwand, also z.B. 44h – 16h = 28h, wird analog in der Zukunft des Tasks eingeplant, auch wieder proportional zur Verfügbarkeit der Ressource. Diese Verteilung ist in der folgenden Illustration mit den genannten Beispielzahlen dargestellt. Ein wichtiges Detail ist, dass der Tag des Heute-Datums der Zukunft (nicht der Vergangenheit) angerechnet wird. Der Übergang von der Vergangenheit zur Zukunft – also im Prinzip die Gegenwart – ist im System immer die letzte Mitternacht. Durch das manuelle Erfassen des Fortschritts kann also die Allokation anteilsmässig in einen Anteil, welcher angenommen bereits geleistet wurde (provisorischer Aufwand), und einen Anteil, der noch zu leisten ist (ausstehender Aufwand), unterteilt werden.

Zu beachten gilt, dass die manuelle Erfassung des Fortschritts regelmässig überprüft und nachgeführt werden sollte. Ansonsten bleibt der Fortschritt und somit insbesondere auch der ausstehende Aufwand mit fortschreitender Zeit konstant gleich, und da das Enddatum des Tasks jeden Tag näher rückt, staut sich dieser ausstehende Aufwand am Taskende an, siehe das Beispiel in Illustration 3. Um diesem Umstand entgegenzuwirken , kann die Fortschrittsberechnung automatisiert werden. Auf dem Tasks kann also hinterlegt werden, dass der Fortschritt automatisch nachgeführt wird, und zwar so: Das System belässt die gleichmässige Verteilung der Allokation über den Gesamtzeitraum des Tasks und berechnet den Fortschritt als Anteil der Allokation, welcher in der Vergangenheit liegt. Dadurch wandert der Prozentwert sozusagen mit dem Heute-Datum zwischen Startdatum des Tasks (0%) und Enddatum des Tasks (100%) vorwärts. Aber Vorsicht: Dies bedeutet nicht, dass der Fortschritt immer gleich gross ist wie der Anteil der seit dem Startdatum verstrichenen Zeit im Verhältnis zur Taskdauer! Siehe auch hierzu wieder die Illustration oben: Weil die Verfügbarkeit der Ressource in der Vergangenheit viel kleiner ist als in der Zukunft, ist der provisorische Aufwand auch entsprechend kleiner als der ausstehende Aufwand. Obwohl das Heute-Datum genau in der Mitte zwischen Start- und Enddatum des Tasks liegt, ist der automatische Fortschritt deutlich kleiner als 50%.

Erweiterte Berechnungslogik ab PQFORCE 4.09

Mit dem Release 4.09 wird die Art und Weise der Fortschrittsbeurteilung grundsätzlich erweitert. Dabei wird ein wesentlicher Faktor miteinbezogen, nämlich die Vergangenheit und damit der Ist-Aufwand, also die bereits geleistete und im System rapportierte Arbeit der Ressource. Im bisherigen System kann zwar der Fortschritt manuell erfasst werden, damit wurde der Ist-Aufwand jedoch nicht miteinbezogen. Eigentlich wurde der Ausstand (also 100% minus Fortschritt) verwendet, um auf Basis der Allokation den Restaufwand zu berechnen. Das bisher Geschehene wird dabei ausser Betracht gelassen.

Ab PQFORCE 4.09 wird nun auch der Ist-Aufwand in die Fortschrittsbetrachtung einbezogen, um eine Extrapolation in die Zukunft zu machen. Dabei kann auch ein möglicher Zusatz- oder Minderaufwand gegenüber der Allokation (initialer Planwert) entstehen, welcher zusammen mit der Allokation zu einem Prognose-Aufwand wird. Wir betrachten dies nun wiederum mit Hilfe von Illustrationen, um diese Aspekte anhand des oben bereits verwendeten Beispiels zu erläutern.

Rapportierte und provisorische Ist-Aufwände

Widmen wir uns zuerst dem Ist-Aufwand. Idealerweise werden die geleisteten Arbeiten tagesgenau auf die jeweiligen Tasks rapportiert, sodass das System jederzeit den in der Vergangenheit (also bis letzte Mitternacht, siehe oben) geleistete Aufwand ausweisen kann. Aus der Praxis ist jedoch bekannt, dass die Mitarbeitenden ihre Leistungen kaum je so zeitnah rapportieren, sondern vielmehr daran erinnert werden müssen, diese noch nachträglich zu erfassen. Viele tun es dann z.B. wöchentlich oder einfach gelegentlich, müssen aber typischerweise spätestens zu Beginn eines Monats aufgefordert werden, den vergangenen Monat mit ihrem Stundenrapport abzuschliessen, sodass die «Projektbuchhaltung» mindestens monatlich stimmt.

Wie geht PQFORCE mit dieser Problematik der fehlenden Ist-Aufwände um? Damit die Projektleitenden oder Task-Verantwortlichen jederzeit ein einigermassen korrektes Bild des Task-Fortschritts erhalten, macht das System folgende 2 Grundannahmen:

• Jede Ressource hat bis zu einem Datum x ihre Leistungen vollständig im System erfasst. Das Datum x kann zwar von Ressource zu Ressource variieren, aber es wird angenommen, dass an allen vergangenen Tagen inkl. am Tag x alle Leistungen auf allen Tasks und allen Projekten erfasst sind. Das Datum x wird bestimmt als jener Tag, an welchem die letzte Rapportierung der Ressource vorhanden ist – unabhängig von Task und Projekt.
• Nach dem Datum x hat die Ressource gemäss Plan gearbeitet. In dieser Zeit (also ab Datum x bis zur letzten Mitternacht) wurde gemäss Definition zwar nichts rapportiert, aber das System nimmt wider besseren Wissens an, dass nach Plan gearbeitet wurde .

Mit diesen Grundannahmen setzt sich der geleistete Aufwand also aus zwei Teilen zusammen: dem rapportierten Ist-Aufwand (hiernach kurz: Ist) und einem angenommenen Ist-Aufwand (hiernach kurz: Provisorisch). Ist-Aufwände werden im System mit dunkelgrüner Farbe dargestellt – insbesondere in Auslastungsdiagrammen – provisorische Aufwände hingegen mit hellgrüner Farbe. Die Summe aus Ist und Provisorisch nennen wir der Klarheit halber einfach Ist+Provisorisch.

Effort-driven und time-driven Tasks

Bereits vor Release 4.09 war es möglich, die Ressourcen auf zwei unterschiedliche Weise auf die Tasks zu allozieren:

• Die Allokation wird in Form eines absoluten Aufwands erzeugt, z.B. als Anzahl Stunden oder Tage, oder auch als Anteil des hinterlegten Grobplans (also prozentualer Anteil am sogenannten Planned Effort, kurz: % PE).
• Alternativ kann die Allokation durch Zuweisung relativ zu einer Verfügbarkeit pro Zeiteinheit erfolgen, entweder der Verfügbarkeit der allozierten Ressource (kurz: % AV, für Availability) oder der Verfügbarkeit einer Vollzeitstelle (kurz: % FTE, für Full-Time Equivalent).

Ab PQFORCE 4.09 werden die Tasks nun auf Basis der hinterlegten Allokationen in zwei Arten aufgeteilt, weil dies einen Einfluss auf die Fortschrittsbeurteilung hat. Ein Task, welcher ausschliesslich absolute Allokationen aufweist, wird effort-driven genannt. Wir gehen hier davon aus, dass es das primäre Ziel des Tasks ist, ein bestimmtes Ergebnis zu erzielen, welches mit einem geschätzten, absoluten Arbeitsaufwand erreicht werden kann. Dieser Arbeitsaufwand wird in Form von absoluten Allokationen den Ressourcen zugewiesen. Der Endtermin des Tasks bestimmt dann die Auslastung der Ressourcen bis dahin. Verschiebt sich der Endtermin in die Zukunft, flacht die Auslastung ab. Soll das Taskende hingegen früher erreicht werden, dann ergibt sich eine Vergrösserung der Auslastung, weil derselbe Aufwand in kürzerer Zeit zu leisten ist («Bugwelle»-Effekt).

Wenn auf einem Task alle enthaltenen Allokationen relativ sind, nennen wir den Task time-driven. In diesem Fall liegt der Fokus primär auf dem Task-Enddatum, bis zu welchem die Ressourcen mit gegebenem Aufwand pro Zeiteinheit an einem Ergebnis arbeiten sollen. Der absolute Aufwand der Ressourcen verändert sich in diesem Fall, wenn das Enddatum verschoben wird. Er wird grösser, wenn es sich in die Zukunft verschiebt bzw. kleiner, wenn das Taskende früher erreicht werden soll. Die Auslastung pro Zeiteinheit bleibt aber konstant. Vergleiche diesen Fall mit dem Fall effort-driven, bei dem der absolute Aufwand konstant bleibt, wenn das Taskenddatum verändert wird.

Wann Fortschrittseinschätzungen nicht möglich sind

In folgenden Fällen ist eine Erfassung des Fortschritts (Neueinschätzung) eines Tasks nicht möglich:

• Der Task liegt vollständig in der Vergangenheit, d.h. das Enddatum liegt vor dem Heute-Datum. In diesem Fall wird der Fortschritt automatisch als 100% angegeben und kann nicht manuell verändert werden. Soll ein Fortschritt erfasst werden können, muss das Enddatum in die Zukunft gelegt werden.
• Der Task liegt vollständig in der Zukunft, d.h. das Startdatum liegt nach dem Heute-Datum. In diesem Fall wird der Fortschritt automatisch als 0% angegeben und kann nicht manuell verändert werden. Soll ein Fortschritt erfasst werden können, muss das Startdatum in die Vergangenheit gelegt werden.
• Der Task ist time-driven. Mit der Erfassung eines Fortschritts wird indirekt ein Restaufwand errechnet. Alternativ kann der geschätzte Restaufwand auch direkt erfasst werden – die beiden Grössen Fortschritt und Restaufwand sind direkt voneinander abhängig, siehe unten. Auf jeden Fall widerspricht dies bei einem time-driven Task der Definition, dass die Ressourcen bis zum Taskenddatum einen gegeben Aufwand pro Zeiteinheit zu leisten haben. Jeder time-driven Task kann aber einfach in einen effort-driven Task umgewandelt werden.

Im Folgenden betrachten wir somit ausschliesslich Fälle von effort-driven Tasks, die gerade in Ausführung sind, d.h. deren Startdatum nicht in der Zukunft und deren Enddatum nicht in der Vergangenheit liegen.

Fortschrittsbeurteilung bei fehlenden Ist-Aufwände

Schauen wir uns einen effort-driven Task an, bei dem keine Ist-Aufwände erfasst werden.

Beispiel: In der folgenden Illustration ist die Ressource «Paul Müller» mit einem Aufwand von 44h auf dem Task alloziert. Es ist ersichtlich, dass die provisorischen Aufwände (hellgrün) genau den in der Vergangenheit allozierten Aufwänden entsprechen. 

Nun nehmen wir eine Neueinschätzung vor und legen den Fortschritt manuell auf 20% fest. Bei einer Neueinschätzung kann zwischen «Fortschritt» (in Prozent) und «Ausstehend» (Aufwand in der gewählten Einheit) gewählt werden. Zu beachten ist aber, dass unabhängig von der gewählten Option stets der ausstehende Aufwand gespeichert wird. Ein erfasster Fortschritt wird also in ausstehenden Aufwand umgerechnet und so abgespeichert. Mit einer Neueinschätzung kann zudem ein (nicht in der Zukunft liegendes) Stichdatum gewählt werden, für welches die Neueinschätzung gilt, sowie ein Kommentar erfasst werden. Pro Stichdatum können beliebig viele Neueinschätzungen vorgenommen werden, wobei pro Stichdatum immer die zuletzt erfasste effektiv gilt. Die Liste der pro Datum jeweils gültigen Neueinschätzungen ist in der Seitenansicht als Historie ersichtlich, chronologisch von oben nach unten  geordnet. Pro Datum werden die erfassten Neueinschätzungen in einem Tooltip dargestellt. Jeweils die letzte erfasste Neueinschätzung pro Stichdatum kann per Drag&Drop auf den Abfalleimer wieder gelöscht werden.

Beispiel (Fortsetzung): In der folgenden Illustration ist das Ergebnis dargestellt, welches sich nach der Erfassung einer Neueinschätzung von 20% Fortschritt ergibt.

Fortschrittsbeurteilung mit erfassten Ist-Aufwände

Wir schauen uns nun an, was passiert, wenn von den allozierten Ressourcen Ist-Aufwände auf dem Task erfasst werden. Die erfassten Neueinschätzungen werden dadurch natürlich nicht verändert. Da diese aber stets in Form von ausstehenden Aufwänden gespeichert sind (und nicht als Fortschritt), führt die Erfassung von Ist-Aufwänden zu einer automatischen Neuberechnung des Fortschritts.