<?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: Dinner with a menu or without?</title>
	<atom:link href="http://www.b2ttraining.com/2008/04/07/dinner-with-a-menu-or-without/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.b2ttraining.com/2008/04/07/dinner-with-a-menu-or-without/</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>By: Angie</title>
		<link>http://www.b2ttraining.com/2008/04/07/dinner-with-a-menu-or-without/comment-page-1/#comment-2543</link>
		<dc:creator>Angie</dc:creator>
		<pubDate>Wed, 07 May 2008 18:39:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/page/business-analyst-blog/archives/132/dinner-with-a-menu-or-without#comment-2543</guid>
		<description>Andrew - I agree that many business stakeholders are interested in documentation One reason is because they need to explain or train the impact of systems changes to the rest of their organizations. I would like to think that no one creates documentation for job security. I think you are referring to the deliverable sign-offs (as job security) which is more of an IT project management effort to protect themselves if the business says they are unhappy with the resulting software system. They can say your sign-off was on the detailed documents, and the software is built per specs. Although that may be true (and binding) - does that lead to a happy, satisfied customer? Is the project deemed successful in that case? I would say no. By the way the BA has failed in communicating clearly with the stakeholders. I think that is why agile development began with a focus on producing less documentation- &#034;only what is necessary&#034;. Agile thought leaders say that there has been too much focus on documents and not enough on whether the customer getting the software that they need. I absolutely agree that we should only produce documentation that adds value.</description>
		<content:encoded><![CDATA[<p>Andrew &#8211; I agree that many business stakeholders are interested in documentation One reason is because they need to explain or train the impact of systems changes to the rest of their organizations. I would like to think that no one creates documentation for job security. I think you are referring to the deliverable sign-offs (as job security) which is more of an IT project management effort to protect themselves if the business says they are unhappy with the resulting software system. They can say your sign-off was on the detailed documents, and the software is built per specs. Although that may be true (and binding) &#8211; does that lead to a happy, satisfied customer? Is the project deemed successful in that case? I would say no. By the way the BA has failed in communicating clearly with the stakeholders. I think that is why agile development began with a focus on producing less documentation- &#38;#34;only what is necessary&#38;#34;. Agile thought leaders say that there has been too much focus on documents and not enough on whether the customer getting the software that they need. I absolutely agree that we should only produce documentation that adds value.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew</title>
		<link>http://www.b2ttraining.com/2008/04/07/dinner-with-a-menu-or-without/comment-page-1/#comment-2542</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Wed, 07 May 2008 10:01:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/page/business-analyst-blog/archives/132/dinner-with-a-menu-or-without#comment-2542</guid>
		<description>From my experience, normally the user is the party who keep chasing after documentations. They treat documentation as important as the system and must be ready before the system ready. Documents like system and functional specs, design details, data dictionary, user guide, deployment guide etc are used by them to safe guard their job, where any discrepancy between the system and business needs, those documents are the judges. In fact these documents are important for the development team too as proof of requirements sign off.</description>
		<content:encoded><![CDATA[<p>From my experience, normally the user is the party who keep chasing after documentations. They treat documentation as important as the system and must be ready before the system ready. Documents like system and functional specs, design details, data dictionary, user guide, deployment guide etc are used by them to safe guard their job, where any discrepancy between the system and business needs, those documents are the judges. In fact these documents are important for the development team too as proof of requirements sign off.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

