- Elicitation and Collaboration
- 4.2 Conduct Elicitation
- 4.3 Confirm Elicitation Results
- 4.4 Communicate Business Analysis Information
- 4.5 Manage Stakeholder Collaboration
Elicitation and Collaboration
The Elicitation and Collaboration knowledge area describes the tasks that business analysts perform to obtain information from stakeholders and confirm the results. It also describes the communication with stakeholders once the business analysis information is assembled.
Elicitation is the drawing forth or receiving of information from stakeholders or other sources. It is the main path to discovering requirements and design information, and might involve talking with stakeholders directly, researching topics, experimenting, or simply being handed information. Collaboration is the act of two or more people working together towards a common goal. The Elicitation and Collaboration knowledge area describes how business analysts identify and reach agreement on the mutual understanding of all types of business analysis information. Elicitation and collaboration work is never a ‘phase’ in business analysis; rather, it is ongoing as long as business analysis work is occurring.
Elicitation and collaboration can be planned, unplanned, or both. Planned activities such as workshops, experiments, and/or surveys can be structured and organized in advance. Unplanned activities happen in the moment without notice, such as last-minute or ‘just in time’ collaboration or conversations.
Business analysis information derived from an unplanned activity may require deeper exploration through a planned activity.
Eliciting business analysis information is not an isolated activity. Information is elicited while performing any task that includes interaction with stakeholders and while the business analyst is performing independent analytical work. Elicitation may trigger additional elicitation for details to fill in gaps or increase understanding.
Elicitation and Collaboration
The Elicitation and Collaboration knowledge area is composed of the following tasks:
• Prepare for Elicitation: involves ensuring that the stakeholders have the information they need to provide and that they understand the nature of the activities they are going to perform. It also sets a shared set of expectations regarding the outcomes of the activity. Preparation may also involve identifying research sources or preparing to conduct an experiment to see if a process change actually results in an improvement.
• Conduct Elicitation: describes the work performed to understand stakeholder needs and identify potential solutions that may meet those needs. This may involve direct interaction with stakeholders, doing research, or running experiments.
• Confirm Elicitation Results: involves ensuring that stakeholders have a shared understanding of the outcomes of elicitation, that elicited information is recorded appropriately, and that the business analyst has the information sought from an elicitation activity. This task also involves comparing the information received with other information to look for inconsistencies or gaps.
• Communicate Business Analysis Information: provides stakeholders with the information they need, at the time they need it. The information is presented in a useful form, using the right terminology and concepts.
• Manage Stakeholder Collaboration: describes working with stakeholders to engage them in the overall business analysis process and to ensure that the business analyst can deliver the outcomes needed.
The Core Concept Model in Elicitation and Collaboration
The Business Analysis Core Concept Model™ (BACCM™) describes the relationships among the six core concepts.
The following table describes the usage and application of each of the core concepts within the context of Elicitation and Collaboration.
Table 4.0.1: The Core Concept Model in Elicitation and Collaboration
| Core Concept | During Elicitation and Collaboration, business analysts… |
|---|---|
| Change: the act of transformation in response to a need. | use a variety of elicitation techniques to fully identify the characteristics of the change including concerns that stakeholders have about the change. The change itself may determine the appropriate types and extent of elicitation and collaboration. |
| Need: a problem or opportunity to be addressed. | elicit, confirm, and communicate needs and supporting business analysis information. As elicitation is iterative and incremental, the understanding of needs may evolve over time. |
| Solution: a specific way of satisfying one or more needs in a context. | elicit, confirm, and communicate necessary or desired characteristics of proposed solutions. |
| Stakeholder: a group or individual with a relationship to the change, the need, or the solution. | manage the collaboration with the stakeholders who participate in the business analysis work. All stakeholders may participate in different roles and at different times during a change. |
| Value: the worth, importance, or usefulness of something to a stakeholder within a context. | collaborate with stakeholders to assess the relative value of information provided through elicitation, and apply a variety of techniques to confirm and communicate that value. |
| Context: the circumstances that influence, are influenced by, and provide understanding of the change. | apply a variety of elicitation techniques to identify business analysis information about the context that may affect the change. |
**
Figure 4.0.1: Elicitation and Collaboration Input/Output Diagram
4.1 Prepare for Elicitation
4.1.1 Purpose
The purpose of Prepare for Elicitation is to understand the scope of the elicitation activity, select appropriate techniques, and plan for (or procure) appropriate supporting materials and resources.
4.1.2 Description
Business analysts prepare for elicitation by defining the desired outcomes of the activity, considering the stakeholders involved and the goals of the initiative. This includes determining which work products will be produced using the elicitation results, deciding which techniques are best suited to produce those results, establishing the elicitation logistics, identifying any supporting materials needed, and understanding circumstances to foster collaboration during an elicitation activity.
4.1.3 Inputs
• Needs: guides the preparation in terms of the scope and purpose of elicitation activities. Elicitation can be used to discover the needs, but in order to get started there must be some need that exists—even if it has not yet been fully elicited or understood.
• Stakeholder Engagement Approach: understanding stakeholders’ communication and collaboration needs helps plan and prepare appropriate and effective elicitation events.
Figure 4.1.1: Prepare for Elicitation Input/Output Diagram
**
4.1.4 Elements
.1 Understand the Scope of Elicitation
To determine the type of business analysis information to be discovered during the elicitation activity and the techniques that may be used, business analysts consider:
• business domain,
• overall corporate culture and environment,
• stakeholder locations,
• stakeholders who are involved and their group dynamics,
• expected outputs the elicitation activities will feed,
• skills of the business analysis practitioner,
• other elicitation activities planned to complement this one,
• strategy or solution approach,
• scope of future solution, and
• possible sources of the business analysis information that might feed into the specific elicitation activity.
Understanding the scope of the elicitation activity allows business analysts to respond if the activity strays from the intended scope. It also allows them to recognize if people and materials are not available in time, and when the activity is complete.
.2 Select Elicitation Techniques
In most cases, multiple techniques are used during an elicitation activity. The techniques used depend on cost and time constraints, the types of business analysis information sources and their access, the culture of the organization, and the desired outcomes. The business analyst may also factor in the needs of the stakeholders, their availability, and their location (co-located or dispersed).
Choosing the right techniques and ensuring each technique is performed correctly is extremely important to the success of the elicitation activity. When selecting elicitation techniques, business analysts consider:
• techniques commonly used in similar initiatives,
• techniques specifically suited to the situation, and
• the tasks needed to prepare, execute, and complete each technique.
Due to changing dynamics and situations, the business analyst may be required to adjust the initial selections by incorporating more appropriate techniques. A thorough understanding of the variety of techniques available assists the business analyst in adapting to changing circumstances.
.3 Set Up Logistics
Logistics are planned prior to an elicitation activity. The logistics for each elicitation activity include identifying:
• the activity’s goals,
• participants and their roles,
• scheduled resources, including people, rooms, and tools,
• locations,
• communication channels,
• techniques, and
• languages used by stakeholders (oral and written).
The logistics may also involve creating an agenda if other stakeholders are involved.
.4 Secure Supporting Material
Business analysts identify sources of information that are needed to conduct the elicitation activity. There might be a great deal of information needed to conduct elicitation including people, systems, historical data, materials and documents.
Documents could include existing system documents, relevant business rules, organizational polices, regulations, and contracts. Supporting materials might also take the form of outputs of analysis work, such as draft versions of analysis models (see SpecifyandModelRequirements(p.136)). Business analysts procure or develop the materials and tools needed. Additional planning for experimental elicitation might be required if novel tools, equipment, or techniques are going to be used.
.5 Prepare Stakeholders
Business analysts may need to educate stakeholders on how an elicitation technique works or what information is needed. It may be helpful to explain an elicitation technique to stakeholders not involved in the activity to help them understand the validity and relevance of the information elicited. Stakeholders may be unresponsive or challenging during an elicitation activity if they feel that it is not aligned to their individual objectives, don’t understand the purpose, or are confused about the process. In preparing for elicitation, the business analyst should ensure that there is buy-in from all necessary stakeholders.
Business analysts may also prepare stakeholders by requesting that they review supporting materials prior to the elicitation activity in order to make it as effective as possible. An agenda might be provided in advance to support stakeholders in coming prepared to the activity with the necessary frame of mind and information.
Eliciting through research or exploration may be a solo activity for the business analyst and not require preparing other stakeholders.
4.1.5 Guidelines and Tools
• Business Analysis Approach: sets the general strategy to be used to guide the business analysis work. This includes the general methodology, types of stakeholders and how they should be involved, list of stakeholders, timing of the work, expected format and level of detail of elicitation results, and identified challenges and uncertainties.
• Business Objectives: describe the desired direction needed to achieve the future state. They can be used to plan and prepare elicitation events, and to develop supporting materials.
• Existing Business Analysis Information: may provide a better understanding of the goals of the elicitation activity, and aid in preparing for elicitation.
• Potential Value: describes the value to be realized by implementing the proposed future state, and can be used to shape elicitation events.
4.1.6 Techniques
• Brainstorming: used to collaboratively identify and reach consensus about which sources of business analysis information should be consulted and which elicitation techniques might be most effective.
• Data Mining: used to identify information or patterns that require further investigation.
• Document Analysis: used to identify and assess candidate sources of supporting materials.
• Estimation: used to estimate the time and effort required for the elicitation and the associated cost.
• Interviews: used to identify concerns about the planned elicitation, and can be used to seek authority to proceed with specific options.
• Mind Mapping: used to collaboratively identify and reach consensus about which sources of business analysis information should be consulted and which elicitation techniques might be most effective.
• Risk Analysis and Management: used to identify, assess, and manage conditions or situations that could disrupt the elicitation, or affect the quality and validity of the elicitation results. The plans for the elicitation should be adjusted to avoid, transfer, or mitigate the most serious risks.
• Stakeholder List, Map, or Personas: used to determine who should be consulted while preparing for the elicitation, who should participate in the event, and the appropriate roles for each stakeholder.
4.1.7 Stakeholders
• Domain Subject Matter Expert: provides supporting materials as well as guidance about which other sources of business analysis information to consult. May also help to arrange research, experiments, and facilitated elicitation.
• Project Manager: ensures that the appropriate people and resources are available to conduct the elicitation.
• Sponsor: has the authority to approve or deny a planned elicitation event, and to authorize and require the participation of specific stakeholders.
4.1.8 Outputs
• Elicitation Activity Plan: used for each elicitation activity. It includes logistics, scope of the elicitation activity, selected techniques, and supporting materials.
4.2 Conduct Elicitation
4.2.1 Purpose
The purpose of Conduct Elicitation is to draw out, explore, and identify information relevant to the change.
4.2.2 Description
There are three common types of elicitation:
• Collaborative: involves direct interaction with stakeholders, and relies on their experiences, expertise, and judgment.
• Research: involves systematically discovering and studying information from materials or sources that are not directly known by stakeholders involved in the change. Stakeholders might still participate in the research. Research can include data analysis of historical data to identify trends or past results.
• Experiments: involves identifying information that could not be known without some sort of controlled test. Some information cannot be drawn from people or documents—because it is unknown. Experiments can help discover this kind of information. Experiments include observational studies, proofs of concept, and prototypes.
One or more elicitation techniques may be used to produce the desired outcome within the scope of elicitation.
Stakeholders may collaborate in elicitation by:
• participating and interacting during the elicitation activity, and
• researching, studying, and providing feedback on documents, systems, models, and interfaces.
4.2.3 Inputs
• Elicitation Activity Plan: includes the planned elicitation activities and techniques, activity logistics (for example, date, time, location, resources,
agenda), scope of the elicitation activity, and available sources of background information.
Figure 4.2.1: Conduct Elicitation Input/Output Diagram
4.2.4 Elements
.1 Guide Elicitation Activity
Understanding the proposed representations of business analysis information, which were defined in planning, helps ensure that the elicitation activities are focused on producing the intended information at the desired level of detail. This applies to each instance of an elicitation activity throughout a change and may vary based on the activity. In order to help guide and facilitate towards the expected outcomes, business analysts consider:
• the elicitation activity goals and agenda,
• scope of the change,
• what forms of output the activity will generate,
• what other representations the activity results will support,
• how the output integrates into what is already known,
• who provides the information,
• who will use the information, and
• how the information will be used.
While most of these are considered when planning for the elicitation activity (see Prepare for Elicitation (p. 56)), they are also all important while performing the elicitation activity in order to keep it on track and achieve its goal. For example, stakeholders might have discussions that are out of scope for the activity or change, and the business analyst needs to recognize that in the moment to determine the next step; either acknowledge it and continue, or guide the conversation differently.
The business analyst also uses this information to determine when there has been sufficient elicitation, in order to stop the activity.
.2 Capture Elicitation Outcomes
Conducting elicitation is frequently iterative and takes place in a series of sessions—in parallel or in sequence—according to the scope of the elicitation activity (see PrepareforElicitation(p.56)). If the elicitation activity is unplanned, outcomes are captured and integrated into the appropriate planned outcomes.
Capturing the elicitation outcomes helps to ensure that the information produced during elicitation activities is recorded for later reference and use.
4.2.5 Guidelines and Tools
• Business Analysis Approach: influences how each elicitation activity is performed, as it identifies the types of outputs that will be needed based on the approach.
• Existing Business Analysis Information: may guide the questions posed during elicitation and the approach used to draw out information from various stakeholders.
• Stakeholder Engagement Approach: provides collaboration and communication approaches that might be effective during elicitation.
• Supporting Materials: includes any materials to prepare both the business analyst and participants before elicitation, as well as any information, tools, or equipment to be used during the elicitation.
4.2.6 Techniques
• Benchmarking and Market Analysis: used as a source of business analysis information by comparing a specific process, system, product, service, or structure with some external baseline, such as a similar organization or baseline provided by an industry association. Market analysis is used to determine what customers want and what competitors provide.
• Brainstorming: used to generate many ideas from a group of stakeholders in a short period, and to organize and prioritize those ideas.
• Business Rules Analysis: used to identify the rules that govern decisions in an organization and that define, constrain, or enable organizational operations.
• Collaborative Games: used to develop a better understanding of a problem or to stimulate creative solutions.
• Concept Modelling: used to identify key terms and ideas of importance and define the relationships between them.
• Data Mining: used to identify relevant information and patterns.
• DataModelling: used to understand entity relationships during elicitation.
• Document Analysis: used to review existing systems, contracts, business procedures and policies, standards, and regulations.
• Focus Groups: used to identify and understand ideas and attitudes from a group.
• Interface Analysis: used to understand the interaction, and characteristics of that interaction, between two entities, such as two systems, two organizations, or two people or roles.
• Interviews: used to ask questions of stakeholders to uncover needs, identify problems, or discover opportunities.
• Mind Mapping: used to generate many ideas from a group of stakeholders in a short period, and to organize and prioritize those ideas.
• Observation: used to gain insight about how work is currently done, possibly in different locations and in different circumstances.
• Process Analysis: used to understand current processes and to identify opportunities for improvement in those processes.
• ProcessModelling: used to elicit processes with stakeholders during elicitation activities.
• Prototyping: used to elicit and validate stakeholders’ needs through an iterative process that creates a model of requirements or designs.
• Survey or Questionnaire: used to elicit business analysis information, including information about customers, products, work practices, and attitudes, from a group of people in a structured way and in a relatively short period of time.
• Workshops: used to elicit business analysis information, including information about customers, products, work practices, and attitudes, from a group of people in a collaborative, facilitated way.
4.2.7 Stakeholders
• Customer: will provide valuable business analysis information during elicitation.
• Domain Subject Matter Expert: has expertise in some aspect of the situation and can provide the required business analysis information. Often guides and
assists the business analyst in identifying appropriate research sources, and may help to arrange research, experiments, and facilitated elicitation.
• End User: the user of existing and future solutions, who should participate in elicitation.
• Implementation Subject Matter Expert: designs and implements a solution and provides specialist expertise, and can participate in elicitation by asking clarifying questions and offering alternatives.
• Sponsor: authorizes and ensures that the stakeholders necessary to participate in elicitation are involved.
• Any stakeholders: could have relevant knowledge or experience to participate in elicitation activities.
4.2.8 Outputs
• Elicitation Results (unconfirmed): captured information in a format that is specific to the elicitation activity.
4.3 Confirm Elicitation Results
4.3.1 Purpose
The purpose of Confirm Elicitation Results is to check the information gathered during an elicitation session for accuracy and consistency with other information.
4.3.2 Description
Elicited information is confirmed to identify any problems and resolve them before resources are committed to using the information. This review may discover errors, omissions, conflicts, and ambiguity.
The elicitation results can be compared against their source and other elicitation results to ensure consistency. Collaboration with stakeholders might be necessary to ensure their inputs are correctly captured and that they agree with the results of non-facilitated elicitation. If information is not correct, the business analyst determines what is correct, which can require more elicitation. Committing resources to business analysis activities based on unconfirmed elicitation results may mean stakeholder expectations are not met. If the results are inconsistent, additional elicitation might need to be conducted to resolve the discrepancies.
Confirming the elicitation results is a much less rigorous and formal review than occurs during analysis.
4.3.3 Inputs
• Elicitation Results (unconfirmed): capture information in a format specific to the elicitation activity.
Figure 4.3.1: Confirm Elicitation Results
Input
**
Guidelines and Tools
Elicitation Activity Plan
Existing Business Analysis Information
4.2
Elicitation Results (unconfirmed)
4.3
Confirm Elicitation Results
Output
4.3.4 Elements
.1 Compare Elicitation Results Against Source Information
Task Conduct Elicitation (p. 61)describes sources from which elicitation results may be derived, including documents and stakeholder knowledge. The business analyst may lead follow-up meetings where stakeholders correct the elicitation results. Stakeholders may also confirm the elicitation results independently.
.2 Compare Elicitation Results Against Other Elicitation Results
Business analysts compare results collected through multiple elicitation activities to confirm that the information is consistent and accurately represented. As comparisons are drawn, business analysts identify variations in results and resolve them in collaboration with stakeholders. Comparisons may also be made with historical data to confirm more recent elicitation results.
Inconsistencies in elicitation results are often uncovered when business analysts develop specifications and models. These models may be developed during an elicitation activity to improve collaboration.
4.3.5 Guidelines and Tools
• Elicitation Activity Plan: used to guide which alternative sources and which elicitation results are to be compared.
• Existing Business Analysis Information: can be used to confirm the results of elicitation activities or to develop additional questions to draw out more detailed information.
4.3.6 Techniques
• Document Analysis: used to confirm elicitation results against source information or other existing documents.
• Interviews: used to confirm the business analysis information and to confirm that the integration of that information is correct.
• Reviews: used to confirm a set of elicitation results. Such reviews could be informal or formal depending on the risks of not having correct, useful, and relevant information.
• Workshops: used to conduct reviews of the drafted elicitation results using any level of formality. A predetermined agenda, scripts, or scenario tests may be used to walk through the elicitation results, and feedback is requested from the participants and recorded.
4.3.7 Stakeholders
• Domain Subject Matter Experts: people with substantial knowledge, experience, or expertise about the business analysis information being elicited, or about the change or the solution, help to confirm that elicitation results are correct, and can help to identify omissions, inconsistencies and conflicts in elicitation results. They can also confirm that the right business analysis information has been elicited.
• Any stakeholder: all types of stakeholders may need to participate in confirming elicitation results.
4.3.8 Outputs
• Elicitation Results (confirmed): integrated output that the business analyst and other stakeholders agree correctly reflects captured information and confirms that it is relevant and useful as an input to further work.
4.4 Communicate Business Analysis Information
4.4.1 Purpose
The purpose of Communicate Business Analysis Information is to ensure stakeholders have a shared understanding of business analysis information.
4.4.2 Description
Business analysts must communicate appropriate information to stakeholders at the right time and in formats that meet their needs. Consideration is given to expressing the information in language, tone, and style that is appropriate to the audience.
Communication of business analysis information is bi-directional and iterative. It involves determining the recipients, content, purpose, context, and expected outcomes. Task Plan Stakeholder Engagement (p. 31)evaluates communication needs and plans anticipated messages.
Communicating information does not simply involve pushing information out and assuming it was received and understood. Business analysts engage stakeholders to ensure they understand the information and gain agreement. The business analyst acts on any disagreements. The method of delivering the information may need to change if the stakeholders are not receiving or understanding it. Multiple forms of communication might be required for the same information.
4.4.3 Inputs
• Business Analysis Information: any kind of information at any level of detail that is used as an input or output of business analysis work. Business analysis information becomes an input for this task when the need is discovered to communicate the information to additional stakeholders.
• Stakeholder Engagement Approach: describes stakeholder groups, roles, and general needs regarding communication of business analysis information.
Figure 4.4.1: Communicate Business Analysis Information Input/Output Diagram
4.4.4 Elements
.1 Determine Objectives and Format of Communication
Business analysis information packages may be prepared for a number of reasons including—but not limited to—the following:
• communication of requirements and designs to stakeholders,
• early assessment of quality and planning,
• evaluation of possible alternatives,
• formal reviews and approvals,
• inputs to solution design,
• conformance to contractual and regulatory obligations, and
• maintenance for reuse.
The primary goal of developing a package is to convey information clearly and in usable format for continuing change activities. To help decide how to present requirements, business analysts ask the following types of questions:
• Who is the audience of the package?
• What will each type of stakeholder understand and need from the communication?
• What is each stakeholder’s preferred style of communication or learning?
• What information is important to communicate?
• Are the presentation and format of the package, and the information contained in the package, appropriate for the type of audience?
• How does the package support other activities?
• Are there any regulatory or contractual constraints to conform to? Possible forms for packages may include:
• Formal Documentation: is usually based on a template used by the
organization and may include text, matrices, or diagrams. It provides a stable, easy to use, long-term record of the information.
• Informal Documentation: may include text, diagrams, or matrices that are used during a change but are not part of a formal organizational process.
• Presentations: deliver a high-level overview appropriate for understanding goals of a change, functions of a solution, or information to support decision making.
Consideration is given to the best way to combine and present the materials to convey a cohesive and effective message to one or more stakeholder groups.
Packages can be stored in different online or offline repositories, including documents or tools.
.2 Communicate Business Analysis Package
The purpose of communicating the business analysis package is to provide stakeholders with the appropriate level of detail about the change so they can understand the information it contains. Stakeholders are given the opportunity to review the package, ask questions about the information, and raise any concerns they may have.
Selecting the appropriate communication platform is also important. Common communication platforms include:
• Group collaboration: used to communicate the package to a group of relevant stakeholders at the same time. It allows immediate discussion about the information and related issues.
• Individual collaboration: used to communicate the package to a single stakeholder at a time. It can be used to gain individual understanding of the information when a group setting is not feasible, most productive, or going to yield the best results.
• E-mail or other non-verbal methods: used to communicate the package when there is a high maturity level of information that will need little or no verbal explanation to support it.
4.4.5 Guidelines and Tools
• Business Analysis Approach: describes how the various types of information will be disseminated rather than what will be disseminated. It describes the level of detail and formality required, frequency of the communications, and how communications could be affected by the number and geographic dispersion of stakeholders.
• Information Management Approach: helps determine how business analysis information will be packaged and communicated to stakeholders.
4.4.6 Techniques
• Interviews: used to individually communicate information to stakeholders.
• Reviews: used to provide stakeholders with an opportunity to express feedback, request required adjustments, understand required responses and actions, and agree or provide approvals. Reviews can be used during group or individual collaboration.
• Workshops: used to provide stakeholders with an opportunity to express feedback and to understand required adjustments, responses, and actions. They are also useful for gaining consensus and providing approvals. Typically used during group collaboration.
4.4.7 Stakeholders
• End User: needs to be communicated with frequently so they are aware of relevant business analysis information.
• Customer: needs to be communicated with frequently so they are aware of relevant business analysis information.
• Domain Subject Matter Expert: needs to understand the business analysis information as part of confirming and validating it throughout the change initiative.
• Implementation Subject Matter Expert: needs to be aware of and understand the business analysis information, particularly requirements and designs, for implementation purposes.
• Tester: needs to be aware of and understand the business analysis information, particularly requirements and designs for testing purposes.
• Any stakeholder: all types of stakeholders will likely need to be communicated with at some point during the change initiative.
4.4.8 Outputs
• Business Analysis Information (communicated): business analysis information is considered communicated when the target stakeholders have reached an understanding of its content and implications.
4.5 Manage Stakeholder Collaboration
4.5.1 Purpose
The purpose of Manage Stakeholder Collaboration is to encourage stakeholders to work towards a common goal.
4.5.2 Description
Business analysis work lends itself to many collaboration opportunities between groups of stakeholders on the business analysis work products. Stakeholders hold various degrees of influence and authority over the approval of work products, and are also an important source of needs, constraints, and assumptions. As the business analysis work progresses, the business analyst identifies stakeholders, confirms their roles, and communicates with them to ensure that the right stakeholders participate at the right times and in the appropriate roles.
Managing stakeholder collaboration is an ongoing activity. Although managing stakeholder collaboration begins once stakeholders have been identified and analyzed, new stakeholders may be identified at any point during an initiative. As new stakeholders are identified, their role, influence, and relationship to the initiative are analyzed. Each stakeholder’s role, responsibility, influence, attitude, and authority may change over time.
The more significant the impact of the change or its visibility within the organization, the more attention is directed to managing stakeholder collaboration. Business analysts manage stakeholder collaboration to capitalize on positive reactions, and mitigate or avoid negative reactions. The business analyst should constantly monitor and assess each stakeholder’s attitude to determine if it might affect their involvement in the business analysis activities.
Poor relationships with stakeholders can have many detrimental effects on business analysis, including:
• failure to provide quality information,
• strong negative reactions to setbacks and obstacles,
• resistance to change,
• lack of support for, and participation in, business analysis work, and
• business analysis information being ignored.
These effects can be modified in part through strong, positive, and trust-based relationships with stakeholders. Business analysts actively manage relationships with stakeholders who:
• provide services to the business analyst, including inputs to business analysis tasks and other support activities,
• depend on services provided by the business analyst, including outputs of business analysis tasks, and
• participate in the execution of business analysis tasks.
4.5.3 Inputs
• Stakeholder Engagement Approach: describes the types of expected engagement with stakeholders and how they might need to be managed.
• Business Analysis Performance Assessment: provides key information about the effectiveness of business analysis tasks being executed, including those focused on stakeholder engagement.
Figure 4.5.1: Manage Stakeholder Collaboration Input/Output Diagram
4.5.4 Elements
.1 Gain Agreement on Commitments
Stakeholders participate in business analysis activities that may require time and resource commitments. The business analyst and stakeholders identify and agree upon these commitments as early in the initiative as possible. The specific details of the commitments can be communicated formally or informally, as long as there is explicit understanding of the expectations and desired outcomes of the commitment.
There may be dialogue and negotiation regarding the terms and conditions of the commitments. Effective negotiation, communication, and conflict resolution skills are important to effective stakeholder management (see NegotiationandConflict Resolution (p.210)).
.2 Monitor Stakeholder Engagement
Business analysts monitor the participation and performance of stakeholders to ensure that:
• the right subject matter experts (SMEs) and other stakeholders are participating effectively,
• stakeholder attitudes and interest are staying constant or improving,
• elicitation results are confirmed in a timely manner, and
• agreements and commitments are maintained. Business analysts continually monitor for such risks as:
• stakeholders being diverted to other work,
• elicitation activities not providing the quality of business analysis information required, and
• delayed approvals.
.3 Collaboration
Stakeholders are more likely to support change if business analysts collaborate with them and encourage the free flow of information, ideas, and innovations. Genuine stakeholder engagement requires that all stakeholders involved feel that they are heard, their opinions matter, and their contributions are recognized.
Collaboration involves regular, frequent, and bi-directional communication. Collaborative relationships help maintain the free flow of information when obstacles and setbacks occur, and promote a shared effort to resolve problems and achieve desired outcomes.
4.5.5 Guidelines and Tools
• Business Analysis Approach: describes the nature and level of collaboration required from each stakeholder group to perform planned business analysis activities.
• Business Objectives: describe the desired direction needed to achieve the future state. They can be used to focus diverse stakeholders on a common vision of the desired business outcomes.
• Future State Description: defines the desired future state and the expected value it delivers which can be used to focus diverse stakeholders on the common goal.
• Recommended Actions: communicating what should be done to improve the value of a solution can help to galvanize support and focus stakeholders on a common goal.
• Risk Analysis Results: stakeholder-related risks will need to be addressed to ensure stakeholder collaboration activities are successful.
4.5.6 Techniques
• Collaborative Games: used to stimulate teamwork and collaboration by temporarily immersing participants in a safe and fun situation in which they can share their knowledge and experience on a given topic, identify hidden assumptions, and explore that knowledge in ways that may not occur during the course of normal interactions.
• Lessons Learned: used to understand stakeholders’ satisfaction or dissatisfaction, and offer them an opportunity to help improve the working relationships.
• Risk Analysis and Management: used to identify and manage risks as they relate to stakeholder involvement, participation, and engagement.
• Stakeholder List, Map, or Personas: used to determine who is available to participate in the business analysis work, show the informal relationships between stakeholders, and understand which stakeholders should be consulted about different kinds of business analysis information.
4.5.7 Stakeholders
• All stakeholders: all types of stakeholders who might be involved in collaboration during change.
4.5.8 Outputs
• Stakeholder Engagement: willingness from stakeholders to engage in business analysis activities and interact with the business analyst when necessary.
