Project planning with Gantt, team planning, task planning

Tutorials and guides for the features of Octaved Flow

Project planning with Gantt is a classic and an indispensable part of project management.

Screenshot more complex Gantt planning

Because it is a well-known method, this tutorial will briefly review the basics, but focus on the specifics of Gantt charts in Octaved Flow. There are only a few specifics, and the learning curve is flat.

Organization with work packages and tasks

The term project is broadly defined in Octaved Flow. Any type of endeavor can be construed as a project. Today, it is also quite common to call an order that includes services a project.

In Octaved Flow projects are divided into work packages. So it could also be expressed that anything that can be divided into work packages is a project.

Work packages can be grouped into groups. The hierarchy is thus:

Short Hierarchy in Octaved Flow

Schedule work packages with fixed start and end dates.

In Octaved Flow, work packages are primarily scheduled. Work packages have a start and end date and are thus displayed as bars in the Gantt chart.

With the mouse, a work package can be moved as a whole, as well as extended or shortened on the left and right.

If you click on the bar, further information about the work package is displayed on the right. There you can alternatively enter the start and end date or select it from the calendar. You can enter either the end date or the duration and the other field will be calculated.

Screenshot Inspector

Moving, lengthening and shortening bars with the mouse changes the values in the three fields Start, End, Duration.

Bracket for projects and groups, milestones

In the Project Planning menu item, a gray bracket (bar) is displayed for the duration of the project. The project duration results from the work packages. The start of the project is the start of the earliest work package. The project end is equal to the end of the last work package.

Bracket for groups in Gantt planning

You can specify a milestone for a project. The milestone is the date by which the last work package should be completed. Specifying a milestone is optional. The milestone is displayed as a diamond. The colors of the milestone are:

  • Blue - Lies in the future.
  • Red - Lies in the past and not all work packages have been completed.
  • Green - Lies in the past and all work packages are completed.

Unfinished work packages that are past the milestone are displayed in red.

Work package after milestone

Groups of work packages work analogous to projects. The first work package determines the beginning, the last the end of the group. A group can also have a milestone.

A simple project plan then looks like this:

Simple Gantt chart


Up to this point, we have assumed that work packages each have a fixed start and end date. You can also define dependencies between work packages.

A dependency in Octaved Flow is always defined starting from the current work package to the work package on which the current one should depend.

In the literature this work package is often called "predecessor". Because this name is misleading, for example, if both work packages have the same beginning, Octaved Flow usually speaks of "dependencies". Who depends on whom is always clear from the context and is visualized in the Gantt chart by arrows.

Octaved Flow offers three variants for dependency:

  • Start after end of predecessor - The dependent work package starts after the end of the work package it depends on. In this case, it is referred to as the predecessor. This dependency is also called end-beginning.
  • Same end - Both work packages end on the same day. This dependency is also called end-end.
  • Common Start - Both work packages start on the same day. This dependency is also called start-start.
Types of dependencies

The dependent work package is also moved when the work package it depends on ("predecessor") is moved. In an end-start relationship, the start date of the dependent work package is always one working day after the end date of the work package on which it depends. So if work package A has Friday as its end date, the start date of work package B is Monday. The easiest way to remember the logic is to assume that the end date is 23:59 and the start date is 0:00.

In each of the dependency types, an offset can be specified in days. If the offset is 0, the behavior is as described above. The offset can be specified in plus or minus days. Variants that seem senseless are also allowed, including exceeding milestones. The software does not restrict the project manager with warning messages, which would be temporary in case of rescheduling and would only distract the user. It is assumed that the project manager knows what he is doing. Red colored bars and milestones make problems immediately visible.

Effects of planning on the workspace

In the workspace, executors always see the work packages for which today is in the work package's planning period. In addition, unplanned work packages and favorites (golden star) are displayed.

Executors therefore always see exactly what has been planned for them in their workspace.

Overlapping planning is often useful because there is still work to be done on a work package, but it does not fill the workday. Another work package can be started in parallel. Often many work packages are planned in parallel for an executor, because there are often delays in at least one work package and then no idle time should occur. Octaved Flow assumes this as a rule and it is left to the executor to organize the work accordingly in this case. The project manager typically provides the framework.

Team planning

The menu item Team Planning offers a different perspective of the same information base. In both menu items, Project Planning and Team Planning, work packages are displayed in the timeline. However, while in Project Planning the left pane is structured by projects, groups and work packages, in Project Planning the left pane shows the team members. So you can see at a glance which work packages the team members should work on and when.

This makes Team Planning a workspace simulator at the same time. Looking at a day from top to bottom, you can see which work packages a team member will have in the workspace that day.

Many project managers use team planning to check their planning and to see if team members are overloaded or still have free capacities. Extending bars in team planning, for example, is usually not a good way to go. For this purpose, it is better to switch to project planning, since the interrelationships of the project process are better visible there. However, planning work packages in team planning is possible and can also be useful depending on the context.

The imputed workload is displayed in team planning per team member as a bar per day. The workload can be used for capacity planning, among other things.

Task planning

Organization between project managers and executors

In the complexity of today's project world, it is impossible for the project manager to know all the details of all the work packages in a project. "Micro-management," or the oversight of even the smallest details by those responsible, has long ceased to be a sign of good team leadership, and rightly so.

Today, project managers provide the framework, but they are dependent on leaving the precise details to the executors. They are usually in a better position to judge the details.

In Octaved Flow, this working method is illustrated as follows: Project managers divide the project into work packages. These work packages are given an estimated or maximum effort by the project manager, are planned and assigned to performers.

The performers then divide a work package into tasks, which they create at the beginning of the implementation and which serve as a checklist at the end. Ideally, the performers give the tasks an estimated effort in the process and plan them.

The subdivision into manageable tasks, which tend to be kept small in terms of their respective effort, with time intervals such as 15 minutes, 1 hour, 2 hours and half a day has proven successful in practice.

The planning of tasks is done analogously to the planning of work packages. Tasks are also planned in the Project Planning menu item. Tasks are always assigned to a work package, so you unfold the work package to see and plan the tasks.

The same functions are available. In addition, there is the possibility to schedule the task in relation to the work package. For example, on day 2 of the work package or on the penultimate day of the work package. If the work package is moved, the task scheduling will be moved to match it in this case.

If the task is scheduled with absolute dates and the work package is postponed, the absolute schedules will remain. This can lead to tasks being outside the work package and thus becoming red.

The executor always moves within the planning of the work package. For example, if he plans a task after the end date of the work package, this task will be displayed in red.


In the default color, the work package is blue and the bar of the work package is also blue. If another color has been chosen for the work package, the bar will be displayed in this color.

It is advisable not to "reach too deeply into the color pot", otherwise the display in the Gantt chart will become confusing.

The colors red, green and gray are not available for selection. They have a different meaning, defined by Octaved Flow, depending on the context. For project planning, the three colors mean:

  • Red - Late, by end date or by milestone.
  • Green - Marked as done by executor or closed by project manager.
  • Gray - Cannot be started yet, status is "Not yet open."


As you can see, project planning with Gantt is intuitive and simple. If you don't have more experience with Gantt charts, it's best to play through a small test project with different scenarios first.

dot background image