A lot has been said over the last several years about the fallacy of increased productivity when a person multitasks. Lean, Agile, and the Theory of Constraints each recommend reducing or eliminating it, as do many scientists, and sociologists. Just Google search for 'multitasking' and you'll see what I mean.
Much has also been said, especially by people in hardware development companies, about the impossibility of eliminating multitasking.
Throughout this post on effective task management, we’ll find common ground that allows us to see and eliminate the costliest multitasking without going overboard and wasting capacity, delaying production issues, or creating a lot of rework.
The effects of multi-tasking on task duration
We start with a simplified picture of our tasks, and expand on it through this post and the next.
Figure 1: The Effects of Multitasking on Task Duration
In this first picture, note the area of each task rectangle is the total work required to complete the task. Its height is the resource’s availability to perform the task, and the width of each task is its duration. Work is generally the "given," availability is the input variable, and duration is the output, determined by work and availability.
These tasks can be thought of as a malleable, but non-compressible fluid, like Play-Doh, flowing through the resource's pipeline. The pipeline's total diameter is the resource’s capacity, which, in a sustainable (Lean) system must be considered mostly fixed. Our control is in how we choose to divide up that capacity.
Notice that availability is less than capacity, because of meetings, bathroom breaks, interruptions, miscellaneous emails, and many, many other things. These additional tasks choke the flow of work through the pipeline. The remaining availability, is then divided across the resource's in-process tasks (WIP). The availability applied to each task determines the duration of that task.
Notice, also, that the area (total work) of each task is greater in the multitasking scenario. This is because of multiple factors, including switching costs and the time spent remembering what we did and why we did it. Also, the longer each task takes, the more time we spend reporting the status of that task. In short, multitasking creates more work.
The real cost of push task management
There is an important difference between the Play-Doh analogy and real tasks through a resource pipeline. With Play-Doh, we can increase the rate of flow by increasing the force we use to push it through, almost without limit. However, imagine hitting the plunger in the picture below with a hammer - what would happen? The same thing that happens in product development - either the pipe breaks, or stuff comes out the wrong end, or both.
Figure 2: Excessive pressure forces some work to escape (not usually a good thing)
Excessive pressure has this effect even more easily on real tasks. Pressure often causes some work to be omitted, rather than forcing it through faster. Some of this escaping work is otherwise known as 'cutting corners' and 'taking risks' and very often it comes back later, in the form of a lot more work and costly delays.
Not all tasks are created equal
Note, figure 1 depicts “sit and do the work” type tasks, such as; draft a document, review a document, run a test, set up the analysis model and so on. For these tasks every hour not applied to that task delays completion of that task by one hour. If your availability is one hour a day, each hour not applied to the task is one whole day of delay.
“Sit and do the work” tasks are in contrast to monitor tasks like receive parts and release documents, where the task duration is not so directly dependent on the resource’s availability. Monitor tasks generally take priority over work tasks, and therefore they leave less availability for the work tasks. Monitor tasks become much like meetings, emails and interruptions, in that they line the walls of the resource pipeline and leave a narrower passage for the work tasks to fit through, stretching them out and creating more work due to switching costs, etc.
In addition, these are three independent tasks. For example, work on task C does not impact tasks A or B. If the tasks are dependent enough that they must be done together to reduce rework, then we don't call that multitasking. Instead, we segment the work to better reflect what we must do together and what we can do separately. If we can't do much separately, we make it one task.
Lastly, there are sometimes blockages on these tasks. If for some reason we cannot move forward on one task and instead work on a different task, that is not 'multitasking' in our definition. This includes mental blockages, where you just need to get away from a task for a little bit to clear your head.
What is multitasking?
At Playbook, our definition of multitasking is when two or more independent work type tasks are in process at the same time and not blocked. Instead of picking one to focus on, the resource works on more than one. Even with this limited definition of multitasking, there is a lot of multitasking every day among typical resources.
So, returning to Figure 1, let me ask these key questions:
- How much earlier did we complete task C by starting it earlier?
Answer: We don’t complete C any earlier – we complete it later. - How much did we delay A and B by starting C earlier?
Answer: A LOT.
We simply delay some tasks without accelerating other tasks in the process. In our definition of multitasking, it is all downside. And there is a lot of it in our systems right now.
Figure 3: Multitasking Creates Uncertainty and Turbulence
To make matters worse, when we spread our availability more thinly across the tasks, we lose a lot of confidence in the duration of those tasks. This uncertainty causes turbulence in our product development systems, which further slows the flow of projects though the system.
Having clear priorities reduces multitasking
So why do people multitask so much, and what can be done to reduce it? There are many reasons but in this post we will discuss a critical contributor to reducing multitasking – having clear priorities.
In most hardware development environments, the team members are required to work on multiple projects, and multiple activities within a project simultaneously. Along with activities related to developing a new product, resources often have multiple sustaining engineering activities which require their attention.
Very often different people have different opinions about what a given resource should focus on. In a typical matrix scenario, people have multiple managers come to them asking for the status reports on various tasks across projects. What’s a resource to do? Tell them, “Sorry, I’m busy with someone else’s tasks.” This response is not in our nature. It is uncomfortable for most people to say, “No." Instead, people will just multitask so they can say, “I’m working on it.”
Figure 4: Push Creates Delays
Making matters worse, even on a single project there are often multiple activities which require a resource’s time. Imagine if the four tasks on Project A in the image above were stacked vertically and all pushed in simultaneously, rather than lined up horizontally in succession. That is what it usually looks like to the resource anyway.
The value of clear priorities
The result is that all of the tasks get very stretched out, and a significant amount of extra work is created. If our resources, on average, work on 3 tasks at a time, each task takes more than 3 times as long to complete.
Figure 5: Value of clear priorities
If they average 5 tasks in WIP, each task takes over 5 times as long. How many tasks do each of your resources have in WIP right now? Is it any wonder that completed work just trickles out?
Note, the directions of the flow in the pictures above are reversed. In figures 2 and 4, we depict flow in the traditional direction: from left to right. What happens on day 1 is on the far right. In Figures 1 and 5, however, we show a calendar-day, Gantt-chart view, where flow goes from right to left and what happens on day 1 is on the far left. The figures below also use a right-to-left calendar-day view. Regardless of how it is depicted, however, the effects are the same, so please ignore the differing directions.
Establishing clear priorities
In order to reduce costly multitasking, establishing clear priorities both within a project and across multiple projects is absolutely necessary. To establish clear priorities it is very helpful if priorities are common and project team members and management are on the same page with what each resource should be doing each day.
In order for priorities to be clear and common across multiple projects, there must be clear prioritization of the projects themselves. Project A, Project B, CAPA X, and Issue Y in the pictures above must be prioritized relative to each other.
Common priorities across projects is imperative, but not sufficient. If the work is not visible, then priorities aren't very clear to everyone, and push and multitasking will return. Visible work is an absolute must to achieve clear priorities.
From the previous post on Pull vs. Push using the Black Friday analogy, what if, instead of standing in line with clear visibility to the people (work) in front of you, you were asked to sit in a closed room all by yourself until it was your turn? How long before you start clamoring for someone to multitask on you?
Having recently been in the Emergency Room for seven stitches in my thumb, invisible work is a lot like that. I sat a long time, waiting for the doctors and nurses to help me out. Had I been able to see them busy with someone else's more urgent needs, I would not care. As it was, I was pretty annoyed. Sound familiar?
The value of correct priorities
With clear priorities, even if they aren’t the ‘correct’ priorities, the throughput of the system will improve. Tasks A, B, and C are all completed earlier when multitasking is reduced. Maybe C would have been a better task to start first, but even if we didn't realize this, as long as we just picked something, we complete C earlier than we would by multitasking.
However, how much would it accelerate our project to recognize and work on ‘correct’ priorities as well? What if C were actually the task on the critical path that we should have worked on first, but we couldn't tell and we guessed wrong?
Figure 6: Value of Correct Priorities
As figure 6 indicates, every day we defer completing a critical task is one day later the project will be completed. This applies whether those days are lost while the task is inside the execution pipeline, or while it is sitting in a queue waiting to get in.
Figure 7: More Value of Correct Priorities
Every day we set the priorities of critical tasks correctly instead of incorrectly, every day we make the better decision about what to work on, is one day earlier our project will be completed. There is a huge opportunity to accelerate projects by getting the priorities right more often.
Effective task management
Correct priorities within a project are easily determined with a good model of the project (a good plan) and the criticality calculations that the model enables. Without a good model of our project, we must use gut feel to make priority decisions.
In the complex, dynamic system of product development, establishing correct priorities using gut feel is a lot harder than most people think. Importantly, each day we work on the wrong priority task moves our end date further out. Unfortunately, typical project plans fall far short of ‘good’ plans and don't help us make great priority decisions.
Good models of our projects are not difficult to develop, if you have the right tools. There are several very important ingredients which many tools do not contain, including good criticality calculations, the ability to see and limit multitasking, the ability to see, measure, and control resource availability, and many more.
In a future post on Decentralized Project Management, we’ll dive deeper into the key aspects of a good model of a project and how to attain and maintain the model. In the meantime, there is one more key to reducing multitasking: the elimination of Task Buffers, and the use of Project Buffers instead.
In Part 8 we discuss replacing individual task buffers with shared team buffers.
Stay tuned....
-----
Ready to see two paradigm shifting ideas around what causes project delays?
Related articles
Lean project management
Lean project management methodology
Lean project management Kanban
Lean project management principles
Resource management
Pull vs. push
Task management
Shared project buffers
Decentralized planning
Daily stand-up meetings
Guide to Lean Project Management
