The Making of a Business Analyst

Image for post
Image for post

Great business analysts (BAs) arise from diverse backgrounds of education and work experience. Consequently, they’re likely to have some gaps in their knowledge and skill sets that will present challenges as they pursue requirements development for a new software system.

Each BA should decide which knowledge and skills pertain to their situation and actively seek to fill their own gaps through continuing education. My book with Joy Beatty, Software Requirements, 3rd Edition, identifies numerous skills that most BAs need to accumulate through training and experience. These fit into the following categories:

  • Communication skills (listening, interviewing and questioning, writing)
  • Interpersonal skills (facilitation, leadership, teamwork)
  • Technical skills (modeling, analysis, systems thinking, organization, creativity)

The International Institute of Business Analysis (IIBA) describes the competencies entry-level, junior, intermediate, and senior business analysts should exhibit across the common BA activities. All new BAs will benefit from mentoring and coaching from those with more experience, perhaps in the form of an apprenticeship.

This article explores how people with different educational and professional backgrounds might move into the BA role. I’ll describe the advantages each can offer, as well as some of the challenges and risks they’ll face.

The Rookie

Becoming a BA sometimes is an entry point into the information technology (IT) arena for someone right out of school or coming from an unrelated job. The new graduate will have little, if any, relevant experience or knowledge. He will likely be hired into the BA role because he demonstrates many of the skills required to be a good analyst.

An advantage of hiring a novice as a BA is that he’ll have few preconceived notions about how requirements processes should work. He might not have to un-learn some bad habits picked up from previous project experience.

Because he lacks related experience and knowledge, though, a recent graduate has much to learn about how to execute the BA tasks and the intricacies of the practices. The new graduate must learn enough about the software development process to understand the challenges developers, testers, and other team members face so he can collaborate effectively with them. Mentoring can reduce the learning curve for a novice BA and instill good habits from the outset.

The Former User

Corporate IT departments often have business analysts who migrated into that role from a previous career as a user. These individuals have already understand the business and the work environment, which is a big advantage. They speak the user’s language. They know the existing systems and business processes. This makes it easier for their former colleagues to trust those former users to present their needs.

On the downside, former users who are now BAs might know little about software development or how to communicate with technical people. If they aren’t familiar with modeling techniques, they’ll likely express all requirements information in textual form. Users who become BAs need to learn about the technical side of software development so they can represent information in the most appropriate forms for their multiple audiences.

Some former users believe they understand what a new system needs better than current users do. Therefore, they might not solicit or respect input from those who will actually use the new system. Recent users can be stuck in the here-and-now of the current ways of working. They don’t see opportunities to improve business processes with the help of a future information system. It’s also easy for a former user to think of requirements strictly from a user interface perspective. This focus on solution ideas can impose unnecessary design constraints and often fails to solve the real problem.

Companies sometimes have employees for whom migration into business analysis is a logical career move. The senior manager of a medical devices division in a large company once told me, “Two years ago, I hired three medical technologists into my division to represent our customers’ needs. They’ve done a great job, but they’re no longer current in medical technology, so they can’t speak accurately for what our customers need today. What’s a reasonable career path for them now?”

This manager’s former medical technologists were good candidates to become business analysts. Although they weren’t up on the latest happenings in the hospital laboratory, they could still communicate with other med techs and understood the job. Spending two years in a product development environment gave them a good appreciation for how IT works.

They needed some additional training in requirements-writing techniques, but these employees had accumulated a range of valuable experiences that could make them effective analysts. These former users did indeed transition into the BA role successfully.

The Subject Matter Expert

In his book Effective Requirements Practices Ralph Young recommended that the BA be an application domain expert or a subject matter expert (SME), as opposed to being a typical user. He said, “SMEs can determine…whether the requirements are reasonable, how they extend the existing system, how the proposed architecture should be designed, and impacts on users, among other areas.” Some product development organizations even hire expert users of their products who have extensive domain experience into their companies to serve as either BAs or user surrogates, as with the medical technologist example above.

There are risks here too, though. The BA who is a domain expert might specify the system’s requirements to suit his own preferences, rather than addressing the legitimate needs of diverse user classes. He might have blinders on when thinking about requirements and be less creative in proposing new ideas.

SMEs are expert in their understanding of the “as-is” system; they sometimes have difficulty imagining the “to-be” system. It often works better to have a BA from the development team work with the SME, who then serves as a key user representative or product champion. (See “Hearing the Voice of the Customer: The Product Champion Approach” for more information about the product champion role.)

The Former Developer or Tester

Project managers who lack a dedicated BA on their team often expect a developer (or a “product owner” in the agile world) to do the job. Unfortunately, the skills and personality needed for requirements development aren’t the same as those needed for software development.

Some developers have little patience with users, preferring to wrestle with code. Of course, many other developers do recognize the criticality of the requirements process and can work as analysts when necessary. Those who enjoy collaborating with customers to understand the needs that drive software development are good candidates to specialize in business analysis.

The developer-turned-analyst might need to learn more about the business domain. Developers can easily lapse into technical thinking and jargon, focusing on the solution to be built instead of customer needs. They’ll need to get up to speed on current best practices for requirements development. Developers will benefit from training and mentoring in the diverse soft skills that the best analysts master. These include interviewing techniques and facilitating requirements elicitation discussions.

A software tester often has an analytical mindset that can lend itself to being a good BA. Testers are already used to thinking about exceptions — conditions that can cause errors — and how to break things, a useful skill for finding gaps in requirements. As with a former developer, a tester must learn about good requirements engineering practices. She might also need more education about the business domain.

The Former (or Concurrent) Project Manager

Project managers are sometimes asked to also fill the role of BA, perhaps because they have some of the same skills and domain knowledge required. This can be an effective role change. Project managers will already be used to working with the appropriate teams, understanding the organization and business domains, and using their communication skills to good advantage. They will likely be good at listening, negotiation, and facilitation. They should have strong organizational and written skills as well.

As with the other backgrounds described above, the former project manager also will have to learn more about effective requirements practices. It’s one thing to set up a plan, allocate resources, and coordinate the activities of analysts and other team members. It’s a very different matter to perform the BA role yourself.

Former project managers must learn to focus on understanding the customers’ business needs and prioritizing those within existing project schedules, rather than focusing on timelines, resources, and budget constraints. They’ll need to develop the analysis, writing, modeling, and interviewing skills that are essential to BA success.

No matter what her background, a creative business analyst can apply it to enhance her effectiveness. The analyst needs to gain the knowledge and skills she lacks, build on any past experiences, and practice performing the BA tasks to become more proficient. All of these together help create a well-rounded business analyst who can add considerable value to any software project.


This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Written by

I’ve written on software development and management, consulting, self-help, chemistry, military history, and a mystery novel. More info at

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store