We Are Called ‘Analysts’ for a Reason: Observations from the Field

Featured
24698 Views
40 Comments
61 Likes

There is a reason we are called ‘analysts’!

Please forgive me, but I have to vent. I am frustrated, and I find that when I share my frustration, I feel better. No doubt some of you have felt the same way. Now on with my rant….

I am constantly coming across alleged ‘business analysts’, many new to the industry, sauntering confidently into a project or an organization. Typically, the first thing they do when assigned requirements elicitation is organize a workshop. These people are engaging, charming, energetic, and, in many cases, evangelistic. They are very adept at gaining the undivided attention of their audience.

However, their primary and, in most cases, their only concern is determining what the client wants and what the problem is without a thought to a workable action plan to improve anything. The whiteboard fills up with their scribbling and scrawl very quickly, and perhaps they even invite workshop participants to join them at the whiteboard to add to the mess. The smartphones come out, and participants take pictures of the whiteboard. Every participant feels energised and happy because they been listened to; they have had their chance to voice an opinion—a very inclusive process. The notes and statements taken in the workshop are documented as ‘requirements’.

At such workshops, I have asked the business analysts numerous times, “What value are you adding to the process?” The most common replies were “I'm doing requirements” or “I’m working on the requirements portion of the process”. The single word I was looking for was ‘analysis’ or even ‘analysing’. I would have settled for investigating, examining, sifting, scrutinizing—anything that would indicate that there was some thought going into the process. Sadly, I found none—nor, I’m certain, would the clients that these analysts were doing work for.

These guys are facilitators. There is a world of difference between a business analyst and a facilitator. Although facilitating is a necessary part of the business analyst role, that’s not the tangible value the business analyst adds. Basically, anyone can be a facilitator. You don’t need to call yourself an analyst to facilitate requirements activities.

An analyst is like a mechanic. When your vehicle is having issues, a competent mechanic will troubleshoot, find the problem, and fix it. They don’t simply ask you, “Well, what do you think the problem is?” They listen to the symptoms and, drawing on their training and experience, proceed to right what is wrong. That’s what a proficient business analyst will do for a client.

I have worked with business analysts who sit at their work stations waiting for stakeholders to tell them what the problem is. They document it and ship it back for approval. Such a person is not an analyst; they are clerks, and they should change their job titles accordingly.

This same type of business analysts—upon occasion, if the mood strikes them—will get off their backsides and meet with the business and ask, “What do you want or need?” and “What is the problem as you see it?” They take notes and go back to their workstation to document the so-called ‘requirements’ and ship them to the stakeholders for approval.

I’ve noticed that in general, stakeholders tend to accept this approach, regarding it as ‘the business analyst method’. However, they are blinkered and totally oblivious to the fact that it does not add value. In the process of developing a solution, the ‘requirements’ do not deliver a suitable outcome and, at times, will even hinder the delivery process. In the majority of cases, it is IT that will be blamed, not the business analyst. Technology receives inadequate ‘requirements’, hence a wrong outcome.

What is expected from the business analyst?

In one of my assignments, I was asked by my client to assess their business analysis capability (their deliverables, the perception of stakeholders, the added value, etc.). According to my client, he was receiving ‘conflicting’ feedback from his stakeholders regarding the business analyst team (N.B the organization name shall remain anonymous. Permission to use the assignment for this article was sought and approved by the client). I decided to start by asking the stakeholders, the business analysts’ clients, for their opinion of the business analysts’ capability. I simply asked, “Can you share your opinion and experience with the BAs you have worked with?” Twenty-one participants were identified and accepted an invite to participate in the process. I used semi-structured interviews because they result in the extraction of in-depth information. Interview data were then used to generate the information to analyse the research questions. The data analysis suggests that the understanding of the business analyst’s function has various interpretations and is invariably misunderstood. However, some participants expressed some level of dissatisfaction:

  • Business Analyst Function Misunderstood:
    • Participants seem to think that the business analyst gathers and documents requirements. Participants were asked what gathering entails, but most of the respondents struggled to define it. There was no consensus among participants on how to define it.
    • Most participants defined the business analyst role as a conduit of the business in IT.
  • Dissatisfaction:
    • “They don’t go beyond documenting the requirements.” This was repeated by participants multiple times. It is expected that the business analyst should accomplish more than simply documenting requirements.
  • Value Added:
    • When asked about the value-added benefit of the business analyst role, there was, surprisingly, a consensus that ‘accurate and complete requirements’ are part of the value.
    • Accurate and complete requirements are but one milestone in measuring the business analyst added value, where accurate is defined as no ambiguity, and complete defined as all unknowns have been revealed and the known unknowns documented and acknowledged.

In my opinion, and in the instance of this investigation, the business analyst value-add is underestimated. We are called analysts for a reason. The analyst role goes beyond producing deliverables. We combine innovative thinking with a realistic sense of what can be achieved. That is my understanding of value creation excellence.

How do we do that? Our mission is to deliver the optimal outcome by assessing whether the problem’s solution adheres to my business solution principles:

  1. Reusable Solution
  2. Seamlessness in Every Process
  3. Scalable Solution
  4. Future-proof Solution

Organizations have little or an unclear understanding of the actual business analyst role, specifically:

  1. The method and process of getting to the requirements. It appears they trust the business analyst and do not question anything.
  2. There is a level of dissatisfaction regarding the scope of the business analyst’s endeavours. They are not doing enough.
  3. The value of the business analyst is a valid requirement. This is a low expectation from a business analyst who is commanding an obscene amount of money for his services.

To the stakeholder, the business analyst must be called to task; if she or he is not doing analysis, you are wasting time and money. Along those lines, you must hold her or him to high standards to ensure you are getting value for the fee being paid.

Thank you for letting me vent—I feel much better. I’m still frustrated, but I do feel better. This has been very cathartic.


Author: Adam Alami, Sr. Business Analyst

Adam Alami is a seasoned IT consultant with over 18 years’ experience. Business Analysis and Project Management is his passion. His experience revolved around major business transformation projects. He is a versatile IT professional. He accumulated a wealth of cross industry experience with Tier 1 businesses in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.

Adam has a passion for research. His research interests are IT Offshoring, Global Project Managements, Banking Technology, Business Analysis, Information Technology and Culture, Enterprise Innovation and Business Solutions.

Email: [email protected]
Website: www.adamalami.com

Like this article:
  61 members liked this article
Featured
24698 Views
40 Comments
61 Likes

COMMENTS

ron segal posted on Tuesday, February 9, 2016 3:37 PM
You are more than 'forgiven' Adam .. what you say is also something that I've been expounding for years. Analysis is about analysis, its about understanding what makes things tick, or prevents them from ticking, solving problems and providing solutions, identifying the important characteristics of those solutions. The most valuable analysis often involves challenging the status quo and engaging in disruptive innovation. The rest, such as 'facilitation' are just supporting skills.
ronsegal
Michael Cooke posted on Tuesday, February 9, 2016 5:31 PM
Two things came to mind when reading this article Adam. 1. Facilitation. Not anyone can obtain consensus, help a group of often conflicted people agree on a common set of objectives and work harmoniously. 2. Defining a context for your questions around 'what value business analysis adds'. Every human system is complex by default and the complexity comes from the human interaction not the systemic problem statements. A good Enterprise Analyst or Business Architect can not exist without facilitating because strategy is political. The value lever for analysis is in upfront understanding of the problem/opportunity from multiple stakeholders' perspectives. If you do this work using more traditional techniques such as observation/interview, sure your analysis may be more detailed but it will cost more...whose value are you speaking to?
diagram-p
ron segal posted on Tuesday, February 9, 2016 6:33 PM
Analysis is about abstraction and reduction to an understanding that is more valuable than the sum of facilitated inputs.
ronsegal
Michael Cooke posted on Tuesday, February 9, 2016 7:21 PM
I agree with your summary and with Adams frustrations with regards to 'Scribes' vs 'Analysts'. Facilitation is a very deep discipline and toolkit in it's own right. Just as business analysis is not as simple as writing down the businesses guff verbatim, nor is facilitation as simple as keeping people tracking to an agenda (that is a meeting). I am interested in how do you suggest abstracting information from the heads of business people who are working in a continuously changing market landscape? and because of the constant change struggle to agree on priority, complexity etc.

diagram-p
ron segal posted on Tuesday, February 9, 2016 8:03 PM
Actually I've rarely found extracting key information to be that hard given time with the right people. The trick is identifying the typically one or two individuals who really know a business well.
ronsegal
Kupe posted on Wednesday, February 10, 2016 9:26 AM
I don't think anyone can argue with you. I like to say there are many people out there that give BA a bad name. feel free to sing it to the tune of Bon Jovi's "you give love a bad name". My question for you is related to your solution principles. Can you indulge me with some more detail.
Kupe
Adam Alami posted on Thursday, February 11, 2016 2:05 PM
Hi all, thanks for your contributions.

diagram-p, Being a good ‘facilitator’ doesn’t make good ‘analyst’. As ronsegal stated, facilitation is a supporting skill for an analyst. My experience as a business analyst has, however, taught me that before an elicitation technique is selected, one needs to have a strategy in place for how to elicit requirements. For example, a workshop may not be the best option for every situation.

Knowing exactly where your stakeholders stand is, in my opinion, the definitive base towards understanding the environment and the approach to adopt in the process. For example, if the business is of the stand ‘we know what we want’, then all you will get in a workshop is participants pitching the ‘want’ and not the ‘need’.

My point is you could be a great facilitator but it doesn’t make you a good ‘analyst’! Facilitation is not the value add of business analysis.

Kupe, I’m working on an article to discuss those principals. I’ll send you the link when available

Thanks
Adam
adamalami
Mark Monteleone posted on Friday, February 12, 2016 8:12 AM
Suggest reading a past article submission "The Twelve Shades of the Business Analyst (BA) Facilitator" in Modern Analyst.

I have to admit I winced at the statement "These guys are..." However, I understand this submission is a rant. I agree BA facilitators are not just documenters; the marriage between business analysis and facilitation is far more complex.

Solution ownership is key. Too often stakeholders abdicate ownership to the BA, "analyze the problem and give us the solution." This abdication causes blame later and breeds resistance, "who is the BA to determine how the business is run." By solely providing a solution, the BA runs the risk of assuming ownership by default. While maintaining a neutral position, a trained BA facilitator provides a process that guides the stakeholders to a solution via questioning and active listening rather than just providing a solution. This ensures that the stakeholders maintain ownership.
mmonteleone
Kupe posted on Friday, February 12, 2016 8:21 AM
And this is why collaboration is the name of the game. Regardless of who makes the decisions the team has to stand behind it. Creating an environment where you gain buy-in from others is a key skill. If a BA has that, they fall into the Good BA bucket!
Kupe
ron segal posted on Friday, February 12, 2016 2:02 PM
Achieving 'buy-in' is largely about being a good salesperson, another essential supporting skill (as with any kind of consulting), but which again has very little to do with analysis.

Simplistically, sound analysis is first about identifying business need over stakeholders wants, understanding the implications of those needs, then synthesising potential solution strategies and options. After that (or perhaps during) being able to bring influential stakeholders on-board.

ronsegal
Michael Cooke posted on Friday, February 12, 2016 2:33 PM
this discussion is a perfect case in point of why facilitating (read active listening, providing a space for hearing perspectives, resolving conflict, NOT workshopping) is so fundamentally necessary. We have three of four perfectly correct viewpoints on analysis. 1. Adam and rosengal seem to be talking about analysis from the elicitation and decomposition/recomposition perspective 2. I am looking at it from a stakeholder perspective because these are all human activity systems and 3. Kupe and mmonteleone have added in third lense with a focus on collab and solution ownership. All of these viewpoints are right. This is the human challenge on analysis. Even still, it sounds like we are all professional analysts here...the scribes won't wade in until we tell them to :)
diagram-p
ron segal posted on Friday, February 12, 2016 3:27 PM
Part of the issue is that these aren't different perspectives on analysis, rather they are different perspectives on the role of the so called business analyst. Over the years I have seen the median role shift from an emphasis on outcome focused analysis to focus on facilitation and documentation, and particularly inside projects, where opportunity for high value, game changing analysis has already gone. To me this is largely down to a failure of the profession to recognise the value potential and set a corresponding aspirational direction, instead apparently being content to accept regression towards the mean.
ronsegal
Michael Cooke posted on Friday, February 12, 2016 4:02 PM
Can you say more about what 'high value, game changing' analysis is?
diagram-p
ron segal posted on Friday, February 12, 2016 5:02 PM
Ok, as a concrete example. Shifting a loyalty company's current practice of issuing multiple kinds of reward 'points' to the notion of an exchangeable private currency. Simple, even obvious in hindsight. Arrived at by abstracting from the concept of 'reward'. Huge positive impact on customer facility and operational efficiency.
ronsegal
ron segal posted on Friday, February 12, 2016 5:08 PM
So its really about the kind of analysis that has the potential to get a board excited.
ronsegal
Adam Alami posted on Friday, February 12, 2016 7:20 PM
'Over the years I have seen the median role shift from an emphasis on outcome focused analysis to focus on facilitation and documentation, and particularly inside projects, where opportunity for high value, game changing analysis has already gone' Cant agree more! Analysts are not 'yes men'. They are critical thinkers who challenge the 'status quo'. Listening and documenting is echoing not analysis.
Being a good facilitator is a great attribute but as stated by Ron 'It is a supplementary skill' for a BA.
adamalami
Michael Cooke posted on Friday, February 12, 2016 9:26 PM
Sounds frustrating and I'm sure there are tonnes of professional, career Analysts that feel the same; the analytical value has certainly
been watered down. Why Do you think this shift has happened?
diagram-p
Sean posted on Friday, February 12, 2016 9:58 PM
I agree that "business order takers" can do serious harm to organizations and their projects. The role of business analyst is sometimes poorly understood by organizations and those who find themselves in the role. Hopefully a healthy team will question requirements from such analysts and ultimately help them become more competent.
Beyond this, I think the author of this rant is on the wrong track. Even experienced business analysts cannot pretend to master all of the information, variables and decisions involved in developing, delivering and implementing complex systems. Wicked problems require highly effective collaboration of cross-functional teams and this makes facilitation absolutely essential. The lone analyst retiring to figure out the solution - like a mechanic tinkering on a car - is a fiction that over-simplifies our challenge.
Analysis is a critical step in the requirements process but we shouldn't give it pride of place over any others. Experienced business analysts politically poke, prod and probe people, systems and data to reveal and cross-check the true problem let alone the requirements of potential solutions. A narrow focus on analysis is just as harmful as merely taking orders and documenting them. Analysis is the process of decomposing something (e.g. a problem or opportunity) into its constituent parts. This is often the easier side of our work. Business analysts bring tremendous value by synthesizing all the elements of a business solution into a coherent whole. Technical teams rarely have an awareness of where there may be latitude to change business processes, rules, actors and roles because they focus on technologies. Business stakeholders often feel mystified and frustrated with technical options and constraints. Business analysts facilitate a synthesis of these views resulting in the team providing a solution with real business value.
sgatien
Michael Cooke posted on Friday, February 12, 2016 11:18 PM
I agree Sean. One of the fundamental reasons that Technology Projects have failed to deliver on business expectations for the last 20 years is because we focussed more heavily on the engineering side of systems analysis at the expense of the people side. This is the difference between a complicated problem and a complex one.
diagram-p
Adam Alami posted on Saturday, February 13, 2016 3:12 AM
'Analysis is a critical step in the requirements process but we shouldn't give it pride of place over any others.' Yes, we should take a lot of pride on analysis, that why we called 'analysts'. Anybody can be a 'facilitator' but not anybody can be an 'analyst'.

'This (analysis) is often the easier side of our work.' Not Its not! Facilitation is the easiest part of our job. Otherwise, we would have been called 'Business Facilitators'! We not called facilitators because analysis is at he heart of what we do.

'The lone analyst retiring to figure out the solution - like a mechanic tinkering on a car - is a fiction that over-simplifies our challenge' Analysts dont figure out 'solutions', they figure out problems.

'Technology Projects have failed to deliver on business expectations for the last 20 years is because we focussed more heavily on the engineering side of systems analysis at the expense of people side' The last research I'm aware off states '... average organization will
consume over 41.5% of its new project development resources on unnecessary or poorly specified requirements', The Impact of Business Requirements on the Success of Technology Projects Report, IAG Consulting 2009

In my 18+ years doing IT projects, I've experienced projects suffering because of lack of analysis not lack of collaboration, facilitation, documentation, structure, etc. You can get everybody full in love with each others but if the requirements, for example, have high degree of unknowns, dont address the real business pains, not aligned with the business objectives and strategies... Then, the love will get sour at once stage!
adamalami
Michael Cooke posted on Saturday, February 13, 2016 5:27 AM
Perhaps rather than focussing on our different opinions we can revise what we do agree with. Everyone seems to be in unanimous agreement with the main thematic point of your article i.e. there are far too many apathetic, scribes called analysts (document jockeys) who write substandard artifacts due to the minimal or simplistic levels of analysis undertaken (God knows I review a few unreadable specs every day). I find it equally frustrating as I have also chosen analysis as a career and constantly hone existing tools whilst adding new ones to the toolkit. From the responses, it would appear that everyone involved in the debate is an experienced 'analyst' (not the type your article was addressing). A great case in point (and why facilitating is hard) is I clearly missed the emotional point you made at the end of your article...you were frustrated. My response should have been conscious of that. Thank-you for writing the article and apologies if my responses have caused further frustration...it was not intended.
diagram-p
Kupe posted on Saturday, February 13, 2016 5:42 AM
I think these conversations are good for the community. We need to debate, we need to flesh out ideas. I wrote a post yesterday that didn't get posted for some reason (user error). And now I wish I could remember the details. For me, it is not about one thing over the other. Earlier Ron said "Simplistically, sound analysis is first about identifying business need over stakeholders wants, understanding the implications of those needs, then synthesising potential solution strategies and options. After that (or perhaps during) being able to bring influential stakeholders on-board."

I think we can all agree on that. The challenge is you don't do analysis for analysis sake. And how do you do that without being a good facilitator, without creating a collaborative environment. I talked about buy-in earlier and this was put into the supplementary skills category. I don't see how you can separate it. How do you come up with strategies and options without getting buy-in. It's not a available solution if the organization won't buy-in to using it.

Let's keep up the good fight!
Kupe
ron segal posted on Saturday, February 13, 2016 2:01 PM
Great, unusual even, that we seem to have converged on something approaching agreement or at least empathy with the main point of frustration in Adam's article.

From there I guess there is a question, so what? What are the implications?
What do we do?

Actually there's an interesting implication of the majority of document jockeys being engaged on IT projects, together with an accelerating shift towards 'agile' development, which eschews documentation and indeed up-front development of requirements!
ronsegal
Michael Cooke posted on Saturday, February 13, 2016 4:11 PM
Hi Ron, it is a double whammy right? The Agile teams do bare minimum analysis (if at all) and then wonder why they experience problems integrating to broader technology.

On the empathy point, I guess it is also a good example of what can happen when people listen better (not just to the content but to the underlying emotion)...opportunity to learn for me :)

Mid point last...so what do we do? It is a good question; one which I posed to one of the Senior members of the IIBA recently. How can we get better at assessing actual competence (CBAP is a step but it merely tests that people have a common language). Any ideas?

diagram-p
ron segal posted on Saturday, February 13, 2016 6:55 PM
Re IIBA. Its surely not just a matter of assessing competence, rather what we have been discussing here is the right kind of competence. Its not clear that IIBA has got that right. Indeed the IIBA BoK is based on a median or consensus view of what constitutes business analysis rather than excellence. A consensus approach sets up a profession for regression towards the mean. To an extent this is avoided by organisations such as ISACA that has a research arm, which helps to objectively set aspirational direction.
ronsegal
ron segal posted on Saturday, February 13, 2016 7:20 PM
Without getting into the pros and cons of 'Agile' development, the suggestions being made of how the now potentially redundant 'BA' can make themselves useful, starts to look even more like a glorified project gofer. Instead there's a massive, burgeoning area of data science or data analytics, which looks like it should have been a major new stamping ground for business 'analysts'. Facilitators, and documenters, maybe not!
ronsegal
Adam Alami posted on Sunday, February 14, 2016 2:48 AM
'What are the implications? What do we do?' Good questions!
The IIBA focuses on the 'what?' What is business analysis? what the BA deliverables? etc. Deliverables, appear to emphasise on what ‘can be done’ by the BA – rather than how it will help address the problems at hand.
Would be interesting to know how institutionalization has helped other professions and practices e.i. Medicine, Engineering ...

'What are the implications?' is a good research question for a PhD Thesis :-)
adamalami
ron segal posted on Sunday, February 14, 2016 1:27 PM
As you indicate Adam, the IIBA BoK is effectively a check list of current common working practices, deliverables and techniques. Which is really all it set out to achieve, i.e. provide a description of 'the kind of stuff that we do', rather than an analysis of why. It's behavioral rather than problem oriented.

IIBA, or really any profession needs an an active guiding, forward thinking research arm. Without that and with emphasis on current common practice it's a recipe to get stuck in the mud. So for BA, 'data analytics' is almost entirely omitted, despite its burgeoning importance. A waterfall like approach is assumed rather than potentially agile or lean start-up. There is virtually nothing on solution derivation methods or disruptive innovation ...

ronsegal
Adrian M. posted on Sunday, February 14, 2016 7:32 PM
Great discussion guys!!

I would like to offer a thought - perhaps a questions... or maybe I'm just thinking out loud

-- Maybe we expect too much of the average "business analyst".

As evident from Adam's article and from the ensuing comments, it appears that we are not happy with the performance of many of the 'business analysts' we have encountered.

So, do you know a "perfect" business analyst? I would like to meet them. ;-)

My point is that those analysts which awe us with their ability to perform their jobs are few and far between and they are worth their weight in gold. Most organizations, especially large enterprises, are not willing to pay the top dollar commended by these super-analysts.

What ends up happening is that the organization figures out that they don't want to pay the top-notch analyst to perform tasks which could be done by less skilled practitioners. This leads to various sub-analyst roles which develop in large enterprises: requirements analyst (just get me the requirements), process analyst (just figure out the business process), rules analyst (can you document the business needs in the business rules system), systems analyst (document how the system will work), data analyst (create me the scripts for the new tables), etc.

Adam was wondering what has helped other professions like Medicine. The medical field is a great example because I find it similar in many ways to business analysis.

My primary care physician is a rare breed these days... when I had my most recent annual physical exam he:
* took blood pressure and temperature,
* gave me a full medical exam (he even asked questions in the process)
* pushed the needle in my vain and collected my blood,
* gave me my flu shot
* froze a fatty mole on my back
* etc.

Does your personal physician do that? Probably not... And if no, why not?

I would venture to guess that the health care industry (at the advise of some business analyst) figured out that it's much cheaper to have somebody else take your blood pressure and collect your blood besides the doctor. When you go to a modern doctor's office or hospital you can clearly see the degree of specialization for the various tasks: intake clerk, intake nurse, registered nurse, nurse practitioner, emergency room nurse, phlebotomist, physiciant's assistant, doctor.

Even in the doctor rank, it's very rare to find a doctor who will stick with you from the beginning (your initial complaint) to the end (healed). What happens is that the final solution (if you ever get one) has been delegated to a network and series of specialists who have lost the ability to solve the problem holistically and end to end.

BOTTOM LINE: The same thing is happening in business analysis with the main difference being that we are rarely willing to admit it.

We call everybody "business analysts" even though they play different roles in the broader goal of solving a given problem.

Maybe we can begin by recognizing that specialized roles exist and then we can be less frustrated when the intake nurse cannot figure out how to solve my complex auto-immune disease.

Happy Valentine's Day!
Adrian

adrian
ron segal posted on Sunday, February 14, 2016 8:14 PM
Analogies can be very useful Adrian. Following your line of analogous reasoning, the medical equivalent of 'business analyst' would be just 'medical practitioner' or similar (i.e. huge range of competencies all under the same broad brush banner). So at your local medical practice you might well be confused when the 'medical practitioner' was unable to diagnose a complex medical condition.

Though in the context of Adam's article the analogy would be more like 'medical surgeon', who has a great bedside manner but doesn't actually engage in surgery!
ronsegal
hokena1 posted on Friday, February 19, 2016 10:10 AM
I agree that facilitation is a part of being a Business Analyst, however if we fail to find out what the problem is (versus what the stakeholders think it is), we fail to create long-term value. I have seen many BAs document requirements based solely on what stakeholders say during discovery. The key to being a good BA is to take what stakeholders say (yes, while facilitating meetings) and dig deeper.

The common questions that I ask during these meetings include "Why do you want to do it this way?", "Why have you done it this way in the past?" and "How will this help you in the future?". These questions mean nothing if you, as a BA, are unable to analyze the responses and find out what the stakeholders ACTUALLY want (but may not know it). Having a BA that is able to facilitate, collaborate, dig deeper and analyze is where a business will find true value.
hokena1
Kupe posted on Friday, February 19, 2016 11:05 AM
I think it is hard to argue that it is a combination of skills and qualities that's needed.
Kupe
ron segal posted on Friday, February 19, 2016 2:36 PM
Why, why, why is a good start on requirements analysis. Next comes 'what if', which is where creative analysis happens.


ronsegal
Michael Cooke posted on Friday, February 19, 2016 8:46 PM
All good points. One thing I see frequently, is a lack of analysis done on the 'people' part of the problem. I agree we need to focus on the why, what if, who, what, when, where questions but at the strategic end of the problem definition space, people can be subversive, obstructive, undermining or downright lie based on interpersonal issues, conflicted perspectives etc. All I am saying is that part of every functioning business system or model are people, processes, information, technology and governance. Let's not forget tools that focus on the people lense.
diagram-p
Michael Cooke posted on Friday, February 19, 2016 8:50 PM
Forgot to say that 'facilitation' does not equal workshops. I have sat through hundreds of workshops that uncovered far less information than would have been achieved through observations or a good one-on-one interview. Unfortunately, there is more of that...to Adam's point.
diagram-p
David Wright posted on Monday, April 18, 2016 12:51 PM
Hmm, seems I missed this discussion... some themes about facilitation that stuck out for me, in that some are saying that running facilitated sessions doesn't mean doing analysis. What appears to be missing is that you need to facilitate specifically to enable analysis; you need techniques that guide the group through questions and topics that deliver desired results, in my case it is requirements statements; it is certainly not order-taking or just asking people what they want. ... I understand that people want Business Analysis to be about more than requirements, to be that problem solver and solution definer, but I think one should be very good at requirements before spreading their scope to other areas.
dwwright99
ron segal posted on Monday, April 18, 2016 4:11 PM
dwwright99, it's not that facilitation isn't needed but that it isn't of itself analysis. However it is possible to facilitate analytic sessions, which abstract and explore the problem definition and scope, then investigate different potential, maybe even disruptive solutions. This means that facilitated sessions need to commence well before thinking has settled into a project related 'requirements' trough.
ronsegal
Michael Cooke posted on Monday, April 18, 2016 7:00 PM
I get your point Ron. Maybe it depends on whether the problem or opportunity that you are looking to analyse is commonly understood and that all relevant perspectives have been considered. It seems like we are separating elicitation from analysis and although the IIBA competency model has done just that, in reality they are joined at the hip.
diagram-p
ron segal posted on Monday, April 18, 2016 10:09 PM
Exactly, elicitation isn't analysis. Also if the problem or requirement is already well understood (or not necessarily well understood but where key decisions have already been made) the need for analysis diminishes. Which comes back to the original article that many so called 'analysts' aren't actually engaging in much analysis. Which tends to limit the value of the role from realising its potential.
ronsegal
Dave Ayiku posted on Wednesday, November 30, 2016 1:16 PM
Thanks for writing this article. I also followed the comments with interest. As a BA, I am interested in this and will keep track of your posts.
dayiku
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC