One of the sad truths about application development in corporate America is how much of what really happens is a hit-or-miss proposition.
First, some executive agrees to sponsor the application, which then results in months of interviews with business analysts from the IT department who are trying to wrap their minds around the everyday processes that drive the company's business. Months of mind-numbing conversation then usually result in a specification that gets delivered to the application developers, who then dutifully code whatever was handed to them.
Then comes the big day when the application gets launched with great fanfare, only to fall back to Earth like a lead balloon because the users of the application can't make heads or tails of the thing concocted by the business analysts, who in turn blame the developers for not understanding what was intended versus written in the original specification. This usually results in developers, with clipboard and stopwatch in hand, spending a lot of time with end users trying to figure out what went wrong with the application, or why the performance of certain application activities is roughly equal to the speed of molasses.
Does it have to be this painful?
Source: Baseline, http://www.baselinemag.com