Tag: Skills


Avoid Illusory Constraints And Incentives

If you were learning to drive in the UK, chances are you’d get in touch with a driving instructor. Over here, many of the driving schools they work for have company names starting with the number 1 (often ‘1st CompanyName Driving School’).  I suppose if I were a driving instructor my default company name would be “1st Reed” or something similar.

It might seem curious as to why there are so many driving schools with “1st” in their company names. We might assume it’s a signal that people who learn with them pass their driving test first time… but I suspect there’s another legacy reason, which goes back twenty years or more.  You see, when I learned to drive, you didn’t Google a driving instructor, you used the Yellow Pages.


For anyone unfamiliar with the Yellow Pages, it used to be a thick local telephone directory of different companies. It probably still exists, but twenty years ago it was an essential reference for every household and could usually be found close to the (corded) landline telephone.  It was printed on thin yellow paper, and had thousands and thousands of companies listed.

You’d search for a category (‘driving instructor’) and then (with the exception of paid ads) the companies were generally listed in alphabetical order.  And company names starting with numbers were given preference, so a company named “1st Aardvark Driving School” would be listed above “Aardvark Driving School”… hence the incentive to start a company name with the phrase “1st…”.




The Constraints and Incentives Of Yesterday Might Be Irrelevant Today

Today, I would guess that very few people search for a driving school using a paper telephone directory, so this necessity to preface a company name with ‘1st’ is no longer valid.  Not only this, it could actually hinder findability…. Imagine if you heard somebody say their company name was “First Reed”.  Would the URL be 1stReed.com, FirstReed.com, First-Reed.com, or something else?  What keyword would you type into Google to search for them?

I wonder if issues of ‘digital findability’ might also start to affect musicians. With more and more people using voice-activated assistants, bands might get more airplay if they have a band name and a song name that is “voice assistant friendly”.  Don’t believe me? Try to get an AI assistant to find music by 90s band Campag Velocet and you’ll likely see the problem.

The point here is that constraints and incentives of yesterday (“We must start our company name with ‘1st’” or “Unusual band names sell records!”) might actually be disadvantages today.  The incentives and constraints have changed, and those that recognize that can use it to their advantage.


What This Means For BAs: The Importance of Healthy Challenge

This is where good business analysis helps.  It often feels that there is a human tendency to revert-to-norm and to “do what we’ve always done”.  In our world as BAs, this might relate to the way work is undertaken, the way a process works, or the way that technology is used.

In these situations there is a huge opportunity to tactfully challenge: to ask does it still need to be that way? And also ask what are the implications if it is implemented that way? Are we ‘baking in’ a constraint that is no longer relevant?

This starts by identifying those tacit assumptions and constraints and seeing whether they are really still valid. Techniques such as ‘five whys’, the brown cow model, or just informally asking questions with curiosity and listening deeply to the response can help a great deal.

Whichever techniques we use, having the confidence to build rapport and tactfully challenge accepted practices is key. Sometimes there might be a valid reason for the status quo… but if there isn’t, we might be able to help co-create a better way with our stakeholders. And if we can create something better, cheaper, slicker, better… that has to be a good thing!


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!


Encouraging Collaboration and Resolving Conflicts with Mockups

All business analysts have (or will) attend the same meeting with stakeholders so disagreeable that if you put an orange between them, they would immediately disagree on its color. If these stakeholders cannot bridge their disagreement, a great approach is to collaborate with the stakeholders to create lo-fi visual mockups.

When done correctly, BAs can use mockups to engage stakeholders in a collaborative learning exercise that includes the following elements:

  • Visual elements to depict subjects such as roles, actions, and relationships.
  • Auditory elements when discussing these topics.
  • Reading and writing elements when documenting discoveries and agreements.
  • Kinesthetic elements when modifying the placement and relationships of visual elements.

These are the styles identified in the VARK model of learning. Using this multi-sensory approach in a collaborative learning exercise can be bring together stakeholders, even if they have different learning styles.




Mockups can depict anything related to the business change – software screens, tables and fields in a database, or process flow diagrams. By collaboratively creating these items, BAs can engage stakeholders in a shared journey of discovery. During this journey, BAs can introduce new data points and information to gently transition stakeholders from entrenched “I-know-best” positions to the more neutral territory of shared learning. This additional territory can yield discoveries in terms of requirements and solution approaches. And sometimes, it can identify previously unknown common ground for adversarial stakeholders.

I participated in a real-world example of using mockups in this manner. During an elicitation session, two stakeholders adopted opposing views that involved a simple workflow. Each stakeholder had something of a point – stakeholder #1 argued that the solution should require completing a specific task before continuing; stakeholder #2 argued that finalizing that task later allowed for more flexibility.


I had mockups depicting a workflow for a related and similar process. These mockups were simple slides with screenshots and text boxes calling out the user workflow. I quickly made copies of those mockups to depict each stakeholder’s approach. Each stakeholder was able to instruct me on tweaking their mockup as needed; then, using the mockup as a visual aid, the stakeholder could articulate their approach more effectively. By comparing them side-by-side, it was easier for both stakeholders to see the validity and shortcomings of each. During our discussions, a third approach emerged, which we were quickly able to mockup. The stakeholders negotiated from their combined shared learning experience and agreed that this third approach would satisfy their requirements.

This real-world example of resolving stakeholder conflict with mockups reinforces the importance of the visual:

  • Stakeholders could more easily understand the relationship between their disparate requirements when mocked up.
  • Stakeholders could better appreciate alternative user workflows as the mockups clarified it.
  • Stakeholders could envision and agree upon a compromise solution when mocked up.

The mockups clarified the merits and obstacles of each approach and made the third (compromise) choice obvious. Even if the stakeholders had not agreed on the compromise solution, the depictions provided by the interim mockups would have clarified their point of disagreement and made their conflicting priorities clear.

Even in requirements, a picture is worth a thousand words.


The Better Meeting Manifesto – Stop Having Terrible Meetings!

Terrible meetings are an unfortunate feature of modern working life.  It doesn’t have to be this way: read on to find out how you can take a stand and achieve better meetings for all!


Encountering a terrible meeting in the wild

Most of us have suffered through a terrible meeting.  You know the scenario.  A group has assembled in an airless meeting room in response to a calendar invitation.  The AV equipment is faulty, so the unlucky person with the controls has spent the past 10 minutes trying to connect to the remote attendees.  Everyone else is making small talk or discussing the previous meeting.  When the equipment finally cooperates, you all realise that the meeting organiser isn’t in attendance.  Undeterred, you check the meeting invitation – only to find it unhelpfully blank.  The group makes a valiant attempt to progress things; however, you can only get so far with the main person missing.  The meeting finishes early; the group sighs and agrees to reconvene another day.


Then there is the alternative, more insidious variant.  At first glance, things begin well: the meeting logistics are on point, the right people are in the room, and you received the outline ahead of time.  Yet once the meeting starts, issues soon become apparent.  There are too many items for discussion.  Due to aggressive timeboxing, there is little scope for more than brief comments regarding each.  People grow increasingly frustrated with the lack of opportunity for input, the schedule drifts, the meeting overruns and several agenda items are never reached.  The group makes little progress; the attendees are sentenced to a re-match to address the same material the following week.


Regrettably, these experiences are far from rare.  Is it little wonder, then, that we sometimes find it hard to get our stakeholders to make time in their diaries for yet another meeting?


Trojan horse meetings: a false solution

To combat meeting aversion, some session organizers resort to subterfuge.  One such ploy is the classic Trojan horse maneuver: book meetings into the calendar under the guise of something more palatable.  Often, the decoy is a workshop.  For example, a document sign-off meeting might be billed as a ‘requirement sign-off workshop’, even though the session is less about facilitated qualitative review and more about sitting around a table together to agree that the ensuing work can proceed.  A stakeholder interview to elicit information about a particular aspect of their role might appear in the calendar as a ‘process workshop’.  A team meeting might become a ‘team workshop’, and so on.


Superficially, this tactic can bear fruit – at least in the short term.  So why do people feel more positive about workshops over meetings?


  • Meeting fatigue

The first reason is novelty, pure and simple.  People want respite from busy calendars booked up with tedious and unproductive meetings.  Workshops are attractive because they generally feature interactive activities instead of the usual dry discourse.  Even the mere hint of this variety can suffice to lure stakeholders into believing they are in for a welcome change.


  • Productivity by association

A workshop is a facilitated intervention that seeks constructive input from all attendees to achieve a defined output.  In positioning their meeting as a workshop, the organiser aims to appropriate the qualities of focused, engaged participation and demonstrable productivity from the workshop format and confer them upon their meeting session.


Unfortunately, the aspiration of engagement and productivity will only get you so far.  Without good facilitation, a meeting will still be terrible no matter how you dress it up.  Worse: a bad ‘workshop-but-actually-a-meeting’ experience might harm your work by putting stakeholders off attending workshops in the future.




Another way

Rather than deflecting attention from the problem, it’s time to take a long, hard stare at the meetings in our lives.  Faced with a wilderness of terrible meetings, how can we act to change things for the better, no matter which end of the calendar invitation we are on?


  1. Make meetings pointy

All meetings should have a clearly defined purpose and intended outcome.  No point?  No meeting.

As the organizer:

If you are responsible for setting up a meeting but cannot answer the questions ‘Why are we meeting?’ and ‘What should we have achieved by the end of the meeting?’, this is a sign that you should reconsider.  Is a meeting necessary, or might there be another way to work with your stakeholders (e.g. using your organisation’s preferred collaboration tool)?  Don’t be afraid to postpone or cancel a meeting if circumstances change.


As an attendee:

Your time is as valuable as anyone else’s.  Invitations are not obligations.  If you receive a vague meeting invitation, contact the organizer and politely ask them to clarify the meeting’s purpose.  A helpful sentence to use is ‘Please could you confirm what will be covered in this meeting so that I can prepare?’ – it helps you sound engaged while also acting as a prompt for the organizer to step up their game.


  1. Energize and engage

Meetings can’t always be fun, but don’t make them any more painful than they have to be.  Start with the intended outcome and take active responsibility for getting there.


As the organizer:

A great tip from BA guru Angela Wick is to ‘verb-noun’ your meeting titles to set the intention for the session outcome: instead of ‘Requirements Review Meeting’, try ‘Finalise Requirements for Procurement’.  It instantly puts your attendees into a more active mode of thinking which will carry into the meeting itself.  Set a clear schedule with realistic timings and manage the session actively to keep things on track.  Don’t let people doze off: check in frequently with all attendees (particularly those attending remotely) to ensure that everyone feels involved and has the opportunity to provide input, even if it’s just a quick thumbs-up/thumbs-down vote.


As an attendee:

It might not be your meeting, but you are part of it – and its success or failure.  Help things go smoothly by doing any necessary pre-work ahead of time and coming to the meeting prepared.  Be fully present and listen actively – nobody wants to recap points made five minutes ago because you were not paying attention.  Consider whether your comments contribute usefully to the intended outcome before speaking.  Where you can, support the facilitator.  For example, can you help by relaying remote attendees’ comments to the room?

  1. Master your meeting modes

Following the recent pandemic, many of us continue to work flexibly between the office and home; meetings now frequently mix face-to-face and remote attendance.  These ‘hybrid’ sessions can be tricky to get right, but it’s not impossible.  With a bit of planning, you can be a meeting mode superstar.


As the organiser:

Meet your stakeholders where they are.  If people are uncomfortable with coming into an office space, forcing an in-person meeting will result in no-shows.  Save face-to-face for the times you truly need it and focus on providing a good experience online for everything else.  Be aware that attendees may decide to group up and attend online from the same room, so give specific instructions if your planned activities require each person to have separate access to a computer.  Design for online: take full advantage of the synchronous and asynchronous collaboration tools available through the applications at your disposal.  Get equipment warmed up in plenty of time, ready to get going when the meeting starts.  And whatever you do: don’t apologise or make excuses!  You’re about to lead a fantastic online session, after all.


As an attendee:

If you are attending in person, don’t forget to acknowledge and address any people attending remotely.  As a remote attendee, be mindful of your audio input.  Use a quality headset with a good microphone if you work in a shared office environment – and be prepared to mute yourself when you aren’t speaking to minimise disruption.  Nothing is worse than hearing background noise or someone thundering away at their keyboard.


What tips and tricks have you found to tackle the tyranny of terrible meetings?  I’d love to hear your thoughts!