Why do so many technology projects fail?

Fri, 23 Nov 2007 14:48:00 GMT

The Financial Times published an interesting article earlier in the week entitled Perspectives: Why do so many technology projects fail? (registration required) detailing a court action between BSkyB and EDS. In summary, it's about the failure to deliver a software project, how software projects aren't like construction projects, how a new way of working is needed, etc, etc. It's all stuff we've heard before and, as the article says, are lessons never learned?

Why do so many technology projects fail? Here are my thoughts, some of which overlap with the FT's article.

Iterative and agile techniques have revolutionized the way that software development is performed, but our industry needs to take a step back and look at the way in which software projects are engaged. Why, when you read about so many high profile big budget software failures, do businesses still initiate software projects with "we want this, tell me how much it will cost"? *We* know that they'll change their mind. *They* know that they'll change their mind. So let's change the engagement model, stop hiding behind fixed price contracts and work *together* to solve problems.
In my opinion, the view that software development is a commoditized skill is wrong. This is regardless of whether software is developed on-shore, off-shore, etc. Software development is a discipline that's part engineering and part art. If you want decent software built, don't treat it like a commodity. You wouldn't want anybody to build you a Ferrari, would you?
And finally, of course, there's the lack of a technical architect. Not all architects sit in ivory towers throwing unworkable "solutions" at development teams. Some of us like to work *in* the development team and eat our own dog food. Think of how many software projects you've seen that function correctly but are not fast enough, scalable enough or secure enough. That's why you need an architect.

I was chatting to Sam yesterday and he has some interesting thoughts too, which I'm hoping he'll write about one day. Something that we both agreed on though, is that the software industry generally needs to learn some lessons and wake up to some of the shortcomings that are so prevalent today.

Nines

Wed, 26 Sep 2007 22:21:00 GMT

I've been reviewing some software architecture documents as part of a training course today, where the authors had restated the non-functional requirements. Given that the non-functional requirements are some of the key architectural drivers, restating them in the architecture document is something that I recommend and like to see, so I was pleased that this had been done here. The thing that really struck me, though, was how nobody had seemed to question the requirements that they had been given. While most were okay, the availability requirement really stuck out as being extreme, for what is basically a desktop-based CRUD application.

The system must be available for 99.99% of the time, from 9am to 6pm London time.

With a duration of 9 working hours, this availability requirement means that only about 3 seconds of downtime can be tolerated. As a general guide, I'd say that availability figures of 99% and above mean that you have to start thinking about different types of architectures that include characteristics such as automatic (or very fast manual) failover, clustering, no single points of failure and so on. Clearly, a change in the architecture has a knock-on effect to the cost, potentially turning a £100,000 project into a £1,000,000 project. Whenever you're given non-functional requirements, always be prepared to ask the stakeholders whether they really *need* them and remember to emphasise that added complexity doesn't come for free.

Coding the Architecture - cost tag

Why do so many technology projects fail?

Nines