1

Ask audience: Why do BA’s exist? Why has there been such a proliferation? Its becoming a field of expertise But why – what is the main value? Lowest order of BA skill: Bridge the gap (top level, taking notes, documenting, etc.) Second order of BA skill: Improve and innovate (deeper level – bring something Highest order of BA skill: Facilitate change (outcome of good BA is change, being the first point of change on the ground, often req.s is first time ppl understanding change) • Traditionally BA stands between business and IT. For the purposes of this school of thought, I’ll

call this the first order of BA capability. • BAs are not just about requirements. By the time a BA writes down a requirement they should’ve

challenged it and believe it is the best thing for the ambition of the project. • BA’s are not external to the process. You are not just a scribe. Anyone can be a scribe. Challenge.

Query. Be passionate and be involved. • It’s a difficult role. Too often we fall into the trap of being the scribe and communicator but the

challenge role is tough. • BAs should be positioned to improve and innovate. This means understanding what the

organisation is trying to achieve and bringing one’s experience to bear on the problem. • BAs are the first agents for change in an organisation.

Key point • 3 orders of Business Analysis

2

Think back on some of the conversations you have with BA colleagues. How often have you heard lines such as … • “We’re at end stage 2.” • “Of course it is supposed to work that way. It’s in the BRS.” • “The sub-process is instantiated by an ad hoc trigger event.”

Delve into the top level (i.e. translator / gap bridger). What are the fundamentals that need to be in place to be BA operating in the “bridge the gap” space? Why can’t we just speak English and write things down? In speaking analyst, we need to be able to communicate in a fashion that we know we’re being clearly understood. Day-to-day English is too fluid or prosaic for this. If I talk about SCRUM or Prince2 to people in this room, you’ll know I’m talking about agile software development or project governance rather than rugby or Prince William. Sometimes we can take it too far. But there is a reality – complex systems are complex. We need a way to explain them to our stakeholder groups in a consistent and meaningful fashion. We need our own language to be able to effectively communicate in a meaningful fashion – the language of “analyst”. I imagine that this audience is largely bought into this. To be effective, we have to be fluent. At the top level of BA practice, you can probably stumble through. But you’re just being a glorified scribe. If all of your cognitive attention goes to this then you won’t be able to apply your mind to innovation or change. What is the likelihood that this sub-language intimidates our business community? Or IT community? The words sound smart but making something complex sound smart is nowhere near as difficult as making something complex sound simple. And nowhere near as productive. Differentiating ourselves by talking in code only undermines our role as communicators. Speaking analyst fluently means knowing when to speak in simple language and when to speak in hifalutin language. Key point • In order to be successful as a “bridge the gap” BA, need to be able to use the language of analyst.

3

We’ve talked about the notion of a language. What about its constructs? Ask audience: What do you think makes up the language of analyst? It is important to recognise that analyst comes in dialects. Different communication needs call for different dialects. Different situations call for different dialects. A successful BA needs to be a bit of a poly-linguist in respect of dialects. It may even be necessary to establish a dialect of analyst, if that’s realistic (e.g. UML). Even operating efficiently at level 1 requires ability to fluently speak analyst in day-to-day conversations. And, like English (or any other language), in different contexts the flavour of the language will be different. This will be determined by the intention of the interaction, the level of sophistication of the audience, etc. Key point • Language of analyst has many aspects / dialects and need to be fluent as to what to apply when

So, given that we’re passionate about analyst, I want to talk a bit more about it to share some of the reasons why it is interesting.

4

Take 2 minutes to read this.

5

And again, take a few minutes to consider this. They’re obviously representations of the same thing. Tell me about the two representations you’ve seen. With a page of text, I can’t… • apply a lens • create a scope boundary • consider a single dimension • apply a design pattern

So you cannot really “analyse” a page of text, although contextual meaning should not be lost as well. Key point • In order to operate at level 2 (innovator), need to be able to use the language of analyst to

identify problems / opportunities

6

Analysis is an interesting language. And a language that evolved. These are just a few examples. Here some examples (1) UML has been improved to help reduce ambiguity (2) Our practice has evolved to reduce tautology (3) In different circumstances, you could notate the same thing differently depending on what

you’re looking to achieve. Drive home a point that there is a language. It is interesting. Intellectually interesting. This stuff is not just made up as you go. Need to be aware of continual evolution. Also, an interesting aside – note that there is a degree of art in determining when it is necessary to analyse to the nth degree of detail and when that level of detail may not be necessary. Key point • Analyst is an interesting intellectual concept. • Need to be selectively descriptive not universally prescriptive

7

Ask audience: Why bother? To operate at level 2, improving and innovating, it is necessary to do some analytical work. We need to be able to break things down, understand them at component level and build them up again. • Identifying patterns • Reducing complexity • Using different lenses to ask and answer different questions Lenses • Technology landscape view • Data requirements view • Etc. Yes – it’s about breaking something down to understand its essential features and their relationships. Speaking analyst is just like speaking any other language. The ability to write beautiful prose is an art, not a science. The difference between a great analyst and a poor analyst is knowing when to delve down into the detail and when to work in abstractions. It is not just permitted to be selectively descriptive, it is essential. Modern projects can’t sustain detailed process models, use cases, wireframes and requirements on every single business process. Example … Angel Trains story (not analysing everything). It’s okay not to be a slave to your methodology, but it’s not okay to communicate badly.

8

Ask audience: When should we be speaking analyst? The short answer is always. If you want to operate at the 3rd order of BA, you need to be working all the time to bring people with you. A reminder – the 3rd order is about being a proactive agent of change. Of course, need to be aware of when speaking to which people. To be a change agent, can’t confuse people, need to bring people along. If you are not selectively descriptive, lose the change element because all energy is focusing on covering ground rather than thinking about benefits to be achieved and focused We want to be agents of change. My ambition is that BAs are at the vanguard of change for the organisations we work in. Not as renegades, but as the vehicle through which we help our organisations translate their why (their ambition) into a how and a what. In order to do this, we need to always be communicating effectively. When shouldn’t we be speaking analyst? When wouldn’t we speak analyst? Key point • Using analytical method should be something we always do as part of developing purposeful

practice

9

Many years ago we took on a new client and they had many of the initial meeting in Afrikaans. Now I sort of knew what was going on, but only sort of. It wasn’t productive and it was a waste of time. I was barely able to provide insight because I was focusing so hard on understanding the conversation. They were getting limited benefit for my time because at best I could write down requirements. Thankfully we spoke up about the situation to our project leader and changed meetings to English (which was the business language of the client anyway). To have the right to play … conversational fluency is not good enough, you need to be unconsciously competent. You can’t stand at a whiteboard and wonder about joins v merges. You need to be able to keep up with the flow of conversation. Innovation requires the ability to (1) break things down into a structured fashion (speaking analyst) and (2) providing insight against the analysis which improves the matter at hand. To be a change agent this capability must come naturally. My vision for our profession is that we are the ones who drive change in our organisations. Being a scribe is not good enough. It was a perilous business model in the first place and with better technical understanding in our stakeholder communities it’s not enough to warrant our existence. Acting as an innovator is a great leap forward. Our ability to apply lenses to the problem help us identify opportunities for our organisations to improve. But the real action happens when we can make change happen. If we’re seen as the “go-to community” to design and implement change, then we will be much better placed to influence our organisations. And that’s a much more interesting place to be than writing requirements documents. Key points Analysis is art. Art requires method. Application of method requires purposeful practice.

10