Skip to main content

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

Back To Basics: Excellent Elicitation

Elicitation is a core business analysis skill, and one that BAs typically utilize daily. It is easy to fall into the trap of thinking that elicitation is so basic that it doesn’t warrant talking about. Yet, just because it is a core skill doesn’t mean it’s easy, and it certainly doesn’t mean it’s unimportant. Not only this, but elicitation usually involves working with stakeholders, and whenever people are involved there can be inadvertent conflict and contradiction.  Achieving  clarity is rarely easy!  In this article, I’ll address three perspectives of elicitation that you might find useful.

 

Elicitation As A “Trawling” Activity

In their book Mastering the Requirements Process, James and Suzanne Robertson use the metaphor of trawling to describe elicitation. The idea is, much like a fishing boat with a net trawls for fish, an analyst ‘trawls’ a business area for relevant pieces of information.

 

Ever since I first heard this metaphor I’ve liked it. Building on the Robertsons’ work and extending the metaphor, we might also say:

 

  • Where you trawl matters: If you trawl in an area with no fish, you’ll end up with an empty net. The same is true of requirements—ask the ‘wrong’ people and you’ll get very little.
  • The type of net matters: I’d imagine that the type and size of fish you are trying to catch will affect the type of net used. There’s a comparison here with elicitation—the techniques need to vary depending on the context and the types of requirements that you’re looking for. Detailed observation might yield very in-depth requirements, so might be considered a ‘small net’. A high-level conversation with an executive might yield high level outcomes and be considered a ‘big net’. Both are important, but it’s important to know which you are looking for.
  • There will always be stuff to throw back: Sometimes, it’s tempting to plan elicitation activity in a straightforward, linear way. As if you’ll be able to speak to person A, person B, do some observation and then everything is done. Of course, it never works exactly like that, as people will throw in curve-balls, there’ll be discussions which take you in unknown directions and so forth. I suppose this is a bit like trawling for fish: there will always be some fish to throw back if they are too small, too big, or the wrong type. In requirements terms, this shows that elicitation and analysis go hand in hand. As soon as elicitation starts, there will be filtering and prioritization happening.
  • Ethics should be built in to the process: I gather that fishing boats may throw back fish that are endangered, or are below a certain size. In terms of requirements, there is perhaps a lesson for us as analysts: If we come across a requirement that we believe is unethical, we should question it.  This might sound like an odd thing to say, after all, who would raise an unethical requirement? Yet, with proposed technological transformation there might be an underrepresented group that is disproportionately affected, and perhaps this hadn’t been considered. It might be that the requirement owner had never considered the ethical consequences, and is very happy to amend or remove it once they think about the broader unintended consequences.

 

Advertisement

 

Elicitation Relies On Stakeholder Analysis

Much as elicitation and analysis are inextricably connected, there is a clear dependency on stakeholder analysis. Sometimes we might be led to believe that stakeholder analysis is a frivolous activity, after all, who has time to sit down and create stakeholder lists and models?  Yet, the reality is that it’s one of those activities that will likely save time in the future.

 

I can still vividly remember a time, very early in my business analysis career, when I was assured that a particular project I was working on didn’t require compliance sign-off. I took this at face value, didn’t do any further stakeholder analysis and went ahead. Cutting a long story short, we got to testing and found that we absolutely did need compliance sign off. That was a scary revelation, but luckily our compliance colleagues were friendly and pragmatic. With some late nights and minor changes we got the project over the line. But for me, it was a lesson learned: Proper stakeholder analysis could have avoided it entirely.

 

I’m a particular fan of the stakeholder rainbow, and the stakeholder interest intensity index. I discussed a number of stakeholder techniques in a presentation that’s available on YouTube, feel free to check that out if you’d like to know more!

 

Context And Scope Matter

Finally, it’s worth noting that elicitation which doesn’t consider context and scope is really just a Santa’s wishlist. Imagine asking everyone in an organization “what is it you want?” or “what could save you time?”. You’ll get lots of ideas, many of them actionable, but you won’t get a coherent set of ideas.

 

This probably sounds so obvious, but it’s an easy trap to fall into. As analysts, it’s easy to be so familiar with the scope and context of a project that we assume everyone knows it. Yet that’s rarely the case, so spending a few moments to outline the core objectives and outcomes can really help.

 

This also highlights another key point: It’s absolutely crucial to understand the business objectives and outcomes being sought. Trying to elicit and prioritize without knowing the outcomes is virtually impossible. How can anyone say requirement A is in scope (or not), and whether it’s more important than requirement B if there’s no clear agreement over the ultimate outcomes being sought?

 

Conclusion: Shine The Light On Elicitation

It’s easy, particularly as an experienced practitioner, to let elicitation become second nature. That is completely natural. But perhaps it is worth spending time now and again reflecting on how we elicit and whether it is still effective. Although it might not be a headline-grabbing topic, elicitation is absolutely crucial to what we all do!

Do You Consider “Opportunity Cost” In Your Analysis?

I’m a fan of live music, and I particularly enjoy music festivals. If you’ve never been to a music festival, you’re missing out. They usually involve multiple days of listening to music, dancing and having fun. There’s often multiple stages so one challenge is deciding which bands to listen to.

I was reminded of this fact last summer when I bumped into a friend of mine (who is also a BA) at a music festival. It turned out that we’d both created (and printed) spreadsheets showing who was playing when at what time. My spreadsheet even used color coding with green being bands we planned to see, and yellow being ‘backups’ (in case the first choice was too full, or there was some other reason we couldn’t get there).  Well, everyone loves a spreadsheet, don’t they?

 

Comparison and Opportunity Cost

Spreadsheets aside, this illustrates a point that is important in projects and product development initiatives too. Typically every action or decision has an opportunity cost associated with it. Taking one course of action means that it isn’t possible to pursue others (as time and budget is focused on the course of action that’s been chosen).

At a music festival, the opportunity cost is fairly easy to calculate. If I see Band A on the main stage at 8pm, I can’t see Band B on another stage at the same time.  I also can’t go to the bar (probably for the best), nor can I grab an overpriced hotdog. The act of deciding on an action means that other options are no longer open to me.

 

The same is true when it comes to deciding which projects to progress, which features to focus on, or which requirements to prioritize.  When writing an options paper, it’s usual to consider the impact of ‘doing nothing’, but in some cases it may be worth extending the thinking even further and considering what else could be done with the time and money.

When prioritizing requirements, there are always trade-offs. It’s desirable to deliver the features first that will enable the most benefit to be realized. This is certainly true, and this is something that I’m sure we all aspire to… but in reality aren’t things often a bit more complicated than that? There’s often resource contention (multiple development and testing teams, often with limited resources), organizational level challenges (code freezes, budget changes) and a whole load of other opportunities and threats outside of the immediate orbit of the project.

 

Sometimes It Makes Sense To Do The Second Best Thing

There might be cases when it actually makes sense to do the second most beneficial thing. Imagine there’s a high priority set of requirements. Everyone agrees those will yield the most benefit. However, the technical experts that need to work on them are also needed to work on some essential maintenance. Although systems maintenance and the art of ‘keeping the lights on’ is never as glamorous as delivering new features, it’s still super important.

Within the project, the logical decision is to go for the highest priority requirements. But, there’s an opportunity cost for the organization. If that action is taken, the maintenance is delayed. That might be a very bad idea, depending on the nature of the maintenance.

The key point here is that progressing the second best thing for the project might actually be the best thing for the organization overall.

 

Advertisement

 

Know Which Decision Options Are “Perishable”

Some options available to us “perish” if they aren’t taken. If you’re at an airport and delay deciding whether to get on the plane for too long, your option to board that plane will eventually disappear (as it’ll have taken off without you). The same is true at a music festival, if Band A clashes with Band B, then you have a straight choice to make. Choosing Band A means you don’t see Band B at that festival.

These are different from prioritization decisions where you can do both things sequentially. Delaying requirement A so the team can do some urgent maintenance probably doesn’t mean that requirement A will never be delivered… it’ll just be delayed. There will be an impact on the timing of benefits realization, but it’s not a binary “yes or no” decision. It’s important these types of prioritization decisions are separated from those where there really is one chance, and one chance only.

 

BAs as Facilitators of Decision Making

All of this leads to an interesting conclusion: An important and often overlooked element of the BA role is to facilitate decision making.  Whether that’s over prioritization of projects, feature requests, requirements or something else, we are on hand to analyze the different perspectives and ensure an informed decision is made.

Ensuring that we do this consciously, taking into account multiple factors (while keeping ‘opportunity cost’ in mind) is crucial. It’s one of the many areas where BAs add value!

Deep Listening: Avoid Hearing What You Want To Hear

Elicitation is a key business analysis skill. Whether it’s one-on-one interviews, workshops, observation or one of the many other techniques, elicitation is a key source of information. As BAs, it’s easy to think that we are highly attuned listeners, carefully scouring the airwaves for tasty morsels of relevant information. Of course, this is probably true. However, have you ever reflected on how deeply you pay attention and listen? For example, have you ever:

  • Quickly checked your email in a meeting (where something critical could be mentioned, but you weren’t expecting it)
  • Been tired at the end of the day so tried to rush a conversation
  • Skim-read an email and missed a key detail
  • Missed a key piece of information in a document
  • By the time you interview the sixth person, you think you already know the answer so ‘tune out’ for part of the interview

If you haven’t, then you probably deserve a medal. I’m sure most of us have indulged in some—or all—of these behaviors at some point in our careers. While there might be good reasons to do so in some cases, doing so will affect the ability to listen deeply. Notably, by ‘listening’ here, I’m also referring to ‘reading’ of information, as I suspect we all spend a lot of time ‘listening’ to our colleagues through their emails and comments on documents etc.

 

Miscommunication Is Rife

It’s easy to miss the point when listening or reading.  As an example, I was wandering around a large supermarket here in the UK, and I picked up a bottle of own-brand hand wash. I was looking on the back of it, and noticed the following statement in bold:

 

[Supermarket name] is against animal testing and funds alternatives

It struck me that this is a deliberate piece of misdirection. If you were scanning it quickly to look for information about whether the product is tested on animals, you might see that statement and think “oh, they’re against animal testing, so it’s fine”. This is similar to a case where a listener hears what they expect to hear, or what they want to hear! However, the statement taken at face value doesn’t confirm (or refute) whether the product was (or wasn’t) tested on animals. It just says the supermarket is against animal testing and funds alternatives.  Yet many readers’ might inadvertently apply their own meaning to it.

 

Advertisement

 

Granted, you’re unlikely to be reading a statement on the back of a hand wash bottle at work, and it’s unlikely that folks will be deliberately trying to deceive. But it’s very easy to miss tiny nuances in verbal or written communication.  Take these statements:

  • “I broadly agree with what is proposed” (what does broadly mean? Are there areas of disagreement? If so, what are they?)
  • “I agree with points 1 and 3”. (OK. Do you disagree with point 2?)
  • “This is a real pain point for us.” (What does ‘pain point’ mean? Does our definition of ‘pain point’ agree with theirs?)

These are just three specific examples, but I’m sure you get the point.

 

Curiosity Is A Prerequisite To Listening Deeply

Deep listening is hard, and a skill that one could probably work on for their entire life. I have heard it said multiple times that people tend to listen to respond; by the end of the speaker’s sentence the listener is tuned out thinking how to respond. As a BA, this might translate into thinking about the next question.

It is almost as if we are scared of silence. Like silence will be interpreted as some awful slight on our stakeholders. Yet in reality a (relatively short) amount of silence can be useful. In my experience, people will often pause, reflect, and add more insight when given a bit of breathing space. Of course, what is considered an appropriate length of silence varies, and certainly it shouldn’t be excessive!

A common thread throughout this is curiosity. If we are genuinely curious about the stakeholder, the subject-matter, their perspectives and so on then it’s easier to focus in and listen. If we lose curiosity or get distracted by the busy-work of organizational life it’s far too easy to tune out.

 

Here’s to remaining curious, and to listening deeply!

 

What A Shoulder Injury Taught Me About Business Change

I’ve recently been going through physiotherapy treatment on my shoulder after a minor (but painful) injury. I’ve never had physiotherapy before, and so I had certain (entirely wrong) assumptions about what would happen. I assumed that a quick but potentially painful treatment would be ‘done to me’.   I had visions of the physio grabbing my shoulder, cracking it back into place, me briefly wincing and then me happily going on with my life…

As anyone who has gone through physio will tell you, this isn’t generally how things work. In fact, recovery has involved months of varied exercises and stretches to build up particular muscles and regain movement. I mentioned my misconception to my physio; “Yes” she said “That’s a common misconception. Physio is not something we can do to you, a lot of the improvement is down to the efforts of the patient”.

 

Business Change Needs Wide-Ranging Engagement & Effort

It strikes me that there is a broad similarity here with business change.  There might sometimes be a perception that change can be “done to” or “imposed upon” a particular team or business area. There might be the (highly flawed) view that a new IT system can be rolled out with little interaction or engagement with those that are actually using it, and once the system is rolled out the ‘job is done’.  Of course, nothing could be further from the truth. If the right people aren’t involved or represented, it’s very likely that key requirements will have been missed. Even if the system is functionally fantastic, without buy-in it might still be rejected.  We’ve probably all got systems and processes that we just hate because we weren’t consulted when they were created. Employee expense submission processes are rarely popular, for example…

 

Advertisement

 

This highlights a dangerous myth: the “one and done” view of change. The “deploy and forget” approach. Few people would deliberately do this of course… but when times are hard and deadlines slip, it’s tempting to reduce the engagement (as engagement inevitably leads to varying perspectives and opinions being uncovered).  Far easier to steamroll ahead with the assumed solution.

Yet much as physiotherapy relies on the efforts of the patient, successful business change is often predicated on the buy-in, engagement and efforts of a whole range of key stakeholders. It might sometimes be seen as inconvenient when different stakeholders have different (sometimes conflicting) views, but surface them early and this can be addressed. If the views aren’t surfaced, then the conflict will bubble away… and one (or both) groups will slowly simmer until something explodes, usually at the least convenient of times!

 

Incremental Delivery Helps (When Appropriate)

Just as physiotherapy relies on repetition and building of muscles/range, there’s a similarity with business change. In some situations it’ll be far more desirable to deliver change incrementally, in small manageable chunks. Not only does this de-risk the delivery, it also gives people the chance to get used to things more gradually. Using the metaphor of physiotherapy, it’s a gradual change over a period of time.  It also allows feedback to be sought along the way, so that the course can be changed if things aren’t on track. Much as a physio would change the exercise regime if things aren’t working.

It’s also important to keep the outcomes firmly in mind. Much as I now have phrases like “external rotation”, “shoulder abduction” and others firmly imprinted on my brain (along with how to benchmark them), projects need to consider their outcomes too.

This is much more than just a tickbox ‘business case’ exercise. For change to be successful, it’s likely there will be outcomes at a strategic and tactical level. Yes, a key aim might be to  ‘increase revenue’. However if it actually makes the lives of a whole bunch of internal users worse it’s likely to flop. Hence, ‘reducing frustration with the current process’ might be a key enabler for ‘increasing revenue’.  Knowing this, and seeing how things progress as the changes are incrementally implemented will help.

Finally, it turns out that my estimate of how long my shoulder would take to recover was wildly inaccurate. However, as work started I could see the finish line more clearly. Perhaps there is a lesson to be learned there about estimation: with ‘rolling wave’ estimation being preferable over a single estimate that is given long before anything tangible is known!

Best of BATimes: Does Networking Hurt Your Hands? The Power Of A Glossary

A few weeks ago I was working away from home, and I was able to attend an IIBA UK event in the evening.

 

It was a really enjoyable event, and after meeting a whole bunch of new people and chatting about all things BA related, I went and checked in to my hotel. As I was checking in, the receptionist asked me how my day had gone. I explained that it had been busy, and I’d spent a few hours networking late into the evening. As much as I enjoy networking (I love meeting new people and sharing/learning), I do find it exhausting. As he handed me my key, the receptionist said something that really surprised me:

“Ah, I used to do a lot of networking. Kills the hands, doesn’t it? All that terminating. I used to work for a communication company so I did a lot of networking”.

Perhaps it was because I was tired, but I did the typically British thing and just smiled and accepted the statement that he’d made without questioning it–but on my way to my room I was puzzling over what he’d said. Why would networking hurt his hands? Too many handshakes maybe? And why would you terminate something at a networking event… that sounds pretty serious! And why is the fact he worked for a communication company important…

Then the penny dropped. Networking has different meanings, and I suspect he was referring to laying physical networking cables in a data center or communication room, where cables have to be crimped and (presumably) ‘terminated’. Perhaps using some of the tools is uncomfortable after a while. “An evening networking” to me means meeting other BAs and having a coffee. To him it meant navigating cables in a comms room ‘out of hours’ getting everything ready before people arrive the next day.

 

Advertisement

 

The Illusion Of Communication

As William H. Wyte once wrote “The great enemy of communication, we find, is the illusion of it.”. This is often the case inside organizations and between organizations too. With our plethora of acronyms and words with ‘special meanings’, it is easy to appear that we are agreeing on a particular issue, idea or requirement, only to find out that each person at the table has a subtly different understanding of what is being discussed.

Even words that appear, on the surface, to be obvious can have different meanings depending on who you ask. The word ‘customer’ might seem clear and obvious, but it is quite possible that different people attribute different meanings to it. Who is the ‘customer’ of a training course? The delegate who attends it? The company that employs the delegate (assuming they are paying)? Probably both–although both will have subtly different needs and requirements, only some of which overlap. This is made even more complicated in intermediated industries where there might be an end customer, and one (or many) intermediaries. If a financial service company sells products via brokers, some might refer to the broker as a ‘customer’, others might refer to the end investor as the ‘customer’. Again, they’ll have very different needs and requirements.

This can lead to all sorts of crossed-communication throughout the business change lifecycle, not least when it comes to requirements. Whether we’re writing user stories, use cases or even a heavy-weight requirements catalogue, it pays to think about terminology. This is where the good, old, trustworthy glossary comes in.

A glossary perhaps isn’t the first thing that springs to our minds as business analysts. It’s something we know we probably should do, but with the pressures of a project it can be easy to let it slide. This simple experience, with a misunderstanding over the word ‘networking’, reminded me how important they are. After all, with a clear glossary, writing just about any type of requirement artifact becomes easier. If there is a clear and agreed meaning of “Investor” and “Broker”, for example (rather than using a term like “Customer” that might mean either, or both) we can be concise and precise in our requirements writing.

This potential for misunderstanding also highlights the need for techniques that don’t rely on the written word. Visual techniques, including formal modeling, can help explore the problem space and requirement scope too. All of these activities help us cultivate conversations and help us ask “what exactly do you mean by ‘x’?”. Not only this, but a well-defined glossary can help inform the production of other artefacts such as a concept model (these are clearly different things, but defining terms up front helps a great deal).

In Summary

A glossary might take some time to create and maintain, but it’ll help avoid ambiguity and ensure we can create concise and precise requirements. It is an investment in time worth making.