Tag: Skills

Behavior for Internal vs. External Customers

Written by Jeannette Olson on December 7, 2022. Posted in Articles.

Mentoring my first BA apprentice this year has been challenging and extremely rewarding. It’s provided me with a great sense of achievement but also a renewed love of the craft, I highly recommend it for ‘old hats’ like myself.

Some of the questions an apprentice asks are eye-opening since they are coming from an ‘education first’ posture, and as a mentor, you get to help them put what they’ve learned into practice. As I’m primarily self-taught and only certified four years ago, I’m sometimes taken aback that I’d never asked these questions myself but thinking through the questions I’m thrilled to find I usually know the answer.

For most BA-related questions though, the answer usually starts with, IT DEPENDS.

Also, the BA craft is an art, not a science, and an important trait a BA builds is FLEXIBILITY. Their behavior should change based on whom they are dealing with, and the stage the project is in.

As an IT BA, everyone is a customer, but we need to treat internal and external customers differently, based on the relationships we’ve built with them. If you’ve repeatedly worked with an internal business partner from IT or another part of the organization, your interactions with them can be informal and somewhat friendly, while remaining professional. Interactions with ‘new’ internal business partners should be professional first, and friendly but formal until you’ve proven you can deliver. Trust is earned, not given, playground rules apply.

Turning this idea around for external customers, in my company’s case product vendors, an IT BA should expect to be treated like a customer, as they help ‘guard the gate’ for their internal business partner during product justification, selection, and sometimes implementation project phases. They need to be the product manager in order to evaluate solutions against requirements, arrange for vendor demos, and justify the purchase of new solutions. This can also mean assisting in the delivery of functionality, standing in the business partners’ shoes initially, and ensuring quality and acceptance of the solution.

In essence, IT and business partners ‘subcontract’ product evaluation and selection to the IT BA, who must always act in everyone’s best interest, within existing IT constraints. It’s a complicated dance, while the IT BA needs to be the main vendor point of contact throughout product selection and possibly delivery, they often also need to assist with negotiations for all stakeholders to reach a consensus. This is doubly true if they are also involved in testing. I like to call this zone Switzerland.

I recently helped select a solution provider based on a solid match to our requirements, however, once the contract was signed, we found that there were slight changes to the product that made it a less desirable choice. Partnering with the internal business customer, we successfully negotiated with the vendor to use the original version of the product for delivery, understanding that while they would continue to support this version, future functionality enhancements would only be applied to the new version of the tool. This vendor had tried to take control of delivery early on, attempting to require us to submit to their implementation script, but slowly understood that we needed to be in charge due to extreme resource constraints. As a result, our initial communications were short and sweet, this was how it needed to happen, and they grudgingly complied. By the time we started testing the new application with live data, however, we’d become a team.

Seasoned BA’s can pull this off effortlessly, while a newer BA, especially an apprentice, needs guidance and practice to build the confidence they need to be successful. I think this is true for both waterfall and agile methodologies, I hope this helps.

Avoid Illusory Constraints And Incentives

Written by Adrian Reed on November 23, 2022. Posted in Articles.

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

Written by Jimmy Rodela on November 9, 2022. Posted in Articles.

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.

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.

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.

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.

Bottomline

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!

Written by Adrian Reed on November 3, 2022. Posted in Articles.

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

Written by Paul Burgdorf on November 2, 2022. Posted in Articles.

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.