3

BUSINESS ANALYSIS PLANNING

3.1 Overview of this Section

Within business analysis, planning consists of the activities that are performed in order to ensure that the optimal business analysis approach is selected for the project and that:

• Stakeholders are thoroughly identified and analyzed;
• Business analysis activities and deliverables are defined and agreed to;
• Processes that will be used for validating, verifying, and approving requirements and solutions are acceptable to key stakeholders;
• The process for proposing changes to requirements is defined and understood; and
• Key stakeholders are aware of and support the activities and time commitments required to complete the requirements effort.

The business analysis approach is simply the method the business analyst uses when managing and performing the business analysis activities on the project. As described later in this section, the approach is described within the business analysis plan.

How business analysis planning is conducted is heavily dependent on the selected project life cycle; therefore when a planning activity is performed differently across life cycles or not performed at all, the differences are noted in this section. There is no one approach to business analysis planning that will work for every project, so ultimately the business analyst should understand the context and project characteristics enough to ensure the planning activities are sufficiently sized for the situation.

This section describes the important things one needs to think about when defining the business analysis approach. The level of thought described in this section applies to all programs and projects whether it is performed all at once at the forefront of the project or throughout the project, regardless of the degree of formality used to document the business analysis plan.

3.2 The Importance of Business Analysis Planning

Planning the business analysis work is critical for project success. When business analysis planning is bypassed, it is difficult to understand the scope of work, stakeholder's expectations, and the appropriate amount and level of business analysis required for the project. This in turn makes the estimation process difficult and can result in unrealistic expectations by those involved in the requirements-related activities. Business analysts who begin elicitation sessions without a well thought out roadmap of how they will address the work will often find themselves pressed for time and rushing through activities to meet a schedule to the detriment of the project.

3.2.1 Rationale

Because requirements are the foundation from which the project is based and a key contributor to project success, the sponsor and project manager should ensure that a sufficient level of business analysis planning is conducted. Many projects are initiated with tight timelines that place pressure to address the tactical activities before the plan. The project team should avoid the urge to rush into requirements elicitation without first understanding the expectations for the business analysis process and the roadmap for pursuing the work.

Business analysis planning achieves the following:

• Sets expectations with the sponsor, project team, and key stakeholders as to the business analysis activities that will be performed;
• Ensures that roles are identified, understood, and communicated to everyone participating in the business analysis process;
• Achieves buy-in and support for the business analysis process before work begins;
• Provides context to support estimation of the business analysis activities; and
• Produces a more efficiently run business analysis process, because activities are not missed or excessively performed.

While planning provides many benefits and reduces a number of requirements-related risks, planning work should be judiciously performed to ensure the process is not too heavy or formal for the needs of the program or project. It may not be necessary or advisable to plan entirely up-front and in great detail on every type of program or project. When using a predictive life cycle, planning is performed up-front prior to elicitation. In adaptive life cycles, some planning is performed up-front and plans are adapted or evolve over the course of the program or project. Too much planning can be counterproductive, therefore the business analyst needs to plan a sufficient level of detail to address the specific needs of the project such as the size, complexity, and risk level.

3.2.2 Business Analysis Planning and Project Management Planning

Business analysis is a critical portion of the overall project activities. The work involved to perform a successful business analysis process is detailed and the number of activities conducted can be quite extensive. Program and project success is dependent on adequate business analysis; therefore, attention should be given to ensure that activities are well thought out and meet the needs of the program or project and the stakeholders.

Business analysis planning and scheduling is not performed independent of project management scheduling activities. It is a best practice to have the project manager and business analyst working closely together while the business analysis approach and plan is formulated. Business analysts will develop a work plan to cover the activities they are responsible for performing; however, the work plan should be integrated into the overall project management plan managed by the project manager.

3.3 Conduct or Refine the Stakeholder Analysis

A stakeholder is an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a program or project. Stakeholder analysis is a technique used to systematically gather and analyze quantitative and qualitative information to determine whose interests should be taken into account throughout the project.

Stakeholder analysis is often conducted during the planning phase so that the project team can understand the stakeholder impacts and influences on the business analysis process as early as possible. Stakeholder analysis is performed iteratively and is revisited throughout the project as new stakeholders are discovered or existing stakeholders are determined to no longer be impacted by the proposed solution. Early planning will produce the initial stakeholder list, but further stakeholder identification will maintain the list. When there are a large number of stakeholders identified, stakeholder analysis may involve grouping the list by common characteristics which helps to streamline analysis.

Project managers use stakeholder analysis to assess how the stakeholder groups will influence and impact the project work. Business analysts use the results to understand how the stakeholders will impact the business analysis process. The business analyst considers a number of stakeholder characteristics before determining how to best conduct the business analysis activities. Both roles assess stakeholders to understand how to communicate, collaborate, manage, and set expectations.

Collaboration Point—How project managers and business analysts collaborate and work together on stakeholder analysis varies by organization, but it is more efficient if they work collaboratively with their project and product teams to avoid duplication of effort. Collaboration will also provide a more insightful examination of stakeholders as the experiences and expertise of all participants are leveraged to identify project and product impacts.

3.3.1 Techniques for Identifying Stakeholders

There are various techniques that can be used to uncover and analyze stakeholders. Using a variety of techniques helps to draw out the information from different perspectives and angles. The discovery approach may be as simple as asking other stakeholders for input. Existing documentation, such as organizational charts or process flows, can help to identify user groups. Common techniques that can be used in the discovery of stakeholders are brainstorming, decomposition modeling, interviews, surveys, or organizational modeling, to name a few.

3.3.1.1 Brainstorming

Brainstorming is a data gathering technique that can be used to identify a list of ideas in a short period of time (e.g., list of risks, stakeholders, or solutions to issues). Brainstorming is conducted in a group environment and is led by a facilitator. A topic or issue is presented and the group is asked to generate as many ideas or solutions as possible about the topic. Ideas are provided freely and rapidly and all ideas are accepted. Because the discussion occurs in a group setting, participants feed off of each other's inputs to generate additional ideas. The responses are documented in front of the group so progress is continually fed back to the participants. The facilitator takes on an important role to ensure all participants are involved in the discussion and to ensure no one individual monopolizes the session or critiques or criticizes the ideas that are offered by others.

Brainstorming is comprised of two parts: idea generation and analysis. The analysis is conducted to turn the initial list of ideas into a usable form of information. In business analysis planning, brainstorming can be leveraged to build the initial list of stakeholders, to discover new stakeholders, or to identify a list of tasks to be included in the business analysis work plan.

3.3.1.2 Organizational Charts

An organizational chart helps with stakeholder discovery. The business analyst reviews the chart to locate stakeholder groups who may be impacted by the product or service. This may include departments who operate or maintain a system, produce a product or service, support customers, or influence product or service decisions within the area under analysis.

Whether existing organizational charts are used as the starting point or the charts are built from scratch, the work to finalize the chart is completed through a series of discussions with the managers of the departments being modeled. Based on the size of the organization and how the organizational charts are being leveraged during the analysis, the business analyst determines whether it makes sense to take a role organizational chart down to the individual stakeholder level. If the goal is to only identify the number of groups impacted by the project, the role organizational chart may be the sufficient level of detail required.

The business analyst should keep in mind that roles may be conducted differently across the organization and may vary regionally or by type of customer supported. Additionally, stakeholders from the same group may use a product or service differently. When differences are identified during analysis, the model should be updated to reflect a role for each of the variations discovered. The ultimate goal is to uncover all of the stakeholders who have needs to be met by the product or service and may have requirements to provide for the product or service. An oversight of just one role type can result in implementing a solution that fails to meet the needs of hundreds or even thousands of customers.

3.3.2 Determine Stakeholder Characteristics

After developing or refining the stakeholder list, the business analyst analyzes the characteristics for the stakeholders identified. The list of characteristics is almost endless, so the analyst will choose those that have the most significance or most relevance to the project. Some commonly applied characteristics along with a brief explanation of their importance and significance for consideration are as follows:

3.3.2.1 Attitude

Consider analyzing stakeholder attitudes to identify which stakeholders support the project and proposed solution and which stakeholders do not. Stakeholders who are positive about the project and solution may serve as project champions; these stakeholders will assist the project team in building excitement and support for the solution. Identifying nonsupportive stakeholders can help identify areas where additional collaboration is needed. Spending more time with these stakeholders may uncover unspoken business needs, requirements, training issues, resource constraints, or past and current experiences important for the project team to understand. Uncovering stakeholder likes and dislikes may even bring to the forefront unspoken concerns about the proposed business analysis process.

Attitudes are not solely based upon likes and dislikes for the project. A stakeholder who exerts dislike or disinterest in a project may simply see no value in the initiative or final solution. The stakeholder group may be included in the project because its business processes are impacted, but these stakeholders may not be recipients of direct value from the work. Stakeholder groups may be recipients of additional work after a project is implemented and therefore never display a high level of interest. Those stakeholders whose workload is likely to increase may never become supportive of the project. Understand the concerns of the disinterested stakeholders and look for ways to obtain their engagement despite the lack of support the stakeholder may have toward the project.

3.3.2.2 Complexity

A stakeholder group can be considered complex for a number of reasons, including but not limited to whether the group

• Is comprised of a large number of stakeholders,
• Is made up of stakeholders with vastly different needs,
• Has a number of business processes impacted by the project,
• Exhibits a lack of uniformity across business processes,
• Interacts with a number of business units to complete their work, or
• Performs work across a number of IT systems, and/or systems external to the organization.

Understanding complexity levels will help when quantifying and planning the number of requirement sessions to conduct, when determining the right amount of requirements-related documentation to produce, and when determining the level of formality to apply in those deliverables. Complexity levels are also helpful to understand when assessing solution options and the change impacts that a project will have on stakeholder groups.

PMI's Pulse of the Profession® In-Depth Report: Navigating Complexity⁵ identified multiple stakeholders, followed by ambiguity in project features as the top reasons for project complexity (see Figure 3-1). By understanding the factors that drive complexity on projects and among various stakeholder groups, the business analyst is able to more effectively plan the best approach for conducting the business analysis work, including selecting the best techniques for eliciting and analyzing the product requirements.

Collaboration Point—Project managers are interested in understanding the complexity level of the project in order to allocate sufficient time for project activities, including collaboration and communication with stakeholders. The business analyst assesses complexity to understand how best to approach business analysis activities and to understand the impact that the change will have on stakeholders.

3.3.2.3 Culture

Consider the cultural diversity that exists among stakeholders and make necessary adjustments to the business analysis process to ensure these differences are considered. Many aspects of culture may be worthy of analysis, including age, nationality, or group, departmental, or organizational culture. Culture can impact how the business analyst proposes communicating with stakeholders, eliciting requirements, conducting requirement walkthroughs, and running the prioritization, approval, and change processes. Culture and location are not the same thing. Even when all the stakeholder groups reside in one location, there are cultural differences among the groups. Cultural differences impact how stakeholders:

• Perform their work,
• Interact with other team members,
• Contribute to the decision-making process,
• Interpret nonverbal communication,
• Understand the primary written and spoken language of the team,
• Question or interact with authority,
• View their role on the team,
• Raise questions or issues,
• Negotiate, and
• Deal with conflicts.

A business analyst who takes the time to recognize and understand the cultural differences will gain an awareness and appreciation for the diversity and can use their understandings to run a more effective business analysis process.

3.3.2.4 Experience

Understanding the experience level of the project stakeholders provides helpful information for planning activities. Elicitation may be completed more efficiently when stakeholders have prior experience participating in requirement workshops or validating requirements than with a team of stakeholders who are unfamiliar with business analysis or do not understand the value of the business analysis activities. A business analyst should consider the number of years of industry experience stakeholders have, whether they have worked with the organization for an extended length of time or whether an individual stakeholder is new to the organization. These factors can influence how requirements are validated and approved as well as the number of stakeholders to engage from a stakeholder group. The business analyst will also find it important to analyze experience across stakeholder groups to ensure that a sufficient breadth of business knowledge is represented on the requirements team. Where gaps are identified, the business analyst, working with the project manager, should seek to acquire additional resources to provide the needed or missing experience for the requirements-related activities.

3.3.2.5 Level of Influence

Understanding the amount of influence a stakeholder has within an organization helps to identify where influence can serve as a motivator as much as it can serve to distract or deter others from embracing the work of the project team. A person's level of influence is often tied to his or her position within the organization; however, influence is not solely associated to a person's rank, reporting structure, or job title. A person's level of influence is also affected by business relationships, reputation, knowledge or level of experience, or successes within the organization. Analyze the level of influence to understand the power an individual or stakeholder possesses. This analysis will highlight those who can help rally for the solution as well as identify those that can hinder project success. Through this analysis, the business analyst will be able to identify influential stakeholders and areas where more time needs to be spent on building relationships and collaborating with key individuals.

3.3.2.6 Location and Availability

A global workforce and an increase in the number of organizations supporting a virtual work environment are two trends that make analyzing location a worthwhile step in stakeholder analysis. Even when the project team is centralized, the business analyst should understand whether remote work is supported. The business analyst should review the stakeholder list and identify where each stakeholder is based and the locations from which each conducts their work. If stakeholders work from multiple locations, then the frequency that stakeholders work from each location should be noted.

When stakeholders work remotely, it is also helpful to identify the methods used for connectivity. This information can be used when determining the best approach for collaboration, for example, conference calls, desktop sharing, web conferencing, etc. Understanding availability, including work hours, and whether a flexible work schedule is used or a four-day work week is in place is beneficial as availability impacts the frequency by which the business analyst can conduct elicitation sessions. The business analyst may choose to elicit requirements through facilitated workshops when key stakeholders are local but use interviews or surveys when key stakeholders are dispersed or when time zone differences make scheduling conference calls difficult. Documentation analysis may be used when stakeholders are not available at all.

Location affects a number of business analysis planning decisions such as:

• Determining the techniques that are most effective to elicit requirements,
• Estimating how much time is required to complete business analysis activities,
• Deciding on the formality and level of detail required for the business analysis deliverables,
• Deciding on the types of models to use,
• Determining the approach and frequency of collaboration, and
• Determining how requirements will be managed, maintained, and shared with project stakeholders.

3.3.3 Techniques for Grouping or Analyzing Stakeholders

Stakeholders can be grouped once their characteristics are understood. Stakeholder lists can quickly become long and difficult to manage; therefore, placing stakeholders into groups will allow for easier management of the information. Groupings can be structured by similar interests, common needs, level of importance, by roles, motivations, complexity level, location or many other qualities. Primary and secondary designations can also be used to separate stakeholders by those who are primarily or directly impacted by the project or solution compared to secondary stakeholders who are indirectly impacted. The business analyst should choose the type of stakeholder grouping that best meets the objectives of the analysis.

There are several techniques that can be used to group or analyze stakeholders such as job analysis, organizational modeling, personas, process modeling, risk analysis, and stakeholder maps (see 3.3.3.1 and 3.3.3.2).

3.3.3.1 Job Analysis

Job analysis is a technique used to identify the job requirements and competencies needed to perform effectively in a specific job or role. The technique is often used when a new job is created or when an existing job is modified.

Organizations use job analysis when drafting job descriptions and when determining the best person to fill a position. The output of job analysis may include a number of details such as the description of the work, a depiction of the work environment, a detailed list of the activities a person will perform, a listing of the interpersonal skills required to perform well in the job, or a list of required training, degrees, and certifications. Job analysis may also be used to determine training needs, formulate information needed to write a job posting, and to support the performance appraisal process.

Business analysts can review the job analysis to understand how particular roles are performed by stakeholders. When the project entails replacing or revising workflow and business processes, the business analyst uses the job analysis to understand how the existing job is currently performed. When the project entails the creation of a new job, job analysis may be used to specify the tasks required for the new role.

3.3.3.2 Persona Analysis

Persona analysis is a technique that is conducted to analyze a class of users or process workers. It is a powerful tool for understanding stakeholder needs and for targeting product design and behavior for each class of user. A persona is a fictional character created to represent a user group or group of stakeholders who have similar needs. During planning activities, the business analyst uses personas to understand the characteristics of various stakeholder groups and can apply that information to select the best business analysis approach to meet the needs of the project.

Personas are often used in IT systems development and product development to help design or map out a user's experience. While it is often not possible to obtain requirements for every stakeholder on the stakeholder list, it becomes necessary to group the list of stakeholders into various user classes and then build a persona for each class. The objective is to analyze usage information or draw out user requirements to determine how a user class interacts with a system or how a user class would use a product.

The difference between a persona and a stakeholder is that the persona includes much more detail about how it interacts with the problem or solution space, such as, device literacy and preferences, preferred method for searching, and frequency of performing specific actions, etc. Generally, a business analyst does not need this kind of in-depth information for all of the identified stakeholders. In stakeholder analysis, types are identified; however, the business analyst also identifies specific individual stakeholders. In persona analysis, the business analyst focuses on types, often giving them a name and picture for fun (e.g., “Paul the Purchaser”). Unlike stakeholders, a persona may or may not have a material interest in the outcome of the project; a persona simply may be a user who has no influence.

A persona is written in the form of a narrative and tells a story about the user class. Personas describe the goals, behaviors, motivations, environment, demographics, and skills of the user class. The information provided in the persona is behavioral in nature versus the information that is obtained from a job analysis that would be descriptive in nature. A persona is usually one to two pages in length.

3.3.4 Assemble the Stakeholder Analysis Results

As stakeholder characteristics are analyzed, the business analyst may choose to document the results of the analysis in a way that can be shared with the project manager, project team, and sponsor. Much of the information being gathered and analyzed could be considered sensitive in nature; therefore, the business analyst should exercise care when distributing the analysis to a broad distribution group.

The intent of analyzing these characteristics is not to stereotype the stakeholders but to obtain a better understanding of them so that the decisions made when formulating an approach to the business analysis work is optimal and conducive to running a high-performing business analysis process. The additional stakeholder characteristics shared after the stakeholder analysis provides the project team with insights for determining how best to collaborate and work with the stakeholders throughout the entire project life cycle, especially during the business analysis activities.

3.4 Create the Business Analysis Plan

A business analysis plan is created to document how the business analysis process will be performed, including the plan decisions agreed to by the project team. The plan can be constructed formally and be reviewed and approved by the project team or the document can be more informal, simply serving as a record of team decisions. Much value is obtained when building the plan as a team and in collaboration with the stakeholders involved in the business analysis activities.

Plan templates may exist, and when available, business analysts can leverage them as a starting point to avoid building the plan from scratch. Using an existing plan as a starting point also provides the benefit of leveraging existing corporate standards, culturally accepted practices, and any expected governance or management steps expected for the business analysis work.

Not all information may be known at the time the plan is developed; therefore, the business analyst may be required to make some assumptions. The business analyst includes any assumptions made in the business analysis plan document. Making process decisions up-front in the planning phase reduces the risk of being held up debating process during the execution phase.

In some situations, planning in the execution phase may be preferable to planning everything up-front to avoid reaching premature decisions based on incomplete information. In some cases, it may not be possible or desired to plan the entire approach up-front. Rolling wave planning may be used, which involves planning from a high-level first and a more detailed level later on in the project when the activities are ready to be performed. In these cases, the business analysis plan evolves over time and the business analyst reviews planning and approach decisions with the sponsor, project manager, and key stakeholders as more details are known. The business analyst needs to balance the advantages provided by up-front planning against any disadvantages when considering how much up-front planning to perform.

Collaboration Point—The business analyst should build the business analysis plan collaboratively with key stakeholders to attain buy-in. A plan that is constructed by the team provides a sense of ownership to those involved and sets expectations by bringing awareness to how the work will be performed.

3.4.1 Business Analysis Plan vs. Requirements Management Plan

In the project management discipline, a requirements management plan is a component of the project management plan and describes how the overall requirements of the project will be elicited, analyzed, documented, and managed across the project. The requirements management plan covers planning decisions for both the product and project requirements. Previously in the business analysis discipline, the term requirements management plan referred to a document that contained planning decisions about how requirements were to be stored and maintained, as well as decisions about baselining, updating, and change impact analysis. The term has evolved in some organizations to also encompass planning decisions for the business analysis process: how requirements will be elicited, analyzed, documented, and managed across the project. Because business analysis is focused on product requirements and the primary focus of this practice guide is the business analysis process, this practice guide will use the term “business analysis plan” to refer to all information that is documented regarding business analysis planning decisions.

Collaboration Point—The business analysis plan works in conjunction with the requirements management plan. The business analyst should work closely with the project manager to ensure content is not duplicated between the documents and that the planning decisions for both the project requirements and product requirements are covered.

3.4.2 What to Include in the Business Analysis Plan

The business analysis plan is focused on the scope of the business analysis effort. This includes a list of the activities to be conducted and the business analysis deliverables to be produced. A list of the roles required to successfully conduct the business analysis process is included in the business analysis plan. Key process decisions are also included, for example, the approach for prioritizing, documenting, validating, communicating, approving, and changing requirements.

All planning decisions should be documented in a straightforward and clear manner so that stakeholders know what to expect when business analysis activities begin. Where team members disagree with one or more of the decisions being made, the business analyst assumes responsibility for negotiating and bringing the team to consensus. Once decisions are made, these should be documented so conflicts do not resurface later when the business analysis work is being performed.

The business analysis plan should be written in a manner that will be easily understood, because it will be reviewed and may need to be approved by key stakeholders. When developing the business analysis plan, it is a good practice to provide explanations for the planning choices made. For example, for projects using an adaptive life cycle, the depth and cadence of analysis activities will be planned much differently than for projects using a waterfall approach. The prioritization process, types of techniques, and deliverables will vary. Explaining why planning choices were selected provides context for those who review the plan and provides the rationale for the decisions made.

Generally, decisions that are reflected in the business analysis plan and are influenced by the selected project life cycle include:

• Type of elicitation activities to be conducted;
• Requirements analysis models that are required or expected;
• How requirements will be documented and communicated to stakeholders, including the use of any specialized tools;
• Business analysis deliverables to be produced;
• Roles and responsibilities for those participating in the requirement activities;
• How requirements will be prioritized, approved, and maintained;
• List of requirement states that will be tracked and managed in the project;
• How requirements will be validated and verified; and
• How the acceptance criteria will be determined for the requirements and solution validation.

3.4.2.1 Determining the Proper Level of Detail

The business analyst should ensure that a sufficient level of planning occurs in order to minimize the risks of developing poor estimates; misguiding stakeholders regarding the amount of required commitment; and miscommunicating the important decisions regarding requirement signoff, prioritization, and change management. The business analyst should avoid being too prescriptive and try to find a balance in the amount of planning performed. When rolling wave planning is used, consider the planning horizon and provide planning details only for the activities that are on the short-term horizon.

• Balancing between flexibility and management. The type of information commonly contained in a business analysis plan varies because each organization develops the template a bit differently depending upon organizational needs. When developing a business analysis plan, the business analyst should not attempt to document every aspect of the business analysis approach as that tactic is time-consuming and ineffective.
• Do not sacrifice good management practices for flexibility. The business analysis plan is intended to provide enough guidance to ensure quality in the business analysis process and is not intended to constrain or remove flexibility when an adaptive approach is needed to perform effectively. The plan should focus on documenting the key decisions about how the business analysis process will be performed and should not try to plan out each and every step of the process.

3.4.3 Understand the Project Context

There is no single approach to the business analysis effort that works best for every project, because all projects are unique. It is essential to understand the characteristics of a project and the context in which it is being conducted in order to define an appropriate approach. A project that is highly complex because it involves several interfaces or impacts a large number of business units requires a different approach to business analysis work compared to a project that is smaller in size and less complex.

The business analyst conducts some initial analysis including a review of the business case, project goals, and objectives in order to obtain the necessary context required to start defining the approach. Before planning decisions are made, the business analyst analyzes the characteristics of the project in order to determine the approach, including but not limited to the following:

• Project size,
• Project complexity,
• Type of project,
• Risk level,
• Risk tolerance,
• Geographic distribution of stakeholders,
• Aggressiveness of project timelines,
• Selected project life cycle,
• Imposed constraints and/or regulations,
• Market conditions and/or competitive landscape,
• Technology trends,
• Level of detail and formality required for deliverables,
• Time to market requirements, and
• Experience level of the business analysts assigned to the project.

There may be mandatory organizational standards that impose prescribed methods for conducting the work or require business analysts to follow a predefined process for defining, tracing, approving, or managing requirements. An organization may also influence the approach by requiring the use of standardized requirements templates. The business analyst needs to consider all of these factors when planning how to perform the business analysis work for the project.

3.4.4 Understand How the Project Life Cycle Influences Planning Decisions

A project life cycle is the series of phases that a project passes through from its initiation to its closure. The life cycle provides the structure for managing the project and is determined by factors such as managerial preferences, project characteristics, or how the organization desires to maintain and control projects. A number of process and planning decisions are dependent on the chosen project life cycle; therefore, the business analyst should tailor process decisions in accordance with the project life cycle selected.

Project life cycle models range from predictive (fully plan-driven) to adaptive (change-driven), and hybrid approaches fall anywhere between the two. The following is a high-level comparison of the three main structure types:

• Predictive:
  • Emphasis is on minimizing uncertainty.
  • Scope is entirely defined up-front.
  • Time and cost estimates are determined for the entire project when scope is defined.
  • Business analysis is conducted mostly up-front; requirements are completed before product development begins.
  • Deliverables are determined at the onset of the project.
  • Changes to scope are carefully managed.
  • Business value is delivered through one implementation.
  • The need and solution are known and do not change throughout the project.
  • Predictive life cycle methods are also referred to as plan-driven, traditional, or waterfall methods.
• Iterative/Incremental:
  • Project is split into phases and project phases are intentionally repeated.
  • Project work is performed sequentially or with some overlap in iterations.
  • High-level scope is defined up-front and the detailed scope is elaborated upon for each iteration.
  • Scope for future phases is defined when the prior phase starts or completes.
  • Product is developed iteratively as features are added incrementally.
  • Business analysis is performed up-front and then in small amounts throughout the project.
  • Requirements analysis is performed in time-boxed iterations.
  • The need and solution become more stable as the project progresses.
• Adaptive:
  • Business value is emphasized over minimizing uncertainty.
  • Time and cost estimates are fixed for each iteration.
  • Iterations are conducted quickly.
  • Overall scope is agreed to early. Detailed scope and product requirements are defined for a single iteration at a time.
  • Changes are expected; when new requirements are presented, these are captured in a product backlog, and then the backlog is reprioritized.
  • Business value is delivered iteratively.
  • Business analysis is constant.
  • The need and solution are unknown and unstable.
  • Adaptive life cycle methods are also referred to as change-driven or agile methods.

The project life cycle impacts a number of decisions about the business analysis process, such as:

• Business analysis activities that are to be performed,
• Order in which the activities will be completed,
• Timing of activities,
• Deliverables,
• Level of formality required for deliverables,
• Approach for prioritizing requirements, and
• Methods for addressing requirement changes.

3.4.5 Ensure the Team is Trained on the Project Life Cycle

Project teams and key stakeholders may require training if they have not worked previously with a selected project life cycle. The business analyst should be aware of the experience levels of the stakeholders and identify areas where coaching or training may need to be provided to assist the stakeholder through the requirement activities. Because templates and business analysis deliverables vary based on the project life cycle, time should be provided to update stakeholders who have the responsibility for reviewing, prioritizing, and validating requirements. In addition, the business analyst lead who manages a team of business analysts should ensure that the business analysts have the necessary skills to use the techniques and tools selected for the work.

Collaboration Point—Business analysts are responsible for stakeholder engagement in the business analysis process and the project manager is responsible for stakeholder engagement across the project. There is an opportunity for the roles to work together to determine the readiness and willingness of key stakeholders to participate in project activities.

3.4.6 Leverage Past Experiences When Planning

3.4.6.1 Lessons Learned

Lessons learned is the knowledge gained during a project, which shows how project events were addressed or should be addressed for the purpose of improving future performance. The lessons learned process is a best practice used by project teams to discuss, analyze, and document feedback about completed project activities. Lessons learned sessions are typically scheduled after the conclusion of a major phase or completion of a project. These sessions may be held more frequently as the need arises or when major events that require attention occur.

When determining a business analysis approach, the business analyst looks for similarities with other ongoing projects or previous projects that had successful business analysis approaches, reviews lessons learned documentation, and applies relevant lessons in whole or in part to the current business analysis process. For example, the business analyst may look through a previous business analysis plan to pull out estimating metrics and find ways in which the estimates can be improved for the current business analysis process.

Collaboration Point—Project managers and business analysts may each conduct lessons learned sessions; the project manager obtains feedback on completed project activities and the business analyst focuses on completed business analysis work. Instead of working independently, the roles should collaborate and facilitate the session together.

3.4.6.2 Retrospectives

In adaptive life cycle projects, retrospectives are meetings that are scheduled on a regular basis or conducted when a body of work is completed, such as the conclusion of an iteration or at the end of a project phase. Retrospectives have been used for many years in the development process of Kanban, agile approaches (e.g., Scrum and eXtreme programming), and in Lean methods, such as Kaizen and continuous improvement. The purpose of a retrospective is to task the project team with identifying those areas where team performance can be improved. The team reflects on their successes and areas for improvement. The facilitator takes responsibility to ensure everyone in the room participates and works together to determine a course of action. Typically retrospectives use the following steps:

• Set the stage. The context and tone for the meeting is established.
• Gather data. Factual and relevant data is pulled together to support feedback.
• Generate insights. The team looks for commonality in the feedback including cause and effect.
• Decide what to do. The team collaborates to determine a course of action for improvement.
• Close the Retrospective. The session is ended.

This process is often facilitated with a list of simple questions:

• What is working?
• What is not working?
• What needs to change?

The facilitator uses charts and other visual methods to capture the information presented. The process is highly collaborative.

The biggest differences between lessons learned and retrospectives are in the timing and speed by which issues raised are addressed and the formality around documenting the learnings. Because adaptive life cycles offer more opportunity, retrospectives occur regularly and frequently, such as at the end of each sprint, or at the end of a Kanban delivery. Retrospectives may also be scheduled on a once-a-week basis, irrespective of delivery. Retrospectives are conducted in a highly collaborative fashion and decisions made are most often implemented with little formal documentation. Lessons learned are conducted at the end of stage gates or a phase such as a project closeout or when events occur that are worth learning from. Although lessons learned can be conducted more frequently, these are used less frequently than retrospectives and may be driven by the occurrence of an event versus a fixed schedule. Learnings discussed are formally documented and stored in a repository for future reference. Project teams leverage the lessons learned repository as an input prior to planning work on subsequent projects.

Due to the frequency by which retrospectives occur and because they are held multiple times over the course of a single project, improvements can be applied immediately, allowing the value to be gained from the proposed improvement in the next iteration.

When lessons learned are performed within a predictive life cycle, the learning can be applied on the same project or future projects. When improvements are proposed on future projects, the project context or characteristics may be different; therefore, identifying applicable lessons that add value and address performance can prove to be challenging.

To ensure that the frequency of retrospectives does not diminish their value, it is important that retrospectives are kept fresh to avoid mundane gatherings where time is not well spent. The team needs to meet often enough to conduct valuable sessions but not too often that the task is considered a waste of time. Retrospectives assist in generating ideas to improve team performance but are not a replacement for training and coaching staff on process. Retrospective and lessons learned data are valuable inputs when formulating an approach for how to conduct the business analysis work for a project. The information gained from both can be leveraged to ensure process mistakes are not repeated and that valuable steps are continued.

3.4.7 Plan for Elicitation

At this stage of planning, the business analyst should begin to think about how and when to elicit, which techniques to use, and the sequence of the elicitation activities. Although it is appropriate to start thinking about technique options in planning, it is not important to prescribe each and every technique that will be used throughout the process.

Planning is iterative and much of the information will not be known or uncovered until the elicitation work is underway. When decisions or assumptions impacting the elicitation work are known and worthy of noting (e.g., decisions or assumptions that provide clarity or identify dependencies) the business analyst should note this information.

There are a number of factors to consider when planning for elicitation:

• Stakeholder group characteristics and dynamics,
• Project life cycle,
• Characteristics of the technique (e.g., speed of use, particular advantages),
• Type of project,
• Time constraints,
• Budget,
• Number of stakeholders,
• Location of stakeholders,
• Types of requirement deliverables being produced,
• Level of detail required in business analysis deliverables, and
• Techniques that are familiar to the business analyst and key stakeholders involved.

The business analyst should be aware that elicitation consumes project resources; therefore, there is a cost for each facilitated workshop completed, each interview conducted, and every survey sent. The business analyst balances the needs of the project against the quantity of requirements elicitation conducted with the goal of eliciting the right amount to sufficiently define the product solution.

Elicitation planning helps to ensure sufficient time is allocated for the elicitation work. It is easy to misjudge the level of effort required. For example, when a survey comprises a part of the elicitation effort, sufficient time needs to be allocated to design, build, administer, and analyze the survey results. When subsequent work is dependent on the survey results, the business analyst should identify and plan for that also.

When insufficient time is allocated for elicitation activities, dependent downstream tasks may be delayed when business activities extend past the projected timelines. Key stakeholders may find it difficult to allocate additional time to participate in unplanned elicitation sessions when these sessions are planned at the last minute. The need to accommodate additional, unexpected workshops begins to have a multitude of impacts to the project schedule. It is best to take a judicious approach to planning up-front but to ensure enough planning is performed so that dependencies can be identified and relied upon to schedule downstream activities.

3.4.7.1 Strategies for Sequencing Elicitation Activities

Where to start eliciting requirements often poses a challenge. Business analysts know they need to acquire a lot of information, they are constrained by the project timeline, their stakeholders have a limited number of hours to dedicate to the project, and their stakeholders have business knowledge and expertise in specific areas. All of these factors need to be considered to determine the optimal sequence for conducting elicitation activities.

There are a number of strategies the business analyst may consider when determining which areas of requirements elicitation to address first. Suggested areas of focus are where there are:

• Significant amounts of business value to be gained,
• Greater risks,
• Many project unknowns or uncertainties,
• Significant technical challenges,
• Dependencies on other components or interfaces,
• Required third-party resources that the project is dependent on, and
• Limited number of resources or a risk that a key resource may leave the project or company.

Other constraints that affect elicitation sequencing are the dates key stakeholders impose on the project. For example, plant shutdowns or seasonal constraints where stakeholders are committed to the operational work of the business before the work of the project.

Collaboration Point—When deciding the order of business analysis activities, the project manager and business analyst should work together to determine how the resource availability will impact sequencing decisions.

3.4.8 Plan for Analysis

Planning for analysis occurs at a high level in much the same manner as elicitation planning. The business analyst will begin to think about which analysis techniques will be best suited to meet stakeholder and project needs. Although it is not necessary to call out each and every analysis technique that may be used, the business analyst should start to think about how the analysis work may be performed and determine the tools, templates, or training that need to be acquired prior to the start of the actual work.

There are a number of analysis techniques to choose from, and each technique has its strengths and circumstances where each is best used. At the planning stage, the business analyst does not have sufficient information to know all of the analysis techniques that will be used, since it is unknown as to what type of information the elicitation activities will produce. At the planning stage, the business analyst is just starting to think about how to approach the analysis activities and much of what is considered here may change as the elicitation activities proceed. Planning for analysis is iterative and occurs throughout the project.

3.4.9 Define the Requirements Prioritization Process

Prioritizing requirements is an important step in managing product scope. There are many ways to prioritize requirements; therefore, the business analyst determines which approaches are going to be used on the current project. To minimize conflict during the requirements prioritization activities, the business analyst should define the process for establishing priorities before the requirements are elicited. Setting expectations early with stakeholders helps to minimize situations where stakeholders become unhappy when their requirements are prioritized to the bottom of the list. Business analysts will find themselves leveraging their negotiation and conflict management skills heavily during prioritization discussions.

When building the business analysis plan, the business analyst should include an explanation as to how prioritization will be conducted for the project. Some common factors to consider when defining the prioritization process are:

• When requirements prioritization will occur,
• The likelihood that priorities will change,
• Stakeholders who will be involved in the prioritization process,
• Techniques that will be used for prioritization,
• Criteria that will be used to prioritize, and
• Stakeholders who will approve the prioritization decisions.

The project life cycle influences the prioritization process and often dictates the frequency, timing, and techniques for performing prioritization. For example, adaptive life cycles use prioritization techniques for each iteration in order to determine the features to be provided in the next release of the product. Projects using a predictive or waterfall life cycle will conduct prioritization up-front before product construction begins. Priorities may still shift in a waterfall project, but incorporating such changes is more difficult than in a project following an iterative development cycle.

In addition to defining the timing and frequency of prioritization, the business analyst should also define the criteria that will be used to prioritize. Requirements are prioritized based on a number of factors such as:

• Value. Addressing high-value requirements first to reap the financial or goodwill benefits up-front.
• Cost. Evaluating requirements based on financial costs or opportunity costs.
• Difficulty. Considering how difficult the requirement is to fulfill.
• Regulatory. Addressing regulatory or legislative requirements that have imminent compliance deadlines first.
• Risk. Implementing high-risk requirements first to uncover issues early.

Some common techniques for determining priority are MoSCoW, multivoting, timeboxing, and weighted ranking. For information about conducting the prioritization process, see Section 4 on Requirements Elicitation and Analysis where MoSCow, multivoting, and timeboxing are discussed. See Section 2 on Needs Assessment for more information about the weighted-ranking matrix and weighted-ranking approach.

3.4.10 Define the Traceability Approach

Traceability involves documenting requirement relationships and is used in business analysis to maintain product scope. When a traceability approach is defined and adhered to, requirement relationships are created, which allow the project team to trace backwards to identify the origin of a requirement, trace forward to identify how the requirement was tested and implemented, or trace in-between requirements to provide insight into the value a group of related requirements can deliver. Requirements that are documented but fail to trace to a business need are considered out of scope. Requirements that fail to trace to a solution component identify areas where the product is not in compliance with the requirements.

When sufficient traceability is established, it is much easier for the project team to understand how a proposed change will impact the project. Those requirements affected by a change can be evaluated to understand how a change in that requirement impacts (a) the related project components already built to satisfy the requirement or (b) test cases already created to test the feature, etc. A sufficient amount of traceability ensures that the impacts of requirements change are properly assessed and quantified from a risk, cost, and time perspective.

During planning, the business analyst should determine what level of traceability is going to be performed on the project. Higher-risk or more complex projects may require more traceability. Understanding the project context, the type of project, and any organizational process or compliance standards that are required, the business analyst then documents the traceability approach in the business analysis plan.

The types of traceability decisions the business analyst should consider are:

• Types of requirements to be traced,
• Level of detail to trace to,
• Relationships that will be established and maintained,
• Requirement attributes to be tracked,
• Requirement states that drive the requirements life cycle (for example, approve, defer, reject, etc.),
• Tools used to perform the traceability, and
• Process decisions regarding how traceability will be established and maintained.

As the size and complexity of the project increases, so does the complexity of the traceability. Larger, more complex projects increase the number of relationships that need to be established between the components. As the amount of traceability increases, the time and cost to manage the established linkages increases as well.

To ensure the traceability approach is adequately sized for the project, the value of the process should be compared against the time and cost required to establish and support it. Risks should also be analyzed to ensure additional risks are not introduced by proposing a traceability process that increases the likelihood of missing requirements in the final product.

Collaboration Point—The right amount of traceability helps to reduce project risks, but too much traceability works against the project team and incurs costs and schedule impacts unnecessarily. The project team has an opportunity to collaborate and define a traceability approach that is suitable for the needs of the project. Business analysts should not define the traceability approach independently as decisions on traceability are very interrelated to project factors that the project manager is responsible for managing.

For further information on establishing and maintaining traceability, see Section 5 on Traceability and Monitoring.

3.4.11 Define the Communication Approach

A communication approach describes how business analysis information will be structured and when communication to stakeholders will occur. The approach can be formally documented in the business analysis plan or in a separate business analysis communication plan if the project or organizational needs require this level of structure or formality.

The business analyst should discuss the communication process with stakeholders to ensure the approach will meet expectations.

When defining the business analysis communication approach, consider the following:

• Types of requirements and requirements-related information that will be communicated,
• Who requires communications and what information they expect,
• Stakeholder preferences for receiving information (e.g., summary level or detail),
• Preferred delivery methods for distributing or accessing requirements and requirement related information,
• Level of formality required in the communication, and
• Tools, including requirement repositories, which stakeholders will need access to.

In addition to gaining agreement on what information will be communicated, the business analyst also receives input about how stakeholders wish to receive information on requirements and how often they wish to receive information. For example, upper level management may request access only to requirements once the requirements are approved. Subject matter experts may request access to the requirements throughout the project. It may not be appropriate to copy every stakeholder on each communication; therefore, the business analyst may request the business to identify a key stakeholder representative who can serve as the recipient of the requirement-related communications.

The time zone and physical locations of the stakeholder should be considered when defining the communication approach. Location may impose constraints on the communication process as well as the tools selected to support the process. When stakeholders span across multiple time zones, which makes it difficult to have direct contact with the stakeholder, then the communication process may need to be formalized to ensure information is delivered in a clear and concise manner and can be easily understood when the practitioner is unavailable.

Collaboration Point—The business analyst should not create the communication plan independently of the project manager. If the business analysis communication plan is formally documented, agreement should be reached on whether the information will be kept as a subplan or included within the project manager's communication plan.

3.4.12 Define the Decision-Making Process

Throughout the business analysis process, there are a number of decisions that need to be made before work can commence. The decision-making process should be defined collaboratively with stakeholder input. Once the team determines the decision process, it is documented within the business analysis plan so the team has a point of reference when the work begins. When there are differences regarding how decisions should be made, the business analyst facilitates agreement and clears up conflicting viewpoints prior to the execution of the business analysis activity. A thorough understanding of the types of decisions that stakeholders will be required to make and an assessment of the authority levels in the process will save tremendous time and confusion later on when decisions need to be reached by the requirements team.

The following information can be considered when defining the decision-making process:

• Types of decisions that will be made, including how requirements will be approved,
• Roles and authority levels, for example, who is involved in the discussions and who makes decisions, etc.,
• Process to follow when consensus cannot be reached and requirements-related issues need to be escalated,
• Required turn-around time for a decision to be reached,
• How decisions are documented and communicated, including requirements signoff, and
• Special tools or techniques that may be used to help teams evaluate alternatives, for example, decision analysis, decision modeling, decision trees etc.

3.4.13 Define the Requirements Verification and Validation Processes

Two business analysis activities that often confuse stakeholders are requirements verification and requirements validation. According to the PMBOK® Guide – Fifth Edition, verification is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. Validation is the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. Requirements and associated requirement models are both verified and validated.

In business analysis, requirements verification is the process of reviewing requirements and models to ensure they meet quality standards. Verification is performed to ensure that requirements are constructed properly and that models are clear enough to be used effectively. Verification activities ensure that the right product will be built. Verification can be conducted iteratively as requirements are in development. All requirement types should be verified, for example, business requirements, stakeholder requirements, solution requirements, etc.

Requirements validation is the process of ensuring that all requirements accurately reflect the intent of the stakeholder and that each requirement aligns to one or more business requirements. Validation is performed through the use of structured walkthroughs and traceability. Conducting a structured walkthrough provides an opportunity for the business analyst and stakeholders to collaborate and to ensure the requirement as stated is correct. Requirements validation ensures that the requirements accurately reflect what the project is expected to deliver. Validation ensures that the right product is being built.

During business analysis planning, the business analyst defines how verification and validation activities will be conducted. Stakeholders often have expectations about how they want to review requirements and, therefore, their input should be taken into consideration when defining these processes. Organizations may already have documented standards that identify the characteristics for good requirements. Quality standards should be defined in planning so they are known prior to requirements development and verification activities. Verification processes often leverage checklists to define the quality attributes. When a checklist will be leveraged for the verification process, the business analyst ensures that the checklist is created before the verification activities begin. Requirements validation and verification and the characteristics for quality requirements are further discussed in Chapter 4 on Requirements Elicitation and Analysis.

3.4.14 Define the Requirements Change Process

The requirements change process is performed differently depending on the selected project life cycle. For a project following a predictive life cycle, the project team may use a formal change control process; whereas a project following an adaptive life cycle may not. Adaptive approaches expect that requirements will evolve over time and, as a result, often take a flexible approach to requirements change control.

For projects that use a formal change control process, the business analyst should consider documenting the approach so that stakeholders know how to request a change and how changes will be assessed for impact. Changes to requirements may involve a change in scope, a restated business objective, or the addition or deletion of features to the product or service being developed; therefore, the business analyst will need to determine how requirements documentation should be updated once a change is approved.

Consider the following type of information when defining a requirements change control process:

• How requirement changes will be proposed,
• How changes will be reviewed,
• How change management decisions will be documented,
• How requirement changes will be communicated, and
• How changes to requirements, models, traceability, and other requirements-related information will be completed and made available once a change is approved.

The business analyst also needs to ensure the project team understands the roles and responsibilities for the requirements change process, for example:

• Responsibility for proposing changes,
• Responsibility for conducting the assessment or impact analysis,
• Roles that participate in change discussions, and
• Responsibility for approving changes.

When there is an approved change request form or impact analysis template that should be used, this information should be included when defining the requirements change process. For information on conducting the change control process, see Section 5 on Traceability and Monitoring.

Collaboration Point—The requirements change control process may be documented by the project manager in the change management plan. When there is a need to formally document the process, the business analyst and project manager should work together to determine who takes ownership for documenting the plan and whether the business analysis plan or change management plan is the source for this information.

3.4.15 Define the Solution Evaluation Process

Defining the solution evaluation process identifies how a solution is evaluated during the evaluation phase, which activities will be performed, what techniques will be applied, and how information will be analyzed.

Through evaluation, the business analyst determines whether a solution has achieved the desired business result. Evaluation is performed before and after a solution is implemented. When evaluation is conducted after a solution is implemented, new or changed requirements may be identified, which can lead to refinement of the solution or can generate new projects for the purpose of creating a new version of the product. The project life cycle influences the timing and frequency of the evaluation activities.

The expected benefits for the product or solution were defined in the business case. The work in planning is to determine how to measure these benefits.

Solution evaluation planning involves defining the following:

• Evaluation criteria and acceptance levels;
• Qualitative and quantitative evaluation activities to be performed;
• How the solution will be evaluated;
• When and how often evaluation will be performed;
• Evaluation techniques that will be used, for example, focus groups, observations, surveys, etc.;
• Whether any special measurement tools will be required; and
• How results will be analyzed and reported.

For more information on conducting the evaluation process, see Section 6 on Solution Evaluation.

3.5 Plan the Business Analysis Work

3.5.1 Determine Who Plans the Business Analysis Effort

One point of confusion on projects is the overlap that exists between business analysis planning and project management planning. The confusion over who performs what work is compounded by the fact that the responsibility for business analysis planning differs across organizations, by type of project and by project methodology. Even within a single organization, the business analyst may be assigned to build the work breakdown structure for one project in order to define the business analysis work; and for a second project, the project manager may interview the business analyst to obtain the needed inputs for developing that plan.

The business analysis profession is progressing, and the role has become more defined over the years. Hybrid roles, for example the project manager/business analyst (PM/BA) positions have existed for many years and still exist in a number of organizations. As organizations have purposely split apart the responsibilities into two distinct roles, the practitioners who migrated into pure business analyst positions bring with them experience in project planning. When a business analyst is adept at planning, a project manager may leverage that experience and request assistance from the business analyst. It is not uncommon for a business analyst on a project with a predictive life cycle to draft a work breakdown structure to conduct initial conversations with the project manager regarding the business analysis work for the project.

Collaboration Point—Planning is an area where project managers and business analysts will find that their roles overlap. Ultimately the project manager is responsible for the project management plan and is accountable for managing all project activities. The business analyst can help support the project manager, because the business analyst has expertise with the business analysis process and can provide specifics on the business analysis work that is recommended to meet project objectives. Other team members should be consulted and included in plan development to ensure their buy-in and engagement in the work.

3.5.2 Build the Business Analysis Work Plan

The business analysis work plan is the project plan that covers the work to be performed during the business analysis process. The business analyst is responsible for identifying this work using all the project and environment information known to them, for example, selected project life cycle, project size, known risks, organizational process assets, etc. It is critical that the project manager be included and involved as the business analyst lays out this work, because ultimately the business analysis work plan will be integrated within the project management plan. Any discrepancies or misalignment needs to be resolved before work commences.

The first step in building the plan is identifying the deliverables that the business analyst is responsible for producing.

3.5.2.1 Identify the Deliverables

The business analyst collects many forms of information over the course of the project, but not all information collected and documented is considered to be a project deliverable. According to the PMBOK® Guide – Fifth Edition, a deliverable is any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.

Agendas, meeting minutes, parking lot lists, and some types of models, although necessary to organize work and perform effectively, are not required to be produced and, therefore, are not considered a business analysis deliverable. These items are often referred to as work products and are created in order to perform the work, but are not a promised deliverable that will be tracked and managed through the project management plan. During planning, the business analyst should think about the work products and how they will be created, stored, accessed, and used by the project team. Planning for work products is much less formal than deliverables.

Deliverables, on the other hand, are required and often impact the work of individuals who perform activities later on in the project life cycle. These documents are usually formatted for consistency across projects and often have an approved structure or template that the business analyst is required to use. Examples of these include, but are not limited to: a high-level requirements document, software requirements specification, user stories, business rules catalog, and a nonfunctional requirements list. While planning the deliverables for the project, the business analyst considers what types of requirements will be collected and the different deliverable formats that are required to be used. Additionally, consideration is given to stakeholder requests for receiving specific types of documentation or obtaining information in certain formats or tools. The selected project life cycle heavily influences which deliverables will be produced as do the size and complexity of the project.

The business analyst should consider the following when planning the business analysis documentation:

• What deliverables will be produced;
• How deliverables will be used by other team members and key stakeholders;
• How changes to deliverables will be managed;
• Required formality of the deliverables;
• How deliverables will be accessed and by whom;
• Tools that are required to produce, maintain, or store deliverables; and
• Whether requirements will be reused on future projects.

Collaboration Point—The business analysis deliverables produced for the project are determined by the business analyst but these decisions are not made independently. The business analyst solicits input from the sponsor, project manager, and key stakeholders to ensure that expectations are met. The business analyst should work closely with the project manager, because deliverables impact the project schedule and can create dependencies for other downstream project work.

3.5.2.2 Determine the Tasks and Activities

As the stakeholder and project characteristics become better understood during the planning process, the business analyst considers the business analysis work that needs to be performed in order to conduct an effective business analysis process. After agreeing on the list of deliverables that will be produced to satisfy the project objectives, the business analyst begins to define the activities required to produce them. Each deliverable requires the completion of one or more activities. The project team should work together to define the task list. Task identification is an iterative process. The business analyst may use a number of techniques to help identify a complete list. Brainstorming, decomposition modeling, interviews, and lessons learned are a few of the techniques that can be used.

• Decomposition model. A decomposition model is an analysis model used to break down a high-level object into smaller more discrete parts. Typical objects often analyzed with decomposition may be solution scope, organizational units, work products, processes, functions, or any other object types that can be subdivided into smaller elements. A decomposition model is easy to produce and the models are easily constructed and understood by stakeholders. Decomposition models provide a way to analyze highly complex concepts, because these allow for the complexity to be broken into manageable elements. The hierarchical relationships are easily portrayed through the levels.

  Decomposition models cannot be used to show sequence and process steps. In business analysis planning, a decomposition model is used to identify business analysis tasks, activities, and deliverables by detailing out the business analysis work. When conducting stakeholder analysis, a decomposition model is used to analyze the organization with the goal of discovering stakeholder groups. On IT projects, this type of model is helpful to break down solutions into solution components to further understand their features. Decomposition models are also referred to as decomposition diagrams.

3.5.2.3 Determine the Timing and Sequencing of Tasks

The timing of business analysis tasks is directly influenced by the selected project life cycle. Sequencing is also influenced by a natural order, because some tasks require the completion of outputs produced by other activities. The business analyst analyzes these factors and may consider one or more of the following when determining the sequence of activities for the work plan:

• Availability of resources required to perform or contribute to the work,
• Needs of downstream recipients whose work relies on the business analysis deliverables,
• Relationship of project work to other work being performed within the organization,
• Contractual and statement of work obligations,
• Dependencies on training and tools to perform the business analysis work,
• Staffing and new hire needs, and
• Risk and complexity level of tasks.

3.5.2.4 Determine the Roles and Responsibilities

Project managers often develop a RACI to identify roles and responsibilities for the resources assigned to the project. RACI analysis is also performed in business analysis when determining roles and responsibilities for the business analysis effort. The business analyst cannot assume that everyone involved in the business analysis process knows their role or what they are accountable for. Key stakeholders may be confused when they participate on more than one project team at a time. Stakeholders may have confusion about the roles that are assigned to them versus the roles they desire. While the RACI is used to document the role responsibilities across the team, it is also valuable to use this technique to define the role responsibilities between the project manager and the business analyst. Determining roles and responsibilities at the start of the project helps to minimize confusion and conflicts, especially in areas where responsibilities appear to overlap.

In business analysis activities, it is essential to understand who is responsible for providing requirements, who has authority to approve requirements, who can make decisions or settle differences when they arise, and who is involved when changes to requirements are proposed. The RACI technique can be used to facilitate, sort through, document, and gain approval on these decisions. In addition, the RACI can be used as a communication tool. It can be referenced throughout the business analysis work when conflicts arise over authority and responsibility levels. Once completed, the RACI matrix can be included as part of the business analysis plan to ensure these decisions are approved and managed. How to construct a RACI is described in Section 2 on Needs Assessment.

Collaboration Point—The business analyst and project manager share a common interest in ensuring that key stakeholders fully understand and agree to the roles and responsibilities they hold on a project. While the project manager is managing these expectations across the project, the business analyst is managing these expectations during the business analysis activities. Both roles have an opportunity to work together to help ensure the expectations regarding stakeholder involvement are met.

3.5.2.5 Identifying the Resources

The business analyst will review the planned work, determine which resources will be needed for the work, and identify any areas where resources may be overallocated or missing. As a minimum, the business analyst needs to ensure that all functional areas impacted by the project are represented by a resource during requirements elicitation, validation, and approval activities. As subject matter experts are often coveted across the organization and often allocated on multiple projects, business analysts should raise any concerns obtaining commitments from resources once the resources are assigned to the project.

Collaboration Point—The business analyst can lend their expertise and personal insight to the project manager as they work collaboratively to determine the optimal number of subject matter experts to engage on the business analysis activities. The business analyst may have prior experience working with key resources and specifics that influence task allocations and assignments that the project manager may benefit from prior to finalizing the overall resource plans for the project.

3.5.2.6 Estimate the Work

As the work plan details begin to emerge, the business analyst plays a key role in defining the level of effort required for the defined activities and deliverables. There are a number of estimation techniques that may be used to help support the estimation process. The project manager may have a preference as to which techniques are applied.

To help improve the reliability of the estimates, the business analyst may seek the support of peers within the organization who have more years of experience in estimating similar projects within the industry or line of business. These resources may review proposed estimates and suggest adjustments based on their experience. Business analysts may consider consulting with the key stakeholders who will be involved in the work. Business analysts may validate estimates by reviewing the planning information from past projects that used similar elicitation and analysis techniques.

The following considerations should be factored into the estimates:

• Project size and complexity,
• Selected project life cycle,
• Amount of ambiguity surrounding the proposed solution (e.g., ambiguity will be higher when taking advantage of an emerging technology or using a solution that the organization has little experience with),
• Number of stakeholders and stakeholder groups involved in the elicitation activities,
• Types of elicitation techniques being considered,
• Location of those involved in the business analysis activities (including the product development and testing resources who the business analyst will interface with),
• Schedule and budget constraints,
• Any known assumptions,
• Number of business analysis deliverables being produced,
• Formality and level of detail required for the business analysis deliverables, and
• Experience level of the project team (including the business analysis team assigned to the project and the stakeholders participating in the requirements-related activities).

Estimation is an iterative process and estimates should always be revisited as the project progresses and more information becomes known to the project team. For an adaptive life cycle, the analysis work may not be estimated separately but may be included in an overall estimate of what it will take to deliver an increment of the solution.

Collaboration Point—The project manager and business analyst should determine how revisions to the business analysis estimates will occur. Project managers facilitate the estimation work when building the project management plan. Business analysts may be asked to facilitate the estimation work for the business analysis activities, since they are responsible for the business analysis process and more familiar with the specifics. Estimating the business analysis activities is a potential area of overlap between the two roles; therefore, the business analyst and project manager will benefit greatly by collaborating to determine who should complete and revise these estimates throughout the project.

3.5.3 Assemble the Business Analysis Work Plan

Once the business analysis deliverables, tasks and activities, and required resources for completing the work are known, the information is assembled in a plan that clearly depicts the timing of the work and any dependencies. This is a point of integration between business analysis and project management. The business analyst and project manager need to agree on the level of detail needed for the project management plan. The level of detail maintained in the project management plan can vary based on a number of factors minimally depending upon:

• Complexity of the business analysis effort,
• Size of the project,
• Amount of business analysis work being tracked, and
• Type of project life cycle.

The business analysis work plan may be included within the business analysis plan along with the other planning decisions or organizational preferences, and the selected project life cycle can influence the approach used to document and communicate the work plan. See Table 3-1 for a sample business analysis work plan.

Collaboration Point—It is beneficial for the project manager and business analyst to collaborate on how to document and communicate the work plan to ensure that the business analysis activities and schedule properly integrate into the project management plan. When the business analysis process is highly complex, the project manager may prefer that the low-level details regarding the business analysis activities be tracked by the business analyst in a separate business analysis work plan.

Table 3-1. Sample Business Analysis Work Plan

Task Name	Resource	Level Of Effort
Use Case Diagrams	S. Bhomack	34 hours
Use Case Specifications
Use Case 1
Interview SMEs	A. Manach	10 hours
Draft Use Case	A. Manach	32 hours
Review Use Case	A. Manach	2 hours
Refine Use Case	A. Manach	5 hours
Approve Use Case	A. Manach	1 hour
Use Case 2
Interview SMEs	E. Simone	12 hours
Draft Use Case	E. Simone	41 hours
Review Use Case	E. Simone	3 hours
Refine Use Case	E. Simone	6 hours
Approve Use Case	E. Simone	1 hour
Use Case 3
Interview SMEs	S. Bhomack	7 hours
Draft Use Case	S. Bhomack	22 hours
Review Use Case	S. Bhomack	1.5 hours
Refine Use Case	unassigned	3.5 hours
Approve Use Case	unassigned	1 hour

3.5.4 Document the Rationale for the Business Analysis Approach

Documenting the basis for the decisions made during the planning efforts helps to reduce uncertainty. Sharing the rationale with the stakeholders provides assurance that the plan is thought out and purposeful. For the project team, understanding the rationale behind the chosen business analysis approach provides context and helps answer questions regarding why the work is being conducted and why it is being performed in a specific manner. For the project manager, understanding the rationale for the business analysis approach provides the context needed to support and fund the work, manage it, and justify the roles and resources required to complete the work. The sponsor should understand the approach to champion, lend support, and rally stakeholders around the importance of the business analysis activities.

The business analysis plan along with the documented rationale provides valuable information for future project teams. When business analysis work is being planned for a new project, reviewing past plans and lessons learned assists with the planning work and allows analysis decisions to be based on experience. A Center of Business Analysis Practice may help to formalize the collection and storage of these assets, but for organizations that do not operate a center, an informal process for storing this information in a shared repository serves the organizational need.

3.5.5 Review the Business Analysis Plan with Key Stakeholders

Once the business analysis plan is completed, the business analyst reviews the plan with the key project stakeholders. Reviews are conducted in person; however, when stakeholders are distributed in different geographical locations, a collaborative approach may be used that allows stakeholders to raise questions and receive direct feedback to their concerns.

The objective for the review is to reduce the risk of stakeholders failing to support business analysis activities when the work begins. Stakeholders need to be comfortable with their role in the process, be aware of the time commitment to participate in the process, and understand how decisions about requirement priorities and changes are handled. Conducting these discussions up-front helps to obtain buy-in early and minimizes the risk of stakeholder conflict when the activities are underway.

There should be sufficient stakeholder involvement during these reviews to ensure stakeholder needs are adequately addressed. When stakeholders feel a sense of ownership about the process, they are more likely to demonstrate a higher level of interest and remain more engaged in the business analysis activities. The review process is a way to reduce the possibility of overlooking a stakeholder characteristic, concern, or limitation that could negatively influence the business analysis process. Reviews can reveal areas where stakeholders are confused or unclear about the requirements-related activities. Reviews sometimes uncover unknown risks such as a shortage of resources, schedule conflicts, or concern over assigned roles.

Key stakeholders in the business analysis activities should be invited to participate in the review process, for example, those having:

• Responsibility for approving, prioritizing, or validating requirements;
• Responsibility for a role in the change control process;
• Management responsibility for staff participating in the requirement activities; and
• Responsibility for serving as a subject matter expert on the project.

Additionally the project sponsor, project manager, and lead person who represent the interests of the downstream recipients of the requirements, such as the software development manager, quality assurance manager, and training manager should be included.

Collaboration Point—The business analyst should ensure to discuss the business analysis process with those who are tasked with performing the work. Key stakeholders who have an opportunity to provide input to structure the process are more likely to support the requirements-related activities.

3.5.6 Obtain Approval of the Business Analysis Plan

The business analysis plan may need to be revised to accommodate the feedback received from stakeholders. All stakeholder concerns may not be actionable, especially when the request imposes a risk to the project or reduces the effectiveness or quality of the business analysis process. The business analyst works through the issues raised and facilitates resolutions in order to avoid discouraging or disengaging stakeholders.

Once all concerns are resolved, the business analyst takes steps to obtain approval on the plan. Obtaining approval on the plan helps to reduce the following project risks:

• Stakeholders do not support the business analysis process once it starts.
• Project team underestimates the amount of time that business analysis activities will take.
• Funding allocated to the requirements phase of the project is inadequate.
• Key stakeholders underestimate the level of involvement or participation necessary for the requirement activities.
• Key resources are unavailable to participate in requirement activities, when required.
• Stakeholder expectations with regard to how requirements are documented and communicated are missed.

Approval may be formal and require a signature or may be informal and only require verbal acceptance. There may be an organizational process that defines how this approval should be attained, but when a process does not exist, the practitioner or project team should define the process. It is recommended to obtain approval from the sponsor and key stakeholders, such as the subject matter experts who will be participating in the requirements activities or anyone who approves requirements or participates in change activities. Once the business analysis plan is approved, updates to the plan should be made in a controlled fashion.

When the project uses an adaptive project life cycle, the team may forego a formal review and approval process since, in this case, much of the planning would have occurred as a result of extensive team dialogue and collaboration.

---

⁵ Project Management Institute. (2013). PMI's Pulse of the Profession® In-Depth Report: Navigating Complexity. Available from http://www.pmi.org/~/media/PDF/Business-Solutions/Navigating_Complexity.ashx