{"id":162,"date":"2007-03-16T23:43:04","date_gmt":"2007-03-16T22:43:04","guid":{"rendered":"http:\/\/www.itwriting.com\/blog\/?p=162"},"modified":"2007-03-16T23:43:04","modified_gmt":"2007-03-16T22:43:04","slug":"why-software-projects-fail","status":"publish","type":"post","link":"https:\/\/www.itwriting.com\/blog\/162-why-software-projects-fail.html","title":{"rendered":"Why software projects fail"},"content":{"rendered":"<p>Martin Fowler and Dan North from <a href=\"http:\/\/www.thoughtworks.com\" target=\"_blank\">ThoughtWorks<\/a> gave a keynote at QCon&nbsp;entitled <em>The yawning crevasse of doom<\/em>; this refers to the tendency of&nbsp;those who develop software&nbsp;not to communicate with the beneficiaries of the software &#8211; users, business people etc. This was a recurrent theme at <a href=\"http:\/\/qcon.infoq.com\/qcon\/conference\/\" target=\"_blank\">QCon<\/a>; addressing this problem strikes me as a primary characteristic of agile methods such as Scrum. It helped me to understand that most software failures are caused not by technical issues but rather by communication problems. Of course communication failures can occur within the development team as well as between developers and other stakeholders; Kevlin Henney and James Coplien mentioned the perils of &#8220;throwing architecture over the wall&#8221; in their session on <em>Agile Architecture is not Fragile Architecture. <\/em>If architecture is divorced from coding it is likely to fail.&nbsp;It further follows that improving the software development process is more to do with&nbsp;improving how&nbsp;teams function than it is about tools or even procedures.<\/p>\n<p>I find this a healthy corrective to the reams of PR I receive from vendors implying that their tools can prevent project failures. They love to quote figures from <a href=\"http:\/\/www.standishgroup.com\/\" target=\"_blank\">the Standish Group<\/a> which allege that most software projects fail. This is the cue for a marketing pitch explaining the benefits of their application lifecycle tools. I am not against application lifecycle&nbsp;tools; one of their purposes is to enable better communication. However, it&#8217;s unlikely that landing new tools on dysfunctional teams will bring about improvement. It&#8217;s better to fix the team, which is a management issue, and only then to&nbsp;resource it with the right tools.<\/p>\n<p>What is the team? In reality, the team is everyone with an interest in the outcome of the project, not just developers.<\/p>\n<p>The snag is that it is much easier to buy new tools, or indulge in other forms of deckchair rearrangement, than it is to address the real issues that are preventing the team from functioning &#8211; maybe issues of personality, geography, or inappropriate management structures.<\/p>\n<p>&nbsp;<\/p>\n<div class=\"wlWriterSmartContent\" id=\"0767317B-992E-4b12-91E0-4F059A8CECA8:590e20ce-4470-45b8-b449-58d19b231b5e\" contenteditable=\"false\" style=\"padding-right: 0px; display: inline; padding-left: 0px; padding-bottom: 0px; margin: 0px; padding-top: 0px\">Technorati tags: <a href=\"http:\/\/technorati.com\/tags\/qcon\" rel=\"tag\">qcon<\/a>, <a href=\"http:\/\/technorati.com\/tags\/thoughtworks\" rel=\"tag\">thoughtworks<\/a>, <a href=\"http:\/\/technorati.com\/tags\/agile\" rel=\"tag\">agile<\/a>, <a href=\"http:\/\/technorati.com\/tags\/software%20development\" rel=\"tag\">software development<\/a><\/div>\n","protected":false},"excerpt":{"rendered":"<p>Martin Fowler and Dan North from ThoughtWorks gave a keynote at QCon&nbsp;entitled The yawning crevasse of doom; this refers to the tendency of&nbsp;those who develop software&nbsp;not to communicate with the beneficiaries of the software &#8211; users, business people etc. This was a recurrent theme at QCon; addressing this problem strikes me as a primary characteristic &hellip; <a href=\"https:\/\/www.itwriting.com\/blog\/162-why-software-projects-fail.html\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Why software projects fail<\/span> <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-162","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/posts\/162","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/comments?post=162"}],"version-history":[{"count":0,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/posts\/162\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/media?parent=162"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/categories?post=162"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/tags?post=162"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}