Tag: Communication

The Tyranny of the Algorithm

Written by Adrian Reed on August 16, 2023. Posted in Articles.

A while ago, I noticed that some people changed the way that they were writing LinkedIn posts. Rather than writing in sentences and paragraphs, everything would be written in this weird separated way with everything spaced out in a really unnatural way. Then certain other common patterns appeared (e.g. using PDFs documents with multiple pages, or ‘carousels’ as some people call them). Video was huge, then not huge, and so the trends fluctuated. Some of the formats seemed really good and useful… others… not so much (we’ve probably all clicked on the occasional ‘click bait’ LinkedIn post…).

I gather one of the reasons that people post in particular ways is to get maximum exposure, and to do this you have to pander to the algorithm. It is, after all, the algorithm that will decide how many people see your post… and not all posts are created equal. Those that get more ‘engagement’ will be seen by more people (and, very likely, get even more engagement). Yet the algorithm decides what counts as ‘engagement’.

There’s nothing inherently wrong with this. LinkedIn is a private enterprise, it can (I suppose) run its operations however it chooses. But take a step back for a moment, and let’s make a hypothesis here:

The algorithm has changed the way people write content and interact with others on LinkedIn

I’m making no moral judgment here, and the way that people write and engage with each other has adapted over the years. But let’s follow this to its logical conclusion: social media algorithms have the ability to influence the style and formats in which people communicate. It decides what content gets seen (and doesn’t get seen). Again, as users we might be OK with that. But I hope that there is someone within those companies asking a whole set of ethical questions…

Avoiding Biases and Unintended Consequences

In particular, it’s important to consider whether algorithms might lead to bias, and might inadvertently disadvantage or affect particular groups or stakeholders, or whether they might have other types of unintended consequences. For example, I’d imagine that the LinkedIn algorithm probably aims to keep people on the site for as long as possible, and serve them up relevant adverts. But when people learn its nuances, they start to ‘game’ the algorithm, meaning that some folks are more likely to get their content seen than others. Presumably, LinkedIn eventually learns about this too, and adapts the algorithm, and the process repeats.

Yet unintended consequences like this aren’t limited to IT or algorithms. Nor are biases (there are plenty of well-documented cognitive biases that affect people too). Crucially this is an area where BAs can help ask some of the difficult questions, and get beyond (or at least highlight) potential issues.

I have often thought it interesting that within most organizations, if you ask the question “who is responsible for regulatory compliance” you will get a clear cut answer. There is usually a legal or compliance team, and often a named individual who is responsible and accountable. Ask “who is responsible for the ethics of this product or project?” and (outside of some very specific domains) you’ll likely get a blank stare. Or, you’ll get a word-soup answer that boils down to “we’re all responsible”. And when everyone is responsible, too often nobody steps up to ask the hard questions.

The Ethical Imperative

This is a space where BAs can add significant value. As BAs we’ll be used to conducting stakeholder analysis, thinking in terms of the different stakeholders or personas who will be impacted by a particular proposal. We can extend this thinking by asking “who isn’t here around the table, who is missing from these conversations, and how can we ensure they are represented?”.

We can ask the difficult, but important ethical questions, and ensure that the projects and products that are progressed by the organization are in line not only with its strategy but also its values. If there’s a strategy-execution divide in many organizations, that’s nothing compared to the values-execution divide! (We’ve probably all had experiences with organizations that say they ‘put the customer at the heart of what they do’ that… definitely don’t actually do that!).

Often, as BAs, we are able to take a step and ask “what is the impact of this”, and “what does success look like for X stakeholder group?” and “how does that vary from what the Y stakeholder group thinks?”. By taking a holistic view, balancing different viewpoints and putting an ethical lens on things, we can hopefully reduce the risk of inadvertently introducing bias or unintended consequences.

This involves us having the courage to ask bold questions and keep ethics firmly in mind. If we don’t, there’s a real danger that the ethical dimension will get missed. A situation that I’m sure we’re all keen to avoid!

Avoid The “Saying/Doing” Gap

Written by Adrian Reed on August 10, 2023. Posted in Articles.

Elicitation is a core part of business analysis, and there are a vast array of elicitation techniques at a BA’s disposal. However, if you’re like me (and most BAs) you probably have a few favorite techniques that you gravitate towards. For me, I’ll often start with interviews and workshops, using document analysis to gain context and perhaps some observation to see how things really work.

While it’s completely natural to have frequently-used techniques, it’s important not to forget that other elicitation techniques exist. It is very easy to fall into a rhythm of reverting to a particular set of techniques irrespective of the context, project or situation being examined. This could lead to a situation where other techniques might have proved more efficient or effective. In particular, it’s important to use an appropriately varied set of techniques to avoid the ‘saying/doing’ gap…

People Often Do Things Differently In Reality

As any experienced BA will tell you, asking someone to describe how they do their work will often give you a very different result to going and seeing them do their work. There are often parts of the process that are so obvious to the people undertaking the work that they don’t even think about mentioning them. Imagine if someone asked you to describe the act of driving a car… you might explain the steps of opening the car door, putting the key in the ignition, checking mirrors and accelerating away. You probably wouldn’t mention putting on a seatbelt, or closing the door… but these are things that are very important! If we are wanting to understand an as-is process, we’ll often want to understand those ‘seatbelt’ moments too.

There’s also the tricky subject of exceptions and unofficial workarounds. Sometimes there will be exceptions that the designed process never really catered for, so workarounds have emerged. These workarounds might not be documented anywhere, or if they are documented they might be documented in an informal way. Knowing about these workarounds (and the exceptions that cause them) is important too—any new process really ought to cater for these situations without a workaround being necessary.

All of this points towards the need for a mixture of elicitation techniques.

Use a Mixture of Elicitation Techniques

Interviews and workshops are excellent techniques for understanding stakeholders’ perspectives on a situation and asking probing questions. Yet if we are going to gain a broader understanding of the situation, it’s important to mix and match our techniques. There are also some techniques that might not traditionally be thought of as elicitation techniques that can be brought into the mix too.

Here are just a few examples for consideration:

Analysis of Reports, Data & MI: What does the data show you about the process? When are the peaks? How many queries go unanswered? What are the most common queries from customers? Why are those the most common queries? What are the uncommon situations that might be causing exceptions or problems?
Observation, Sampling & Surveys: Observing colleagues undertaking their work can help us understand how the work really works, but requires a good level of rapport (else people might revert to the ‘official’ process rather than what they actually do). It isn’t always possible to do this, so sampling can be useful. In a call center where calls are recorded, if (with the relevant legal permissions) you can gain access to call recordings, you can potentially sample elements of a process and see how things are done. Or, you might issue a survey to the relevant customers or internal stakeholders. Sometimes giving people some time to reflect (rather than asking for an instant response in a one-on-one interview) can be useful.
Document analysis: A very broad technique, but looking at things like process models, procedures, exception reports and so on can prove useful. Of course, there is often a gap between how a process is written and how it is actually executed, but documentation is a good starting point.
Correspondence or sentiment analysis: This is really a particular type of document analysis, but if you are looking to improve a customer-facing process, why not look at some of the correspondence that customers have written about it? What do they like and dislike? Look at complaint logs, which elements are they complaining about? After all, complaints are a potential source of innovation, when they are filtered and used as input to process improvement. If your company has a social media team, perhaps they are capturing suggestions that have been submitted via these channels also.

Of course there are many other elicitation techniques too, these are just a few examples. But crucially, initiatives usually benefit from a mixture of elicitation techniques, some of which require synchronous stakeholder input, some of which require asynchronous stakeholder input (and therefore gives reflection time), and some of which initially don’t require stakeholder input at all (e.g. document analysis).

With a breadth of elicitation techniques, we gain a broad understanding of the current situation (and future needs). This helps ensure we deliver a valuable solution to our stakeholders.

Best of BATimes: Business Analyst vs. Business Analytics Professional: What’s the Difference?

Written by Savaram Ravindra on August 2, 2023. Posted in Articles.

A business analyst and a business analytics professional are not the same. Very often, people get confused about these 2 terms.

Many times, they are used interchangeably. Few start-ups and organizations also seek out a business analyst when they are actually in search of a business analytics professional. Among the analytics enthusiasts who are searching for a job in business analytics, this causes huge confusion. So, it would be better if the difference between a business analyst and a business analytics professional is well-known.

Who is a business analyst?

As defined by IIBA(International Institute of Business Analysis), the business analysis is a discipline of determining the business needs and identifying the solutions to business problems.

A business analyst coordinates between a client and the technical team. A client can be either the internal team that is required to work with the technical team or external, with the requirements to solve a particular problem. The technical team has the ability to either deliver a service or build a product.

The business analyst makes sure that the service or product provided by the technical team meets the client’s present requirements. He/she collaborates with the external and internal stakeholders in the implementation as well as design of the service or product.

Who is a business analytics professional?

A business analyst doesn’t work with data and is mostly concerned about processes and functions. On the contrary, reporting and data are the key components of a business analytics professional’s job.

Let us consider 3 major elements that help us in understanding the difference between a business analyst and a business analytics professional.

Analytical problem solving skills

The business analysts utilize different techniques to analyze the problem and determine the solution. They conduct thorough analysis and deconstruct the solution or problem by making use of various methods. Few examples of this include decision models, business process models and use cases.

On the other hand, business analytics executives use logical thinking, predictive analytics and statistics to solve the business problems.

Let us consider 2 examples that state the way in which the business analytics executives solve the business problems.

If a continuous stream of loan applications are being received by a particular bank, the business analytics professional will develop and implement a model to give a recommendation on which loan applications that bank must lend to.
From a catalogue launch, if a manufacturer of home-goods wants to predict the expected profits, a framework will be applied by the business analytics executive to work on the problem and develop a predictive model to provide recommendation and results.

The capability to tell story with data

The business analytics professionals must be in a position to share the insights they derive from raw data. They must share the insights in a way that is clearly understandable to the end stake holder as most of the times, the end stakeholder will be a non-technical and/or business-centric person. They shouldn’t use technical jargons while communicating and must present the insights in the simplest possible way. The stakeholder can be an internal or external client. Most of the times, they are business professionals with zero technical background and the authority to take decisions rests with them. The business analytics professionals are very good story tellers and they make use of advanced tools like Ds.js, R and Tableau to share their findings or story to the end stakeholders.

On the other hand, the business analysts are good communicators and they make use of excel, word and PowerPoint to create visual models like wireframe prototypes or work-flow diagrams. They are also good at creating technical documentations. But, they don’t develop custom dashboards making use of modern data visualization tools like business analytics executives do.

Programming skills

A business analytics professional works with structured data and utilizes SQL in order to retrieve data from databases. He/she will write SQL queries to analyze and extract data from the transactions database and develop a set of visualizations if the management requires some advanced metrics about their company.

The analytics professional will also have a good expertise on the data science programming languages like Python, Julia, Hadoop and so on. He/she is good at visualizing, analyzing and manipulating data.

A business analyst, on the other hand, has nothing to do with data. Their focus is more on the functions and processes. The significant business analyst value propositions incorporate the calibration and testing, IT re-engineering, process, model requirements, KPIs(Key Performance Indicators), vital pain points, context and business value maps. A business analyst possesses strong knowledge in development frameworks such as SLDC. He/she makes use of Excel to perform quantitative calculations and analysis. The programming skills are not used by the business analysts to perform calculations.

Conclusion

It is evident from the above that both these functions are extremely important for a successful business model. From the business decisions it automates as well as enables, the value of analytics can be derived. Every time, a business analyst will first begin with the business questions but not with data. They are also the domain experts who manage the project from the beginning till the end.

On the other hand, a business analytics professional begins to solve the business problem making use of data first. He/she cares about the retrieval of data, format of data and source of data. Data is the raw material for a business analytics professional.

A business analytics professional and a business analyst work closely to make sure the final project is delivered successfully. This explains the difference between a business analyst and a business analytics professional.

Posted on: 2017/12/27

Deconstructing the Stress Factors in the Business Analyst Role

Written by Shanekia (Shay) Thomas on July 13, 2023. Posted in Articles.

Over my years as a professional, I have come to realize that the title of Business Analyst (BA) is a heavy one. How each organization defines the role can be completely different. A BA in Company C may be a requirements scribe, whereas a BA in Company D wears many hats: process analyst, project manager proxy, test validator, etc. Whichever way the role is defined, I think stress has plagued many of us who call Business Analysis our profession. If you have found yourself feeling anxious or overwhelmed at any point during your career in business analysis, you are not alone. There are many factors that can play into that feeling. I want to deconstruct a few of the typical stressors here and offer some potential solutions.

1. Not understanding the area of study:

BAs are often on the fringes of the business. It is analogous to being a window cleaner. As each pane gets cleaned, we can see a little more into the room in front of us, but we are still only seeing a portion. Each pane reveals a bit more about the room, but the entire picture may still elude us. We are on the outside looking in. Not having the full picture of the business, its processes, or its business drivers can leave a Business Analyst feeling inadequate and uninformed.

As a BA, questions are your friend (like your squeegee on the dirty window). I have been guilty of feeling like I was asking too many questions. What I realized is that if I don’t ask my second follow-up question, which may lead to a third follow-up question, I risk not gaining the knowledge that I need to understand the business to write better requirements.

Feeling anxious because we don’t know the business is stressful, but not asking enough questions to get the understanding we need will cause more stress later. If you have 100 questions, don’t stop at number 99. Ask all 100. If you find that the participants are getting a little impatient with your questions, gently remind them that you are trying to understand them as an outsider looking in. Once you gain a better understanding, your perspective changes, and you are no longer looking through smudged windowpanes.

2. Large complex projects:

If you have been on projects with multiple stakeholders, then you may feel pressure before you even type the ‘r’ in requirements. It can be daunting to start a new project. You may be working in a new department with all new faces. Unfamiliarity coupled with complexity can be intimidating. In instances like this, it is important to build alliances.

Find project team members that you can trust. Relationship building is so important to your success as a BA and will also go a long way in helping alleviate some of your stress. It can be nice to have a friend when you are on the fringes.

3. Requirement Elicitation is not one size fits all:

For those who do not practice Business analysis, gathering requirements may seem like a simple task. You find out the need, and you write it down. It is not at all that simple. Different stakeholders require different elicitation methods. Some stakeholders are very forthcoming with information. Others can be more guarded or may simply not know how to express the need. Interviewing may work for some. Passing e-mails back and forth may be more appropriate for others.

The key here is to really take the pulse of your stakeholder population (a personality assessment of sorts). Understand their optimal mode of communication and how you can best work within the confines of that. Also, do not neglect your best mode of working as well. Finding the proper balance between stakeholder and BA methods of working will be key to helping alleviate stress.

Do not feel pressured to use an elicitation technique that is not a good fit. We do not want to simply check boxes on the list of deliverables; we want to add true value.

4. Feeling pressured by deadlines:

Every project comes with a start and end date. BAs often occupy a few task lines on that project schedule, and the pressure to meet those deadlines can feel immense. We don’t want to be the ripple that causes the project timeline to shift.

As BAs, we often take the deadlines given to us and work to fit within them. If we do not understand the business, the project is complex, and we don’t know what elicitation method to use when starting a project, then how can we be tied to a deadline?

Speak up when you feel that timelines are not realistic. Open and honest conversations can be uncomfortable but can also be wholly necessary when the quality of work is on the line. The timeline may not shift because you raised a concern, but I guarantee you will feel a little less pressure when you have been open and honest and raised your hand.

This is not an exhaustive list; it is just some of the key things I noticed in my career as a previously stressed and anxious BA. In the end, it is important to remember that your success as a Business Analyst rests in part on your ability to perform the job well. Different stress factors can become obstacles to your performance. Understanding those factors is the first step in tackling them. Apply different techniques to alleviate the stress. You will thank yourself.

Process Redesign: Problem Prevention or Detection

Written by Adrian Reed on July 12, 2023. Posted in Articles.

I recently changed phone networks, and wanted to keep the same phone number. I’ve done this before in the past, and it’s always been a relatively simple process. Usually, a changeover date is agreed, and on that date there’s an hour or so where the phone number is inactive, and then everything works again as usual.

Unfortunately, this time was different. Something went wrong with the ‘porting’ of my number, and days later I was left in a situation where I couldn’t reliably receive calls or texts. Pretty annoying for someone who relies on a phone for work. It was doubly annoying that I kept getting told “wait another 24 hours to see if it magically corrects itself” and it was only when I made a formal complaint that things got resolved…

Now I’ve no idea how number porting works on UK mobile (cell) phones, but from what I read online it’s more complex than a consumer might imagine, involving lots of interfaces and interactions between the old and new companies, and sometimes problems occur. This got me thinking about how some processes preempt problems, and others leave the customer high-and-dry…

Predictable Problems: Prevent or Detect

When designing processes, there will be some potential problems that can be predicted. If you were designing the payment processes for an online shop, you can predict that at some point in the future someone will try and use a stolen card to make a transaction. You can try to prevent that by restricting the shipping address to be the same as the cardholder address, and by processing the card transaction prior to shipping the goods.

Prevention involves use of sensible validation and “guard rails” to ensure that things go as smoothly as possible. Yet there will be some predictable problems that you can’t prevent, but you can still detect as soon as they occur. Once detected, the process can notify relevant people or systems, so that action is taken to rectify the situation.

An example: “Your bags didn’t make the flight”

A few years ago, I was flying from the USA to the UK, with a flight connection at Dallas Fort Worth. Unfortunately, my initial flight was delayed and I landed at the airport really late. So late that even though I ran as fast as I could, the gate for my transatlantic flight had closed. However, luckily the plane hadn’t left and the gate staff explained they were holding the flight for passengers like me who were transferring. Phew! I boarded the plane, relaxed, and tried to sleep for the flight.

When I landed in London and turned on my phone, I got a notification. It read:

“We’re sorry, but your baggage (1 of 1) for record locator <<Reference number>> is arriving on a later flight. For help, go to the <<Airline Company Name’s>> baggage office”

It also had contact details, and a link to track my bags. Now, the fact my bags didn’t make it onto the flight wasn’t really a surprise to me… I nearly didn’t make it onto the flight! But this preemptive message meant I didn’t have to waste time at the baggage carousel. I went straight to the baggage counter, they explained it was on a flight about 12 hours later and they’d courier it to my home address.

A Process Design Pattern: Detect, Inform and Solve

A key point here is the process the airline had set up meant that the problem (a delayed bag) was detected by them, they provided relevant information to me and provided a practical solution. I suspect most customers accept that problems will occur. But when the customer notices the problem first, surely that indicates an opportunity to improve the process?

This highlights the importance of building in problem detection into manual and automated processes. Going back to my earlier example of a phone number transfer that went wrong, surely there must be some way for the phone company to detect that the process failed? Wouldn’t it be far better for them to ‘notice’ this before the customer does, and either fix it straight away or at least inform the customer so the customer doesn’t have to raise a query?

This might sound like it will add processing cost. Yet, it might actually be cost saving or cost-neutral. When things go wrong, customers often spend an inordinate amount of time navigating helpdesks and eventually making complaints. This is really a type of ‘failure demand’—work that is best avoided. By creating a situation where customers don’t have to raise the query in the first place, it reduces these incoming queries and will also likely increase customer satisfaction. In many cases, this will be a clear win/win!

This pattern of prevent or detect, inform and solve is one well worth remembering for us as BAs. I hope that you find it useful in your process analysis and definition!