<?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: Wrong Approach to Weekly Project Meetings</title>
	<atom:link href="http://blog.johnestrella.com/2009/06/wrong-approach-to-weekly-project-meetings/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.johnestrella.com/2009/06/wrong-approach-to-weekly-project-meetings/</link>
	<description>Project Management &#124; Business Analysis &#124; Software Testing</description>
	<pubDate>Fri, 12 Mar 2010 09:50:20 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: John Estrella</title>
		<link>http://blog.johnestrella.com/2009/06/wrong-approach-to-weekly-project-meetings/comment-page-1/#comment-181</link>
		<dc:creator>John Estrella</dc:creator>
		<pubDate>Thu, 11 Jun 2009 17:06:41 +0000</pubDate>
		<guid isPermaLink="false">http://blog.johnestrella.com/?p=319#comment-181</guid>
		<description>Look me up next time Atul.</description>
		<content:encoded><![CDATA[<p>Look me up next time Atul.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Atul</title>
		<link>http://blog.johnestrella.com/2009/06/wrong-approach-to-weekly-project-meetings/comment-page-1/#comment-174</link>
		<dc:creator>Atul</dc:creator>
		<pubDate>Sun, 07 Jun 2009 13:17:50 +0000</pubDate>
		<guid isPermaLink="false">http://blog.johnestrella.com/?p=319#comment-174</guid>
		<description>•	Further break the meeting into two parts a) Status b) Potential issues.
•	Seek status first, this allows team members who do not have any potential issues and are not required to contribute in solution discussions to leave the meeting.
•	Hold risk identification and management meetings separately and not mix with status meetings, a status meeting should be short compared to potential issue identification, problem solving or risk management meetings.
•	Reason - Very often a status meeting runs in to solution discussions and you run out of time, without rest of the team members getting a chance to provide status updates.
•	Clearly identify the purpose of the meeting and time allotted for the activity i.e. Status, Potential issues and finally discussion on finding the right solution.
•	As a thumb rule if a problem can not be resolved under 5 minutes, park it and book a separate meeting with only key players, thus respecting the time of other team members.

Ps: I was also present in the evening session, let us meet next time.</description>
		<content:encoded><![CDATA[<p>•	Further break the meeting into two parts a) Status b) Potential issues.<br />
•	Seek status first, this allows team members who do not have any potential issues and are not required to contribute in solution discussions to leave the meeting.<br />
•	Hold risk identification and management meetings separately and not mix with status meetings, a status meeting should be short compared to potential issue identification, problem solving or risk management meetings.<br />
•	Reason - Very often a status meeting runs in to solution discussions and you run out of time, without rest of the team members getting a chance to provide status updates.<br />
•	Clearly identify the purpose of the meeting and time allotted for the activity i.e. Status, Potential issues and finally discussion on finding the right solution.<br />
•	As a thumb rule if a problem can not be resolved under 5 minutes, park it and book a separate meeting with only key players, thus respecting the time of other team members.</p>
<p>Ps: I was also present in the evening session, let us meet next time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://blog.johnestrella.com/2009/06/wrong-approach-to-weekly-project-meetings/comment-page-1/#comment-168</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Fri, 05 Jun 2009 20:41:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.johnestrella.com/?p=319#comment-168</guid>
		<description>Absolutely the right way to do things. 

I do find that some attendees at my meetings are confused when I do not provide them with the "normal" structure and agenda, but there is not enough time to go through the niceties.   

I want to know what today's problem is, what we are doing about it, what the next problem is going to be and how can we avoid or mitigate it.</description>
		<content:encoded><![CDATA[<p>Absolutely the right way to do things. </p>
<p>I do find that some attendees at my meetings are confused when I do not provide them with the &#8220;normal&#8221; structure and agenda, but there is not enough time to go through the niceties.   </p>
<p>I want to know what today&#8217;s problem is, what we are doing about it, what the next problem is going to be and how can we avoid or mitigate it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harwinder</title>
		<link>http://blog.johnestrella.com/2009/06/wrong-approach-to-weekly-project-meetings/comment-page-1/#comment-165</link>
		<dc:creator>Harwinder</dc:creator>
		<pubDate>Fri, 05 Jun 2009 12:47:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.johnestrella.com/?p=319#comment-165</guid>
		<description>Very good point. Nice to be reminded of it again. Thanks.</description>
		<content:encoded><![CDATA[<p>Very good point. Nice to be reminded of it again. Thanks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
