Demo Access

Best Practices

If you are new to the basic concepts of Octaved Flow, it's best to read them first.

PID structuring considerations

This article contains thoughts and suggestions about the work breakdown, i.e. the repeated breakdown into task packages. Octaved Flow adapts to your way of working, so there are only a few requirements for dividing it into work packages. Perhaps the basic considerations in this article are still helpful for your decisions. 
A simple example from IT, where the project is the delivery of new PCs:
This structuring contains two levels. "2021" is the project and below that are the three work packages. As a larger example, let's take a machine builder who, as a project, adapts a machine from his product line to a customer's requirements.
In the example, the acquisition is divided into pure sales. Because technical preliminary work is necessary, the sales team takes development engineers on board. The advantage is that the development engineers have their separate platform for the exchange of information (the sales people can view the stand if it is relevant to them). The time of the development engineers is also booked separately, so that reliable statements can be made over a year about the degree to which the development engineers are involved in the sales process. 
In this example, the structuring has three levels.  
In Octaved Flow, the top level is called "Master PID". The customer is selected at the level of the master PID and the customer is then firm for all further subdivisions. Note: The customer can also be "internal". Time controls are also carried out at the master PID level. Timing is useful when projects are for a fixed period, such as maintenance over a month. Deadlines can be set at all levels. The deadline at the master PID level is the keystone, so to speak.    
The lowest level is called “Leaf PID” in Octaved Flow. The name "leaf" comes from the fact that there are no further branches in a tree in nature from one leaf. At the sheet PID level, information exchange and time recording take place in Octaved Flow.  
The middle level enables the work packages (sheet PIDs) to be grouped. How many such grouping levels are necessary depends on various factors. If the number of leaf PIDs is too high, a grouping level creates a better overview. Authorizations can also be assigned at the grouping level. It can therefore make sense to include a grouping level in order to be able to assign authorizations more easily.  
The trick behind this type of structuring is that there is no compulsion to move in one grouping level and there can even be several nested grouping levels. In the first example there is no grouping level, in the second there is one. And that can also be mixed as required. Per department, per project type and even within a project.  
If the development engineers were not involved in the second example, the split of the acquisition into "sales" and "technical advance services" could be omitted. Then "acquisition" would be the leaf PID.  
So what is the "optimal number of levels"? There can and should not be a blanket answer.
  • A guideline could be that a leaf PID contains a working time of 1-5 or maybe 1-10 days. In addition, planning and analysis could become too imprecise. More days often mean more complexity.
  • A leaf PID should neither be too big nor too small.
  • Too large means that the control becomes more difficult, too small means too much administrative effort or too many questions "where should I post my contribution?"
  • It is important that the structure is self-explanatory so that there are as few questions as possible. To be self-explanatory, the structure must be clear. Everyone must immediately understand where something belongs.
  • If there are more than 20 leaf PIDs, it becomes too confusing and it can make sense to group the leaf PIDs. A group that contains only one leaf PID is usually not useful.
  • Evaluability plays an equally important role. To see the sum of the PIDs within a group, simply click on the group.
  • Three levels are well suited for many applications: Master PID > Group > Leaf PID.
  • For contingents, especially for maintenance and support, times of 30 or 50 days on a leaf PID can also be useful.
There is also no need to look for a “forever” solution at the beginning. The structure can be changed at any time. If it turned out that the handling of one project wasn't perfect, you do it differently for the next project. In Octaved Flow there is no need to reprogram, no one has to reconfigure anything, and you can just "do". 
Note: Teams can still assign tasks under the leaf PID for self-administration. So the tasks are one level below the sheet PID. 
In computer science, this type of structuring is called "tree". The tree structure is not a new invention, but has long been used successfully in many areas. Let's take a look at the visualization of trees
A tree as you know it. The root is at the bottom, the branches branch at the top.
This representation is known for example from the folders of a network drive. The root is up here. Branches are to the right (or right and down). In this example, contracts are divided into two large customers "Buyer AG" and "Mein Kunde AG" and others.
This tree structure is known as an organization chart. The root, so "the whole" is up here again. The breakdown is downwards.
As you can see, all three are the same. The presentation is just different. 
At Octaved Flow, we usually use version 2 for the PIDs, because this is the best way to read and overview. 
The concept of work breakdown may sound complicated to some, but in practice it is almost never. If you know the organization in your own company well enough, this structure almost always arises naturally. You may already be working - specifically or indirectly - according to such a structure. With Octaved Flow you always have this in mind and can benefit from the advantages of the structured approach in several ways. 
And if you use just one level (i.e. master PID = leaf PID), then you have the basic concept that some collaboration tools known as "space".

Consistent time recording - yes or no

Octaved Flow includes project time tracking. Since it is not a time record, every employee does not necessarily have to record the time. Which internal rules make sense from practical experience? 
Anyone who works in consulting and is paid via a commission model naturally has a high (own) interest in a time recording that is as consistent as possible. What happens if a quota of further training per month has been agreed between the manager and the employee? It is then advisable to create a PID for the further training so that an evaluation is possible. In the same way, PIDs could also be created for other internal activities. On the one hand, there is an option for evaluation, on the other hand, continuous time recording is easy to use and ultimately even more pleasant for the employees. 
As a second example, let's take an employee who issues spare parts. Even if there is a repair order behind every spare part issue and even if there are PIDs for repairs, assigning each spare part issue to an order could be disproportionate to the effort. Such an employee would then not record his time, he would fall under the general costs. However, if the employee also undertakes repairs himself, it would be a different situation. The employee would book for the respective PID for the repair and to have a continuous time recording, for example, a PID "General Goods Issue" could be created. Corresponding evaluations are possible and an overload or underutilization of the employee can be recognized early. 
With continuous time recording, project time recording can also be used indirectly as working time recording. If it takes 15 minutes from entering the company premises to booting up the computer, employees and management could agree on a time recording requirement of 7.5 hours on an 8-hour day. 
Conclusion: For successful use of Octaved Flow, it is not necessary that all employees continuously record the times. From practical experience, it is more pleasant for employees who record their time if they can do this consistently. For example, quarterly PIDs are created for internal activities.

Request revision of board contributions

A very useful feature of the board is that new versions of a post can be created. If a contribution is out of date or if information needs to be added, the contribution will be revised. Old versions are always available. 
It can happen that you stumble across a contribution, but do not want to revise it yourself, but would like to ask someone else, for example the original author. What are the options?
Yellow note
  • Yellow notes can be attached to each board contribution. If the yellow note is too long, it is not the right way. Yellow notes are an indication, not a communication.
Ask a question with the board element "Question"
  • Questions are meant more as a question in the group, as "Who can tell me something about X?" and less than "Could someone revise the contribution?". The latter is actually a prompt, just politely packed into a question. If you want to keep the board clear, this would not be the first choice.
Assign a task
  • Putting a task in PID is certainly a good way. Longer notes on what needs to be revised can be written in the comment of the task. Tasks also have a clear assignment of who should take care of them. That usually leaves the change request not very long at one spot. The person in charge of the task can still pass it on to someone else or someone else takes the task
Revise yourself
  • A new version is always based on the previous one, so that a revision - at least from a technical point of view - can be done quickly. Since “only” a new version is created, the original author can, for example, straighten the whole thing out again in a final version.

Widespread use of Octaved Flow

It is obvious that Octaved Flow is a tool primarily for teams. Do I have to introduce Octaved Flow “across the board” in my company, that is, for all potential users?
Octaved Flow is also useful for small work groups within companies and increases productivity there. And of course, Octaved Flow also increases efficiency in smaller companies as well.
Ideally, everyone working in a team should also use Octaved Flow as a team. Then Octaved Flow can really increase the flow. If some end up in a team from Octaved Flow and increasingly use conventional tools such as e-mail, this disrupts the processes well organized with Octaved Flow and thus the flow of others.
The conclusion is that Octaved Flow can be used sensibly by a single team right up to "widespread". In the expansion stages in between, however, it should always be complete teams. So team 1 team 2 team 5. But not team 1 team 2 some of team 5. Exceptions confirm the rule. This is only a guide for planning the use of Octaved Flow.


Choose your language