<?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 for B2T Training</title>
	<atom:link href="http://www.b2ttraining.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.b2ttraining.com</link>
	<description>Connecting Business Requirements to Technology</description>
	<lastBuildDate>Mon, 30 Jan 2012 21:31:56 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>Comment on Stop doing final document review meetings! by Paul Mulvey</title>
		<link>http://www.b2ttraining.com/2011/12/29/stop-doing-final-document-review-meetings/comment-page-1/#comment-4073</link>
		<dc:creator>Paul Mulvey</dc:creator>
		<pubDate>Mon, 30 Jan 2012 21:31:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2677#comment-4073</guid>
		<description>@Simon - good for you for putting this in play. When I tried it, people found it unfamiliar that they couldn&#039;t ask questions on what was not ready for review. But then when they saw those sections finished, they knew it was a better use of time because the burning questions they had were answered once we made the sections ready for review. And then we could spend more time targeting the important questions.

You bring up a good point, though, about having a consistent facilitator or a defined process. If each session was going about it differently, it&#039;s a great way to keep stakeholders off-balanced, but not the best for them to get consistency. The first time that I tried what I wrote about in the blog, it was confusing because it was different. Once my group went through 3-4 meetings, we pretty-well had the process defined and it was a decent success.

Thanks for getting engaged in the conversation and sharing your experience. If you&#039;re on Twitter, Follow me at @PaulTheBA. Cheers!</description>
		<content:encoded><![CDATA[<p>@Simon &#8211; good for you for putting this in play. When I tried it, people found it unfamiliar that they couldn&#8217;t ask questions on what was not ready for review. But then when they saw those sections finished, they knew it was a better use of time because the burning questions they had were answered once we made the sections ready for review. And then we could spend more time targeting the important questions.</p>
<p>You bring up a good point, though, about having a consistent facilitator or a defined process. If each session was going about it differently, it&#8217;s a great way to keep stakeholders off-balanced, but not the best for them to get consistency. The first time that I tried what I wrote about in the blog, it was confusing because it was different. Once my group went through 3-4 meetings, we pretty-well had the process defined and it was a decent success.</p>
<p>Thanks for getting engaged in the conversation and sharing your experience. If you&#8217;re on Twitter, Follow me at @PaulTheBA. Cheers!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Stop doing final document review meetings! by Simon Barber</title>
		<link>http://www.b2ttraining.com/2011/12/29/stop-doing-final-document-review-meetings/comment-page-1/#comment-4072</link>
		<dc:creator>Simon Barber</dc:creator>
		<pubDate>Mon, 30 Jan 2012 13:42:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2677#comment-4072</guid>
		<description>Hi Paul. I tried a similar approach to the one you&#039;ve outlined on a very large project at my company so I thought I&#039;d share my experiences. We held about 10 different workshops each focusing on a different area and only inviting those people who had an input to that part of the project. We used DOORS to manage all our requirements and make it clear which were approved and which were still draft, as well as tracking all the changes. At the end of each session we could baseline the module and have a permanent record of exactly what was agreed at that point and by whom.

Unfortunately what we didn&#039;t do was have one facilitator who was present at all the workshops. There was just too much work to be done in the time we had for me to attend every session so I delegated responsibility for some of them and obviously didn&#039;t explain well enough what needed to be achieved. As a result the output from each workshop varied quite dramatically and thus the quality of requirements generated was not consistent and this led to unnecessary re-work.

So yes, I definitely agree with your approach but you either need to have a consistent facilitator or a better defined process that we did.</description>
		<content:encoded><![CDATA[<p>Hi Paul. I tried a similar approach to the one you&#8217;ve outlined on a very large project at my company so I thought I&#8217;d share my experiences. We held about 10 different workshops each focusing on a different area and only inviting those people who had an input to that part of the project. We used DOORS to manage all our requirements and make it clear which were approved and which were still draft, as well as tracking all the changes. At the end of each session we could baseline the module and have a permanent record of exactly what was agreed at that point and by whom.</p>
<p>Unfortunately what we didn&#8217;t do was have one facilitator who was present at all the workshops. There was just too much work to be done in the time we had for me to attend every session so I delegated responsibility for some of them and obviously didn&#8217;t explain well enough what needed to be achieved. As a result the output from each workshop varied quite dramatically and thus the quality of requirements generated was not consistent and this led to unnecessary re-work.</p>
<p>So yes, I definitely agree with your approach but you either need to have a consistent facilitator or a better defined process that we did.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Telecommuting: It’s not just about working in your “jammies” by Paul Mulvey</title>
		<link>http://www.b2ttraining.com/2011/10/18/telecommuting-it%e2%80%99s-not-just-about-working-in-your-%e2%80%9cjammies%e2%80%9d/comment-page-1/#comment-4068</link>
		<dc:creator>Paul Mulvey</dc:creator>
		<pubDate>Fri, 20 Jan 2012 21:20:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2651#comment-4068</guid>
		<description>@John - good point about the library - I never thought about that. I could take advantage of my tax dollars!

Also true about coffee shops being sub-optimal for verbal meetings. They are great places if you have to &quot;be connected&quot; but are primarily working on collaborative documentation and responding via e-mail. I have used them (along with other &quot;P****** Bread&quot; places) with great success. If you need to have a serious meeting, it might be tough to communicate with all the coffee-shop noise in the background.</description>
		<content:encoded><![CDATA[<p>@John &#8211; good point about the library &#8211; I never thought about that. I could take advantage of my tax dollars!</p>
<p>Also true about coffee shops being sub-optimal for verbal meetings. They are great places if you have to &#8220;be connected&#8221; but are primarily working on collaborative documentation and responding via e-mail. I have used them (along with other &#8220;P****** Bread&#8221; places) with great success. If you need to have a serious meeting, it might be tough to communicate with all the coffee-shop noise in the background.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Telecommuting: It’s not just about working in your “jammies” by John Reiling</title>
		<link>http://www.b2ttraining.com/2011/10/18/telecommuting-it%e2%80%99s-not-just-about-working-in-your-%e2%80%9cjammies%e2%80%9d/comment-page-1/#comment-4067</link>
		<dc:creator>John Reiling</dc:creator>
		<pubDate>Wed, 18 Jan 2012 11:40:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2651#comment-4067</guid>
		<description>Good post, capturing lots of good points.  I find that many people who have a telecommute day tend to be seen as having a day off, becasue rarely are they engaged with those at work.  It is the reposnsiblity of the teleocmmuter to make that as seemless as possible, and many of the suggestions above can help.  Note that coffee shops are great places, but are probably sub-optimal for any kind of verbal communication, and can sometimes also be distracting.  One often overlooked venue is the local library, many of which have private rooms that you can use for virtual or in-person meetings.</description>
		<content:encoded><![CDATA[<p>Good post, capturing lots of good points.  I find that many people who have a telecommute day tend to be seen as having a day off, becasue rarely are they engaged with those at work.  It is the reposnsiblity of the teleocmmuter to make that as seemless as possible, and many of the suggestions above can help.  Note that coffee shops are great places, but are probably sub-optimal for any kind of verbal communication, and can sometimes also be distracting.  One often overlooked venue is the local library, many of which have private rooms that you can use for virtual or in-person meetings.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Stop doing final document review meetings! by Paul Mulvey</title>
		<link>http://www.b2ttraining.com/2011/12/29/stop-doing-final-document-review-meetings/comment-page-1/#comment-4062</link>
		<dc:creator>Paul Mulvey</dc:creator>
		<pubDate>Mon, 09 Jan 2012 14:10:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2677#comment-4062</guid>
		<description>@Viki - you are correct in saying that people don&#039;t want to get together over and over again to review, and then have to sit through a marathon final review session. There&#039;s only so long that they can stay tuned-in. Different people have different levels. My rule-of-thumb is to make meetings no longer than 90 minutes. Any longer than that, and I find people starting to &quot;check out&quot;. By keeping each session to that length and having a razor focus on those requirements that you have to review, it helps move the meeting along and keep the stakeholders engaged. Also, another thing is to only invite those that need to be involved that day. If you are reviewing sales processes and have nothing planned for Operations, don&#039;t invite Operations to sit in the meeting for 90 minutes when they have nothing to contribute. This will help establish trust with your stakeholders that you are using their time wisely.

@Jennifer - right on with Caliber! That&#039;s the tool that I used when I used this process. There are other tools out there that you can use to do the same thing (yes, even Word and Excel), but the RM tool just made it so much easier. This process also works well for those big projects when the analysis phase is 8 weeks long. During a final review, people don&#039;t remember what was discussed in the first week and they bring up all sorts of questions that were already covered. While you may have the answers documented, it takes time in that final meeting to repeat back what was discussed and decided upon. By approving sections of the document as you move along, you are avoiding the questions that may arise in the final-final-final review that were answered weeks ago. And with some of those big final-final reviews, how do you get them under 4 hours? :-)</description>
		<content:encoded><![CDATA[<p>@Viki &#8211; you are correct in saying that people don&#8217;t want to get together over and over again to review, and then have to sit through a marathon final review session. There&#8217;s only so long that they can stay tuned-in. Different people have different levels. My rule-of-thumb is to make meetings no longer than 90 minutes. Any longer than that, and I find people starting to &#8220;check out&#8221;. By keeping each session to that length and having a razor focus on those requirements that you have to review, it helps move the meeting along and keep the stakeholders engaged. Also, another thing is to only invite those that need to be involved that day. If you are reviewing sales processes and have nothing planned for Operations, don&#8217;t invite Operations to sit in the meeting for 90 minutes when they have nothing to contribute. This will help establish trust with your stakeholders that you are using their time wisely.</p>
<p>@Jennifer &#8211; right on with Caliber! That&#8217;s the tool that I used when I used this process. There are other tools out there that you can use to do the same thing (yes, even Word and Excel), but the RM tool just made it so much easier. This process also works well for those big projects when the analysis phase is 8 weeks long. During a final review, people don&#8217;t remember what was discussed in the first week and they bring up all sorts of questions that were already covered. While you may have the answers documented, it takes time in that final meeting to repeat back what was discussed and decided upon. By approving sections of the document as you move along, you are avoiding the questions that may arise in the final-final-final review that were answered weeks ago. And with some of those big final-final reviews, how do you get them under 4 hours? <img src='http://www.b2ttraining.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Business Analysts&#8230;FYI by Paul Mulvey</title>
		<link>http://www.b2ttraining.com/2011/07/18/business-analysts-fyi/comment-page-1/#comment-4061</link>
		<dc:creator>Paul Mulvey</dc:creator>
		<pubDate>Mon, 09 Jan 2012 14:02:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2564#comment-4061</guid>
		<description>@Ratan - you got it! When people can arrive at one consistent interpretation of your message, the communication is successful. If there can be a different interpretation than the one originally intended, it&#039;s unsuccessful. For instance, my wife uses the word &quot;right&quot; to mean &quot;OK, or correct&quot;. So, when giving directions over the phone (for those who don&#039;t have a GPS or use Google Maps), they will state, &quot;so I make a left turn at the traffic light&quot; and she&#039;ll reply, &quot;right&quot;. Does she mean that the statement is correct, or does she mean that you make a RIGHT TURN? The communication needs to be clearer. It always helps to have a different set of eyes look through your communication, especially formal communication, to ensure that what you are saying has the same meaning to others.

Cheers!</description>
		<content:encoded><![CDATA[<p>@Ratan &#8211; you got it! When people can arrive at one consistent interpretation of your message, the communication is successful. If there can be a different interpretation than the one originally intended, it&#8217;s unsuccessful. For instance, my wife uses the word &#8220;right&#8221; to mean &#8220;OK, or correct&#8221;. So, when giving directions over the phone (for those who don&#8217;t have a GPS or use Google Maps), they will state, &#8220;so I make a left turn at the traffic light&#8221; and she&#8217;ll reply, &#8220;right&#8221;. Does she mean that the statement is correct, or does she mean that you make a RIGHT TURN? The communication needs to be clearer. It always helps to have a different set of eyes look through your communication, especially formal communication, to ensure that what you are saying has the same meaning to others.</p>
<p>Cheers!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Stop doing final document review meetings! by Jennifer Doyle</title>
		<link>http://www.b2ttraining.com/2011/12/29/stop-doing-final-document-review-meetings/comment-page-1/#comment-4060</link>
		<dc:creator>Jennifer Doyle</dc:creator>
		<pubDate>Mon, 09 Jan 2012 00:27:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2677#comment-4060</guid>
		<description>Great article Paul! I agree this is a much more efficient approach particularly if your project is going to result in a significant number of requirements. My meetings are exciting &amp; fun but no one can stay awake &amp; alert for a 4 hour marathon review session, right?

I also agree with your assessment on how a requirements management tool really helps with your model. I have been a big believer in RM tools as they make a huge difference compared to Excel or Word (yuck). I have used your suggested model using products from IBM and Borland (CaliberRM) and both worked great in this situation.  

Great suggestion - I look forward to hearing what others think!</description>
		<content:encoded><![CDATA[<p>Great article Paul! I agree this is a much more efficient approach particularly if your project is going to result in a significant number of requirements. My meetings are exciting &amp; fun but no one can stay awake &amp; alert for a 4 hour marathon review session, right?</p>
<p>I also agree with your assessment on how a requirements management tool really helps with your model. I have been a big believer in RM tools as they make a huge difference compared to Excel or Word (yuck). I have used your suggested model using products from IBM and Borland (CaliberRM) and both worked great in this situation.  </p>
<p>Great suggestion &#8211; I look forward to hearing what others think!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Stop doing final document review meetings! by Viki</title>
		<link>http://www.b2ttraining.com/2011/12/29/stop-doing-final-document-review-meetings/comment-page-1/#comment-4059</link>
		<dc:creator>Viki</dc:creator>
		<pubDate>Sun, 08 Jan 2012 09:15:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2677#comment-4059</guid>
		<description>Thanks Paul for sharing experience.
In my case, I&#039;ve notice people become reluctant to review again and again. As per my experience, your technique works well, because it drives off the fear of reviewing whole document in one go. That&#039;s why, in many cases, when asked to do final review, I got reply ...last comments in review are considered final. That is no more final review.</description>
		<content:encoded><![CDATA[<p>Thanks Paul for sharing experience.<br />
In my case, I&#8217;ve notice people become reluctant to review again and again. As per my experience, your technique works well, because it drives off the fear of reviewing whole document in one go. That&#8217;s why, in many cases, when asked to do final review, I got reply &#8230;last comments in review are considered final. That is no more final review.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Business Analysts&#8230;FYI by Ratan Upadhyay</title>
		<link>http://www.b2ttraining.com/2011/07/18/business-analysts-fyi/comment-page-1/#comment-4058</link>
		<dc:creator>Ratan Upadhyay</dc:creator>
		<pubDate>Sat, 07 Jan 2012 06:34:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2564#comment-4058</guid>
		<description>nice post...clear and correct communication is must for any project to run successfully and good  communication for a business analyst must .</description>
		<content:encoded><![CDATA[<p>nice post&#8230;clear and correct communication is must for any project to run successfully and good  communication for a business analyst must .</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Business Analysts&#8230;FYI by ba blogger</title>
		<link>http://www.b2ttraining.com/2011/07/18/business-analysts-fyi/comment-page-1/#comment-4053</link>
		<dc:creator>ba blogger</dc:creator>
		<pubDate>Sun, 27 Nov 2011 16:17:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/?p=2564#comment-4053</guid>
		<description>Thank you for the tip. Indeed, BA is the person who &quot;bridges the gap&quot; between the customer and the developers. So passing the info in the right manner is important.

Mike</description>
		<content:encoded><![CDATA[<p>Thank you for the tip. Indeed, BA is the person who &#8220;bridges the gap&#8221; between the customer and the developers. So passing the info in the right manner is important.</p>
<p>Mike</p>
]]></content:encoded>
	</item>
</channel>
</rss>

