We continue with the administration waste from the last blog post, and the last in line is Project Administration waste.
In this category we have general coordination, replanning, hand-overs, project meetings, retrospectives, reports, time planning, big room planning, coordination between different hierarchy project levels, etc. A common figure for Project Administration waste is about 20% (the exact figure is not important), but depends on the context of the task that the employee has.
But, it is a big difference compared to Line Administration waste, since the more projects an employee work with, the more Project Administration waste. So, one project look like this.
But, for an employee working in two projects, it looks like this.
And the 20% figure is not constant either, it increases for every project that is added, due to scheduling time between projects, mental set-up time for changing project, loss of control, etc. Having more than two projects to handle, is not only a big visible waste as in above picture, but also extremely stressful for the employee, where the latter is an invisible waste, since it can lead to a burned-out employee. But, once again it depends on what the employee’s task is, and somtimes we need specialistsf for some tasks. The more routinized the work is, the more projects can be handled, and here it can be appropriate with a Mean queue, that of course must have over capacity. Without over capacity, the projects will be delayed, but worse is that there is once again risk for a burned-out employee due to stressful work.
The picture below was shown in an earlier blog post, and characterises what happens with the Project Administration waste when a company grows. But, what we could not see in the picture was that from beginning we had seven full time resources, but on the lower one to cover all work, we need in total 8,2 full time resource equivalents (twelve 60% Resources + the project manager), which means that 1,2 persons (20% waste) are pure Project Administration waste, because now we use only part time resources. And then we have not taken into account that more people make it harder to collaborate. Not to mention the other projects that get only 40% Resources, which then only work 20% effective time.
And because the broad competence probably still exists among the employee, the upper part is still possible to achieve, but the Line organisation puts a constraint that makes it impossible. The constraint makes the employees’ competence sadly enough to be narrowed, niched, over time. But the project manager’s manager only wants the project to be successful, meaning that the project manager will most probably get broader competence, at the same pace as the employees’ competence are narrowed.
Here we have a clear example on a wheel of curse, where the sub-optimizations will lead to the following (death) spiral. The manager is short of resources. Why? Resources have been cut. Why? It looked like we were expensive. Why? The manager only had 95% resource utilization over a long time. Cutting resources in this situations, is a very common action in silo organizations with projects, but since the last statement, like all earlier statements in the chain also is a symptom, we need to continue to ask “why?”. If we ask “why?” one more time, one of the answers for big organizations will be that the competence was wrong, which is exactly what happens when we narrow the I-competences too much. And when we are having to narrow competence, we per se also have Project Administration waste, at least in the cases where big organizations make small initiatives. This means that cutting resources is a clear sub-optimization that will not lead to 100% resource utilization, we will still only have 95% resource utilization, but this time the manager for sure are even more short of resources.
If the manager is successful filling up to 100%, we will not understand that we have Project Administration waste. And the manager will most probably try this out, since there often is a KPI on the manager to have 100% resource utilization, i.e., resource “efficiency”, since the thinking is that that makes an organization efficient. As we understand we will, when not solving our problems, be totally blind for any waste and instead think that we are very efficient.
Note! There is two different cases here. The first one is when a big silo organization with projects tries to do small initiatives, which means that we have the needed knowledge within our employees, but our employees need to be more T-shaped, i.e., aggregate knowledge from others to their current knowledge and in this way get broader competence. The other case is when new knowledge that no employee have is needed, for example interdisciplinary and transdisciplinary knowledge when making, for example when making a new systems design, which means iterations of the systems design, within a team of experts and generalists in order to achieve the new knowledge, which not can be aggregated, since no one have it yet. The latter is the strength of Lean Product Development, making for example future-proof platforms.
In tomorrow’s blog post, we will, after these preparing blog posts, start examine the tight connection between resource and flow efficiency.