Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspxI did a scan around the web to figure out what many of the leading thinkers were saying about IT project failure and the root causes.&#160; Numbers varied between 20% and 80% of projects failing to deliver on their business case.&#160; The root causeen-USTelligent Evolution Platform Developer Build (Build: 5.6.50428.7875)re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10379476Wed, 19 Dec 2012 16:20:53 GMT91d46819-8472-40ad-a661-2c78acb4018c:10379476Nick Malik<p>I assume that the last comment was made by Prem U. Kamble since the links were to Prem&#39;s pages.</p>
<p>I would agree that there are relationships between the items. &nbsp;The diagram above is a taxonomy, not a model of relationships. &nbsp;First things first. &nbsp;If we agree on the distinct causes, we can compose models that represent the groupings and interdependencies that drive specific situations for specific organizations. &nbsp;This blog post represents step one, not step two.</p>
<p>I disagree with the word &quot;equally&quot; in following statement: &quot;The relationship and collaboration between IT and Management, IT and end-user, IT and supplier, all these are equally responsible for failure.&quot; &nbsp;Nonsense. &nbsp;Some organizations will have excellent relationships in one area, and crappy relationships in another. &nbsp;Where the crappy relationships exist, larger opportunities for failure exist. &nbsp;I agree that a good generalization is that, INDUSTRY WIDE, one could collect a count of failures by cause and they would break out in fairly predictable ways. &nbsp;That said, they would not, even in that case, break out to be 33% each. &nbsp;The three groupings that you mention are not equal causes for IT project failure.</p>
<p>It&#39;s good to see that you&#39;ve coined a term called &quot;Behavioral IT.&quot; &nbsp;Not sure we needed a new term for that... I would have called it &quot;delivery management&quot; or perhaps more specifically &quot;change management,&quot; but what the heck... we are never short of new names for existing things in this business :-). &nbsp;</p>
<p>You will find a good section in the IIBA BABOK (chapter 7) that covers some of these aspects of delivery readiness. &nbsp;You will also find discussions of delivery management in other (somewhat overlapping) bodies of knowledge. &nbsp;There are probably 200 books on the topic of successful readiness and deployment strategies. &nbsp;</p>
<p>I&#39;m sure that your work is unique and valuable. &nbsp;However, the language is different and you may not be using the same techniques as your audience is. &nbsp;You may want to familiarize yourself with that literature in order to make your work more accessible to your core audience.</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10379476" width="1" height="1">re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10378658Mon, 17 Dec 2012 13:54:03 GMT91d46819-8472-40ad-a661-2c78acb4018c:10378658Cambell11<p>You have done well to highlight the problems outside the blue box. But the problems have been highlighted in isolation. I can think of another vital factor is the interrelationship between each of these boxes. The relationship and collaboration between IT and management, IT and end-user, IT and supplier, all these are equally responsible for failure. In fact I see one of the most important roles of CEO is to ensure that the IT - User relationship is that of collaboration and not of confrontation. These are all people aspects and are dependent on attitudes, fears, misconceptions, beliefs, expectations and other people traits.</p>
<p>I therefore call it a special skill and have coined a term called &quot;Behavioral IT&quot; to describe this. It deals with the human aspects of IT failures. (Pls see <a rel="nofollow" target="_new" href="http://prem.cu.cc/behavioralit">http://prem.cu.cc/behavioralit</a> and <a rel="nofollow" target="_new" href="http://prem.cu.cc/seminar">http://prem.cu.cc/seminar</a>, or google on &#39;Behavioral IT&#39;).</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10378658" width="1" height="1">re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10377196Thu, 13 Dec 2012 14:07:36 GMT91d46819-8472-40ad-a661-2c78acb4018c:10377196Stefan Haselsteiner<p>Your missing one block at the bottom though - one that states &quot;All of the above&quot;</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10377196" width="1" height="1">re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10376640Wed, 12 Dec 2012 00:00:19 GMT91d46819-8472-40ad-a661-2c78acb4018c:10376640Nick Malik<p>I agree Adrian. &nbsp;Good points</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10376640" width="1" height="1">re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10376542Tue, 11 Dec 2012 18:00:11 GMT91d46819-8472-40ad-a661-2c78acb4018c:10376542Adrian Reed<p>This is a really interesting article, thanks for sharing. You raise some interesting points. &nbsp; One item you haven&#39;t covered is that many organizations will simply &quot;do the wrong thing&quot; in the first place. &nbsp; Sponsors, stakeholders and organizations get blinded by the &quot;Solution Illusion&quot;. &nbsp; They see a solution they love, and then try to shoe-horn it into their organization.</p>
<p>Successful projects start with a thorough and robust understanding of the problem domain. &nbsp;And they also start with a completely *technically agnostic* view of what the solution might be. &nbsp;Yes, the solution *might* involve IT -- but there are many other ways of solving problems. Process change, organizational change, outsourcing etc.</p>
<p>To take an example from you article: &nbsp;</p>
<p> &nbsp; &nbsp;&quot;The strategy is to make the sales force more productive by moving the company over to a new CRM system&quot;</p>
<p>This is an example of a solution being mixed with a problem. &nbsp; The problem here seems to be &quot;Make the sales force more productive&quot; and the *assumed* solution is &quot;move the company over to a new CRM system&quot;. &nbsp;I suspect that&#39;s not the only way! &nbsp; I worked with an organization that faced this very dilemma. &nbsp;There were reservations over how long it took sales users to update the system with notes, meetings etc, and there were questions over the usefulness of the data it was generating. &nbsp;Upon proper inspection, it was discovered that their existing CRM system had all the features and functions they needed. &nbsp;The issue was user buy in. &nbsp;The resolution? Buy the sales staff iPads. &nbsp; That way they can update and access the system easier from the road. &nbsp; This solution could only be formulated by understanding the business processes AND the environment in which the users actually had to work. &nbsp; </p>
<p>So -- in summary, I agree with the comment above &nbsp; &quot;There is no such thing as an IT project&quot; -- just business projects that implement, impact, change or interface with IT.</p>
<p>Thanks again for posting such a thought provoking article.</p>
<p>Kind regards,</p>
<p>Adrian.</p>
<p>--</p>
<p>Blog: www.adrianreed.co.uk</p>
<p>Twitter: @UKAdrianReed</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10376542" width="1" height="1">re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10376085Mon, 10 Dec 2012 16:18:43 GMT91d46819-8472-40ad-a661-2c78acb4018c:10376085Nick Malik<p>Just saw this related article on large project failure in the u.s. Military. <a rel="nofollow" target="_new" href="http://www.post-gazette.com/stories/business/technology/billion-dollar-flop-air-force-stumbles-on-software-plan-665500/">www.post-gazette.com/.../billion-dollar-flop-air-force-stumbles-on-software-plan-665500</a></p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10376085" width="1" height="1">re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10376000Mon, 10 Dec 2012 09:41:35 GMT91d46819-8472-40ad-a661-2c78acb4018c:10376000Adrian Grigoriu<p>Many of these causes seem to apply to EA as well. What do you think?</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10376000" width="1" height="1">re: Everything you’ve read about IT Project Failure is wronghttp://blogs.msdn.com/b/nickmalik/archive/2012/12/09/everything-you-ve-read-about-it-project-failure-is-wrong.aspx#10375962Mon, 10 Dec 2012 06:01:56 GMT91d46819-8472-40ad-a661-2c78acb4018c:10375962Osama Salah<p>The problem is already in the first sentence when you talk about &quot;IT Projects&quot;. There are no IT projects, only business projects that use IT. As long as project managers maintain the view of &quot;IT Projects&quot; they will continue to overlook all the failure root causes you have listed.</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=10375962" width="1" height="1">