How Multitasking Affects Capitalization and What You Can Try Instead

I've been working with a new-to-the-organization senior leader, Steve, who struggles with this challenge: He wants to capitalize some operational expenses. (That's a move from OpEx to CapEx.) He is convinced that will give him some freedom to change things while everyone is still working hard.

So they've asked all the technical people to fill out time cards to describe how much time each person spends on which project. With that information, the finance people can determine capitalization. However, their timecard software has several restrictions:

• No time card can exceed 40 hours. (But too many people are working overtime to “catch up.”)
• No time card can exceed 5 projects. (But too many people are attempting to work on 6, 7, or even 8 projects in one week.)
• The technical people claim they do not remember where they spent their time at the end of the week. (With more than 5 projects in one week, I'm not surprised.)

Steve is at a loss. He took over this organization, thinking he could capitalize some expenses and get some time to fix the organization. Now, he's worried he will have to lay off people and otherwise reduce expenses because he can't figure out how to move to CapEx.

We used a three-pronged approach: visualize the system, discover some of the root cause(s), and offer some alternatives.

Visualize the System

I asked Steve if this picture accurately described his problem. (This picture is from Manage It!)  The blue boxes are the work times for one single task. (That task might be a story, an entire feature set, whatever.) The white boxes are the delays between the work times for that specific task:

“Yes! Except, make the blue boxes smaller because people are slicing their time smaller. And make the white boxes all other colors because people are working on several tasks at one time. Then, add more wait times and that's exactly what's happening!”

I showed him this image, too, with each person as a row:

I said, “This image does not show delays, but does this describe more of what you see, with all people and their various tasks: the yellows as one task, all the blues as another, and so on?”

He said it did.

We now have a systems view of the work. It's not a perfect view, but it's good enough. (If we had wanted a “perfect” view, we could have created value stream maps for several features for several teams. But we did not need a perfect view.) We can now discover root causes.

Discover Root Causes

Most systemic problems do not have a single root cause. Instead, they have several causes, often interrelated.

I will spare you the long 5 Whys conversation, but Steve had several root causes:

• None of the products had an overarching product goal. Even though each iteration had a Scrum goal, that goal rarely related back to an overarching product strategy.
• There was no relative ranking of the products, as in which product offered more value now. That means there was no ranking of the projects in the project portfolio. Instead, all products were assumed to be equal and all were “high” in value.
• The teams push-planned more work than they could possibly do in an iteration.
• Everyone worked as an individual, with the corresponding increase in WIP, longer cycle times, and lower throughput. (See the Flow Metrics post.)

Steve saw this list and sighed.

I said, “You wanted a challenge for this job, right?”

After we laughed, we discussed Steve's options.

Consider These Options

I first suggested that Steve rank every product. But he said he did not know—or even suspect—which product was more valuable than all the others. (Yes, even though I recommended he use Cost of Delay to rank products.)

Instead, did he know the top 3 products? Yes, he did.

I then asked him to consider these options:

• Option 1: Assign all the teams to just those three products. If he needed interrupt-driven work, such as production support, make sure all the teams were large enough to add that work to their normal product work. If he could not, he had to choose which two products were most important.
• Option 2: Ask team members to collaborate, not cooperate or work solo. We discussed pairing, swarming, and mobbing. Steve needed to explain to everyone that the teams needed to focus on finishing work, not starting any more work.
• Option 3: Consider different timeboxes, such as three days or one week. For example, if he really thought all three products were of the same importance and he did not have more teams or people to assign, he could ask each team to work on one product for three days or one week. Then, rotate to another product for the next two or three days.

You can see there might be more alternatives based on these principles of more people doing less work for less time. If he could reduce WIP, increase throughput, he could make the capitalization information easier to obtain. (I wrote about these and even more options in Manage Your Project Portfolio.)

In parallel to the teams, the managers had to decide on the product ranking and the portfolio. Even Steve was surprised by the results.

Team Results

Steve started with Option 3 and one-week timeboxes. He decided that Products A, B, & C were most important. He asked the product leaders to collaborate on just those three products. In addition, he asked the teams to focus on just their product—one of A, B, or C.

Almost immediately, each team realized they did not have enough domain expertise to finish their work. The domain expertise was split across too many people.

Steve asked the teams to use mobbing or other learning techniques to collaborate as they learned. But, they had to spend at least a couple of hours learning together before interrupting any other team.

In addition, each team would spend one week on their product. At the end of that week, the product owners would jointly decide which products were most important. Then, at the end of two weeks, the portfolio team could readjust the project portfolio.

That lasted three days. Each of the teams was stuck on problems they could not solve. They needed time from experts. However, the teams were able to easily fill out their time cards.

Steve decided that was fine. In those three days, each team had finished several features. For the next two days, the teams would support each other and the teams could decide how.

Steve repeated that three-day experiment where each team was on one product and then supported each other for the other two days for another week.

By then, the portfolio team had decided on the project portfolio. And the product managers decided on the strategies for each product.

As a result, the organization reduced the number of projects and the number of products. That made everything much easier at the organizational level.

Organization Results

The easiest way to manage the project portfolio and to capitalize investment is to assign teams to projects. Not individual people, but teams. Aside from reducing the team-based multitasking with all of its delays, that makes it easier to know where the money is going.

Multitasking in the small (at the team level) creates delays, increases WIP, and makes it difficult to finish anything. Worse, the team cannot offer any kind of estimate because even cycle time is too random when people multitask.

Muiltitasking in the large (at the organizational level) makes it impossible to see where the money goes. No one can tell where all those salaries are going and the value you're getting from the people.

Instead, always rank the portfolio and the backlogs by value with Cost of Delay. Then, assign one cross-functional team to a feature set or a product. Encourage that team to collaborate so they don't increase wait time between states. Then, if you want to capitalize your development, you have a shot of being correct.

But time cards (or other trackers) cannot give you accurate information for capitalization. Any tool focused on the individual is wrong. Instead, use the team as the unit of work and start there with the data you need.