Congratulations lucky Business Analyst a career opportunity of a lifetime has just been assigned to you!  Ah the smell of a used car salesmen that is coming off your manager is so refreshing in the morning.  Whether you are being “volun-told” or volunteer, understanding roles and responsibilities for any project helps avoid conflict. 

It’s important to understand how each team member will contribute to the success of the project – and to your requirements elicitation and communication. The key is to get your audience – the stakeholders and project team – to understand the BA role and what will be delivered.  Ideally it’s a one pager and everybody gets it.  Avoid the Gantt chart as it doesn’t communicate roles and responsibilities.  A task doesn’t define your role and that Gantt chart doesn’t either.

Going a little bit wider, look at roles and responsibilities for the entire team – not just you the Business Analyst.  Look at business and technology folks as a whole.  You might step on your project manager’s toes a bit if you do this without them.  Best to keep the Project Manager and all stakeholders and project team members in sync.

Here’s a suggestion for a few columns on your roles and responsibilities matrix:

• Name:  Obvious one!  Include any nicknames or preferred names.
• Organization / Team : The team the individual is aligned with in the organization such as “Server Operations”, “Java Development”, “Business Analysis” or “PMO”.  This helps define the individual’s role within the organization – not so much the project.  Team members can be from “Server Operations” which implies a hardware or server role but really be playing a project manager or BA on the project team.  
• Team Role: The is the role the individual plays on the team.  
• Areas of Control: What areas of the project this individual or role handle.  For a business analyst those would be “Requirements Elicitation”, “Requirements Planning”, etc.  This is about the activities the individual performs not deliverables.  
• Deliverables: This is the physical thing or document that will be delivered by this person as their primary responsibility.  “Project Schedule” would be owned by the Project Manager.  “Business Requirements Document” would be owned by the Business Analyst.  
• Communication Preferences:  To help facilitate better communication established preferred communication channels.  People tend to be like sheep here – if everyone is using instant messaging they feel they need to go along with it but it may not work well for them.  Encourage individuals to be open about how they like to be communicated with.  If it’s a post-it note on the desk – that’s okay.  If it makes them more effective and efficient then it’s all good.

There are a lot more columns to consider.  The list above is a good start.  Can you think of other columns that should be added?

For extra credit - think about escalation paths.  Is there a backup for each role?  Who do you escalate to when there are concerns or issues with a role?  Look at this from a perspective of, “Well that went to hell in a hand basket - now what?”  Build an alternative path ahead of time that you can take if there are unresolvable questions or issues.  Sit down with your Project Manager and work out escalation paths.  Save yourself from the nightmare of blazing a new path through a jungle of large organizations while fire balls from the sky are coming down on you.  Okay that’s a bit dramatic but you get the point.  

Keep the roles and responsibilities document front and center.  Don’t laminate it or carve it in stone.  Things will change fast on the project and keeping everyone in sync is important.  Plus, stone carving isn’t as easy as it looks.  Consider version control of the document to ensure everyone is reading the correct version of the document and not an old one.  Publish and communicate frequently.  Even having a standing item on the project team meeting to discuss roles and responsibilities can be very helpful.  If you’re lucky there may never be any changes but be prepared if there are role changes.

Stakeholder analysis is a good thing.  Spend some quality time on it as part of your role.  Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today.  Following Bob on twitter (@bobtheba), Facebook (Bob the BA), and LinkedIn (Bob the BA Company).