Going for Business Analyst Role? These 7 steps will make your journey easier
Success in BA role depends on your attitude more than anything else
Companies very often assume that every skilled programmer is also proficient at interviewing customers and writing requirements specifications, without any training, resources or coaching. This isn’t a reasonable assumption. Like testing, estimation and project management, a Business Analyst skill has its own body of knowledge. Unfortunately, most computer science educational curricula emphasize programming-related knowledge over other software life cycle activities. In addition, many software practitioners lack formal education in their field. Self-study and on-the-job learning often neglect softer skills such as those needed in requirements engineering.
So what makes a successful business analyst? These 7 points sums of the core elements of a business analyst role.
Act as Principal Conduit
Business Analyst’s primary responsibility is to gather, analyze, document and validate the needs of the project stakeholders. As the principal conduit through which requirements flow between the customer community and the software development team, you’ll play a central role in collecting and disseminating product information, whereas the project manager takes the lead in communicating project information An effective analyst combines strong communication, facilitation and interpersonal ability with technical and business domain knowledge and the right personality for the job. Patience and a genuine desire to work with people are key success factors. Here are 10 soft skills that you’ll need to succeed.
Color Inside the Lines
A seasoned Business Analyst engage in a dialogue with the project’s funding sponsor, marketing manager or product visionary early on to define the project’s business requirements. You might suggest a suitable template for a vision and scope document or a marketing requirements document and work with those who hold the vision to help them describe it. Such high-level requirements documentation helps you answer this critical question whenever someone suggests a new product feature: “Is this feature in scope?”
It’s also important to focus the early requirements elicitation discussions on the tasks users need to accomplish with the system. Requirements discussions often center on fragments of functionality (“I need to be able to sort the list alphabetically”), quality characteristics (“this system has to be a lot more reliable than the old one”), or solution ideas (“then I select the state where I want to send the package from a drop-down list”). Don’t discard these bits of information because they convey part of what the user has in mind. However, the process is more
efficient if you encourage users to describe their goals in using the system, why they need the
functionality or characteristics they describe, and the business tasks they’re trying to accomplish.
Ask Revealing Questions
Users naturally focus on the system’s normal, expected behaviors. However, much code
gets written to handle exceptions, so a Business Analyst should also search for possible error conditions that
could arise and decide how the system should respond. If you don’t describe exceptions during
requirements elicitation, either the developers will make their best guess at how to handle them,
or the system will simply fail when a user hits the error condition.
It’s a safe bet that system
crashes aren’t in the user’s plans.To function as an effective analyst, you must think at multiple levels of abstraction. You should be able to generalize from a specific need expressed by one user representative to define a set of related needs that will satisfy many members of that individual’s user class. With
experience, you as a Business Analyst will become skilled in the art of asking questions that probe into the heart of each
issue and clarify (or at least reveal) uncertainties, disagreements, assumptions and implicit expectations.
Prioritize Early and Often
Requirements development is an iterative and incremental process, proceeding from
fuzzy notions to detailed specifications a layer at a time. If you as Business Analyst facilitating an elicitation
workshop, keep the discussion focused on the right level of abstraction for that day’s objectives. Don’t let the participants get bogged down in excessive detail or premature system design. While it can be valuable to sketch out possible user interface screens or build prototypes to clarify the requirements, diving deeply into design too early can lead to a system that fails to meet the user’s actual needs.
It’s discouraging to realize at crunch-time that everything the team has left to do is essential, while they’ve already implemented some features that weren’t really that important. Analysts must work with customers to define the priorities for requested product features, so the team can build the most critical functionality first. All customers will claim that their requirements should have the top priority. Your job as an analyst includes facilitating collaboration and negotiation between the various user classes and the developers to ensure that
sensible priority decisions are made.
Next, work with appropriate representatives of each user class to identify their major use cases. Performing a first-cut prioritization on the use cases will help you determine which ones to explore in detail early on. The top priority use cases are those that are the most important (capabilities the users really need) and the most urgent (capabilities the users need right away). The users might elect to implement only selected portions of certain use cases in the initial release, leaving refinements for later.
Create a Collaborative Environment
Software development is often characterized by strained relationships among developers, users, managers and marketing. The parties may not trust each other’s motivations or appreciate each other’s needs and constraints. In reality, though, the producers and customers of a software product share some common objectives. For information systems development, all parties work for the same company and benefit from improvements to the corporate bottom line.
For commercial products, developers and marketing should strive to meet the purchasing customers’ needs, so they will buy more products and rave to their friends. And contract developers should
try to make the client happy to get repeat business. A win/win outcome means customers are delighted with the product, the developing organization is happy with the business outcomes, and the development team members are proud of the good work they did on a challenging and rewarding project.
It’s not unusual for an Business Analyst to solicit input from users only to be told, “I don’t have time to talk to you. You should know what I need.” However, software success is most likely when the analyst can forge an effective collaborative relationship with key customer representatives (see my article “Requirements and the Software Customer,” Dec. 1999). Identify individuals who could serve as the voice of the customer for each of your system’s user classes, then engage them in dialogs about their needs.
Fine Tune Your Skills
Business Analyst provides the essential function of bridging the understanding and perspective gap that lies between customers and developers.
A competent Business Analyst must combine communication, facilitation and interpersonal skills with some technical and business domain knowledge. Even a dynamite programmer or a system-savvy user needs suitable preparation before acting as an analyst. The following capabilities are particularly important:
- Facilitation techniques, to lead elicitation workshops;
- Interviewing techniques, to talk with individuals and groups about their needs
- Listening skills, to understand what people say and to detect what they might be hesitant
- Writing skills, to communicate information effectively to users, managers and technical
- Organizational skills, to make sense of the vast array of information gathered during
elicitation and analysis
- Interpersonal skills, to help negotiate priorities and resolve conflicts among project
stakeholders; domain knowledge, to have credibility with user representatives and
converse effectively with them
- Modeling skills, to represent requirements information in graphical forms that augment
textual representations in natural language
Bridge the Communication Gap
If you aspire to be an effective Business Analyst ,
become proficient in all forms of communication, including listening, speaking and writing. As you interact with executive project sponsors, marketing and user representatives, understand their objectives for the proposed system and their concerns about the business and the application. Learn and use the vocabulary of the application domain, rather than forcing your customers to understand computer jargon. Include business terms in a project glossary, which should become part of the requirements documentation.
Try to understand the users’ implicit expectations about the system’s characteristics, such as performance, usability, efficiency and reliability. Read more about communication skills here
The Business Analyst is responsible for writing high-quality and well-organized requirements documents that clearly express this shared understanding. Writing documents that customer representatives can understand and verify, while unambiguously conveying precise functional and nonfunctional requirements to the developers, is a tightrope walk. A single requirements document might not meet both needs.