Task Switching...And why it's bad
OK... Imagine for a moment that I have three tasks that I need to do. Each task will take one week. The deadline to complete them all is three weeks. They are all equally important.
I have two possible ways to divide my time. I can do the tasks sequentially, or in parallel. Finish one then do another, or work one day on each then switch to another -
As you can see, if I do the tasks in parallel, none of them get finished in time. The culprit is that tiny little gap between each task in the parallel flow. Switching between tasks is not seamless. I need to tidy up one task to where it can be left easily. I need to pick up the other task and remember where I was. I need to get my mind thinking about something that could be very different to what it was doing before. Let's say it takes an hour to do all that. If we switch tasks every day that's an hour a day over three weeks - 15 hours. That's easily two full working days lost to task switching. In reality, it can take a lot longer than an hour to switch tasks. Research has shown that for complex, technical/creative work like software development the switching time can be closer to 2-4 hours. That's a lot of time.
By contrast, if I complete one task then move to the next there are only three task switches required. A few hours rather than a few days. But there's another benefit. Can you see it?
Imagine that each of those tasks is creating a new product or service to sell. Creating something of value. I finished task A after one week. That means I (or the company I work for) can start to profit from my work after only one week. And after two weeks I have a second thing of value to profit from. Even without task switching losses, the parallel flow means that none of the tasks get finished until week three. That's two weeks of lost value on task A and 1 week lost value on task B.
Two weeks you say? Hardly anything. But now replace the word Task with Project, I with Team and Week with Quarter or Year. I have three projects to schedule and one team. Each will take one year. So, do I schedule them sequentially? Finish one then start the next? Or do I run them in parallel?
If I run them sequentially, I can get two extra year's value from project A and an extra year's value from project B. Why then do most development groups run projects in parallel? Why do I hear "you will be working 50% on X, 30% on Y and 20% on Z" so often?
The problem is one of prioritisation. In order to run sequentially, someone needs to decide that A is more important than B which is more important than C. That can be a very hard decision. But it is one that can, and should be made.