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

Do You Really Need Permission

I once worked for an organization that had several buildings within walking distance of each other.  There was one building where the organization rented a single floor, and since a project was ending they no longer needed the space so everyone moved out.  I had left some paperwork there, so I went over to retrieve it.  I had expected my pass wouldn’t work and I’d have to get special permission to get in, but I was pleasantly surprised to find my pass still swiped me in.

Continue reading

Avoid “One Size Fits All” Analysis

A commonly used business analysis get-out-clause is the all-encompassing phrase “it depends…”.

Although using this phrase might be seen as an attempt to evade certainty, the reality is often that the world is more complex than people like to admit, and in some contexts there really isn’t one single ‘right’ answer. What is considered ‘right’ will depend very much on who you ask and how the question is framed. This can lead to situations where an approach is followed with absolute conviction and certainty… only to lead to a completely unexpected outcome. Something that seemed so ‘right’ and ‘proven’ wasn’t so ‘right’ after all…

The business analysis toolkit is broad, and we benefit from having access to a whole range of bodies of knowledge where skilled practitioners have captured years of knowledge and experience. With so many different tools, techniques and approaches it’s possible to get into ‘analysis paralysis’—it’s difficult to know which tool or technique to use in a particular situation. This can lead to an understandable desire to search for industry standards and best practices. Perhaps a set of templates are developed, or a particular software tool is used to track user stories because that’s what everyone uses these days.

Of course, there’s nothing inherently wrong with springboarding and learning from the experiences of others. The very fact that we have bodies of knowledge in the first place allows us to do this. However it can be dangerous when one set of practices is copied, without sufficient consideration, from one context to another. It’s even more dangerous when this becomes a mandated standard that nobody is allowed to deviate from.


Advertisement

A Plumber and an Electrician

This point can be illuminated by taking it outside of business analysis. Let’s imagine that a plumber is using a pipe wrench. The wrench is really effective at certain tasks, and somebody notices that it’s an integral part of ‘unblocking pipes’. This fact might be true in a particular context, but switch the environment and it’s a completely inappropriate tool. I’m not sure a wrench alone would be much use unblocking a main city sewer (although I’m fortunate in that I’ve never had to try that). Additionally, a wrench has many other uses that (in this case) haven’t yet been observed or documented: from opening stubborn lids through to dislodging dropped items behind a bookcase. Not only this, there are many other types of wrench that have specific purposes (this site lists 40 types!). Plus a wrench is really only useful if it’s in the hands of someone who actually knows how to use it… and who knows how to find the root causes of the problems they are attempting to resolve.

A similar pattern exists in business analysis and business change more generally. It can be tempting to look at companies that are successfully delivering change and notice they are using particular approaches to business analysis or are utilizing particular techniques. Undoubtedly these approaches contribute towards the success however simply ‘copying’ or ‘transplanting’ approaches from one context and culture to another doesn’t mean that the performance will follow. They have likely refined their approaches over years, piecing together different practices and building on experience. Hitting the ‘copy and paste’ button is like giving a wrench to an electrician and saying “hey, the plumber over there had great success with this, so surely you can make use of it? We reckon it should cut the time it takes you to do each job by at least 50%”. Equally, it can be easy to overlook (or even dissuade or disapprove) of practitioners who are successfully using techniques in ways that aren’t considered ‘standard’ or ‘usual’. So what if somebody is using use cases rather than the ‘expected’ technique? If it is working, if people understand them, and if it is having the desired effect, surely that’s what matters.

In fact, some organizations go further and mandate certain approaches or create rigid templates. Templates absolutely have their place—they can help avoid the need to ‘reinvent the wheel’ on every engagement—but they need to be extensible and customizable. If they are mandatory, situations occur when sections are filled in simply because the sections exist. This is like giving a wrench to an electrician and saying “Oh, and by the way, this is the new company standard…. So you absolutely must use the wrench on every job”. Which, let’s face it, sounds crazy.

Professional Judgement

Business analysis is a profession that relies on our ability to analyze things, including the approaches that are relevant. There are a whole set of approaches, patterns, tools and techniques, so rarely will we have to start from a completely blank sheet. Yet as practitioners it is our job to choose the right tools for the context. It’s important that we have an understanding of a wide range of tools, and that we know where to go to find information about others (it’s virtually impossible to be an expert on all of them). There’s no ‘one-sized-fits-all’ approach to business analysis, and one of the skills that we bring to the party is the ability to advise and help choose. I believe this is one of the most interesting parts of the role!

Don’t Give Up “Thinking Space”

One of the perennial challenges of corporate life seems to be that everything is perceived as “urgent”.

People spend their lives bouncing from one virtual meeting to the next, desperately trying to complete their actions by deadlines that seemed reasonable at the time (but seem almost impossible in retrospect!). The move to virtual working has perhaps exacerbated this for some–when working in an office it physically takes time to move between meeting rooms so even when a diary is filled “back to back” there is some time to move and think…

As practitioners of organizational change, we are usually aiming to maximize the value that is realized by our organizations and customers. This means focusing on delivering the most valuable things first, and “time” seems to be a significant focus on many projects and product development initiatives.  Yet delivering the “wrong” thing faster is unlikely to win many supporters. I suspect we’ve all seen situations where things were more complicated than initially seemed to be the case, but pressure is still applied to deliver to the original deadline…

Reflection Time

One fairly basic planning tenant is that elapsed time is a different thing to effort. This sounds almost trivial and obvious, doesn’t it? I mean obviously a day’s work can take much longer if the people who need to contribute aren’t available.  Yet, so often planning seems to be optimistically conducted assuming people are available, no unexpected information surfaces and decisions can be made instantly. Perhaps you’ve also fallen into this trap? “We’ll have the workshop on Tuesday so the decision will be made on Tuesday”. This sounds logical and might sometimes be the case, but equally we might find somebody discovers some additional information that requires thought and investigation before an informed decision can be made. If the deadline is still Tuesday then we have a dilemma.


Advertisement

Deadlines like this create pressure and they can reduce the ability or willingness to consider constructive dissent and additional unexpected information. If a facilitator says “we must agree today, and if we don’t it’ll be escalated to the board”, this is hardly creating conditions for a fair and balanced discussion. People with doubts might choose to refrain from expressing them. Who wants to be the reason that a deadline is missed… particularly if it’s a concern where there isn’t 100% certainly? Yet that very concern might have been the one that uncovered a major misconception and nudged the project onto a better track.

Of course, there needs to be a balance and we need to avoid “analysis paralysis”. Yet we also need to avoid steamrollering decisions through. An important contributing factor is to build in time for reflection.  This involves deliberately building space for people to think, consider and for ideas to incubate.

This is probably something we all do intuitively, but it’s worth bringing it to the fore and considering it consciously. It might involve, for example, holding 1 on 1 interviews with stakeholders on Monday, then a workshop to synthesize their views on Thursday, sending them the output on Friday and reconvening for a quick check the following Wednesday.  Rather than building an expectation of “back to back” engagement and sprinting from interview to workshop to validation session, we create space for creativity and for more information to emerge. It’ll also likely be easier to schedule as few stakeholders have lots of consecutive free time in their diaries. After the initial interviews people might have “Eureka” moments and send additional information by email that we wouldn’t have seen if the timetable had been tighter.

This also highlights an important part of analysis work: analysis requires collaboration and relies on thinking. It isn’t purely mechanistic work that can be easily sequenced. In a factory, if someone can produce 50 widgets in an hour, then all things being equal they can probably produce 100 widgets in two hours.  The same isn’t true for analysis; an eight hour day filled with eight back to back stakeholder interviews would likely lead to information getting lost (no time to write up notes) and a missed opportunity for connecting the dots between information provided. We don’t work in an “analysis factory”.

As with anything in analysis, there will be times when we need to adapt to the context. There will always be times when something urgent and unexpected happens and we need to mobilize quickly and we have less time that we’d like. However, even in those situations we ought to avoid situations where there’s no time for thinking and creative reflection.  At the very least, when a deadline is presented, questions including “how was this deadline arrived at” and “what are the consequences if it is not met” ought to be asked. It may well be that a few days delay now, in return for a better product and more benefits later might be deemed not only acceptable but desirable!

Don’t Forget The “Why”: What A Fax Machine Taught Me About Process Improvement.

Recently, for the first time in years, I had to fax a multi-page document through to a company I was dealing with.

Of course, I don’t own a fax machine as it’s not 1995 anymore, but I do still have a USB fax modem which just about did the job.  As I listened to the computer dial and heard the old familiar beep and screech of the fax being sent it brought back memories of a time when faxes were common.

As I waited the 20 minutes (yes, really) for the thirty three page document to send, I couldn’t help but consider the ludicrousness of the situation.  It is 2021, we have the Internet, we can video-call anyone in the world, yet the only way I could get documents to this particular company was via fax (or by regular post/mail).  The issue was of security: They didn’t have any other secure means of me getting the information to them.

As I was watching the progress bar slowly move as page after page slowly got sent, it made me think about how processes are defined in organizations, and specifically how handovers work.  In many situations it is information that needs to flow between actors, or put differently, one person (or IT system) provides information to another so that a decision can be made or some work can be undertaken.  In this example, I needed to securely get some information into a process, as a customer, from outside the organization.

Think Beyond Format & Channel: Focus on Why

When looking to improve existing processes, it’s very easy to get caught up in thinking too much about the format of the information and focus on improving the channel of communication, instead of asking the fundamental question “why is this information required, and what is the recipient going to do with it?”.

Let’s take my fax example: I was faxing a series of receipts and pieces of correspondence to my credit card company as a supplier did not deliver the service they promised, and had delayed issuing a refund.  Imagine we were redesigning this process, with a view to making it more effective and efficient. We might ask: how else could that documentation get to us? We might suggest that the scanned evidence is uploaded to a portal, or perhaps we might center upon an encrypted e-mail solution.  Yet doing so would be focusing on a solution too soon…


Advertisement

Let’s imagine instead we ask the recipient why they want the information. Perhaps, for example, they say that they need to:

  1. Validate details of the items or services purchased
  2. Establish that the cardholder has contacted the merchant to request a refund which hasn’t materialized

A logical next question would be “what do you do with the information once it’s received?” and “why do you do that?” We might find out that they:

#

What

Why

1

Attach it to a case management system

In case it’s necessary to refer to the documentation in future

2

Read the detail from the scans, and manually key relevant pieces of information against the record (e.g. nature of product/service, price, merchant details)

To ensure the record is up to date. It is this record that will assist with the final decision making.

3

Find the merchant, contact them to validate that the information is correct (as receipts can easily be forged)

To establish the merchant’s versions of events so that a decision can be made. Often information from customers will be incomplete.

4

Ask the merchant why they are refusing to refund the customer

As above

5

Make a decision and either refund the customer or not (and claw back funds from the merchant as appropriate)

To ensure that customers are refunded when they are entitled/when it is fair to do so.

In this example there is work being created simply because a historical assumption has been made over the format of the information.  It’s been assumed that it must be ‘documentary evidence’, PDF copies of scanned receipts and so forth.  Yet (in this hypothetical example) the minute that information comes in, it is rekeyed and checked with the merchant anyway as the documentation itself isn’t trusted.

Ask The Provocative Questions

This is where we can really earn our money as analysts.  We might ask the provocative but illuminating question “if we don’t trust the documents, why ask for them at all?”.  If we’re going to check the details with the merchant in 100% of cases, why not just ask for a smaller subset of information, e.g. transaction date, time and a brief description of the issue.  Perhaps this could be quickly vetted and then automatically directed to the merchant so that they can add their version of events.  Supplementary information could be asked for when needed.  Rather than asking for “everything we might conceivably need” up front, the process changes to “let’s make everyone’s life easier, ask for the minimum amount, and streamline things as much as we can”.  A risk based approach could be taken, a single five dollar refund from a customer who has never requested a refund before is probably going to be treated differently from a ten thousand dollar refund.

Of course, this is just one example, and it’s probably a while since you last saw a fax machine.  Yet I’m sure you’ve seen similar patterns on the processes you are working with, where old constraints have become ‘baked in’. It’s our job to question them!

If this topic is of interest to you, you may also be interested in seeing the ‘Brown Cow Model’ by James & Suzanne Robertson, which I am certain indirectly inspired this post!