Jun
10

What not to do! How to be a bad Business Analyst.

5 Comments

No one wants to do a bad job, but unfortunately not all BA’s impress their clients.

Here are a few things to avoid.

3 – Saying “yes” to every request from the business.

It is really important to listen to the business, but we are Analysts, not Dictaphones.

Our job is to put ourselves in the shoes of our Stakeholders – we need to understand their current practices and their vision of the future.  What makes you stand above the pack  is to really question the wish list, encourage lateral thinking and make sure both you and the stakeholder understand  the value of every requirement you capture.

2 –  Taking the “I’m a bridge between the business and IT” analogy a little too far.

It is important that the BA is the main point of contact between the Business and IT, however, if you really want your developers to understand the solution they are building – let the Developer and the Business have a conversation without you always being there.

We should be facilitating communication and stimulating ideas  - not being road blocks.

1 – Being a know it all.

There is nothing worse than the BA who knows it all, doesn’t really speak with the business and makes people feel uncomfortable for questioning “their requirements”.  Not listening to the business and just writing requirements is the best way to leave a long and lasting bad legacy!!

Implementing a new system is a difficult time for any organisation, jobs are lost, changes are introduced and everyone is under loads of pressure to get things right.  Be wary of the challenges that your stakeholders are facing- help extract their requirements and really work hard to understand why they need them.

Posted in Requirements Uncategorized
5 Comments Posted by Adam Feldman

5 Responses to "What not to do! How to be a bad Business Analyst."

  • Adriana B. says:
    June 10, 2009 at 1:30 pm
    Reply

    Adam,

    All good points, but I would be careful with item #2. Even though I advocate and facilitate as much as possible direct communication between the business and technical sides, there’s always a risk involved in letting developers and business representatives discuss the solution without the participation of the BA.

    In my experience, developers are often guilty of your #3 mistake (saying yes to every request just to please the business). The BA is typically responsible for doing what you suggest as the right course: question the wish list, encourage lateral thinking and make sure the value of every requirement captured is well understood.

    • Adam Feldman says:
      June 10, 2009 at 1:48 pm
      Reply

      Hi Adriana,

      Thanks for your comment!

      You’re right about #2 and to be honest, I thought long and hard about not including it. But I really feel it is important.

      I have worked on some big projects and I have often seen BA’s really hoarding their knowledge and not allowing others in the team to have a relationship with the business. I think this is bad for the rest of the team as the developers don’t see the big picture or the purpose of what they are building. So long as the BA is still in the loop, I don’t think we need to sit in on every conversation.

      I agree that there is a risk of the developer just agreeing to build everything as requested – but this risk is mitigated if the development team understands that they only build approved requirements.

      Would your thoughts differ if this was an Agile implementation?

      Adam

  • Adriana B. says:
    June 10, 2009 at 2:32 pm
    Reply

    Adam,

    I’m glad I haven’t seen a BA “hoarding their knowledge” in my work environment yet, and completely agree that this is unacceptable behavior, and understand why you included point #2 based on your own experience.

    You nailed it with “So long as the BA is still in the loop”. Note that I’m talking specifically of situations in which conversations between business and development teams affect requirements that the BA is responsible for analyzing and documenting (if both sides want to go have a beer after work without the BA’s presence, I say, go for it!).

    But having conversations that can result in new or changed requirements, and then briefing the BA afterwards, just doesn’t seem to me the most productive way of eliciting requirements.

    Perhaps because of my personality, I’ve always being in the opposite situation – having to fight to get the business and the technical team to interact more.

    For example, in one of my last external assignments, I actually had to convince the head of the development team to let me bring the developer to the meetings with the users and project sponsor. This manager didn’t have much faith in his developer’s soft skills, and preferred to have me as the “translator” from business needs to technical requirements. In the end, he was convinced and the developer was allowed to sit in on our meetings, to great benefit to our project.

    Another example: A few years ago I was working for a financial institution, and made a suggestion that once a month we held a meeting with the participation of both business and IT teams. In it, a business person would present an aspect of a business process or discuss business rules, and in turn, a developer or tester would make a short presentation on a technical issues (once the technical presentation covered the reason why some calculations in the application were not 100% correct – there were issues with Java floating point operations that they were still trying to solve).

    As the BA, I’d be usually present in these meetings, but only as a listener. The relationship building and knowledge exchange results of these meetings were excellent, giving each side a better perspective of what challenges the other group was facing.

    P.S. To answer your question, I don’t think my opinion changes in an agile environment. I’m thinking here that there were probably serious flaws in the leadership processes in these big projects you saw BAs “hoarding their knowledge and not allowing others in the team to have a relationship with the business”, and also becoming “road blocks”. Wouldn’t you agree?

  • Declan Chellar says:
    June 11, 2009 at 8:24 am
    Reply

    Hi, Adam.

    I wholeheartedly agree with #3. I have seen systems costing tens of millions go live and then fail to work effectively largely because the solution provider was in a precarious position with the customer and so the project manager and requirements manager basically said “Yes” to everything in order to keep the customer happy. “Yes” to everything, while not exercising change control, of course, resulting in unscheduled delays, contradictory or undeliverable requirements.

    I have also seen situations where a company brought in cheap labour from a subsidiary abroad but from a culture where the people are educated not to question authority and that the customer is ALWAYS right. These people were then put into workshops without any briefing as to how they were to behave and said “Yes” to everything, causing havoc.

    I have also seen cases of #1 where the analysis consultants were quite arrogant and the customer unsure of what they wanted, with the result that the analysts basically told the customer what they wanted. The problem was that the consultants were recent graduates who, because they all had first-class honours degrees from either Oxford or Cambridge, thought they knew it all. Result: the system never got past the design stage because the analysis kept having to be re-done by the design team (who were also experienced analysts). By the way, I am not in any way critical of people with good degrees, just people who think a good degree in a particular subject makes them an expert on anything they touch.

    As for #2, I understand Adriana’s reservations. My experience, though, when I leave developers alone with customers is not that they say “Yes” to everything, but that they moot solutions (trying to be helpful) and then the customer picks one as their requirement. As you say, however, by staying in the loop, I am able to go back to both parties and find out what the actual business problem is and document that.

    Good selection of points, Adam!

    All the best.

    Declan

  • vijay says:
    June 21, 2009 at 1:12 pm
    Reply

    Quite true, every point mentioned above are the MUST-HAVE’s for being a good BA.Especially the third point where for implementing a solution in a organization BA must make aware of the challenges and changes requried to Business.

Leave a Comment