Tag: Tips

User Stories Without Users: The Pitfalls of Assumption-Driven Design

Written by Adrian Reed on September 12, 2024. Posted in Articles.

Where I live, every year residents receive two water bills. One is for the fresh (tap) water supply, the other is for wastewater and maintenance of sewers. The wastewater bill is a standard tariff, and I guess most people have automatic monthly payment set up. It’s the kind of thing you “set and forget about”. I mean, it’s hard to get too excited about wastewater, right?

Recently, I’ve been receiving letters from the water company trying to get me to sign up for their online portal (or app) so that I can get my bills electronically. I can almost imagine the initial user story that was written:

“As a user, I want to access my annual statement online, so that I know how much I’ll be charged”

Yet, for me at least, this is an illusion. I really don’t need another app, I really don’t need another portal account and password. For something I receive once a year there is a good chance I will have forgotten my password by the time I need to use it, and if I’m completely honest I look at about 10% of the statement anyway (I glance at the monthly payment amount then file the statement).

These days I’m a digital native, but having to access this information via an online portal would be less convenient for me. I suspect I’m not the only consumer that thinks this…

Digitalization with Purpose

I’m not saying that portals and apps aren’t useful, they absolutely are in the right context. I use online banking apps and portals all the time, and these save me time. However, I wonder how many customers the wastewater company spoke to before building their app/portal. I wonder whether they determined whether customers actually wanted it or not?

Another possibility is that this wasn’t a customer-driven initiative at all. Perhaps the director of customer service was given a target of reducing cost. One way of doing this is to reduce the amount of letters and statements that are printed. Every statement costs money: the paper, printing, envelope, postage cost plus the cost of handling it too.

But when the change is purely driven from an internal cost-saving perspective, with little or zero customer interaction, isn’t it a little disingenuous to write a “user” story from the perspective of the customer? A customer who hasn’t been consulted? There’s the danger we jump straight to a solution, and with no customer interaction this might be a solution that has very low adoption.

Understand the Real Drivers

So, if the driver is cost reduction say so. Rather than jumping straight to a user story or set of requirements, a more useful starting point will be to understand the specific outcomes that are being sought. In this case, it might be:

“A reduction in cost of sending and handling outgoing correspondence of X%”

Then, it’s useful to understand any constraints. There is likely to be a regulatory requirement to issue an annual ‘statement’ (although what a ‘statement’ is may or may not be prescribed in the regulations). With these things in mind, existing practices can be challenged.

Then, having understood why a change is necessary in the first place, we can start to work with the stakeholder team (including customers or customer representatives) to figure out ways that this can be achieved that will ideally benefit them too. Or, at least ways that they can live with.

This might create a very different set of solutions. Perhaps a solution is proposed where a customer receives a small discount for the first year when they opt in to having electronic statements. They’ll receive an SMS text message with the key details (payment amounts, dates) and an email reminding them that the statement information is there if they want it. This is just one option: it’s one that would work well for me, but I am a sample of one. It would be important to get a range of views from different stakeholder groups.

Understand Variety

When thinking about changes like this, it’s also important to consider those who can’t engage with organizations digitally. There can be many reasons for this, so thinking about accessibility not just in terms of “how can we make the digital solution accessible” but also “what are our options for non-digital engagement” is important. Understanding the variety of people, their needs and preferences is important.

In conclusion, whatever final solution is agreed upon, starting by understanding the desired outcomes (and being transparent when the primary goal is cost saving) will lead to a broader conversation. It’s important to avoid rushing towards an early solution in absence of this!

Learning to Love Compliance

Written by Adrian Reed on May 20, 2024. Posted in Articles.

OK, I’m going to let you into a secret here. I genuinely like compliance projects. You know the ones, those projects that people think are really boring because they relate to a change in regulation or legislation? The ones that it’s really hard to get people excited about? The ones that few BAs volunteer for? Yep, those ones!

Framed differently, there’s often a real opportunity to shape and scope things in a way that isn’t always the case with other (seemingly more exciting) projects. These projects can be career-enhancing, provide more autonomy and really don’t have to be boring. Or, at the very least, they don’t have to be as boring as they first appear! Let me explain…

Pain Reliever or Vitamin

I remember reading somewhere that one question that some Silicon Valley venture capitalists will ask startups when they are pitching for funding is:

“Is your product a pain reliever or a vitamin?”

You might think it is better to be a vitamin. Yet, apparently, the answer that investors are looking for is ‘pain killer’. Sure, we might take vitamins some days, but it’s easy to forget. But if you’re in pain, you will soon remember to reach for the pain reliever. So, solving a pain point will likely get people to reach into their wallet.

Think about a change in regulation or legislation. Most people who are part of the core business know they need to comply, but if we’re brutally honest, they probably aren’t that interested. A change in (say) data protection legislation is just a distraction to them. They probably don’t care how it’s solved, as long as it doesn’t disrupt them too much, and as long as it doesn’t cost too much. In fact, they might even be worried that the legal & compliance team are going to be ‘heavy handed’ and create all sorts of bureaucracy for them.

This is an area where BAs can act as a real pain reliever. By working with the relevant business areas and the legal and compliance team, by working with stakeholders to understand enough about the business operations, the solution landscape and the legislation or regulation we can co-create innovative solutions. We can find a balance that works for the different stakeholders, and rather than just achieving compliance, might actually improve things for them too. Imagine that, a compliance project actually leading to improvements! It is totally possible.

Crucially, we take away a distraction for them. We get far more autonomy and leeway to shape things precisely because they just want the pain to go away.

Understanding The Problem

One of the things I love about compliance problems is the fact that business people usually haven’t pre-determined a solution. Other projects often come with an assumed solution attached (e.g. “Oh, we’re going to implement XYZ system, so we need you to write a couple of user stories”, leading to us having to work backwards to understand the problem). Usually the brief is really broad (e.g. “Comply with the new Data Protection Act).

This leaves the BA with a significant amount of autonomy and latitude. There will be many ways of solving that problem, and defining the problem space is usually really fun and makes a huge difference to the success. The biggest challenge is people will often think that the impact is small, when actually it is actually far wider ranging. It’s therefore necessary to bring stakeholders along on the journey.

Although every compliance project is different, I typically find starting by identifying and having an understanding of the legislation or regulation is key. Of course, the BA does not need to be a legal expert, but we need to know enough to ask sensible questions and challenge. In many jurisdictions, legislation is written in (fairly) plain language, and you can even start to imagine some of the business rules/impacts that might be implied by it as you read it.

However, an important next step is to work with the relevant business and compliance stakeholders to determine the company’s interpretation of the legislation or regulation. Rarely are these things completely prescriptive. You’ll find words like “appropriate” and “from time to time” and other phrases that show the intent without prescribing solutions. Particularly with new regulations this can be tricky, as there’s no existing convention or regulator judgements to base things on. Ultimately this is often a balancing act, and an area where good facilitation is key.

Ultimately, all of this leads us to a position where we can judge the impact on existing processes, applications, data and more. This is where the requirements or stories get written, but they will trace neatly back to an interpretation of a piece of the legislation or regulation. In many ways scoping can be easier on regulatory projects… a requirement either maps to a piece of the regulation or it doesn’t! (OK, it’s never quite that binary, but it is close).

Fringe Benefits

There’s still the challenge of selling regulatory projects to stakeholders. If we can’t get them excited about them, then there’s a chance their attention will wane and they won’t give us the input we need.

This is where our pain reliever/vitamin analogy comes in useful again. In fact, a good compliance project can be both. A (hypothetical) project to comply with new data protection legislation might ensure we avoid million dollar fines (pain killer) while also providing us the opportunity to cleanse our existing data, so reports are more accurate (pain killer) and we have more flexibility on how we capture future data (vitamin). This is just an example, but I am sure you get the gist.

So, have I changed your view of compliance projects? Either way, connect with me on LinkedIn and let me know. I’d love to hear your views!

Beyond The Happy Path: One Size Does Not Fit All

Written by Adrian Reed on May 15, 2024. Posted in Articles.

Up until a few years ago, I used to spend a lot of time working ‘on the road’. I’d spend time traveling between different client-sites, and this would inevitably mean spending far too much time in airports. Business travel is one of those things that sounds really glamorous until you do it, but believe me it soon gets really boring.

When you are a regular traveler, you tend to become very familiar with certain airports and you know exactly how to transition through them quickly. If you’re ever at an airport, you can usually spot regular travelers as they tend to know exactly where they are going, and tend to move at pace. This is completely different to the family who are checking in with three kids, who are having to refer to the signs, and might have even initially arrived at the wrong terminal. Quite understandably, they often need a little bit more help.

I used to joke that it would be good to have an entrance especially for regular travelers, as their needs are so different (I certainly wouldn’t be buying anything from the duty free store, not even one of those giant airport Toblerones that seem ubiquitous in Europe, but a family may well do). This wouldn’t be practical in airports, but it does highlight a point that has direct relevance for business and business analysis: sometimes you need two (metaphorical) entrances…

Understanding Different Usage Patterns

When defining a process, journey or set of features for an IT system, it’s common to think about one path or scenario through which users will navigate. This main success scenario or ‘happy path’ is then often supplemented by exceptions and alternative paths which are essentially ‘branches’ from the main scenario.

Yet it is worth considering that different types of stakeholders might have different needs as they navigate through. There might even be benefit in having two entry points. Building on the airport analogy, an experienced traveler probably doesn’t need to be told about the security rules (unless they have changed recently). A new or less frequent traveler may well need to be informed in detail.

This translates to wider contexts too. An experienced user of an IT system probably won’t want lots of dialogue boxes popping up with hints and tips. A new user might need virtual hand-holding as they learn how the application works. Someone who calls a call center once might need to hear that three minute Interactive Voice Response (IVR) message explaining all about the services they can access via phone, and letting them know which number to press. Someone who calls every day as part of their job probably doesn’t need to listen to the whole three minute spiel every time they call… Understanding these usage patterns is key.

One Size Rarely Fits All

There is often a desire to standardize processes, journeys and customer experiences. There is benefit in doing this, but the benefit really surfaces when the different users and stakeholders are understood. Understanding whether users will be casual/occasional or regular is important, as is understanding what they are ultimately trying to achieve.

This relies on elicitation and customer research. This is an area where business analysts can add value by advocating for the customer’s perspective. Too often definition and design decisions are made by people in comfortable conference rooms who are detached from what the experience will actually be like. Sometimes those decisions are made by people who haven’t spoken to a real customer in a decade (or ever!).

In these situations we can ask important but difficult questions such as “what evidence do we have that customers want that?”, “which types of customers does that appeal to most?” or “how do we know this will be a priority for our customers?”. Using a technique such as personas, when coupled with proper insight and research, can make a real difference here.

As in so many cases, asking these questions can sometimes be uncomfortable. But if we don’t ask them, who will?

The Pitfalls Of Efficiency: Process Improvement Is A Balancing Act

Written by Adrian Reed on April 24, 2024. Posted in Articles.

Business analysis work often involves improving processes. This might include simplification of a process, reengineering or automation. When used well, IT can be used to enhance (or even completely rethink) a process. The ideal outcome is to design a process that is quicker, more convenient and more cost-effective than what it replaces.

When aiming for efficiency, it’s important to ask “for whom are we optimizing this process?”. This might sound like an odd question to ask, but often there’s a fine balancing act. A process that appears very efficient for a company might actually be very inefficient and inconvenient for its customers. Standardizing a procurement process might create internal efficiencies for the company involved, but might place additional work on the company’s suppliers.

An Example: “No Reply” Secure Email

I was recently a customer of a company that would send correspondence via secure email. I’d receive a notification via regular email, and I’d then need to log in to the company’s secure email portal to read what they had sent me. This was fine, except the emails they sent were all from a ‘no reply’ address. While the secure email system they had implemented literally had a ‘reply’ button, there was a disclaimer on every email they sent which said “don’t reply, as we won’t read what you send us” (OK, it wasn’t that blunt, but you get the idea!).

This led to the crazy situation where the only way of replying to their secure emails was to either call via phone (and queue for 45 minutes), or put a reply in the mail.

This is an example of a situation where convenience and savings are predominantly biased towards the company, with some minor benefit for the customer. Prior to sending secure email, they would put correspondence in the regular mail. Moving this to an electronic platform presumably saves in printing, postage and stamps. It’s of marginal benefit to customers too, as they receive correspondence quicker (providing they look at their email regularly).

But the real customer benefit would have been to be able to correspond and reply with the company via secure email. Ironically, by implementing the solution the way that they did I suspect their ‘no reply’ mailbox is actually full of replies from customers who didn’t read their disclaimer!

There is no “right”, it’s a balance

As a customer, I found the situation frustrating, but there is no inherent or universal ‘right’ answer here. It might be that the company in question had deliberately chosen not to accept incoming secure email for compliance reasons, or perhaps they feared they’d be flooded with lots of customer inquiries as they are now ‘too easy’ to contact (although I’d argue that if this is the case then there’s probably a bigger root cause they ought to be contending with!).

The point here is that it should be a conscious balancing act. It is all too easy to create a situation that is more efficient for one group of stakeholders, but actually worse for another. An employer who decides to streamline their process for employees who need to claim travel expenses might decide that they can save time if they ask their employees to input more data at the time they submit their claim. If they get the employee to select where the expense was incurred, the amount of sales tax that was included in the expense, the category of cost and so forth, then this saves time later. Yet an employee who isn’t a tax expert might find this frustrating (“Is train travel exempt, or zero-rated for sales tax?”). Of course, in reality this will likely affect the quality of data too, as people try their best (but don’t know which of the different tax code options to choose).

This is a specific example, but it highlights a wider point: it’s important to consider process improvements from the perspectives of the stakeholders impacted. This involves considering what efficiency as well as effectiveness looks like for each key group.

As with so much in business analysis, stakeholder identification, engagement and empathy is key!

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!