These people are convinced they must pay attention to their work issues while they are in the workshop. And, they are the same people who want the “cheat sheet” or the “10-second overview of user stories” (true!). They are the ones who don’t participate in the debriefs for the experiential activities. They are the people who don’t see the value of instructor-facilitated and experiential training.

I’ve started a new introduction to my workshops. I say something like this: “I know that you are an adult. I trust you to make the right decision about your laptop open or closed. I will warn you that it is impossible to fully participate in this workshop with your laptop open.” (I smile as I say this.) “You have the choice to leave your laptop open or participate in the workshop. If you choose to leave your laptop open, please don’t prevent the other people at your table from working through the activities.” I stop then and start with the workshop.

I have mixed results. The people who believe me at the beginning learn a lot in my workshops. The people who realize I was serious later on in the workshop and finally   put away their laptops learn too, and it depends on when they put away their laptops. I can’t tell about the people who don’t put away their laptops. From the way they debrief the workshop, I don’t think they learn much.

I sort-of understand why conference-workshops are like this. Few people expect experiential activities at a conference workshop. (Ha! Gotcha!) Many of them have never encountered interactive and experiential training before. And, too many of them are expected (so they say) to check in at work while they are at the conference.

I don’t understand why a company brings me in and expects their employees to be on their laptops all the time while they are supposed to be at training. People really cannot do two things at once and do each of them well. They can do one thing well and the other not at all. They can do both things poorly. But they can’t learn and work at the same time.

I do ask people in in-house workshops how often they need to check email and check in back with their teams. I try to have enough breaks and a long-enough lunch to take that into account. But it’s quite difficult if the answer is “I have to be on email all the time.” I can’t teach and accommodate that request.

If you are attending a workshop, please participate. If you are working, go ahead! But, please, don’t try to do both at one time. It just doesn’t work.

Remember, the AYE conference is all experiential and interactive sessions. We would love to have you. And, we give you long-enough breaks between sessions so you can email or phone back to work. You’ll learn to work better. Isn’t that the whole point of workshops?

Tweet This Post

But, as I’ve been working with clients and writing more, I’ve been realizing that not only do the decisi0n-makers have to commit to projects, but that the project staff also have to commit to a project–and only one project–at a time.

That can be challenging. People need some time to think about future work, and maybe act on it a little. People might have an interruption from another project, that is in the best interest of the organization to answer. (If Project #1 has a question for someone on project #2, it is in Project #2’s staff’s best interest to answer the question. Not the other way around.)

So, one of the ways to make sure people fully commit is to make sure they are not fully booked 100% of the time. If people have a little slack in their day, they can accommodate the organization interruptions, the stray thought that they want to write down and explore later. Exploring later works best if you have a structure such as “20% time”, where people can take 20% of their time to work on something else.

What I’m finding interesting in my work is that people who have some slack can commit to one project much more easily than people who are 100% “committed” to a project. The people who are 100% committed have no slack to provide other projects some consulting or provide future projects some thinking. The people who are only 80% committed to one project (and not committed to something else, slack is key) are more able to finish their work and accommodate the inevitable interruptions.

When people multitask, they are not committed to a project. They have no slack. They have no time to innovate. They are always behind.

If you are lucky enough to have a leadership team commit to projects in a rank order, take advantage of that ranking. Work on one project at a time–commit to it– giving yourself a little slack, just in case. You can always use the time on your project. But if a higher ranking project needs you to answer a question, you can. You have time to innovate.

It’s not just serial monogamy project management; it’s serial monogamy project participation.

Tweet This Post

The real reason is that the managers are out to manage *their* efficiencies of staffing all the projects. The managers are not out to optimize the organization’s throughput. (I don’t know this organization, but many of my clients have been in this position.)

Matrix management–itself–is not the evil. Multitasking is the evil. And the root cause is a lack of project portfolio management.

In PPM, you don’t commit to a project unless you can staff it. Fully. Period. No half-staffing. No 1/4 of this person and 1/3 of that person etc to make 1 FTE (full time equivalents). There is no equivalent for one person fully committed to a project.

Remember that, the next time your manager asks you to work on more than one project. “Which project am I fully committed to?” is a reasonable question.

Managers, if you feel the need to assign people to multiple projects, ask your manager which project is most important. Staff that one. Now ask about the next one. Stop staffing projects when you run out of people.

When managers optimize their work at their level, they are (almost never) doing this out of maliciousness. But if the organization rewards them for sub-optimal optimization, how can they not take advantage of it?

Tweet This Post

Dan said, “Oh, you want them to commit to serial monogamy project management!” I cracked up.

He said exactly the right thing. No one has to be married to a project forever–just long enough to finish an iteration. (That’s why serial lifecycle projects are so hard. You have to stay married to the darn project forever.) But once you finish an iteration, you’re free to marry another project.

Thanks, Dan!

Tweet This Post

There’s a great quote over at The pernicious thinking behind multi-tasking.

Note the admission that required multi-tasking is an implicit means to avoid conflicts around setting priorities.

I’ve been doing a bunch of multitasking talks this year (and suggesting ways for people to say no), and have written about it in Successful Project Management. (I did rename the section that originally said, “Multitasking is the root of all evil.”) When I talk about it, and tell people it makes no sense, at least part of the time they say “Ooh.” Too many people have no idea what the cost of multitasking is.

But the conflict avoidance part is because management, especially senior management is unwilling to make the hard decisions about what’s most important to do. That’s unacceptable. Managers are the only people who can make these most strategic decisions.

Multitasking guarantees your project will be late. If managers don’t make the decisions, project staff will. And it won’t be the way the managers want it.

Labels: multitasking, project management, Successful Project Management

Tweet This Post

I’m trying to describe the costs of multitasking. Here’s what I’ve got so far:

There are three parts to multitasking:

• Stopping the work you’re doing. The stopping cost is the time it takes to mark your place, save your work, etc. You haven’t stopped thinking about what you’re doing, but when you stop to take a phone call or answer a question, there’s a stopping cost. If you’re in flow, this is surprisingly high.
• Swapping out what you’re working on. The swapping out is the act of clearing your mind of the work you’d been doing so you have room to swap in the new work. If you were in flow or concentrating deeply, this can take anywhere from 5 minutes to 30 minutes. Sometimes, it takes me even longer.
• Swapping in the new task. The swapping in depends on the complexity of the work and how long it’s been since you last touched the task. The more complex and the longer the time since you last touched the task, and the more people you have to talk to, the longer it takes.

I don’t know how to give ballparks for each of these. Certainly, for some tasks, it’s fairly trivial. If I’m organizing a normal weekday dinner, my swapping in/out is very fast, because there’s little knowledge associated with each task. But now when I write chapters of a book (or back when I was writing code,) the costs can be very high, because the knowledge in my head is not yet written down. For me, the stopping the work is defect-inducing. Unplanned interruptions help me make defects. So does the swapping back in, if it’s been a long time since I last worked on this task.

Did I miss anything?

Tweet This Post

A few weeks ago, I republished an article originally published in Better Software: Convincing Management That Context Switching Is a Bad Idea on the AYE site. I’d received no feedback about the article when it was published, so I wanted to generate some discussion about my ideas.

I did generate a little discussion. Don Gray first said “Context switching is fun!“. Later on, he said the differences were:

* One switches between similar tasks, the other doesn’t.
* I’m not under deadline pressure. (Should anyone be?)
* I get to choose when to switch contexts.

George Dinwiddie discusses the issues of flow in his Context Switching post and the consequences of being interrupted. Don Gray in a later post discusses why managers feel it’s ok to ask people to do multiple things.

I still think managers assign people to context switch for these reasons:

• The manager can’t decide what’s most important.
• The manager doesn’t understand/remember that technical work is different from management work, and that the more things a technical person works on, the less that person will get done and the worse the work is.
• The manager can’t remember all the work required and doesn’t realize he or she is asking one person to work on more than one thing.
• The manager still believes that people who multi-task are more efficient or get more work done than people who don’t.

Do you have better arguments than mine? What do you think?

Tweet This Post

A reader sent me email with this question: “We have a group of four people (3 developers and a tester). We work on 4 products, releasing one about once a month (each product is released once a quarter). The developers are devoted to one product when they’re developing, but have to fix problems immediately if someone finds a problem and reports it. How do I manage the multi-tasking?”

I’ve asked the reader a few questions. I still don’t know everything about the environment, but here’s what I suspect is happening, based on my questions:

Each product has technical debt, from insufficient testing (all the way through development) from previous releases.

There are a ton of ways to deal with insufficient testing. I would first start with peer review of fixes. If someone is interrupted from new development to deal with an already-existing, but newly discovered problem, have the developer ask a peer to review the fix. Part of the peer review would be to create automated tests for this fix. (Yes, I realize this now interrupts two people. I find that if there’s a Big Problem in one product, there are frequently other related Big Problems in the related products.)

After peer review and automated tests, I would (gently) ask the tester how the tester missed this problem. This is for root cause analysis, not to assign blame. The tester doesn’t read or write code, so the tester can only perform black box testing. Black box testing, by its very nature, is unlikely to find most of the gotcha’s in a product. After a short root cause analysis, I would add some form of automated test development activity to each project.

I can see some heads shaking from here. “If we take time to add tests, we can’t add as many features.” You’re absolutely right. But here’s the problem. You’re not adding the features now. You’re adding broken almost-features. That’s not helping the customers. The customers deserve to have features that work.

So, to deal with multi-tasking from defects in a small group, I recommend changing the way you work. If you keep the same lifecycle you have now, add the practice of peer review of all code and all fixes. Add in automated testing for all defects that have to be fixed from the field. Change the testing, because it’s not exposing the Big Problems before you release. If you choose to change lifecycles, I suggest an agile lifecycle with test-driven development.

Whatever you do, don’t assume that wishing away the problem will make it go away. Some practices need to change. Maybe not the ones I’ve suggested, but some of them do. The change will take time, depending on how much technical debt you have. Otherwise, you’re left with the quality pledge and no muscle behind it.

Tweet This Post

Clarke Ching’s Multitasking MAKES YOU STUPID is another great article. But when I teach PMs or coach managers, they say, “I need to multitask to get things done.” Or, they say, “I’m ok with multitasking.”

Even smart people think they can do a couple of things at one time. Maybe they can. But the more things you try to focus on, the less overall you do. Think about that word focus for a few seconds. When you focus on something, you concentrate. If you’re attempting to think or work on several different things, you’re not focusing on anything.

I once worked for a company who decided its mission was to “focus on five.” Even then, I knew five was too big a number. But when I suggested we focus on two, my suggestion was dismissed. Company no longer exists.

Deciding what to do –and what not to do — is not simple. I just created a simulation (Esther reviewed it for me) to hammer home the point that we all have a limited attention span, and when we pay the necessary attention to one thing, we’re not paying attention to something else. In the simulation, people have to make choices about what to do and what not to do. I’m using the simulation for the first time next week. We’ll see how it goes. Maybe I’ll be able to report back.

If you’re faced with multitasking demands, stop for a few seconds. What’s the most strategically important work? Do that first. If you have three or seventeen things you think are all at the same importance and you can’t rank them, ask your boss. You’ll find that a bunch of the things you think you’re supposed to do may not even need to be done. Just don’t think you can do them all at the same time, because you can’t.

Tweet This Post

At a recent presentation, (Managing the Management Balancing Act) I discussed the problems of multi-tasking. I received this feedback:

Johanna, I have to say that I think you are off the path in terms of “multiple projects.”

1) Organizations just don’t work this way – it isn’t cost-effective.

2) Today’s emerging workforce (20-30) were raised in an environment that was not FIFO. It’s multi-in, multi-out.

If you can prioritize projects and sub-divide the work, these people are fantastic “multi-project” testers. Looking around the room this morning, I see many young faces, raised with multi-tasking as the norm. I think you need to update your thinking.

Oh dear. When I read this feedback, I was sure this was an unseasoned manager, assuming he/she was encountering these problems for the first time. Unfortunately, multi-tasking has been around since people had more than one thing to do :-)

In a recent Software Development article I discussed the true costs of multitasking (as have Hal and Esther and I in our blogs). This manager doesn’t seem to understand the costs; he/she sees the apparent completion of work.

As I reflected more on this, I realized that I believe each manager has the job of prioritizing the work as his/her first role. If you know what you’re supposed to deliver to the organization, you can select the people and organize the work to succeed. If you never choose what to deliver to the organization, you can never fail as a manager. Of course, you can never succeed either, because there’s always too much to do. But you can certainly never fail. Until the whole organization fails.

Managers who never reassess their work prioritization are inadequate managers. Managers who take on the work the organization requests (or demands) and who don’t prioritize are inadequate managers. Organizations that don’t rank their work will fail.

If you’re a manager, first prioritize your group’s work. Then assign it. Monitor the flow and the organization’s priorities. It’s not easy, and it’s necessary.

Tweet This Post