<?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: 6 Reasons That IT / Business Alignment May Be Impossible To Do</title>
	<atom:link href="http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do/feed" rel="self" type="application/rss+xml" />
	<link>http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do</link>
	<description>The Premier Blog For Learning How To Become A Successful CIO</description>
	<lastBuildDate>Wed, 08 Feb 2012 09:01:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Dr. Jim Anderson</title>
		<link>http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do/comment-page-1#comment-3027</link>
		<dc:creator>Dr. Jim Anderson</dc:creator>
		<pubDate>Fri, 12 Aug 2011 12:53:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.theaccidentalsuccessfulcio.com/?p=1166#comment-3027</guid>
		<description>Mark: right on! Ultimately I believe that it&#039;s not just technical knowledge that is needed, but also subject matter expertise -- what the heck does the company do? If you know both of these, then you&#039;ll be able to work well with the rest of the company...</description>
		<content:encoded><![CDATA[<p>Mark: right on! Ultimately I believe that it&#8217;s not just technical knowledge that is needed, but also subject matter expertise &#8212; what the heck does the company do? If you know both of these, then you&#8217;ll be able to work well with the rest of the company&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Polsgrove</title>
		<link>http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do/comment-page-1#comment-3022</link>
		<dc:creator>Mark Polsgrove</dc:creator>
		<pubDate>Thu, 11 Aug 2011 13:14:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.theaccidentalsuccessfulcio.com/?p=1166#comment-3022</guid>
		<description>In twenty years of IT experience, the biggest obstacle that I&#039;ve seen to IT/business alignment is the lack of experienced successful people.  Every CIO can say, &quot;I&#039;ve got people that can get this done.&quot;  The difference is people.  When you hire a developer who has never used the term, &quot;deductible&quot;, what do you expect?</description>
		<content:encoded><![CDATA[<p>In twenty years of IT experience, the biggest obstacle that I&#8217;ve seen to IT/business alignment is the lack of experienced successful people.  Every CIO can say, &#8220;I&#8217;ve got people that can get this done.&#8221;  The difference is people.  When you hire a developer who has never used the term, &#8220;deductible&#8221;, what do you expect?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr. Jim Anderson</title>
		<link>http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do/comment-page-1#comment-2973</link>
		<dc:creator>Dr. Jim Anderson</dc:creator>
		<pubDate>Fri, 15 Jul 2011 18:04:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.theaccidentalsuccessfulcio.com/?p=1166#comment-2973</guid>
		<description>Robin: very well said. In the end it comes down to knowing how to ask the right questions when you are building the requirements. This often includes asking &quot;why&quot; over and over again until you get down to the core reason that the requirement is being created. Easy to say, very hard to do correctly!</description>
		<content:encoded><![CDATA[<p>Robin: very well said. In the end it comes down to knowing how to ask the right questions when you are building the requirements. This often includes asking &#8220;why&#8221; over and over again until you get down to the core reason that the requirement is being created. Easy to say, very hard to do correctly!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr. Jim Anderson</title>
		<link>http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do/comment-page-1#comment-2970</link>
		<dc:creator>Dr. Jim Anderson</dc:creator>
		<pubDate>Fri, 15 Jul 2011 17:56:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.theaccidentalsuccessfulcio.com/?p=1166#comment-2970</guid>
		<description>Niels: all of your points are well made. Here&#039;s an interesting thought for you -- just exactly how do people become a CIO? I believe that all too often it&#039;s simply that you happen to be in the right place at the right time. You may not have the communication skills that are needed to be successful. Sure, you know a lot about technology, but do you know how to interact with the rest of the business? Where does one learn such skills? Just Do IT is a great sports phrase; however, it can be a bit trickier when it comes to running an IT department...!</description>
		<content:encoded><![CDATA[<p>Niels: all of your points are well made. Here&#8217;s an interesting thought for you &#8212; just exactly how do people become a CIO? I believe that all too often it&#8217;s simply that you happen to be in the right place at the right time. You may not have the communication skills that are needed to be successful. Sure, you know a lot about technology, but do you know how to interact with the rest of the business? Where does one learn such skills? Just Do IT is a great sports phrase; however, it can be a bit trickier when it comes to running an IT department&#8230;!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robin F. Goldsmith, JD</title>
		<link>http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do/comment-page-1#comment-2961</link>
		<dc:creator>Robin F. Goldsmith, JD</dc:creator>
		<pubDate>Mon, 11 Jul 2011 14:43:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.theaccidentalsuccessfulcio.com/?p=1166#comment-2961</guid>
		<description>A major but seldom-recognized obstacle to IT/business alignment is their widely-accepted but flawed model of requirements.  Both IT and the business focus almost entirely on the requirements of the product, system, or software they expect to create without first discovering the REAL business requirements deliverable _whats_ that provide value when satisfied by the product _how_.  

When that product inevitably fails to provide desired business value, IT declares requirements keep changing, cannot be known, and the user/business didn&#039;t know what they wanted.  IT also declares the only solution is to iteratively change the product, often in largely a trial-and-error manner, making inability to understand the requirements a self-fulfilling prophecy.  IT keeps repeating the process until finally something is settled upon.

In fact, it is unfounded high-level design requirements of products, systems, and software that changes so much--not the REAL business requirements those products have to satisfy.  What is actually changing in a most inefficient manner is mainly awareness of those REAL business requirements that have been there all along but have not been discovered adequately.    

It is a lot quicker, cheaper, and more satisfying to discover the REAL business requirements and then design a product, system, or software which actually satisfies them.  The first step of learning to do it well is to recognize the flaws of widely-held current model.</description>
		<content:encoded><![CDATA[<p>A major but seldom-recognized obstacle to IT/business alignment is their widely-accepted but flawed model of requirements.  Both IT and the business focus almost entirely on the requirements of the product, system, or software they expect to create without first discovering the REAL business requirements deliverable _whats_ that provide value when satisfied by the product _how_.  </p>
<p>When that product inevitably fails to provide desired business value, IT declares requirements keep changing, cannot be known, and the user/business didn&#8217;t know what they wanted.  IT also declares the only solution is to iteratively change the product, often in largely a trial-and-error manner, making inability to understand the requirements a self-fulfilling prophecy.  IT keeps repeating the process until finally something is settled upon.</p>
<p>In fact, it is unfounded high-level design requirements of products, systems, and software that changes so much&#8211;not the REAL business requirements those products have to satisfy.  What is actually changing in a most inefficient manner is mainly awareness of those REAL business requirements that have been there all along but have not been discovered adequately.    </p>
<p>It is a lot quicker, cheaper, and more satisfying to discover the REAL business requirements and then design a product, system, or software which actually satisfies them.  The first step of learning to do it well is to recognize the flaws of widely-held current model.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Niels Malotaux</title>
		<link>http://www.theaccidentalsuccessfulcio.com/alignment/6-reasons-that-it-business-alignment-may-be-impossible-to-do/comment-page-1#comment-2959</link>
		<dc:creator>Niels Malotaux</dc:creator>
		<pubDate>Mon, 11 Jul 2011 13:28:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.theaccidentalsuccessfulcio.com/?p=1166#comment-2959</guid>
		<description>Excuses, excuses, excuses !
(see http://www.malotaux.nl/?id=excusesexcuses)
When I coach business or IT projects, I use the &#039;Bullshit Stamp&#039;. Every time I hear those excuses about things that we know for decades that hinder the results we&#039;re expected to achieve, I use this Stamp.
If it&#039;s some absolutely new issue that would pop up, I can understand that it&#039;s a bit more difficult to handle the situation right the first time. But the things that go wrong are known and have been going wrong for decades (if not longer), so there is no excuse that you&#039;re &#039;trapped&#039; by such issues. Ref Cobb&#039;s paradox (1989!): &quot;We know why projects fail. We know how to prevent their failure. Why do they still fail?&quot;
If it&#039;s known for so long it&#039;s either Ignorance (=incompetence of education) or Incompetence.

If you are a CIO, you do what is needed to achieve what you&#039;re supposed to achieve. No excuses needed. If you need to communicate, you communicate. No excuses that it&#039;s difficult. If you need metrics, you devise metrics that tell you what is really important. etc. By golly, why do we still have to repeat this? If you don’t know how to handle the CIO functions well, why are you appointed CIO?
Sorry for being a bit blunt. I’m Dutch.</description>
		<content:encoded><![CDATA[<p>Excuses, excuses, excuses !<br />
(see <a href="http://www.malotaux.nl/?id=excusesexcuses" rel="nofollow">http://www.malotaux.nl/?id=excusesexcuses</a>)<br />
When I coach business or IT projects, I use the &#8216;Bullshit Stamp&#8217;. Every time I hear those excuses about things that we know for decades that hinder the results we&#8217;re expected to achieve, I use this Stamp.<br />
If it&#8217;s some absolutely new issue that would pop up, I can understand that it&#8217;s a bit more difficult to handle the situation right the first time. But the things that go wrong are known and have been going wrong for decades (if not longer), so there is no excuse that you&#8217;re &#8216;trapped&#8217; by such issues. Ref Cobb&#8217;s paradox (1989!): &#8220;We know why projects fail. We know how to prevent their failure. Why do they still fail?&#8221;<br />
If it&#8217;s known for so long it&#8217;s either Ignorance (=incompetence of education) or Incompetence.</p>
<p>If you are a CIO, you do what is needed to achieve what you&#8217;re supposed to achieve. No excuses needed. If you need to communicate, you communicate. No excuses that it&#8217;s difficult. If you need metrics, you devise metrics that tell you what is really important. etc. By golly, why do we still have to repeat this? If you don’t know how to handle the CIO functions well, why are you appointed CIO?<br />
Sorry for being a bit blunt. I’m Dutch.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

