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.
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
Excel fuzzy add-in, SSIS components.
You May Also Like
These Related Stories
Business Analyst Training in 2024 | 100% Success Guarantee
How to choose the right stakeholder management technique?
The Perfect Business Analyst Interview - 10 Essential Tips
Get Email Notifications
No Comments Yet
Let us know what you think