Skip to main content

Tag: Tips

Learning to Love Compliance

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.

 

Advertisement

 

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

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.

 

Advertisement

 

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

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!

 

Advertisement

 

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

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.

 

Advertisement

 

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!

50 Most Dangerous Words for Business Analysts

As business analysts, it’s our primary responsibility to bring clarity to requirements communication. Unfortunately, many words spoken by our stakeholders can be ambiguous. Not understanding these words in their proper context or without adequate information can lead to situations where different stakeholders can have a different understanding of the same word.

One of my very favorite words is Manage. Manage can mean anything under the sun to anyone. For example, managing a schedule to me means creating a schedule, viewing schedule, updating schedule, deleting schedule, importing schedule, exporting schedule, reporting on schedule, and alerting schedule delays. For the developer in my team, managing a schedule could simply mean creating a schedule, viewing the schedule, updating the schedule, and deleting the schedule (The four fundamental operations on data).

Discussing the ambiguous terms with stakeholders will give them the idea that something is also missing from their end. They can do some more research to find how exactly they want the system to behave rather than giving information that is at a higher level. In this blog, I am writing down the top 50 ambiguous words I came across as a business analyst. I want all my business analyst friends to contribute to this list so that we can comprehensively list the ambiguous words.

Any time any of our stakeholders use these words, we would know that there is some ambiguity involved. It’s not that the ambiguity is always bad, but it must be clarified before something goes for designing and development. So till the time we are far away from that, it’s ok, but as we come closer to the design and development phase, we must find the real concrete information so that the development team can design the solution as per the stakeholder requirements.

 

Advertisement

 

Rank The word What makes it dangerous
50 Most appropriate Who decides what’s most appropriate?
49 As soon as possible In the next 5 seconds?
48 In future By EoD Tomorrow?
47 ETC Missing details
46 TBD When?
45 Usually Where is the unusual stuff?
44 Generally Non-precise
43 Normally Non-precise
42 To the greatest extent Who decides the extent?
41 Properly Non-precise
40 Where practicable Conditions not specified
39 Supported Passive voice, Actor unknown
38 Handled Passive voice, Actor unknown
37 Processed Passive voice, Actor unknown
36 Rejected Passive voice, Actor unknown
35 Always Assumed certainty which does not exist
34 Never Assumed certainty which does not exist
33 All Assumed certainty which does not exist
32 None Assumed certainty which does not exist
31 Every Assumed certainty which does not exist
30 Earliest Non-precise
29 Latest Non-precise
28 Highest Non-precise
27 Fastest Non-precise
26 Flexible Non-precise
25 Modular Non-precise
24 Efficient Non-precise
23 Adequate Non-precise
22 Minimum required Minimum shall be achieved
21 Minimum acceptable Minimum shall be achieved
20 Better Non-precise
19 Higher Non-precise
18 Faster Non-precise
17 Less Non-precise
16 Slower Non-precise
15 Infrequent Non-precise
14 To the extent specified Non-precise
13 To the extent required Non-precise
12 Very high Non-precise
11 Very low Non-precise
10 Fantastic What is Fantastic?
9 Multiple currencies Which currencies?
8 Multiple languages Which languages?
7 Multiple browsers Which browsers? Even for the same browser, which versions?
6 Robust Non-precise
5 Sturdy Non-precise
4 User-friendly Non-precise
3 Great performance How do you determine that?
2 User All users or specific types of users?
1 Manage Possibly the most dangerous verb – Can mean anything under the sun

What other words would you like to add to the above list?