How to Become (or Manage) a Successful Business Analyst
Completing information technology projects on time and on budget is both essential and a struggle for most organizations. Business analysts can help shepherd projects through to successful results by gathering requirements from a business area and presenting them in ways that are understandable and actionable by the organization. Unfortunately, the business analyst’s job description is often vague. While many organizations know what needs to be done, they don’t know how to identify and develop the skills necessary to meet these needs.
As such, we’ve outlined here eight essential competencies necessary for success in this job. For each competency below, we explore the skills, knowledge and abilities inherent to each competency and provide practical tips for using these competencies as guidelines for improving the efficiency of business analysts within any organization. By definition, a competency is made up of three components: knowledge, skill and ability. Knowledge considers “what is being measured?” Skill looks at “how is it done?” Ability examines “to what degree can it be done?”
Competency #1: Eliciting Requirements On the most basic level, the business analyst’s job is to gather and document user requirements. Requirements are needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of business, rather than the constraints imposed by technology. This means that the business analyst’s job has more to do with identifying the desired results than the actions or resources required to reach these results. The purpose of gathering requirements is to provide an understanding of the problem or opportunity before trying to propose the solution.
Competency #2: Creating the Business Requirements Document A Business Requirements Document (BRD) is an exhaustive, written study of all facets of regulatory, business, user, functional or non-functional requirements. It is a detailed profile of primary and secondary users and comes directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD should be written by the business analyst. After the document is completed, the business analyst and the client, or user, meet for a formal review and to formally approve the BRD. The document is then shared with the rest of the development team, including the project manager. In creating the BRD, a business analyst should define the various sources for requirements and the placement and relevancy of these requirements.
For example, senior business analysts may identify such items as the project charter and vision, business case, requirements work plan, vendor request documents and business contract documents. They may also work with the project manager to define the project and product scope. Any requested changes to any area of the BRD, before or after work has begun, must be carefully reviewed by the business analyst who would then work with the client or user to make the necessary changes.
Competency #3: Modeling Modeling refers to the ability to conduct structured analysis. In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organize information into coherent ideas. The most common types of business analysis models include business models, process models, data models and workflow models. Experienced business analysts develop models such as business interaction charts or entity relationship diagrams and examine how the business process works now, in order to develop improved charts and help troubleshoot in the future. When looking at models, the business analyst is looking for problems and opportunities that will change the process or the deliverable.
Competency #4: Object-Oriented Analysis An object model is an abstract representation of the process and data requirements of a system, based on separating the system into units called objects. Each object includes the data and operational characteristics of one business item. Object-oriented analysis is particularly important to business analysts as a business planning tool to depict the hierarchy of business functions, processes and sub-processes within an organization. Generally speaking, individuals working on object-oriented analysis should be competent in structured analysis.Object-oriented analysis requires a clear understanding of both the process and data modeling techniques, including the ability to separate systems into objects. Junior business analysts may get involved in the functional separation of the as-is state of a project, including forming a simple model of this state. From this model, an intermediate business analyst may consider developing activity diagrams to further clarify requirements. With diagrams in hand, a senior business analyst is likely to begin designing the to-be state during one-on-one interviews, group interviews and the documentation process. Essentially, each of the processes involved in object-oriented modeling ensures that the requirements are properly communicated to the developers and administrators.
Competency #5: Testing When it comes to testing in business analysis, the first thing to understand is that the term applies to several different levels of work. First, business analysts are looking to test the products to validate whether the requirements have been met. They develop test scripts, test plans and test scenarios based on the as-is state as well as the to-be models. Testing requirements should be done in recurring stages to ensure that, by following the requirements, the desired deliverables will be met. The second level of testing is more familiar. This is testing the functionality of the physical product – testing lines of code and user testing of graphical appeal, speed and functionality. Black box testing and glass box testing fall into this category. As with the first type of testing, this testing also makes sure we reach the desired state, but it is based on user acceptance. In testing situations, business analysts design test cases and review the results from these scenarios.
Competency #6: End-User Support It’s a common misconception among project teams that the project ends when the deliverable is completed. This isn’t true. Business analysts should be aware that end-user support after the product is delivered is almost as important. The role of the business analyst is not to act on behalf of the training team, but to complement the training team’s efforts with their knowledge of the business requirements. Much of the documentation created in the process of identifying the deliverables is invaluable to the development of training needs and end user support, including user manuals and reference materials. Business analysts work with end-users after deployment to clarify any high-level questions that need to be addressed. They also work closely with training managers and facilitators to define requirements to deliver the training supporting the business needs. Finally, business analysts assess and evaluate all feedback from team members, those individuals involved in the deployment of the product and any pilot or “test” groups, to ensure that the requirements necessary to correct any issues are addressed in future releases, iterations or versions of the product.
Competency #7: IT Fluency How much IT knowledge is enough for a business analyst? The IT background for a competent business analyst depends entirely on the environment and possibly the industry vertical within which he or she works. It’s important to remember that IT fluency is just one of eight competencies that a successful business analyst must have. Also, just because an individual is fluent in a given technology does not automatically qualify him or her as a business analyst. This is a mistake made by many organizations. In theory, a great business analyst should have the wherewithal to understand which resources would be appropriate to help define and validate both requirements and specifications within a given project and product scope. In examining the different stages of a business analyst, a person at the junior level would need to have a clear understanding of the IT products and tools necessary for the business to function. An intermediate business analyst may understand interconnectivity and relationships between the tools and, perhaps, system architecture and information architecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical. He or she may also have a very clear understanding of how different IT products are related, interface with and connect to each other, as well as the positive or negative impact they may have in a given situation.
Competency #8: Business Process Re-Engineering Considered the “big-picture thinking” of business analysis, Business Process Re-engineering (BPR) is a rapidly growing part of business analysis. In fact, lately many companies have been grouping business analysts around this specialty and developing teams of process analysts. This is the phase in which business analysts seek out both problems and opportunities. BPR uses a variety of modeling techniques in order to look at the bigger picture, while still thinking tactically. Business analysts’ responsibilities are often to identify, using various modeling techniques, possible areas of improvement to walk the client or user through each step of the process, examining individual tasks that could potentially be improved and then to actually make suggestions for improvements.
You’ve Defined the Competencies . . . What Next? Now that the competencies have been spelled out, how do companies go about developing business analysts? First, they must develop and document specific job functions, and the task or tasks related to a particular level of competency. Next, they should assess existing knowledge. Finally, they must provide the training needed to develop the competencies outlined above. The first step in ensuring that an organization’s business analysts have the knowledge, skills and abilities necessary for success is to develop job functions, associated tasks and activities, and expected inputs and outputs, that would in turn support an organizations defined competency. When job descriptions have been determined and approved, it’s essential that organizations “take inventory” of the competencies their business analysts already possess. There are specific assessments to test these competencies. Such tools will establish the knowledge level of individuals in each competency area and of the team as a whole. If knowledge isn’t base-lined, improved cannot be observed, and overall performance for the individual and the organization. After establishing the business analysis knowledge and ability levels within an organization, the next step is to implement training to improve any competencies that may be lacking. The competencies above can also serve as a validation tool for such training. They can be used to ensure that the performance improvement program is comprehensive, that no behaviors or competencies are missed, through proper training, on the job experience as well as the appropriate coaching and mentoring. Keeping in mind the eight competencies, as well as the necessary people, processes, tools and technology, will put an organization on the path to better business analysis and, ultimately, to more successful projects.