Multitasking Engineers Isn't Always A Bad Idea

May 29, 2000
Companies increasingly view the multitasking of project team members as a necessary evil. They do it, but acknowledge that they shouldn't. Because multitasking is seen as an obvious evil, we should examine its disadvantages and advantages....

Companies increasingly view the multitasking of project team members as a necessary evil. They do it, but acknowledge that they shouldn't. Because multitasking is seen as an obvious evil, we should examine its disadvantages and advantages.

Dedicated full-time team members usually perform faster product development than part-timers for several reasons. First, part-timers often aren't available when you want them. Next, task switching adds overhead that reduces productivity. Third, part-timers create larger team sizes, which lowers efficiency. Additionally, part-timers feel both less identification with a specific project and less accountability for its objectives.

Finally, part-timers are far less likely to work outside of their specialty on whichever issue is on the project's critical path. Instead, they focus on the work inside of their specialty in support of other projects. It would appear then that the case for multitasking team members is very weak. Because of this, it may be useful to review the right and wrong reasons for multitasking.

Unfortunately, the most common justifications are usually wrong. Managers argue that sharing resources across teams increases efficiency and profitability. While this may improve efficiency, it can come at a high price. The true cost of experts isn't the cost of their task. Rather, it's the delay that they add to a project which frequently is 100 times higher than the expense of their task.

Nevertheless, there are some good reasons to multitask experts in support of multiple teams. First, multitasked team members create important linkages between projects. They cross-pollinate ideas and ensure consistent approaches on multiple projects.

Second, shared resources are often inherently more responsive to variation. Imagine, for instance, that there were three manufacturing engineers available to support three projects. One could be assigned to each project, or all three engineers could simultaneously support all three projects. The latter approach works best when the demand for manufacturing engineering time is "lumpy." We might need three engineers full-time at one stage of the project and none at another. The lumpy demand for a resource from multiple projects is thus aggregated into a combined demand with less variation. This reduces queueing problems and associated delays.

Finally, multitasked re-sources are valuable to project managers because it's easier to modulate their workload. If Joe works 80-hour weeks, it's hard to double his time on a project. In contrast, a shared resource spending 20 hours per week can be temporarily raised to a higher level of utilization.

Why do companies fail to gain the benefits of multitasking? They manage such resources incorrectly. Key mistakes must be avoided. Loading multitasked members to 100% utilization guarantees queues and delays. Measuring and encouraging them on efficiency leads them to load to full utilization. Involving multitasked members too late in a project causes them to generate expensive changes and be on the critical path. Exclusion from project recognition and incentive plans makes these workers think they're second-class citizens. Failing to engage them in the goals and culture of the project makes them feel like nameless gears in the machine. So, don't assume that multitasked team members are always a bad idea.

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!