I wrote earlier about a potential method of using Critical Chain-stype “mini-buffers” within an element of a traditional project management approach. Now I would like to revisit multi-tasking and how having some experience with the Agile software development methodology called SCRUM has helped me formulate some guidelines. Some of these ideas come straight from Critical Chain too, and a myriad of other methodologies all pointing to the same conclusions.
First there is good multitasking and bad multitasking. Good multitasking may be an essential part of your job. Or you may be working on something where you really need to switch gears after a little while in order to recharge your batteries. Bad multitasking is really the enemy. This can take the form of fire-fighting, or just wandering around from task to task depending on how you feel that day. Both of these reflect a lack of proactive thinking when they occur in abundance.
What’s wrong with bad multitasking anyway?
I’m glad you asked!
First, switching from task to task means that even if you are putting full effort into your work, the cycle time from start to finish on any given task is going to lengthen dramatically. See the following illustration for an example.
Second, when you switch from task to task, you introduce overhead into the equation, especially when you are talking about something in a manufacturing setting (Theory of Constraints, Lean) or if you are working on a highly intellectual task. It can take a long time to either set up a production line to run something different through, or remember where you were at the last time you left off.
Remember these are just illustrations and guidelines, not an ideology to be followed blindly. Obviously, there are many examples where you can not finish a task because you are waiting on someone else, for instance. Would you sit idle for a day until they get back to you? Of course not. Prudent judgment is required here, but avoid voluntary bad multitasking whenever you can.
So how can my project team avoid bad multitasking?
Here is where my experiences and research on SCRUM come in. One of the key contributors to mad multitasking is a lack of focus and planning. With SCRUM, each morning we would have a “war room” session for 15 minutes, with a very strict agenda. This is a small piece of SCRUM but a very crucial one. The leader would ask the questions and usually take notes so that he/she can help remove obstacles and have a good sense of what the team is working on that day.
The agenda consists of 3 questions, asked of each team member.
- What did you work on yesterday?
- What will you work on today?
- What obstacles or risks do you see?
This is not a meeting to discuss technical issues or even solutions. Usually 2-3 minutes maximum per person is what should be allowed. The lead should jot down issues or discuss afterwards in more detail.
The goals of the war room meetings are to:
- Foster excellent communication
- Allow for potential synergy in collaboration (by re-using code in software development, but parallels exist in all industries)
- Make sure everyone has clear goals and plans for their work
- Ensure the project manager/lead knows exactly what they need to focus on to remove obstacles and deal with potential risks on the horizon.
Done daily or perhaps a few times a week, this means that everyone has a clear purpose of what task they are going to work on that day, and it helps them focus on that and not jump around to other tasks. This is a good way to eliminate as much bad multitasking as possible by using a proactive approach.
About the author
Josh Nankivel is a Project Planning & Controls Control Account Manager and contractor for the ground system of the Landsat Data Continuity Mission, a joint project between the USGS and NASA. His academic background includes a BS in Project Management, summa cum laude. He can be found writing and contributing in many places within the project management community, and his primary project management website is located at pmstudent.com.
