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

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!

Editing for Success: Applying Hollywood Wisdom to Projects

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

I’ve long been a believer that a good movie is 90 – 120 minutes long. Sure, there’s the occasional storyline that can keep my attention for longer than that, but generally speaking after a couple of hours I’m getting pretty restless. One of the reasons I rarely go to the movie theater these days is that films seem to be getting longer and longer, and unlike watching at home I can’t press ‘pause’ in the theater!

It turns out that I’m not alone. Celebrated film director Sir Ridley Scott, who directed films including Alien, Gladiator and Blade Runner recently spoke about the ‘bum ache’ (‘butt ache’) factor of films. Too long sitting down and apparently movie-goers will get uncomfortable, and this is something that he takes account of in his editing. A classic case of “less is more”, and a director being empathetic to his audience.

Less Is More

I know virtually nothing about movie production, but I’m guessing that it is probably technically easier to produce and distribute a long film than it was, say, 40 years ago. I gather that in the past films came on multiple spools, all of which had to be physically duplicated and distributed. Apparently since the early 2000s, films have been distributed digitally to theaters. With fewer constraints, you could have a ten hour film if you really wanted it.

Yet being unconstrained isn’t a good thing. I’m guessing few people are lining up to watch the ten hour film “Paint Drying” (which is a real film, but was a protest against the cost of censorship). The fact that it’s possible to do something because a constraint is removed doesn’t mean that it’s actually a good thing to do. Sometimes constraints can foster creativity.

From Hollywood To Projects: Time As A Constraint

I’m guessing that you probably don’t work on Hollywood movies, but there’s a direct parallel with projects here. After all, a Hollywood movie brings together a collection of specialists for a period of time to create a deliverable that will generate benefits for its sponsor… which sounds strongly analogous to a project!

One constraint that you and I probably come up against frequently is time. There never seems to be enough, and time is always the thing being squeezed. It is easy to become somewhat jaded to this, and either just accept the deadline (but implicitly know that it’ll never be met) or rally against it.

Certainly, calling out unrealistic deadlines is an important thing to do. Yet, in some circumstances an alternative approach is to test the constraint and see how it balances against others.

Let’s imagine that a sponsor has set a deadline of 1st January for the launch of a product or project deliverable. We feel there’s a risk that this is an arbitrary deadline, so we start to tactfully ask “if it was two weeks later, but 10% cheaper, would that be beneficial?”. If the sponsor says “Absolutely, yes!” then we know that they probably value the budget over a fixed deadline. Or we might ask “How about we delivered it on that date, but the quality was lower?”. They might answer “No! Absolutely not”, at which point we know quality is paramount. We might ask these types of questions about all sorts of things, including scope, timeframe, deliverables, style of delivery and so on.

What we’re doing here is understanding which are hard constraints that genuinely can’t change (or, there would be a significantly negative impact of breaching) and those that can potentially bend. Not achieving regulatory compliance by a mandated date, where the regulator is strict and there’s a significant fine, might be an example of a hard deadline. It’s better to pay more now, and dedicate more resources to ensure compliance. Other things which appear to be constraints might be more malleable.

Product Management and Business Analysis as Film Editing

Once the hard constraints are identified, it’s tempting to be deflated. Rarely are we dealing with a situation where there’s too much time, resources and budget. Yet another way of looking at this is to think about the movie theater experience… sometimes less is more. Much as an ambitious scriptwriter might have a scene cut because it’s not essential to the story (or the location is too expensive to hire), we can ‘edit’ elements of a project or product in or out.

This probably sounds obvious, I mean scoping and prioritization is crucial. Yet, too often scoping and prioritization are carried out somewhat in isolation. It’s easy to end up with an incoherent set of features, or (worse) to find that only the person who shouts the loudest gets what they want…

If we reframe this as a process of ‘editing’, then we are keeping in mind the coherence and desirability of the product as a whole. Imagine asking twenty people for their favorite ever scenes in movies. Perhaps one mentions a scene from Wargames, another from the Barbie movie, another from Love Actually and so on. Now imagine making a film out of these ‘best’ scenes… it wouldn’t make any sense. The same can be true of a product too. If the features aren’t coherent it can become somewhat of a Frankenstein’s monster that is difficult to use and doesn’t really serve any single purpose well.

Another thing about editing is that it involves compromises and making difficult decisions. I’d guess actors probably hate having their biggest scene cut. And script writers probably hate being told they can’t have that on-location scene in Barbados due to budgetary cuts. But, it is the editing that means that the film makes money (achieves its financial outcomes) while also providing an experience that the consumer wants (achieving another of its core purposes).

I suspect this is a balance that we all tread on our projects and products, and bringing it to the fore and making tradeoffs transparently and purposefully can only be a good thing!