How to Effectively Engage Stakeholders? - Adaptive US

All Business Analysis Initiatives require some level of interaction with people in the organization. A large part of the business analyst's work involves engagement to gather data about their stakeholders' issues and needs. Projects are about people, and success is about creating value for those people.

Very often, as a BA, I have to anticipate stakeholder expectations such that requirements elicitation covers a maximum number of deliverable. Microsoft Flow and SharePoint are a good example where 'no code' drives the way business user interacts with the system. Sometimes high-end code development is not necessary. Providing results as part of elicitation can win new projects as long as project expenditures are well under budget and within schedule.

If I prioritize the wrong stakeholders and don't estimate their power and level of interest, I stand to lose out on essential/crucial opinions. So, time and again, I go back to concepts. BABOK explains this stakeholder engagement concept as illustrated above, which is to keep people with high power higher levels of interest closest to all business analysis activities. A crucial part of stakeholder analysis for a business analyst is identifying the project stakeholders and the level of influence they have over the project.

Through this article, I'll be narrating my personal experience dealing with multiple roles that evaluated my elicitation outcomes and how I engaged with those roles/stakeholders effectively.

Stakeholder Engagement in My Projects

My interaction with stakeholder roles, during the last few years, have primarily been during system integration for Workday, Destiny LOS, and Microsoft Dynamics CRM. I not only play the role of a Business Analyst, but also that of VBA functional/technical programmer, IT contractor, and consultant. Some of my recent projects, elicitation deliverable, had the following scope:

• Immediate need to transition the current system into the future state for specific process models
• Interim preparation between CRM version upgrades that affect data cleansing using 'no-code' SSIS components data flow models.

Irrespective of any project scope, the following elicitation methods, hold the weight while engaging with any group of stakeholders:

• Find out who your stakeholders are and understand their aspirations, goals, interest, and level of involvement in the project. Understanding stakeholder needs will help in customizing delivery
• Assess their level of impact and prioritize your interactions with them
• Plan a stakeholder engagement strategy and collaborate with them effectively
• Keep track of the scope
• Be attentive during meetings and virtual sessions
• Bide time during elicitation
• Prepare and analyze elicitation outcomes
• Be attentive to stakeholders
• Have a keen eye for problem-solving
• Review and monitor your outcomes and accommodate change when required
• Utilize many techniques based on business analysis tasks starting with stakeholder lists, maps, and personas and then diversify into other methods. Please read further.

Stakeholders List, Map, and Persona

During the new system integrations as an external contractor/consultant, it is essential to plan stakeholder engagement to adhere to the client's current state description and change strategy.

Business analysts understand the scope of the system and data spread across customers, business end-users, project managers, developers, and supplier stakeholder groups through active interaction and collaboration. Stakeholder lists are a well-known BA technique for consulting assignments as well as other projects.

Other Business Analysis Techniques

For new project deliverable, stakeholders depend on me for techno-functional business analysis and process management documentation. On the data front, I use data models, research, descriptive data mining, brainstorming, business rules analysis, lessons learned, data modeling, document analysis, workshops, and interface analysis. However, process model/analysis, and walk through are non-technical methods. I will explain what I mean by both techno-functional and non-technical elicitation.

Firstly by 'techno-functional,' I mean wearing the hat of VBA coder for Excel and Access data and looking for 'no code' efficacies in document analysis using research. I create data flow automation using Microsoft Flow, SSIS components for SQL Server and then assemble my research and data documents as business analysis information for further IT integration. I bring an automation request up to speed so that developers, SharePoint, and System Administrator IT roles refer to this information for proposed requirement analysis and solution analysis.

Secondly, as part of process management, I typically complete elicitation using Visio process models and process analysis.

My Interactions with Relevant Stakeholders

Below, I have highlighted the importance of stakeholder engagement by tying all the roles that I interacted with as a Business Analyst (BA), who were enablers to effective solution implementation and requirement analysis across multiple elicitation and collaboration efforts. Let's see what these roles did:

Project Manager Role

• Completed system walk-through and accepted my data analysis inputs to evaluate outputs using new implementation's system features, thus creating entity record linearity for one master record to multiple subordinate files using two records merge MS Dynamics CRM feature.
• Observed the BA doing manual keying of combining two different entities as part of individual record de-duplication during interface analysis.
• Brainstormed alongside the BA for project closure backlog management.
• Planned how the BA prepares, conducts, and confirms elicitation within an estimated timeline of a year, plus how to communicate gathered information for stakeholder collaboration.

IT Managers Role

• As a sponsor, IT management provided a clear idea of the desired outcome, i.e., entity record de-duplication required data cleansing to activate advanced search CRM indexing features
• Incumbent BA needed to have a keen interest in agile methodologies and data to meet the desired outcome of the business need to cleanse data between the first and second CRM system versions

Domain and Implementation Subject Matter Expert (SME)

• Expert assessors as users in business areas such as Accounting, Treasury, Legal, or Agencies
• Aid in completing business analysis packages constituting templates such as SIPOC
• Approve compliance request and validate recommended actions through further collaboration

SMEs – CRM Developers

• Evaluated business analysis outcome for elicitation during workshops
• Guided BA change strategy improvements such as SharePoint stored business analysis documents preparation and glossary which were affected, to make critical terms accessible for IT and business users
• Validated requirements documents through Excel VBA flowcharts and Excel fuzzy add-in data analysis
• Reviewed SSAS data flows that completed primary deduplication task

Business Analyst (BA) – IT Role

I played the role of an IT BA for a consulting project that concluded about a year back. The conclusion mentioned herewith are for all tasks that was in the past.

I completed data flows and provided technical specifications translating data analysis into requirements through elicitation outputs. Elicitation documents gave two scenarios for both mass merge and system-wide organizational hierarchy.

After project close, users realized requirements validity when indexed search became available – this feature was inaccessible before record deduplication. Users received near similarity entity vendor records through data analysis.

For IT developers, I provided data layout to enable similarly or misspelled phrase mass merge. Fuzzy add-in Excel report was useful for vendor names comprising two or more words. I provided research for a system-wide upgrade for use in the organization hierarchy. IT offered a glimpse to business users on the next version implementation - cloud and address verification services in addition to organization hierarchy in SharePoint documents. 

Business Analyst – Process and Requirements Discovery

Process analysis and requirements discovery are my current projects. I work with domain and implementation SMEs and plan to deliver clarification documents to discover user requirements.

For process and program management, simplistic as-is documentation for requirements discovery starts with current standard operating procedures. I then complete clarification, recommendations, and gap analysis documentation of AS-IS process (SIPOC) documents covering insights gathered during process walk-through.

For current projects, I focus on short iterations for producing documents, and the key roles are domain and implementation SMEs from Accounting and Financial Systems domain for Work Day implementation.

Conclusion

To conclude, determining the stakeholders of the project early on and engaging effectively with them determines the success of the project. If they feel ignored or overlooked, it can affect the project negatively. BABOK outlines elicitation and collaboration tasks across knowledge areas in much greater detail than I mentioned here. This article talks about my experiences in the last few years. Finally, it’s important to always keep yourself updated by reading and researching online and finding that coveted information liked by your stakeholders!

Project Terms Used in the Article

Technical terms have a much deeper meaning and scope, so much so that it encompasses the need for advanced knowledge and practical experience. I acknowledge the following are project specific technical terms only: Data Cleansing, Record Deduplication, SSAS components, SSAS data flows, Excel fuzzy add-in, SSIS components.

How to manage negative stakeholders?
How to handle aggressive stakeholders
Stakeholder Management