Tag: Business Analysis


The Strategic Flexibility Approach in Solution Design

Compared with strategic management, strategic business analysis focuses on designing a sustainable solution in order the long term strategic goals and future demands to be fulfilled with the best way. Constant changes in internal and external environment require business analysts working on a specific solution to constantly assess solution approach and capabilities for success.

Strategic flexibility it terms of a solution may be defined as the ability of the solution to adapt to substantial, uncertain, and fast-occurring environmental changes that have a meaningful impact on the solution performance.


Strategic business analysis involves a future outlook. Detection of emerging threats and opportunities, prediction of their future impact, and the development of solution responses is something that should be considered before a solution definition. Ideally, the “future paths” should be incorporated in the solution itself in order “strategic adaptations” to be achieved with less cost and effort.

Because the environment is so uncertain and fast moving with many potential threats and opportunities, business analysts often finds it difficult to react using conventional business analysis approaches. Evaluating the likelihood and nature of the impact of each environmental change that can consequently affect the solution requires is challenging.


It is common that during the analysis phases of a solution definition, considerations of alternative ways to increase solution’s flexibility tend to be limited and ad hoc and not comprehensive, systematic, or formal.

Moreover, internal and external constraints on the style and experience of the business analysis team tend to dictate an inflexible approach that is not taking into account the future challenges and adaptations that will be necessary for the solution’s sustainability.




Another challenge in embracing strategic flexibility is the lack of objectivity in flexibility and scalability options. This is inevitable given the lack of information for the future conditions and the difficulties in predictions.  Options concerning sustainable solutions tend to be subjective and informal. Flexibility levels are rarely monitored or even measured. An example of a subjective KPI is the time and the cost required to modify core flows in a system or the time and effort required incorporating a new group of users in an existing solution.

Identifying assumptions that had been made during design phases is crucial in order to clear out the future state and to develop contingency plans that can contribute to lower time, cost and effort in future changes. Well-defined contingency scenarios with specific responses associated with each future specific event may be decrease the response time required, once those events occur.


Paying attention at the confirmation of the elicitation results and trying to find areas for sustainability and preparation to change improvement should be cultivated in business analysis approach.

Last but least working towards defining specific evaluation criteria concerning the long term horizon solution flexibility as a response to future events is essential in an era of fast – moving and numerous environment changes.

  1. David A. Aaker, Briance Mascarenhas, (1984) “THE NEED FOR STRATEGIC FLEXIBILITY”, Journal of Business Strategy, Vol. 5 Issue: 2, pp.74-82, https://doi.org/10.1108/eb039060

Important Techniques for CBAP Certification Examination

This again is a very frequent question that we receive from our CBAP participants. BABoK V3 has 50 techniques and obviously, all techniques would not be of equal importance for all three certifications. Some techniques are more important to junior business analysts and some techniques are used more by the Senior Business Analysts.

In this article, we are going to categorize the techniques into three categories based on their complexity levels. Low complexity techniques are more useful for ECBA aspirants. Medium and high complex ones are more important for CBAP examination aspirants. High complexity techniques would require CBAP practitioners more time and effort to understand and be comfortable with.

You must be wondering how did we come up with this list?

It’s primarily based on inputs from many of our past CBAP participants regarding what kind of techniques challenged them more during the CBAP certification examination. Secondly, most business analysts start their careers as requirements analysts and as part of requirement analysis work, they use some techniques more extensively than others. Techniques that typically belong to strategy analysis planning and solution evaluation are the techniques where usually many have a lesser comfort level and obviously, they need to pay more attention to those techniques. Three specific areas that we would advise CBAP participants to pay attention are the techniques related to Financial Analysis, Decision Analysis, and UML.

Here are a few blogs and videos that we published which will help CBAP aspirants:



Metrics and KPI


Data and Concept model



Process analysis


Business model canvas


Non-functional requirements





Stakeholder list, map, and personas

Here is a summary of important techniques for CBAP certification:

Author: L N Mishra, Co-Founder, Adaptive US


L N Mishra co-founded Adaptive US, a business analysis skill development organization, working with professionals from 80+ countries in skyrocketing their BA career and staying ahead of the game. He has helped 5000+ BA professionals to achieve better salary and role in their BA career. He is the ONLY trainer who holds all 7 certifications from IIBA (ECBA, CCBA, CBAP, CCA, AAC, CBDA, and CPOA).

LN has authored 12 best-selling books on business analysis. He is also a Versatile trainer, coach and speaker on all IIBA Certifications.

Grab a copy of best-selling eBook –  FREE 50 CBAP Exam Mock Questions Plus Comprehensive CBAP Exam Information utilized by 1000s of BA professionals to ace their IIBA exam.


LN is also a member of IIBA Question Setting Committee, mentored 100+ global clients and 3000+ Bas. He has 24+ years of working experience as a Business Analyst and conducted 1000+ workshops in business analysis, requirements engineering and agile, project management, requirements engineering and different BA Skilled webinars.

Please write to LN if your thoughts are in sync with his or if they spark a thought in you.


Best of BATimes: 99 Tips To Be A Fantastic Business Analyst

Published on August 29, 2019

1. BA yourself

This is one thing that only some professions can do. An Actuary can’t actuary himself, a developer can’t code herself, a mechanic can’t mechanic himself. We can analyze ourselves. Use your skills. Decide what a fantastic BA is; research, interview, question and then review yourself. Do some gap analysis and then formulate an action plan.

2. Be nice

No one wants to work with a jerk. No one wants to help and supply information to a jerk so engender support. Thank people, go out of your way to be personable, establish friendships and mutually positive working relationships.

3. Understand project lifecycles

Get to know all the steps in project lifecycles, not just your own and especially the intricacies and peculiarities of the adaptation used by your organization.

4. Be a mentee

There is much to be learned from Analysts further along the road than you.

5. Present well

Don’t dress like a scruff, smell nice, clean your teeth. These are surely basics but I have met people in business who have overlooked these things and they are avoided. You can’t be avoided and be successful. 

6. Prep prep prep

When you go to meet a stakeholder, especially for the first time, prepare. Understand who they are in the business and project context. Ask them for any pertinent information to be sent for your review in advance. Maximize the time with them to appear (or be) effective and efficient and they will happily give you more.

7. Be on time

Your prompt arrival in the office and at meetings will give you more poise than if you rush in late. It is the fruitage of an organized and self-correcting individual.

8. Work on your confidence

We’re not all naturally confident but by reassuring ourselves of our abilities in our BA skills or in our industry knowledge we can instill the needed confidence and trust from our business stakeholders that we can understand their world view and needs.

9. Don’t reject difficult things

They help you grow. Be the BA that accepts unusual assignments and see your career enriched and flourishing.

10. Get good at cost benefit analysis

Don’t leave this to the PM. At project inception, or for minor changes, be able to determine with appropriate certainty whether to accept or reject activity. Maintain a project which can stand-up on its own merits.

11. Be optimistic

Pointing out the bad may be necessary but if you find yourself always the nay-sayer then fix it. Problems are our business. Our optimism can make for a gentler change process.

12. Get your desk in order

Give your workspace a make-over. Keeping it clean and orderly can help you be organized and looks a lot more respectful.

13. Go to a conference or two

Hear some new stuff. Mingle with your peers. Feel proud to be part of a greater something.

14. Help others

You have a project deadline, sure, there’s always one looming but give your fellow BAs your assistance. It will broaden your knowledge and strengthen your team.

15. Be strict about your change management

Keep a record of changing requirements and details about them. It will save you the red face when, inevitably, someone will ask you later for paperwork.

16. Do your actions

If the PM has to continually chase you for your actions they will resent it.

17. Don’t be offended by the red pen

Your work will be reviewed, heavily. Welcome critique and correction. Never be upset about any proposed edits. The individual has spent time immersing themselves in your work and for that you can be grateful. It will make your work better, or at least more acceptable to your audience.

18. Volunteer to share your knowledge

Blog, post, present at lunch-and-learns, write-up how-to guides. There are always people who don’t know what you know so share.

19. Model

Use models a lot. Business people invariably find models easier to verify than paragraphs of information and it brings the potential delivery to life. Architects, Developers and Data Analysts thrive on a well-produced model.

20. Learn, learn and learn some more

If you have the means then don’t stop learning. There is so much training available in BA skills, industry knowledge, peripheral project skills, business knowledge, techniques and soft skills.

21. Offer plentiful walk-throughs

By walking-through your outputs with developers, testers and business representatives you reduce the risk of misinterpretations.

22. Finish your projects

This is especially true if you are a contractor. It’s not good practice to leave a project part-way through if you can help it.

23. Develop strategies for juggling

You will have to work on many things at once. Find what works for you to avoid loss of productivity. If you have yet to nail this there are plenty of productivity tips and hacks on the internet.

24. Clear paths for people

Be someone who anticipates down-stream problems and blockers for yourself and others and intervene.

25. Categorize people but know your exceptions

Use personality and character traits to help you understand the motivations and reactions of your team but note that exceptions exist. Tailor your interactions to fit.

26. Don’t jump to solutions

Have problem-formulating conversations to focus your mind away from solution-mode.

27. Form collaborative relationships

When you collaborate you are more likely to get early and continuous buy-in, nothing will come as a surprise to your end client and you get immediate feedback on your work. It’s worth the extra effort.

28. Find your key SME voices

The quality of Subject Matter Experts is not equal. I have seen business users hide information for a variety of reasons (most understandably) making elicitation more than the usual effort and I have had System Testers guess answers and present information as fact. Hunt for good sources of information and verify what is said.

29. Play requirements back

Saying things like: “So if I understand this right, what you needs is…” saves misunderstanding.

30. Work to uncover implicit requirements

What assumptions have you or your customers made that they haven’t vocalized. Set aside some time and thought to uncovering these.

31. Know your audience

The level of detail that you go to should reflect your audience, know this before you start your elicitation. Get it wrong and you either waste time or have to re-work.

32. Recognize that accuracy is important

Particularly in your written English. If you can’t get that right, what else might get called into question.

33. Start with context

Ask: “Why the project exists?”, “What will be the end results?”, “What benefits are sought?” Then work from there.

34. Document what you won’t build..

..and get it agreed. It doesn’t mean it can’t be changed but it will at least be recognized as a change rather than something that you missed.

35. Get creative

With care not to promise an outcome, suggest ideas and alternatives to users during elicitation. Possible options can be used as a sort of model to tease out other requirements.

36. Read widely

The IT industry is constantly changing and working practices follow hot on the heels. Our understanding of business practice, psychology, methods for collaboration and effecting change progresses. Manuals, how-to guides and handbooks to support our work are plentiful.

37. Don’t forget your non-functionals

If you don’t include these in your document template as standard, add a section for each non-functional as a reminder to consider it.

38. Don’t gild the lily

It may not be scope creep as such but it’s easy to gold-plate our requirements with unnecessary items. Admirably this is usually in response to wanting to deliver the best but these types of extras add up. Work out what your Minimum Viable Product is and then be sure to note any additions as just that.

39. Revisit your prioritizations often

Work with your group of SMEs to get your product features delivered in the right order but remember that things change so schedule re-prioritizations throughout delivery.

40. Evaluate your own skills

Choose a couple of areas for improvement, write them down and formulate some actions that will help you improve them.

41. Look for “free”/cheap benefits

By knowing what’s off-the-shelf or can be achieved with relative ease you can maximize the product and minimize the cost.

42. Ask for feedback

At suitable points during and at the end of projects get personal feedback. Asking people who will give you constructive critique is valuable. Keep it. In years to come you can see how this helped you to change and grow.

43. Find balance

Don’t neglect your personal life. Finding a good work-life balance helps you cope with the ups and downs of projects.

44. Connect with others

Associate with other Business Analysts. Everyone knows different things and that diversity is valuable. Learn, share, help and be helped.

45. Know when to shut up

You’ve raised a risk or an issue but no action has been taken, so you raise it again or differently. It’s good practice to be assertive but there comes a point when you have sufficiently noted it and taking it further causes consternation. Learn where that point is and stop before you reach it.

46. Be a mentor

You know more than you think you know. Give back to the profession by sharing that with someone following in your footsteps.

47. Work as a team

When you work with other BAs, even if you’re tasked on different items, work together. Peer review, support, offer and ask for opinion and share experience.

48. Make your research visible

If you do background reading, conduct surveys, read manuals, hold workshops then put your findings as links or appendices to your documents. Don’t make someone who may need to pick up your work at some later point have to start from scratch.

49. Expand your comfort zone

Do something a little bit uncomfortable, just a little. It will make you capable of more in the future.

(See www.batimes.com/articles/personal-growth-through-discomfort.html)

50. Be agnostic to the solution

If you begin with a pre-determined solution or have a particular software package in mind you won’t be working on behalf of your client.




51. Be flexible to software development lifecycles

Learn to work waterfall, agile, fragile, whatever your client wants. Help them build on what they have.

52. Work with positive people

When you get a choice, pick to spend your work hours with optimists. Lift your chin up and thrive with them.

53. Don’t plagiarize

It’s fine to get inspiration from other text but word them in your own way. The process of breaking something and re-working it allows you to assimilate it properly.

54. Create your own templates, improve others

If templates don’t exist within your organization start to build a repository as you work. Have one eye on how a future project may use the template. If your organization does have templates, seek ways to improve them.

55. Hone your toolkit

Rich pictures, sequence diagrams, business model canvas, running workshops.. and the other scores of tools and techniques in the BA toolkit. Practice them and then get them into your workplace. The more the merrier.

56. Encourage newbies

We were all new once. The profession is constantly refreshed with new and trainee BAs. Welcome people. Help them.

57. Don’t get stereotyped

Take on projects in areas that you haven’t done before so that you have experience and confidence in delivery in as wide a range of topics and disciplines as possible.

58. Avoid too much future-proofing

While it’s a very useful consideration some attempts at future proofing just don’t fit with the future when you get there. Unless it has wide application and has relatively no cost or impact to the project don’t overengineer it.

59. The devil is in the detail

Ask for detail and then spend time understanding complexities. If you don’t, annoying requirements will rear their ugly heads later, when you’re further down the road than is desirable.

60. Order your own tasks

It’s in our nature to do enjoyable things or things which are easy or small first and then rush others. Avoid this by monitoring deadlines and dependencies taking into account impacts from other people and their availability.

61. Decide what your goals are

Ask yourself where you want to be in 5 years and put a plan into place. It may be various certifications, it may be working on certain types of projects, with technologies or in specific locations. Work out the steps you need to get there.

62. Ask for help

No man is an island. There is no shame in asking for help whether about your career, with techniques or technical aspects.

63. Archive and catalogue

Don’t leave files, part finished documents, reference material and other artefacts as collateral damage of your work. Archive your documents, catalogue your information and generally make it easy for people to work out what are the most recent versions and what supports them.

64. Have a to-do list

Don’t risk forgetting important tasks for something as simple as keeping a list. Be organised.

65. Its ok to make mistakes

We are human and mistakes are inevitable. Know that you will make them and decide that dealing with them diligently and humbly will be appreciated and respected.

66. Estimate using metrics

If you’re asked to estimate for a piece of work, use quantitative methods as much as possible and share the information on which it is based.

67. Add a glossary

I have not seen a BA deliverable yet that hasn’t benefitted or would benefit from a glossary (either within the document or at project level). To determine what goes into it, consider your audience. You may need to add business terminology to give framework from IT readers and IT and project terminology for the business.

68. Vanilla is not the only flavor

Don’t forget about alternative flows. The abnormal activities are generally the pain points for most businesses. Overlook them at your peril.

69. Get your must-haves right

The MoSCoW rating is incredibly useful and the priority of requirements must be stated explicitly but it is only useful if you have ratified that a must-have requirement is absolutely necessary. Double check.

70. Chunk up your work and take breaks

By creating a series of much smaller tasks you maintain motivation as you complete activities and as a result have natural break points to re-energize you ready for the next task.

71. Speak up

If you see a possible method of improvement have the courage to vocalize it, respectfully and professionally.

72. Flesh out a plan but be flexible

Plan your assignments in a work-breakdown structure, so you can keep an eye on your own progress but don’t be too rigidly stuck to it that you can’t make the most of stakeholder time when they are available.

73. Do it now

If you get the choice between doing it now and doing it tomorrow; do it now. Procrastinating individual items adds up to lost time and missed deadlines.

74. Be motivated and committed

Volunteer enthusiastically, actively pursue end goals, deliver on your deadlines.

75. Find your USP

Maybe you’re a people person, good with data, can see the bigger picture, are an influencer, have specific technical expertise or domain knowledge, run killer workshops, are highly accurate….everyone has a unique selling point. Whatever it is, find it and use it.

76. Be an observer

Keep an eye on what your peers are doing. Look for cross-over and gaps between their work and yours.

77. Don’t cut corners

Guessing, not completing research fully, ignoring the quiet opposing viewpoint, not determining the full stakeholder group, failing to verify background information, removing valid approval stages are all ways to store up later problems. Don’t cut corners.

78. Run your own project

Is it possible to start a little business of your own? Doing this lets you really test your BA skills.

79. Display kindness and patience

When projects get pressurized this will make you stand out and be someone others want to have around.

80. Understand your Subject Matter Experts

Put yourself in their shoes. You’ve invited them to sit in a long meeting? Make it interesting, schedule breaks and bring biscuits.

81. Get your unfinished specs reviewed

Reduce your own risk of large rework by shipping parts of your document early and get feedback.

82. Take the initiative

Make suggestions. Improve your own team’s processes. Create bodies of knowledge. Organize socials Involve yourself.

83. Keep your requirements updated to the end

A change has been made at the eleventh hour, everyone knows about it, is there any need to take time-out to correct the documentation, especially when the pressure is on?….Yes. If you don’t, no-one will be sure of any of it in the future.

84. Take a step back

During meetings and workshops, take time to observe; interactions between people, gauge motivations. There is a lot more to be learned than comes in through the ears.

85. Control/Challenge scope

Consider scope constantly. It is the bread and butter of getting the optimal solution for the composite group of stakeholders.

86. Mock stuff up

User interfaces, documents, reports. Let your end users see and play with the final product at the design stage.

87. Minute your meetings

It doesn’t have to be War and Peace but make notes. Dictate, doodle or mind map if it’s a more effective or efficient method for you.

88. Give people a “starter for 10”

People provide what you want more quickly if they’re not starting from scratch. If you have a template, provide it. If you want data, provide the table to be populated. If you want a quote, propose a sentence.

89. Learn standards

If there is a UML or ISO way of doing something then try to use it. It’s less ambiguous.

90. Use data analysis tools

Many Business Analyst roles include research in data. You can be more self-reliant if you are capable at manipulating it.

91. Use requirement ‘numbering’ for more than a unique reference

Use prefix letter, suffix letters and sub-numbering to store information about the source (stakeholder or actor), expected delivery method (various IT systems, manual processes, teams, department or companies) and dependencies on other requirements.

Eg, CS75-S.1 (CS = Customer Services, S = SQL, .1 = 1st child requirement)

92. Don’t be vague

Make requirements specific. Eg the phrase “needs to be run regularly” should be “needs to be run twice a day, usually at 12pm and 5pm” and the phrase “other systems use it” should be “three Access databases, listed in Appendix C, link directly to the data”

93. Find your best packages

Find and get proficient with tools and application supporting BA work. Eg, for producing and tracking requirements, for producing diagrams, flows and other models, collaborating and conducting meetings, managing work, etc.

94. Change control your documents

Applying version control saves your readers’ time. Be specific about what’s changed in your version history and use function for highlighting changes.

95. Understand development basics

Gain some knowledge in the basics of development; processes, data and events, components and re-use, integration with other applications, design principles and constraints. Learning to write in a pseudo code style can help with that mentality.

96. Understand test basics

Gain some knowledge in the basics of testing; test condition design, what a tester needs from your documentation.

97. Conduct Stakeholder Analysis

Don’t leave this to your project manager, do your own. Know who your influencers are, your VIPs and any potential “troublemakers”.

98. Ask effective questions

Questions are the keys that unlock treasure troves of information. Closed questions are useful when you need to be specific and open questions are needed to allow free-flow of knowledge transfer. Learn how to make them effective and unbiased.

99. Get qualified

There are a number of qualifications tracks available in various jurisdictions. International Institute of Business Analysis, British Computer Society and International Requirements Engineering Board. For gaining knowledge in the fundamentals as well as sharpening practitioner skills it is invaluable and a résumé necessity.


Best of BATimes: 4 Business Analyst Interview Questions And Answers To Kickstart Your Career

Published on November 7, 2019

If you’re just starting your career as a Business Analyst (BA),


knowing the usual types of interview questions can help you prepare to impress your potential employers.

After all, knowing the possible interview questions will help you prepare the right answers that will make you stand out from other candidates who are vying for the same position.

Although the requirements for Business Analyst positions vary depending on the company, there are a set of common questions that you’re most likely to hear in every interview.

These questions could range from a simple “Why a career in Business Analysis?” to more in-depth queries, like the kind of tools you use, so the more familiar you are with these questions, the better equipped you’ll be to ace your interviews.

To aid you on how to do just that, here are four Business Analyst interview questions and possible answers to help you prepare to leave a positive impression on your prospective companies.

Question 1. What Is The Role Of A Business Analyst In A Company?

As a business analyst, you play a crucial role in guiding businesses to improve their products, services, software, and processes through data analysis.

Plus, you can bridge the gap between IT and your employers to help boost efficiency and translate data into useful and actionable insights.

As such, you’ll need to emphasize the specific roles of business analysts. If you have experience in the field, discuss some of your previous functions with your interviewers.

BATimes Nov07 01

Here are some of the things you can consider to help you discuss the roles of a BA.

  • Business analysts can take on specific roles within a company project such as System Analyst, Application Designer, Business Planner, Technical Architect, Data Analyst, etc.

If you’ve played these specific roles in the past, expound on what you did and the solutions you came up with.

  • The job of a BA will vary based on the requirements of your potential employer – some BA roles may be limited to IT projects, with a few extending to marketing, accounting, finance, and more.
  • Your primary role as a BA is to help determine the needs of your company, uncover the problems – including using predictive technology to predict future issues (to some extent) – and come up with business solutions.
  • Aside from technical skills, your role as a BA will require you to have a good grasp on engineering concepts, possess leadership qualities, and excellent communication skills.

Question 2. What Are The Crucial Tools For Business Analysis?

There is a wide array of tools and software that business analysts use to perform several functions required of the role.

With that said, interviewers will ask you what the crucial tools are for business analysis so they’ll know which ones you’re proficient in and what you can bring to their company.

If you are proficient with tools like MS Office, Structured Query Language (SQL), Blueprint, programming languages such as Python and R, Tableau, and more, bring them up during the interview.

Most interviewers will also ask you outrightly about the tools and the training you are certified in, but instead of going through the whole list, bring to focus a few of your most recent ones.

For instance, if you have undergone a CBAP certification training course, then discuss how it has enhanced your skills and how you can apply it to your prospective company.

BATimes Nov07 02

Doing so helps give your potential employers an idea about your skills and proficiency, and whether or not you already have what they need or if they need to train you for specific tools.




Question 3. How Do You Handle Difficult Stakeholders?

Remember that being a Business Analyst means coming up with solutions, but you’ll also need to prepare for the possibility when your proposed solutions are met with resistance.

Many factors can contribute to this, but among the rest, human factors like – difficult stakeholders – might be one of the most challenging to handle.

Your potential employers will want to know how you can manage this type of situation since it is bound to happen in every company.

You won’t need to provide an entire outline of your answers during your actual interview, but keep these few points in mind when formulating your possible responses.

  • Spot your “difficult” stakeholders from the group, listen to what they have to say, and exercise a significant amount of patience.

If you cut them off or be impolite towards them, it will only lead to misunderstandings, and that will not help you resolve any of your issues.

  • Some stakeholders are difficult because they are not comfortable with some of the things in your project. So take the time to dig deeper into their issues by listening to what they say and answering any questions they might have.
  • As much as possible, meet and discuss with your difficult stakeholders personally as a way of showing them that you are committed to working towards the same goal with them.
  • Continuously engaging your difficult stakeholders helps them understand that their contribution is valuable to your project. Their resistance could also stem from valid points of view, so it’s crucial that you don’t just dismiss their opinions.

Keep in mind that there are no perfect answers, but being prepared for possible questions like this will always help you have concrete responses.

Question 4.  Do You Have Any Questions For Me?

Asking tons of questions comes with the job of being a Business Analyst, and one of the best places to demonstrate your ability to ask relevant and insightful questions is during your interview.

This part of the interview that you can turn into a conversation by asking questions about the company, its processes, and more.

Aside from demonstrating your abilities, asking relevant questions also shows your potential employers your interest in their company, which can only help increase your chances of getting the job.

BATimes Nov07 03

Here are a few questions that you can ask your interviewers.

  • How does your company handle systems analysis, and do you have a dedicated systems analyst?”

There are companies with job postings for BAs when what they really want is a Systems Analyst/BA, so it’s best to clarify this ahead if this is not the type of role you would like to fulfill.

  • Which project phases are your BAs involved with?”

If your interviewer says that business analysts are only involved in requirements, then the company might be looking for a Requirement Analyst specialist.

This might not suit you if you want to perform a deeper and wider BA role, so you should get this out of the way during the interview.

  • Does your company have a central BA team, or does each function have its own BA team?”

Asking this question will help you determine whether or not there is a central team that will allow the pooling of knowledge.


There might not be perfect answers to your business analyst interview questions, but being prepared by learning the possible responses will help equip you for the big day.

Remember that being a business analyst means solving problems, and your interview Q&A is the first obstacle you need to overcome in a long list of challenges coming your way in a BA career.

Also Read: Business Analyst Manager Interview Questions

Did you learn something from this post? Please share this with your network if you agree. Cheers!


The Tyranny Of “Default”: Be Careful When Choosing Analysis Techniques/Artifacts!

At its essence, a lot of what we do as business analysts involves co-creating a shared understanding. Whether that’s a shared understanding of a problematic situation, or of a set of requirements or features, a common theme is that we work to understand different perspectives and ensure that people are ‘on the same page’.

This can cause some challenges when we want to communicate complex ideas. Text is a challenging media to convey complexity, and the English language is just brimming with words that have multiple meanings. For that reason, it’s very usual to use a combination of text, models and conversations to ensure that key stakeholders are aligned.


When we create a model, we are essentially codifying some information in a way that can be later referred to. Codifying typically involves using some form of notation (whether that’s a business process modeling notation, or the symbols of an alphabet when writing text), and there will usually be particular rules on what elements of the notation mean and how they should be used.  For example, particular shapes on a process model represent particular things, particular words in a textual paragraph have a particular meaning.

Yet when we encode our analysis in this way, how often do we reflect and think “will my stakeholders understand this?”.  Will the consumers of the information both know how to read it, and, ideally like referring to it as it’s a format that works for them?  Perhaps we don’t think about this quite as often as we could…




The Tyranny Of “Default”

I have a confession to make. I love Business Process Model & Notation (BPMN).  I could quite easily ‘geek out’ and create process models to an executable level, using just about every BPMN symbol and construct that is available to me.  But, as those of you who are familiar with BPMN will attest, if I did that the resulting diagram wouldn’t be very accessible to the average stakeholder.  It would be somewhat akin to me sending an email in French to someone who only speaks English.  It might be possible to pick out some elements of the communication and work out what is going on… but it’d be very difficult to draw conclusions.

This absolutely isn’t an argument against BPMN by the way—it’s stil one ofl my preferred notations—but it highlights the importance of thinking of the artifact’s audience and choosing an appropriate level.  With BPMN, I might create a ‘view’ of a process using a cut-down palette of symbols, and model at a much higher level, so it is more intuitive. Equally, I might choose to use ‘boxes, arrows, diamonds and lines’ instead where it is appropriate to do so…

The key point here is flexibility.  It is very easy to get stuck in a rut and choose a technique because it’s the default.  You probably have a favorite approach or technique, which might mean you tend to default to a particular type of artifact. Or perhaps your organization has templates or tools that ‘nudge’ you towards a particular style.  That can be useful, it can embed consistency… but it can also lead to things being articulated in a particular way “because that’s the way we do it here, and that’s the way that we’ve always done it”.  Neither of which, on their own, are particularly compelling reasons.


Light The Fuse: Ask “Why Are We Using User Stories”

If you like a bit of controversy, next time you are working on an agile project, ask “why do we use user stories here?”.  Usually, the response will be a blank face, followed by either “because we’re agile” or “well… the tool is set up for user stories… so….that’s what we do”.

But are these really valid responses?  There’s certainly nothing in the agile manifesto that decrees user stories are mandatory.  The term ‘user story’ isn’t in the Scrum guide at all. So why default to user stories?

Of course, user stories do have merit, particularly in agile. Yet the choice to use them should be a conscious one. In fact, user stories alone are probably not enough… they will probably need to be supplemented with regular collaboration, acceptance criteria and you might even decide to document some journeys or prototypes.  It’s likely that most successful teams already do this, but it is worth highlighting.   Some of this might emerge as you discover more about the requirements… but having at least an idea of what the requirements architecture will look like up front will save pain later (e.g. “We might use prototypes, so let’s agree that one prototype will span multiple user stories… we’ll capture the links here…).

So, this article certainly isn’t criticizing user stories. However, as with any profession, we need to regularly challenge ourselves and challenge our ‘defaults’.  It is worth remembering that we have a wide toolkit at our disposal. If a plumber approached your sink with a hammer and started smashing it (rather than figuring out the right tool for the context), you’d be somewhat annoyed. An explanation of “ah, I always use a hammer” is unlikely to help.  The same is true in our profession too… and it is worth remembering how broad our toolkit is. Which provides us with many possibilities!