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

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!

Unveiling the Unsaid: The Power of Subtle Stakeholder Cues

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

When eliciting information from stakeholders, often what isn’t said can be as significant as what is said. Of course, the information that a stakeholder explicitly mentions is of crucial importance, but often there are subtle and nuanced details that aren’t obvious unless you look for them. Perhaps a stakeholder subtly pauses and looks uncomfortable and avoids answering a specific part of a question. Or perhaps they use a qualifying word like “usually” or “sometimes”. Either way, it is crucial to probe further and find out more.

Hearing What You Expect To Hear

Looking out for these clues is important, but is easier said than done, particularly when time is tight. When there are a number of stakeholders to speak to, it is easy to get drawn into a pattern of hearing what you expect to hear. We’ve probably all experienced this: after three people from different departments outline a process consistently, speaking to the fourth and fifth person seems like ticking a box. After all, they are going to just confirm what the first three people have described, surely?

That might be the case, but equally they might have additional insights that the original three did not. There is presumably a reason that they have been selected to participate in the elicitation activities, perhaps because they have a different perspective on things. Yet, it would be easy to let those discussions be swayed by the conversations that have happened before. To almost go on ‘autopilot’ and lead the stakeholder in a particular direction. It is worth being especially aware of those subtle cues and nuances in situations like this.

An Example

Imagine interviewing a stakeholder in a finance team about the invoice payment process. You’ve spoken to other stakeholders previously and you’re pretty sure you know the process:

“So, you get an invoice in, and as long as there’s a purchase order number on there, and as long as it’s approved, it gets scheduled for payment, is that right?”

“So, yes, mainly…. Yeah, mostly that’s it.”

It’d be easy to move on from this. It would be easy to assume that they are confirming some of the key decision rules (if an invoice has a purchase order number and has been approved, it gets scheduled). But the stakeholder has added qualifying words: mainly and mostly. These are easy to miss, but definitely require probing.

Probing might go like this:

“I noticed you said that this is mainly how the process works, are there other circumstances?”

“Yes, only very occasionally though. Sometimes, we get ‘proforma’ invoices that have to be paid immediately. We have a different process for those. Also, there are some cases where we pay up front by credit card. For example, booking training and conference places. That has a slightly different process too.”

Suddenly, a whole new set of facts becomes available. If this were a real situation, this would lead to further probing (e.g. “Are there any other times when the process operates differently?”, “Is there just one corporate credit card, and if so who is responsible for it” etc, etc).

Make Sure They Feel Heard

Of course, probing this way is important to ensure that nothing crucial is missed. However, genuinely listening is important for another reason too: to ensure that people actually feel heard.

If you’ve ever had the experience of speaking to someone who appears to be preoccupied, and is perhaps presuming what your responses are, you’ll know that this rarely feels great. As analysts, it’s important that we empathize with and genuinely hear what people are saying.

Listening in this way will help uncover important information. It is a crucial and often taken for granted skill, but one that we can probably all hone and improve upon!

Strings Attached: The Art of Adapting Templates in Business Analysis

Written by Adrian Reed on March 13, 2024. Posted in Articles.

I’ve recently started learning to play the ukulele. I made a decision early on that I’m not interested in learning ‘properly’, I don’t want to commit to formal lessons, I just want to try a fun new hobby. For that reason, the (very little) I’ve learned has been learned largely from YouTube.

When I say I’m not learning ‘properly’, I’m really just learning chords and tabs, I’m not reading sheet music and I’m pretty much just strumming along to the YouTube videos. That is perfectly fine for what I am aiming for, I never want to be a professional, I just want to play some simplified versions of songs I know.

In the dim and distant past I took piano lessons. Back then I could read sheet music (in treble and bass clef), knew about timing and some of the theory behind music. That knowledge has all gone now, and I have no idea how to play a piece of sheet music on the ukulele!

Now, you probably didn’t come here to read about ukulele playing, but there is relevance here, I promise! It’s all down to application within a context.

From Ukuleles To BA Templates

One of the things that I see a lot on social media is people asking for (and providing) BA templates. There’s a huge draw in using a template, it means that you don’t have to start from scratch. Things like templates and checklists can be very useful to make sure there’s consistency, and to make sure things don’t get forgotten. (I have a travel checklist for that very reason.)

Yet a template without an understanding of the underlying theory and rationale can be dangerous. It can lead to slavish adoption (“well, I need to put this diagram in, because there’s a section for it… the template is ‘best practice’ after all”). Just like my ukulele playing will always be restricted by my lack of music theory, someone who picks up a template without understanding why the template was created that way and what techniques can potentially accompany it will likely run into issues.

An Example: “BRD for the Financial Services Industry”

Let’s take an entirely fictional example and imagine that somebody produces a Business Requirements Document for the Financial Services Industry. It is pitched as a document that will likely be used in a waterfall or incremental delivery environment, and includes a context diagram, use case diagram, scenarios, functional requirements, non-functional requirements and so on.

It’s hard to criticize any of those sections, there will be times when all of those are useful. But what if the person picking it up doesn’t know what a context diagram is? Even if they do, the whole act of eliciting information to construct a context diagram is an artform in itself.

Or, what about if you’re making a tiny change to the label on a single field? Are you really going to fill in all of those sections? You might, in some circumstances, but in all probability something more lightweight would be appropriate. In fact, a prototype alone might suffice…

Of course, this is a deliberately provocative example, but I’m sure you see the point. There really is no ‘one size fits all’ in business analysis. So much is down to context, and understanding the context is key.

However: Templates Can Be Useful

It is worth clarifying here that I am absolutely not arguing against templates, nor am I arguing against the appropriate sharing of templates on social media. They are extremely useful, when used appropriately by skilled practitioners. They can even act as a guide to less-experienced practitioners providing this is accompanied by a desire to learn the underlying theory and techniques.

However, templates are also most useful when they are flexible. What works in one situation won’t work in all, so cut a section, or add a section! It’s important to think about the purpose of the artifact, its consumers and how persistent it is (i.e. how long it is expected to remain current for).

Like so much in change, pragmatic and intelligent application is what matters.

Connecting the Dots: The Crucial Role of Synthesis

Written by Adrian Reed on February 28, 2024. Posted in Articles.

A few years ago, I was working in a fast-paced environment where we very quickly needed to achieve a shared understanding of a particular problem that existed, and then elicit and analyze requirements for improving things.

I’d spent a couple of days speaking to some of the key people, largely in back-to-back meetings, and I was working really late in the office, energized by the conversations I’d been having. I’d managed to find an empty meeting room where I could spread my notes over a large table to think things through. Over the past couple of days I’d had countless conversations, been given documents to read, been shown IT systems, processes and more… It was a lot to take in! Plus of course not everyone necessarily agreed on the nature of the problem, or even what a desirable solution would look like. So my thoughts went to “what next… how do I arrange and make sense of all of this ‘stuff’?”

Luckily, the meeting room had a whiteboard. I instinctively started drawing the ‘problem’ that had been described to me. I drew people, IT systems, data and information flow, customer interactions, bottlenecks, problems. It was a messy drawing that wasn’t intended for anyone but me. If you’re familiar with the idea of a rich picture, it was very much like that. Crucially, it helped me make connections between pieces of information that different stakeholders had told me. This act of synthesis—bringing things together—helped gain a more holistic picture of what was going on.

I was midway through pondering whether two concepts were related to each other, when a very senior stakeholder walked through the door. He asked what I was drawing, and I talked him through my messy diagram. He started instinctively adding things to it, not only adding his perspective to the mix but also highlighting things I’d missed (or misunderstood). Even though this happened years ago, I can still remember parts of the diagram now….

Analysis Needs Synthesis

Of course, that drawing on a whiteboard was really just an interim work product. It wasn’t a deliverable, and although I recorded it by taking a photo, it wasn’t ever intended to form part of any user stories or requirements documentation. It was really just an exploration of the problem domain and the connections within it. It helped me to get my own head around the situation, so that I could ask better questions and know which areas to examine further. It also helped me to understand which areas and perspectives I was missing.

This highlights the importance of synthesis as well as analysis. Synthesis is described by the Merriam-Webster online dictionary as:

“…the composition or combination of parts or elements so as to form a whole…”

There are of course other definitions too, but this sentence is particularly useful for us as BAs. It’s very easy to think that our job is elicitation and analysis, capturing different viewpoints and pieces of information about a situation. Yet without synthesis, those different pieces of information are of limited use! There will likely be contradiction, conflict, different views and more. We all instinctively know this, but it is worth highlighting how important synthesis is in what we do.

Synthesis Techniques

Ironically, many of the techniques that we use on a day-to-day basis have synthesis, as well as analysis, built at their core. I have already mentioned a rich picture, but many other techniques (when used with synthesis in mind) can help in bringing together different pieces of information and viewpoints. Here are just a few examples:

Concept model and glossary: Bringing together (and reconciling) different terms, and the connections between terms
Process model: Creating a view on how the work should take place, taking into account a number of stakeholder’s viewpoints
Prototype: Bringing together and testing assumptions made, or a set of requirements assembled from varying stakeholders,.
Multiple Cause Diagram: After conducting ‘5 whys’ with different stakeholders, creating a combined diagram and presenting it back and saying “what else?” and “what’s wrong here?”
Workshops: Bringing people together to synthesis and discuss their views
… and many more besides

The Importance and Relevance

To do our jobs well as BAs, we need to consider synthesis as well as analysis, and this means making time for it. In my opening example, I mentioned I was working late in the office, drawing on a whiteboard. I was working late that night mainly because I was energized and excited about the project but also because time was so short and I’d focussed on planning the elicitation but less so the synthesis of the information I’d gleaned.

When you’ve conducted a whole number of interviews, read documents, seen processes and systems as they are operated, there are so many sources of information. It’s easy to just jump on to the next elicitation activity, or jump straight to writing a problem statement (or user story) or whatever. Yet, doing so robs us of the opportunity to see the bigger picture.

Building in time for synthesis—the sort that allows us to see connections—will help ensure we don’t implement a change in one area that inadvertently makes things much worse elsewhere. Of course, time is always tight… but if we don’t make time for synthesis, we might end up having to make time for rework. And that’s definitely best avoided!

Prints, Processes, and Pitfalls: More Than Just Process Design!

Written by Adrian Reed on February 14, 2024. Posted in Articles.

I was recently planning the logistics of an upcoming client workshop. I needed 12 copies of a document printed and spiral bound, and I visited the website of a printing company that we’ve used many times before for such tasks. The website had changed, and unfortunately I couldn’t complete the order. For some reason the website was saying it couldn’t deliver to my address.

I’m pretty sure I know why this is. I live in Portsmouth, on the South Coast of the UK, and to the uninitiated, some Portsmouth postal codes look similar to postal codes used on the Isle of Wight. I suspect some courier firms don’t deliver to the Isle of Wight (or charge extra as it’s an island with no roads connecting it to the mainland). This leads to some online sites (incorrectly) lumping some or all of the post codes together and tag them as an ‘exception’. This is really, really, bad design, but it definitely happens.

I was trying to place the order on a weekend, so I waited until Monday and went to contact the company by phone. I tried to phone shortly after 9, and then again at 9.30, and then again at 9.45. No reply. So, even though I’d used this company many times in the past, I just moved on to another supplier. And in fact, I’ll probably use this new supplier in the future, too. So the original printing supplier has lost a customer and it doesn’t even know that. Plus, it missed the opportunity to get feedback about the defect on their website… I wonder how many other cities/postal codes are affected? How many other sales are being routinely lost?

Considering The Customer’s Pivotal Moments In Process Design

As a business analyst, this experience made me think about process and operational design. While the example above was an example of bad design, it is impossible to design an IT system, interface or process that truly caters for every situation, nor (in most situations) would you usually want to. Sure, some call centers might have a process which defines the detailed steps to take if the President of the United States calls from a satellite phone while onboard Air Force One and asks for a message to be passed urgently to the CEO… but not many!

The point here is that there will be certain types of situations that are:

Predictable, but very unlikely and/or uniquely complicated
Difficult (or impossible) to predict, with unknown levels of likelihood or complexity
Unintended, where with the best will in the world (and lots of testing) still something unexpected has happened which has led to an unintended consequence

The first set (predictable) are deliberately not fully catered for by a process as they are either so unlikely that spending time specifying them is overkill, or they are so uniquely complicated that anything beyond broad guidelines can’t be issued. I’d imagine that large companies have a “respond to media request” process which ensures that any inquiry from a TV station or newspaper gets to the right person. The broad process will be structured, and the response will likely be logged in a consistent way. However, how the response is formulated is probably somewhat variable, and more likely subject to guidelines and principles than a strict process. Responding to a request for a photo of the CEO to accompany a “top 10 CEOs” article is likely to be somewhat different to responding to notification that a documentary will be airing showing evidence of corruption within the company!

The second set of (difficult or impossible to predict) conditions can’t be catered for as they are unknown, or the effort of trying to predict them is so great that it is prohibitive. The final set (unintended consequences) are, by their nature, unpredicted! The key here is to find them when they occur and rectify not just the individual case, but the root causes. Taking my printing example, had I got through to the first printing company, I suspect they’d have quoted me via phone and manually processed the order. Great—except the website is still faulty and swathes of other customers might be affected. Understanding what needs to change to prevent the issue happening again is key.

So, what aspects can be considered when designing customer journeys, IT systems and/or processes to cater for these types of situations?

Flexibility, Feedback and Responsiveness are Key Factors

Assuming an organization wants to handle these types of cases, it’s key to design processes with feedback mechanisms built in. Feedback should of course include opportunities for customer or user feedback, but it can also include feedback generated by the process itself.

Take the printing company example I mentioned earlier. As a nationwide printing firm, they are almost certainly finding that there’s been a minor drop in Sales (Portsmouth is a relatively big city, but probably not big enough that the drop in printing sales would ring any warning bells) and the distribution of where they are sending parcels has changed. A curious analyst diving into the data might say “hmmm, it’s odd, there are entire cities where we are no longer sending parcels… maybe we should look into that”. Making sure diagnostic data is captured and examined is important, and this is so much more than just performance data.

It’s also important to ensure there’s a viable support option and, yes, this does usually mean ensuring someone can speak to (or communicate somehow with) a human being when they need to! That support person or team needs to have sufficient autonomy and be empowered to raise issues for investigation. A team that just “raises tickets” and passes them on to others is unlikely to cut it.

Finally, it’s important to note that processes will need to change and this should be expected. Building in responsiveness to the environment is important. Expectations will change, the way people communicate will change and so forth. By designing processes with this in mind, and ensuring they are owned, reviewed and adapted when needed, is a small but important step towards agility. As BAs, we can often nudge towards this way of thinking, and every step in the right direction is a good thing!