Glossar, verwendete Begriffe und ihre Bedeutung

Die in Octaved Flow verwendeten Begriffe orientieren sich an dem, was im Projektmanagement üblich ist. Damit finden sich erfahrene Projektmanager zurecht, ohne umdenken zu müssen. Es gibt einige Besonderheiten, die in diesem Tutorial anschaulich erläutert werden. Zusätzlich ergibt sich beim Lesen ein gutes Bild über Funktionen von Octaved Flow und wie sie ineinandergreifen.

Projektmanager und Ausführende sind die beiden Kategorien, in die in Octaved Flow Projektbeteiligte eingeteilt werden. Projektmanager managen Projekte, legen also beispielsweise Arbeitspakete zu einem Projekt an und planen den Projektablauf. Ausführende setzen die ihnen vom Projektmanager zugewiesenen Arbeitspakete um.

Die Begriffe sind hierbei nicht fest, ein Teamleiter kann genauso die Funktion haben, die in Octaved Flow als Projektmanager bezeichnet wird.

Der Begriff Projekt ist in Octaved Flow weit gefasst. Jede Art von Vorhaben kann als Projekt aufgefasst werden. Es ist heute auch durchaus üblich einen Auftrag, der Dienstleistungen beinhaltet, als Projekt zu bezeichnen.

In Octaved Flow werden Projekte in Arbeitspakete unterteilt. Man könnte es also auch so ausdrücken, dass alles was sich in Arbeitspakete unterteilen lässt, ein Projekt ist.

Arbeitspakete können in Teilprojekten zusammengefasst werden. Die Hierarchie ist damit:

Zu jedem Arbeitspaket können Aufgaben erstellt werden. Damit wird das Arbeitspaket weiter aufgeteilt. Das Anlegen von Aufgaben ist optional.

In größeren Unternehmen und Organisationen werden häufig Projektordner eingesetzt. Projekte werden in die Projektordner einsortiert und alles wird übersichtlicher. Die Hierarchie ist in Summe:

An vielen Stellen in Octaved Flow werden Projekte, Teilprojekte und Arbeitspakete angezeigt, jeweils zum Ausklappen. Man kann beispielsweise ein Projekt ausklappen und es werden alle enthaltenen Teilprojekte angezeigt. Der Begriff kommt in der Software nicht vor, aber viele nennen diese Darstellung Projektbaum. Vielleicht wollen Sie den Begriff auch verwenden, wenn Sie darüber sprechen.

Arbeitspakete haben in Octaved Flow einen Status. Der Status ist zum Beispiel „Offen“ oder „Gesperrt" für Abrechnung. Der Status steuert, ob man auf ein Arbeitspaket Zeit buchen kann und wie das Arbeitspaket angezeigt wird. Im Workspace der Ausführenden werden Arbeitspakete nur angezeigt, wenn sie offen sind, man also Projektarbeitszeiten darauf buchen kann. Der Status wird vom Projektmanager gesetzt.

Ob ein Arbeitspaket erledigt ist, wird nicht über den Status festgelegt. Ausführende markieren ein Arbeitspaket als erledigt, wenn sie damit fertig sind und signalisieren dies damit dem Projektmanager. Das Kennzeichen als erledigt markiert kann auch jederzeit wieder rückgängig gemacht werden.

Diese beiden Begriffe werden häufig verwechselt und selbst erfahrenere Projektmanager greifen schon einmal daneben.

Die geplante Arbeitszeit für ein Arbeitspaket wird als Aufwand bezeichnet. Der Aufwand ist also die Anzahl an Arbeitsstunden, die für die Erledigung des Arbeitspakets laut Plan benötigt wird.

Die Dauer ist die Anzahl an Tagen, innerhalb derer laut Plan das Arbeitspaket zu erledigen ist.

Nehmen wir beispielsweise an, dass für die Umsetzung eines Arbeitspakets 2 Tage entsprechend 16 Stunden Arbeitszeit geplant sind. Die Umsetzung soll in der Zeit von Montag bis Freitag erfolgen. Dann ist der Aufwand 2 Tage (16 Stunden) und die Dauer 5 Tage.

Wenn die Dauer größer ist als der Aufwand, wird davon ausgegangen, dass der Ausführende das Arbeitspaket nicht an einem Stück umsetzt, sondern es Unterbrechungen geben wird. Ist die Dauer geringer als der Aufwand, müssen mehrere Ausführende das Arbeitspaket umsetzen, um im Plan zu bleiben.

Im Englischen ist die Verwechslungsgefahr zwischen den Begriffen Aufwand und Dauer geringer: Aufwand ist effort und Dauer ist duration. Das wirkt klarer und eindeutiger. In Octaved Flow wird immer durch den Kontext klar, ob Aufwand oder Dauer gemeint sind. Sie müssen sich also den Unterschied der beiden Begriffe nicht merken, um mit Octaved Flow arbeiten zu können.

Aus dem geplanten Datum für den Beginn eines Arbeitspakets und dem Ende ergibt sich der Zeitraum. Der Zusammenhang zwischen Zeitraum und Dauer ist offensichtlich. In Octaved Flow kann man das Enddatum oder die Dauer eingeben und der jeweils andere Wert wird berechnet.

Der Aufwand ist die für die Umsetzung geplante Arbeitszeit. Wenn Sie Projektarbeitszeiten buchen, dann finden Sie über die gebuchte Zeit heraus, wie lange es wirklich gedauert hat (Sehen Sie, wie leicht man die Begriffe verwechselt? Es müsste genau genommen heißen „wie groß der Aufwand wirklich war“). Der Aufwand ist also die Planung oder anders gesagt die Zukunft. Die gebuchte Zeit eines fertig umgesetzten Arbeitspakets ist die Realität, und zwar rückblickend.

Zu jedem Arbeitspaket können Aufgaben erstellt werden. Aufgaben können für die Detailplanung eines Arbeitspaket durch den Ausführenden verwendet werden oder als Checkliste dienen. Es gibt einige Szenarien, in denen es sinnvoll ist auch den Aufwand von Aufgaben einzeln zu ermitteln oder abzuschätzen. Der Aufwand von Aufgaben, also die zur Umsetzung laut Annahme benötigte Zeit, wird in Octaved Flow Aufgabenzeit genannt. Eigentlich müsste es Aufgabenaufwand heißen, aber durch den gewählten Begriff werden Verwechslungen vermieden. Auch Aufgaben können einen Zeitraum haben und damit eine Dauer, wenn sie geplant werden.

Mit Octaved Flow können agile, klassische und hybride Vorgehensweisen abgebildet werden. Die Terminologie und die Funktionen sind an die im agilen Bereich übliche Terminologie angepasst, wenn auf agil umgestellt wird.

Arbeitspakete bilden die Grundlagen für User Stories. Wenn Sie auf agile Methodik umschalten, was Sie übrigens auch innerhalb eins Projekts in gemischter Form können, dann legen Sie keine Arbeitspakete, sondern User Stories an. Die Funktionen von Arbeitspaketen, wie beispielsweise Aufgabenmanagement, Boards oder Projektzeiterfassung, können Sie genau so nutzen, wenn es User Stories sind.

Arbeitspakete können in Teilprojekte zusammengefasst werden. Teilprojekte bilden die Grundlage für Backlogs. Sie schalten den Typ eines Teilprojekts einfach zum Backlog um, und die Arbeitspakete werden zu User Stories.

Sprints sind ein weiterer Typ von Teilprojekten. Sie verschieben eine User Story einfach in einen Sprint und planen damit den Sprint inhaltlich.

Hinweis: Bei Teilprojekten ergibt sich die Planung durch die enthaltenen Arbeitspakete. Der Beginn des ersten Arbeitspakets bestimmt den Beginn des Teilprojekts, das Ende des letzten Arbeitspakets das Ende des Teilprojekts. Wird das Teilprojekt zum Sprint, gibt es ein Beginn- und Enddatum des Sprints. Die User Stories haben keine eigene Planung, sie sind im Sprint enthalten.

Auf Projekt-, Teilprojekt- und Arbeitspaketebene steht jeweils ein Board zur Verfügung, in dem Informationen ausgetauscht, Besprechungsberichte abgelegt, Dateien hochgeladen oder Fragen gestellt werden können.

Kanban-Boards sind so realisiert, wie allgemein und insbesondere bei agilen Vorgehensweisen üblich. Die Spalten des Kanban-Boards heißen wie üblich Swimlanes, weil sie an Bahnen eines Schwimmbads erinnern. Die Einträge im Kanban-Board können von einer Swimlane auf eine andere mit der Maus gezogen werden. Dadurch wird ein Label entfernt und ein anderes hinzugefügt. Kanban-Boards eigenen sich unter anderem gut, wenn es darum geht Prioritäten für Arbeitspakete festzulegen.

Über Berechtigungsrollen wird festgelegt, was ein Benutzer darf. Mit der Berechtigungsrolle Leser darf man zum Beispiel Projekte und Arbeitspakete nur sehen, aber nichts verändern. Als (Projekt-) Manager darf man sehr viel mehr, wie zum Beispiel Projekte anlegen, Arbeitspakete anlegen oder die Zeitvorgabe eines Arbeitspakets erhöhen (normalerweise, wenn dies mit dem Kunden so abgestimmt wurde).

Projektrollen legen fest, welche Funktion oder Rolle man im Projekt hat. Projektrollen sind beispielsweise Ausführender, für jemanden der ein Arbeitspaket umsetzt, oder Projektmanager. Ist Berechtigungsrolle und Projektrolle dann nicht dasselbe?

Keineswegs. Es ist ein denkbares und sinnvolles Szenario für mehrere Projekte die Berechtigungsrolle eines (Projekt-) Managers zu haben. So kann ein Projektmanager-Kollege im Urlaub vertreten werden, ohne dass das Berechtigungskonzept jeweils angepasst werden muss. Die Projektrolle zeigt die Verantwortlichkeit nach außen. Wenn andere sehen, dass ich die Projektrolle Projektmanager für ein Projekt habe, wissen sie, dass sie mich bei Fragen zu diesem Projekt ansprechen können.

Die Situation, dass ein Benutzer für ein Projekt zwar die Verantwortlichkeit hat, aber nicht die Berechtigung, um die Verantwortung auch auszufüllen, wird in Octaved Flow über das sogenannte Rechte-Upgrade gelöst. Hat man weniger Berechtigung als Verantwortung, erhält man automatisch das passende Upgrade.

Jeder Knoten im Projektbaum erhält eine eigene, eindeutige Projekt-ID, kurz PID. Jeder Knoten bedeutet, dass jedes Projekt, jedes Teilprojekt und jedes Arbeitspaket eine jeweils eigene PID haben.

Damit sie kurz und handlich bleibt, besteht die PID aus Zahlen und Buchstaben. Leicht zu verwechselnde Zeichen gibt es nicht, wie zum Beispiel 0 (Null) und O (Buchstabe „Oh“). Eine PID ist beispielsweise: A4M

Die PID kann bei der Anbindung an ein ERP-System nützlich sein oder wenn viele Arbeitspakete ähnliche Namen haben und man sich darüber unterhalten möchte. Die PID wird in der Detailsansicht unter dem Reiter Technisch angezeigt. In vielen Suchfeldern kann nach der PID gesucht werden.