Honestly speaking, I love the business users for whom I try to propose a solution. Afterall, I get to spend so many hours with them during typical inception phase(s) of project(s) while undertsanding, analyzing, modeling and verifying their needs which I then translate into formal requirement defintion. I get to go out for lunch(es) with them and share an occasional ride back home. When I witness an imbroglio centered around “Organizational politics”, I am obliged to walk a fine line between the business and IT(as Barbara opines in her note).

Should a stalemate crop up between the two teams over requirement-based issue(s), I prefer to demonstrate an alternate way of working to the business users by using low-fidelity paper prototypes that mimic their way of working but does not constraint my IT group into using a system development methodology, application development tool or a testing tool. If I perceive that the IT team is having a tough time pulling resources and wants to avoid over-straining the already starined developers and QA teams, I usually try to buy some time from the main stakeholder(s) representing the business user community by contemplating over the priority of the requested feature(s). Some times we are able to negotiate by moving down the requested feature in terms of its priority. Yet other times, I choose to give a brief status update to the main stakeholder(s) in the business user group around the “critical” requirements that my IT team is currently working upon and demonstrate the business value(s) that would abound once those requirements are delivered.

I understand that this tight rope walking can be daunting at times, but then as all of us would vouch for the dictum “Thou shall not be faint-hearted” .

Setting industry standards for a new profession is very difficult. The best way for them to develop accurately is for lots of professionals to contribute.