Skip to content

Uncategorized

Lessons from the MultiVac: The Importance of Context in Business Analysis

It may surprise you to know that my first ever job was as an assistant groundsperson in an industrial estate. For those of you unfamiliar with what a ‘groundsperson’ does, it’s essentially a job that involves maintaining just about everything that is outside, including gardening, roads, and so much more. 

With such a varied role, there are a variety of tools. A spade is definitely not a shovel, a ‘hoe’ is probably not what you think it is. Oh, and be careful with bow saws (I still have a scar that reminds me of that).

A MultiVac: A large outdoor vacuum cleaner, industrial looking, with a broom laid on top.
A “MultiVac”

One of the particular tools I have a ‘fond memory’ of is a MultiVac.  If you’ve never had the ‘pleasure’ (and I use that term with a large dose of British irony) of using one of these devices, here’s a photo.  A MutiVac is essentially a large, outdoor vacuum cleaner, predominantly for clearing leaves and other stuff on roads.

It is a lot quicker than sweeping.  Or rather, it is a lot quicker than sweeping in some specific sets of circumstances. Outside of those circumstances, it is slower and less efficient.

The Right Tool For The Situation

Now, I’m sure MutiVac technology has come a long way since the early-90s when I used one. Back in those days it was definitely not advisable to use one in the rain, or when the road surface was wet. The issue was that the machine would clog up, and you’d be forever unblocking the darn thing and believe me this was not a pleasant task. If you really needed to clear a road in the rain, it might actually be quicker to use a stiff broom and a shovel. Although, frankly, the best thing to do was probably wait and do something else. (Incidentally, weeding flower beds is a great job in light rain. The moisture loosens the soil).

Uneven surfaces were also a no-go. Steps, and anything with too much of an incline would be far better cleared by hand.

Now of course, you (probably) don’t use a MultiVac at work. So why is this relevant?

There are, in my mind, at least two reasons, and they relate to how tools are used in different contexts.

It’s Functionally Fantastic, But We Still Hate It: The Importance Of NFRs

When considering buying or designing a new product, it is often the functionality that dominates the conversation. Cast your mind back to the day that you got your first smartphone. If you’re anything like me, you were excited about the new features that you’d be able to use: suddenly there was the ability to send emails, play games, look up train times and much more besides. Yet for any of those features to be useful, certain other non-functional aspects have to be met too. As a consumer, I take for granted that my smartphone will be quick (imagine if it took 20 seconds to swipe the screen) and have a reasonable battery life (if the battery didn’t last a full working day that would be a major issue).  

An AI generated image of an old mobile phone. It looks like a combination between a landline and a mobile, with a polaroid camera lens on the top. It is a horrible brown colour, with worn keys, and a coiled cable.
Image courtesy of Stable Diffusion XL Pro AI

These implicit non-functional aspects play a huge part in whether the product will actually be used once it’s purchased, and whether anyone will actually like using it.  The harsh truth is that a product can be functionally fantastic, but if the non-functional aspects aren’t right, whoever has to use it might still end up hating it!

In the example of a smartphone, many of these aspects are implicit and taken for granted. Having a phone that is speedy to load apps is normal so (unless they’ve had bad experiences in the past) it’s unlikely that a customer is going to specifically ask for it.  We could almost consider some of these aspects to be ‘hygiene factors’.  Customers are unlikely to get excited if these requirements are met, but they are likely to be extremely disappointed if they aren’t met!

The Non-Functional Challenge

The implicit nature of these expectations hints at the challenge of eliciting and analysing Non-Functional Requirements (NFR).  Before we discuss this further, it is valuable to provide a definition. The International Institute for Business Analysis (IIBA®)’s Business Analysis Body of Knowledge (BABOK®) guide v3 define an NFR as:

Defining “Finished”: Don’t Leave Trash In The Forecourt

We recently had some (relatively minor) repairs done on the roof of our house. If you’ve ever had to arrange repair work on a house, you’ll know that the process can be tricky. It’s necessary to find a credible and reputable tradesperson, and then actually get a quote and arrange a date. What is made worse, of course, is when it comes to roofing problems there tend to be peaks in demand. When there’s stormy weather and rain, roofers are in sudden demand!

Following a few phone calls we found a suitable roofing firm, who were really easy to deal with. They turned up when they said they were going to, did the job with minimum disruption to us, and then left. They took photos of the work, and even alerted us to some other potential maintenance issues we might want to consider. This is pretty much everything you could hope for when it comes to having work done on a house!

And Then They Were “Done”

Several bags of rubbish/garbage piled in an urban setting. There are at least 11 bags visible, mostly big black bin liners, with the occasional smaller white shopping bag.
(Image credit ©sdf_qwe — yayimages.com #48587870)

Shortly after they had finished for the day and left, we received a message from the owner of the company confirming the work was complete and attaching an invoice. He also let us know that the rubbish they’d left behind would be collected in the next few days. That’s pretty important to us, as they had included removal of the rubbish in their quote, and as a ‘zero car’ household, it’s difficult to get rid of bulky waste.

This got me thinking about what the term “finished” actually means. I know there’s all sorts of debate about ‘definition of done’ in agile and I just don’t want to open that can of worms. Here, I’m speaking more generally about how different perspectives can exist on what ‘finished’ or ‘done’ actually means.  For example:

Navigating the Why: The Essential Role of Product Vision and Coherence

  • Adrian Reed 
  • 5 min read

One area where BAs can add significant value is in the early stages of a project or product development initiative.  All too often, initiatives start out without a clear agreement on why change is necessary in the first place. Different stakeholders might have subtly (or vastly) different perspectives on what is wrong and what success looks like. Even worse, these differences may be lurking well beneath the surface. 

High pile of stones on the sea coast
(Image credit ©styf22 — yayimages.com #522056)

Sometimes, there is the illusion of agreement. Stakeholders may appear to agree on broad principles, but there is tacit disagreement because their interpretation of these principles differ! They have very different visions in their head over what is being done and why. This illusion allows the initiative to be launched and accelerated, with the danger that it might accelerate straight into a concrete wall.

Lack Of Shared Vision Can Lead To Incoherence

A Lesson From Top Of The Pops: Knowing Your Real Stakeholders’ Needs

Over the past few months, I’ve been watching old 1990s episodes of Top of The Pops (ToTP). For anyone who isn’t UK based, or doesn’t remember ToTP, it was a weekly show which featured music artists and bands from the charts. Being on ToTP was seen as a huge indication of success, and at the time it was one of the few places to see chart music on TV. For anyone that liked pop music, it was required viewing.

A man singing and jumping on stage at concert
(Image Credit: ©moodboardww — yayimages.com #35516264)

One of the things that looks really odd, in retrospect, is how the crowd reacts to the music. Generally speaking, they pretty much clap along in a weirdly coordinated, almost robotic, way. It’s really odd seeing people clap and sway along to early 90s indie music in a way that, well, nobody ever would at a gig. If you go and watch an episode from 91 or 92 on YouTube, you’ll see what I mean.

Having watched a documentary about the making of Top of The Pops, I gather that in the early 90s the crowd were pretty much told how to behave. Not only this, some bands and artists that weren’t seen as ‘visual’ enough would be provided with backing dancers who would dance along with them.  Watch these in retrospect and you can see how much the different styles of dancing jars with the music.  It must have been a thoroughly bizarre experience to be in the audience, and in retrospect it’s quite a bizarre thing to watch!

Building For “Them” Not For “Us”

The decision to encourage people to clap and to employ generic dancers could be described as ‘design decisions’. Ultimately, an executive producer (or someone) is presumably responsible for designing the programming and ensuring the output meets its stakeholder needs. Those stakeholders would include the viewers, the live audience and many others (including the needs of the person commissioning the show).

Learn To Love Workarounds: They Signpost Opportunity

I suspect that many people reading this article will have been involved with the definition of business processes. Business processes, when well-defined can help to ensure a standard approach is adopted, as well as ensuring that work and customer queries are dealt with in a consistent manner.  They can also help remove the cognitive burden of those conducting the work. A good process will ensure that all of the predictable, high frequency, repeatable decisions are made in advance so that less ad-hoc decision-making is needed “on the fly”.  Of course, there are some contexts where this is less appropriate, and there must always be room for variation, but there are many contexts where at least some standardisation is desirable.

Yet, there is an old saying that “no process model survives contact with the real world”. I’m sure we’ve all seen situations where there is a beautifully created, detailed set of process models… but everyone involved knows that the work isn’t really conducted that way.  This is one of the many reasons that techniques such as observation are so key alongside interviews and workshops. Observation helps us begin to see what really goes on (or at least gets us closer to it).

One of the practical challenges can be that there is a disconnect between those that define processes, and those that actually do the work.  I remember once arriving at a client-site, hearing some of the warehouse staff outside describing decisions that had been made by “the office people”; the implication being those decisions had been made by somebody who had no idea how the work actually works…

Process Disconnects

I saw an interesting example of this type of pattern recently. As many rail-users in the UK will know, there is a free newspaper called “The Metro” which is ubiquitous at railway stations in parts of the UK. Take a look at the picture below.

Questioning The Unquestionable

The music video was set on a desert island (Image credit:  ©12ee12 — stock.adobe.com #105027014)

One thing you probably don’t know about me is that I was a backing dancer in the video for the  2001 hit ‘Survivor’ by Destiny’s Child.  One of the reasons that you probably aren’t aware of this is that it isn’t something that I talk about much as 2001 seems a lifetime ago and I’ve made a major career shift since then. However the second (and most important reason) that you probably don’t know this about me is that it absolutely isn’t true.  Literally none of it.

That’s right, I’m sorry to disappoint you, but I didn’t make the career change from backing dancer to business analyst (if only).  Yet, there was probably part of you that read that opening line and thought ‘wow, backing dancer, I wasn’t expecting that, how interesting!’. After all, it is a bizarrely specific claim isn’t it? And you’d be forgiven for thinking “what possible motive would Adrian have to try to convince me that he was in a music video if this isn’t true?”.

This is actually one of my go-to ‘bluffs’ for those unimaginitive ice-breakers where you have to list two truths and one lie. I’ve even created an entire backstory for it (and again, I cannot stress this enough: this is not true and it is a complete bluff):

Digital Transformation: The Emperor Is Naked!

Image Credit: © everettovrk — stock.adobe.com #104450030

A term that seems to have taken increased prominence over the last decade or so is digital transformation.  It has become such a frequently used part of the organisational lexicon that it is rarely questioned.  It’s a term that is accepted, it sounds like something that is self-explanatory and somehow obvious.  I mean who doesn’t want a digital transformation?  In the next breath there will be the inevitable cliches of Blockbuster, Netflix, Uber and others (cliches, by the way, that I am just as guilty as anyone as using…).

Within the business analysis community I hear a lot of discussions about how to work within a digital transformation programme, whether the tools and techniques are different to “other” types of initiative. I occasionally hear debates about whether there should be a “Digital BA” role. These are sensible questions for us to ask ourselves—but shouldn’t we start by asking what does digital transformation actually mean anyway?

Far be it from me to reinvent the wheel.  A bit of research will uncover scores of books and papers about this topic, here are two definitions that I find particularly interesting.  

Digital transformation:

Mindful Stakeholder Engagement

This post is written by Kathy Berkidge of Mind at Work Consulting. I first met Kathy at a conference and I was absolutely blown away by her presentation, and I’m so pleased she agreed to write an article. I hope you enjoy it as much as I did! — Adrian


Effective stakeholder engagement can mean the difference between successful project delivery and project failure. We BAs work closely with stakeholders to understand their needs and ensure they are translated into solution requirements. If we don’t engage with our stakeholders successfully, requirements may be missed or misinterpreted leading to products and services that fail to deliver the outcomes expected.

There are many barriers that may affect a stakeholder’s engagement, including:

  • Lack of vision or not understanding the project context
  • Resistance to share information
  • Failure to understand what’s in it for them
  • Misinterpretation of their needs
  • Lack of available time
  • Poor communication
  • Lack of trust
  • Previous history or negative perceptions from past experiences and projects
  • Fear of change

Also, stakeholders often have very different expectations on what is, or is not, going to change. Something that seems like an improvement to one group of stakeholders may be perceived as a retrograde step for others. For example, an energy company that wants householders to download an app to submit meter readings and receive bills – the householders just want to keep things the same as they are now – it’s much easier!

Thanks For Following My Blog. You Might Also Be Interested In ‘BA Digest’ And Our #BACommunity Webinars

Hi there,

Adrian Reed

Thanks so much for being a subscriber/reader of my blog, I really appreciate it. 🙂  I hope that you’re finding the content useful and interesting.  In a break from my regular ‘blog style’, I just wanted to let you know about some other resources that might be of interest to you.


BA Digest: A regular round-up of BA related articles

I’ve been creating the BA Digest newsletter for a few years now.  I send this out every 4-8 weeks, and it is a round-up of a whole range of articles/videos/interesting content from around the web.  I recently realised that not everyone who reads my blog might be aware of this 🙂

You can check out the May/June Edition Here

If you’d like to receive a copy direct to your inbox, just sign up (for free) at www.badigest.co.uk