Multi-tasking Multiplies Lead Time
>...snip ...Most of the
>members of my project teams (I have 2 projects right now) are in the
>application areas and are not directly associated with the Y2K project team
>that has been assembled -- I have their time for anywhere from .25 FTE to
>.5 FTE. I was told that none of them could be allocated any more than this
>due to their responsibility to support production. There are usually only
>1 or 2 people supporting each third-party application. In addition, due to
>the physical structure here, they are not even in the same building as I
The idea of assigning a half or a quarter of a headcount to a project is a good way to start down the slippery slope of multitasking. When I talk about multitasking, I mean bouncing back and forth between two or more tasks before they are done and handed off. By task, I mean a chunk of work, that, when complete, is handed off to someone else for additional work.
People can easily be involved with more than one project without multitasking, as long as they complete the individual tasks they are involved in before moving to the other project's task. If, however they bounce back and forth, both projects suffer due to the time spent on the other one.
Let's say we have three tasks (A, B, & C) on three projects, each taking 4 time units of effort.
If multitasking is in effect, that means that the resource will bounce back and forth at the beck and call of the three project managers. Let's make it simple and assume that each task gets half completed before moving off to satisfy the needs of another project status review.
The work would look like:
if the resource is allowed to focus on one before moving on to another. Actually I'm being kind here, ignoring additional setup and rework that will further expand the first example. But even without it, while yes, all three tasks were done in the 12 time units, from the point of view of the individual projects, each task actually took 8 time units instead of 4, resulting in the expansion of the project lead time and delay of downstream tasks relative to the start of A, B or C. If all resources on a project are working in this mode, than it's an easy leap to the statement that many of our project plans could very well be at least twice as long as they need to be.
The individual projects would actually be better off if they didn't pressure the resource to work on their task and allowed them to focus on the task at hand!!!
|To do two things at once is to do neither. - Publius Syrus
The source of this page is a posting made by Frank Patrick to one of a variety of online discussion forums, most likely an e-mail discussion list. It's tone and style may be informal, occasionally provocative, and sometimes, even impertinent. There may even be typos until an opportunity arises to clean them up for more formal presentation. Despite these minor shortcomings of style, the content is worth sharing.
Discuss Critical Chain - An email-based discussion group
Frequently Asked Questions about Critical Chain-based project Management
Top 10 Sources of Project Failure -- A list you probably won't see on Letterman.
FP's Postings - others like this page on a variety of topics
Unconstrained Thinking - a collection of more polished mutterings and musings, written as a column for APICS chapter newsleters
Check Out the Following Links for More About the TOC Approach to Project Management:
Critical Chain and Risk Management - Protecting Project Value from Uncertainty -- Project management is the practice of turning uncertain events into certain promises. If so, then project management is an extended excersie in risk management. The core concepts underlying Critical Chain-based project management directly support risk management and are described in this paper, expanded from one presented at PMI's 2001 National Symposium.
Getting Out From Between Parkinson's Rock and Murphy's Hard Place -- This first link will bring up a paper based on a poster presentation originally given at the 1998 New Jersey PMI Chapter's annual symposium, honored with a "best of the show" award by attendees, and later turned into an article published in PMI's PM Network magazine.
Program Management -- Turning Many Projects into Few Priorities with TOC -- This link will lead to a paper on the key attributes of a TOC Multi-Project Management environment. (Most projects are performed by resources shared with other projects. It can be deadly to ignore the resulting interactions, no matter how well you manage single projects.) This paper was originally presented at PMI's Global Symposium in Philadelphia in October of 1999 and is included in the proceedings of that conference. Audio tapes of the presentation are also available from PMI.
Project Portfolio Management - The First Cut is the Kindest Cut - One of the common problems faced by project-oriented organizations is having too many projects relative to their capacity. Therefore, one of the first things that needs to be done is to determine what can be done is to determine what should be done . . . and what should not be done . . .
Consumption of Effort and Conservation of Energy for Project Success -- This link will lead to an essay on the necessity for managing protective capacity in multi-project environments to get the most organizational throughput from the efforts of project resources.
Critical Chain Basics
A Critical Chain Schedule
The Sooner You Start, The Later You Finish