Great business analysts are great communicators. We communicate in meetings, through elicitation, via email, and through our requirements documentation. Verbal and written communication are key competencies for the successful business analyst. I’ve collected together some past lessons on communication.
In this article, lets look at 10 ways you can communicate even more effectively on IT projects.
Communicate with Business Stakeholders
1. Always remember: It is never a waste of time to define the problem before discussing solutions.
2. Sometimes business stakeholders just aren’t sure where to start with “requirements”. Become a sounding board for new ideas and look for ways to help your stakeholders discover technical possibilities.
3. As business analyst, we are often in a position to reach across organizational boundaries, especially the gulf that seems to separate business and technology. Doug Goldberg provides a host of ideas on why attitude issues surface on both sides and how a business analyst is in a position to forge new paths of communication between business and IT.
Improve Analyst / Developer Communication
4. Have you ever had a developer tell you “that’s impossible”? I certainly have. Read my advice for how to overcome this communication barrier between analysts and developers.
5. And to avoid the above problem in the first place, always look for opportunities to share business context with your technical team. It is a positive form of communication and will do wonders in establishing your relationships.
6. Have you witnessed a tense moment between a developer and a stakeholder? Have you wondered how you can help your teammate? Doug Hill shares a wonderful story about a small gesture that created a big positive experience.
Overcome Common BA Communication Challenges
7. It can be difficult to turn off our analysis hat and really listen to what our stakeholders have to say. Using a variety of active listening techniques will help your stakeholders realize you did really hear what they said and understood what they meant.
8. Have you wished you had resisted the urge to say “I told you so” or the more professional equivalent of “remember last week when I pointed that out”. Learn to think of these moments as opportunities to learn how to better influence your stakeholders next time.
Leverage Techniques and Templates to Improve Communication
There are a few tools that I rarely leave my desk without because they do so much to improve both my own organization and how I communicate with others. They include
9. Be proactive with an issues list to drive attention to open items and breed accountability amongst your stakeholder team.
10. Avoid mystery meetings with quick and simple meeting agendas and start your meetings by establishing context.
>>Looking for More Support?
Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.
Click here to learn more about the Effective Conversations Template Collection
I think you hit the nail on the head with your post.
Hi Richard,
I am a strong proponent of leading by example. Establish a strong set of best practices for the meetings that you are responsible for first. Then begin asking questions (behind the scenes) to help others follow your lead. You might also consider pulling together information on how the improperly planned meetings impact your team or productivity. Numbers and waste can make a strong case for better meetings.
Laura
Here’s a question, how do you get “the business” to follow these guidelines? I can’t begin to count the number of meetings I’ve been asked to attend where there was no previously posted agenda, the meeting coordinator arrives late, the wrong individuals were invited. I would say that in the last three years I have attended one or two meetings that were well planned, efficient and effective.
Steve, thanks for all the great feedback and info. Great comment that really adds to the post. Regarding #1, I hear this a lot from BAs — that they are typically brought in after the problem has been “solved”. I feel fortunate that’s not been my experience, but I think I also create some opportunities here through digging. If I start to get conflicting requirements or see people having trouble prioritize, then I know we need to clarify the problem together as a way forward.
For some strange reason, #1 – problem identification, seems to be the one that it investigated the least on most of the projects I have been assigned to. By the time I am on a project, the solution has already been identified even though the requirements have yet to be developed.
#6 usually has a way of working things out when FOOD is the intermediary. Trouble with driving directions – give food landmarks. Disagreement between project members – create an afternoon coffee/snack break to work out issues and promote communication.
As for #5 – share business context with your technical team, I couldn’t agree more. If you can include some measure of both technical and business information into the documents (tech for BRD, business for FSD,SRD), you’d be surprised at how that additional information can be useful to the other parties. Sometimes that extra information provides the perfect amount to eliminate confusion and help with understanding… business context for the techs can often lead to the delivery of a better solution than originally planned because now they see “what” AND “why” and do something unexpected… build capability/expansion options because they see it will probably be needed in the future, with only a small (2-5%) variance from what was originally planned.
One addition to the meeting Agenda – including the meeting logistics within the original message. If you can find the time on everyone’s calendars but don’t yet have a room or teleconference #, don’t send it until you do because people don’t always process the follow ups with that info if separate and begin to wonder where/how the meeting is going to happen. In my case, I had extended a holiday break with one extra day knowing there was an early morning meeting upon my return. I tentatively accepted because the logistics info was not included and stated if it wasn’t finalized prior to end of day, my attendance should not be expected. Glad I did because the info never came in and traffic delays made getting to the meeting impossible – and with no call in info available, the meeting was missed entirely.
Couldn’t agree more Tom. Thanks for your comment!
Communication is the key to everything. It helps build trust between all parties and from there anything can be accomplished. The role of the BA is to create a bond with the stakeholder so you can truly identify what the need is which is also something they are unable to articulate, so some digging might be required. Once the need has been determined (and agreed to) then the same bond must be created with the IT side. No entity in the stakeholder-BSA-IT connection should enter with an attitude of “I know better than you”.
Pingback: Tweets that mention 10 lessons in effective IT communication -- Topsy.com