We have already started with the small company that is growing as an example of what easily happens, and now we need to continue to elaborate on this, because it is the key to find the connection between Resource and Flow efficiency.
Here is the small company. The project and Line organisation are more or less the same.
And here is the bigger company.
Remember that the project organisation is a mirror of the Line organisation, meaning that projects will still need all I-competence, and therefore only getting part time resources, due to the area of responsibility for each manager. Don’t forget that the market of today requires speed and flexibility, so gigantic projects is really not our first-hand choice. And part time resources will increase the Project Administration waste, which actually means that we cannot do as much as before. If the line organisation does not understand this, they will increase the budget in proportion to the employee, and think they will get the same proportional products and services. This will spell symptoms for the employees.
So, already at start, the employees need to work over time, since the productive working time is eaten up by the Project Administration waste. Resource efficiency will evidently go down. And all of the employees, as they now also are (niched) specialists will have their own queue of activities. A queue with one activity from each project and together with the always present variability, even if the planning is well done, this will be a mess, with the Flow efficiency also going down. See this blog post for a deep dive regarding variability and problems with queues, and how to find the root causes.
So, the more the competence for an employee is narrowed, the more waste. And this goes for any organisation, but especially evident it will be in product development. But, also in production with its ups and downs in product quantity, sickness, education, vacation etc., where an employee with many different I-competences is very useful and can fill any empty position, and I call it Multi-I-competence. The difference and similarities between production and product development will be thoroughly elaborated on in the blog post Aggregation vs Integration.
As stated before, the figure of 20% Project Administration loss is not constant either and will increase for every project due to scheduling time between projects, mental set-up time for changing project, loss of control, stress, handovers generating Chinese whisper effect, etc. So, the waste is not linear rather exponential for every project that is added. We also have an exponential curve in the number of communication channels between our employees by the formula n(n-1)/2, which points on the difficulty to solve problems, take decisions, meeting time needed, etc. when number of employees (n) is increasing.
And exponentiality is valid also for Flow efficiency, with continuous splitting of groups into 2 halves, giving the formula of; the power of 2 and n-1, plus 1, not only for number of queues (one per person), but also for the number of activities in each queue (one from each project). That is the maximum (not reachable) and also implies that the projects get smaller and increase in quantity at the same rate. And variability will, even though it is well planned in the ordered domains, generate both many activities in a queue sometimes, and an empty queue sometimes, where the former will generate empty queues somewhere else. And empty queues to specialists are really Activities in Queues waste, and are adding up the Flow efficiency waste. Lean queues, see details in this blog post, on the other hand never gets empty, it is always another planned activity to work on for the team members, if the first one is blocked. Efficiency studies made by Kim Clark and Steven Wheelwright [1], show that having two tasks, where the one with highest Business Value is always prioritised, gives the highest individual efficiency. This in comparison with only having one task or more than two tasks, where the risk of running out of work combined with increased context switching waste gives more inefficiency. This efficiency study supports Lean queues.
Note! Do not mix this up with multitasking, where there is a constant switching between two or several tasks and where the actual context switch will cost time, as well as adding more and easy errors, making frequent context switching highly inefficient.
Tomorrow’s blog post will be the wrap-up of “to solve”, with the curve, the relation between Resource efficiency and Flow efficiency, principles and our root cause. The principle is kind of straightforward now, right? C u soon.
References:
[1] Cohn, Mike. Succeeding with Agile Software Development Using Scrum. Link copied 2018-09-21:
http://www.informit.com/articles/article.aspx?p=1409779&seqNum=4