<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Bob Lambert &#187; Business Case</title>
	<atom:link href="http://robertlambert.net/tag/business-case/feed/" rel="self" type="application/rss+xml" />
	<link>http://robertlambert.net</link>
	<description>on business-aligned information technology</description>
	<lastBuildDate>Fri, 04 May 2012 10:51:07 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Agile development: rugby analogy considered harmful</title>
		<link>http://robertlambert.net/2010/12/agile-development-rugby-analogy-considered-harmful/</link>
		<comments>http://robertlambert.net/2010/12/agile-development-rugby-analogy-considered-harmful/#comments</comments>
		<pubDate>Mon, 13 Dec 2010 17:53:39 +0000</pubDate>
		<dc:creator>Bob</dc:creator>
				<category><![CDATA[App Dev]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Project Management]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[Alignment]]></category>
		<category><![CDATA[Business Analysis]]></category>
		<category><![CDATA[Business Case]]></category>
		<category><![CDATA[Requirements]]></category>

		<guid isPermaLink="false">http://robertlambert.net/?p=1037</guid>
		<description><![CDATA[Recently my friend Mark Hudson posted about the inappropriateness of the term &#8220;sprint&#8221; for an agile project phase, preferring the cycling term &#8220;interval.&#8221; That post really struck a chord with me. As a rugby union fan and former wing/fullback I&#8217;ve always thought the whole rugby analogy was wrong. Agile development is continuous and fluid, yet <a href='http://robertlambert.net/2010/12/agile-development-rugby-analogy-considered-harmful/' class='excerpt-more'>[...]</a>]]></description>
		<wfw:commentRss>http://robertlambert.net/2010/12/agile-development-rugby-analogy-considered-harmful/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Business requirements up front</title>
		<link>http://robertlambert.net/2010/03/plan-decide-ac/</link>
		<comments>http://robertlambert.net/2010/03/plan-decide-ac/#comments</comments>
		<pubDate>Wed, 31 Mar 2010 20:38:03 +0000</pubDate>
		<dc:creator>Bob</dc:creator>
				<category><![CDATA[IT]]></category>
		<category><![CDATA[Alignment]]></category>
		<category><![CDATA[Business Analysis]]></category>
		<category><![CDATA[Business Case]]></category>
		<category><![CDATA[Project Management]]></category>
		<category><![CDATA[Requirements]]></category>
		<category><![CDATA[Strategy]]></category>

		<guid isPermaLink="false">http://robertlambert.net/?p=866</guid>
		<description><![CDATA[&#8220;Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success.&#8221; &#8211; Pablo Picasso It is an old story: about 30% of IT application projects succeed, 45% are &#8220;challenged,&#8221; and the other quarter fail <a href='http://robertlambert.net/2010/03/plan-decide-ac/' class='excerpt-more'>[...]</a>]]></description>
		<wfw:commentRss>http://robertlambert.net/2010/03/plan-decide-ac/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>BI Business Case Basics: Three Things to Remember</title>
		<link>http://robertlambert.net/2009/07/bi-business-case-basics-three-things-to-remember/</link>
		<comments>http://robertlambert.net/2009/07/bi-business-case-basics-three-things-to-remember/#comments</comments>
		<pubDate>Tue, 28 Jul 2009 11:33:26 +0000</pubDate>
		<dc:creator>Bob</dc:creator>
				<category><![CDATA[Data Management]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Project Management]]></category>
		<category><![CDATA[Alignment]]></category>
		<category><![CDATA[Business Case]]></category>
		<category><![CDATA[Business Intelligence]]></category>
		<category><![CDATA[CapTech]]></category>
		<category><![CDATA[Strategy]]></category>

		<guid isPermaLink="false">http://robertlambert.net/?p=587</guid>
		<description><![CDATA[Here are three things to remember when putting together a BI business case: Intangible benefits don’t count. BI has no inherent value. Senior managers often make decisions about future outcomes with insufficient data. Intangible Benefits Don’t Count: An effective business case communicates tangible future value in a convincing way.  An argument has a chance of <a href='http://robertlambert.net/2009/07/bi-business-case-basics-three-things-to-remember/' class='excerpt-more'>[...]</a>]]></description>
		<wfw:commentRss>http://robertlambert.net/2009/07/bi-business-case-basics-three-things-to-remember/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DQ, he isn&#8217;t so dumb he just needs glasses</title>
		<link>http://robertlambert.net/2009/05/dq-he-isnt-so-dumb-he-just-needs-glasses/</link>
		<comments>http://robertlambert.net/2009/05/dq-he-isnt-so-dumb-he-just-needs-glasses/#comments</comments>
		<pubDate>Sun, 03 May 2009 20:58:48 +0000</pubDate>
		<dc:creator>Bob</dc:creator>
				<category><![CDATA[Data Management]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Project Management]]></category>
		<category><![CDATA[Alignment]]></category>
		<category><![CDATA[Business Case]]></category>
		<category><![CDATA[CapTech]]></category>
		<category><![CDATA[Data Modeling]]></category>
		<category><![CDATA[Data Quality]]></category>
		<category><![CDATA[Requirements]]></category>
		<category><![CDATA[Strategy]]></category>

		<guid isPermaLink="false">http://robertlambert.net/?p=418</guid>
		<description><![CDATA[In a recent very thoughtful post on data quality, Paul Erb plays out an analogy comparing data users with Don Quixote and data quality professionals with Sancho Panza, then reverses the analogy to cleverly coin the &#8220;Sancho Panza&#8221; test of data quality professionals.  He encourages data quality professionals promoting the critical role of data quality <a href='http://robertlambert.net/2009/05/dq-he-isnt-so-dumb-he-just-needs-glasses/' class='excerpt-more'>[...]</a>]]></description>
		<wfw:commentRss>http://robertlambert.net/2009/05/dq-he-isnt-so-dumb-he-just-needs-glasses/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Do your homework before presenting a BI business case</title>
		<link>http://robertlambert.net/2009/03/do-your-homework-before-presenting-a-bi-business-case/</link>
		<comments>http://robertlambert.net/2009/03/do-your-homework-before-presenting-a-bi-business-case/#comments</comments>
		<pubDate>Wed, 25 Mar 2009 16:32:11 +0000</pubDate>
		<dc:creator>Bob</dc:creator>
				<category><![CDATA[IT]]></category>
		<category><![CDATA[Project Management]]></category>
		<category><![CDATA[Business Case]]></category>
		<category><![CDATA[Business Intelligence]]></category>
		<category><![CDATA[CapTech]]></category>

		<guid isPermaLink="false">http://robertlambert.net/?p=290</guid>
		<description><![CDATA[Before starting the Business Intelligence business case, the BI advocate should do the homework required to ensure its success, including these essential steps: 1. Know the organization’s goals and objectives. 2. Identify a BI champion. 3. Identify and work with BI stakeholders. 4. Identify an application with tangible business value. 5. Define and quantify a <a href='http://robertlambert.net/2009/03/do-your-homework-before-presenting-a-bi-business-case/' class='excerpt-more'>[...]</a>]]></description>
		<wfw:commentRss>http://robertlambert.net/2009/03/do-your-homework-before-presenting-a-bi-business-case/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Big project coming up?  Learn to two-step.</title>
		<link>http://robertlambert.net/2009/03/big-project-two-step/</link>
		<comments>http://robertlambert.net/2009/03/big-project-two-step/#comments</comments>
		<pubDate>Fri, 06 Mar 2009 23:14:02 +0000</pubDate>
		<dc:creator>Bob</dc:creator>
				<category><![CDATA[IT]]></category>
		<category><![CDATA[Project Management]]></category>
		<category><![CDATA[Business Case]]></category>
		<category><![CDATA[Requirements]]></category>
		<category><![CDATA[Strategy]]></category>

		<guid isPermaLink="false">http://robertlambert.net/?p=185</guid>
		<description><![CDATA[History is littered with IT application projects that end late, go way over budget, or abandoned altogether.  I was fortunate enough to see one work out really well (almost &#8211; please read on).  It was no mistake.  It came down to a simple method advocated by a gentleman named named John Carpenter. The project was <a href='http://robertlambert.net/2009/03/big-project-two-step/' class='excerpt-more'>[...]</a>]]></description>
		<wfw:commentRss>http://robertlambert.net/2009/03/big-project-two-step/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

