Am I a Business Analyst? What about those calling themselves BAs?

Send to Kindle


I attended and spoke at the Perth Business Analyst World Conference this week and really enjoyed it. This was a bit of a departure from the SharePoint events that I normally frequent, and I really didn’t know what to expect. Certainly, not having to fly 30+ hours just to speak is a big plus 🙂 The recommendation to the organisers to consider me, came about via Craig Brown, who has a very popular project management blog that I follow. Thanks so much Craig, I owe you a beer when I am in Melbourne next.


The conference report…

My talk was actually *not* about SharePoint and instead I was able to focus on more of my material on wicked problems, the shared understanding/shared commitment principle and then, the sense-making tools and techniques that I use to help bring this about. I was also able to demo the fruits of a very exciting, non IT project that I have been working on for a long time (more on that in a future post).

Despite my “This ain’t my normal crowd” trepidations, the feedback was great and the best thing to hear from participants, was that for many, it was stuff they have never heard before. That, for me, was really satisfying because I like the notion of presenting new ideas that actually have some decent practical examples to back them up. (This is something Andrew Woodward and I have in common. We love academic rigor for what we use, but it has to have been used in the real world with tangible success). Although I know that some people will disagree with the methods that myself and my colleagues use, I was able to demonstrate what I think is some pretty compelling case studies that support them.

What was interesting though, was that the examples and case studies were able to support what a lot of the other presenters had to say as well.

Ann Smith of Black Circle for example, had a great talk that was essentially about human cognition; essentially the wiring in our brains that serve to explain why big, fat documents are often not good ways to convey information. (Being a practicing dialogue mapper, no arguments from me there!) I am a nerd for this sort of stuff, having written previously on behavioural styles, learning styles and organisational culture, and Anne offered some new, interesting things that I have previously not considered or covered – more blog fodder for CleverWorkarounds, methinks.

Another highlight,the Western Power Business Transformation project, presented by Lorraine Pestell was also fascinating (I have a weakness for voice of the customer type sessions and this was no exception). Many of the strategic challenges that they are facing, such as sustainability and the changing business/regulatory environment, is very similar to the work I am doing elsewhere and it was great to see how Lorraine and her team were approaching the challenge and has given me some ideas and approaches to take back with me to my clients and projects.

The BA identity crisis

But back to the question suggested by the title of this post. There were some panel and round-table sessions about the topics of what actually *is* a BA, how you validate or recognise BA excellence, and the perennial BA versus PM turf-war debate.

Up until this time, I had actually never considered myself a BA because I had never actually given it any thought! As a self employed consultant, the only thing that matters is doing a good enough job to keep people wanting you to come back. So to that end, I didn’t worry so much about what I was called, provided that my clients were happy and the invoice was paid. But even if I wasn’t a consultant, I think that role titles often do not reflect reality and they also have a pigeonholing effect, depending on the attitudes and perceptions of what others think that role entails. Many position titles were discussed, “Solutions Architect”, “Business Architect”, “Change Manager” and some that were so pretentious that they bordered on wanky. More fancy words with no more clarity. No wonder many BA’s are struggling a bit for a sense of identity.

What I noticed when talking to the conference participants was that some attendees spoke from a lens where they seemed to feel that it was incumbent on them to provide a “translator” role between IT and “the business”. After all, nerds and CFO’s can’t communicate right? Enter the BA to ask questions and solve problems.

I have no major objection to that notion at some levels, but it is that *precise* mindset that makes me think “Well, I am definitely not a BA.”

Why? It was the notion that this “translation” was based on being the go-between from IT and the business. Thus, taking what one party says, transforming it and then passing it to the other party. As a result, BA’s are acting as a listener and interpreter, yet relaying second hand messages (messages that may be very different originally) between parties.

I personally balk at this. In fact, it really grates on me. By that definition, I don’t think I am a BA at all.

Interestingly, other topics of conversations were around “Well, how does a BA fit into Agile?”, “Is there a place for the BA in an Agile world”, and the like. What was interesting, and somewhat concerning, about these conversations was that those BAs who tended to think of themselves in terms of this “translation” role, really did not have a great grasp on the underlying principles of what we now call “Agile”.

Although Agile means a lot of different things and there are different sub-methods applied, these BAs got all focussed on the processes of Agile. They overlooked the fact that the process is actually the means to an end and it is the end-game that they have overlooked. Agile, (okay well Scrum anyway) attempts to use process and rigour (yes, rigour!) to make a project as conducive to shared understanding as possible. Probably the best thing that Agile does, above all else, is put diverse people in the same room. That alone will make bigger understanding breakthroughs than anything else!

Business Analyst KPI – shared understanding?

So, why am I not a BA?

My methods for translating are fundamentally inclusive. In other words, I do not “translate” anything, “take” it to another party and “relay” through my own words (and lens). I feel that despite all best intentions and whatever diagramming or modelling tool that you use, when you do this, you will always still find that you have your own cognitive biases that will not necessarily deliver the shared understanding that you think you are delivering. Instead, what I do is provide a rich container for a group to explore an issue together. In the same way that Agile tends to like all project members and stakeholders to be in the same room, Dialogue Mapping puts everyone in the same room and provides a suitable container for handling dialogue in a much better manner than traditional meetings and workshops.

If you agree with my previous assertions that a lot of the visible causes of project failure (scope creep, vague requirements, etc) comes from a lack of shared understanding among participants, and that BAs identify themselves as the bridge between IT and “the business” (which by the way is an insultingly gross simplification), then isn’t the ultimate KPI for the BA is to create and maintain that shared understanding? If not, yours is just another opinion that is counted no more or less than anybody else’s. Are you signal or noise?

So, in my humble opinion, the role of the BA is not to be the go-between from disparate stakeholders. Instead, it is your ability to create the sort of conducive holding environment that enables project participants to achieving shared understanding. How you do that is completely up to you of course, and if you have managed to progress a group from an agreed undesirable present state to a desirable future state, then your methods are totally validated.

Get over titles…

Now, if you call yourself a BA and think I am picking on you because you feel that you are the translator, don’t feel bad because plenty of PMs are guilty in their way too. In some ways, I feel that business analysts only exist as a career because enough people with the “Project Manager” title thought that time and budget alone were the only factors in project success. Some PMs who disagreed with this, felt that solving the problem was also critical, gravitated to the discipline of what we now label as “Business Analyst”. Some application developers that felt there was more to life than cutting code and made a similar gravitation. Put a bunch of like-minded people together and soon enough we have a “cool kids” club and lo’ and behold, we have a new discipline with a new set of titles.

(“Information architect” is a more recent example of this phenomenon than “Business Analyst”).

But, let me tell you something else about this title misconception. For a BA to label all PMs as interested only in time and budget is an insult to those PMs who actually understand that achieving and maintaining shared understanding is the end-game. The truly great project managers who I have had the pleasure of working with were actually leaders, not managers. They have all of the same characteristics of what makes a truly good business analyst: Critical thinking, soft-skills and most of all, a great radar for determining when stakeholders are not aligned and doing what is necessary to rectify the situation. They do not always dive into process and structure because their particular body of knowledge told them to. Instead, they have coffees, drink beer, conduct lunch-time workshops with free food and beverages, mediate, essentially whatever is needed to oil the cogs of dialogue that prevents something small becoming something nasty later.

By the way, I have met some angel application developers like this too, as well as infrastructure people.

If you want proof of a truly great project manager, then Kailash Awati’s wonderful site should be mandatory reading for both the BA and PM disciplines (and scrum masters too for that matter!). Kailash writes what essentially is a project management blog, but he has a deeper understanding of the sorts of soft factors that would put many BAs and some facilitators to shame.


In my talk at the conference, I emphasised that the ultimate success factor in any project is bringing about shared commitment through shared understanding among the participants. I believe that achieving these goals is the ultimate KPI for a BA, or anybody else who feels that they are there to help solve a problem, not deliver a crap solution that happens to be on time and on budget.

Thus, any method that helps a group achieve this is a good method because it has made a positive difference in advancing a group from understood present state to an understood desirable future state.

So, perhaps I am, after all, a BA?

Thanks for reading

Paul Culmsee

Print Friendly, PDF & Email
 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle
Bookmark the permalink.

12 Responses to Am I a Business Analyst? What about those calling themselves BAs?

  1. mark talbot says:

    Great post!

    I work as a PM and I never like to think of the PM role as someone who simply manages schedules and budgets. This is why in enjoy taking part in “BA activities” such as requirements gathering and AS-IS / TO-BE modeling. This allows one to really understand the business problem that the project is attempting to solve. Without that level of understanding, it’s hard to make the right PM decisions further into the project life cycle.

    All the best,

  2. Andrew says:

    Great post, I also see that sometimes the role of BA is created in an organisation becuase the management do not have the ability or vision to enable the stakeholders and technical people to be able to communicate. Often looking at the technical people as people who don’t need to talk to the customer becuase they need to be coding.

    The role of BA is valid, but as you so well put. Not as a translator doing the chinese whispers, but as a person who facilitates a shared understanding and shared committment.

  3. Kailash says:


    Excellent post. An advantage of working in a small dev shop (as I do at the moment) is that developers are generally required to do all the things that BAs do, and more. Developers who’ve worked in larger organisations may find this a bit unusual (and challenging) at first, but soon start to enjoy interacting with users.

    On a related note, formal interactions with end-users (such as requirements analysis sessions) offer a great opportunity to learn/practice dialogue mapping. Most folks understand the notation right away, and begin to see the benefits as the discussion progresses and the map starts to take shape.

    Thanks for the shout out and some very kind words!



  4. In my opinion as an interim programme manager the role of a business analyst is as a bridge between the business and technology in determining and translating requirements. I think this is demonstrated in the business analyst skills which are required to be a successful part of a project.

    So even though I hear so many job titles bandied about whether functional analyst, solution architect or even technology analyst they all in my book amount to the samething. Someone who can determine what the business want, and then translate that into something which can be delivered. And in Agile this is an even more important trait to have than even on a waterfall project.


    Susan de Sousa
    Site Editor

  5. Good post and interesting thoughts Paul.

    I have to say I use the title Business Analyst with my role at companies quite a bit and agree that many take different interpretations as to what the responsibility and roles a BA should play.

    I think this touches on a much larger, wider, and bigger (wicked?) problem that becomes more and more apparent the more global and broader organizations and individuals become. That is that roles, titles, and even functional areas/departments are never very clear.

    If you want some examples just imagine how many different titles an individual can have working with SharePoint. Now consider that each of these roles most likely has multiple names/titles available. Now take that one step further and think of the cultural and language complications of creating even more roles/perceptions of responsibility for those roles and subsequent titles.

    What we end up with is large corporate structures where we have to have hundreds of ‘relationships’ defined where one role relates to another in order for people to find the desired individual with the desired role. (Example: When I perform a people search at many international companies I might get seven different titles with the word Analyst, when I am really looking for an Architect.) Then there is the complication of the individuals experience with set roles, and the expectations they build for themselves around that role.

    Hence I think the solution (which the world seems to be moving towards) is not a focus on the role, but instead a focus on the skill sets of a role (or title). This results in some of the same issues: Requirements Gathering, Requirements Analysis, Requirements Definition, Solution Specification, Requirements Translation, etc. However since listing and keeping track of a skill set is in the domain and control of an individual (in almost all companies today) they can list ALL of those as skills they possess and get around many of the issues listed.

    The problem then (in my honest and humble opinion) is that the business ‘owns’ the title and since this is related (often, but not always) to pay rate and perceptions (as documented above) it cannot be moved to the individual. Skills however aren’t seen this way.

    Would love to hear your thoughts on this or talk with you more about it as I think it would make a very interesting and good discussion as to where we are moving as a society, economy, businesses, and people (most people feel their title represents who they are quite a bit).

    Self Titled Business Analyst with varied skills,
    Richard Harbridge

  6. P.S – Kailash’s blog is awesome. I second Paul’s nomination as something you should read. Yes you.

  7. admin says:

    Richard, I think that your reply nails it (and a really nice SharePoint intersect by the way :-). I felt, during the conference that the conversations were not necessary, but it is human nature I guess to want to put a name and box around a bunch of practices. It wasn’t till I was self employed before I really stopped worrying about what I was called.

    But I also suspect (and happy to be proven otherwise), that for some roles this is not a problem. Teachers and nurses is an obvious example, but also when I worked in mining, you had geologists, senior geologists, project geologists and exploration managers. That was the career progression for that particular vocation.

    So maybe, like there is tame or “technical” problems compared to wicked problems, there might be a similar type of parallel that can be drawn to roles.

    In terms of skills, what about this scenario? (I’ve been thinking about this too). Imagine that all IBIS maps are stored in SharePoint or somehow available via BDC or custom code to search. Imagine then being able to populate the user profile store, based on what topics or projects that you participated in. For example, if a particular person supplies a lot of idea (or answer) nodes, to a map (which is classified by metadata), that might indicate some skill or experience with the project or topic. That information should be stored in user profile and surfaced via people search.

    Thanks for your comments – much appreciated

  8. Really interesting idea Paul. In regards to the retrieval and surfacing of data from IBIS (or really any external collection of data) to provide better searching capability and relevance.

    The idea is interesting but I am going to try and take (what I believe) you are suggesting and try working through it here.

    Typically I would classify a project management system (which may even already exist in SharePoint) to be a good place to data mine that sort of information from task lists if they are designed and maintained effectively. Especially if user profiles have previous projects up to date (which is a field in user profiles by default).

    As an example: If I am given 50 tasks which are called “SIT Testing” then it could be assumed I have experience/skill with “SIT Testing”. So when we search for “SIT Testing” ‘by experience level’ it should return the person who has had the highest number of project tasks assigned based on the previous projects listed in their profile.

    The gap I see with this methodology/idea and the IBIS mapping one is that the relevancy/usefulness depends completely on how accurate the data represents the culture, individuals, and search methodology being employed. I believe this would be a very difficult thing to measure, identify, and plan for in most environments where (as suggested in this article) titles, skills, culture and nomenclature/terminology is constantly changing.

    Just some more food for thought on your idea.

    In terms of what is suggested by miners, teachers, nurses, etc that brings up a really good point. I believe this is shifting the opposite direction over time. These roles are well identified as a result of fairly standardized schooling, and industries. However if we look at education especially right now it is on the cusp of dramatic change (my opinion) as the current methodologies, processes, and scholarly institutions change the way they teach people. If we think about how fast technical information is growing (which aside from soft skills is the bread and butter of education) the current way in which we teach (over years in an immersed educational culture) will not be as effective as shorter, faster, and more selective training/knowledge building over time. What kind of impact will this have on standardized education (and subsequently standardized industries and standardized titles)?

    Next let’s make an assumption that over time more and more individuals will share more and more information creating a whole different style of learning which is self motivated and self evaluated (social driven learning). Further enforced by a growing number of people ‘hiring their bosses’ not having their bosses hire them (again my opinion of the future hiring process – LinkedIn is a good starting point for this?).

    The simple fact so many more people shift jobs/positions now than previously also adds greater complication. Since my ‘title’ might change multiple times it may also effect things like searching, and relevancy.

    All really interesting starting points for further discussion, analysis and thought. I appreciate your feedback and will have to think about all of this a bit more to try and work it out in my own mind.
    Richard Harbridge

  9. Pingback: Business Analyst or Information Architect? « Budding Business Analyst

  10. Nigel (Infrastructure Analyst) says:

    I work in IT within the broadcast industry.

    We techies think BA stands for Bullshit Artist or is statement of their knowledge level (Bugger All!)

  11. Pingback: We, the Business Analysts | Eric Provost .net

  12. Pingback: CleverWorkarounds » SharePoint Analysts–Stop analysing!

Leave a Reply

Your email address will not be published. Required fields are marked *