Author: Daryl Chan

Is Business Analysis Undervalued?

Written by Daryl Chan on April 21, 2014. Posted in Articles.

Today I was talking to a friend about some cool work we’ve been doing recently around a “basics of BA capability uplift”, and were talking about the value of Business Analysis and Business Analysts here in Australia compared to overseas.

I offered the viewpoint that I felt Business Analysis is poorly understood and undervalued in general in Melbourne (my experience being mostly with large corporates). He agreed and compared it to his experience in Canada, where he did not find it to be the case.

What influenced my viewpoint? Well, the general attitudes I’ve experienced in my career as a Business Analyst, but more recently, some truly inspiring lines (spoiler alert: not at all inspiring) I’ve heard in the workplace recently, such as:

“So, what exactly does a business analyst do?”
“Just put the requirements into the BRD template, that’ll do.”
“I’ve taken my notes down as a mind map, and everyone else’s notes are quite linear. Ha, typical BAs!”
“The ideation stuff happens WAY before a BA gets involved.”
“Oh you don’t know how to do a PivotTable? Just give it to a BA to do.” (I think this one was my favourite.)

All the above of inspire certain feelings in me, some gentle, some a little more aggressive, but in general, something along the lines of below.

Communicating the value of business analysis

So why don’t people “get” business analysis and the role of a business analyst?

Well, I actually don’t think it’s down to the people who made the above statements. I think that their perception of business analysis is very much down to the way we (or we don’t) communicate what it is that Business Analysts do.
I believe that we need to take responsibility for communicating the value of the BA profession, firstly as individuals, and also as a community. (Side note: Kupe Kupersmith has recently written a great article here on a similar topic)

There’s a fine line though. Bear with me, I won’t suffocate you… yet. (via Cripplegate)

For instance, take a look at the some of the descriptions which have used to describe business analysis in the past. They’re all nice attempts, and whilst I don’t feel like they’re intrinsically incorrect, I also feel like they don’t adequately describe the full scope of what we can and actually do as BAs. They focus on the detail over the concept of Business Analysis.

Here’s a description which really hits the nail on the head for me though, and it’s straight from the good old IIBA website (and hopefully will be present in BABOK v3):

“Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.”

What’s different you say? The real beauty of this description is that each of the highlighted words come together in a dynamic, conceptual model, without a single mention of tools, techniques, “business and IT”, spreadsheets or Powerpoint.

Business Analysis Core Concepts Model

It’s called the Business Analysis Core Concepts Model. There is a fantastic article by Julian Sammy which goes into this model in more depth here. Make yourself a cup of coffee/tea/other caffeine mask before you start, but it is an intelligent, thoughtful, worthy read – here’s a quick summary:

Change: a controlled transformation of an organization
Solution: a specific way of satisfying a need in a context
Context: the part of the environment that encompasses the change
Value: the importance of something to a stakeholder in a context
Stakeholder: a group or individual with a relationship to the change or the solution
Need: a problem, opportunity or constraint with potential value to a stakeholder

Principles of Business Analysis

So whilst these core concepts articulate the areas we cover as Business Analysts, what is it that we actually do with regards to these concepts?

Laura Brandenburg has created this neat BA manifesto:

“Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve.”

Not bad right? It definitely resonated with myself and my colleagues as a call to action which sets a strong vision for Business Analysis. From this vision, we drew out four core principles which we believe best represents BA from an overarching point of view:

Bring stakeholders together
See the bigger picture
Facilitate shared understanding
Focus on what is valuable

I am sure there are many more principles (such as the ones suggested in Steve Blais’s article) which can apply, but we’ve decided for a less is more approach. Much like the law, I can’t remember every single rule out of the thousands which exist – but I certainly try live and abide by the principles those thousands of rules aim to serve.

Likewise, with these BA principles – no matter what tools or techniques we use, wherever we are in the product lifecycle, no matter how agile or rigid the environment is – they provide foundational beliefs which we can use to help organisations do better, and we can always link back to these and each of the six core concepts in every aspect of our work as Business Analysts.

This is how I see Business Analysis in my head, and in fact how we structured our recent capability uplift. Very keen to see how it’s depicted in BABOK v3.

How we might talk about Business Analysis in future

We feel that the combination of these two approaches set the scene for everything we do as Business Analysts. We believe it’s a succinct way of communicating the value of Business Analysis across the breadth of activities we can perform, but also hinting at the detail we can dive into when necessary.

Business Analysts can facilitate as much as we can set direction. We can help teams achieve business value as much as we can understand and communicate the ins and outs of a complex system. And we can sure as hell innovate whilst also being able to create super sexy spreadsheets which will knock people’s socks off- just as long as it’s valuable. Or brings stakeholders together by creating shared meaning. Or helps them see the bigger picture.

Do you even Excel, bro? (via Pixel77)

I’d love to hear your thoughts on the topic – do you have any thoughts on the questions below?

How would you describe the perception of Business Analysis in your community/country?
What do you think of the Core Concepts/Principles approach to describing Business Analysis?
What are you doing to communicate the value of our profession?

Until next time.
Daryl

Don’t forget to leave your comments below.

Making Friends with Ambiguity

Written by Daryl Chan on March 25, 2014. Posted in Articles.

Ambiguity is a good thing.

That may first sound counter-intuitive to everything you’ve learnt about Business Analysis to date. And it will be a mess if you don’t get the timing right. But with the right controls in place, a little ambiguity in your requirements can lead to more creative solutions, as well as empowering team members to truly make a difference.

Often we don’t realise that trying to “do the right thing” and providing as much detail as possible up front actually limits ongoing creativity. This applies to situations as simple as telling a developer to use a drop-down box based UI instead of telling them you want users to be able to access various functions all from the one screen; and as complicated as advising that a business implement Sharepoint instead of advising that they need to develop a collaboration and knowledge management strategy.

Courtesy of http://funnyfunks.com/wp-content/uploads/2013/11/funny-creativity-comics.jpg

The secret to being successfully ambiguous? Don’t substitute detail in place of clarity.

Less solution detail does not mean less solution clarity, if you centre conversations around VALUE, not just OUTPUT. You can facilitate everyone in imagining what value looks like – whether that be using tabs or accordion based UI in the simple example, or a wiki/Google Hangouts for the complicated scenario – and from there come up with solutions you didn’t even know were possible. And at the end of the day, you’re still going to get VALUE, just that the output itself may be a little different than what you were expecting.

(Side note: I feel like the BABOK here is a little bit ambiguous itself on the definition of solution requirements and indeed functional requirements, and not in a helpful way. I believe that behaviour and information the solution will manage is correct at a high level – but this should be separate from the lowest level of requirements – let’s call them technical requirements.)

This does NOT mean you can be lazy with collecting, writing and managing requirements. The responsibility for requirements still lies with you, as the business analyst – however it just means giving up a little bit more control over the solution in the early stages. After you’ve had the robust discussions about how to achieve value, then your next level of requirements breakdown should contain more detail and be less ambiguous. Then break it down again for the next level of detail, right all the way down to low-level testing. Make the decision to converge on detailed requirements only at the last responsible (or necessary) moment.

Courtesy of http://www.vmi.edu.vn/

This won’t work for every situation – you won’t be looking for as much creativity or empowerment in a Six Sigma environment, nor if you have strict regulatory requirements to follow.

If you find you’re getting push back on team members not actually giving input, just sitting around waiting to be told what to do – well, you might enjoy that if you love being a command and control type – but if you want a true shared outcome, set the context, roles and responsibilities clearly up front. Facilitating a kick-off session to discuss and investigate the environment in which the problem the team is trying to solve helps provide greater context and hopefully a greater sense of purpose rather than “we’re here just to do what they want”. RACIs are just one of the tools you may find helpful in that session.

Also, if you find you’re not getting the ongoing quality or speed that you desire, set shorter review cycle times. Set the tone that this freedom has to be balanced out – everyone has to back up their interpretation of the requirement with an MVP – whether that be a wireframe, working software, or good old pen and paper. But keep that balance between divergence and convergence.

So despite all the negative press, ambiguity is a powerful and useful thing to embrace. As long as you are disciplined with your focus on value, the tension ambiguity provides is a small step on the way to becoming more adaptive, a way to imagine more creative solutions and allow everyone to add their individual touch.

And that’s why ambiguity is a good thing. And a beautiful thing. Or an awesome thing.

Don’t forget to leave your comments below.