Messages

I am loving this thread.  Thank you, Luz, for putting the question out there.  And thank you everybody for joining in!

My two cents:

1. I love God analogies

2. Never been to Wyoming

3. I am also learning how to work with BAs and also BSAs. Never had them in any organization I worked in before (IAs pretty much covered all those roles).  In my current gig, we do have role expectations, but we are also very fluid and let people's individual strengths / the project at hand determine who handles certain aspects.

General roles, much like others have said:

BA:

• know the business / stakeholders very well and develop good business requirements (that don't dictate a solution)
• be aware of processes in other parts of the company that are affected (i.e., develop a plan for how the phone bank will change their script)
  
• later in the process flesh out specifications (annotations) to cover business rules (IA could do this, but if BA is there, let him/her do it)
• set up meetings and handle logistics, if not being handled by a PM
  

BSA:

• know tech constraints and opportunities (i.e., be the person who can say, "hey, if we only had this data element present in the new system, we could seamlessly tie to that system over there.")
• develop use cases and document all error conditions
• BSA or IA often leads key meetings, as they tend to be the more sr person or have more of that skill set

IA

• Fill in gaps where BA or existing knowledge don't provide enough about the actual users
  
• Help BA / BSA with requirements / tech issues by bringing good methods to the table (i.e., group card sorting as a way to get the business stakeholders to open up)
• Help shape presentation documents for key meetings and touch points (hey, we're info designers, right? and the BA / BSA often don't excel in that)
  
• Lead certain key meetings
• Develop solutions from the requirements and constraints/opportunities
• Document solutions, with help from BA and BSA in their respective areas
  

Thanks,
Weston