Adrian Reed's Blog

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).

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.

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).  

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:

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”

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:

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. 

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

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.

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).

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.

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):