What Makes One BA Better Than Another?

What makes one BA better than the other?  What really makes any of us better than the other?  I think it comes down to a two things:  Experience and personality.

  • Experience.   Experience is invaluable and covers a lot of ground and I would like talk a bit about a number of key drivers.
    • Organizational experience.  You know the people/groups you need to bring in on a project.  You know what groups may provide roadblocks to your project and the best ways to communicate/work with them.  These are things you learn from working in past projects within the company.  These are things that a good BA can easily learn and prepare for by asking other BAs in the company, their manager, or other contacts on the project team.
    • Event experience.  This is when or when problems have occurred in the past and how were they dealt with.  You also know what people or groups who are likely to be slow in responding to emails or giving sign offs or asking for last minute changes.  These are highly frustrating things but experience teaches the BA what to expect and how to deal with it.
    • Vocabulary.  A lot of times the client doesn’t know exactly what they what or how they want something to work and sometimes the client knows just enough to be dangerous.  The BA becomes an interpreter between the business and the IT teams.

      I’ve found that the best way to solve this is to create a data dictionary.  When I work in a Waterfall methodology, I put a glossary at the beginning of the document I’m working on, whether it is a project charter, business requirements document, High level document, or Low level document.  I also include any acronyms that may be used.

      When working in Agile, I typically do two things.  First, I create a spreadsheet with all of the definitions and acronyms and keep it where I can link to it when necessary.  Second, when I write the user story I try to put either the definition in the story or link to the data dictionary.  The type of story, the application we are creating the user story in, and the agreed procedures usually dictates how I do this.  One thing I have noticed about Agile is that EVERY group does Agile a bit differently.

  • Personality.  I think personality is a given, really, with anything you do.  People feed off of the people that they work with and when they work with someone who is confident, trusted, and well-liked, then you are more likely to have success.  Let’s face it, no one wants to work with someone who is always miserable, cranky, argumentative, or untrustworthy.  It makes for really long meetings.

When you are a BA, you have to manage ALL of those people, you CANNOT be one of those people.  Everyone has a bad day.  Everyone has days that they don’t want to be on the meetings.  I believe that the BAs personality drives the project.  Another key thing to remember is that the BA NEEDS input and help from all groups.  You don’t get a lot of help when people don’t like you.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s