The Business Analyst: Facilitator or Designer?

Craig challenged me on the role of the BA recently.  I said that Web 2.0 is something you can only understand in practice and he posted:

Having said that what do you say to the role of the professional Business analyst; the person who doesn’t use the system but makes many of the key decisions about what goes into it?

It’s a good question and one I’ve been mulling over since he asked it. For the sake of brevity I’m going to park the generic question ‘what is the role of the Business Analyst’ and the vexed issue of whether or not the user should be the primary arbiter of what goes into a system.

Users do know about user experience.  One of the things I like about Lean Interventions is that you go to the people enmeshed in using the process and get them to re-design it.  If a BA has a role in this, it’s as an educator about Lean principles and as a facilitator. The BA does not design the process, the people using the process do that.  I should probably also mention focus groups as a way of involving users in the design phase, but I can’t really comment since I’ve never worked in that way.

But users are rarely available. In my career to date the actual end user has rarely had a seat at the table because with web stuff the user is quite often outside the organisation.   The Business is frequently the proxy for the user, and the Business is sometimes the team sponsoring the system, but it can also be a programme team whose expertise is in change not the system they are changing.  Either way they are representing the user, which brings us back to the underlying question:

‘is it possible for the user to be represented by anyone else?’

After thinking about it for some days and toying with this post for several hours, I think the short answer to that one is: Not always, but that is what use cases ¹ are for.’

So what to do about it?

I’ve mentioned focus groups, though I’ve not run any myself.  But let’s hear a shout out for prototypes and pilot studies here. Oh, the difference when you prototype a user journey! It’s like having a mystery shopper before the shop has opened. The great joy of a prototype is that the thing comes to life and suddenly everyone involved can have a go at being a user, and pilot implementations tell you where the weak spots are. This is closely linked to O’Reilly’s perpetual beta of course, and is also why Anything 2.0 is better than Anything 1.0.

Craig didn’t ask whether the BA could represent the user, he actually asked:

What do you say to the role of the professional Business Analyst?

I think my answer is that the BA should be a facilitator not a designer.  The facilitator enables the Business to produce a design that IT can use whereas a designer does that for them.  (Other operating models are available). It’s the BA’s job to use tools like use cases and prototypes to help the Business represent the user. That doesn’t mean the Business will do a good job of representing the user, but it’s a step closer than if the BA tries to do it. And even so, it’s a tad idealistic. At times the Business Analyst who’s a facilitator has to make calls that affect the design, but I think that’s something that we shouldn’t do by default.

As  you can see, Craig’s question gave me pause for a considerable amount of thought, a lot of it typed directly into this post and most of it cut straight  out again.  To pull it all together:

• Organisations deliver user-aggressive or ineffective systems for a myriad of reasons which include
  • organisational culture during the design stage resulting in a lack of user representation
  • pressures of time and cost
    which frequently result in
  • methodologies which lack rigour, in particular sloppy requirements definition and sign-off
• Good design requires holistic systems thinking (that’s one for the buzzword bingo) which incorporates the user’s point of view
• Only users are users, but tools like use cases, user journeys, prototyping and testing get you closer
• Ideally, the BA’s role is as a facilitator rather than a designer
• The local challenge is whether you
  • go directly to the user (eg a Lean Intervention)
  • allow the Business to act as a proxy (so much of my life to date)
  • use a prototype, or focus group or pilot study (love those)

I’m quite surprised Web 2.0 evangelists aren’t yet hypothesising Open Source Organisation Design which would be well wiki’d.

(Boom boom).

O’Reilly says ‘Users must be treated as co-developers’ which takes open source software build on into open source software design. If he or anyone else has taken this idea into the realms of open source organisation design and I’ve missed it, please drop a link in the comments.

---

1 – a Use Case is – for want of a better term – a scenario: ‘A white horse walks into a bar’; ‘A funny thing happened on the way to the theatre’; ‘Writing a blog, (what’s that all about)’. A use case can be large: ‘Government bails out banks’ or small ‘Customer buys a bottle of milk’.  If you want a less flippant definition, here’s the one from Wikipedia. But much better to go back to post

---

If not duffers, won’t drown

Better drowned than duffers 
if not duffers won’t drown

The young teenagers in Swallows and Amazons spend their entire summer camping and sailing around Lake Coniston.  When their father gives them permission by telegram, he explicitly states that he trusts their common sense and sense of self-preservation to keep them out of danger, and he puts in a  rider about the Darwinian consequences of stupidity.  

This may seem a long way from good Business Analysis, but it’s too easy to let caution drive out common sense and pragmatism when you are in the world of risk avoidance and business rules.  I’d forgotten what it was like to live in a world where I’m trusted not to be stupid.  Shetland is a delight because it is just such a world.  Let me give you three examples:

The Broch at Mousa is an archaeological site of international importance.  Brochs were large cooling-tower shaped buildings built by the Picts in the last few centuries BC.  They were only ever built in Shetland, Orkney and Northern Scotland and little is known about them because the Picts seem to have been wiped out by the Norse in the first millenium AD.  The Broch at Mousa stands 13 meters tall (about 4 storeys) and is the most complete.  

The Broch at Mousa

Compare it in your mind with Stonehenge, the Pyramids at Giza or the Taj Mahal in terms of unique cultural importance.  The building isn’t particularly fragile but it’s a dry-stone building so it is vulnerable to souvenir hunters.  

Get this: there is a cupboard containing torches to help you climb the staircase spiraling around the broch inside its double-skinned walls.  

Inside the broch at Mousa

The underlying assumption here is that they can’t stop you, so they might as well make it safer.  They assume that you’re bright enough to realise that it’s risky particularly so in the wet or the winter, and that you have enough imagination to work out the consequences of breaking a leg on an uninhabited island. If not duffers, won’t fall.

Sign on the door of the Broch at Mousa

Second example:  we had a long chat about shipwrecks with the chap who was manning the Croft House Museum.  He had a practical interest in the subject because he’d been the last man to sound the foghorn at the light-house where we were staying.   We talked about the ferry that ran aground at Blackpool.  

The Blackpool Ferry - originally came to rest tilted at an angle but has now sunk on to its side

He simply could not understand why there were security guards around it.  If not duffers, won’t be crushed.  

Final example: the coolest level crossing in the world is where the road crosses the runway at Sumburgh airport.  There are lights, there is a bloke and a barrier but there’s nothing to stop you hanging a left and drag-racing.  If not duffers won’t burn up and down the runway as fast as your souped up Purgeot 206 will take you.

It would be easy to distract myself with a Daily Mail style rant about ‘elf an’ safety gorn mad, and it would be equally easy to speculate romantically that life on Shetland was so hard for so long that common sense is ingrained (the duffers presumably having been darwined out of the population) but that’s not really the point I’m making.

I am just going to note that if part of the role of the Business Analyst is to design lean systems that do just enough and no more, systems that are as simple as possible but no simpler, then Shetland is a living case study in how to do it.

Besides being a superb place for a holiday.

The Good, the Lean and the Ugly

My car was written off a few weeks ago.  The insurance claim made an ironic conterpoint to a Lean course I went on the same week.  

“Lean” isn’t an acronym, though it sounds like one.  It’s a description of how Toyota make their cars.  They don’t waste a thing: not time, not effort, and certainly not materials.  No fat: it’s all lean.  Lean is about a lot of things, but ultimately it’s about cutting out waste and making sure that each step in a process explicitly adds value for the customer.  

There’s a lot that I really like about Lean, for instance it assumes that the people who operate a process know more about it than anyone else.  Who’d have thunk?  

I don’t want to turn this into a whinge-fest about my insurance claim.  You’ve been there, you know what a nightmare it is if your car is totalled by three unknown lads in a stolen transit.  

However it seems entirely ludicrous that I ended up with the notes from 15 phone calls made to four different companies on my pad, and those were only the calls when there was something worth noting down. And why four companies? Why was I  the one co-ordinating the insurance claim itself, the legal claim for uninsured losses, the loss-adjustor’s valuation, the purported hire car while the claim was settled and the other purported hire car while the claim was settled?  Actually, that’s five companies, isn’t it?

Breathe in, two, three

Breathe out, two, three

Think of Calm Blue Light

It made an interesting case-study on the Lean Course, and I wonder if there is money to be made creating a “Lean and Mean” accreditation for organisations.  If an insurer could prove they had a Lean Claims Department, it would make me choose to use them.  

Just one phone call to sort out a claim?  Who wouldn’t go for that?

More on Lean: 

• The Machine that Changed the World – the original book on Lean published in the 1990s
• Wikipedia on Lean Manufacturing
• Wikipedia on Lean Software Production