This quick post is in reference to the T-SQL Tuesday for the Month of December of 2010, hosted by Steve Jones. The subject is “What issues have you had in interacting with the business to get your job done?”

T-SQL Tuesday, December of 2010

Have you ever been in a situation where you were told to develop and deliver certain application because Business folks already sold it to a particular buyer, even with a preset delivery date? You are not alone. I have experienced similar ones without even knowing “What” we were supposed to deliver, less “How” to do it.

Business and Technology need to create a partnership, and communication needs to flow back and forth. This is where a very strong business analyst with technical knowledge comes into play. If business would like to have a portfolio of products of services they can sell, it needs to be communicated with the business analyst, who at the same time will ask questions to the technical team to get an idea of the feasibility and viability of the product. If there are technical questions then they can be asked to the business analyst or even directly to the business owners if required.

Technical teams cannot develop without having a solid business requirement, or a good understanding of what the business folks want. I agree that most of the times, especially with new products or services, complete business requirements are unfeasible, but the business analyst needs to write what business folks want conceptually in a technical form, pointing out relevance and priority.

Iterative development and deployment is a trend being followed by more companies nowadays. As releases get to production on a much quicker fashion it can give the opportunity to the business folks to analyze the original requirements/concepts and recommend changes. It can also build confidence with the technical team as results are being delivered in small releases but in a progressive fashion. This is key to continuously building a partnership.

My opinion is that technical teams need to understand what are they going to develop and for what purpose. Analyze and suggest the technology to be used and work with the project manager and/or business analyst in order to come up with a timeline. Interact with the business folks in order to clarify any doubts and prototype the solution before engaging into a full blown project. Approach short releases if viable and build confidence with the business team. Never be afraid to ask questions; if you do not know “what” needs to be developed rest assured that “how”, the way you will do it, is wrong.