The development team should trust a BA; this was the first lesson that I got from a senior BA. When I asked him how to do it, he told me that you have to figure that out for yourself there is no proven formula. Some of the things that I tried and how they helped me in building a good rapport with the development team.

• Interact with the developers regularly and keep asking them if they have any doubts. The idea is not to overdo it as they may get a feeling that you are trying to judge their work. Keep it simple and just make sure that they know you are there if they need any clarifications in the requirements.
• Make sure you run the development team through the requirements before they start with the implementation. Do it on module-to-module basis, plan with the Project Managers and Team Leads. Make sure you keep these sessions as informal as possible and try to make them understand the business pain points rather than teaching them (as they may switch off).
• Encourage the team to approach you for any clarification in the requirements. When they approach you make sure you clarify their issues or get the issues raised to correct person, if you are not the right one.
• It is a good idea to explain the business side to the developers and also let them know about the domain, as you have that knowledge. Have these talks at non-work timings like lunch, coffee or while traveling. Make sure you don’t come out as a person who is bragging about his knowledge but as a person who is genuinely helping. Keep it honest; if you are not comfortable don’t try it.

I tried these things and they helped me immensely in building a good relation with the development team. Do let me know what works with you and how you achieved it?

We’re not strictly tech and we’re not strictly business. The definition of what we do is usually written in semi-tech language (we write requirements). But how do we write those requirements, what makes us different? How do we see things and why do we see them in the way that we do? What is the potential of the Business Analyst profession? What do senior managers want that causes them to listen to us? How do we move from Business Analyst to Business Architect? How do we advance ourselves in our positions and advance the profession as a whole?

Let me define the difference between an analyst and an architect. The differences are subtle but I will try to define the three most critical as I see them.

- A Business Analyst reports to developers or an IT project manager. A Business Architect reports to managers or senior managers who may be business or IT but are independent of the project.

- A Business Analyst documents requirements as defined by users. A Business Architect documents and may define a business strategy using requirements provided by the users.

- A Business Analyst operates within the confines of a predetermined technical architecture. A Business Architect is a part of the decision making process to define the technical architecture.

A few more things:

- An Architect is considered a neutral voice and because of that will make more critical decisions than an Analyst.

- An Architect must have the ability to think in both a strategic and tactical manner whereas an Analyst is normally tactical.

- An Architect must be cognizant of enterprise strategies whereas an Analyst is normally concerned with specific projects independent of enterprise strategy.

So we see that each type of “BA” is necessary. How do you become the best BA you can be? Or how do you move from Analyst to Architect? Hopefully I can provide some tips. If this interests you the next few posts will concern listening to the needs of the business in order to become the one who assists in driving out the business strategy – if that’s what you want to do.

Until then – Dum Spiro Spero! (Look it up on Wikipedia)