One thing that I’m confident that readers of this site will agree on is that good quality business analysis can add significant value throughout a project’s lifecycle. But let me ask you a question. Have you ever found that some stakeholders just don’t “get” business analysis? They just want to implement a tactical, messy solution without really understanding the root cause, business need or opportunity?
Have you ever heard stakeholders say things like:
“We don’t have time for up-front enterprise analysis… we just need to get going!”
“Why do I need requirements? It’s simple – I just want xyz system. That’s my requirement. Now go deliver it, by next Tuesday please.”
“Why do we need to understand the ‘as is’ system – surely we can just worry about the changes?”
“Why do you keep asking me about business goals and objectives? That’s not for you to worry about.”
If you haven’t ever heard sentiments of this type, I am extremely jealous! I know from my work with organizations and BA practitioners in the UK, that misunderstanding, and in some cases resistance against the BA role does occur. Sometimes it feels like they don’t really want a BA at all.
As a community, it’s easy to blame the stakeholders for misunderstanding the BA role. “Those annoying stakeholders… why don’t they understand the benefits that structured change and analysis can bring to them?” However, I think it’s time for us as a community to turn the conversation around.
A Challenge: The Cocktail Party Test
One of the challenges we face in articulating the value we add can be illustrated with what I call the “cocktail party test”. Imagine you’re being introduced to a new friend at a party – someone you’ve not met before. They don’t work in business change, in fact they’ve never worked in a project environment at all. Perhaps they’re a chef or a baker. Imagine you tell them that you’re a business analyst—and you’re met with a blank stare. Followed by the question: “What does that mean?”
How would you explain your role to them? Take a moment to consider this before reading further.
This is what some people describe as an “elevator pitch”, and many BAs (myself included) find it incredibly difficult to succinctly and meaningfully describe the role and the BA value proposition. What we do is so broad—we work on projects from conception to realisation—and it’s hard to cut down the essence into a single, snappy sentence. Particularly to someone whose role is outside of business change.
It’s like there’s a brick wall…
Add into the mix that if you ask 50 different BAs to describe the role, you’ll get 50 different descriptions, all of which are probably perfectly correct. There will undoubtedly be some areas of controversy; what counts as “systems analysis” or “design” varies between organizational contexts. So, if as a community of analysts we can’t agree on a succinctly and useful definition of our role, no wonder our stakeholders are confused!
You may ask “why does this matter?” History is littered with expensive project failures… and we know that good quality business analysis (along with our change colleagues – project managers, architects etc.) can avoid this. But, sometimes it feels like there’s a brick wall between us and our stakeholders. We know that we can help them so much… if only they’d engage us earlier. If only they’d let us help them before key design decisions were made. But they don’t yet know the breadth of problems we can solve for them.
The million dollar question:
So my final question: Does anyone ever really want a BA anyway? Or a project manager for that matter, or an architect? Controversially, I think the answer is no. To draw on the commonly quoted cliché… people don’t buy drills because they want a drill. They buy a drill because they want a hole in the wall. In the same way, people engage BAs and other change professionals because they want effective business change that delivers business and customer value. Sounds obvious, right?
However, this provides a useful lens to break down the brick wall of misunderstanding. When we’re faced with scepticism, we need to break it down – brick by brick – by explaining and demonstrating how we add value in the context of the change that the business needs and wants. Then, we need to faithfully deliver that change.
We can’t bulldoze down the brick wall, but through reliable and consistent delivery, mixed with superior stakeholder management and marketing, we can nibble it away—a brick at a time… leading to better quality earlier engagement and better quality project and business outcomes.
Hi Adrian. Another great piece! I’ve been thinking about this topic a fair bit lately…
Personally, I feel that stakeholders don’t always appreciate the value that a business analyst adds. This is why they struggle to accept them into a role.
I feel that one contributor to this, is that the role of the BA has been ill-defined in the past. As a result, their value has come under scrutiny. I admit that this is only one factor, but it seems that any specialist-type role, where a deep understanding of a subject matter has been developed, has been dubbed ‘business analyst’. Consequently, the BA role has been bench-marked against the skills, capabilities and outputs of a pseudo-BA role, rather than that of a fully skilled one.
The two roles are assumed to serve the same purpose, but this is simply not the case. BAs need to be kitted with the requisite skills and knowledge to perform a job effectively. These are not skills that naturally come with a specialist-type role. That’s not so say that specialists make bad BAs. They only make bad BAs when they don’t acknowledge, understand and apply the correct BA skillset.
I’d appreciate your thoughts on this.
Regards,
Nik
Adrian,
Since this article was published, I am noticing more and more IT consulting companies creating BA positions, and clients of such firms *demanding* that BAs are assigned to their projects. I actually started to think that the title of this article, “The Tough Truth: Your Stakeholders Don’t Want a BA” is wrong (even if the article’s content is correct).
I think a better title would be “The Tough Truth: You May Meet With Resistance if Joining an Organization Who never Experienced Solid Business Analysis Work Before”.
I see project managers and product owners in the companies I consult for look at the projects that have a solid BA assigned to them, realize how much smoother things are in these projects, and immediately put a request for a BA for their initiatives as well.
More and more I get convinced that the only stakeholders who don’t want a BA are the ones who never had a solid BA help with their projects. The first time they have this experience, they immediately see the value, and don’t want to go back to the old ways of projects without a BA.
In my experience, stakeholders can be tough and demand that an underperforming BA is replaced in a matter of weeks (especially they are using a third-party provider and thus have the prerogative to ask for team changes any time). But I get weekly calls from recruiters, consulting firms, and large companies, asking if I have a BA to recommend for one of their openings. Getting a talented BA allocated to projects has become one of the top priorities of executives and delivery managers I speak to, which is good news for BAs who put effort into developing their analytical and communication skills.
Hi Ron,
You raise a good question about apprenticeships. The short answer is no, I’ve not seen this model very much in the BA world. In fact, I meet a lot of people who want to make the transition into a BA role, but are finding this difficult (as even ‘entry level’ BA jobs tend to ask for prior experience). It’s a bit of a cliche, but many BAs “fall into” the role — i.e. they do business analysis before they *know* what business analysis is! I am one of those BAs — I was working in a business doing BA work long before I knew what the role was. Then, as part of an organisational restructure, this new & exciting role “BA” was created!!
Some organisations do employ ‘Junior BAs’ — and there is an element of “apprenticeship” behind this — however these tend to be the exception. My view is this has to change — purely from a succession management perspective. I predict more JBA roles in the future. However, this is a personal opinion, based on nothing more than “gut feel” 🙂
I have seen an “apprenticeship” type scheme in some organisations as part of their graduate programme — e.g. the grads from university tend to “rotate”, and then perhaps choose business analysis after getting exposure to the whole organisation, at which time they’ll start to gain more experience and exposure.
Kind regards,
Adrian.
PS – No, I’m not near Scarborough — I’m about 300 miles South, down on the South coast 🙂
Thank you Adrian!
As always, most valuable feedback. Greatly appreciate it!
I concur with your view on apprenticeships as a needed professional development. Perhaps the IIBA will take up a lead role in that regard.
So, it looks like many of us in transition have quite the challenge ahead of us, indeed.
Best Regards,
~Ron
Thank you Adrian for the clarification with respect to ‘BA practices’. While I look forward to your and anyone else’s further thoughts on the challenge point that you have prudently raised, your answer also sparked another question- How common or prevalent are BA consultancy firms?
Thank you.
Ron,
You are most welcome! This is a very interesting discussion.
Certainly, here in the UK there are consultancy firms that specialise in business analysis. However, I would widen the definition somewhat — I’d say that *most* consulting firms are doing (at least an element) of business analysis.
In fact, in many ways, a BA is an “internal consultant” (in fact, this is partly how the role is described in the classic BA book “Business Analysis” by D.Paul, J.Cadle, D.Yeats et al). In fact, my job title is “Principal Consultant” — but that’s only because I work for a consultancy. If I was carrying out the same work internally, I’d be called a BA! I certainly consider myself to be a BA.
I hope this helps — Adrian.
Thank you Adrian for this insight, and for the reference to the book!
In the context of prevalence, I wonder if there is a difference between the UK (or mainland western Europe for that matter) and North America in the proportionality of consultancy firms in comparison to corporations that purposely staff BAs.
Knowing such information would be particularly helpful for those professionals domiciled in North America, who are of European extraction, can speak one or more languages beyond English, and are open to good opportunities abroad.
I know I get quizzical looks and shrugs of shoulders whenever I have asked North American BAs whether any among them knows of any apprenticeship practice opportunities (not unpaid internship) ever being offered. Since the apprenticeship-journeyman-master system is still very much a European model, are you aware of BA apprenticeships in the UK and/or in western Europe?
Thank you for your time invested in contemplating and responding to these topics (it would be nice to hear from others too, to take some of the load off your shoulders, my friend).
Cheers,
Ron Werda
P.S.- Are you near Scarborough by chance?
Thanks Adrian, Adriana, and Shailaja for your inputs.
Really helped, Shall share my experince when exposed to new domains.
Cheers, thanks once again to all.
I agree with Adriana Beal… For a BA, it is not important to have domain specific knowledge all the time. It is almost very difficult to gather domain knowledge when there are so many different domains out there. However, with that being said, we can always do better with some research, and a SME in our current job. And our deliverables remain the same or in-line with a generic BA role. Over time, we will be add value to the business until we find a different domain to work on. I have been working with various clients in various domains – real estate, financial, banking and now manufacturing. Domain experience has not been a block so far! As a BA, we just have to do our best with what resources are available to us.
In my opinion, I actually think it is interesting, challenging and a great learning experience to work in different domain with no prior experience. I think it will expand our analytical skills and go beyond our capabilities while delivering the requirements – making us think out of the box. 🙂 Cheers! Good luck.. I hope this was helpful..
Ravi, here goes my opinion, and let’s see what others have to say.
No, a BA doesn’t have to be attached to a particular domain. Yes, you need to learn about the business domain you are serving — getting to understand their processes, policies, systems used to support their tasks, user profiles, and so on. But you can be highly successful (for example, in an IT project), starting off without much knowledge of the particular business domain.
Right now, I’m working for the first time in healthcare, and being very successful in my role. Prior to that I worked in the financial industry (in domains that were very different among themselves — from trading to loan syndication and Internet Banking). I’ve also successfully delivered requirements for projects in in B2C ecommerce, knowledge marketplace, start-up targeting restaurant owners, and many other fields I had no prior experience with.
What is important is to be able to differentiate things that are common across domains and things that work differently even within the same domain. For example, information security is important both in financial and healthcare (even though the compliance issues are sometimes different, the same technical principles apply). And ecommerce for B2C has different implications than for B2B relative to number and volume of monthly orders and fulfillment process.
The more exposure you have to different domains, the more comfortable you become managing the requirements in different domains. Even if you are working in the same business domain, when you switch companies you need to “relearn” plenty of things, as processes and policies can be very different among companies. A good BA will partner with SMEs to develop reasonable knowledge about the business domain while contributing to the project by applying business analysis techniques to identify project stakeholders, elicit information, elaborate and model requirements, and so on.
Its was a good read also the comments by other experts.
Also have few queries.
Do BA has to be attached to a particular domain?. for eg. i’m from P&C insurance domain, its hard for me to add value without the knowledge of P&C. also, I’ve worked in non insurance project. However, i designed the application only as per the requirement without any value add. i wasn’t able to get in detials. all that i did is designed as per common sense. how does it work in long term.
Can a BA not be from a particular domain and still can be successful in talking to business and solution team. and add value to the deliverables?
Thanks..
Hi Ravi, I agree with Adriana and Shailaja on this. Here are my views:
In my view, a BA *does not* require in-depth domain expertise. However they need the ability and skill to quickly gain *enough* knowledge of the domain, terminology etc without wasting stakeholder time. Many BAs move between domains quite successfully — I have done so throughout my career. Background research, networking and fact-finding skills become important. It’s essential to do enough background research to be credible.
I draw a simple analogy here. If you hired a painter and decorator to paint your house, would you ask him/her “Have you ever painted in blue before”?
Probably not. Painting a wall is painting a wall. Some walls might have different characteristics — if you’re painting a house built in 1900, the plaster might be loose — but a good painter and decorator will assess this when they get there.
The same is true of a good BA. Elicitation is elicitation. Business process modelling is business process modelling. Yes, the territory may be different — but that is where the skill of a good BA comes in. Actually, I’ve found moving between domains beneficial in itself — you are able to refer your knowledge of best practice in one domain to another. And the more I’ve moved between domains, the better I’ve become at getting up to speed quickly.
A good BA quickly gets up to speed in a domain through research. The key is knowing *enough*. Remember — however I think it’s important to draw a distinction here. A BA isn’t an SME, and an SME isn’t a BA. Projects benefit from having *both* roles.
In fact, a BA with *too much* domain knowledge can prove challenging. You see this when stakeholders and users from the business become a BA. I know this, because this was my own route into analysis! It is difficult to “abstract away” from the detail and think more diagnostically. Some BAs fall into a semi SME/Systems Analyst role this way. That’s not a bad thing of course — providing they want that role — but a SME/Systems analyst role is *different* from a BA. When you’re doing SME work you’re not doing BA work.
The challenge, however, is getting employers and the agencies that recruit BAs to accept that domain expertise needn’t be a pre-requisite. Often there is a perception that domain knowledge is needed and this is reinforced by the many job adverts that ask for it. This is something where we, as a community of practitioners, need to help to change the pre-conceived ideas.
So, in summary: A good BA can move between domains, and will be able to adapt. However, unfortunately the businesses that *employ* BAs often perceive domain knowledge as a pre-requisite, which leaves us in somewhat of a conundrum. However, forward-thinking BA practices increasingly do recognise that good BAs can move between domains with (relative) ease.
Very seldom do I save a good commentary as a pdf for future direct reference TWICE. In Adrian’s June 17 post, he nicely addresses 2 distinct matters.
That a BA should endeavour to expose oneself to as many domains as possible across one’s career pursuit logically lends to building a (ultimately very) good inventory of experience(s). BAs in earnest about their career development should strive to be the farthest thing from having singularity of domain mindsets: no BA should be content to being essentially a line worker. This sage advice should be an easy sell to BAs at any stage of their career.
The second issue- that proverbial paint point- is how there seems to be this recurring “conundrum” of little Miss 20/30-somethings that staff potential employer HRs and agencies as recuiters who just can’t see the forest for the trees. No context, no perspective, just abstract document word scans to see if the right combination of words pop up. To undoubtedly echo the sentiments of many of us pursuing attractive BA opportunities, if we wanted to play bingo, we’d go down to the community hall. Who the heck (“hell”, really), besides lazy SOBs (glossary needed?), decided to turn the craft of candidate assessment into a lottery?
So, as Adrian puts it, the challenge is, from the BA community side of the ledger, to work toward changing these pre-conceived ideas. To advance this discussion, I logically ask- “How?”
If recruiters and HR “specialists” were not so covetous of their ‘process’, BAs could get in behind the process of candidate assessment and formulate positive change. How does the “BA community” get this ball rolling?
I also have a question for clarity’s sake as well with respect to the term “BA practices”. Adrian, do you mean “practices” as the professional exercise of the tradecraft, or do you mean as “consulting firms”? Thanks for both shepherding this subject matter to this point- and potentially advancing it if you will, and for answering my interpretation question.
Thank you.
Hi Ron,
Thanks so much for your comment, I’m glad you find the article & comments useful!
You have raised a great question. By “BA Practices”, I mean *any* professional community of BAs. That might include, say, a large Community of Practice within a single employer. Equally, it might include a community of BAs inside a consulting firm (who offer their services externally).
Kind regards,
Adrian.
Well, I am really late in joining this discussion and thread (my apologies). To lend context to what I am about to relate, I am currently transitioning from careers in the investigations and legal services field into the field of (and pursuing a career in) Business Analysis.
Mr. Reed’s comments, and for that matter, that of Mr. Lachapelle and Ms. Beal, should be a section or in a chapter in a BA’s handbook.
In my humble opinion, there are three significant topics emerging in this discussion that we should always be vigilantly mindful of.
The Business Analysis profession benefits greatly from the very contextual diversity observed, experienced, and commented in this post/thread. The trait of diversity is essential to the vitality and evolution of the profession. BAs operate in a learning and adaptation continuum. BAs are, or ought to be, perpetually obliged to seek out new opportunities to expand their knowledge areas, experiences, and thus their tradecraft, for the benefit of each successive client, themselves as professionals, and the profession as a professed community (a collective).
So, BAs should fear the day when every BA can reflexively recite a singular, practically monolithic definition of what a BA is/does, for that day will be the watershed moment where the profession is on a course to confining, restrictive compartmentalization- stifling the very creativity that fuels the passion- our passion- for the work.
Coming from the legal profession, I note Mr. LaChapelle’s analogy. In the context of this discussion, the analogy to a degree is adequate, but I make this cautionary caveat. The legal profession’s diversity, what there is of it, though driven by demand and practitioners’ personal interests, has followed a path where over-compartmentalization has encroached to the point of sapping creative, and at times progressive thought, including a less collaborative model of professional development. Result? the evolutionary path of the legal professions (lawyer/attorney, paralegal, law clerk) wrestled away from the practitioners by and controlled by bureaucrats and regulators divested of the essence of the professions and with ulterior agendas. Long live the IIBA and its chapters!
Related to this analogy is Mr. LaChapelle’s merited comment on VALUE. I can attest from observation over many years that consideration of and attentiveness to value of the deliverables is a concept widely foreign to a tragically many practitioners in the legal professions- despite convenient sound & word bytes you might come across to the contrary in the public domain. I remain intrigued, if not confounded, that the significance of VALUE is even subject to debate, as made again evident in an IIBA webinar earlier this year.
To tie up loose ends, Mr. Bomino’s comments essentially support Mr. Reed’s point (and for that matter, observations made by peers with respect to the topic of stakeholder relations & gaining their trust). Here again, tie in also to VALUE: R.O.I. .
Ms. Beal’s comments are solid and insightful, particularly as to her handling of “Issue #2”.
Feedback most welcome!
Great topic, Adrian!
In my view, there are three different issues here:
1. Difficulty in explaining our role for people not familiar with it (the “cocktail party” problem).
2. Difficulty convincing stakeholders to engage with the BA when they haven’t yet experienced the benefits of having a skilled BA in their projects.
3. Long-term issues with business and IT teams rejecting the BA role.
I haven’t yet found a solution for issue #1 (even trying “elevator pitches” suggested by other BAs, I often get a blank stare in response to my description).
I believe that the #3 issue only happens when the BA (or team or BAs) is not doing the job well. I have worked for many organizations where the business wanted to ignore the BAs and go directly talk to the developers, but this situation quickly changed once they saw how the work of a skilled BA joining the team truly made a difference (that agrees with what others have said about delivery being the best way to change this perception).
Regarding issue #2, I think it’s important to use a different strategy than you would use at a cocktail party. Instead of describing generically what contributions a BA can make (which may not be convincing for people not used to having an analyst in their projects), be very specific. For the particular project you are finding resistance, start talking about how clarifying the business need would avoid the problems the team had with a previous project that was didn’t go so well, and explain how more structured analysis could help, using very specific examples. In parallel, start asking good questions — this has never failed to get the business and IT teams to start paying attention to my work and inviting me to participate in their sessions. If people realize you have a valuable contribution to offer, it’s very easy to go from “we don’t need a middleperson” to “please stay with us throughout the project!”.
While I can appreciate the knowledge and value provided by the ideal of the BA profession and admire the work that has been done by its practicitioners in the field of documenting particular businessbest practices, my own personal experiences with BA’s left me cold. I found many in the role to be clueless about anything beyond mindless “checking the checker” type actions that were driven by endless spreadsheet meanderings that really added little value beyond paper pushing and being a refuge from “real work.” Very few had the discipline, understanding or knowledge of what had been formulated in the world of academic business analysis and were submitting to the bureacratic urge to generate reams and reams of meaningless documentation that didn’t drive the project forward but wound up creating endless edit sessions where the meaning of “is” was debated ad nauseum. I remember a time when systems analysis was an esteemed role, usually held by someone who had been with an organization in a technical role and who wanted to leave the nuts and bolts of the technology behind while still continuing to make a contribution. That role may have been more appropriate for a time when organization’s roles had longevity and where loyalty and commitment were valued. Perhaps the BA role has been created out of the new reality of disposable roles and jobs where it serves the purpose similar to that of styrofoam packinging: it keeps things from totalling going to pieces but after it’s served its purpose, it becomes an annoyance and a danger to the environment!
Adrian, your piece strikes two major notes with me.
The first is the context of business analysis. For project managers the knowledge baseline is well defined and what varies is the scale and complexity of the projects being managed. Business Analysis, if you will, suffers by comparison in that the domains of knowledge are much more varied and the very type of what work is done can vary drastically. I have long held that business analysis profession is more akin to the medical or legal professions than project management. We are all analysts, some are generalists, and there is a lot of specialization. So, often when introducing myself I have to set the context of my work as people either don’t know it or have pre-conceived notions, e.g. front end to IT projects. As the context around BAs can vary greatly, it is not a bad thing that different BAs describe themselves differently. What is wrong is assuming the person you are talking to understands the context of your work.
The second note relates to the actual ‘pitch’ most people give. I have done a lot of work over the past year or so with startups and entrepreneurs and the most significant lesson learned, which we personally should adopt, is what value you provide is much important than what you do. There is a tendency to explain business analysis by what is done rather than the outcome that is valuable to the person for whom you work. The corollary to that is explaining value by the tool rather than the outcome – the Harvard Business School approach of the need (a hole) rather than the tool (a drill) being the value that motivates.
When I am asked what I do as a business analyst, I focus on two things, establishing the context of my work, and what outcomes I create that are of value to the people for whom I work.
I just joined this forum & I’m catching up on the conversation.
I wanted to say THANKS to Mike Lachapelle for such a logical feedback; it is level-headed and beneficial. I agree that when it’s all said and done the label you decide to use on yourself or career is not what people will remember. It is the value you added or failed to add that lingers.
Great article, Adrian and great discussion, too. My elevator pitch (for the bakers, teachers, accountants, secretaries and other people who have never met a BA and are still scared of computers) is: “I help to understand what the business people need and try to get the IT guys to build just that, and then interpret the IT-speak back to the business people.” Sure, it doesn’t cover every nuance of Business Analysis, but it extends the “bridge” metaphor, and helps people to understand that I “do something with computers” but from a business viewpoint.
I agree that there are many BAs who can’t articulate what they do and there are many, many business people (including PMs and architects) who still don’t really understand and appreciate what we do, but it’s better than it was 10 years ago and I believe it will continue to impr0ve. Maybe one day “they” will actually start to value us.
Thanks again, Adrian.
A very well-written article on how the ‘other’ guys perceive us. Especially loved the ongoing discussions that your article has generated. Excellent work Adrian.
Pingback: The tough truth: Your stakeholders don’t want a BA | Adrian Reed's blog
Good article Adrian. My elevator pitch continues to evolve. Lately I’ve been saying “I help businesses improve their processes.” What’s yours?
Adrian,
Thanks so much for shining a light on this issue. As someone who has stepped into organizations that have either never worked with a BA or who did and did not have a good experience with one, I agree that demonstrating value can be an uphill battle. I’ve definitely had more success jumping in, rolling up my sleeves, and creating value than in referring to industry standard definitions, best practices, or past successes. Sometimes this means I even need to step outside the BA role at first to get a toe into the process and then grow the BA role from there.
Having spoken to you personally about this topic, I know this wasn’t written in a moment of frustration, but after much reflection and after having turned around how an organization viewed business analysis contributions. I deeply respect you sharing your own professional experience to help others. I look forward to a dialog on this one. We all have so much to learn from each other!
Thanks for asking the tough question Adrian, apparently one that some people do not want asked.
I think you have hit the nail on the head (to extend the drill, hole metaphor a bit to the left) when you said that the best way for people with analysis skills to be valued is to actually deliver. We need to demonstrate how we can apply our unique skill set to deliver the right kind of change in the right way.
Thanks Kent. I completely agree — only through consistent quality deliveries is reputation built! That enables us to nudge away a single brick at a time…
Excellent article, Adrian. To your point of helping us obliterate the wall brick-by-brick, it can be quite an interesting ask (and consideration). The outcome is completely dependent on the history of the organization, stakeholders experience with business analysis, and the standards that are maintained or held up for for keeping them as standards.
Sometimes, the image in stakeholders mind (if they have some history) of a BA is the last BA that did or did not do a good job. The moment they hear “BA”, there is a whole slew of connotations that could derive out of that ‘word’; which I like to call as the ‘gut sense’. 🙂 Then your battle becomes proving that gut sense right or corrective course if there has been some damage done in the past.
If I am in a cocktail party my definition would be: “I am a BA, I act as a bridge between different organizational units that are undergoing change OR I just simply say between IT & the business” … The bridge may sound too simplistic at times, however it is quite the complicated one when you entangle it with different people having different levels of interest to be a part of a positive or negative change, their fears & joys, their past failures & successes, their security & safety, processes and technology (and hey don’t forget to mix-in what a BA does in a given organization).
At any rate, depending on how the party takes course I would most likely stop at bridge, unless there is a hint of some insightful ensuing conversations! 🙂
Great article, and wonderfully written narrative!
Thanks for the comment Yamo, and I’m glad you liked the article. You raise a very valid point about any organizational history, and any pre-conceptions that the stakeholders have.
Interestingly enough, I also use the analogy of a bridge, but I tend to say “The bridge between the business & solution providers”. However, we also tend to act as a bridge within the organization too… plugging the gap between stakeholders and making sure everyone is aligned!
Thanks again for the comment Yamo, all the best, Adrian.
first time to read such a low quality article in bridging the gap website, I believe that article was written in a awkward moment of frustration no more, my comments are:
1- 50 Ba will give 50 different definitions!!, Okay I believe you talk about 50 persons are not qualified enough to play their rule, they don’t even read the IIBA standard definition of the BA .
2- BA can not explain what they do!!, did you really mean that, if yes I believe no wonder that stakeholder don’t need that type of BA who can’t describe his own job, how to trust him to describe what other people do!!
3- If people don’t want BA please raise your hand and inform that piece of info. to IIBA because they claim that the profession is rapidly increasing, the market don’t need more unneeded resources it’s already saturated.
Wael — Thank you for your comment. I think it’s great that Bridging The Gap creates an environment where the community to exchange and share different views–and it’s clear from your comment that you take a different view on this subject to me. It is always great to hear other views, and I think professional debate within the BA community is an extremely positive thing!
To expand upon the points you have raised:
1. I agree with you that IIBA provide a definition of business analysis. This is, however, only one definition, and others exist too. In my experience of working with and meeting a range of BAs here in Europe and also the USA, the reality is that the *scope* of the role varies depending on the organizational context in which they work. Some focus only on requirements–they perhaps carry out 95% of their time on requirements engineering activities (or Requirement elicitation, analysis and validation, if you prefer BABOK terminology). They are clearly at one end of the continuum. However, many other BAs are involved up-front, pre-initiation — and this is where we can add even more value. Some BAs only work on IT projects–whereas others have managed to prove their worth beyond IT (and my view is that business analysis *definitely* spans beyond IT).
So, I would disagree with your assertion that BAs who define their role differently than IIBA are not qualified. It really depends on the organizational context in which they operate–and remember, not all organizations have reached the same level of Change Maturity.
2. My point about BAs articulating their role is that we often work with stakeholders who have extensive business knowledge, but might not be from a Business Change environment. They may never have heard the term “Business Analyst” before, and it’s difficult to come up with a succinct definition that fits all contexts–remembering that we can be involved from pre-initiation, we can help define strategy, define or improve processes, gather requirements, input into business cases etc etc. My point is that the role is extremely wide, and it’s difficult to boil down into a single sentence.
Perhaps you could share with us how you define the role in a single sentence? It’s always great to learn from other practitioners experiences. Yamo has provided an excellent example below.
3. With regards to stakeholders not wanting BAs, my point is related to the fact that stakeholders actually want *delivered change*. We, as a community, know that we’re an essential part of facilitating that change. Our stakeholders don’t always appreciate that, for the reasons articulated in the article. Hence the “drill and hole” analogy.
Thanks again for taking the time out to post your views.
All the best, Adrian.
Adrian: thank you for answering my comments & below my feedback:
– If I agree with you that the definition of BA rule will depend on the organizational context, why this is not applicable to another profession like PM, why PM’s don’t have the same problem? why they don’t have a specific PM’s rule definition for every type of business? I believe you agree with me that it would be chaos to give a definition of BA relevant to every industry type.
– my point when i meant (not qualified) I meant they fail in their main job to give guidance & mentoring to people about their own job.
– Regarding my definition of BA I usually mention that (I am the one who can change the way you do your business by using IT making your processes faster & more Efficient with noticeable reflection on your costs & revenues).