I think a lot of focus has been placed on the software/solution/product/magic bullet here and not enough on the teams architecting requirements and architecting a solution. I find a lot of clients want the "off the shelf system that meets all my current requirements exactly as I see them" and in a lot of cases that means something that does what they had made their previous systems do. This leads to a lot of complexity and no one on the customer's side wants to take a step back and ask if those requirements truly are necessary.

Then if they are necessary do they need to be met exactly the way originally defined - I've had to build the "easy" button that does 4 things at once because it was too difficult for them to make someone push 4 buttons. If the client could tolerate their users using their brains and doing a small bit of work (or maybe following a process) than the system could be less complicated, require less development and be easier to maintain. Basically clients that can tolerate small tweaks to requirements or processes so as to make the actual solution less technically complicated or simpler get better results.

However as this was for large bureaucratic organization I would suspect (based on my experiences) that there were a lot of requirements that got very detailed, very complicated, just so people could cover their ***, but bloated the complexity. If those dictating the requirements can't see they're shooting themselves in the foot like that, and their consultants don't help them to pull back...well they were probably going to go over budget or have problems even before things got started.