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

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.

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.