CBAP / CCBA Certified Business Analysis Study Guide

Chapter 1

Foundation Concepts

CBAP®/CCBA™ EXAM TOPICS COVERED IN THIS CHAPTER

Describe business analysis and the role of the business analyst.

Explain the Business Analysis Core Concept Model (BACCM™).

Explore the six business analysis knowledge areas.

Recognize the basic contents, structure, and intent of the BABOK ® Guide.

Define the BABOK ® Guide requirements classification scheme.

Map business analysis activities to a generic project life cycle.

Understand the content and intent of the BABOK ®Guide.

   This chapter lays the foundation for navigating and understanding the content and intent of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). It is our high-level look at what it means to be a business analyst and how to successfully perform business analysis work. Business analysts can be found in all facets of an organization—projects, programs, strategic planning, operations, or other initiatives. Although the examples in this chapter use projects and the project life cycle to step through the discipline, remember that business analysts do not have to be members of a project team to do their jobs. They can work almost anywhere.

The set of generally accepted best practices defined by the BABOK® Guide provides a business analysis framework defining areas of knowledge, associated activities and tasks, and the skills required to perform them. The scope of this standard covers pre-project activities, the full project life cycle, and the final product’s operational life.

What Is Business Analysis?

Let’s start with an example of how difficult it can be to do business analysis work when you are not certain where to begin. New business analysts start their careers in a number of ways. In the past, it was not uncommon for young software engineers to transition into the business side of an organization when their manager called them into their office, saying, We are short-staffed, and I need you to figure out what the users need this new software application to do. The fledging business analyst needed to discover who to talk to, what to ask, how to ask, and how to document the information that they discovered in a way that made sense to the development team and to the business. This was not an easy task the first time around!

In this situation, performing basic business analysis work took a lot longer than it seemed like it should. These unprepared rookie business analysts had great difficulty deciding exactly how to get started. There was no process in place to guide them and no one available to point them in the right direction. They found themselves longing to go back to their cubicles and just write some more code. Luckily, there is no need for business analysts to feel this way today. There are standards, books (like this one), websites, blogs, and tons of experienced folks out there to mentor and guide business analysts in getting the job done right.

Business analysis is the glue that holds successful organizations together. It is a distinct discipline focusing on identifying business needs, problems, and opportunities, and on determining the appropriate solutions to address them. The resulting projects and initiatives may focus on systems development, process improvement, organizational change, or some combination of the three. Business analysis touches all levels of an organization: strategic, tactical, and operational. Business analysts participate across the project and the product life cycles as they look at all aspects of an organization’s enterprise architecture, stakeholder needs, business processes, software, and hardware.

The set of generally accepted best practices defined by the BABOK® Guide make this book an essential resource for every business analyst. You should take this basic business analysis framework and make it work for you and your projects. The areas of knowledge, associated activities and tasks, and the skills required to perform them will give you a valuable starting point for introducing, validating, or improving your business analysis processes throughout an organization. Even better, the scope of the BABOK® Guide covers pre-project activities, the full project life cycle and the final solution’s operational life.

The BABOK® Guide focuses on building underlying competencies that make for a successful business analyst on today’s projects and initiatives. The BABOK® Guide defines business analysis as the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Put simply, a business analyst is defined as anyone performing these business analysis activities.

When looking at business analysis in an organization, you need to make sure that you know how the organization views its business analysts. First, what is the role of the business analyst? Second, what is the expected relationship between the business analyst and the project manager? And third, who are the stakeholders with whom the business analyst will be interacting along the way? We will look at each of these topics next.

The Business Analyst’s Role

The linchpin of successful business analysis is the business analyst performing the actual work. Their involvement in defining and validating solutions that address key business needs and goals is essential to both project and business success. According to the BABOK® Guide, "a business analyst is any person who performs business analysis tasks described in the BABOK® Guide, no matter their job title or organizational role." Business analysts work as liaisons among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.

So, what exactly is the job description for the business analyst? There have been many job postings lately that came straight from the BABOK® Guide role definition. That is a good sign. The adoption and integration of these principles as best practices in the corporate environment will lead to stronger business analysis process, better business analysts, and more credibility and consistency in the role of business analysts today. Here is a short list of the business analyst’s job responsibilities from the BABOK® Guide:

Discovers, synthesizes, and analyzes enterprise information

Understands enterprise problems, opportunities, and goals in the context of the requirements

Analyzes needs and solutions

Devises strategies and drives change

Facilitates stakeholder collaboration

In many organizations, the folks performing business analysis work do not have the job title of business analyst. The business analyst role can be filled by anyone performing business analysis work regardless of job title. The BABOK® Guide lists a number of job roles that may do business analysis work, such as business system analysts, requirements engineers, process analysts, product managers or owners, enterprise analysts, business architects, and management consultants.

Essential Skills of Effective Business Analysts

Business analysts must possess a wide spectrum of skills and knowledge. Being a technical expert in a particular area does not guarantee success as a business analyst on a project. In addition to the necessary business, technical, and domain knowledge, the business analyst should have management, interpersonal, business, and structured problem-solving skills.

Reviewing Requirements over a Cup of Coffee

Years ago, Phil was the technical team lead for a team working on an executive compensation system for top-level management. The team needed input from a small, closed community of senior and executive management customers in order to define the current and future processes. Unfortunately, his key contact from this group felt that the job of customer interface had been given to a young, up-and-coming star who didn’t have a clue. This made developing a rapport with the key customer contact almost impossible. However, the project deadlines remained inflexible, as they usually do.

Taking what little input was offered and doing significant research from other sources, the team compiled their draft of the business requirements document. The document was huge. It was single-spaced and double-sided, and it filled a 3-inch binder. There was a meeting to step through it. The customer contact was there and took her place at the head of the table. Phil sat at the opposite end of the table.

During the meeting, the customer’s demeanor grew increasingly agitated. She hurled the requirements document down the table along with the exclamation, I don’t do this kind of menial work. Unfortunately, Phil reacted by returning the document in the same manner. His aim wasn’t quite as true, and the document slammed into her coffee cup sending a spray of hot, sugary liquid into her lap. Her color changed from the red of aggravation to the scarlet of rage. She stalked out of the room. So much for creating rapport with the customer! In the end, it all worked out. Both parties apologized, and the project (meeting the business requirements that had been approved) was delivered. But how much better things could have been if this situation had been avoided in the first place.

Technical skills and expertise are necessary on the project team, but they are not the skills and knowledge that separate effective business analysts from the pack. Superior business analysis skills are not necessarily derived from a superior set of technical skills.

Soft skills and knowledge support and enable effective business analysis. Knowing what to do and when to do it is a good start for a business analyst, but how you actually do that work makes a big difference! The BABOK® Guide refers to these behaviors as the underlying competencies of effective business analysts. The underlying competencies are in addition to knowing what business analysts produce from a work activity and a deliverable perspective. They encompass the interpersonal skills and additional business and technical knowledge that are necessary for doing the business analyst’s job well. These essential skills range from applying structured analysis techniques to issue management to addressing solution usability concerns.

The BABOK® Guide puts the essential skills and knowledge of effective business analysts into six categories. Let’s take a quick look at each of these categories that are the building blocks for the business analyst’s skill and knowledge.

Analytical Thinking and Problem-Solving Skills Facilitating solutions to business problems would be impossible without a logical mind. Analytical thinking and problem-solving skills enable the business analyst to assess and understand a situation. Once that situation is fully understood, the business analyst assesses and recommends one or more potential solutions to address the business need, problem, or opportunity.

Behavioral Characteristics Effective business analysts apply personal integrity and strength of character when dealing with people, including the business analysis team, project team, and internal and external project stakeholders. The ability to build strong, lasting working relationships serves the business analyst, the enterprise, and the project or initiative well.

Business Knowledge It is impossible to be a liaison between the business and the technology if you have no understanding of the business. Skilled business analysts understand the internal and external business environment surrounding their projects, and they use that knowledge to make good decisions and recommendations.

Communication Skills The number-one reason for project failure is poor communication. Business analysts must have excellent communication skills, verbal, nonverbal, and written, in order to complete business analysis tasks.

Interaction Skills Good business analysts are team players. In large part, this is because of their ability to interact and work well with other members of the team. Leadership, negotiation, and facilitation skills play a key part in defining and agreeing to a solution to a business problem or need.

Tools and Technology Software applications are typically used by the business analyst to develop and manage requirements. This can range from using a word processor to document project scope to using a requirements management tool to develop detailed user and system requirements. Although using a requirements management tool is not a required skill, the ability to master and apply requirements management, word processing, and spreadsheet tools are desirable traits in experienced business analysts.

The underlying competencies of effective business analysts have numerous pieces and parts. In Chapter 8, Underlying Competencies, we will discuss them in more depth along with a few additional skills that you might want to use on your projects.

The Business Analyst and the Project Manager

There is much buzz about the potential for overlap and conflict between the project manager and the business analyst. Interestingly enough, many project managers perform business analysis work early in their projects—developing feasibility studies, business cases, scope statements, and business-level requirements as part of project selection, initiation, and scope definition. Many project managers were part of the business analysis team earlier in their careers. As a result, many project managers have business analysis skills to complement and overlap their project management skill set.

The project manager’s responsibilities differ from the responsibilities of the business analyst in several ways. The project manager focuses on meeting the project objectives. They initiate, plan, and manage the project. The project manager makes sure the project team delivers a solution that meets requirements, the acceptance criteria, and the customer’s quality expectations. The project manager juggles the many constraints present on a project, such as scope, budget, schedule, resources, quality, and risk. On a large project, the business analysis team is only one part of the project resources the project manager is managing.

The business analyst and the project manager typically work closely together on projects and must maintain good communications. However, there is potential for the project manager and the business analyst to be in conflict with one another. The business analyst works with key stakeholders to understand the structure, policies, and operations of an organization and to recommend solutions. The project manager focuses on planning and managing the project to achieve the project objectives and deliver those solutions to the stakeholders. Where are they going to step on each other’s toes? There are two key areas for conflict: stakeholder communication and planning.

The project manager and the business analyst both need to communicate well with key stakeholders. Without planning and discussion, the project manager and the business analyst could easily come to blows about who owns the stakeholders, when in actuality the project owns the stakeholders. A good project-level communications plan needs to be built and followed to minimize potential areas of political game play and conflict. As far as planning goes, the business analysis team must remember that it is a subset of the project team. As such, any business analysis work plans they put together must be consistent with and roll up into the overall project plan.

Dealing with Key Stakeholders

There is no project without stakeholders. Stakeholders have a vested interest in the project and its outcome, and they are the major source of requirements, constraints, and assumptions for the business analyst. Remember that stakeholder roles are like hats—one person may wear multiple hats and fill more than one role on a project.

There are a number of generic stakeholders who will interact with the business analyst across the project life cycle. While the list in Table 1.1 doesn’t cover every possible role, it is a good starting point for who should be involved with your business analysis activities. Many organizations have different names for the same role, so don’t get excited if these are not the generic stakeholder roles with which you are familiar. In addition to the business analyst, there are a number of key stakeholder roles involved with business analysis activities. They are summarized in Table 1.1.

TABLE 1.1 Key business analysis stakeholders

Exam Spotlight

These stakeholder role names and definitions from the BABOK® Guide are exactly what you will see in your exam questions. The business analyst is a stakeholder for all business analysis activities and is responsible and accountable for their execution. Remember that stakeholder roles are like hats. One person can wear one or many hats across the project life cycle. The roles are not necessarily the same as their job titles; however, they do indicate the job responsibilities and the level of accountability for the person filling that particular role on a project.

Reviewing the Business Analysis Core Concept Model (BACCM™)

The Business Analysis Core Concept Model (BACCM™) provides you with a conceptual framework that shows what it really means to be a business analyst. This framework creates a common, generic language describing the business analysis profession. You can use this common language to discuss what you do with a business analyst working in a different industry.

There are six concepts in the BACCM™: change, need, solution, stakeholder, value, and context. You need to understand all of these concepts in relation to one another to be an effective business analyst. They are the framework for a successful business analysis effort.

Change Change is the driving force for most projects and initiatives. Change takes place when one responds to satisfy a need. You need to be aware of the enterprise-level changes that will result from your project efforts and outcome.

Need Businesses and their stakeholders have needs that often result in projects. Needs are value-driven ways to address business problems or opportunities.

Solution Solutions are the end result of projects and initiatives. They resolve the problems or take advantage of the opportunities. Solutions satisfy needs within the context of the enterprise and its environment.

Stakeholder Stakeholders are the people who have a relationship to the change, need, or solution. Stakeholder analysis often groups stakeholders relative to these relationships.

Value Value is the worth of something to a stakeholder within the context of the enterprise. Business analysts assess value as a tangible or intangible thing. Business analysts should assess value from the key stakeholder’s point of view.

Context Context is the environment where the change is taking place.

The BACCM™ and its six concepts help you assess the quality and completeness of the work you are doing. As you will see, the concepts intertwine as you work through a project. A change that affects the tasks, tools, inputs, or deliverables covered by one of the concepts presents an opportunity for reevaluation of the impact on the other five concepts. The magnitude of the change, as well as where you are in the project life cycle, determines how significant the changes may be. The effects can be felt both in your current projects and in what may need to change moving forward.

Exploring the Business Analysis Knowledge Areas

The BABOK® Guide is based on a set of knowledge areas guiding the business analyst when they perform business analysis activities at any point in the project or product life cycle. Knowledge areas define what business analysts need to understand and the tasks they should perform. They do not represent project phases, and their activities are not intended to be performed in a linear fashion. Tasks from one or more knowledge areas may be performed in any order (such as in succession, simultaneously, or iteratively), provided that the necessary inputs to each task are available.

Six knowledge areas are defined by the BABOK® Guide. If you are planning to take the Certified Business Analyst Professional (CBAP®) or Certification of Competency in Business Analysis (CCBA™) exam, you will need to memorize the high-level definition of each knowledge area, as well as the more detailed tasks, elements, inputs, and outputs. If you are interested in applying these knowledge areas to your work world, you will need to master the tasks and the skills in order to become an effective business analyst. Figure 1.1 shows the relationships between the six knowledge areas listed here:

Business Analysis Planning and Monitoring

Elicitation and Collaboration

Requirements Life Cycle Management

Strategy Analysis

Requirements Analysis and Design Definition

Solution Evaluation

FIGURE 1.1 Relationships between knowledge areas

Knowledge Area: Business Analysis Planning and Monitoring

In the Business Analysis Planning and Monitoring knowledge area, a business analyst plans how to approach the business analysis effort. The approach is a set of processes, templates, and activities used to perform business analysis in a specific context. The tasks organize and coordinate the performance of all other business analysis tasks. These planning and monitoring activities take place throughout the project life cycle. The results of this knowledge area guide the tasks found in the remaining five knowledge areas and set the performance metrics to be used to evaluate all business analysis work.

So, what is a business analyst to do? Well, the business analyst’s task list for this particular knowledge area consists of the following:

Planning the business analysis approach for the project

Determining how to engage stakeholders, including stakeholder identification, analysis, and categorization

Defining the business analysis governance activities for decision making

Addressing business analysis information management needs

Planning the requirements development and management process

Managing and reporting on the business analysis effort

Knowledge Area: Strategy Analysis

Strategy Analysis focuses on how the business analyst identifies the business needs driving a project by performing problem definition and analysis. In addition to defining and refining these strategic or tactical needs, the business analyst is responsible for defining a feasible solution scope that can be implemented by the business. This work may also include developing a business case or feasibility study for a proposed project. Typically, the tasks in this knowledge area occur prior to or early in the project life cycle. The business analyst’s task list for this knowledge area includes translating business strategy into proposed new business or enterprise solutions by doing the following:

Defining and understanding the business problem or opportunity

Assessing capability gaps in the organization by analyzing the current and future states

Assessing risks relative to the proposed solution

Defining the change strategy for the initiative

Determining the most feasible business solution approach

Knowledge Area: Requirements Life Cycle Management

Requirements Life Cycle Management defines how the business analyst approaches managing and maintaining requirements. Tasks and techniques for managing changes, conflicts, and issues related to requirements are also described. Business analysts perform requirement management tasks as part of requirements development work by doing the following:

Managing requirements traceability

Maintaining requirements for accuracy and reuse

Addressing requirements prioritization

Determining how requirements should change

Facilitating requirements approval

Knowledge Area: Elicitation and Collaboration

Elicitation and Collaboration defines how business analysts work with stakeholders to elicit requirements and understand stakeholder needs and concerns. This knowledge area also addresses ongoing collaboration and communication during all business analysis activities. The business analyst’s task list for this knowledge area consists of the following:

Preparing for elicitation activities

Meeting with stakeholders to conduct the elicitation activity

Confirming, documenting, and recording the elicitation results

Communicating and confirming elicitation results with key stakeholders

Knowledge Area: Requirements Analysis and Design Definition

Requirements Analysis and Design Definition describes how the business analyst progressively elaborates to define, refine, prioritize, and organize requirements. In essence, the business analyst takes the elicited information and makes sense of it to derive the real requirements for the project. This knowledge area also focuses on graphically modeling the requirements and resulting designs as well as documenting them. When performing these tasks, the business analyst should ensure the feasibility of the requirements while defining, describing, and refining the characteristics of an acceptable solution. The business analyst’s task list for this knowledge area consists of the following:

Specifying and modeling requirements and designs

Verifying requirements and designs

Validating requirements and designs

Defining the architecture and structure of requirements

Defining solution options

Analyzing value and recommending a solution

Knowledge Area: Solution Evaluation

Solution Evaluation focuses on assessing and validating proposed, in progress, and implemented solutions before, during, and after the project life cycle. A business analyst’s attention is on the value that the solution will deliver to the enterprise, including the constraints that may impact value. While many tasks in this knowledge area take place later in the project life cycle, some solution-focused activities may occur quite early. The business analyst’s task list for this knowledge area consists of the following:

Defining solution performance measures

Collecting and analyzing solution performance data

Assessing solution limitations

Assessing enterprise limitations

Recommending actions to increase solution value

You will examine each knowledge area and every task within it in great detail in the coming chapters. You will need this level of knowledge to successfully prepare for and pass the certification exam. You will also need this level of knowledge to be an effective business analysis practitioner in your organization.

How Are the Knowledge Areas Organized?

The BABOK™ Guide breaks down knowledge areas into tasks that specify what work business analysts need to perform. The business analyst can dip into one or more tasks at any time—in any order—to select a deliverable or learn to apply a particular technique. The knowledge areas are not a road map or a methodology; they simply break business analysis stuff into common areas.

To achieve the purpose of a particular knowledge area, the business analyst must perform a defined set of high-level tasks. Each task has a particular purpose and adds value to the overall effort when performed. The expectation is that a business analyst will perform each task at least once during any project. Each knowledge area task is broken down into the following pieces:

Purpose

Description

Inputs

Elements

Guidelines and Tools

Techniques

Stakeholders

Outputs

The content of each task is defined using the same structure. Let’s take a closer look at this structure now.

Purpose Each task starts off with a short description of its purpose: why that task is needed and what value performing the task creates.

Description The task description explains a task to the business analyst in greater detail, including what the task actually is, why the task is performed, and what the task should accomplish.

Inputs Inputs consist of the information and preconditions tasks require so that task can begin. These inputs must be usable by the task that needs them. Single or multiple business analysis tasks produce inputs externally.

Elements Elements are the detailed concepts that are necessary to perform a particular task. For some tasks, the elements are categories of things a business analyst must consider. For other tasks, the elements are subtasks a business analyst performs.

Guidelines and Tools Guidelines and tools list resources a business analyst uses to transform a task input into the resulting task output. Guidelines provide instructions to the business analyst for executing a task. Tools provide things the business analyst can use to perform the task.

Techniques Techniques guide the business analyst in the ways a particular task might be done. The techniques in the BABOK® Guide are best practices that many business analysts use. However, business analysts can certainly use techniques that are not found in the BABOK® Guide.

Exam Spotlight

When you are reviewing and learning the techniques from the BABOK® Guide, make sure you don’t miss anything! Techniques are summarized in Appendix C, Mapping Techniques, Stakeholders, and Deliverables to Knowledge Areas and Tasks, of this book and are defined in Chapter 10 of the BABOK® Guide. They can be used by any task, and many are used by more than one task.

Stakeholders All tasks come with a generic list of stakeholders who may be involved in performing that task or who might be affected by the task and its outcome. Interestingly enough, the business analyst is a stakeholder for every business analysis activity found in the BABOK® Guide. This makes perfect sense—the business analyst is responsible and accountable for making sure that these tasks are done and done well. Remember that earlier in this chapter we took a look at the key generic stakeholder roles that typically interact with business analysts on their projects.

Outputs Outputs are the results that successfully completed tasks deliver. One task can have a single or many outputs.

Exploring Requirements

Projects are successful when stakeholders, including business analysts, clearly state and agree upon desired accomplishments. For most projects, this statement consists of defining the high-level scope of the project along with its more detailed project requirements. The general definition of a requirement is something wanted or needed. Business analysts in many organizations spend a lot of time developing requirements. This is a good thing. Defining and documenting requirements allow a business analyst to quantify and document the needs, wants, and expectations of project stakeholders.

The BABOK® Guide uses the term requirement to cover many aspects of the business and its needs. Their broad view of requirements addresses both the current state of the business and its desired future state. Requirements may focus on the business, the users, or the systems and subsystems that already exist or are being considered. Requirements range from high-level enterprise capabilities to organizational structure and roles to processes and policies. Information systems fall into the requirements realm, as do business rules. Requirements analysis activities are also quite broad in nature. There is no prescription for the correct level of detail in your project requirements other than what is sufficient for understanding and subsequent action.

Distinguishing Between Requirements and Design

Requirements and design are closely linked. Many times, the distinction between requirements and design is unclear. Business analysts will use the same techniques to elicit, model, and analyze requirements and designs on their projects. Figure 1.2 shows the relationship between requirements and design in the BABOK® Guide.

FIGURE 1.2 Requirements and design cycle

For the exam, remember that requirements focus on defining the opportunity or need to be addressed. Design focuses on the solution that will result from addressing that opportunity or need. When a business analyst is defining and documenting project requirements, the business analyst is building a usable representation of a need. When the focus of specifying and analyzing elicitation results is on the solution, the outputs being produced are referred to as designs.

Exam Spotlight

Remember that requirements focus on the need, and designs focus on the solution that will address that need.

Defining the Requirements Management Process

The requirements management process is a detailed subset of the business analysis approach, targeting how the team performs requirements development activities for a project. The process should be documented in the requirements management plan. This deliverable defines many things, including the following:

How the team will deal with requirements traceability

The explicit process for developing requirements

How requirements will be prioritized

What requirements attributes will be collected

How changing requirements will be handled both during requirements development and after the requirements are agreed upon and baselined

Who will review and approve requirements and any requested changes

In addition, the requirements management process defines the types or classes of requirements found on the project. Often, these requirements classes are associated with a particular requirements document. Classifying requirements allows the business analysis team to make sure that their project requirements are reviewed and understood by the correct stakeholders. Requirements classes help you determine the appropriate level of detail and the specificity needed in the project requirements, and they help you decide how many documents you will use to define what is needed.

Requirements classes can be defined using two dimensions: focus and type. Requirements classified by focus tend to be named in a more traditional way. Here are some