"If you want to see what failure truly looks like, attempt to reengineer a process without ensuring that all of those with a stake in the process are represented during the effort."
That pretty much sums up what I've seen at this organization. The requirements were written by those who had a superficial understanding of the process and who used it only rarely or who filled in when the subject matter expert was on vacation. One subject matter expert was not consulted at all, and a hardcopy of the requirements was thrown on her desk after the fact -- she wasn't even privy as to where the electronic copy was located and had never been invited to any of the planning meetings! The other subject matter expert was consulted for 15 minutes tops.
Needless to say, when the project moved to UAT, it was a absolute disaster. It was at this point that one of the subject matter experts was pulled in, only to find that the process was totally unsuitable. After having spent thousands of dollars, the organization pushed the project onto the back burner for retooling and then months later made a second attempt, still using much of the code from the first try. The process "works" now, with a myriad of workarounds and hands-on management required. If this organization didn't have big pockets, someone's head surely would have rolled for such mismanagement.
After having participated in this fiasco, anyone can readily understand why this IT organization's internal applications are absolutely terrible.
Keep Up with TechRepublic