IT departments typically staff themselves with a group of folks known as business analysts.
These folks have the responsibility of talking to folks that work in the business and translating their needs into a format that more technical folks can understand, because for some reason or other, most managers think that developers are unable to speak the same English that everyone else does.
IT is consistently cursed with getting the requirements wrong. Users, it seems, are horrible at actually reading the requirements documents they are given, worse they always seem to hate the great software that IT gives them. IT management typically has two solutions to the problem
1 – put a change management system in place that prevents those customers from actually changing their minds
2 – invest in better capability in requirements facilitation and documentation
None of these assumption address the underlying cause of churn in IT requirements, which is that today’s customer economy has created an environment where the benefit of many IT requirements are based entirely on assumptions. When these assumptions turn out to be wrong (and they often do) the business has no choice but to change direction, and fast.
Faced with this challenge IT either jumps into heroics mode or shuts down into change request mode, or worse some weird mixture of both.
No amount of requirements gathering expertise can fix this problem.
For the IT Analyst function to be relevant in today’s world requires a different set of skills. What is required is an IT Analyst who is well versed in how to reverse engineer a business plan and associated IT solution into a set of testable assumptions that can be implemented, and validated by order of highest risk.
In short Business Analysts need to become Business Technology Innovation Experts if they want to more than mere order takers.