Business Analyst or Subject Matter Expert?

I took part at a fascinating debate at a recent IIBA event.  The debate focussed on the distinction between a Business Analyst (BA) and a Subject Matter Expert (SME), and the extent that the BA should “learn” the business.

There is an ongoing debate within the BA community over the level of industry (business domain) specific knowledge that a BA should be expected to have.   Some organisations require their BAs to have extensive business domain knowledge, and will generally only recruit BAs who have worked in the same (or a very similar) industry.  Others look for core analysis skills, and are happy to recruit BAs from completely different industries.

My view is that while business domain knowledge does matter, analysis skills and experience are far more important. It is certainly important to have a basic understanding of the industry in which you are working, as this helps you to know which questions to ask when starting a project.  However,  this knowledge is something that can be expanded upon over time as you gain exposure to more and more projects.  In fact, in my experience, new BAs from outside industries are often able to add a huge amount of value by “questioning” standard industry norms and conventions, and adding a new focus on true objectivity.

To draw an analogy, I view core Business Analysis work as a bit like driving a car.  You learn a core set of techniques up-front, and learn even more when you apply them in all sorts of terrains and adverse conditions.  You learn to be creative and use different tools and techniques when need to get a particular result.

Changing industries as a BA is a little like driving in an unfamilliar country.  You need to know the basic rules of the road and you need a map.  But once you have these things, you can drive as effectively and efficiently as you could back home (using all or most of the same techniques).

Driving is driving. Analysis is analysis. In both cases you need a map of the landscape, and you need to read the map before you set out. However you don’t need to understand the mechanics of the engine at the outset – and if you do eventually need to know this there will hopefully be a mechanic (SME) to help you!

However, I do believe that there are a number of core skills above and beyond the benchmark BA competencies that are of particular relevance when changing industries or projects:

1. Learning how to Learn: I believe that one of the core skills that a BA needs is “Learning how to learn”.  This is barely talked about within the BA community, but from personal experience I believe it is so important and it is a key differentiating factor.  A good BA needs to be able to pick up new project work quickly, and this will involve doing self-driven research.   The ability to very quickly assimilate the relevant facts from Google, Wikipedia and other more industry-specific sources is as much art as science!

2. Knowing which questions to ask: Another core skill is knowing which questions to ask. As analysts, we uncover the detail and the ‘tacit knowledge’ that has never been written down. We question the semantics, we ask people to explain exactly what they mean when they say “the item is processed“. Being new to the organisation may actually help here; a ‘fresh pair of eyes’ may help to see a new perspective on things. This helps us to challenge old ways of doing things, and get to the root ‘problem’ (rather than focussing on ’solutions’).

3. Stakeholder Analysis & Management: When entering a new company, project or industry it is especially important to actively analyse and manage stakeholders.   It’s important to understand their level of interest and influence on the project, and also their expectations.  It’s also key to understand their motivation; are they likely to be a keen supporter of your project, or will they need some convincing?  I could talk about stakeholder management for hours – perhaps I’ll write a follow-up blog!

What are your views on the BA vs SME debate?  I’d love to hear from you, please feel free to add a comment to this post, or contact me directly!



Further Reading:

If you my blog post interesting, you might also be interested in the following article, published by Barbara at B2B training : Blog – When do you learn the business?

http://www.b2ttraining.com/2010/04/06/when-do-you-learn-the-business/

“I want that one”: Helping project stakeholders to define the problem (rather than the solution)

I believe that one of the most important success factors in just about any project is having a shared understanding of the “problem” that needs to be solved.  Once the problem has been clearly defined, it is much easier to define the scope of the project (and far easier to analyse, define and prioritise requirements).

The trouble is that not all business stakeholders think in this way.  Business stakeholders will often focus on the solution first .  This is completely understandable – after all the “solution” is something tangible, you can see it and touch it.  The “problem” is something abstract and often invisible.

Take this theoretical example:

“We are receiving an increased volume of complaints, and our current complaints system cannot keep up.  We need a more efficient complaints case-handling system, which can report on (and enforce) strict Service Level Agreements to ensure we respond to our customers quicker.   I have seen that xyz systems incorporated offer an off-the-shelf system. We’re going to initiate a project to implement that system…..”

This statement focuses on the solution (a more efficient claims handling system) rather than the problem (an increase in complaints).  In this hypothetical example, a more efficient and effective solution might be to re-train staff, or to re-engineer specific business processes so that there aren’t so many complaints in the first place!

As Business Analysts, we can add a great deal of value in projects by professionally challenging our stakeholders, and working with them to define the problem.  Here are some quick tips that might help:

1. Define the problem (or opportunity) at the outset: Work with key stakeholders to formulate a “problem statement”.  This needn’t be more than a few paragraphs, but it should clearly and unambiguously define what needs to change.   Ideally it should also include a list of key success factors – these will help to measure the success of the project, and can help to guide the high level requirements.  If the project is looking to exploit a new market opportunity, then you might want to refer to this as an “opportunity statement”

2. Ask questions: “Why” and “How”: Remember that the problem that is initially presented to you might be the tip of the iceberg.  Keep delving; ask lots of open questions.  Why, How, What, What if.   If you have the time, a workshop can be an effective way of achieving this.  Try to incorporate the views of a wide range of stakeholders, not just your sponsor.  Remember, operational business users who are “closer to the ground” may be able to uncover essential detail about the problem or opportunity.

3. Check for constraints (real and imaginary): There may well be real constraints that need to be met.  For example, if there is a regulatory change that needs to be implemented by 1st January, then this may well impact on the solution and it is worth documenting these constraints at the outset.  However, it is worth challenging all constraints – people often state constraints which could be unintentionally misleading.  For example:  “We need to increase efficiency through automation” when clearly automation isn’t the only way to increase efficiency.  Challenging these constraints earlier in the project lifecycle is likely to make your job as a BA easier!

4. Reign people in: Use the rapport you have with your stakeholders to “reign them in” when necessary.  For example : “That’s a totally valid point, but I think we’ve stepped into the solution domain here… can you remind me of the business problem that we need to solve?”.

Challenging stakeholders in this way gets easier over time, particularly as your organisation learns the true value that robust Business Analysis brings.  It’s a great way to get people thinking, and to ensure that your project has the best possible chance of delivering the required benefits for your stakeholders and clients!

Do you have any top tips for keeping people’s focus on the problem, rather than the solution?  I’d love to hear from you, so feel free to reply to this blog post!

7 things I wish I’d known when I started my BA career

One of the great things about the Business Analysis profession is that all of us have different backgrounds. I made a number of career moves before I became a BA, and I have never looked back (!)

I’ve been working as a BA for a fair few years now. However, it strikes me that when I started out, I had some rather naïve misconceptions over what the job would entail. I thought I would share these with you in this slightly light-hearted post. Did you find the same?

1. Not all business people understand the value of a BA: Strange, I know, but I was genuinely surprised to find that some business people don’t understand the BA role (or where it adds value). This was an extremely sharp learning curve, and I learned the importance of  reputation management and self promotion.

2. Business decisions are often made on emotion : It doesn’t matter how tentative the business case, in some organisations if a charismatic executive has a pet project, it might just fly.  As  a  Business Analyst, the challenge is to inform the decision making process and ensure that both logic and emotion are considered.

3. Good Project Managers like being challenged: Some BAs find PMs intimidating, but my experience is that good PMs are open to challenge. If a deadline is unrealistic, it’s better that they know in advance.

4. It’s OK to be unpopular: A controversial point, but BAs won’t always be popular with everyone! In my view, Integrity is much more important than popularity.

5. Stakeholder Analysis is more important than anyone admits: It’s absolutely essential that you know who to talk to, and when to engage them. Whether formal or informal, Stakeholder Management might just save your project.

6. Continuing Professional Development makes you stand out : Professional development gives you “the edge” and significantly increases your credibility. And it doesn’t have to be provided by an employer, it is something that can be sought out by an individual.

7. The concept of “The Business” as a single entity is misconceived: Any organisation is actually a group of stakeholders, and they may well have differing or conflicting views.

I’d be interested to hear your views. What do you wish you knew when you were just starting out?

This article was originally published by Adrian Reed on Pragnalysis.com, a site dedicated to Business Analysis in the real world, and more importantly, home to an entirely free requirements toolkit.

BA Skillset : Refresh the lost art of ‘networking’!

In recent times, there has been a renewed focus on Stakeholder Management during business change projects.  Formal Stakeholder Management helps to ensure that expectations are managed, and conflict is addressed.  With this renewed focus on formal management techniques, it’s easy to forget the value of your informal network of colleagues, suppliers, friends and associates.

Your network is there to support you, and you are in a great position to help them. As a Business Analyst, It’s great to expand your network as widely as possible – both within your organisation and beyond.  Your network can help you solve problems, and can provide you with advice and guidance (after all, you’d do the same for them, right?). It’s often the case that information cascades through informal networks far quicker than through any formal methods.  These chance encounters could lead you to discover synergies between projects, hear of new opportunities, or maybe even get your next job (!)

So how do you expand your network?   This is especially challenging given that “Networking” sounds scary.  It often brings back memories of ill-fated cocktail parties, or Champagne-and-canapés product launches.  The reality is that it doesn’t have to be that way – any place, event or situation when you are meeting new people (or building relationships with existing colleagues) is an opportunity to expand your network.  That includes the queue for the coffee machine!

So why not spend a little extra time at the coffee machine next time.  Who knows what information you might find, or who you might be able to help.

If you’re serious about expanding your network, here are 4 “quick tips”:

1. Take the opportunity to exchange details: Make sure you make the most of any potential networking opportunity open to you, and exchange details.  This could be a training course where you’ll meet other delegates, or even an internal meeting.  If appropriate, make sure you have a good supply of business cards ready.  Follow up the next day with an e-mail.

2. Run your own mini-CRM system: It needn’t be complicated, but keep track of who you have met.  Perhaps keep a file of business cards, or update your Outlook address book.

3. Stay in touch: Make a point of staying in touch with people.  Perhaps go out to lunch once a quarter, or catch up for coffee.  Find out what they’re up to, and share your experiences.  Find out how you can help each other!

4. Join a networking group: One of the best ways to meet new people is to join a networking group.  The IIBA would be a good start, but also consider general business networking groups in your area.  Try googling ‘Chamber of Commerce’,  ‘JCI’  and ‘BNI’ for starters.

Do you consciously “network”?  If so, what are your experiences?

This article was originally published by Adrian Reed on Pragnalysis.com, a site dedicated to Business Analysis in the real world, and more importantly, home to an entirely free requirements toolkit.

Requirement Prioritisation: 3 quick tips

As Business Analysts, we deal with requirements prioritisation nearly every day.  Prioritising requirements is an excellent way of ‘drilling down’ and understanding the real critical success factors which apply to your project, and it’s a great way to help with scoping.

The trouble is that stakeholders are often incredibly bad at prioritising.  This is one area where we can add a huge amount of value, by clarifying and facilitating their thoughts.

Much has been written about prioritisation, however here are 3 “Quick Tips” that I find personally useful whenever I’m working to prioritise requirements.

1. Flip the “But”: A great way to ‘test’ the relative priority of a requirement is to look out for the word but when a stakeholder is talking about their needs. For example, a stakeholder might say something like:

“It would be incredibly beneficial for xyz document to be made available to our staff in Singapore, but it’s likely to be extremely expensive”

At first glance, this sounds like a low priority requirement and you could certainly be forgiven for categorising it as such!  However, in this example, the priority will actually depend on the stakeholder’s appetite for budget. A great way to test this is to ‘flip the but’ and play the sentence back.

“Ok, are you saying that it’s likely to be expensive but you’d like the xyz document available in Singapore?  Or are you telling me that this is a low priority requirement?”

This will give you a good feeling for their attitude towards the requirement.

2. Check the consequence/benefits: Ask your stakeholders what would happen if this requirement wasn’t included in the final implementation. What would the impact be?  Would it reduce sales, increase processing time?

On the flip side, what are the benefits of including this requirement? Even a high-level understanding of these consequences can be incredibly useful when prioritising.  Clearly, those requirements that have most benefit (or most impact) should be the highest priority, providing these contribute towards the objectives of the project.

3. Have a plan for Medium/Low requirements: We’ve all seen projects that are de-scoped to an inch of their lives, where only the “highest” priority requirements are delivered.  This is totally understandable, but in some cases it might leave operational stakeholders with an extremely sour taste in their mouth!

If you can, always consider having a plan for Medium/Low requirements (e.g. will they be implemented in phase 2, or perhaps stored in a ‘wish list’ for future developments?).  By sharing this with your stakeholders it can help avoid the temptation for all requirements to be stated as “Essential” (as they are fearful that any other requirements won’t be delivered!).

There are many other tools and techniques that can help when prioritising, but these are three that I have used time and time again.  I hope that you will find them useful!

Do you have any ‘favourite’ tools or techniques?  If so, please share them by responding to this post!

This article was originally published by Adrian Reed on Pragnalysis.com, a site dedicated to Business Analysis in the real world, and more importantly, home to an entirely free requirements toolkit.

7 Questions to help beat the “Truth Trap”

There are some things that are so obvious that everyone knows them.  These are the things that people talk about on busses, trains and in cafes.  Nobody questions them because they are common sense. Everybody is certain that these “truths” are correct.

The trouble is that people can be wrong.

The “truths” on which people form their strongly held views might be out of date, inaccurate or no longer applicable.   The same thing happens in organisations  and projects. How many times have you heard someone say “that would just never work here”

Innovation may require the challenging or re-writing of “truths”

Innovation often requires a paradigm shift.  It might be uncomfortable, but also  necessary for a project to question  or even reverse “truths” that have been in place for years.

As Business Analysts, we have a real opportunity to challenge these truths using open questions.  Here are a few of my favourites (!):

1. “Are you certain that is true – has it been proved? Or is it an assumption?”
2. “Can you tell me why this solution wouldn’t be appropriate?”
3. “What would have to change for this to work?”
4. “If we were designing this [widget] from scratch, how would it look?”
5. “If we were forming a brand new company, how would we approach this?”
6. “How do our competitors approach this?”
7. “If we were in an ideal world, with no constraints, how would we approach this?”

Ultimately, innovation needs “buy in” from all levels of the organisation.  Robust Business Analysis will help organisations to make sure that they challenge the norm and pick the winning projects.  However an excellent communication & engagement plan will be needed to ensure that people are on board.

Innovative projects aren’t easy, but they are necessary to survive.