I doubt that there are many IT projects of any size that can be deemed a complete success in all respects. There is always something that could have been done better, differently or more cheaply. The post-implementation review process is there precisely to identify those 'failings' and, if it doesnt find any, can itself be deemed a failure!
I also would agree that an individual can perform their own role superbly while the overall outcome is an unmitigated disaster.
But a project requires team work and the ideal team is a team of peers. Whatever my nominal role, I should have equal respect with all other members, take an interest in the overall project and contribute in whatever way I can to its success. If I see something going wrong, whether or not it is my nominal responsibility, it is my duty to my colleagues (and to myself) to point it out and offer a solution. If they reject my suggestion and the project fails as a consequence, then it was, at least in part, my fault for not being persuasive enough!
At the end of the day, it's a question of the attitude that you bring to your work - and life in general. You also will find that (positive) contributors usually end up with more interesting projects and more successful careers.
I'm currently involved in a project that is sort of unique. It's for a multi-billion dollar company. We threw out requirements, specs., milestones, etc. I am in daily contact with supervisors, plant managers, logistics co-ordinators, I.T. managers, network gurus, shipping clerks, and on and on. Everybody from CIO and CFO right on down to people on the production floors, in the warehouses, and on the docks.
It's cool. Way cool. If I need something they stop and send it to me. Likewise when questions come up I stop and dig it to the bottom. Success? Oh yes. Finished? No where near. We are constanly making adjustments to a system of sub projects that is in production, on line, and darn near real time. The list of enhancements to come is a book. Only one volume so far.
Measurement? We ask the users, "Is your job easier than last week?"
Having been within a project that failed big time, maybe £10 million down the drain and lots of jobs lost,from CIO down it's not an easy call.
What I'd probably observe from the article and many of the posts is that the projects were not managed correctly - however that's an easy statement to make, and I can draw on my above example where the DBA team expressed their concerns , well we actually said the implementation was unworkable, what actually happened is that we were told to get on and do as we were told or face the sack.
The pressures and reputations of too many are at risk in a large project and often too many decisions are made without input from the "right people". On a simple level how many DBA's get to have to install database applications which don't work, are full of security holes etc. etc. but were no part of the selection process?
I was part of a BI selection process where we rejected a major BI vendors tools, the Vendor took exception and attempted to get the decision overturned by going to the Managing Director , the argument the Vendor used was that they did not expect to present their products to technical people being more used to presenting to boards of directors. So for a major application around £1 million it should have been decided by non technical people !!
Very tricky and to be honest I'm surpised some companies manage to stay in business and it may explain why IT is so often seen as the enemy within a business.
One more point...
Very nice - I have to remind myself that these people pay me, not vice versa - so it's my reponsibility to point out what I see as flaws and issues, but if they insist - it's their decision, and my job is to do my best to implement it.
This can be frustrating.
As you can imagine, I don't always agree with my boss's approach - but one thing he does that's a good idea is "fail fast". If we don't know if this will work, go at it from the angle with the best chance of failure before doing things that might intuitively come first. Sometimes you feel like if you could do it "right" then it might not fail, but it makes sense to minimize the time spent failing.
Too many articles about project "failure" don't get the fact that failure is part of the process. The trick is managing failure well.