I was a software developer consultant. Karl was a chemist. One ArgonDigital colleague used to be a project manager. Another was a history major who just graduated from college. Yet another was a teacher and a QA expert. But now, we all perform the business analyst role. Great BAs are grown from diverse backgrounds of education and work experience, so they will likely have gaps in their knowledge and skill sets. The International Institute of Business Analysis (IIBA) describes the competencies that 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 who have more experience, perhaps in the form of an apprenticeship. In this blog post (adapted from the new book Software Requirements, 3rd Edition by Karl Wiegers and yours truly), we’ll explore how people with different backgrounds might move into the analyst role and see some of the challenges and risks they’ll face.

The former user

Corporate IT departments often have business analysts who migrated into that role from a career as a user. These individuals understand the business and the work environment, and they can easily gain the trust of their former colleagues. They speak the user’s language, and they know the existing systems and business processes.

On the downside, former users who are now BAs might know little about software engineering or how to communicate with technical people. If they aren’t familiar with modeling techniques, they will express all information in textual form. Users who become BAs need to learn more 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 is needed better than current users do, so they don’t 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, such that they don’t see opportunities to improve business processes with the help of a new information system. It’s also easy for a former user to think of requirements strictly from a user interface perspective. Focusing on solution ideas can impose unnecessary design constraints and often fails to solve the real problem.

The former developer or tester

Project managers who lack a dedicated BA often expect a developer 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 work with the code and promote the glamour of technology. 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 software to be built instead of the customers’ 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.

Testers aren’t commonly asked to perform the analyst role. However, a tester often has an analytical mindset that can lend itself to being a good BA. Testers are already used to thinking about exceptions and how to break things, a useful skill for finding gaps in requirements. As with a former developer, a tester will have to learn about good requirements practices. She might also need to become more knowledgeable about the business domain.

The former (or concurrent) project manager

Project managers are sometimes asked to also fill the role of business analyst, probably 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 demonstrating strong communication skills. They will likely be good at listening, negotiation, and facilitation. They should have strong organizational and written skills as well.

However, the former project manager will have to learn more about requirements practices. It is one thing to set up a plan, allocate resources, and coordinate the activities of business analysts and other team members. It is a very different matter to perform the business analyst role yourself. Former project managers must learn to focus on understanding the business needs and prioritizing those within existing project schedules, rather than focusing on timelines, resources, and budget constraints. They will need to develop the analysis, modeling, and interviewing skills that are less important for project managers but are essential to BA success.

The subject matter expert

In Effective Requirements Practices (Addison-Wesley, 2001), Ralph Young recommends that the business analyst be an application domain expert or a subject matter expert, as opposed to being a typical user: “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 hire expert users of their products who have extensive domain experience into their companies to serve either as analysts or as user surrogates.

There are risks here, though, too. The business analyst who is a domain expert might specify the system’s requirements to suit his own preferences, rather than addressing the legitimate needs of the various 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.

The rookie

Becoming a business analyst is a good entry point into the information technology arena for someone right out of school or coming from a completely 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 will have few preconceived notions about how requirements processes should work.

Because he lacks related experience and knowledge, a new graduate will have much to learn about how to execute the BA tasks and the intricacies of the practices. The new graduate also needs to learn enough about the software development process to understand the challenges that 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.

No matter what his background, a creative business analyst can apply it to enhance his effectiveness. The analyst needs to gain the knowledge and skills he is lacking, build on any past experiences, and practice performing the BA tasks to become more proficient. All of these together help create the well-rounded BA.

Author Bios: Joy Beatty is a Vice President at ArgonDigital. Karl Wiegers is Principal Consultant at Process Impact. Karl and Joy are co-authors of the new book Software Requirements, 3rd Edition (Microsoft Press, 2013).