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.
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.
Info
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:
Schedule work packages with fixed start and end dates.
In Octaved Flow, work packages are primarily planned. 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 set the start and end date of a work package in the calendar. Additionally, one can change the duration of a work package, starting from the previously set start date.
Moving, lengthening and shortening bars with the mouse changes the dates of the planning and the duration of the work package accordingly.
Bracket for projects and sub-projects, due dates.
In the menu item Project planning, 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.
You can specify a due date for a project. The due date is the date by which the last work package should be completed. Specifying a due date is optional. The due date is displayed as a hash. If the planning of a work package exceeds the due date set for the project, the bar of the work package displays a red flame.
Work package bars display a flame even if they are not completed before the work package's scheduled end date.
Tasks are displayed like work packages and get red flames if they pass a due date are not completed before the scheduled end date of the task or work package.
sub-projects of work packages work analogously to projects. The first work package determines the beginning, the last the end of the sub-project. A sub-project can also have a due date.
A simple project plan then looks like this:
Dependencies
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.
There are basically two ways to define dependencies. One is in the detail view and the other is via drag & drop in the project planning.
To do this, starting from the work package that should be dependent, drag the connection to another work package.
The order of the dependencies is defined by the sorting of the work packages in the project planning.
Sorting can be done by project order or start date. If a dependency is created by drag and drop in the Gantt chart, the parent work package is the predecessor. In the detail view, the dependency is always displayed in the work package that is dependent on another.
In the literature, this work package is often called "predecessor". Because this designation is misleading, for example, when 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-beginning.
The dependent work package is moved along when the work package it depends on ("predecessor") is moved.
In an end-start relationship, the start 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 due dates. 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. Problems are immediately visible through the red flame on the bar.
Effects of planning on the workspace
"My Workspace" is the central point for executors. Under the "My tasks" menu items, the executor is shown work packages and tasks that are either assigned to them as an executor or added to their favorites. In "My calendar", the performer only sees the planned work packages and tasks for today.
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, sub-projects 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
Info
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.
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 with a red flame.
Coloring
The bars of the work packages and tasks in the project and team planning can be displayed with different colors. In this case, the corresponding work package or task adopts the selected color of the project or, if a separate color has been defined for a sub-project, the color of the sub-project.
The colors are selected in the dialog box when a project or sub-project is created and can be changed later in the detail view.
Finally
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.
