<?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: Unanticipated Events Screw Up Schedules</title>
	<atom:link href="http://jrothman.com/blog/mpd/2006/09/unanticipated-events-screw-up-schedules.html/feed" rel="self" type="application/rss+xml" />
	<link>http://jrothman.com/blog/mpd/2006/09/unanticipated-events-screw-up-schedules.html</link>
	<description>Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.</description>
	<pubDate>Thu, 08 Jan 2009 13:13:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Amy Schwab</title>
		<link>http://jrothman.com/blog/mpd/2006/09/unanticipated-events-screw-up-schedules.html/comment-page-1#comment-451</link>
		<dc:creator>Amy Schwab</dc:creator>
		<pubDate>Sun, 01 Oct 2006 22:46:25 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8032#comment-451</guid>
		<description>We do an exercise with groups to see just how much time they really have available for their projects - not counting contingencies.  Most project methods suggest allocating at 80% and it is useful to start with a more realistic baseline. We start with the maximum number of hours in a week and then subtract time for the usual - a weekly allocation for vacations, sick time, holidays, administrative time, phone calls/emailing, fire-fighting, and, oh yes, those things called 'life' (eating, sleeping, family time). The median available time left for project work?
16 hours - and that varies from 25-30 hours for individual contributors working on just one project to negative time for project managers juggling multiple efforts.
Yes, plan on the unexpected - AND, most usefully, expect the expected.
Hope you heal quickly.</description>
		<content:encoded><![CDATA[<p>We do an exercise with groups to see just how much time they really have available for their projects - not counting contingencies.  Most project methods suggest allocating at 80% and it is useful to start with a more realistic baseline. We start with the maximum number of hours in a week and then subtract time for the usual - a weekly allocation for vacations, sick time, holidays, administrative time, phone calls/emailing, fire-fighting, and, oh yes, those things called &#8216;life&#8217; (eating, sleeping, family time). The median available time left for project work?<br />
16 hours - and that varies from 25-30 hours for individual contributors working on just one project to negative time for project managers juggling multiple efforts.<br />
Yes, plan on the unexpected - AND, most usefully, expect the expected.<br />
Hope you heal quickly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://jrothman.com/blog/mpd/2006/09/unanticipated-events-screw-up-schedules.html/comment-page-1#comment-450</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Sat, 30 Sep 2006 19:53:34 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8032#comment-450</guid>
		<description>I think one thing can be done. Learning from past. Looking on the past projects you can at least estimate some kind of average time spent on unexpected issues.
However, more often I see schedules screwed up by not planning obvious events. If you're interested in reading a bit more here's the &lt;a href="http://managee.blogspot.com/2006/08/how-to-improve-your-scheduling.html"&gt;link&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>I think one thing can be done. Learning from past. Looking on the past projects you can at least estimate some kind of average time spent on unexpected issues.<br />
However, more often I see schedules screwed up by not planning obvious events. If you&#8217;re interested in reading a bit more here&#8217;s the <a href="http://managee.blogspot.com/2006/08/how-to-improve-your-scheduling.html">link</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Flowers</title>
		<link>http://jrothman.com/blog/mpd/2006/09/unanticipated-events-screw-up-schedules.html/comment-page-1#comment-448</link>
		<dc:creator>Ken Flowers</dc:creator>
		<pubDate>Sat, 30 Sep 2006 01:29:34 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8032#comment-448</guid>
		<description>Queuing theory suggests that you should plan work at about 50-60% of work capacity to avoid bottlenecks.  The theory says that you will get more work done this way than if you plan at 70-80% of capacity.  I think some kind of fudge-factor to account for the historic "unaticipated problem rate" for your projects is not a bad way to handle this.  If you put this extra time as a buffer at the end of your project, then manage against the remaining buffer size, you can leave yourself the opportunity to finish ahead of schedule if you don't need it.
Get well soon.</description>
		<content:encoded><![CDATA[<p>Queuing theory suggests that you should plan work at about 50-60% of work capacity to avoid bottlenecks.  The theory says that you will get more work done this way than if you plan at 70-80% of capacity.  I think some kind of fudge-factor to account for the historic &#8220;unaticipated problem rate&#8221; for your projects is not a bad way to handle this.  If you put this extra time as a buffer at the end of your project, then manage against the remaining buffer size, you can leave yourself the opportunity to finish ahead of schedule if you don&#8217;t need it.<br />
Get well soon.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kenneth P. Katz</title>
		<link>http://jrothman.com/blog/mpd/2006/09/unanticipated-events-screw-up-schedules.html/comment-page-1#comment-449</link>
		<dc:creator>Kenneth P. Katz</dc:creator>
		<pubDate>Fri, 29 Sep 2006 23:22:06 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8032#comment-449</guid>
		<description>Sorry to hear about your injury. Feel better soon.</description>
		<content:encoded><![CDATA[<p>Sorry to hear about your injury. Feel better soon.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
