<?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: User Adoption ROI</title>
	<atom:link href="http://tynerblain.com/blog/2008/01/17/user-adoption-roi/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2008/01/17/user-adoption-roi/</link>
	<description>Software product success.</description>
	<lastBuildDate>Sat, 11 Feb 2012 22:57:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: David Locke</title>
		<link>http://tynerblain.com/blog/2008/01/17/user-adoption-roi/comment-page-1/#comment-477642</link>
		<dc:creator>David Locke</dc:creator>
		<pubDate>Thu, 12 Feb 2009 19:15:59 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2008/01/17/user-adoption-roi/#comment-477642</guid>
		<description>Designers, who design based on ethnographic research aiming for fitness to meaning can speed up adoption. Otherwise, design can just be a smokescreen. I&#039;m not going to adopt it, because it looks nice. 

The assumption that you save $1 per use is mystical. Under the TCO, you can&#039;t get more than a 3% ROI from any software. And, the TCO hides negative use costs like the costs accrued while users become competent with the software. These costs are invisible, implicit, and are never accounted for. They become part of the corporation&#039;s cost structure. 

We used a database application, but had to rework the data for hours to create our report. Then, we had to eyeball the base reports to find what the software could not tell us. The underlying problem was that our needs were in the GIS sphere while the database was relational. Sad. There was no fitness between our needs and meanings relative to that application. No use ever generated any ROI when we used it. None. 

They were even implementng a new system, but it was still relational. 

The TCO has a component called the infrastructural multiple. As we have added lan/wan/wifi/cell to applications, that multiple has increased. That multiple is a divisor of the underlying ROI. Maybe SaaS eliminates these costs for the user, but on the vendor&#039;s side those costs remain and drive the minimum cost at which the functionality can be provided.</description>
		<content:encoded><![CDATA[<p>Designers, who design based on ethnographic research aiming for fitness to meaning can speed up adoption. Otherwise, design can just be a smokescreen. I&#8217;m not going to adopt it, because it looks nice. </p>
<p>The assumption that you save $1 per use is mystical. Under the TCO, you can&#8217;t get more than a 3% ROI from any software. And, the TCO hides negative use costs like the costs accrued while users become competent with the software. These costs are invisible, implicit, and are never accounted for. They become part of the corporation&#8217;s cost structure. </p>
<p>We used a database application, but had to rework the data for hours to create our report. Then, we had to eyeball the base reports to find what the software could not tell us. The underlying problem was that our needs were in the GIS sphere while the database was relational. Sad. There was no fitness between our needs and meanings relative to that application. No use ever generated any ROI when we used it. None. </p>
<p>They were even implementng a new system, but it was still relational. </p>
<p>The TCO has a component called the infrastructural multiple. As we have added lan/wan/wifi/cell to applications, that multiple has increased. That multiple is a divisor of the underlying ROI. Maybe SaaS eliminates these costs for the user, but on the vendor&#8217;s side those costs remain and drive the minimum cost at which the functionality can be provided.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2008/01/17/user-adoption-roi/comment-page-1/#comment-477631</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Thu, 12 Feb 2009 18:33:01 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2008/01/17/user-adoption-roi/#comment-477631</guid>
		<description>Thanks Craig!  Every team that I&#039;ve worked with has struggled to make traction with a &quot;justify investments in good design&quot; approach.  We can all logically see that better products drive higher user adoption.  Seemed like a good way to connect those dots.</description>
		<content:encoded><![CDATA[<p>Thanks Craig!  Every team that I&#8217;ve worked with has struggled to make traction with a &#8220;justify investments in good design&#8221; approach.  We can all logically see that better products drive higher user adoption.  Seemed like a good way to connect those dots.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig Brown</title>
		<link>http://tynerblain.com/blog/2008/01/17/user-adoption-roi/comment-page-1/#comment-272713</link>
		<dc:creator>Craig Brown</dc:creator>
		<pubDate>Sun, 20 Jan 2008 07:17:20 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2008/01/17/user-adoption-roi/#comment-272713</guid>
		<description>Scott
Another excellent article. I am looking forard to the book!</description>
		<content:encoded><![CDATA[<p>Scott<br />
Another excellent article. I am looking forard to the book!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

