Hello, we are TCC.
We are passionate about business change. We help people improve the way they deliver projects and programmes.
We are passionate about business change. We help people improve the way they deliver projects and programmes.
If you're looking for example interview questions for business analysts then it's probably a fair guess that you either want to secure a business analysis job, or you are recruiting for a new business analyst! We will consider the situation from the perspective of the interviewee, but of course if you are looking for ideas on how to run a successful interview to recruit a business analyst then you should find plenty of ideas below.
Before looking at specific questions, put yourself in the position of the interviewer. What would you be trying to find out about any prospective candidate? It's more than just "have they been a Business Analyst before?" and "do they know a bunch of fancy business analysis techniques?". It is also "will this person add value to our operation?", "will they work on their own initiative?" and "will we actually like working with them – will they fit in with our team?".
Success at any interview is often as much about presenting yourself as a capable, willing, nice person to work with, as it is about impressing them with your skills, although both will be important. Also, remember that an interview is two-way. You are also trying to establish whether you would be happy working with them.
Of course, you still need to be a good business analyst in the first place! See our information on how to be a good business analyst for some helpful pointers.
Below are some general questions, followed by some business analysis-specific questions, but do remember that much of the interview will be influenced by human and interpersonal factors. So whatever your answers, try to be positive not negative, be genuine, be honest. Take notice of the interviewers' job roles and names as you are introduced and keep these in mind. This should allow you to tailor your answers to your target audience.
There is no set answer. This is about you, but they do not (usually!) want your full life story, so think of what it would be useful for them to hear. They want to know what relevant jobs you have held and why you are now leaving one of them. Be spontaneous and enthusiastic but focus on what you would want to know if you were asking the question. Try to understand their needs, then answer in relation to this. They already know about themselves as a company, so don't waste too much time trying to impress them with your research into their company, although a little knowledge displayed can be good. They need to know about you! And they don't (usually) need to feel threatened by your encyclopaedic analysis of what is wrong with their company!
They want to know why you think you will be good at this job. Focus on your strengths that fit what the job was advertised to cover, and the successes in these areas you can describe from previous experience.
A difficult question to answer, because only the most conceited person thinks they have no weaknesses. However, you do not need to be weak in the very areas in which they have asked for strength in their advertisement. Perhaps admit to being less strong in a peripheral area and follow on by stating how you mitigate against your "weakness". For example, "I find I worry about unexpected situations arising when I am facilitating workshops, especially where I don’t know the participants, so I always allow myself time to prepare, and have a brief chat with all participants beforehand to ensure I understand their position and views on the agenda.".
This should be an easier question to answer, since you will have a job description and targets will usually be agreed with your direct line manager. You can check if this is the case in the interview.You will also know the metrics for success of the projects you work on and will, as a BA, drive the Benefits Realisation activities. Of course, a successful project is a whole team success, so you cannot take all of the credit!
Here, they are really asking "Why should we hire you?" but it is also your opportunity to answer your own question of "Do I want to work here?". Unless you have already decided that you don’t, this is your opportunity to ask a few practical questions about the work culture and the team you will be working with, and to convey your enthusiasm to join the team.
This is a tricky question! Be cautious here, as there is a movement away from the idea of building a one-off big BRD, FRD or TRD, in favour of "just in time" evolution of detail (This is the Agile approach). In general terms (as there is not a one-size-fits-all standard):
Some organisations will expect a full description of requirements at the outset of a project, which must be signed-off before further work is undertaken; others will take an Agile approach and allow requirements to emerge and evolve, but against a higher level documented set of requirements (known as a Product Backlog or Prioritised Requirements List). Your research into the company before the interview may help you to determine which they use. Otherwise, you could ask whether they take an Agile or a Traditional approach to their projects.
Traditional Approach: Advantages of a Requirements Document:
It helps prevent:
Agile Approach: Disadvantages of a detailed requirements document at the outset:
PESTLE is a business analysis tool used to assess the environment in which the business has to be operated. It stands for the perspectives of: Political, Economic, Sociological, Technological, Environmental, Legal. It is used to analyse the external environment and identify constraints, opportunities and pressures of the environment from those perspectives.
Porter Five Forces is a framework to analyse the level of competition within an industry, based on the 5 forces of: Suppliers; Buyers (customers); Rivalry with those already in the industry; Threat of new entrants to the industry; and Product substitutes which may threaten competitiveness. It can be used to understand the competitive environment in which an organisation operates and to influence organisational strategy. The originator of this technique is Michael E. Porter of Harvard University.
A Use Case model consists of use case diagram supported by use case descriptions. The diagram shows the processes (Use Cases) in an area, and the actors (job roles) associated with them. The Use Case Descriptions give a description / step-by-step account of the process.
A business process model using swim lanes is the most popular process modelling technique. It shows a sequence of tasks performed by a particular actor or department, triggered by a specific event.
A User Story is a format for a requirement derived from Extreme Programming and widely used by Agile teams. It is a requirement stated from a user point of view, with the format:
As a <user role>, I want
<requirement> so that
<business value>
For example:
As a hotel receptionist, I want
the ability to record a reservation, so that
I can charge the customer for the room, and have the room available when the
customer arrives.
Mike Cohn’s book "User Stories Applied" is a good reference.
INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized Appropriately and Testable. It is a way to check the effectiveness of User Stories by building them to these criteria. Bill Wake is the author to note in association with this.
Application usability is the quality of the system that makes it suitable for its end users. In other words, it allows end users to achieve what they need to. It concerns not only the right functionality in the system but the user interface through which this is presented to the user. User Experience (UX) is a job-role in its own right with its own professional standards.
Functional Requirements: These are requirements which define what the solution will do (or give the user the ability to do)
Non-functional requirements: sometimes referred to as "Quality Attributes", these specify how well the system needs to perform against certain criteria. These criteria are attributes such as performance, security, usability, compatibility which are contributory to its success. They are a required characteristic of the system.
The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.
The original paper is in Japanese. However, these categories have been translated into English using various names (delighters/exciters, satisfiers, dis-satisfiers) or (Will, Want and Wow factors).
The Kano model offers some insight into the product attributes which are perceived to be important to customers and those which they take so much for granted that they would not be excited by their presence, but would be dissatisfied by their absence. Kano's model focuses on differentiating product features, as opposed to focusing initially on customer needs.
MoSCoW is a time-dependent way of looking at requirements priorities in terms of:
It is fully described as a part of the DSDM Agile Project Framework but widely used by other agile approaches.
Making the difference. Trusted by leading organisations worldwide, since 1981.