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

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.

Don’t Be The Business Prevention Department

About fifteen years ago, I was working closely with a group of subject matter experts in an insurance company. There was regular friendly banter between members of the marketing team and the representatives from the legal & compliance department. The compliance folk were tasked with ensuring legislative alignment, reducing risk and assuring that everything was done properly. The marketing folk cared about that too, of course, but also wanted to maximize the volume of business that came through the door.

 

Both perspectives are completely valid, and as you can imagine there was the occasional difference of opinion. I remember one of the marketing team playfully giving their compliance counterpart a custom printed mouse mat which read “Compliance: The Business Prevention Department”.  I should stress that this was all done in good humor, with both parties finding it hilarious. In reality, these stakeholders had a good empathy and understanding of each others’ perspectives. They were a joy to work with!

 

However, that phrase “business prevention department” has stuck with me ever since. I have found myself in situations as a BA where stakeholders just don’t want to engage, or engage only reluctantly. This often happens when they feel that analysis is going to slow things down, or ‘clog up the gears of change’.  Of course, you and I know that good and proportionate business analysis absolutely doesn’t do that—it actually clears the way so that change can accelerate—but there is sometimes the perception that we slow things down.

 

I was recently re-reading the fantastic article “When BAs go Bad” by Christina Lovelock, and this got me thinking that some of our BA strengths can actually end up being crucial weaknesses if they are overplayed.  This line particularly jumped out at me from Christina’s article:

“We can be seen as very negative. Some BAs want to say no to everything, and as it is our JOB to analyze things, we can usually come up with five good reasons something won’t work before the other person has even finished explaining the idea.”

 

Constructive Challenge Not Business Prevention

There is a fine line to be drawn here. As BAs we absolutely need to challenge the norm, ask whether constraints still hold true and delve deeply into root causes. This often involves asking questions with genuine curiosity, and pushing well beyond the first answer or first solution that is proposed.

Yet it is important that we do so with rapport, and that we do so in a constructive and tactful way. If we were to interrupt, monopolize the conversation or jump in too soon, the perception of negativity might seep in. All of a sudden people don’t want to work with BAs, because BAs are seen as part of the “business prevention department”… or perhaps the “change prevention department”!

 

Advertisement

 

This highlights the importance of ensuring that we continually hone our interpersonal skills, that we ‘read the room’ and listen deeply to our stakeholders. Sometimes we might have an inkling that someone isn’t giving us the full answer… but jumping in right away might not be the best thing to do. Hearing them out, letting the conversation flow naturally, and following up at an appropriate point in the conversation might be better.

 

Think From Their Perspective: What CAN Be Done

So much of this centers on really understanding our stakeholders and their perspectives. It is usual, at some point in a change initiative, to have to say “no” to someone. It might be that a feature cannot be delivered in a particular release, that a date can’t be met, or something else. If there’s mutual respect and rapport with the person this doesn’t have to be a particularly difficult conversation—particularly if expectations have been managed along the way.

 

It’s so important to get to know our stakeholders, and their perspectives on the particular change initiative. What outcomes are they seeking from it? Of course, there will be overarching project or program outcomes, but there might be particular goals that particular stakeholders gravitate towards. Knowing this makes it easier to preempt what a particular stakeholder will really care about, and when they’ll need to be engaged. It can help with communication and engagement planning, and help to identify which parts of the project they really care about.  Even if we have to say “no” to one thing, perhaps we can say “yes” to something they value even more, or perhaps we can say “yes” to achieving their goal in a better, quicker and slicker way than they envisaged.

 

In summary: one of the key things we need to do as BAs is to help co-create the space for successful change to happen. This involves challenging and asking tricky questions, but we should be careful not to delve into the realms of negativity. We should think business enablement not business prevention!

 

 

Avoid Illusory Constraints And Incentives

If you were learning to drive in the UK, chances are you’d get in touch with a driving instructor. Over here, many of the driving schools they work for have company names starting with the number 1 (often ‘1st CompanyName Driving School’).  I suppose if I were a driving instructor my default company name would be “1st Reed” or something similar.

It might seem curious as to why there are so many driving schools with “1st” in their company names. We might assume it’s a signal that people who learn with them pass their driving test first time… but I suspect there’s another legacy reason, which goes back twenty years or more.  You see, when I learned to drive, you didn’t Google a driving instructor, you used the Yellow Pages.

 

For anyone unfamiliar with the Yellow Pages, it used to be a thick local telephone directory of different companies. It probably still exists, but twenty years ago it was an essential reference for every household and could usually be found close to the (corded) landline telephone.  It was printed on thin yellow paper, and had thousands and thousands of companies listed.

You’d search for a category (‘driving instructor’) and then (with the exception of paid ads) the companies were generally listed in alphabetical order.  And company names starting with numbers were given preference, so a company named “1st Aardvark Driving School” would be listed above “Aardvark Driving School”… hence the incentive to start a company name with the phrase “1st…”.

 

Advertisement

 

The Constraints and Incentives Of Yesterday Might Be Irrelevant Today

Today, I would guess that very few people search for a driving school using a paper telephone directory, so this necessity to preface a company name with ‘1st’ is no longer valid.  Not only this, it could actually hinder findability…. Imagine if you heard somebody say their company name was “First Reed”.  Would the URL be 1stReed.com, FirstReed.com, First-Reed.com, or something else?  What keyword would you type into Google to search for them?

I wonder if issues of ‘digital findability’ might also start to affect musicians. With more and more people using voice-activated assistants, bands might get more airplay if they have a band name and a song name that is “voice assistant friendly”.  Don’t believe me? Try to get an AI assistant to find music by 90s band Campag Velocet and you’ll likely see the problem.

The point here is that constraints and incentives of yesterday (“We must start our company name with ‘1st’” or “Unusual band names sell records!”) might actually be disadvantages today.  The incentives and constraints have changed, and those that recognize that can use it to their advantage.

 

What This Means For BAs: The Importance of Healthy Challenge

This is where good business analysis helps.  It often feels that there is a human tendency to revert-to-norm and to “do what we’ve always done”.  In our world as BAs, this might relate to the way work is undertaken, the way a process works, or the way that technology is used.

In these situations there is a huge opportunity to tactfully challenge: to ask does it still need to be that way? And also ask what are the implications if it is implemented that way? Are we ‘baking in’ a constraint that is no longer relevant?

This starts by identifying those tacit assumptions and constraints and seeing whether they are really still valid. Techniques such as ‘five whys’, the brown cow model, or just informally asking questions with curiosity and listening deeply to the response can help a great deal.

Whichever techniques we use, having the confidence to build rapport and tactfully challenge accepted practices is key. Sometimes there might be a valid reason for the status quo… but if there isn’t, we might be able to help co-create a better way with our stakeholders. And if we can create something better, cheaper, slicker, better… that has to be a good thing!

The Tyranny Of “Default”: Be Careful When Choosing Analysis Techniques/Artifacts!

At its essence, a lot of what we do as business analysts involves co-creating a shared understanding. Whether that’s a shared understanding of a problematic situation, or of a set of requirements or features, a common theme is that we work to understand different perspectives and ensure that people are ‘on the same page’.

This can cause some challenges when we want to communicate complex ideas. Text is a challenging media to convey complexity, and the English language is just brimming with words that have multiple meanings. For that reason, it’s very usual to use a combination of text, models and conversations to ensure that key stakeholders are aligned.

 

When we create a model, we are essentially codifying some information in a way that can be later referred to. Codifying typically involves using some form of notation (whether that’s a business process modeling notation, or the symbols of an alphabet when writing text), and there will usually be particular rules on what elements of the notation mean and how they should be used.  For example, particular shapes on a process model represent particular things, particular words in a textual paragraph have a particular meaning.

Yet when we encode our analysis in this way, how often do we reflect and think “will my stakeholders understand this?”.  Will the consumers of the information both know how to read it, and, ideally like referring to it as it’s a format that works for them?  Perhaps we don’t think about this quite as often as we could…

 

Advertisement

 

The Tyranny Of “Default”

I have a confession to make. I love Business Process Model & Notation (BPMN).  I could quite easily ‘geek out’ and create process models to an executable level, using just about every BPMN symbol and construct that is available to me.  But, as those of you who are familiar with BPMN will attest, if I did that the resulting diagram wouldn’t be very accessible to the average stakeholder.  It would be somewhat akin to me sending an email in French to someone who only speaks English.  It might be possible to pick out some elements of the communication and work out what is going on… but it’d be very difficult to draw conclusions.

This absolutely isn’t an argument against BPMN by the way—it’s stil one ofl my preferred notations—but it highlights the importance of thinking of the artifact’s audience and choosing an appropriate level.  With BPMN, I might create a ‘view’ of a process using a cut-down palette of symbols, and model at a much higher level, so it is more intuitive. Equally, I might choose to use ‘boxes, arrows, diamonds and lines’ instead where it is appropriate to do so…

The key point here is flexibility.  It is very easy to get stuck in a rut and choose a technique because it’s the default.  You probably have a favorite approach or technique, which might mean you tend to default to a particular type of artifact. Or perhaps your organization has templates or tools that ‘nudge’ you towards a particular style.  That can be useful, it can embed consistency… but it can also lead to things being articulated in a particular way “because that’s the way we do it here, and that’s the way that we’ve always done it”.  Neither of which, on their own, are particularly compelling reasons.

 

Light The Fuse: Ask “Why Are We Using User Stories”

If you like a bit of controversy, next time you are working on an agile project, ask “why do we use user stories here?”.  Usually, the response will be a blank face, followed by either “because we’re agile” or “well… the tool is set up for user stories… so….that’s what we do”.

But are these really valid responses?  There’s certainly nothing in the agile manifesto that decrees user stories are mandatory.  The term ‘user story’ isn’t in the Scrum guide at all. So why default to user stories?

Of course, user stories do have merit, particularly in agile. Yet the choice to use them should be a conscious one. In fact, user stories alone are probably not enough… they will probably need to be supplemented with regular collaboration, acceptance criteria and you might even decide to document some journeys or prototypes.  It’s likely that most successful teams already do this, but it is worth highlighting.   Some of this might emerge as you discover more about the requirements… but having at least an idea of what the requirements architecture will look like up front will save pain later (e.g. “We might use prototypes, so let’s agree that one prototype will span multiple user stories… we’ll capture the links here…).

So, this article certainly isn’t criticizing user stories. However, as with any profession, we need to regularly challenge ourselves and challenge our ‘defaults’.  It is worth remembering that we have a wide toolkit at our disposal. If a plumber approached your sink with a hammer and started smashing it (rather than figuring out the right tool for the context), you’d be somewhat annoyed. An explanation of “ah, I always use a hammer” is unlikely to help.  The same is true in our profession too… and it is worth remembering how broad our toolkit is. Which provides us with many possibilities!