Tea Chat with a Business Analyst (BA)

Jun. 21, 2017

What does a business analyst in the cancer genomics and bioinformatics world do?

If asking this question to employees in a cancer research institute, chances are 90% of respondents would have no idea, 10% may have some ideas… and we don’t want to know how many of the 10% would be able to describe a business analyst job. :)

Here’s Brian, the Business Analyst.


This article aims at describing what Brian does in his company illustrated by personal experience, with more examples focused on cancer genomics and bioinformatics. However keep in mind that Brian could do the exact same job for an insurance or sportswear company or any industries with users who need to use an application to perform their job.

Who are the players in an IT project and how do they interact with Brian?

The Business Stakeholders

They are the product owner (in our context the principal investigator) and the subject matter experts or super-users (the bioinformaticians and lead scientists).

This is the starting point of all projects: what do the stakeholders want? The higher up the hierarchy, the higher level the requirements will be. The stakeholder’s role is to give ideas of what they want but Brian is here to dig into the topic and provide more details before any discussion can happen with the software engineering team.

The Project Manager (PM)

Brian is responsible for ensuring requirements get done. The PM ensures the requirements get developed on a schedule.

The Software Development Team (architects, bioinformaticians, technical leads, developers)

The Dev team may not need Brian, they could go directly to the stakeholders, collect the requirements and implement the solution. In larger-size projects, Brian’s role is to document the requirements or implementation options, track the impacts and the decision making process which often involves quite a bit of back and forth since stakeholders can change their mind in the light of external circumstances. Usually the software developers find their joy in prototyping and coding, not so much in writing formalized documentation of the stakeholders’ expectations.

The Quality Assurance Team

The QAs perform quality assurance based on requirements written by Brian.

The users (bioinformaticians, researchers, students, the cancer research community).

Brian will provide assistance in training the users with their new application. Larger projects might have a dedicated user service team. In that case, Brian would provide a more in-depth support to the user service Team for a better understanding of the software solution.

The key in such IT projects is for Brian to thoroughly understand the different needs of bioinformaticians, researchers and software engineers. This requires finding the right questions to ask. To be able to do so, Brian needs to understand the business goals as much as the technical aspects of an application.

Who has never seen this scenario?

  • User service team: “The user cannot use the feature, is it a development issue?”
  • Developer: “No, it’s a data issue”
  • Data Quality: “No, it’s an environment or network issue”
  • Dev-Ops: “No, the user did not use it properly”

Brian’s role here is to clarify the issue and challenge his team to identify the best solution.

Brian’s techniques and main activities

  • Define the 5 W’s: Who did What, Where, When, and Why. Answering What and Why can be challenging in cancer genomics research, or any field with significant complexity. Instead we choose a direction and follow it, discovering the answers along the way.

  • Analyse the existing system, processes and best practices: there is a lot of reading in a Brian’s job, all the documentation of what your company and its competitors produce.

  • Lead brainstorming sessions, interviews and workshops, facilitate meetings: every project needs an unbiased mediator to make sure business and technical perspectives are aligned.

  • Create documentation:
    • scope and rationale of a project
    • business processes, data flow diagrams and user stories
    • mock-ups and wireframes
    • functional and non-functional requirements
    • user acceptance criteria, decision logs, user impact of any business and technical decisions

    50% of Brian’s job is to write documentation and the other 50% is to listen to and communicate with people to make sure the documentation is accurate and shared.

  • Review documentation with the business stakeholders.

  • Participate in solution design (data modeling) with the software engineering team and organize the specifications with developers.

  • For both activities described above, it is important to target the audience as Brian will not emphasize the same information. In one case, he wants to validate the impact to the users, in the other one he wants to break it down so the developers understand and can think of how this will impact their implementation.

  • Analyse and track issues: the issue has to describe a user behaviour but explore the technical aspects of it. A good understanding of both functional and technical sides will help to better analyse the issues.

  • UAT (User Acceptance Testing): Brian will define the user acceptance criteria of the application based on the requirements and business understanding and will perform quality assurance from a business perspective.

  • Create user documentation and train users.

Other activities include: stakeholder analysis, vendor assessment (create a request for proposal), gap analysis, SWOT matrix (Strengths, Weaknesses, Opportunities, Threats), risk analysis, Ishikawa diagrams (or cause analysis), reverse engineering, focus group, MoSCoW (Must have, Should have, Could have, and Won’t have but would like) and many other activities depending on the company needs.

Some comparison

One path to become a business analyst is to start with IT studies. So between a developer and a BA, there’s only a small shift…

CategorySoftware DeveloperBusiness Analyst
StudySoftware Engineering schoolSoftware Engineering school another path could be business study with IT training down the road
Ongoing learningR&D on technologies, programming languages…Benchmark on company business and minimum understanding of software tools or best practice
ChallengesUnclear and changing requirements and functional specifications coming from the business analystsUnclear and changing business requirements coming from the stakeholders
Must have skillsAnalytical, programing skills, problem-solving, willingness to research, teamwork…Analytical, documentation, listening, communication, negotiation, teamwork…

Fun Facts

  • Gender equality: Business analyst is the IT job where gender equality is best represented. Most of the time it’s half-half but I have worked in a BA department with 8 female BAs, 4 male BAs and a female manager. Note that this fact is purely based on experience with no large-scale survey behind that…but I think it’s true.
  • Career path - what’s next? Career business analyst, business analysis manager, project manager, business analysis competency manager, subject matter expert, product owner, business architect…
  • Canadian employers will need 171,000 business analysis related professionals by 2016. 
(Source: Information and Communications Technology Council, 2011)
  • American employers will need 876,000 business analysis related professionals by 2020. (Source: U.S. Bureau of Labor Statistics, Employment Projections Program)

My background

I graduated 10 years ago from a software engineering school in France (INSA Lyon). I once was a developer (my first internship was to develop a website in PHP for radiologists) but found out quickly that coding was not my thing.

My passion is in analysis and talking with the business to understand what they need but also think of how it could relate to software implementation. This is why I could work for the national bank of France to implement a numeric vault, for a health insurance company in the Contribution area, for the Pharmacist Order (e-pharmaceutical file), for the Cancer Care Ontario (cancer assessment surveys for the public), for Michelin Tyre (accounting system) or the equivalent of the French Mountain Equipment Coop - MEC (in Identity and Access Management) and now in Cancer Genomics. None of these industries are related but they all require the same skills from a BA perspective.

I think my job is awesome because it’s like having a tea-chat with everyone in a company to understand what they do. I’m not an expert in cancer genomics, I’m not an expert in software development but I do understand who to talk to and how these topics relate to each other. This is what makes business analysis powerful, you just need the right tools to connect people to each other.


A Guide to the Business Analysis Body of Knowledge®(BABOK® Guide): http://www.iiba.org/babok-guide.aspx

Business Analyst Career path: http://business-analysis-excellence.com/business-analyst-career-path/

13 Jobs that Can Lead to a Business Analyst Job (other than software developer) http://www.bridging-the-gap.com/13-jobs-that-lead-to-a-business-analyst-job/

Phuong-My Do, Business Analyst
Business Analyst who loves negotiating requirements with Software Engineers and Bioinformaticians to make a better world.