Author: Adrian Reed

Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant and Director at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions to a range of clients in varying industries. He is a Past President of the UK chapter of the IIBA® and he speaks internationally on topics relating to business analysis and business change. Adrian wrote the 2016 book ‘Be a Great Problem Solver… Now’ and the 2018 book ‘Business Analyst’ You can read Adrian’s blog at http://www.adrianreed.co.uk and follow him on Twitter at http://twitter.com/UKAdrianReed

Best of BATimes: Business Analyst Jobseeking tips – Acing The Interview

Written by Adrian Reed on October 6, 2022. Posted in Articles.

Published on: January 7, 2021

The business and economic environment is incredibly tough right now, and I know from conversations with some of my connections that it’s a tricky time to be a BA jobseeker.

Competition is rife and it can be a challenge to know how to really shine in a job interview.

I recently facilitated a webinar panel session with Michelle Shakesheff and Saffron House (two senior BA managers) on this very topic. This article summarizes some key takeaways from that session, with a few of my own thoughts added in for good measure. It’s important to keep in mind that I’m based in the UK, so I’ll be reflecting on the expectations for job interviews here—I am sure expectations differ across the world so be sure to check out other articles and resources too.

Preparation Is Everything

When it comes to a job interview, preparation is everything. There are many aspects that need to be considered, including the three ‘Rs’: Research, Role & Rehearsal.

Firstly, if you’re serious about working for a particular organization, then it’s crucial to research it. This doesn’t have to be time-consuming, can be entirely ‘desk-based’ and is an opportunity to use a range of strategic business analysis tools. You’ll want to check out the organization’s website, if it’s a large organization it’ll probably have an annual report. What is its stated mission and strategic objectives? What are its stated values? Techniques such as VMOST can be useful for helping us to understand where a company is heading. Approaches such as STEEPLE are excellent for brainstorming external factors that might affect the organization. You might want to assess what you consider to be the biggest external opportunities and threats to the organization. Utilizing these (and other) techniques alongside general research will provide a picture of the types of project that a company is likely to be undertaking. You’ll pick up the language of the industry and organization, you’ll be well-placed to give specific answers to any strategic questions that the interviewer asks even if these don’t crop up, you’ll be well-placed to ask a relevant question about the organization’s strategy. You’ll also get a sense of whether this is a company that you’d fit into and actually want to work for!

Secondly, there’s the role. Read every detail of the job description, person specification and whatever artefacts you can get your hands on. Think back to your experience and be prepared to give an example for every skill or competency that is listed. One senior manager I used to work with always advocated creating a table to systematically work through a job description, breaking it down into its component parts and adding an example against each. If you do this, you’ll have the right example on the tip-of-your-tongue and won’t hesitate if a question crops up. Here’s an example:

Requirement on job spec	My example	My contribution	The outcome
*Process modeling & analysis*	XYZ Project: analyzed 25 processes, proposed improvements. Used BPMN.	Led process discovery, as-is and to-be modeling. Resolved conflict through workshopping.	All processes were implemented. Stakeholders loved the new processes as they’d been involved throughout.
*Resolving conflict*	ABC Project: Removal of permanent desks.	Ran a prototyping session so ‘hot desking’ workers could see the benefits.	Stakeholders who were reluctant became advocates.
*Analyzing business rules*	Etc.	Etc.	Etc…

Finally, there’s the rehearsal. I remember hearing polar explorer Allan Chambers speak over a decade ago. He gave the sage advice ‘never take your body somewhere your mind hasn’t been’. This applies for interviews too: take your mind to the interview room (or virtual interview room). Imagine the types of questions you might encounter, formulate your response, and say them out loud. What is the first thing you’ll say to the interviewer? You’ll get different questions on the day, of course, but you’ll feel more confident and prepared and your answers will likely be slicker and well-informed. This brings us neatly to our next topic, questions.

There Are No “Top Ten” Interview Question Lists

Although this might sound disappointing, there really aren’t any “standard” BA interview questions. There might be patterns that crop up, but the questions are going to vary depending on the specific requirements for the role. It’s also highly likely that there won’t be a “right answer” to any particular question—put yourself in the shoes of the interviewer and think what are they trying to understand from this question? And don’t be afraid to ask for clarification. It is genuinely hard to create unambiguous interview questions, and speaking personally, whenever I’ve been involved with interviewing candidates I take requests for clarification as an extremely positive thing. After all, BAs ought to be clarity-seekers!

It’s also important to answer the question that’s asked, not the one that you might have hoped the interviewer has asked. I’ve fallen into this trap myself in the past, and I can tell you it doesn’t end well… However, if you’ve considered the different areas of the job specification and have examples for each area you’ll be well prepared to pivot and adapt on-the-fly.

A word of warning here. One trait that seems to be common amongst most BAs I’ve ever met (myself included) is the tendency to say “we”. As BAs we work with others, and a success is a team success. This is fine in most circumstances, but job interviews are a place to say I as well as we. By all means discuss what the team achieved, but remember the job interviewer is going to want to know what you contributing. Hearing “We created and prioritized a backlog” is interesting. Hearing “I worked with the PO and coached them on the user story format. We experimented with different formats, but settled on user stories with some attached scenarios and acceptance criteria, which I wrote on behalf of the PO…” is more useful. Precision is great.

Talking of precision, frameworks can act as a common language. Being familiar with industry frameworks such as IIBA’s Business Analysis Body of Knowledge guide (or whichever is relevant for your context) can help. Using industry standard terminology such as requirements elicitation, strategy analysis, requirements lifecycle management and many, many more besides will help ensure that you and the interviewer are on the same page. Of course, it’s likely that the organization will have its own internal framework. If you’ve been able to learn about that in advance through your research, then use those terms too.

Remember: An Interview Is Two-Way

It might seem like an interview is purely for the employer, but this is far from the truth. It’s also you’re opportunity to assess whether the organization is a good fit for you. Do the interviewers treat you respectfully? Do they keep failing to turn up for the interview at the last minute without explaining why and then re-arranging? Keep in mind that an employer that treats candidates without due respect may well treat employees similarly.

On the flip side, you may well find you get on fantastically with the interviewers, and all of your instincts are that this is the job for you. Be sure to take the opportunity to ask the interviewer questions too. You might ask them about the size of the team, the challenges they are facing—this might be a chance to showcase the research that you’ve done and ask them a specific question about the strategic direction of the organization and how it impacts the BA team. Choose the right questions for the context, and use it to learn about the organization and the role.

Conclusion

Job interviews are nerve-wracking, but those nerves push us to prepare and perform well. Remembering the three Rs: Research, Role & Rehearsal, thinking about the questions that might be asked and remembering an interview is a two-way process can help.

Think “Re-use” When Writing Requirements

Written by Adrian Reed on July 28, 2022. Posted in Articles.

When working on a project or product development initiative, the focus is usually on getting the product ‘over the line’ within a defined timescale. There can be immense pressure to create requirements artifacts quickly, creating just enough to communicate the key business needs to developers and other stakeholders.

This is completely understandable, but it can lead to somewhat of a ‘groundhog day’ like scenario where requirements that are very similar (or even the same) are written multiple times by multiple teams. When the pressure is on, there is less opportunity to think about re-use. Yet requirements re-use, when executed well, can save time in the long run.

Dispelling Myths: “Re-use” doesn’t have to mean copying & pasting

One common misconception is that because no two projects or products are exactly the same, there is no way that any requirements can be reused. However, re-use doesn’t have to mean literally copying & pasting—sometimes it can mean that a set of requirements are used as a starting point to build from.

Imagine that you write a set of non-functional requirements for a customer-facing web application. If, in the future, another team elsewhere in the organization needs a web app, then surely the NFRs that you’ve written would be a useful inspiration? The requirements might only be 80% similar, but the existing artifact means that there’s no need to start from a blank page. Of course, this doesn’t remove the need to ask the right questions and engage the right stakeholders, but having an existing document to build from can save time.

In fact, there can be a benefit in having a “standard” set of NFRs for particular types of systems. Many organizations have their information security policies defined, their brand guidelines defined and so forth. Why not bring all of these policies together, adding other types of NFR, to create a corporate standard? This will likely vary by context, but certain patterns will be relevant for particular situations. Clearly, building or maintaining an internal application is likely to attract different types of requirements to one that is exposed to the outside world. This is just one example.

High level artifacts

It is also worth keeping high level artifacts that show the broad scope of what a particular system or product does. Context diagrams typically show the adjacent systems/actors that are relevant for a particular work area, and the high level data flow. One day, someone is going to want to replace a key IT system… having an up-to-date context model would provide a massive head start. The same is true of business process models. If a new process is implemented, this is an opportunity to identify a process owner. The process owner is typically responsible for keeping the process model up-to-date. Imagine having a central repository with all (or even some) of the organization’s processes stored. This cuts down the effort of ‘as is’ modeling. (I say ‘cuts down’ and not ‘eliminates’, because it’s usually still necessary to see how people are actually undertaking the work, which may or may not be exactly as it is documented!)

Teams and Individuals

Another way artifacts can be reused is as examples or exemplars. When a new BA joins the team, they will often need guidance over ‘how we do requirements here’. Of course, experienced practitioners will bring their own views, but it is useful to have an expectation of what ‘good’ looks like. Too often organizations simply have templates or written standards. These are useful, but alone they are rarely enough… templates or standards with examples are far more useful. This doesn’t just apply to written documents, it can apply to models and requirements stored in repositories too.

These examples can also be used when a BA needs to show a stakeholder examples of business analysis work. Imagine trying to convince a skeptical stakeholder to engage with the BA team. Having a successful case study to show them, along with some fragments of requirements artefacts, prototypes and a working solution to show them might just help set the context. Stakeholder testimonials from the project will help even more.

But There’s No Time!

I know, I know, at this point you’re probably thinking “we’d love to do that, but there’s no time!”. I get it, deadlines are harsh and nobody wants to work even longer hours. There might not be time within the project, but there might be time afterwards or during natural periods of downtime if you are lucky enough to have some of those. Taking time to spruce up requirements artifacts, putting them somewhere central, and cataloging them so they can be found will save time in the long run. It is a short term effort for long term gain.

If you are a BA manager, you might consider building in an ‘air gap’ between project assignments for individual BAs to wrap-up their work and consider re-use (amongst other things). In many ways, this is building a sustained repository of knowledge for the whole team… and isn’t that an effort worth pursuing?

Constructive Conflict Is Better Than False Agreement

Written by Adrian Reed on July 21, 2022. Posted in Articles.

Over a decade ago, I was in a workshop with a range of different stakeholders.

Everything seemed to be going well, and people seemed to be agreeing and we were even running ahead of the meeting schedule. Around halfway through the meeting a particular issue was being discussed, a conclusion was going to be drawn and a stakeholder interjected strongly and firmly with two powerful words. They simply said:

“I disagree”

I remember being taken aback by the bluntness. I live in the UK and our communication style is somewhat indirect most of the time. It’s far more normal to say “Hmmm, interesting idea, or what about…?” which is code for “That’s a crazy idea”. Or often the temptation might be to revert to the ultimate British stereotype and apologize “Sorry to be a pain here, but I’m not sure I entirely agree”. I’m sure British culture is not the only one that has such indirect nuance.

The reason I remember this meeting so vividly, even more than a decade ago is that those two words initially made people visibly uncomfortable. Someone was breaking the consensus; they were “creating conflict”. Yet that wasn’t the intention, and of course they didn’t just say that, the stakeholder went on to explain the source of their disagreement, and what they proposed instead. Thirty seconds later (once the stakeholder had explained themselves) any feeling of discomfort gently dispersed. What’s more, other attendees of the meeting started to question things, interject and show disagreement. One stakeholder questioning a decision had the apparent result in creating perceived permission for others to do so. And you know what? I am convinced that the output of that meeting was better as a result.

Don’t Let Conflict Fester

Many of us have been taught to consider conflict as bad and consensus as good. I suppose that is true in an ideal case, but if you’re working on any kind of large scale change how realistic is it that every stakeholder is really going to be ‘on the same page’ and in total agreement? If a government implements a new type of tax and requires businesses to submit more information, there’s unlikely to be a standing ovation from business owners. Yet that doesn’t mean that their input isn’t valuable—I would go as far as saying it’s essential!

Our fixation with consensus can lead to a situation where we achieve illusory agreement, a veneer of satisfaction. Dissenting voices get marginalized, as they’ll never agree (so why spend too much time asking them?). We carefully facilitate meetings so that there aren’t big disruptive arguments, as we’re desperate to hit all of the aggressive (sorry ‘ambitious’) project deadlines. Yet this dangerous glossy veneer is very quickly broken when people start to interact with the product or service that we deliver. All we’ve done is defer the conflict to an even less convenient time, often a time when there’s so much political capital riding on the ‘solution’ that’s been designed that there’s no appetite to change it.

Cultivating Constructive Disagreement

As business analysts, we can help avoid these situations. We have the opportunity to create space for constructive and respectful conflict, and we should certainly avoid us or others sidelining people just because they have contradictory views. In our analysis activities we should encourage constructive and respectful disagreement.

Taking an example, when setting up a workshop we have the perfect opportunity for creating the opportunity for a robust and respectful discussion. We can lay down an appropriate set of ground rules that allow for differences of opinions to surface. I’ve found myself opening workshops saying things such as:

“This is a controversial topic, and there are bound to be some differences of opinion. That’s to be expected. With that in mind please do speak up at any time and add your view, but please do be prepared to elaborate on it. Keep in mind I’ll be facilitating fiercely but fairly—and there might be times when I need to ‘park’ your item for later discussion. It absolutely won’t be lost, we will come back to it, but please don’t be offended if I need to do that.”

When we facilitate, we can actively prompt, asking questions such as:

“We seem to have complete agreement here; are there any contradictory thoughts. What have we missed?”

Ensuring that stakeholders have the ‘air time’, and ensuring that the most bombastic attendees don’t steal the limelight is crucial. Using a range of tools and techniques in the workshop to consider not only what we want but also what could go wrong can be useful too. Even just asking a question such as “That seemed too simple, might we have missed something?” can help.

Most of all, cultural nuances aside, we shouldn’t be afraid of the concise clarity of an expression such as “I disagree”. When someone says it they provide us with a gift, an opportunity to better understand them.

Analysis Efficiencies: Turning The Mirror On Ourselves

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

As analysts, typically we’ll spend a lot of time examining and critiquing the processes of other departments. We might be looking for ways to make an operational process slicker, quicker and ‘better’, or we might be looking to solve particular problems. There are a whole set of elicitation, problem analysis and process analysis techniques in our toolkit that help us do this. Yet how often do we turn these tools in on ourselves to examine our own practices to see if there are ways that we can improve? As practitioners of change, surely we should be looking to continually improve ourselves too?

I suspect we all intuitively do this, at least to a degree, but I wonder if it’s an area where there’s room for improvement. I’ve included some examples to whet your appetite below:

Deciding How To Decide: Have you ever got to an approval gateway in a predictive (waterfall-type) project and it’s unclear who needs to make the approval? Or the approver shirks responsibility? This can manifest differently on adaptive (agile/evolutionary) initiatives, for example with wrangling over the ‘definition of done’ with different stakeholders having different (and unresolved) perspectives. These things can fester if unresolved, perhaps stakeholders concede in the short term and sign on the dotted line, but resentment builds and bubbles up, only to explode out later at the most inconvenient time.

This creates friction and drama that takes time to resolve, and when it comes to organizational change, time is money. It’s therefore beneficial to spend a little bit of time up front agreeing how these types of decisions will be made. This sounds so obvious doesn’t it? Yet, so often in the blind rush to “just get going” it isn’t discussed… and it is only as the decision emerges is the omission spotted. Practical tools such as the RACI matrix can be extremely useful here.

Planning the Requirements Architecture: When BABOK® v3 was released back in 2015, one of many significant additions was a more explicit recognition of requirements architecture. If you have ever found yourself mid-project with a whole set of useful, but disparate requirements artifacts (“These process models are great. But how on earth do they relate to those user journeys, these scenarios and those wireframes?!) you’ll know what I mean.

Taking time up front to quickly and roughly sketch out how it’s anticipated that the requirements will fit together helps avoid this. Of course, things change, as requirements emerge, new types of artifacts suddenly become relevant (“Ah, so statuses are important… I think I’ll include a state transition model…”), however having a starting point to deviate from when appropriate is better than fumbling around in the fog.

On a legislative project, you might write a quick problem statement to act as a high-level goal/outcome, and define some critical success factors/key performance indicators which will act as desired outcomes. These will all link to the organization being compliant with a piece of legislation, that’s another (external) artifact, but one which some rules can be derived from. Those rules will include internal decisions about how the legislation is interpreted; so those probably need to be captured too. Those rules might be automated or orchestrated via processes, and there might be steps in a process which will be automated via some detailed functional solution requirements. You can see how these different concepts relate to each other here; and of course there will be other types of artifacts too. The point is that creating a quick sketch showing how the concepts map together before creating them will prevent artifacts from being created that don’t clearly relate to each other.

Planning How To Store/Manage Requirements Artefacts: If you’re lucky, you’ll have some form of requirements (or story) management tool. If that’s the case, does everyone actually know how to use it? Is there a common agreement around how things like priorities/statuses and other metadata will be used? If not, will this create noise and friction as the initiative progresses? If so, a short discussion up-front is likely to yield significant benefit.

If you are using documents and a shared document repository (e.g. word processing tools, drawing tools, spreadsheets etc.), decide things like naming conventions and version control conventions up front. It can be very confusing when someone in the team is using a file naming convention that uses “v0.1”, “v0.2” then “v1.0” when it’s signed off, when another person is using “FILENAME v1.0 (Updated) (Second Updates) (Final) (Really Final This Time) (Updated Again).docx”

Plan For The Analyst And Stakeholder Of Tomorrow: Stuff you’re creating today will be useful for the analysts and stakeholders of tomorrow. That process model you’ve created? If it’s detailed enough, I bet the training team would love to use it, and the operations team might too. It might be the catalyst to the creation of a single, unified process repository (if that doesn’t already exist in your organization).

Those performance non-functional requirements for your customer-facing website? You know, the ones that were like pulling teeth to elicit, that required benchmarking and speaking to the technical folk? They might be a useful baseline and starting point for others producing customer-facing web applications within your organization.

As we create artifacts, we ought to be thinking not just about how they can be used today, but how they might be used tomorrow and how we can ensure they will be found. This is a much bigger, organizational, question—however it’s one of the many areas where BAs can nudge the agenda. By creating common pools of knowledge, and by encouraging information sharing we open up channels for these types of artifacts to flow. This has the advantage that information flows in both directions and also that there will be a wider range of documents available at the start of projects too.

Of course, these are only four suggestions, there will be many more. The key is that we shouldn’t rest on our laurels; as BAs we should be looking to hone our craft and improve the efficiency and effectiveness as much as we can. This involves not just “speeding to get the job done”, but also thinking about the stakeholders of tomorrow!

Just Because It’s “Obvious” to You, Doesn’t Mean It’s “Obvious” To Me…

Written by Adrian Reed on June 8, 2022. Posted in Articles.

I can still remember the elation of passing my driving test here in the UK. As is the case with many skills, I often say that I really learned to drive in the six months after passing my test—these were the times where I found myself in unexpected situations that you just don’t encounter during driving lessons.

I still have a very vivid memory of going to a petrol (gas) station for the first time. This is something that they just don’t teach you how to do when you learn to drive. I’d seen people fill up thousands of times before, how hard could it be? Well, after trying to work out which of the confusing array of variants of ‘unleaded’ would be the best one to pick (Regular? Premium? Performance?), I eventually put the nozzle into the fuel tank and pulled the lever. There was an empty clunking sound. Nothing happened, and certainly no fuel flowed..

I tried again, and again a clunk followed by nothing. I could see the queue of people behind me getting increasingly irate as I tried to operate this baffling pump that just didn’t want to work (while simultaneously trying to look like I knew what I was doing). Eventually, a kind fellow-motorist whispered to me from the opposite pump: “You have to press the button to say whether you’re paying at the pump, or paying at the kiosk”. Right! Got it! This was one of the (then) new-fangled pumps that accepted credit cards. I was back on track.

To this day, I think it’s weird that you can pass a driving test without ever having to have pulled up onto a filling station forecourt, but I suppose there’s an assumption that it’s ‘obvious’ and everyone can do it. If you’ve been driving for a few years, it really is second nature. You probably know which side your car’s fuel tank is on, roughly how much it costs to fill up, and exactly how close you like to pull up to the pump. These things are “obvious” to you, but to a new driver they aren’t “obvious” at all, even if they’ve seen the pump used a million times before.

The “Obviousness” Trap

There’s a similar pattern in business analysis and projects. Stakeholders will often omit to say things, not because they are deliberately trying to hide something, but because it’s just so obvious that they don’t even think of it! This is sometimes referred to as ‘tacit knowledge’ and it can prove a real issue in change initiatives if it is not teased out. Not least because these ‘tacit’ areas can stop entire processes working if they are not addressed (much like the gas pump example above).

As business analysts we are tourists in the processes and situations that our stakeholders live in daily. We ask questions, we elicit information, but rarely do we know the finite detail —for that we rely on the talented Subject Matter Experts (SMEs). However, in our role of process-tourist, we need to remain curious, ask probing questions while observing and listening carefully. We need to watch out for the ‘obviousness’ trap—where stakeholders skip over something that is actually important.

A particularly good way of overcoming this can be to observe and shadow stakeholders, gently interrupting them when necessary to ask what they are doing and why. Observation itself is not enough, as we’re unlikely to understand the nuance, so interjecting when appropriate to ask follow up questions is crucial. Of course, this needs to be done with prior knowledge and agreement of those involved, and it’s important that they are briefed on the nature of the project or initiative (and the role of the BA, else they might worry about why they are being observed!).

Additionally, sitting with relevant stakeholders and creating process models or business use case scenarios can be extremely helpful. These help us to elicit and capture the flow of work, and ask questions about anything that is missing. It can also be helpful to ask what exceptions occur, or whether there are any other alternative flows. When combined with observation, it is a very powerful technique.

Whatever techniques are used, being aware of things that are obvious to one person but not another is key. Tapping into the tacit knowledge is key!