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 1 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
Aphra Behn - danger of eclectic shock 