Tips for the “Generalist BA”

In my previous post, I mentioned the IIBA Professional Series day that I recently attended. As mentioned, the day was wound up with a panel discussion from Roxanne, Kevin and Tim Conventry (President of the IIBA Australia Chapter). The discussion topic was “How to promote the value of a Business Analyst”. From the discussion, it was clear that business analysts often face the challenge of coworkers, managers and clients misunderstanding the skillset held by business analysts, which results in BA’s becoming the “fill in” resource – capable of completing work such as testing, project management, development and so on.

What this says about business analysts is that many of us do come from various technical and non-technical backgrounds. We have various skills that complement our core competencies. This can be useful in small teams which rely on each other to ‘get the job done’. A generalist is often more useful than a specialist. However it can result in our core business analysis skills being watered down in the work environment.

The important thing is that we business analysts stay true to our aim of eliciting and understanding the true needs of stakeholders, and ensuring the solutions developed meet those needs. No matter what tasks we’re completing at the time. Below are some suggestions of how you can do this whilst performing a couple of other common “generalist BA” tasks:

Testing: Make sure the requirements your tests trace to exist and are complete, and represent the aims of the client. Have an informal chat to the stakeholders to truly understand where they are coming from and what they are hoping to achieve. Then question whether the requirements align to that vision. If your project has limited time or the solution is hard-set, talk to your techies to find out if there are minor adjustments that could be made to improve the alignment to the client’s vision.

Project Management: If you’re setting up a new project, why not start early with your requirements elicitation. In addition to the resources, timeframes and deliverables, start understanding the scope of the project. Maybe produce a high level business process flow, or high level use case model if your client’s major concerns are around business processes. Or perhaps a domain chart if you are working on a very technical project. If you’re managing the schedule, make sure you add adequate time in for requirements analysis!

Development: Similar to testing, have a chat with the stakeholders to try to understand their vision and what they are trying to achieve. Design the system to allow it to support their long-term goals, such as scalability. Keep in mind what is important to them when making all design decisions. They’ll appreciate it when you demo to them, when you show how you listened to what they were aiming for and designed it to align with that!

Do you have any other suggestions? Leave a comment below!

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s