Is Your Strength Grounded in System Knowledge or Business Analyst Competencies?

Let me share a story with you.

I started my first BA job by transitioning from a QA engineer role into a BA role. I had acquired deep system knowledge. I knew how the system was put together and how the developers designed solutions.

I didn’t know a lick about business analysis (well at least I thought I didn’t, but I later realized that I actually knew a lot about business analysis before getting into the role). And I learned quickly how to get the business perspective and create requirements specifications.

I loved to work through technical challenges and facilitate problem-solving sessions, and was mostly successful because I had an understanding of the conversations, the possibilities, and most of the trade-offs. I could facilitate because I knew the problem space just about as well as anyone else in the room.

>>> The take-away lesson: Strengths in system knowledge or industry expertise can help you navigate into your first business analyst position. 

Then I moved all the way across the country and started doing BA work for a new product to integrate with a legacy system. I still believe this was the most complex, gnarliest system I’ve ever dealt with.

No longer did my system knowledge serve me. I had none.

I had to step back and think about why the heck I was a BA and what I brought to the table.  It turned out that this was the best career move of my life. If I had stayed in my old company, I might never have learned to learn new systems, to be a BA with no system or industry knowledge, or to rest on my core competencies in elicitation, analysis,  and communication.

And did I ever learn. 

  • I learned to facilitate discussions when I was the least knowledgeable person in the room.
  • I learned to evaluate business requirements before functional ones.
  • I learned to build systems from scratch.
  • I learned to dissect complex legacy systems.
  • I learned that so many technical concepts are very general (databases, scripts, processing, rendering, rule-based logic, etc.) and that it matters less what the code is written in and more on what it does and how it works.

Of course, along the way I had my share of missteps, oversights, and mistakes. But I was learning each and every day.

>>>The second take-away lesson: Be aware of what grounds your strengths. Put yourself in situations to help you grow your strengths into portable competencies.

I’ve never looked back from my decision to rest more on my competencies than my know how. Sure there are still positions that want a specific skill or a certain technical ability. I have no problem learning these things. But I know that none of this makes me a better business analyst generally, only helps me address specific problems in specific situations.

So, if you are currently a business analyst or if you want to be one, ask yourself:

  • Where do you find your strengths?
  • Could you be equally effective outside your comfort zone?
  • Are you testing yourself and developing your competencies?

Expand Your BA Strengths

Check out our business analysis training courses to discover how we can help you grow your core business analysis skills and as you push the boundaries of your comfort zone.

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

Comments

  1. DougGtheBA says:

    It’s funny you write this today, as I was just thinking about this. I periodically go through what I call “a severe case of the stupids” and it is a direct result of putting myself into the middle of something that I know nothing about. “Stupids” is that feeling everyone has during their first week or two on a new job when information is running through both ears, the brain is mush, the eyes are glazed over and the pulse is quickened. It wears off as one learns. When idiots like me intentionally volunteer for projects or tasks and place themselves in this situations, it is known as “severe stupids”.

    All kidding aside, it is these scenarios that my skills as an analyst are really put to the test and where I have to rely on many more competencies/techniques that normally is the case. I hate how I feel during these times, as I struggle to comprehend what is going on and how everything fits together. This is where I am most humble and where I capitalize on that to allow myself to ask questions that everyone else is too ashamed to do so. THEY ARE FOOLS! Those are the BEST questions and have the most robust answers. I ask those questions until I get a satisfactory answer…or until the person answering turns blue in the face from frustration with me.

    I’m a firm believer that the more painful the lesson, the better the learning experience. This has proven to be the case and there is no better feeling than overcoming a severe case of the stupids….and becoming someone that actually has a grasp on what is going on.

    So when I feel dumb because I have not attained knowledge on every granular aspect of a problem, I remind myself that perhaps I’m just not stupid enough today…and I start asking questions.

  2. Sometimes, by not being the strongest knowledge expert in the room, we’re forced to rely on or discover our facilitation skills. If we can recognize that inevitably we’ll be placed in a situation where we’re not the expert, we can then acknowledge that our roles may sometimes be team builders, rather than subject matter experts. That only serves to expand our skillsets and gradually enable us to provide more value to the process.

    A team gets so excited when the “guru” can admit that he/she could use some help. We open the door for greater participation and team involvement and become more human in the process. We’re then not only resolving specific issues, but providing a greater value to the ongoing improvement by moving to a different level. The teacher we all remember isn’t the one with the greatest amount of knowledge, but rather the one who somehow managed to engage us in the educational process.

  3. Hi Laura,

    Can you please tell me how I can learn what you have learned in the following:
    “I learned to facilitate discussions when I was the least knowledgeable person in the room.”

    I am new to the BA role and sometimes I do feel very incompetent and useless when in a requirement gathering meeting where I have no knowledge of the business.

    I would like to know how I could really contribute to the discussions, gather good requirements and cover the necessary gaps in understanding the needs at such times.

    Thanks in advance.

  4. Hi Wei,

    It’s just a matter of asking questions, listening, and absorbing. It’s actually not about feeling knowledgeable at all. Actually, quite often it’s the opposite. Take your elicitation in steps. You can’t expect any initial meeting to get 100% of the information so set stakeholder expectations that you’ll be back with more questions once you’ve had time to analyze.

    Laura

  5. Hi Laura,

    Thanks for that.

    I think my problem lies in asking the right question.
    How or where can I learn to ask the right question on the get go even without any knowledge of the business at all?
    Or would the first meeting most likely be a lot of listening and absorbing, then in later meetings asking questions?

    You see, the thing with how most of our elicitation work is we have one or a couple of long workshops with the client. The seniors with the domain knowledge will be asking lots of questions. From there, we go back to our desk, write the requirements document and find any gap with the product for feedback to the product architect. If we have any further questions, we will just send the individual an email. I don’t know if that is how the normal process is. But if it is, how can one contribute on the get go without any domain knowledge at all?

    Thanks again in advance.

  6. Hi Wei, Long workshops do typically involve either more preparation in terms of domain knowledge or stronger facilitation skills in terms of leading the participants through an agenda where they create the requirements models together. A great book on facilitating requirements workshops is Requirements by Collaboration by Ellen Gottesdiener.

    My typical process where I don’t have the domain knowledge (and because I’m not an expert facilitator) is to hold a series of shorter meetings where I can develop my questions iteratively. As I learn more, I can discover more questions. As I analyze, I can validate my models…

    One question to consider is whether the current format for eliciting requirements is the best one. Possibly you might be given license to have follow-up conversations instead of emails? That seems like it might be a small step in the right direction.

    In terms of preparing what questions to ask, you might find these posts helpful.

    http://www.bridging-the-gap.com/what-questions-do-i-ask-during-requirements-elicitation/

    http://www.bridging-the-gap.com/how-to-learn-about-a-new-business/

  7. Another thought regarding that first meeting. In a more iterative requirements process, it will tend to be a lot of listening and absorbing, but you still need to have questions ready to ask. The difference is that in these initial meetings, your questions will be generic “what and why” type of questions. Where in a detailed, follow-up meeting your questions will become very specific to the domain, because by then you will have learned a good deal about the problem being solved and the capabilities available.

  8. Thanks Laura.

    This helps a lot.

    ~Wei Yin

  9. It is interesting you should highlight the need for working ourside the sytems / industry realm and working ourside ones confort zone.

    I have always been the one to look at the business needs and translating to systems. Given my expereince has been on a variety of industries focusing on a varietyof IT tool selection and implementation, I don’t have an “expertise” in 1 system or industry. I do have strong technical skills and the ability to appreciate new technology which helps me look at business requirements and convert to more functional or technical ones. I would like to think I am good at what I do. I thought that was the key to being a good business analyst – except when it came to finding a new job.

    All the job adverts for a BA seem to concentrate entirely on industry and system focused experience than business focussed and I see no interviews coming my way. Made me question the whole business versus systems arguement!

  10. L, This is a common problem in the job market today. But those jobs DO exist and you will find them. Just think, if you had just one specialization in your experience, you would only qualify for a very small handful of the jobs anyway. Exposure to multiple industries and systems is likely to be a stronger benefit in the long-run.

  11. Eve McGivern says:

    Laura, I wanted to let you know that this has been a critical article for me, as this both encouraged me to make a recent job transition, and it has been assisting me in pulling through that transition. In short, I began questioning my skillset and considering if I was an effective Business Systems Analyst, or if I was relying on my technical and systems knowledge to see me through. When I initially encountered this article, I put a two-fold plan into action: a. achieving the CBAP certificiation (I suppose as ‘proof’ of my BSA legitimacy, as well as an avenue to opening new opportunities), and b. breaking away from my current domain and existing systems knowledge (with which I had grown comfortable) to a completely different domain in which I had no little to no prior knowledge.

    It was a frightening choice, and I had to keep telling myself why I was making the move. When I finally made the move, I had to once again tell myself why I had made the move. Even now, when I get discouraged and crave the familiarity of old systems, I realize I need to maintain faith in my BA competencies (I might make a case that the BA profession is in itself a ‘system’!). I admit, I was surprised that I was hired into a new domain sector (even if inside the same industry), so I consider myself lucky to have been hired by someone with the foresight to recognize that BA/BSA skills need not be systems nor domain specific.

    • Eve,
      Thank you so, so much for sharing your story and the impact my story had on your career. It sounds like you are headed for bigger and better things. Yes, I remember my first days, no months, in my new role in a new organization (made more challenging by the fact that I’d also uprooted and moved across the country by myself). I did feel many times like I was drowning in new information and that I couldn’t possibly provide as much value as I did in my old role. Luckily I had an amazing mentor/manager who believed in me and didn’t let me doubt myself.

      Trust me, you will look back at this time with pride very, very soon. It’s difficult but it’s worth it. It will open up so many possibilities for you. Once you learn a new domain, the third is easier and the fourth is even easier…and then all of a sudden you feel confident you could handle a very wide variety of situations.

      Thanks again, and check back soon Eve to let us know how it’s going!