Product Development & Management

The Making of a Business Analyst

By |

Great business analysts are grown, not trained. The job includes many soft skills that are more people-oriented than technical. An organization’s BAs likely will come from diverse backgrounds, which could include the business side, the IT side, and subject matter experts. Whatever their backgrounds, new BAs will have gaps in their experience, knowledge and skill sets because of the unique bridging and communication-centric nature of this vital project role. This article looks at some of the skills and knowledge issues associated with business analysts who come to the job from various previous positions.

Anyone pursuing a career as a BA should study an inventory of relevant knowledge, such as the Business Analysis Body of Knowledge developed by the International Institute of Business Analysis. I’ve developed a suggested business analyst job description (available from the Process Impact Website). All BAs should determine the job knowledge and skills that pertain to their situation, identify their own knowledge gaps, and actively seek the information that will let them do a first-rate job. Classroom training, eLearning courses, self-training, coaching, and practice will all be useful methods for bridging the gaps. New BAs also can benefit from mentoring from those who have more experience, perhaps in the form of an apprenticeship.

The Former User

Many corporate IT departments employ business analysts who migrated into that role following a career as an end user of business applications. These individuals have a solid understanding of the business and the work environment, and they easily can gain the trust of their former colleagues. They speak the user’s language. They know the existing systems and business processes.

On the downside, former users who are now in the BA role often have little understanding about software development and how to communicate with technical people. If they are not familiar with various analysis modeling techniques, they likely will express all requirements information in natural-language textual form. They might not appreciate the importance of specifying how the system should handle exception conditions, which is how you make a software application robust. Users who become BAs will 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 that their understanding of what is needed is better than that of the current users, so they don’t solicit or respect input from those who will be using 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 fall into the trap of thinking of requirements strictly from a user interface perspective. Focusing on solution ideas can impose unnecessary design constraints from the outset and often fails to solve the real problem.

Despite these shortcomings, moving from a user position to a BA role can be a meaningful career option. The senior manager of a medical devices division in a large company once told me that he had a problem. “Two years ago I hired three medical technologists into my division to represent our customers’ needs,” he said. “They’ve done a great job, but they are no longer current in medical technology, so they can’t speak accurately for what our customers need today. What is a reasonable career path for them now?”

This manager’s former medical technologists might be ready to move into a BA role. Although they aren’t up on the latest happenings in the hospital laboratory, they can still communicate effectively with other med techs. Spending two years in a product development environment gave them a good appreciation for how product development works. They might need some additional training in requirements-writing techniques, but these employees have accumulated experience that could make them valuable analysts.

The Former Developer

Project managers who lack a dedicated BA often expect developers to fill the job. Unfortunately, the skills and personality needed for requirements development aren’t the same as those needed for software development. The stereotypical geek isn’t the most socially adroit of human beings. A few developers have little patience with users, considering them a necessary evil to be dealt with quickly so the developer can hustle back to the real job of cutting interesting code. Of course, many developers recognize the criticality of the requirements process and are willing to 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 users’ needs. Former developers also will benefit from training and mentoring in the soft skills that the best analysts master, such as effective listening, negotiation, and facilitation.

The Subject Matter Expert

In his book Effective Requirements Practices (Addison-Wesley, 2001), Ralph Young recommends having the BA be an application domain or subject matter expert, as opposed to being a typical user. As Young puts it, “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 with extensive domain experience into their companies to serve either as BAs or as user representatives.

One risk here is that the BA who is a domain expert might specify the system’s requirements to suit his own preferences, rather than addressing the needs of diverse user classes. SMEs sometimes strive for a high-end, all-inclusive system, when in fact a less comprehensive solution might well meet the needs of most users. It often works better to have a BA from the development team work with the SME, who then serves as a key user representative (product champion).

The Project Manager

These days I hear a lot of discussion juxtaposing the business analyst and project manager roles. There seems to be an expectation that the same people readily can perform both roles on a project, or that there is significant overlap between the roles. I don’t see it that way. I think both project management and business analysis are challenging tasks with their own bodies of knowledge. Certainly, there is some commonality in applicable soft skills and personality characteristics, such as the ability to foster collaboration and negotiation among stakeholders who might have conflicting interests. Activities like scoping and prioritization are also common to both roles. But there are some significant differences.

A project manager who takes on a BA role will likely need to learn more about how to ask the right kinds of questions of user representatives to elicit a robust set of requirements. He’ll also need to learn how to represent that requirements knowledge in various forms, including well-crafted natural language requirement statements and graphical models. Conversely, a BA who picks up project management tasks may need to learn about estimation, planning risk management, resource allocation, and metrics. While a close partnership between a project manager and a business analyst is important to project success, anyone who is thrust from one role into the other should identify and fill crucial gaps in his knowledge and skills.

I believe that people can become good BAs regardless of their background, provided they have the right personality for the job and an appropriate combination of skills, knowledge, and experience. It doesn’t happen simply by decree or by desire, though. All novice BAs need to be honest about the gaps in their background so they can ramp up to full effectiveness quickly.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

Latest posts by Karl Wiegers (see all)