when relevant content is
added and updated.
Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.
The feature, which will appear in two parts on Computerweekly.com , asks the question: Why do large IT projects fail? Here is the first part.
Today I am am featuring a response from a reader about the last post I placed, which was the views of Milan Gupta, chief architect at Barclays bank. Here it is.
Here are the other parts already published: Part 1 Brian Randell, part 2 Anthony Finkelstein, part 3 Yann L’Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan part 9 Sam Kingston, part 10 Peter Brudenal, part 11 Mark Lewis, part 12 John Worthy and part 13 Stuart Drew.
I will be featuring more comments from readers over time so pleaser put your thoughts in the commentrs box.
The response to part 14 from Milan Gupta at Barclays comes from a reader going by the name of Matt.
He says, “Interesting comments, but most of the really big project failures we’ve seen are in the public sector, where the business does not change all that fast. The problem instead is that the business is often so complicated that even the business users do not understand how it all works, especially the senior civil servants and politicians who are typically responsible for setting the overall scope, budget and timescale of the project. As the saying goes, most projects fail at the start, not at the end.
But Mr Gupta makes an excellent point about removing the layers between user and developer. Many projects – especially in these days of outsourcing/offshoring – suffer from the number of interfaces between individuals/departments/organisations that have to be negotiated every time a problem is identified or a question is asked. Add to this the tendency of suppliers to hide problems from the client, and the client’s tendency to hide their ignorance of their own business requirements from these tiresomely inquisitive suppliers, and it is frankly amazing that any information ever makes it across these interfaces at all.
Agile approaches can make this situation worse, because the real requirements are only fully identified (or not) very late in the development process, so there is ample scope for mission creep, unresolved misunderstandings and nasty surprises.
Complex architectures and over-engineered designs can also add to this problem, especially in the public sector where both the client and the supplier think complexity is in itself a good thing (the client because it makes them feel special and gives them an excuse not to understand their own business, and the supplier because they can charge more for it). Some of this complexity may be inevitable, but in my experience you often end up with too many people in the process who see their roles as being mainly about generating confusion, complexity and obfuscation, rather than clarifying matters.
As for the idea of taking 90 days “from user story specification to production” in the public sector, dream on! I’ve spent longer than that trying to get an answer to a single question regarding specific requirements on a government project.
Anyway, after several years working as an independent contractor on government projects, I could really do with working on the kind of project Mr Gupta describes…!”