What is context switching? Project management

Ever come across context switching? Even if you haven’t heard the term, you have likely experienced it at some point. Let’s go over why it’s important to know about it and how to deal with it.

You have probably heard of „Everything Everywhere All at Once”, a movie that received many Oscars during the last gala. The film tells us how different realities, conditions, specific circumstances, and dependencies surround us, and how something that in one dimension means one thing, in another may mean something completely different.

Watching this film, I couldn’t shake the feeling that I knew the idea from somewhere. And soon I realized – this is nothing other than the reality of IT project management!

Not convinced? Well, just see…

What is context switching?

Context switching is jumping between multiple tasks or activities in a short time. In practice, it can look like going from a project to social media, to your phone, to another project, etc. While it’s quite normal and frequent, it can disrupt your workday and leave little space for focused activity.

To make this definition more complete, you need to ask who is affected by context switching. In general, this can be anyone who wants to do their job properly and tries to reconcile its many dependencies.

Examples of context switching at work

Let’s take the job of a hotline consultant as an example. In general, their task is to answer the phone and talk to clients. Theoretically, the number of conversation topics is quantifiable and predictable, but is it really?

In practice, hotline consultants can be connected to many queues on the IVR, answer many calls completely unrelated to each other, and yet still work at one company and handle a single process.

When they receive a sales call, they follow a sales script, but next they may receive a call with a complaint, a question about the status of a delayed order, or a call from an angry customer.

The question is, does adjusting how they talk to each customer, changing to the appropriate conversation script, and mentally preparing for what they will hear and need to say in a moment, fulfill the characteristics of context switching? Of course, the answer is yes!

We deal with this very often, at different scales, not just as project management professionals.

Another example: a person working in a supermarket and splitting their workweek between different stands. Here, in addition to switching to a different form of service, there can be changes to things such as appropriate clothing, other health and safety or sanitary regulations, a different type of customer, etc.

Context switching – what is it?

My definition of context switching is, to put it simply:

The necessity to switch to different types and ways of work performed within 8 or more working hours in a single day, bearing in mind that the consequences may be unpredictable. It involves “changing trades” every few hours and trying to perform each task without consequences to the ones before or after.

Context switching in IT project management

What motivated me to write this article was the fact that I deal with such situations at work too. And I’m sure many people working on multiple and/or complex software development projects feel the same way. The only question is whether we realize that:

• this state of “permanent patching” or switching tasks has a name
• it is nothing unusual and practically everyone must deal with it
• is it absolutely normal that in the multitude of various topics, it is impossible to reconcile everything.

What is the reality of IT projects?

Context switching, in an advanced form, also occurs when we have to do several different activities simultaneously. For example, while at a meeting regarding one project, we’re replying to emails about another.

What are the consequences of such multitasking for project efficiency? Is it a problem at all?

Seemingly, this form of work can be perceived as very effective: one person covers many topics, quickly and cheaply. However, the real cost of such work is very high. In practice, within 1 hour of work, we may have to context switch up to 4 times.

Example of context switching: daily project meetings

One of the key elements of agile project management are stand-up meetings. I’m used to the daily stand-ups being 15 minutes long and taking place in the morning.

But while working on multiple projects, within 1 hour I have 4 meetings on 4 different projects, with different people, in different realities, with different problems, with different stages, even in different languages.

During these 15 minutes, a lot of arrangements are made and new problems that need to be resolved are addressed. This requires me to react very quickly and almost immediately switch my thinking to a completely different context – much like the helpline consultant mentioned earlier.

But this is quite simple: dailies are quick and general. I am in “daily mode”: short questions and quick answers, topic parking, and focus mostly on one, most crucial, issue.

Things get worse later in the day when we go into more detail. What happens then? Sad but true: mistakes happen.

Working as a project manager

An IT project, from a PM point of view, consists of many repeatable and a few unique things. Roughly, it can be said that each engagement has common features, such as the need to set the scope, project planning, people management, working time reporting, budget control, risk management, schedule, status meetings, reports, and presentations.

There are also unique things: the subject matter of the project, team setup, language, or specific reporting requirements due to local legal regulations.

With repetitive things, we often fall into a routine, doing the same tasks in the same way. Sometimes it works out for us, and sometimes it’s just the opposite.

On the other hand, we focus more on unique things because they are way less certain, less clear, and can cause some difficulties or escalations. Naturally, we then pay more attention to these unusual things.

Is that right?

Mistakes happen when task switching

If we have several projects/tasks to perform at the same time, mistakes are inevitable.

From the simple ones (mispronouncing a name at a meeting or asking a question about unrelated task or project), through slightly more problematic ones (overlapping meetings, difficulties in planning the day and inevitably dropping the ball on some seemingly unimportant topics), to big problems (e.g. sending sensitive information by e-mail to the wrong recipients).

These are very important issues coming as a result of working on many threads at the same time and certainly not everyone can handle it, but it is not impossible.

How to be effective when context switching?

First, I would like to note that I have gone through all these examples of changing the context I mentioned. It was easiest for me to refer to my own experiences.

I run several projects, I really have 4 daily meetings each day, I work in Polish and in English, with people from different regions and cultures, and all this 100% remotely.

People can take different approaches to work, from working calmly, at low speed, not filling it entirely with duties, to a fast pace, adrenaline and hours quickly passing one after another.

I lean towards the latter end of the scale, and so I decided to combat context switching instead of resigning from some projects or responsibilities. As a result, I developed several ways that help me to prioritize tasks, regardless of the project management methodology or tools.

Planning

All my tasks or meetings are pre-set in the calendar. Whether it’s a reminder in Outlook or a classic Windows sticky note, or even a piece of paper on the desk, everything is written down as a to do list. It allows me to visualize how much time I have for my focused work during each day.

I also keep notes of all the arrangements. After each meeting I prepare a short summary. What is very important, each summary follows the same pattern:

• what we agreed on
• what to do next, and most importantly
• who does it and when.

It is crucial to be able to control what is happening in your ongoing processes, and summarizing important tasks and information goes a long way towards achieving this goal.

Project roles

When I start a project, I try to devote quite a lot of time to understanding its scope, meeting team members, and noting what they are responsible for. Especially when I can immediately see that it has its own unique characteristics (country, industry, technology, culture).

This allows me to organize the issues and people who deal with these issues in my head. Later, when I’m at a status meeting where we start to go into detail, I can recall who from my team knows the topic best.

So, in principle, I don’t need to know everything about the project, but I need to know who does. This generally works very well for me.

These are quite typical organizational things, basically widely described in various sources, but I also have a few tricks that I use.

“Stakeholder juggling”

What is it about? For a given stakeholder, their project is the most important, that is clear. However, for a project manager who has several projects – the situation is not so obvious.

In a situation where the number of tasks begins to pile up, questions about the status of work arise or we are even approaching escalation, and then the juggling begins.

We queue questions from the most important or the most escalated to the less important ones, and even despite pressure from stakeholders, we leave the least important ones for later.

HOW TO PRIORITIZE PROJECT REQUIREMENTS?

Now, what do I mean by “more important” and “less important”? Because, of course, every project is important and we want to complete every one with success. Each of the stakeholders must feel taken care of, even if for a moment their project has lower priority.

So, for the time being, the “more important project” is the one approaching (or that has reached) escalation, the one closest to the deadline, or the one where we’ve hit a wall and need to unlock the team’s work urgently.

“Less important one” is where we get questions about the status because you can see a slight delay, one where some works are blocked, but there is some progress, and finally one in which you can afford to slow down for a while because project progress is on track.

What you need to remember: when our action is required in “less important” projects – we must perform it, but we can buy ourselves some time: meet the client, calm them down, present a plan, and declare the date of taking action.

To be fully transparent: this is not a suggestion to ignore some projects, this is the way to handle them all and, in the end, have all stakeholders happy.

Communication management

This applies to communicating with everyone: stakeholders, team, superiors. When the client expects information or a response to an escalation and wants to meet urgently, and we are completely unprepared for such a meeting – how to behave then?

As I mentioned before: the client must always feel taken care of, which is why we absolutely go to the meeting, but only to arrange another one. We start a conversation, write down doubts, park topics and generally defuse the situation.

What’s the advantage?

The client knows that their problem is important to us. They know that we are available, and that we plan to solve the problem, even if we don’t have a solution just yet.

I strongly encourage you to develop your own methods and ways of conducting discussions and meetings, because the worst thing that can happen is ignoring the client’s call or avoiding contact.

Helpful tools for handling multiple tasks

Over the course of a few, literally 2-3 years, project management tools have undergone a revolution. I’m not even talking about typical applications such as JIRA or Azure DevOps.

The development of Teams and connection to SharePoint, co-creation of a document by many people, conflict-free, the ability to connect very quickly with anyone, anywhere – these are awesome possibilities.

MS Teams

While not a project management tool in itself, working with chat makes context switches much easier and I notice a lot of people prefer to text rather than call. Sometimes a given topic may be discussed via chat for half a day, but in my opinion, this is not a bad approach. Why?

Because it’s not like that “chat” lasts 4 hours but is done in the so-called meantime as we task-switch. You can have several chats, prepare a presentation or another document for a different project, and at the same time not postpone the topic we are writing about. And you have full notes right away.

In addition, meetings are very expensive, chatrooms cost less, and the effect is quite similar.

Of course, this doesn’t always work. Not everything can be described and there is a greater risk of misunderstanding. However, in my case, I’m able to deal with around 40% of organizational topics only via chat, and 60% in a chat and a short, 15-minute meeting in a small group (or 1:1), instead of in a long meeting with several people.

Any other tools for managing daily tasks?

Other useful tools include:

• Whiteboard applications – they are a very good tool for quickly showing (drawing) what we are saying, which can then be easily saved and shared with others.
• Lightshot – this a brilliant tool for print screens, e.g., shared screen during a Teams meeting, then you don’t need to take notes.
• Project documentation in the form of recordings – it has probably never been easier than it is now. You can record, edit, and share each remote meeting in a very simple way.

These are just examples. I highly recommend that you search the terms that come to your mind online, and there will certainly be some solution or tool that will come in handy. And best of all: more and more of these business tools are free.

I wonder what OpenAI will suggest…

Context switching is not essential for effective project management

Some might think this is an article promoting context switching and I’m a workaholic and take on as many projects as possible. Nothing could be more wrong. It is not something I encourage.

Context switching is a fact, a situation that exists and you must deal with it because it simply cannot be avoided. I am also not a workaholic, because having 9 active projects at the time of writing this article, I usually finish work in 8 hours, and I sometimes work a maximum of 5-8 overtime hours per month.

I also don’t take everything that moves for implementation, but I just found myself in a situation where several parallel demanding projects were placed in front of me, and I had to deal with them. It’s a very interesting experience.

Earlier, in my 12-year PM career, I practically always had large, long, and expensive projects, and even then, when I look at it from the perspective of time, I was dealing with (sometimes unnecessary) context switching.

Now, when I am working on multiple processes simultaneously, it manifests itself with full force. While the beginnings were difficult, now I have a sense of control and that is why I decided to share my observations and methods. I hope some of these tips will help you too.