Being a great business analyst is fundamentally about communication. We communicate in meetings, through elicitation, via email, and through our requirements specifications. Verbal and written communication are key competencies for the successful business analyst. I’ve collected together some past lessons on communication.
I’m sharing 10 lessons from the archives on communication.
Communicating 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.
Improving 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 pre-empt the above problem, 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.
Overcoming common BA communication challenges
7. Like me, you might be a perfectionist and this can lead to some communication challenges. Read about how perfectionism might impact your ability to communicate in a positive way.
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.
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. An issues list — go beyond “CYA” and into proactive communication by using an issues list to drive attention to open items and breed accountability amongst your stakeholder team.
10. A meeting agenda — avoid mystery meetings with quick and simple agendas and start your meetings by establishing context
Bonus: Recommended Reading on Communication
Finally, if you are looking for just one book to add to your holiday wish list to help your communication, consider How to Win Friends and Influence People by Dale Carnegie. It’s full of lessons that will last you for years to come.
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 6 comments… read them below or add one }
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”.
Couldn’t agree more Tom. Thanks for your comment!
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.
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.
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.
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