Why software projects fail

Martin Fowler and Dan North from ThoughtWorks gave a keynote at QCon entitled The yawning crevasse of doom; this refers to the tendency of those who develop software not to communicate with the beneficiaries of the software – users, business people etc. This was a recurrent theme at QCon; 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 “throwing architecture over the wall” in their session on Agile Architecture is not Fragile Architecture. If architecture is divorced from coding it is likely to fail. It further follows that improving the software development process is more to do with improving how teams function than it is about tools or even procedures.

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 the Standish Group 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 tools; one of their purposes is to enable better communication. However, it’s unlikely that landing new tools on dysfunctional teams will bring about improvement. It’s better to fix the team, which is a management issue, and only then to resource it with the right tools.

What is the team? In reality, the team is everyone with an interest in the outcome of the project, not just developers.

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 – maybe issues of personality, geography, or inappropriate management structures.

 

2 thoughts on “Why software projects fail”

  1. Interestingly, Jim Johnson himself (the originator of the Chaos reports and the Standish Group statistics on project failure) considers Agile a key to project success:

    “I’m a big believer in Agile, having introduced the iterative process in the early 90s and followed with the CHAOS reports on quick deliverables. We’re a real flag waver for small projects, small teams, Agile process. Kent Beck has talked at CHAOS University, and I have talked at his seminars. I am a real fan of XP. My new book “My Life is Failure” looks at Scrum, RUP, XP and talks about those methods.”

    Note that Number 1 is “User Involvement, Agile comes in at Number 5, and tools wrap up the list at Number 10 🙂

    http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

  2. Thanks for blogging about QCon! I just wanted to let you know that we quoted and linked from this entry on the over all QCon 2007 blogger’s key takeaway points and lessons learned article: http://www.infoq.com/articles/qcon-2007-bloggers-summary

    Feel free to link to it and of course blogging about this articles existence would help even more people learn from your and other bloggers takeaways.

    Thanks again!

    Diana
    InfoQ/QCon

Comments are closed.