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.

1. 1

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

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

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

5. Take 2 minutes to read this.
5

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

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

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

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

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