<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Clarke Says, Multi-Tasking Is Evil, I Agree</title>
	<atom:link href="http://www.reformingprojectmanagement.com/2008/05/15/863/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.reformingprojectmanagement.com/2008/05/15/863/</link>
	<description>The magazine for the project age</description>
	<lastBuildDate>Fri, 15 Apr 2011 17:20:14 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jeff</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-21980</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Fri, 15 Apr 2011 17:20:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-21980</guid>
		<description>I&#039;m working with a team of architects and engineers on a very large factory retrofit design.  The project is composed of many dozens of small projects.  We&#039;re trying to work in small batches by planning in short cycles.  One challenge is the contracted definition of done at milestone reviews.  The team is conditioned to make the grade - literally to score well on the &#039;report card&#039; they get at each review.  They have, in effect, promised to work on everything all along the way and to finish nothing until everything is done.  We can see how this is a problem, yet have been *unable* to negotiate a different approach with the customer.  Yet we must.</description>
		<content:encoded><![CDATA[<p>I&#8217;m working with a team of architects and engineers on a very large factory retrofit design.  The project is composed of many dozens of small projects.  We&#8217;re trying to work in small batches by planning in short cycles.  One challenge is the contracted definition of done at milestone reviews.  The team is conditioned to make the grade &#8211; literally to score well on the &#8216;report card&#8217; they get at each review.  They have, in effect, promised to work on everything all along the way and to finish nothing until everything is done.  We can see how this is a problem, yet have been *unable* to negotiate a different approach with the customer.  Yet we must.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-21465</link>
		<dc:creator>Hal</dc:creator>
		<pubDate>Mon, 15 Mar 2010 21:07:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-21465</guid>
		<description>I just repeated the exercise with 8 people. The average first result (working on three projects at once) was 46 seconds. The second result averaged 21 seconds. The most interesting thing was that all the errors occurred in the task-switching round.

I just got back from working a week in Ireland. I rented a car. It had a stick shift. I drove for the first time in 20 years on the left side of the road shifting gears with my left hand reading road signs with the names of three up-coming exits alternating in Gaelic and English. It&#039;s not quite the same as task-switching, but boy did one thing get in the way of the others. It took me 2 days to get used to driving on the left and shifting with my left hand. I never did get used to reading the dual language signs. I kept missing my exits.</description>
		<content:encoded><![CDATA[<p>I just repeated the exercise with 8 people. The average first result (working on three projects at once) was 46 seconds. The second result averaged 21 seconds. The most interesting thing was that all the errors occurred in the task-switching round.</p>
<p>I just got back from working a week in Ireland. I rented a car. It had a stick shift. I drove for the first time in 20 years on the left side of the road shifting gears with my left hand reading road signs with the names of three up-coming exits alternating in Gaelic and English. It&#8217;s not quite the same as task-switching, but boy did one thing get in the way of the others. It took me 2 days to get used to driving on the left and shifting with my left hand. I never did get used to reading the dual language signs. I kept missing my exits.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ds</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20873</link>
		<dc:creator>ds</dc:creator>
		<pubDate>Fri, 03 Apr 2009 23:48:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20873</guid>
		<description>I have to say, I did it in both modes in *exactly* 39 seconds in each.  I often have to multi-task in my job, so that may have something to do with my results.   When I don&#039;t have to multi-task, I finish tasks front to back and then move on, but when I reach a point where I need to wait for results to continue, I switch to the next thing, usually small tasks that require less focus &amp; match the amount of time I will need to wait.</description>
		<content:encoded><![CDATA[<p>I have to say, I did it in both modes in *exactly* 39 seconds in each.  I often have to multi-task in my job, so that may have something to do with my results.   When I don&#8217;t have to multi-task, I finish tasks front to back and then move on, but when I reach a point where I need to wait for results to continue, I switch to the next thing, usually small tasks that require less focus &amp; match the amount of time I will need to wait.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20784</link>
		<dc:creator>Hal</dc:creator>
		<pubDate>Sun, 28 Sep 2008 01:17:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20784</guid>
		<description>Disingenuous?  C&#039;mon!  Yes, we multi-task when making coffee and letting the cat out.  We multi-task when listening to the news and reading our email.  Mothers feed their babies while stirring the soup.  Of course it&#039;s like breathing.  But, we&#039;re not talking about that.  We&#039;re talking about professional work.  Work that takes attention...often our full attention.

There are two big issues.  First, as the exercise clearly shows, some of the work that we do will take longer when multi-tasking.  Second, for those of us who do professional work -- structural engineering, architecture, software programming -- multi-tasking introduces errors that can have consequential results.

These are the reasons Clarke calls multi-tasking evil...and I agree.</description>
		<content:encoded><![CDATA[<p>Disingenuous?  C&#8217;mon!  Yes, we multi-task when making coffee and letting the cat out.  We multi-task when listening to the news and reading our email.  Mothers feed their babies while stirring the soup.  Of course it&#8217;s like breathing.  But, we&#8217;re not talking about that.  We&#8217;re talking about professional work.  Work that takes attention&#8230;often our full attention.</p>
<p>There are two big issues.  First, as the exercise clearly shows, some of the work that we do will take longer when multi-tasking.  Second, for those of us who do professional work &#8212; structural engineering, architecture, software programming &#8212; multi-tasking introduces errors that can have consequential results.</p>
<p>These are the reasons Clarke calls multi-tasking evil&#8230;and I agree.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AlexJB</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20783</link>
		<dc:creator>AlexJB</dc:creator>
		<pubDate>Fri, 26 Sep 2008 22:57:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20783</guid>
		<description>An interesting observation, and great &#039;back of the envelope&#039; style demonstration.  but misleading, and rather disingenuous in its simplicity.

There are a number of problems with the underlying premise.

1. premise: each &#039;project&#039; could be taken from beginning to end without interruption if focused on exclusively. i think we can all agree that this is not true on real project work 80% of the time.

2. premise: zero flaws is the preferred outcome. this is not always true either - speed is only one of the sides of the iron triangle.

3. premise: each project is only done when it&#039;s done. sometimes, there are sub-project milestones which, if achieved in a timely way, provide substantive value. you could argue that this is just a matter of re-sizing the &quot;project&quot;, so i&#039;ll throw in...

4. premise: there is no value to a partially started project. in my experience, there are frequently times when having a project &#039;started&#039; has real and tangible value to the stakeholders. 

as fun as it is to malign multi-tasking, i think that it&#039;s unrealistic and pointless. i multi-task constantly, all day long, even more when i&#039;m not at my job than when i am.  while waiting for Quicken to boot up, i pet the cat or get a glass of water.  or i&#039;ll alt-tab to my web browser and trigger my RSS feeds to load so that i can flip over and read one at a time while waiting for some other operation to run. when a TV show goes to commerical, i go pee or pick up the conversation that i was having with my friend. 

it&#039;s not evil, it&#039;s as natural as breathing.</description>
		<content:encoded><![CDATA[<p>An interesting observation, and great &#8216;back of the envelope&#8217; style demonstration.  but misleading, and rather disingenuous in its simplicity.</p>
<p>There are a number of problems with the underlying premise.</p>
<p>1. premise: each &#8216;project&#8217; could be taken from beginning to end without interruption if focused on exclusively. i think we can all agree that this is not true on real project work 80% of the time.</p>
<p>2. premise: zero flaws is the preferred outcome. this is not always true either &#8211; speed is only one of the sides of the iron triangle.</p>
<p>3. premise: each project is only done when it&#8217;s done. sometimes, there are sub-project milestones which, if achieved in a timely way, provide substantive value. you could argue that this is just a matter of re-sizing the &#8220;project&#8221;, so i&#8217;ll throw in&#8230;</p>
<p>4. premise: there is no value to a partially started project. in my experience, there are frequently times when having a project &#8217;started&#8217; has real and tangible value to the stakeholders. </p>
<p>as fun as it is to malign multi-tasking, i think that it&#8217;s unrealistic and pointless. i multi-task constantly, all day long, even more when i&#8217;m not at my job than when i am.  while waiting for Quicken to boot up, i pet the cat or get a glass of water.  or i&#8217;ll alt-tab to my web browser and trigger my <acronym title="Really Simple Syndication">RSS</acronym> feeds to load so that i can flip over and read one at a time while waiting for some other operation to run. when a TV show goes to commerical, i go pee or pick up the conversation that i was having with my friend. </p>
<p>it&#8217;s not evil, it&#8217;s as natural as breathing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20780</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Wed, 17 Sep 2008 16:06:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20780</guid>
		<description>very interesting post. that exercise is a really effective and simple way to prove the point about multi-tasking. and that is the most intelligent way to present an argument! you have great PM blog here. I also have a blog on project management, check it out if you get a chance http://www.santexq.com/blog. keep up the good work.</description>
		<content:encoded><![CDATA[<p>very interesting post. that exercise is a really effective and simple way to prove the point about multi-tasking. and that is the most intelligent way to present an argument! you have great PM blog here. I also have a blog on project management, check it out if you get a chance <a href="http://www.santexq.com/blog" rel="nofollow">http://www.santexq.com/blog</a>. keep up the good work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: opleiding projectmanagement</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20770</link>
		<dc:creator>opleiding projectmanagement</dc:creator>
		<pubDate>Wed, 23 Jul 2008 20:30:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20770</guid>
		<description>It is actually what the zen masters are saying since centuries.</description>
		<content:encoded><![CDATA[<p>It is actually what the zen masters are saying since centuries.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20765</link>
		<dc:creator>Hal</dc:creator>
		<pubDate>Thu, 26 Jun 2008 19:14:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20765</guid>
		<description>Hi Gil,

Great question.  Utilization is an indirect leading indicator of short term firm profitability.  However, there are three situations that require slack capacity: ability to respond to opportunities, working on the business, and learning.  Some firms reserve capacity for this setting lower utilization targets for staff.

One thing you can do is to adopt a make-ready approach for your work along with the rule not to start a task that is not in a condition to be finished.  The combination will result in far less multi-tasking.</description>
		<content:encoded><![CDATA[<p>Hi Gil,</p>
<p>Great question.  Utilization is an indirect leading indicator of short term firm profitability.  However, there are three situations that require slack capacity: ability to respond to opportunities, working on the business, and learning.  Some firms reserve capacity for this setting lower utilization targets for staff.</p>
<p>One thing you can do is to adopt a make-ready approach for your work along with the rule not to start a task that is not in a condition to be finished.  The combination will result in far less multi-tasking.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gil Friend</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20763</link>
		<dc:creator>Gil Friend</dc:creator>
		<pubDate>Thu, 26 Jun 2008 06:10:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20763</guid>
		<description>Thought provoking and just what I needed. Thanks. 

And a question: 
You say &quot;Full utilization is not sustainable.&quot; Yet utilization is typically a key metric (and a key profitability driver) in a consulting firm. So how do you suggest thinking about and managing utilization? (Do you set utilization targets? And if so, at what level?)</description>
		<content:encoded><![CDATA[<p>Thought provoking and just what I needed. Thanks. </p>
<p>And a question:<br />
You say &#8220;Full utilization is not sustainable.&#8221; Yet utilization is typically a key metric (and a key profitability driver) in a consulting firm. So how do you suggest thinking about and managing utilization? (Do you set utilization targets? And if so, at what level?)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20755</link>
		<dc:creator>Hal</dc:creator>
		<pubDate>Wed, 21 May 2008 05:30:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20755</guid>
		<description>Hi Don,

Nice hearing from you.  Has it really been 7 years since we worked on the nuclear power station?

The idea of multi-tasking has more to do with one person who has 2 or more tasks going at the same time than 2 or more people doing one task.  I&#039;ve also seen great value in creating composite crews.  I hear people say that work rules get in the way of that.  It&#039;s not my experience.  Last winter I worked in Canada on a power station where we created composite crews.  We too had great success.

Hal</description>
		<content:encoded><![CDATA[<p>Hi Don,</p>
<p>Nice hearing from you.  Has it really been 7 years since we worked on the nuclear power station?</p>
<p>The idea of multi-tasking has more to do with one person who has 2 or more tasks going at the same time than 2 or more people doing one task.  I&#8217;ve also seen great value in creating composite crews.  I hear people say that work rules get in the way of that.  It&#8217;s not my experience.  Last winter I worked in Canada on a power station where we created composite crews.  We too had great success.</p>
<p>Hal</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Don Miller</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20754</link>
		<dc:creator>Don Miller</dc:creator>
		<pubDate>Mon, 19 May 2008 15:17:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20754</guid>
		<description>At a nuclear facility to reduce maintenance backlogs, we developed teams to work mostly back shifts to reduce the backlog. we utilized one electrican, one welder,one mechanic and an I&amp;C tech. they were self directed and multitasked so that only one of each trade was on the team.
this process worked very well for us. errors were minimal and backlog was reduced. If we did not multi task we would have needed at least twice as many complicating the planning process.</description>
		<content:encoded><![CDATA[<p>At a nuclear facility to reduce maintenance backlogs, we developed teams to work mostly back shifts to reduce the backlog. we utilized one electrican, one welder,one mechanic and an I&amp;C tech. they were self directed and multitasked so that only one of each trade was on the team.<br />
this process worked very well for us. errors were minimal and backlog was reduced. If we did not multi task we would have needed at least twice as many complicating the planning process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Glen B. Alleman</title>
		<link>http://www.reformingprojectmanagement.com/2008/05/15/863/comment-page-1/#comment-20753</link>
		<dc:creator>Glen B. Alleman</dc:creator>
		<pubDate>Mon, 19 May 2008 14:16:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.reformingprojectmanagement.com/2008/05/15/863/#comment-20753</guid>
		<description>Hal,
In the space and defense domain, 100% billing is not a specific issue, but 100% flow of work is. Since the planning process assumes fungible resources at the work package level (these are project with 100&#039;s to 500 engineers spread around the country), the problem of balancing the resources is left to the Control Account Manager and flows down to the Work Package Lead. Design is the primary work product for the first half of the program, so sequencing the work is not really possible in the same way as manufacturing, test, and flight operations.
PDCA is an option, but self organizing the WP Team is the most common, which due to the nature of the work turns into heavy multitasks. The phrase used to describe the situation is OBE (Over Come by Events). Once we get behind the planned hours absorbtion - due to normal overload - multitasking is the only way out. 
Fine grained iterations solve some problems, but it&#039;s a fact of life the multi-tasks is part of the space and defense execution process.
While Clarke&#039;s exercise is cleaver, I&#039;ve yet to hear an actual solution that can be put in place with measurable benefical outcomes. It&#039;s restating the obvious that multi-tasking is less efficient, but still waiting for a better approach that can be put to work on &quot;real&quot; projects - other than the fine grained deliverables. At Rocky Flats, this was called Plan of the Day and supported by the Plan of the Week from the previouos week.</description>
		<content:encoded><![CDATA[<p>Hal,<br />
In the space and defense domain, 100% billing is not a specific issue, but 100% flow of work is. Since the planning process assumes fungible resources at the work package level (these are project with 100&#8217;s to 500 engineers spread around the country), the problem of balancing the resources is left to the Control Account Manager and flows down to the Work Package Lead. Design is the primary work product for the first half of the program, so sequencing the work is not really possible in the same way as manufacturing, test, and flight operations.<br />
<acronym title="Plan, Do, Check, Act/Adjust -- Deming/Shewhart cycle of improvement">PDCA</acronym> is an option, but self organizing the WP Team is the most common, which due to the nature of the work turns into heavy multitasks. The phrase used to describe the situation is OBE (Over Come by Events). Once we get behind the planned hours absorbtion &#8211; due to normal overload &#8211; multitasking is the only way out.<br />
Fine grained iterations solve some problems, but it&#8217;s a fact of life the multi-tasks is part of the space and defense execution process.<br />
While Clarke&#8217;s exercise is cleaver, I&#8217;ve yet to hear an actual solution that can be put in place with measurable benefical outcomes. It&#8217;s restating the obvious that multi-tasking is less efficient, but still waiting for a better approach that can be put to work on &#8220;real&#8221; projects &#8211; other than the fine grained deliverables. At Rocky Flats, this was called Plan of the Day and supported by the Plan of the Week from the previouos week.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic page generated in 1.044 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2011-10-03 10:39:26 -->

