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

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: