In Team Planning, the imputed workload of team members is displayed as a bar.
The workload can be used for capacity planning, among other things. In this tutorial, which is intended more for advanced users, the calculation method for the load bars is disclosed and explained. It also discusses how the accuracy can be positively influenced.
Calculation for a performer
For example, let's assume that a work package has an effort of 20 hours, the realization period is one week, from Monday to Friday, and that a person with a 40-hour week is the executor responsible for the implementation.
Octaved Flow uses equal distribution to calculate the performer's workload. Thus, for the calculation it is assumed that the executor will work the same number of hours on the work package from Monday to Friday, i.e. 4 hours per day in the example. Expressed as a formula, the effort is divided by the days of the realization period (duration) to determine the workload per day.
Compensation of different distribution
It is conceivable that the performer will not work so evenly on the work package in the day-to-day project. Maybe the executor prepares more on Mondays than being really active, works almost full time on the work package on Tuesdays and Wednesdays, and does remaining work on Thursdays and Fridays. The distribution would then be like this:
Of course, this is not taken into account in a uniform distribution. But it could also be that the executor has to wait for something due to external factors and the focus shifts backwards. Or he does most of the work at the beginning of the week to quickly "get a hook on it". What distribution will take place cannot be readily predicted.
Therefore, it is assumed that an uneven distribution within the week will even out in some way along with other work packages. On average, the equal distribution is a good model.
Calculation for multiple performers
If multiple team members are assigned to the work package as performers, the effort is analogously divided by the number of performers. In the example, the effort of 20 hours is divided by 5 days, resulting in a daily workload of 4 hours for one performer. With 2 performers, each has an imputed workload of 2 hours per day.
Again, it is assumed that unequal distributions between executors are balanced over the total consideration.
Influence of project role types
Only project roles of the type Executor are taken into account when calculating the workload. Only those who have a project role of the type Executor are assigned to implement the work package and thus have the workload. Someone who is involved in the work package with a project role of the type Project Manager does not count for the calculation, nor does someone who is supposed to support an inexperienced colleague and therefore has a project role of the type Supporting.
Good to know
Project managers tend to post to separate work packages for project management.
Octaved Flow provides another way to greatly improve accuracy and also map uneven distributions, as shown in the chart above.
Workload based on task time
One of the basic organizational ideas in Octaved Flow is that a distinction is made between project managers and executors, but both have responsibilities for the project flow.
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.
The subdivision into manageable tasks with time intervals such as 15 minutes, 1 hour, 2 hours and half a day, which are kept rather small in terms of the respective effort, has proven itself in practice.
This approach is by no means a must, but it has many advantages. If the performers create tasks with an estimated workload, they have better control over their own activities, and in project controlling, analyses and forecasts become much more accurate.
For the calculation of workload and thus capacity planning, the advantages of task time are obvious. An uneven distribution of the workload within a work package is automatically taken into account, of course as shown in the chart above.
The distribution is done by the executor himself, who firstly can judge this better in the daily business anyway and secondly thus relieves the project manager. The forecast becomes sufficiently accurate if the executor uses the time intervals specified above for the tasks.
Task time and effort of the work package
Ideally, the effort of the work package specified by the project manager matches the sum of task times estimated by the executor. So, if the work package from the example has an effort of 20 hours and the executor estimates 8 tasks at 2 hours each, 3 tasks at one hour, and 4 tasks at 15 minutes each, then the workload calculation is clear.
However, work packages are often scheduled with some reserve or offered to a customer. For example, the total task time could be 18 out of the 20 possible hours in the work package. What then happens to this reserve of 2 hours? These two hours are then distributed according to the same scheme as described above.
The same applies if not all tasks are assigned task time. The time not included in task time is considered like the reserve and distributed equally. Octaved Flow behaves in the best possible way in all cases, even if not all data is complete. Of course, the calculation is more accurate when more data is available.
The third possible case is that the task time is greater than the work package effort. This is usually a rather unpleasant case, which certainly requires further steps. Nevertheless, a workload should be calculated even in this case. Octaved Flow then uses only the task time. It stands to reason that the statement of the performer while he is busy with the subject is a better starting point for the calculation. In other words, there is no reserve here to distribute.
If a person is assigned to a task, the "higher sticks" principle applies and this assignment is counted as higher than the assignment in the work package. The same applies if multiple people are assigned to a task.
Good to know
It is technically possible to assign multiple people to a task, but organizationally it is usually rather inconvenient.
If there is no assignment of people to a task, Octaved Flow assumes that this task is done by the executors of the work package.
Note: When multiple performers are assigned to a work package, the accuracy of the calculation is improved by having tasks assigned to only one of the performers. This also provides more clarity as to who in this team of performers will do exactly what task.
Planning of tasks
For tasks, the realization period can also be independent of the effort. If the performer schedules 15 minutes for a task and plans it over two days, then they will implement the task on one of the two days, they just don't know which one yet. For calculation purposes, 7.5 minutes per day is used.
Workload indicator bar
The workload bar shows the sum of all work packages. In the example above, only one work package was assumed at a time, but usually executors have several work packages in parallel or at least overlapping.
The daily working time of the user is taken into account to indicate an overload. The upper bar indicates the daily working time. Anything over this top bar turns orange.
Octaved Flow works on a daily basis to calculate and display workload.
No time limit
- For work packages without a time limit, statements can only be made about the task time, and even here, only as far as specified.
- If the work package has no time limit and no task time is specified, no statement is possible, it has no influence on the calculation.
- If the work package has no planning with start and end date, but the tasks are planned, only the tasks with task time are used in the calculation.
- If the work package has a start and end date, but the tasks are not scheduled, the start and end of the work package will be used for the tasks in the calculation.
Time bookings are not taken into account, because they have too little significance for determining the remaining effort. For example, if 80% of the time is used up in a work package, this does not necessarily mean that 80% of the work package has been completed.
If more precise statements are desired, for example the more exact utilization of supporting project roles, then the division of the work packages is a good first approach to achieve this.
At the end of this rather long tutorial, you see that Octaved Flow behaves as it should. Complete transparency about the algorithm used in Octaved Flow is important because you rely on the utilization bars and their calculation basis for your capacity planning.
Because the world isn't perfect, it's good to know that Octaved Flow is doing the best it can with the data at hand, even if not all project stakeholders are tracking their data optimally.