Dear oh dear oh dear....  what a total cop out from the author.  If the eventual users don't or can't use the system, it's a failure, no matter how good the program writing is.  

If the eventual result is vastly different from that desired at the start of the exercise, it's a failure.

What we saw in the author's 'not me gov, I wasn't responsible- Ive done exactly what you asked me to do ' rant was the classic conflict of management and managing a project. 

I write and administer for 80- 100 users across SQL, Crystal, MIS, and various other Microsoft programs. The golden rule is always  - First define the objective: what are you trying to achieve, what's the end game, what do you want from this piece of project? Second: who is going to use it? How are they going to use it- what are they going to get out of it?  Thirdly: will they use it? Will they get out of it what they need ( not what we want) to do their job?

When you start with those questions- not project management questions , but management questions - you buy into the responsibility you should be taking to ensure success. From the examples the author gave, it didn't appear that anyone had actually bought into their project - but just took the task and designed a process. That approach and the attitude that goes with it - is doomed forever- and no matter how clever at writing programs the author may be - a change of approach is advised else every project in the future will be a failure.