<?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/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: Adoption Can&#8217;t Be Driven</title>
	<atom:link href="http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/</link>
	<description></description>
	<lastBuildDate>Fri, 20 Nov 2009 20:29:35 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Paula Thornton</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-232587</link>
		<dc:creator>Paula Thornton</dc:creator>
		<pubDate>Thu, 16 Jul 2009 22:10:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-232587</guid>
		<description>Barry: You are really good at summarizing our exchanges. Thanks!

Cultures of command and control will collectively fail at E2.0. Such tools can provide some hope and sanity to pockets of individuals to &#039;escape&#039; the mind-numbing culture they operate in, but in isolation, the tools will fail to capitalize on their true potential to minimize transaction costs across the company.

Governance Model is a term I hesitate to use only because most examples are bad ones -- just more command and control. The goal of such a beast is more of a Collaborative Governance Agreement -- what we all agree will help this knowledge economy thrive.

Hmmm, thanks for the opportunity to reference that in this context -- knowledge economy. While it&#039;s a term that has been used in many other contexts, I believe it has particular relevance in this context that we need to consider more deeply. If you find any related references please send them along; all the ones I&#039;ve found are not specific to this context.</description>
		<content:encoded><![CDATA[<p>Barry: You are really good at summarizing our exchanges. Thanks!</p>
<p>Cultures of command and control will collectively fail at E2.0. Such tools can provide some hope and sanity to pockets of individuals to &#8216;escape&#8217; the mind-numbing culture they operate in, but in isolation, the tools will fail to capitalize on their true potential to minimize transaction costs across the company.</p>
<p>Governance Model is a term I hesitate to use only because most examples are bad ones &#8212; just more command and control. The goal of such a beast is more of a Collaborative Governance Agreement &#8212; what we all agree will help this knowledge economy thrive.</p>
<p>Hmmm, thanks for the opportunity to reference that in this context &#8212; knowledge economy. While it&#8217;s a term that has been used in many other contexts, I believe it has particular relevance in this context that we need to consider more deeply. If you find any related references please send them along; all the ones I&#8217;ve found are not specific to this context.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barry Camson</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-232434</link>
		<dc:creator>Barry Camson</dc:creator>
		<pubDate>Wed, 15 Jul 2009 13:54:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-232434</guid>
		<description>Paula,

It appears that in our respective comments we are scoping out a chronological definition of design from the upstream end of technical platform design through the application to the user and then to the behavioral and organizational configurations that provide the downstream context for the technology&#039;s use. Your comments and expertise are helpful to me in fleshing out the upstream aspects of this. Where our respective comments appear to overlap is with regard to what you describe as the &quot;governance model.&quot; It is at this point, I am assuming, that the configuration of the technology and related agreements has the potential for facilitating adoption and a set of behaviors for openness and sharing. My perspective is that the further downstream support of congruent behaviors, norms, skills and organizational processes is important for impacting whether the user organization is in the Need to Know mode or the Need to Share mode (i.e. command and control or collaborative) and whether the use of the technology achieves the potential seen in its use in the general population.</description>
		<content:encoded><![CDATA[<p>Paula,</p>
<p>It appears that in our respective comments we are scoping out a chronological definition of design from the upstream end of technical platform design through the application to the user and then to the behavioral and organizational configurations that provide the downstream context for the technology&#8217;s use. Your comments and expertise are helpful to me in fleshing out the upstream aspects of this. Where our respective comments appear to overlap is with regard to what you describe as the &#8220;governance model.&#8221; It is at this point, I am assuming, that the configuration of the technology and related agreements has the potential for facilitating adoption and a set of behaviors for openness and sharing. My perspective is that the further downstream support of congruent behaviors, norms, skills and organizational processes is important for impacting whether the user organization is in the Need to Know mode or the Need to Share mode (i.e. command and control or collaborative) and whether the use of the technology achieves the potential seen in its use in the general population.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paula Thornton</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-232394</link>
		<dc:creator>Paula Thornton</dc:creator>
		<pubDate>Wed, 15 Jul 2009 04:41:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-232394</guid>
		<description>Barry:

There are two distinct phases of &#039;use&#039; of a product that are significantly relevant here. The &#039;use&#039; you spoke of relative to Facebook and the like is an &#039;end use&#039;. The most overlooked challenge for E2.0 is that most tools are &#039;platforms&#039; and they must be customized for &#039;end use&#039; -- by putting the tool within the context of use with in the business. This critical design is the crux of the win/lose proposition for E2.0 -- along with a strategy that includes a governance model -- a living one that adapts and adopts agreements as to roles and responsibilities and any agreed &#039;rules&#039; (a term I use lightly) or standard adopted conventions.

Buying E2.0 technologies for which the UI is fixed and final is NOT recommended (except for plug-ins -- functional adds to the platform).

The latter examples you gave are quite relevant. Sadly, I&#039;ve been in organizations where even communities for &#039;open source&#039; initiatives are locked down and highly controlled. That&#039;s the antithesis of what&#039;s needed for success.

Thanks for your contributions. I hope I didn&#039;t misunderstand or take too many liberties with your response.</description>
		<content:encoded><![CDATA[<p>Barry:</p>
<p>There are two distinct phases of &#8216;use&#8217; of a product that are significantly relevant here. The &#8216;use&#8217; you spoke of relative to Facebook and the like is an &#8216;end use&#8217;. The most overlooked challenge for E2.0 is that most tools are &#8216;platforms&#8217; and they must be customized for &#8216;end use&#8217; &#8212; by putting the tool within the context of use with in the business. This critical design is the crux of the win/lose proposition for E2.0 &#8212; along with a strategy that includes a governance model &#8212; a living one that adapts and adopts agreements as to roles and responsibilities and any agreed &#8216;rules&#8217; (a term I use lightly) or standard adopted conventions.</p>
<p>Buying E2.0 technologies for which the UI is fixed and final is NOT recommended (except for plug-ins &#8212; functional adds to the platform).</p>
<p>The latter examples you gave are quite relevant. Sadly, I&#8217;ve been in organizations where even communities for &#8216;open source&#8217; initiatives are locked down and highly controlled. That&#8217;s the antithesis of what&#8217;s needed for success.</p>
<p>Thanks for your contributions. I hope I didn&#8217;t misunderstand or take too many liberties with your response.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barry Camson</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-232201</link>
		<dc:creator>Barry Camson</dc:creator>
		<pubDate>Mon, 13 Jul 2009 15:20:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-232201</guid>
		<description>Paula,

I think one of the issues you are raising is that of symantic corporate-speak . The terms &quot;solution&quot; and &quot;driving&quot; are part of the mainstream in the corporate world. My sense is that they are often used in a broader vein than intended. They may also be used to meet the client where the client is at. I remember a time when these terms represented a step forward in terms of progress. However, now these terms do carry the set of meanings that you talk about. Although they may not equate to a command and control mentality, they do reflect that a solution to a problem can be arrived at and its implementation can be driven from afar regardless of where others are at. There are situations where the approach represented by these terms is a helpful one. I agree that Ent 2.0 expansion is not one of these. I think when we find ourselves using these terms, we need to stop and question whether what they reflect is helpful to our endeavors.

For the purpose of Socratic dialogue, we can also take a look at the word &quot;design.&quot; Though the scope of this term does include members of an organization participating in a design that they then implement, it does seem to diverge from what you were describing in terms of expanding the utilization of Ent 2.0. Though architects and developers had to do some design work, the use of Facebook, Twitter, blogging, wikis among the general population occurs without any kind of design. This is more in line with chaos theory than any Newtonian sense of purposefulness. Even the developers of the technology who likely had some intention of usage of their products must realize that emerging reality can quickly trump such intentions. I think when we use the term &quot;design&quot; we must be clear about what we are intending, what are assumptions are and whether this is the appropriate term for the situation at hand.

I see a progression in terms of the use of the &quot;design&quot; approach over time. For many years, I was a practitioner of Socio-Technical Design. In this approach, a representative design team created an organization or process design which was then implemented by a representative implementation team. In time, what the design team created was seen as only a blueprint which the teams fleshed out and implemented. As time went on, design was seen as an activity of all of the organization assembled together who then went on to participate in implementation planning. This was still a linear approach. This was then followed by Open Space Systems in which the entire organization (as much as was feasible) participated in a more emergent process. The term &quot;design&quot; was at best loosely applied to that. Now, Ent 2.0 expansion seems to have moved beyond this. I believe that there are limitations to all of these approaches as well likely be the case with Ent 2.0. In those situations, maybe what will be necessary is some good old fashioned design. Even here, I agree that driving solutions in this day and age will come up short.</description>
		<content:encoded><![CDATA[<p>Paula,</p>
<p>I think one of the issues you are raising is that of symantic corporate-speak . The terms &#8220;solution&#8221; and &#8220;driving&#8221; are part of the mainstream in the corporate world. My sense is that they are often used in a broader vein than intended. They may also be used to meet the client where the client is at. I remember a time when these terms represented a step forward in terms of progress. However, now these terms do carry the set of meanings that you talk about. Although they may not equate to a command and control mentality, they do reflect that a solution to a problem can be arrived at and its implementation can be driven from afar regardless of where others are at. There are situations where the approach represented by these terms is a helpful one. I agree that Ent 2.0 expansion is not one of these. I think when we find ourselves using these terms, we need to stop and question whether what they reflect is helpful to our endeavors.</p>
<p>For the purpose of Socratic dialogue, we can also take a look at the word &#8220;design.&#8221; Though the scope of this term does include members of an organization participating in a design that they then implement, it does seem to diverge from what you were describing in terms of expanding the utilization of Ent 2.0. Though architects and developers had to do some design work, the use of Facebook, Twitter, blogging, wikis among the general population occurs without any kind of design. This is more in line with chaos theory than any Newtonian sense of purposefulness. Even the developers of the technology who likely had some intention of usage of their products must realize that emerging reality can quickly trump such intentions. I think when we use the term &#8220;design&#8221; we must be clear about what we are intending, what are assumptions are and whether this is the appropriate term for the situation at hand.</p>
<p>I see a progression in terms of the use of the &#8220;design&#8221; approach over time. For many years, I was a practitioner of Socio-Technical Design. In this approach, a representative design team created an organization or process design which was then implemented by a representative implementation team. In time, what the design team created was seen as only a blueprint which the teams fleshed out and implemented. As time went on, design was seen as an activity of all of the organization assembled together who then went on to participate in implementation planning. This was still a linear approach. This was then followed by Open Space Systems in which the entire organization (as much as was feasible) participated in a more emergent process. The term &#8220;design&#8221; was at best loosely applied to that. Now, Ent 2.0 expansion seems to have moved beyond this. I believe that there are limitations to all of these approaches as well likely be the case with Ent 2.0. In those situations, maybe what will be necessary is some good old fashioned design. Even here, I agree that driving solutions in this day and age will come up short.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paula Thornton</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-232073</link>
		<dc:creator>Paula Thornton</dc:creator>
		<pubDate>Mon, 13 Jul 2009 01:51:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-232073</guid>
		<description>James: Thanks for jumping into the conversation from Australia (I&#039;m currently watching an old presentation of Richard Feynman he gave at a conference in New Zealand -- so I&#039;m feeling a close connection right now : ).

The only challenge I&#039;d offer back is that while something might be &#039;labeled&#039; E2.0 doesn&#039;t make it so. To embrace the true intents of E2.0, an effort/solution &#039;would&#039; be easier (more direct/specific) and more natural for staff. In the end it&#039;s all semantics, because people will call things whatever they want, without regard for the real intent. 

I will still stand by the fact that if efforts don&#039;t accomplish such things they not really E2.0 initiatives -- they don&#039;t qualify for the definition -- they&#039;re just a badly implemented &#039;project&#039;. But we know if a project is submitted for funding under an E2.0 label (thus showing up for months on reports labeled &quot;Enterprise 2.0&quot;) and fails, then it&#039;s E2.0 that takes the &#039;hit&#039; not the badly implemented project.</description>
		<content:encoded><![CDATA[<p>James: Thanks for jumping into the conversation from Australia (I&#8217;m currently watching an old presentation of Richard Feynman he gave at a conference in New Zealand &#8212; so I&#8217;m feeling a close connection right now : ).</p>
<p>The only challenge I&#8217;d offer back is that while something might be &#8216;labeled&#8217; E2.0 doesn&#8217;t make it so. To embrace the true intents of E2.0, an effort/solution &#8216;would&#8217; be easier (more direct/specific) and more natural for staff. In the end it&#8217;s all semantics, because people will call things whatever they want, without regard for the real intent. </p>
<p>I will still stand by the fact that if efforts don&#8217;t accomplish such things they not really E2.0 initiatives &#8212; they don&#8217;t qualify for the definition &#8212; they&#8217;re just a badly implemented &#8216;project&#8217;. But we know if a project is submitted for funding under an E2.0 label (thus showing up for months on reports labeled &#8220;Enterprise 2.0&#8243;) and fails, then it&#8217;s E2.0 that takes the &#8216;hit&#8217; not the badly implemented project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Robertson</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-232054</link>
		<dc:creator>James Robertson</dc:creator>
		<pubDate>Sun, 12 Jul 2009 23:17:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-232054</guid>
		<description>Hi Paula, I agree completely that we can&#039;t &quot;drive&quot; adoption!

I also agree that up-front design is the key, and would argue that we can &quot;design for adoption&quot;. Too many tools are either:

a) thrown out to the wider staff population, with little more than the rose-tinted hope that they&#039;ll be used

b) really poorly designed for staff to use the tools (see most corporate software)

Every enterprise project should take the time to understand the staff environment and working practices in depth. This involves going out into the field, watching and listening, asking questions.

Only then can enterprise &amp; enterprise 2.0 solutions really be designed for success. (Enterprise 2.0 solutions are not automatically easier or more natural for staff.)

Cheers, James</description>
		<content:encoded><![CDATA[<p>Hi Paula, I agree completely that we can&#8217;t &#8220;drive&#8221; adoption!</p>
<p>I also agree that up-front design is the key, and would argue that we can &#8220;design for adoption&#8221;. Too many tools are either:</p>
<p>a) thrown out to the wider staff population, with little more than the rose-tinted hope that they&#8217;ll be used</p>
<p>b) really poorly designed for staff to use the tools (see most corporate software)</p>
<p>Every enterprise project should take the time to understand the staff environment and working practices in depth. This involves going out into the field, watching and listening, asking questions.</p>
<p>Only then can enterprise &amp; enterprise 2.0 solutions really be designed for success. (Enterprise 2.0 solutions are not automatically easier or more natural for staff.)</p>
<p>Cheers, James</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paula Thornton</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-231716</link>
		<dc:creator>Paula Thornton</dc:creator>
		<pubDate>Fri, 10 Jul 2009 22:07:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-231716</guid>
		<description>I figured there was a &#039;design&#039; disconnect. It&#039;s the biggest one we face, which is why I keep repeating it (&quot;the floggings will continue...&quot; : )

Per my tweetstream to you:

Rather than drive, push, pull -- movement occurs by mutual attraction: draw (this is a fundamental principle of complexity sciences ala. self organization -- per Stuart Kauffman, it&#039;s &quot;energy for free&quot;). But that&#039;s the &#039;lesser&#039; goal. The FIRST goal is to simply GO to where they are. Meet them. While that can be taken literally, it&#039;s more figurative. It&#039;s about figuring out what activity they&#039;re doing and embed function.

 Applications require that people &#039;go&#039; to them. Applications are dead. Living functions simply present themselves in context. The only place anyone should ever have to &#039;go&#039; is the browser...browser as platform. It&#039;s about architecture. The most relevant example of the concept of &#039;here&#039; (wherever &quot;I&quot; am) is Google Wave. The functions are ubiquitous.</description>
		<content:encoded><![CDATA[<p>I figured there was a &#8216;design&#8217; disconnect. It&#8217;s the biggest one we face, which is why I keep repeating it (&#8221;the floggings will continue&#8230;&#8221; : )</p>
<p>Per my tweetstream to you:</p>
<p>Rather than drive, push, pull &#8212; movement occurs by mutual attraction: draw (this is a fundamental principle of complexity sciences ala. self organization &#8212; per Stuart Kauffman, it&#8217;s &#8220;energy for free&#8221;). But that&#8217;s the &#8216;lesser&#8217; goal. The FIRST goal is to simply GO to where they are. Meet them. While that can be taken literally, it&#8217;s more figurative. It&#8217;s about figuring out what activity they&#8217;re doing and embed function.</p>
<p> Applications require that people &#8216;go&#8217; to them. Applications are dead. Living functions simply present themselves in context. The only place anyone should ever have to &#8216;go&#8217; is the browser&#8230;browser as platform. It&#8217;s about architecture. The most relevant example of the concept of &#8216;here&#8217; (wherever &#8220;I&#8221; am) is Google Wave. The functions are ubiquitous.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Harbridge</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-231714</link>
		<dc:creator>Richard Harbridge</dc:creator>
		<pubDate>Fri, 10 Jul 2009 21:59:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-231714</guid>
		<description>Ah! I think I see what you are saying here. That definition of design is definitely not the context I was using/thinking.

The little puzzle pieces are now set in place in my mind, appreciate the clarification as to what &#039;design&#039; represents to you. 

Also I will toss this in here since I put it on twitter and maybe everyone else isn&#039;t following/seeing those: 

rharbridge: I like &#039;pull&#039;. It&#039;s hard for me to think outside/in a situation where you don&#039;t pull. A.K.A - Does good design pull? Or rather: adoption is perceived as movement or change to me. Without drive (push/pull) how can things move? (Based on physics example.)

Thanks again,
Richard Harbridge</description>
		<content:encoded><![CDATA[<p>Ah! I think I see what you are saying here. That definition of design is definitely not the context I was using/thinking.</p>
<p>The little puzzle pieces are now set in place in my mind, appreciate the clarification as to what &#8216;design&#8217; represents to you. </p>
<p>Also I will toss this in here since I put it on twitter and maybe everyone else isn&#8217;t following/seeing those: </p>
<p>rharbridge: I like &#8216;pull&#8217;. It&#8217;s hard for me to think outside/in a situation where you don&#8217;t pull. A.K.A &#8211; Does good design pull? Or rather: adoption is perceived as movement or change to me. Without drive (push/pull) how can things move? (Based on physics example.)</p>
<p>Thanks again,<br />
Richard Harbridge</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paula Thornton</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-231711</link>
		<dc:creator>Paula Thornton</dc:creator>
		<pubDate>Fri, 10 Jul 2009 21:48:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-231711</guid>
		<description>Richard: Thanks for keeping at obtaining clarity. Your points are all valid and are &#039;typical&#039; perspectives (if it weren&#039;t for people like you who can talk to the others who talk your language, the rest of us would be in trouble).

1. There&#039;s a difference between &#039;reactions&#039; and true issues that need to be solved. I&#039;ve seen far too many development teams respond to the wrong issues -- they can&#039;t differentiate between what&#039;s relevant and what&#039;s just &#039;noise&#039;. But then that shouldn&#039;t be their job. The REAL problem is that the teams lack true designers who DO know how to differentiate these things an apply them effectively.

2. Design has to accept ALL responsibility for the success of the solution (again, do not think &#039;visual&#039; when considering the breadth of design -- it&#039;s a total experience, of which &quot;response time&quot; is part of that). Any relevant rejection of a solution HAS to be considered a design failure. That means that no one design fits all situations or people. You can&#039;t just plug in a solution, it has to be &#039;fitted&#039; to the context of its use. Any &#039;rejection&#039; of that is simply a sign that the design is flawed and more work needs to be done. Typically, implementers just stand up solutions and haven&#039;t the vaguest idea how to assess for or accommodate cultures and work habits. 

3. ALL solutions must be customized, period.</description>
		<content:encoded><![CDATA[<p>Richard: Thanks for keeping at obtaining clarity. Your points are all valid and are &#8216;typical&#8217; perspectives (if it weren&#8217;t for people like you who can talk to the others who talk your language, the rest of us would be in trouble).</p>
<p>1. There&#8217;s a difference between &#8216;reactions&#8217; and true issues that need to be solved. I&#8217;ve seen far too many development teams respond to the wrong issues &#8212; they can&#8217;t differentiate between what&#8217;s relevant and what&#8217;s just &#8216;noise&#8217;. But then that shouldn&#8217;t be their job. The REAL problem is that the teams lack true designers who DO know how to differentiate these things an apply them effectively.</p>
<p>2. Design has to accept ALL responsibility for the success of the solution (again, do not think &#8216;visual&#8217; when considering the breadth of design &#8212; it&#8217;s a total experience, of which &#8220;response time&#8221; is part of that). Any relevant rejection of a solution HAS to be considered a design failure. That means that no one design fits all situations or people. You can&#8217;t just plug in a solution, it has to be &#8216;fitted&#8217; to the context of its use. Any &#8216;rejection&#8217; of that is simply a sign that the design is flawed and more work needs to be done. Typically, implementers just stand up solutions and haven&#8217;t the vaguest idea how to assess for or accommodate cultures and work habits. </p>
<p>3. ALL solutions must be customized, period.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Harbridge</title>
		<link>http://www.fastforwardblog.com/2009/07/09/adoption-cant-be-driven/comment-page-1/#comment-231709</link>
		<dc:creator>Richard Harbridge</dc:creator>
		<pubDate>Fri, 10 Jul 2009 21:28:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.fastforwardblog.com/?p=3020#comment-231709</guid>
		<description>I see what you are saying and where you are coming from. I think I also forgot before to say I really liked the article, and think overall it does provide some really good points and a good message.

From a design perspective I completely agree that the design should be constantly improved overtime which (if successful) will ‘drive’ (pull) more users along and into it because it is more useful, beneficial or more easily understood. Realistically though this point alone disrupts the initial statement I was against which is that adoption cannot be driven. What you really seem to be saying here is that good effective and continual design will drive adoption of a system.

Certainly you need shared understanding of value from those who implement something and those who use something. (I also agree that ‘solution’ is a word with particular connotations I also would like to avoid in this circumstance (maybe always) as a result – Really neat thought btw).

Where I find it difficult to agree is actually with the perceived concept I feel the “Adoption can’t be driven” instills. That specific phrase is basically saying it shouldn’t be driven (which the article also tries to support). However there is no way for a new/different ‘solution’ to be implemented successfully without ‘driving’, or ‘helping’ adoption. (IMO)

Here is a couple thoughts that might be interesting:
If the design, interface, or perception infers in any way that it is different certain personalities will cognitively perceive change as a bad thing. This is reaction. The reason is because “All change is cognitively disruptive.”

For some people (most in many circumstances) when we see something shinier, prettier, or newer we may automatically react with a desire to have, use, or explore it (typically more true for the new generations (in North America) where this has been instilled). However not everyone reacts this way. Since we are probably talking about technology (inferred by reference to E 2.0) this is even more predominate because often we are automating, or adding technology to a process that was previously manual or executed in the physical (not digital) realm.

Now to be fair you could say this might be such a low factor it should be ignored or can be ignored. I agree with this response since the way we often measure ‘success’ with adoption is rarely as a value of 100% without resistance. However when you cross cultures (international/global) that level may increase substantially. This might be especially true within places where technology has not been instilled/ingrained/integrated fully into people’s lives. 

Just a couple more thoughts. I really appreciate the response back and look forward to future articles/your tweets.
Richard Harbridge</description>
		<content:encoded><![CDATA[<p>I see what you are saying and where you are coming from. I think I also forgot before to say I really liked the article, and think overall it does provide some really good points and a good message.</p>
<p>From a design perspective I completely agree that the design should be constantly improved overtime which (if successful) will ‘drive’ (pull) more users along and into it because it is more useful, beneficial or more easily understood. Realistically though this point alone disrupts the initial statement I was against which is that adoption cannot be driven. What you really seem to be saying here is that good effective and continual design will drive adoption of a system.</p>
<p>Certainly you need shared understanding of value from those who implement something and those who use something. (I also agree that ‘solution’ is a word with particular connotations I also would like to avoid in this circumstance (maybe always) as a result – Really neat thought btw).</p>
<p>Where I find it difficult to agree is actually with the perceived concept I feel the “Adoption can’t be driven” instills. That specific phrase is basically saying it shouldn’t be driven (which the article also tries to support). However there is no way for a new/different ‘solution’ to be implemented successfully without ‘driving’, or ‘helping’ adoption. (IMO)</p>
<p>Here is a couple thoughts that might be interesting:<br />
If the design, interface, or perception infers in any way that it is different certain personalities will cognitively perceive change as a bad thing. This is reaction. The reason is because “All change is cognitively disruptive.”</p>
<p>For some people (most in many circumstances) when we see something shinier, prettier, or newer we may automatically react with a desire to have, use, or explore it (typically more true for the new generations (in North America) where this has been instilled). However not everyone reacts this way. Since we are probably talking about technology (inferred by reference to E 2.0) this is even more predominate because often we are automating, or adding technology to a process that was previously manual or executed in the physical (not digital) realm.</p>
<p>Now to be fair you could say this might be such a low factor it should be ignored or can be ignored. I agree with this response since the way we often measure ‘success’ with adoption is rarely as a value of 100% without resistance. However when you cross cultures (international/global) that level may increase substantially. This might be especially true within places where technology has not been instilled/ingrained/integrated fully into people’s lives. </p>
<p>Just a couple more thoughts. I really appreciate the response back and look forward to future articles/your tweets.<br />
Richard Harbridge</p>
]]></content:encoded>
	</item>
</channel>
</rss>
