<?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: Don&#8217;t forget to share business context with your technical team</title>
	<atom:link href="http://www.bridging-the-gap.com/dont-forget-to-share-business-context-with-your-technical-team/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bridging-the-gap.com/dont-forget-to-share-business-context-with-your-technical-team/</link>
	<description>Advance Your Business Analysis Career</description>
	<lastBuildDate>Thu, 09 Feb 2012 00:08:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Richard Lynn Paul</title>
		<link>http://www.bridging-the-gap.com/dont-forget-to-share-business-context-with-your-technical-team/comment-page-1/#comment-500</link>
		<dc:creator>Richard Lynn Paul</dc:creator>
		<pubDate>Tue, 05 May 2009 20:33:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=452#comment-500</guid>
		<description>Similar to how programmers sometimes make prototypes, the User&#039;s Guides written by the Business Analyst would have mock-ups of what the screens would look like.  The programmers usually had these within 2 days of the Feature Blitzes and the designs would change by the two-way communication they engendered.  That is, the programmer would suggest a better way for some sub-feature or button and the BA would change the design.  Likewise, the programmer would actually program what the BA had hoped for as the pictures left less room for misinterpretation.  The programmer would then give actual screenshots to the BA or the BA would get them his/herself from a code drop to replace the mock-ups with actual screenshots in the User&#039;s Guide.</description>
		<content:encoded><![CDATA[<p>Similar to how programmers sometimes make prototypes, the User&#8217;s Guides written by the Business Analyst would have mock-ups of what the screens would look like.  The programmers usually had these within 2 days of the Feature Blitzes and the designs would change by the two-way communication they engendered.  That is, the programmer would suggest a better way for some sub-feature or button and the BA would change the design.  Likewise, the programmer would actually program what the BA had hoped for as the pictures left less room for misinterpretation.  The programmer would then give actual screenshots to the BA or the BA would get them his/herself from a code drop to replace the mock-ups with actual screenshots in the User&#8217;s Guide.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laura Brandau</title>
		<link>http://www.bridging-the-gap.com/dont-forget-to-share-business-context-with-your-technical-team/comment-page-1/#comment-146</link>
		<dc:creator>Laura Brandau</dc:creator>
		<pubDate>Sun, 08 Feb 2009 01:02:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=452#comment-146</guid>
		<description>Hi Derek,
Excellent point.  Making the transition from sharing to collaboration on how to solve the business problem is key.
Laura</description>
		<content:encoded><![CDATA[<p>Hi Derek,<br />
Excellent point.  Making the transition from sharing to collaboration on how to solve the business problem is key.<br />
Laura</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Derek Winter</title>
		<link>http://www.bridging-the-gap.com/dont-forget-to-share-business-context-with-your-technical-team/comment-page-1/#comment-143</link>
		<dc:creator>Derek Winter</dc:creator>
		<pubDate>Fri, 06 Feb 2009 00:35:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=452#comment-143</guid>
		<description>A very important post Laura. I would go one step further however and rather than just suggesting that &quot;everyone deserves the opportunity to understand the larger context&quot; I would assert that without that larger context the quality and value of the outcome will jeapordised and probably diminished.

Related to this is the commitment and &#039;buy-in&#039; you get from people is greatly increased by the increased level of information and communication.  Simply &#039;telling&#039; someone what they have to do is the bottom rung on the scale, and ensures a transactional approach aswell as a lack of buyin. At the very least, being able to &#039;sell&#039; the requirement (Here&#039;s why you need to do ...) provides some ability for people to get on board. Any opportuntiy to progress beyond that and get collaboration from people to help formulate the way forward, or ideally be able to &#039;co-create&#039; will produce vastly better results.</description>
		<content:encoded><![CDATA[<p>A very important post Laura. I would go one step further however and rather than just suggesting that &#8220;everyone deserves the opportunity to understand the larger context&#8221; I would assert that without that larger context the quality and value of the outcome will jeapordised and probably diminished.</p>
<p>Related to this is the commitment and &#8216;buy-in&#8217; you get from people is greatly increased by the increased level of information and communication.  Simply &#8216;telling&#8217; someone what they have to do is the bottom rung on the scale, and ensures a transactional approach aswell as a lack of buyin. At the very least, being able to &#8216;sell&#8217; the requirement (Here&#8217;s why you need to do &#8230;) provides some ability for people to get on board. Any opportuntiy to progress beyond that and get collaboration from people to help formulate the way forward, or ideally be able to &#8216;co-create&#8217; will produce vastly better results.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

