Glossary, terms used and their meaning

The terms used in Octaved Flow are based on what is common in project management. Experienced project managers will find their way around without having to rethink. There are some special features that are explained clearly in this tutorial. In addition, reading this tutorial will give you a good picture of Octaved Flow's features and how they interact with each other.

Project Manager and Executor are the two categories into which project participants are divided in Octaved Flow. Project managers manage projects, e.g. create work packages for a project and plan the project flow. Executors implement the work packages assigned to them by the project manager.

The terms are not fixed here, a team leader can also have the function that is referred to as a project manager in Octaved Flow.

The term project is broadly defined in Octaved Flow. Any kind of undertaking can be considered 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 you could also put it that everything that can be divided into work packages is a project.

Work packages can be combined into sub-projects. The hierarchy is thus:

Tasks can be created for each work package. This further divides the work package. The creation of tasks is optional.

In larger companies and organizations, project folders are often used. Projects are sorted into the project folders and everything becomes clearer. The hierarchy is in sum:

In many places in Octaved Flow, projects, sub-projects and work packages are displayed, each to be expanded. For example, you can expand a project and all the sub-projects it contains will be displayed. The term does not appear in the software, but many call this display Project Tree. You may also want to use the term when talking about.

Projects, sub-projects and work packages are displayed in many places in Octaved Flow, each of which can be expanded. For example, you can expand a project and all the sub-projects it contains are displayed. The term does not appear in the software, but many call this display project tree. You may also want to use the term when talking about it.

Whether a work package is done is not determined by the status. Executors mark a work package as completed when they are finished with it and thus signal this to the project manager. The marked as done indicator can be undone at any time as long as the status allows it.

These two terms are often confused and even more experienced project managers sometimes make mistakes.

The planned work time for a work package is called effort. Effort is therefore the number of working hours required to complete the work package according to the plan.

The duration is the number of days within which, according to the plan, the work package is to be completed.

For example, let's assume that 2 days are planned for the implementation of a work package, corresponding to 16 hours of work time. The implementation is to take place in the period from Monday to Friday. Then the effort is 2 days (16 hours) and the duration is 5 days.

If the duration is greater than the effort, it is assumed that the performer will not implement the work package in one piece, but there will be interruptions. If the duration is less than the effort, several performers must implement the work package to stay on schedule.

In English, there is less confusion between the terms effort and duration: effort is effort and duration is duration. This seems clearer and more unambiguous. In Octaved Flow, the context always makes it clear whether effort or duration is meant. So you don't need to remember the difference between the two terms to work with Octaved Flow.

From the planned date for the start of a work package and the end results the period. The relationship between time period and duration is obvious. In Octaved Flow, you can enter the end date or the duration and the other value will be calculated.

Effort is the work time planned for implementation. When you post project work hours, you find out how long it really took by posted time (See how easy it is to confuse the terms? It should be strictly speaking "how much effort it really took"). So the effort is the planning, or in other words, the future. The posted time of a completed work package is the reality, looking back.

Tasks can be created for each work package. Tasks can be used for detailed planning of a work package by the executor or can serve as a checklist. There are some scenarios in which it is useful to also determine or estimate the effort of tasks individually. The effort of tasks, i.e. the time needed to implement them according to the assumption, is called task time in Octaved Flow. Actually it should be called task effort, but the chosen term avoids confusion. Tasks can also have a time period and thus a duration if they are planned.

Octaved Flow can be used to map agile, classic and hybrid approaches. The terminology and functions are adapted to the terminology commonly used in the agile area when switching to agile.

Work packages form the basis for User Stories. If you switch to agile methodology, which you can also do within a project in mixed form, then you do not create work packages, but user stories. You can use the functions of work packages, such as task management, boards or project time recording, in exactly the same way if they are User Stories.

Work packages can be grouped into sub-projects. Sub-projects form the basis for backlogs. You simply switch the type of a sub-project to backlog and the work packages become user stories.

Sprints are another type of sub-project. You simply move a user story into a sprint and thus plan the content of the sprint.

Note: The planning of sub-projects is determined by the work packages they contain. The start of the first work package determines the start of the sub-project, the end of the last work package determines the end of the sub-project. If the sub-project becomes a sprint, there is a start and end date for the sprint. The user stories do not have their own planning, they are included in the sprint.

For each work package there is a Board where information can be exchanged, meeting reports can be filed, files can be uploaded or questions can be asked.

Kanban boards are implemented in a way that is common practice, especially in agile approaches. As usual, the columns of the Kanban board are called swimlanes because they are reminiscent of lanes in a swimming pool. The entries on the Kanban board can be dragged from one swimlane to another using the mouse. This removes one label and adds another. Kanban boards are well suited to defining priorities for work packages, among other things.

Over authorization roles is specified, what a user may. With the authorization role reader you are only allowed to see projects and work packages, but you are not allowed to change anything. As a (project) manager, you are allowed to do much more, such as create projects, create work packages, or increase the time limit of a work package (usually if this has been agreed with the customer).

Project Roles define what function or role one has in the project. Project roles are for example Executor, for someone who implements a work package, or Project Manager. Isn't authorization role and project role the same thing then?

Not at all. It is a conceivable and reasonable scenario to have the authorization role of a (project) manager for multiple projects. This way, a project manager colleague can be substituted during vacation without having to adjust the authorization concept in each case. The project role shows the responsibility to the outside world. If others see that I have the project role Project Manager for a project, they know that they can contact me if they have questions about that project.

The situation where a user has the responsibility for a project, but not the authorization to also fill the responsibility, is solved in Octaved Flow via the so-called rights upgrade. If you have less authorization than responsibility, you automatically get the appropriate upgrade.

Each node in the project tree is assigned its own unique project ID, or PID for short. Each node means that each project, each sub-project and each work package has its own PID.

To keep it short and handy, the PID consists of numbers and letters. There are no easily confused ones, so there is no 0 (zero) and O (letter "Oh"). For example, a PID is: A4M

The PID can be useful when connecting to an ERP system or when many work packages have similar names and you want to talk about them. The PID is displayed under "Info". You can search for the PID in many search fields.